Desgranando un KEYBLOCK ANSI X9.143 y catálogo de KEY BLOCKS Propietarios

Conociendo que un Key Block es una estructura de datos que provee un mecanismo de “envoltura” para proteger claves simétricas, caracterizado por contener, además del propio valor de la clave cifrada, las restricciones de uso de esta y detalles adicionales sobre la propia clave, sus características o atributos, y que además es una estructura capaz de vincular el propósito de la clave a su propio valor, con el objetivo adicional de proteger la integridad de esta, vamos a proceder a analizar un caso concreto. 

Se presenta una situación de protección de una clave AES mediante un Key Block ANSI X9.143, una claves de cifrado de claves AES de 128 bits, que va a ser protegida mediante un Key Block con una KBPK AES de 256 bit.

B374A26A71490437AA024E4FADD5B497FDFF1A8EA6FF12F6FB65AF2720B59CCF
- Datos de Cabecera

Como se puede observar en las capturas que muestran los log de la calculadora criptográfica, hay una serie de elementos que participan en los cálculos (K1, K2, KBEK, KBAK, KM1 y KM2), tanto para obtener el propio Key Block como para realizar el proceso inverso. Dependiendo de la parametrización de las opciones, que va desde la selección de la version de Key Block que emplea variantes o derivadas, selección de algoritmos, y otras implementaciones, los valores de estos elementos pueden variar. Todos ellos son elementos cruciales que trabajan en conjunto para la protección de los elementos que se protegen dentro de la estructura.  Cada uno tiene un rol específico en la lógica de cifrado y descifrado pertinente, y forma parte del cálculo de todo el bloque, además del proceso inverso para obtener la clave original que se pretendía proteger al inicio.

Detalles sobre la derivación de las claves KBEK Y KBAK

Una vez se dispone de la KBPK, o clave de protección del Key Block, la clave de cifrado del Key Block (KBEK) y la clave de autenticación de este (KBAK) se derivan de esta, que es a quien le corresponde la posición más alta en la jerarquía. Se deriva la KBPK alineando los criterios a NIST SP 800-108, donde se manifiestan recomendaciones para la derivación de claves mediante funciones pseudoaleatorias. Siguiendo los criterios, la especificación emplea CMAC para el cálculo. Para este caso en el que disponemos de una clave AES de 256 bits, se usa CMAC con AES como Block Cipher.

El algoritmo CMAC en su forma general también depende de la elección del tamaño del MAC producido. Dado que el MAC se utiliza como el vector de inicialización (IV) para cifrar/descifrar la clave, la longitud del MAC añadido debe ser igual a la longitud del Block Cipher. Siendo así, b, en el cuadro siguiente, correspondería al tamaño de bloque de la estructura de cifrado subyacente (block Cipher).

Por lo tanto, en el ejemplo que nos compete, la función pseudoaleatoria produce valores MAC de 16 bytes.

Esta tabla a continuación pretende mostrar los datos de entrada a la función CMAC, que se ejecuta una vez por cada 16 bytes de material de clave necesarios (en nuestro caso tenemos una clave de 32 bytes). El valor del contador en los Nibble (colección de 4 bits, representado aquí por un hexadecimal) 0-1 se pone a 1 cuando se derivan los primeros 16 bytes de la clave de cifrado, y se vuelve a poner a 1 cuando se derivan los primeros 16 bytes de la clave de autenticación.

El contador se incrementa en cada llamada a CMAC como parte de la derivación de una clave de cifrado o autenticación a partir de una KBPK. El contador comienza en 0x01. El indicador de uso de clave indica si la clave generada es una clave de cifrado o de autenticación. El Separador es un campo obligatorio de un byte que siempre es 0x00. La Longitud indica cuántos bits de material de claves deben derivarse para las claves de cifrado y autenticación.

Ahora bien, en este proceso se aprecia a grandes rasgos cómo se obtienen las claves de cifrado y de autenticación; mediante derivación empleando CMAC con AES, pero ¿A qué corresponden los valores K1, K2, KM1, y KM2? La realidad es que existe un primer paso en el proceso anterior que corresponde a derivación de subclaves CMAC. En concreto, para obtener la KBEK, se derivarían dos subclaves, K1 y K2, cada una del tamaño del Block Cipher subyacente (16 byte). Estas son las claves que se emplearían para hacer un XOR con los datos de derivación mostrados en los diagramas superiores previo al CMAC, y se podría emplear K1 o K2 para realizar el calculo siguiendo las parametrizaciones de CMAC. Para AES, el escenario en concreto pasa por incluir un padding de 0x8000000000000000 a los datos de derivación y emplear solo K2 (existen otros escenarios en los que se emplea K1). En el ejemplo que hemos seguido, para la obtención de la KBEK, el proceso iría en esta línea, de manera muy resumida, para que se pueda entender:

