Con la entrada en vigencia del estándar PCI PIN v2.0 en el año 2014, todas las claves simétricas cifradas (criptogramas) deben ser manejadas en estructuras denominadas key blocks, que permiten proteger de forma estandarizada la integridad de dichas claves criptográficas y asociarlas de forma inequívoca a un uso en particular para evitar modificaciones o sustituciones no autorizadas. El presente artículo describe de forma general la historia y la necesidad del uso de key blocks, así como las fechas estipuladas para la implementación global de este mecanismo de seguridad.

Actualización enero 2023: Todas las referencias a ASC X9 TR 31: Interoperable Secure Key Exchange Key Block Specification han sido remplazadas por X9.143 Retail Financial Services: Interoperable Secure Key Block Specification.

Introducción

Uno de los algoritmos de encriptación de cifrado por bloques que más se usó en el ámbito financiero fue el algoritmo Data Encryption Standard (DES), también conocido como Data Encryption Algorithm (DEA). Este algoritmo fue originalmente escogido como un estándar FIPS en 1976 y actualmente es considerado inseguro, debido a que el tamaño de su longitud de clave (56 bits reales de clave y 8 bits de paridad) es muy corto y puede ser comprometido fácilmente con las técnicas computacionales actuales (ejemplos de ello son la máquina para romper DES de la EFF, Cost-Optimized Parallel COde Breaker (COPACABANA) y  Crack.sh: The World’s Fastest DES Cracker, entre otros).

Figura 1. Estructura de una clave DES: 64 bits, de los cuales el último bit de cada octeto se usa como bit de paridad

Como respuesta a este problema, se empezó a hacer uso de dos algoritmos que empleaban la misma base de DES pero que agregaban nueva complejidad al proceso usando iteraciones y claves adicionales:

• Double-DES (2DES o 2DEA) usa dos instancias de DES en el mismo bloque de texto en claro. En cada instancia usa diferentes claves de encriptación. Actualmente, este algoritmo está obsoleto.

Figura 2. Double DES (K1 ≠ K2)

• Triple-DES (3DES o TDEA) usa tres instancias de DES en el mismo texto en claro, pudiendo emplear dos claves (Double-length TDEA) o tres claves diferentes de encriptación (Triple-length TDEA).

Figura 3. Double-length TDEA (K1 ≠ K2)

Figura 4. Triple-length TDEA (K1 ≠ K2 ≠ K3)

El conjunto de claves empleadas en 2DES y 3DES y su orden específico se denomina Key Bundle, un concepto introducido en la década de 1990. Como se puede observar, al hacer uso de varias claves se debe establecer el orden de dichas claves o, de lo contrario, el proceso de desencriptación no será correcto. Adicionalmente, el uso de key bundles ayuda a proteger contra ataques de Meet-in-the-middle, orientados a la obtención de las claves criptográficas en cifrados que usan dos o más claves en múltiples rondas de encriptación con el mismo algoritmo.

Sin embargo, el uso de key bundles no garantiza la seguridad completa del criptosistema. Uno de los principales problemas radica en la seguridad durante el proceso de intercambio y almacenamiento de las claves simétricas en entornos hostiles. Por lo general, estas claves se comparten o almacenan encriptándolas con otra clave (key-encrypting key – KEK). Si una KEK es transmitida o almacenada sin ningún tipo de atributos que restrinjan su uso a procesos específicos (cifrado de otra clave), un atacante podría explotar esta vulnerabilidad como parte de un ataque al criptosistema (criptoanálisis).

Una de las alternativas más usadas para gestionar este problema es mediante el uso de variantes (Key Variants). Las variantes son creadas mediante la combinación de una máscara binaria con la clave original, dependiendo del tipo de implementación (Atalla variant, Thales variant, IBM variant o Control Vectors, etc.). No obstante, este método no provee ninguna funcionalidad para verificación de la integridad o autenticación de la clave.

