KEYBLOCKS en la tercera fase

Entrando en el año 2025, una fecha clave para la industria de pagos por tarjeta ha llegado a su punto crítico: el deadline para la implementación de la Fase III de los Key Blocks según los requisitos de seguridad de PCI PIN. Esta fase, que se caracteriza y se centra en extender la implementación de los Key Blocks a todos los hosts de comerciantes, dispositivos de punto de venta (POS) y cajeros automáticos (ATMs), ha entrado en vigor, marcando un hito significativo para la protección de las claves secretas y la integridad de los datos de pago.

Cada organización que participa en el procesamiento de transacciones con PIN, bien sea un adquiriente, procesador o switch intermedio, está sujeto al cumplimiento del estandar de seguridad PCI PIN, sin olvidar las instalaciones de inyección de claves y operadores de autoridades de certificación y registro. Para los primeros, especialmente, esta tercera fase supone un gran cambio en cuanto a la gestión de las claves que manejan, independientemente (en mayor o menor medida) del esquema de cifrado que se emplee, ya que en general, existirá una rotación de claves periódica o puntual, que se puede abordar mediante técnicas simétricas o asimétricas, escenario que se encuentra bajo el amparo del requisito en cuestión. En este artículo nos centraremos en las técnicas simétricas.
Los dispositivos finales, incluidos tanto los terminales de punto de venta como los cajeros automáticos (PED y EPP), trabajan con claves secretas únicas para cifrar la información que posteriormente transmiten al entorno de descifrado, o a uno de ellos, ya que pueden existir varios saltos hasta su destino final que implican el descifrado y re-cifrado de la información con diferentes conjuntos de claves.

¿Y cuál es el objeto de este control? Sustituir el enfoque “tradicional” por el que se compartían e incluso almacenaban claves simétricas, cifradas mediante una clave de transporte, o clave de cifrado de claves (KEK) por un nuevo enfoque que además de proteger la información, asocie los atributos de la clave que se está protegiendo, o la caracterización de esta, a su empleo, protegiendo además la integridad de esta.

¿Y qué estructura nos permite desplegar esta evolución del enfoque de protección? Los KEY BLOCKS. Hagamos un breve repaso de estas estructuras, ya conocidas por numerosos actores de la industria.

¿Qué es un key block?

Un Key Block es una estructura de datos que provee un mecanismo de “envoltura” para proteger claves simétricas, que se caracteriza 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. Esta estructura es capaz de vincular el propósito de la clave al valor de sí misma, con el objetivo adicional de proteger la integridad de esta. En general, se podría representar como sigue:Un Key Block integra una clave cifrada almacenada junto a sus metadatos de forma criptográficamente segura. En otras palabras, es un enfoque que garantiza que la información del uso de la clave y otros parámetros no pueden ser alterados por un atacante mediante la manipulación de la clave cifrada. 

Aunque ANSI X9.143 es la especificación predefinida para estas estructuras (que sucedió al reporte técnico TR-31), existen otras implementaciones validas en la industria.

Detalle de key block ansi x9.143 vs key block thales

A continuación, se presenta una situación de protección de un clave AES mediante Key Block, ejemplo que parte de una claves AES de 128 bits, que va a ser protegida mediante un Key Block con una KBPK AES de 256 bits. Se aprecian ligeras diferencias entre el formato de ANSI y el formato propietario de Thales.

1. Escenario de formato Key Block en ANSI X9.143 (TR-31)

2. Escenario de formato Key Block en formato propietario de Thales

- Clave simétrica AES 128 a proteger, en texto plano:
  24E86111B7206D79114B756E430046CA
- KBPK AES 256, clave de protección del Key Block, en texto plano:  
  B374A26A71490437AA024E4FADD5B497FDFF1A8EA6FF12F6FB65AF2720B59CCF
- ANSI X9.143 (TR-31) Key Block:
- Thales Key Block:
  10096K0AB00E0002B9B8F83097E48C266B8CE60FF2D0CC419D48A20E1CCAB69B
  4B49ADC173B9D39909B005C1031ADA10

Acorde al SSC, la implementación de ANSI X9.143 no sería el único método para cumplir el requisito aplicable de gestionar las claves secretas mediante este tipo de estructuras, sino que también puede emplearse un método equivalente. Aquellos métodos equivalentes que se empleen deben de incluir la vinculación criptográfica de la información de uso de la clave con el propio valor de la clave mediante métodos aceptados. Cualquier vinculación o desvinculación de la información de uso de la clave debe tener lugar dentro de los límites criptográficos seguros de un dispositivos apropiado, como un HSM, un POI, en EPP.

En este sentido, 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 ellos podemos encontrar las versiones de ATALLA, THALES, IBM, por mencionar alguno de ellos. Como vemos al inicio, incluso el de Thales, que es el más parecido al formato de ANSI, difiere de la estructura original.

Enfoque en POIs (EPP, PED)