En cuanto a KM1 y KM2, estas serían subclaves que se emplearían para el calculo del MAC, partiendo de la KBAK. El MAC se calcula aplicando CMAC a todo el payload, es decir, a la cabecera concatenada con los datos de la clave, utilizando como clave la clave KBAK. De nuevo, el primer paso en el cálculo de CMAC es obtener mediante derivación la subclave KM1 a partir de la KBAK; y como los datos MAC no requieren relleno, o padding, KM2 no sería necesario.

Cálculo del KEY BLOCK

Ahora, conociendo todos los elementos que se presentan para la obtención del Key Block, ¿Cuáles son los pasos para obtener dicho criptograma? Veámoslo con nuestro ejemplo donde:

-    Clave simétrica AES 128 a proteger, en texto plano: 24E86111B7206D79114B756E430046CA
-    KBPK AES 256, en texto plano: B374A26A71490437AA024E4FADD5B497FDFF1A8EA6FF12F6FB65AF2720B59CCF

1. Se construye la cabecera. Se emplean para ello caracteres en ASCII en claro.
   

   Nombre de Campo	Contenido en ASCII	Comentario
   Key Block Version ID	D	AES Key Derivation Binding Method
   Key Block Length	0112	112 caracteres -    16 cabecera -    64 clave cifrada -    32 MAC
   Key Usage	K0	Cifrado de claves o Wrapping
   Algorithm	A	AES
   Mode of Use	B	Cifrado o descifrado (Wrap/Unwrap)
   Key Version Number	00	Version (en otros casos puede indicar que de trata de un componente)
   Exportability	E	Exportable bajo una clave de confianza
   Number of Optional Blocks	00	Sin bloques opcionales en la cabecera
   Reserved	00	Reservado, siempre 00

   
   El resultado de la cabecera, en ASCII, es, por lo tanto:  D0112K0AB00E0000
   
   
2. Se procede a construir los “datos binarios de la clave”, los cuales incluyen la propia clave e información relacionada con esta. Los datos a cifrar consisten en la concatenación de la Longitud de la Clave (2 bytes), la clave que se está cifrando, y el padding, todo representado en forma binaria.
   • Longitud (2 bytes): 0080 (128 bits)
   • Clave (16 bytes):  24E86111B7206D79114B756E430046CA
   • Relleno (padding, 14 bytes de datos random): 7BE7518F3EB05A66E190107C868E
   El resultado del dato binario de la clave corresponde a (32 byte, 64 caracteres de la longitud del Key Block):  
   0080 24E86111B7206D79114B756E430046CA 7BE7518F3EB05A66E190107C868E 
   
   
3. Se obtiene mediante derivación, la KBEK y la KBAK a partir de la KBPK. Para ello se deriva la KBPK tal y como se ha comentado en la sección superior, a grandes rasgos. Aquí aparecerían las K1 y K2 para ambas KBEK y KBAK, de las que solamente se emplearía la K2 para el calculo debido al tipo de algoritmo empleado.
   • KBEK AES 256: 5938DE6AA11BBB441DC0E4B13B7E21F7CE1AF6CC60B5B8AB0406B431E418FC2F
   • KBAK AES 256: 3F98E106A1AB42B23433669F7B37ED8FE646134E325AD58675B87ADC86DA854A
4. Se calcular un MAC sobre la cabecera y los datos binarios de la clave, empleando CMAC con la clave de autenticación, KBAK. El dato MAC se calcula aplicando CMAC a toda la carga útil, a todo el payload, es decir, a la cabecera concatenada con los datos binarios de la clave, utilizando como clave la clave de autenticación del Key Block, la KBAK, de lo que se obtiene el MAC. Tal y como se ha comentado en la sección superior, para ello será necesario derivar una subclave KM1 que se va a emplear junto a la KBAK para calcular el MAC.
   • Block MAC: CA600A3E0E575D70 ABAA483C7ABCC944
5. Se calculan los datos cifrados mediante CBC-AES cifrando los “datos binarios de la clave” (punto 2) utilizando el MAC como vector de inicialización (IV). Es decir, los datos binarios de la clave se cifran con el algoritmo asignado, empleando la clave de cifrado KBEK y la MAC calculada en como vector de inicialización (IV).
   Nota: Este es el motivo por el que se asume que las estructuras de los Key Block son capaces de encadenar, asociar y relacionar la clave que protegen con el propio uso (atributos) de esta, ya que el vector de inicialización del algoritmo que cifra el contenido corresponde al MAC calculado tanto a partir de la cabecera con los atributos de la clave como del contenido de esta.

1. compone el Key Block resultado de la concatenación de la cabecera en claro, los datos que corresponden a la clave cifrada (criptograma cifrado de los datos binarios de la clave) y el MAC, dando lugar a los 112 caracteres mencionados en la sección de la cabecera.
   
   D0112K0AB00E0000E780D85FB94306656B62DB3AD51B7797D6FC830719ED4DE6A1D22
   CBFADE78A32CA600A3E0E575D70ABAA483C7ABCC944