Para resolver este inconveniente, se hace uso de otro concepto adicional de protección criptográfica para claves denominado Key Wrapping, que puede ser usado indistintamente para TDEA (Triple DEA Key Wrap – TKW) como para AES (AES Key Wrap – AESKW o AES Key Wrap With Padding – KWP). El propósito del key wrapping es vincular inequívocamente la clave (AES o todas las claves de un Key Bundle de TDEA) a información adicional (metadatos), estableciendo políticas específicas de uso a cada clave. En términos generales, el uso de key wrapping permite:

1. Asociar el tipo/propósito de una clave criptográfica para asegurar que esta clave no se utiliza para otro propósito que no sea el designado, por ejemplo, como clave de cifrado de claves (KEK) o como clave de cifrado de PIN.
2. Proteger la integridad de la clave, incluido el orden de las partes de la clave en el caso de algoritmos que requieren múltiples claves, por ejemplo, TDEA.

De esta manera, las funcionalidades provistas por los key bundles y las variantes (key variants) se pueden desplegar empleando únicamente key wrapping. Técnicamente, el concepto de key wrapping dió origen a lo que se conoce actualmente como Key Blocks.

Estructura de los Key Blocks

De acuerdo con los requisitos 18-3 de PCI PIN v3.0 y de P2PE v3.0, algunos de los métodos aceptables para la implementación de key blocks son:

• Uso de una función MAC (Message Authentication Code) aplicada sobre la concatenación de los atributos en texto claro y la parte encriptada del Key Block, el cual incluye la clave (ejemplo: ANSI X9.143 e ISO 20038),
• Una firma digital computada sobre todos estos datos (ejemplo: ASC X9 TR 34), o
• Una función de verificación de integridad que es una parte implícita del proceso de encriptación de claves como el que se utiliza en el proceso de key-wrapping en claves AES, especificado en ANSI X9.102.

Existen múltiples implementaciones propietarias de estos métodos de key blocks, incluyendo Atalla Key Blocks (AKB) y Thales Key Blocks (TKB). Con el fin de evitar problemas de compatibilidad y garantizar consistencia con ANSI X9.24, ANSI desarrolló en 2017 el reporte técnico ASC X9 TR-31: Interoperable Secure Key Exchange Key Block Specification.  Este reporte fue actualizado en 2021 y finalmente renombrado en 2022 a ANSI X9.143-2022: Retail Financial Services Interoperable Secure Key Block Specification que, hoy por hoy, es el método de facto para la implementación de key blocks.

En X9.143, cada key block contiene una clave protegida, la información de sus limitaciones de uso y otros metadatos que se protegen mediante un mecanismo de key wrapping, de la siguiente manera:

Figura 5. Estructura de Key Block usando ANSI X9.143

Este modelo implica la generación de una nueva clave de encriptación (Key-Block Protection Key – KBPK) de la cual se derivarán dos claves adicionales:

• Key-Block Encryption Key (KBEK), usada para encriptar la sección que contiene el criptograma de la clave y su longitud, y
• Key-Block Authentication Key (KBAK), usada para para generar un código de autenticación de mensaje (Message Authentication Code – MAC) de todo el contenido del Key Block. Esta clave también se conoce como Key-Block MAC Key (KBMK).

Estructura del encabezado (header) de Key Block (ANSI X9.143)

Mediante el uso de estas estructuras se garantiza que el cambio o remplazo de cualquier bit en los atributos o en la clave de encriptación podrán ser detectados de forma efectiva.