Y bien, ¿Cómo se está gestionando este aspecto a nivel de dispositivos finales y qué impacto tiene todo este embrollo de los Key Block? En realidad, una vez se analiza, es sencillo entender la problemática. En función del esquema de cifrado empleado, los dispositivos finales pueden requerir una actualización de claves secretas, que puede asociarse a una planificación establecida, a posibles compromisos de claves o a rotaciones necesarias como sucede en el esquema Master/Session. Incluso un esquema de clave fija puede requerir una actualización de las claves que se inyectan en el terminal mediante un KLD (Key Loader) mediante el empleo de una clave para proteger la clave de trabajo:
Incluso un esquema de derivadas únicas por transacción puede requerir una actualización, en la que puede darse la circunstancia de que se requiera una clave secreta para cargar las claves iniciales en el terminal. Es cierto que el esquema que mayor impacto tiene es el Master/Session, donde todos los dispositivos finales, bien sean un datafono común o el teclado que está incluido en los cajeros automáticos disponen de una clave maestra, TMK, única y diferente para cada dispositivo, que se conoce como clave Maestra del Terminal , y se emplea para rotar las claves de trabajo de estos bajo periodos establecidos (las claves de sesión). Esta clave maestra puede recibir otros nombres, incluso referirse a ella como una KEK, o clave de transporte; pero la denominación TMK es una de las más habituales. 

Hasta ahora, esta clave se ha venido comportando como una clave de transporte clásica, o clave de cifrado de claves, con el objetivo de intercambiar información secreta (claves simétricas) con otros actores superiores, como puede ser el caso de una entidad que necesite rotar las claves bajo un periodo definido, y emplee esta clave de cada terminal para actualizar sus claves de cifrado de datos, que a su vez se generan en un host conectado a uno/varios HSM. 

¿Y cuál es el problema entonces? Que lo que hasta ahora se estaba empleando como una mera clave de transportes, o una clave de cifrado de claves, debe “evolucionar” hacia una KBPK, aplicando tanto a:

▪️ El propio almacenamiento de claves secretas (claves de sesión) en dispositivos locales donde se manipulen estas claves bajo estas estructuras por definición, como es el caso del EPP4.
Nota: Este escenario no aplicaría en dispositivos donde el almacenamiento de las claves de sesión se almacenan en el espacio protegido, almacén de claves de los dispositivos, a no ser que el fabricante en cuestión decida alojar las claves de sesión en dicho almacén de esta manera por defecto

▪️ El propio transporte de claves secretas (de sesión) entre actores. El transporte se debe de realizar mediante estructuras Key Block donde la TMK corresponde a la KBPK, en lugar de emplear la TMK como una claves KEK simple. 

Y vamos al problema añadido, mientras que los fabricantes de dispositivos finales emplean en su mayoría el formato estándar de Key Block de ANSI, el X9.143 (TR-31), los fabricantes de HSMs emplean los formatos propietarios, con lo que la integración y la comunicación eficiente entre extremos no es un caso trivial.

Por lo tanto; procesadores, entidades, comercios con parque de terminales autogestionados, están bajo el impacto de la necesidad de actualizar sus terminales para soportar los Key Block. Aunque todos los terminales a partir de la versión PTS 2.0 deberían de tener soporte para estas estructuras, el migrar el enfoque no es trivial, y puede ser complejo en algunas circunstancias, y supone, o puede suponer tener que reinicializar el terminal de nuevo.

▪️ Puede darse el escenario por el que se disponga de técnicas asimétricas para la distribución de claves secretas, y actualizar las claves de los terminales puede ser, aunque repetitivo, relativamente fácil si se diseña un procedimiento adecuado y maduro, validado en entorno de pruebas, que consista en intercambiar la nueva clave TMK y alojarla como KBPK, y actualizar las claves de trabajo en consecuencia a posteriori.

▪️ En aquellos escenarios en los que no se disponga de técnicas asimétricas para intercambiar claves secretas, y se haya realizado carga de claves por componentes, se necesitará crear nuevas claves por componentes y inyectar esta nueva TMK en dichos dispositivos mediante ceremonias seguras de inyección de claves, con el objetivo de alojar la nueva clave como TMK como KBPK, para, al igual que en el caso anterior, emplear esta como KBPK para intercambiar el resto de claves de trabajo en formato key block.

▪️ Puede existir otras opciones, pero cualquiera de ellas requieren un mínimo de trabajo, esfuerzo, y supone un cambio de mayor o menor envergadura.

¿Y porque no emplear la misma clave que ya existe como KBPK? Bueno, siempre que se pueda dada la no incompatibilidad de algoritmos empleados y su robustez, habrá que realizar una actualización a nivel de dispositivo para registrar la clave con su nuevo formato. Incluso el SSC indica que puede ser una alternativa viable.
Y es cierto que, para organizaciones con mucha población, puede ser útil, dado que las DDBB de niveles superiores contienen las TMK de todos los dispositivos ya registradas, y no sería necesario registrarlas de nuevo… pero…. ¡Sorpresa! Estas claves TMK alojadas en las DDBB que se emplean para la operativa transaccional también deben de estar bajo estructuras key block, no siendo suficiente que se alojen en una tabla cifradas con una clave de cifrado de claves (o una LMK, a no ser que la LMK se haya empleado como KBPK para la protección de estas) Aunque este escenario corresponde a la primera fase de implantación de los Key Block, existe un cambio que atañe a estos criptogramas de las bases de datos derivado de la fase 3. Hasta ahora se habría conformado ese Key block indicando que la clave a proteger contenía una clave de cifrado de claves o wrapping (opción K0) y ahora se debe indicar que contiene una ANSI X9.143 Key Block Protection Key (opción K1); luego este escenario también requeriría una actualización, y llamadas al HMS para actualizar el contenido de las bases de datos.