Validación del Proceso

Podríamos descifrar el criptograma del Key Block de la sección anterior, la parte que corresponde a los datos de la clave, mediante la KBEK y el vector de inicialización (MAC) en una operación estándar de descifrado AES-CBC, mediante la herramienta de cálculo criptográfico, para validar que llegamos a la clave original:


Obteniendo la clave original dentro del Payload, quitando los bytes que corresponden a la longitud de la clave y los empleados para el relleno

Variantes y derivadas

Por otra parte, es interesante mencionar que se puede comprobar que muchas de las políticas de seguridad de algunos dispositivos POI ya indican que estos implementan solo versiones seguras de los Key Block de ANSI X9.143. Esta parametrización se hace tangible y efectiva dentro de la declaración de las propias cabeceras de los Key Block, donde se especifica la version de Key Block implementada, que corresponde a una de las siguientes opciones:

Y aun es más interesante “enlazar” los criterios establecidos en las políticas de los dispositivos con los requisitos del estándar PCI PIN. El requisito 23 de dicho estándar pone trabas al empleo de variantes de clave, que serían aquellas claves resultado de aplicar transformaciones simples a la clave original, como puede ser aplicar una máscara de bits a la clave original, un XOR con una secuencia concreta, un reordenando…. Son modificaciones simples que no proporcionan tanta seguridad como los procesos de derivación. El problema de esto es que ante una posible revelación de la clave resultado (la variante), la integridad de la clave original se pone en entredicho. El estándar PCI PIN, y por extensión P2PE, que se sostiene en prácticamente los mismos criterios de gestión de claves; intentan limitar su uso. ¿Qué es lo que nos dicen? Básicamente, que, si pretendemos emplear una variante de clave en nuestro entorno, extrememos las precauciones, mediante:

▪️ El empleo de estas solamente en los SCD (HSMs, POIs...) que posean la clave original de la que se transforma. Es decir, olvidémonos, por ejemplo, de generar una clave mediante una transformación simple de una LMK (o MKF, por ser una denominación más genérica) en un HSM y emplearla como TMK de un dispositivo concreto, por ejemplo, de un EPP asociado a un cajero automático. El 23-2 precisamente nos prohíbe el empleo de este tipo de claves generadas a partir de una MFK para la distribución de otras claves entre sistemas. 

▪️ No se podrían emplear a diferentes niveles en una jerarquía de claves. Por ejemplo, una variante de una clave de transporte no podría ser empleada como una clave de trabajo, para cifrar datos.

Por lo que en ecosistemas formados por uno o varios centros más un parque de dispositivos, donde es necesario generar claves y exportarlas entre SCDs, solamente emplearemos las opciones ‘B’ y ‘D’; que en Key Blocks en formato ANSI X9.143 son fácilmente identificables por su primer carácter, como podemos apreciar en la tabla de ejemplo, más arriba.

Adicionalmente, es interesante matizar, siguiendo esta línea de las versiones del Key Block, que, el propio ANSI indica que la version A está obsoleta y no debe utilizarse en aplicaciones nuevas. Otra apreciación interesante es conocer que los identificadores numéricos de versión, en la cabecera se reservan para definiciones de bloque propietarias (como, por ejemplo, el Key Block de Thales, que aplica la version ID “0” y “1”, en función de si se trata de un key block TDES o AES, respectivamente). 

Formatos KEY BLOCK Propietarios

Por último, cabria mencionar que, aunque existen formatos propietarios de key block de fabricantes, los principios para conformar la estructura final serian similares a como se describe en este artículo, considerando variaciones en los algoritmos, longitudes, etc. Cada fabricante, o gran parte de ellos, disponen de su propia interpretación de los Key Block, ajustándose a los principios básicos que definen a estas estructuras. Entre todos ellos podemos encontrar los siguientes:

▪️ (Ultimaco) Atalla Key Block es un formato de Key Block de un fabricante de HSMs, aprobado por la comunidad de estándares ANSI para admitir el intercambio de claves simétricas de manera segura y con atributos de clave incluidos en los datos intercambiados. Podría decirse que es el más antiguo y origen del resto de los formatos Key Block, incluyendo el formato ANSI actual que se generó para disponer de un formato común y homogéneo.
El formato de Atalla Key Block se compone de:
    ▪️ Cabecera de 8 bytes que contiene los atributos de la clave
    ▪️ Campo de clave de 48 bytes que contiene el texto cifrado que contiene la clave mediante
       Triple-DES modo CBC
    ▪️ Campo de 16 bytes que contiene el código de autenticación de mensaje (MAC) calculado
       sobre el encabezamiento y el campo de clave cifrada