Figura 6. Ejemplo de decodificación de un Key Block, incluyendo la descripción del encabezado, empleando BP-Tools de EFTlab (https://www.eftlab.com/bp-tools/)

Uso de los Key Blocks

Generalmente, las claves de encriptación se pueden almacenar o transmitir mediante cualquiera de los siguientes métodos:

1. Al menos en dos key shares separados o en componentes
2. Contenidos dentro de un dispositivo criptográfico seguro (Secure Cryptographic Device – SCD)
3. Encriptados con una clave de igual o de mayor fortaleza que la clave protegida

Tradicionalmente, cuando se almacenan o transmiten claves encriptándolas con otras claves (denominadas Key-encrypting (encipherment or exchange) keys –  KEK) no se puede garantizar que la KEK solo podrá ser usada para la encriptación o desencriptación de otras claves ni se puede validar su integridad. En ese caso, el uso de Key Blocks es indispensable y es aplicable en cualquier momento en el que una clave criptográfica exista fuera de los límites de un dispositivo criptográfico de seguridad (SCD).

¿Qué tipo de claves deben ser protegidas empleando Key Blocks?

El concepto de key wrapping / key blocks es aplicable a cualquier clave simétrica cifrada que tenga que ser almacenada fuera de los límites de seguridad de un SCD o que sea transferida a una entidad externa.

Desde la perspectiva de PCI PIN y P2PE, el uso de key blocks es obligatorio para todas las claves simétricas intercambiadas o almacenadas bajo otra clave simétrica bajo los escenarios de clave fija (fixed key) y master key/session key (por ejemplo, Zone Master Keys (ZMK), Key-Encipherment Keys (KEKs), Terminal Master Keys (TMKs) y PIN-Encryption Keys (PEKs)).

Igualmente, en el caso de DUKPT, el uso de Key Blocks es aplicable a Base Derivation Keys (BDKs) y las claves iniciales de DUKPT (initial DUKPT keys).

También es importante resaltar que todos los módulos de seguridad de hardware (Hardware Security Modules – HSM) certificados como PCI HSM y todos los dispositivos de aceptación de PIN (Point-of-Interaction – POI) a partir de la versión 2 de PCI PTS POI (publicada en 2007) soportan TR-31 o métodos equivalentes.

Periodos de implementación de Key Blocks

Con el fin de permitir una migración coordinada y escalonada hacia los Key Blocks, en julio de 2020 (para PCI PIN) y en agosto de 2020 (para P2PE) el PCI SSC definió las siguientes fases y sus fechas relacionadas (modificadas debido al impacto del COVID-19):

• Fase 1: Se deben implementar Key Blocks para todas las conexiones internas y almacenamiento de claves dentro del entorno del Proveedor de Servicios. Esto puede incluir aplicaciones y bases de datos conectadas a Módulos de Seguridad de Hardware (HSM). Fecha de entrada en vigor: 1 de junio de 2019 (completado).
• Fase 2: Se deben implementar Key Blocks para conexiones externas a asociaciones y redes. Fecha de entrada en vigor: 1 de enero de 2023 (completado).
• Fase 3: Extensión de la implementación de Key Blocks a todos los hosts de comerciantes, terminales de puntos de venta y cajeros electrónicos. Fecha de entrada en vigor: 1 de enero de 2025.

Es importante anotar que las marcas de pago (principalmente Visa entro de su programa Visa PIN) también han hecho énfasis en la migración hacia Key Blocks.

¿Qué se debe hacer en cada una de las fases de migración para cumplir con las fechas de implementación de Key Blocks?

La migración desde claves tradicionales a claves en formato key block para su transmisión y almacenamiento requiere planificación y tiempo, así como soporte de entidades externas como fabricantes de HSMs, fabricantes de dispositivos de puntos de interacción (POIs) y empresas con las cuales hay conexiones con datos cifrados desde la entidad (KIF, emisores, etc.). A continuación se describen de forma general las tareas que se deben realizar en cada una de las fases:

Fase I: Conexiones internas y almacenamiento dentro de la entidad

• Todos los repositorios de criptogramas (claves criptográficas cifradas con otras claves) que se encuentren fuera de los límites seguros de un HSM deben ser migrados a key blocks. Esto incluye criptogramas almacenados en bases de datos, ficheros, etc. En función de la jerarquía de claves existentes en la organización, las claves que se encuentran fuera de un HSM pueden estar cifradas por la clave maestra del HSM (Master File Key / Local Master Key) o por otras claves de cifrado (Key-Encrypting Keys – KEK), por lo que dichas claves (MFK/LMK/KEK) deben ser migradas para generar Key Block Protection Keys (KBPK) y poder cifrar otras claves usando key blocks.

Fase II: Conexiones externas a asociaciones y redes

• Todas las KEK (Zone Master Keys – ZMK) que se empleen para la transmisión de claves de cifrado de PIN con entidades externas (Acquirer Working Key (AWK), Issuer Working Key (IWK), etc.) deben ser remplazadas por KBPKs.
• Esta migración de claves afecta no solo al entorno de adquiriencia sino al de emisión, por lo que los emisores y centros autorizadores están obligados a migrar sus claves. De igual manera, si la entidad comparte claves con servicios de inyección de claves (Key Injection Facilities (KIF), CA/RAs, etc.), las claves de transporte deberan ser migradas a formato key block.

Fase III: Hosts de comerciantes, terminales de puntos de venta y cajeros electrónicos

• Todas las KEK (Terminal Master Key – TMK) que se empleen para la transmisión de claves de cifrado de PIN en hosts de comerciantes, terminales de punto de venta y cajeros electrónicos (Terminal PIN Key (TPK), Initial PIN Encryption Key (IPEK)) deben ser remplazadas por KBPKs.

¿Cómo se puede comprobar si una clave criptográfica se encuentra en formato key block?

Una de las ventajas de la estandarización proporcionada por los bloques de claves (key blocks) es que se puede identificar por simple observación directa si una clave criptográfica se encuentra en formato key block o no. El primer dígito del encabezado (header) de un key block indica la versión empleada. Existen cuatro identificadores de versiones de key blocks:

• Versión A: Key block protegido usando Key Variant Binding Method
• Versión B: Key block protegido usando TDEA Key Derivation Binding Method
• Versión C: Key block protegido usando TDEA Key Variant Binding Method
• Version D: Key block protegido usando AES Key Derivation Binding Method

Desde la perspectiva de PCI PIN y PCI P2PE, solamente las versiones B (TDEA) y D (AES) son aceptables, ya que emplean derivación en vez de variantes para al diversificación de claves. Una variante es significativamente más débil al ser reversible, mientras que la derivación no lo es. Empleando este criterio, a continuación se muestran dos claves criptográficas TDEA protegidas por key blocks:

A0136V0TN00S0200102CIBMC012400227E000341000000227E0003210000PB047F5787857B413A01A880461CB19203B0F2D9E3E5326133B9D29036D35BEC873C95F22E81

B0144P0TE00S0200102CIBMC012400247700034100000024770003210000PB04C71F199CC5A13FECEAAF94EC3CC4C3025787E709BC8101236F51736F93421D65CABAD5E97A7FD11B

De estas dos claves, solamente la segunda (la que usa el identificador B) es válida para ser empleada en el entorno PCI PIN/PCI P2PE.

Referencias

• PCI Perspectives: Key Blocks 101, Key Blocks 102, Key Blocks 103 y Key Blocks 104
• PCI SSC Information Supplement: Cryptographic Key Blocks (Junio 2017)
• PCI SSC Information Supplement: PIN Security Requirement 18-3 -Key Blocks (Julio 2022)
• PCI SSC PCI Security Standards Council Bulletin: Revisions to the Implementation Dates for PCI P2PE Security Requirement 18-3
• PCI SSC PCI Security Standards Council Bulletin: Revisions to the Implementation Date for PCI PIN Security Requirement 18-3
• Geobridge: Implementing Key Blocks Guide
• SANS: 3DES and Secure PIN-based Electronic Transaction Processing
• Cryptomathic: Introduction to Cryptographic Key Blocks – FAQs https://www.cryptomathic.com/news-events/blog/introduction-to-cryptographic-key-blocks-faqs
• Cryptomathic: An Overview of the Different Key Block Formats https://www.cryptomathic.com/news-events/blog/an-overview-of-the-different-key-block-formats
• Utimaco: A Panorama of the key blocks https://utimaco.com/current-topics/blog/panorama-key-blocks
• ANSI X9.24 Part 1-2009 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques
• ANSI X9.24 Part 2-2006 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for Distribution of Symmetric Keys
• ANSI X9 TR-31, Interoperable Secure Key Exchange Key Block Specification
• ANSI ANSI X9.143-2022 Retail Financial Services Interoperable Secure Key Block Specification
• ISO 20038: Banking and related financial services — Key wrap using AES