Volviendo al ámbito de los dispositivos y viendo la política de seguridad de alguno de ellos, se pueden observar indicaciones de implementación de los Key Block. Veamos algunos ejemplos y detalles:

Todos estos detalles, corroboran, en mayor o menor medida, la necesidad de realizar una actualización integral de los dispositivos finales para acomodarse a la nueva estructura de claves, en lo que a material de claves se refiere. No obstante, en última instancia se recomienda interactuar con los fabricantes para evaluar posibles sinergias con las implementaciones actuales, ya que los escenarios pueden variables, y el fabricante podría tener métodos que facilitasen la actualización, o sugerencias.  A la pregunta que nos hacíamos de si podemos usar una clave actualmente definida en un dispositivo como TMK como futura KBPK, es muy probable que, sin acomodar el mismo valor en el espacio reservado para la KBPK en la memoria del terminal, las operaciones fallasen. Es decir, aun cuando pudiéramos usar el mismo valor, debería alojarse este en el espacio indicado por el fabricante dentro del almacén de claves del terminal.

No hay que olvidar otro aspecto a tener en cuenta respecto a la Fase tres de implementación de los Key Block, que atañe al intercambio de claves secretas entre organizaciones que no se consideren asociaciones o las propias Marcas. Estas deben enmarcarse bajo el uso de estas estructuras. Algunos escenarios bastante típicos son el envío de claves entre procesadores o fabricantes con laboratorios de inyección de claves (BDKs – Base Derivation Keys). También es cierto que la mayor parte de las organizaciones han abordado este criterio dentro de la Fase 2.

Conclusiones

1. Detectar en el extremo de descifrado los HSM que soportan las actividades relacionadas, identificar el fabricante, así como el soporte de Key Block y tipo de implementación aplicada (ANSI X9.143 o version propietaria). 
2. Evaluar e inventariar la población de terminales a los que se debe desplegar el enfoque solicitado. El inventario debe de estar disponible siempre y cuando la organización trabaje de manera alineada a PCI PIN. Para cada modelo de terminal, será necesario revisar su version PCI PTS y características asociadas. En este ámbito existirán dos líneas de trabajo
   1. Versiones antiguas de terminales sin soporte a este tipo de estructuras (PCI PTS 1.0). La organización deberá establecer un plan de migración para sustituir el conjunto de dispositivos por unidades que si soporten las estructuras.
   2. Para cada familia de modelos disponibles en la organización, detectar el tipo de Key Block soportado, que será en su mayoría el X9.143. Identificar el espacio reservado en la memoria del terminal para acoger las nuevas claves KBPK que dan soporte a las estructuras. 
3. Identificar, si aplica, bases de datos y tablas asociadas pertenecientes a los host de procesamiento en entornos de descifrado para identificar lugares donde se alojan las claves actuales de transporte que pertenecen a la población de terminales. Si se ha procedido adecuadamente, estas tablas registraran las claves dentro de un Key Block, que probablemente emplee la MFK del HSM como KBPK, aunque podrían emplearse otras claves, o incluso, si la población de terminales es pequeña, estas podrían encontrarse en el propio HSM.
4. Contactar con el fabricante de HSM, con el objetivo de conseguir soporte para, una vez se dispone del abanico de claves que se van a emplear en los terminales como KBPK, poder generar las nuevas claves de trabajo, periódicamente (en esquemas Master/Session principalmente) de manera que se incluyan en estructuras Key Block en formato ANSI X9.143 donde se emplee la KBPK de cada terminal, para proteger estas claves de trabajo, y poder realizar el intercambio de manera segura, alineada a PCI PIN, y de manera que el extremo que va a recibir el criptograma sea capaz de manejar este
5. En el caso de que la organización quiera (y pueda) mantener las claves de transporte actuales como nuevas KBPK de los terminales, identificar el espacio reservado en la memoria de estos para alojar las claves, esta vez como KBPK. Tanto para la reutilización de valores, como para valores nuevos, verificar opciones para la carga inicial, y validar con el fabricante (quien puede facilitar la actividad mediante soporte y mecanismos específicos para la carga)
6. Realizar pruebas en entornos de desarrollo y testing
7. Establecer un plan de migración para actualizar la población total (que puede depender, para cada terminal, de una carga remota en el mejor de los caso, considerando el tiempo como factor clave, o de una inicialización completa/parcial del terminal que requiera una inyección manual de la KBPK, lo que tiene un impacto en el tiempo y gestión de recursos organizativos mucho mayor)

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