▪️ IBM creó un formato de Key Block, el IBM (CCA) Key Block con el objetivo de ser usado dentro de su Arquitectura Criptográfica Común (CCA), base de una familia de productos de cifrado desarrollados por IBM. Las aplicaciones emplean la API de seguridad CCA para obtener servicios de un sistema criptográfico que cumpla las especificaciones de la CCA y para gestionar su funcionamiento.

En el formato CCA, un “token de clave” se define como una estructura de datos que contiene información sobre una clave. Contiene una o varias claves. Es el equivalente de una estructura de datos ANSI X9.143 (TR-31). En CCA, el vector de control es una estructura de datos pública que detalla el uso permitido para una clave asociada.

Cuando se quiere cifrar una clave CCA, la KEK se combina con el vector de control mediante una operación XOR exclusiva para formar la clave real utilizada en el proceso de cifrado. El esquema de tipificación de claves del vector de control, junto a la autorización de comandos y la comprobación del vector de control realizadas por un nodo CCA proporcionan en conjunto una importante defensa contra el uso indebido de claves y ataques relacionados, equiparable al mecanismo del esquema ANSI X9.143 (TR-31). Los tokens de claves CCA pueden utilizarse para gestionar claves DES o RSA. Su funcionamiento es mucho más complejo que un simple agrupamiento de claves (key bundle). Se utilizan en muchos dispositivos criptográficos, como el procesador criptográfico (∼HSM) IBM 4758, y operan y están presentes en el procesamiento de transacciones financieras en muchas entidades de renombre.

Este formato de clave contiene de 3 a 5 bloques: 

▪️ Vector de control (público, equivalente a cabecera) de 16 byte fijos (más extensión variable)
▪️ Clave cifrada con la clave maestra de la CCA o la KEK de la CCA / clave de transporte
▪️ Valor de validación utilizado para garantizar la integridad 
▪️ [Opcional] Patrón de verificación de la clave maestra
▪️ [Opcional] Módulo y exponente RSA, si el token encapsula una clave RSA

▪️ Los Key Blocks de Thales, considerados como un formato propietario de Thales, que cumplen con la norma ANSI X9.24; y sustituye a la norma ANSI X9.143 (TR-31) de manera muy similar. Implementan el último y lo amplían aún más, proporcionando funciones adicionales.

La estructura de los bloques de Thales define cuatro bloques en lugar de los tres bloques definidos por ANSI X9.143:

▪️ Cabecera (16 bytes)
▪️ Cabecera opcional
▪️ Datos de clave cifrados
▪️ Autenticador

La principal diferencia es la adición de un bloque de cabecera opcional que permite una mayor flexibilidad en la gestión de claves. La cabecera contiene un campo que registra el valor de la clave maestra local (LMK) del HSM de Thales utilizada para el cifrado. Por lo tanto, en teoría, sólo se pueden utilizar bloques de claves Thales con máquinas Thales. La cabecera contiene un campo que informa si hay cabeceras opcionales, y en caso afirmativo, cuántas hay. 

Los bloques de Thales dan soporte a dos tipos de cifrado de claves: Triple DES y AES Keyblock LMK (cifrado por la LMK). En ambos casos, se utiliza un Vector de Inicialización tomando bytes de la cabecera que, como resultado, vincula directamente la cabecera y los datos de la clave cifrados. A diferencia de los Key Block de Atalla, que utiliza los ocho bytes de sus campos de cabecera, Thales utiliza sólo una parte de su campo de cabecera para el cálculo del vector de inicialización. Las claves de cifrado se derivan del LMK del HSM (AES o Triple DES). La sección empleada para verificar la integridad calcula a través de un CBC-MAC 3DES o un CMAC AES a partir de la concatenación de los datos cifrados, la cabecera y la cabecera opcional.  

Referencias
🔗 https://www.pcisecuritystandards.org/about_us/
🔗 https://www.pcisecuritystandards.org/document_library/
🔗 https://www.ibm.com/docs/en/zos/3.1.0?topic=cryptography-ansi-x9143-tr-31-key-block-support
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Supporting%20Document/PIN_Security_Rqmt_18-3_Key_Blocks_2022_v1.1.pdf
🔗 https://utimaco.com/news/blog-posts/panorama-key-blocks
🔗 https://www.ibm.com/docs/en/linux-on-systems?topic=formats-tr-31-key-header-optional-data
🔗 https://blog.pcisecuritystandards.org/just-updated-key-blocks-information-supplement
🔗 https://www.pcisecuritystandards.org/wp-content/uploads/2020/07/Key-Block-Implementation-Revision-Bulletin-FINAL.pdf
🔗 https://docs-prv.pcisecuritystandards.org/PIN/Frequently%20Asked%20Questions%20(FAQ)/PCI_PIN_Technical_FAQs_v3_December_2024.pdf