En criptografía , la clave única derivada por transacción ( DUKPT ) es un esquema de gestión de claves en el que para cada transacción se utiliza una clave única derivada de una clave fija. Por lo tanto, si una clave derivada se ve comprometida, los datos de transacciones pasadas y futuras siguen estando protegidos, ya que las claves siguientes o anteriores no se pueden determinar fácilmente.
La versión actual (a mayo de 2024) del estándar (ANSI X9.24-3-2017 [1] ) se publicó en 2017. [2] Se basa en el algoritmo de cifrado AES y se recomienda para nuevas implementaciones.
Este artículo trata sobre la variante original de DUKPT que se basa en el algoritmo de cifrado TDEA y se describe en el Apéndice C de ANSI X9.24-3-2017.
DUKPT permite que el procesamiento del cifrado se realice más allá de los dispositivos que contienen el secreto compartido. El cifrado se realiza con una clave derivada , que no se reutiliza después de la transacción. DUKPT se utiliza para cifrar transacciones de comercio electrónico. Si bien se puede utilizar para proteger la información entre dos empresas o bancos, normalmente se utiliza para cifrar la información del PIN adquirida por los dispositivos de punto de venta (POS).
DUKPT no es en sí un estándar de cifrado, sino más bien una técnica de gestión de claves. Las características del sistema DUKPT son:
DUKPT fue inventado a fines de la década de 1980 en Visa, pero no recibió mucha aceptación hasta la década de 1990, cuando las prácticas de la industria cambiaron hacia recomendar, y luego exigir, que cada dispositivo tenga una clave de cifrado distinta.
Antes de DUKPT, el estado de la técnica se conocía como Master/Session , que requería que cada dispositivo de cifrado de PIN se inicializara con una clave maestra única. Al gestionar transacciones originadas en dispositivos que utilizan la gestión de claves Master/Session, un efecto secundario no deseado era la necesidad de una tabla de claves de cifrado tan numerosas como los dispositivos implementados. En un adquirente comercial importante, la tabla podía llegar a ser bastante grande. DUKPT resolvió este problema. En DUKPT, cada dispositivo todavía se inicializa con una clave distinta, pero todas las claves de inicialización de una familia completa de dispositivos se derivan de una clave única, la clave de derivación de base (BDK). Para descifrar mensajes cifrados de dispositivos en el campo, el destinatario solo necesita almacenar la BDK.
Como se indicó anteriormente, el algoritmo necesita una clave única inicial que en la descripción original del algoritmo se denominaba clave supersecreta , pero que luego se renombró como Clave de derivación base (o BDK, por sus siglas en inglés), de una manera más oficial . El nombre original quizás transmita mejor la verdadera naturaleza de esta clave, porque si se ve comprometida, todos los dispositivos y todas las transacciones se verán igualmente comprometidos.
Esto se ve mitigado por el hecho de que sólo hay dos partes que conocen el BDK:
El BDK se almacena normalmente dentro de un módulo de seguridad resistente a manipulaciones (TRSM) o un módulo de seguridad de hardware (HSM). Debe quedar claro que esta clave no es la que se utiliza para inicializar el dispositivo de cifrado que participará en las operaciones DUKPT. Vea a continuación el proceso real de generación de la clave de cifrado.
Al detectar un compromiso, el propio dispositivo deriva una nueva clave a través del proceso de generación de clave derivada.
En el extremo de origen (cifrado), el sistema funciona de la siguiente manera:
En el extremo receptor (descifrador), el sistema funciona de la siguiente manera:
El método para llegar a las claves de sesión es algo diferente en el lado de origen que en el lado de recepción. En el lado de origen, se conserva una cantidad considerable de información de estado entre transacciones, incluido un contador de transacciones, un número de serie y una matriz de hasta 21 "claves futuras". En el lado de recepción, no se conserva ninguna información de estado; solo la BDK es persistente en todas las operaciones de procesamiento. Esta disposición proporciona comodidad al receptor (se puede dar servicio a una gran cantidad de dispositivos mientras se almacena solo una clave). También proporciona cierta seguridad adicional con respecto al originador (los dispositivos de captura de PIN a menudo se implementan en entornos reacios a la seguridad; los parámetros de seguridad en los dispositivos están "distantes" de la BDK sensible y, si el dispositivo se ve comprometido, otros dispositivos no se ven comprometidos implícitamente).
Las siguientes áreas de almacenamiento relacionadas con la administración de claves se mantienen desde el momento del comando "Cargar clave inicial" durante la vida útil del dispositivo de ingreso de PIN:
Contador de la cantidad de cifrados de PIN que se han producido desde que se inicializó por primera vez el dispositivo de entrada de PIN. Se omiten determinados valores del contador (como se explica a continuación), de modo que son posibles más de 1 millón de operaciones de cifrado de PIN. Nota: La concatenación (de izquierda a derecha) del registro de número de serie de clave inicial y el contador de cifrado forman el registro de número de serie de clave de 80 bits (20 dígitos hexadecimales).
Un conjunto de 21 registros, numerados del 1 al 21, que se utilizan para almacenar claves de cifrado PIN futuras. Cada registro incluye una comprobación de redundancia longitudinal (LRC) de 2 dígitos hexadecimales o una comprobación de redundancia cíclica (CRC) de 2 dígitos hexadecimales.
Las siguientes áreas de almacenamiento relacionadas con la gestión de claves se requieren de forma temporal y pueden ser utilizadas para otros fines por otras rutinas de procesamiento de PIN:
Contiene la dirección del registro de clave futura cuyo contenido se está utilizando en la operación criptográfica actual. Identifica el contenido de ese registro de clave futura cuya dirección está contenida en el puntero de clave actual.
Un registro de 21 bits, cuyos bits están numerados de izquierda a derecha del 1 al 21. Este registro normalmente contiene 20 bits "cero" y un solo bit "uno". Uno de los usos de este registro es seleccionar uno de los registros de clave futura. El registro de clave futura que se seleccionará es el que tiene el mismo número que el bit del registro de desplazamiento que contiene el único "uno".
Un registro utilizado para realizar operaciones criptográficas.
Un segundo registro utilizado para realizar operaciones criptográficas.
Un registro utilizado para almacenar una clave criptográfica.
En aplicaciones prácticas, uno podría tener varios BDK registrados, posiblemente para diferentes clientes, o para contener el alcance de la vulneración de claves. Al procesar transacciones, es importante que el receptor sepa qué BDK se utilizó para inicializar el dispositivo de origen. Para lograr esto, el KSN de 80 bits se estructura en tres partes: un ID de conjunto de claves, un ID de TRSM y el contador de transacciones. El algoritmo especifica que el contador de transacciones es de 21 bits, pero trata los 59 bits restantes de forma opaca (el algoritmo solo especifica que los bits no utilizados se rellenen con 0 hasta un límite de nibble y luego se rellenen con 'f' hasta el límite de 80 bits). Debido a esto, la entidad que administra la creación de los dispositivos DUKPT (normalmente un adquirente comercial) es libre de subdividir los 59 bits según sus preferencias.
La práctica de la industria es designar la partición como una serie de tres dígitos, que indican la cantidad de dígitos hexadecimales utilizados en cada parte: el ID del conjunto de claves, el ID de TRSM y el contador de transacciones. Una opción común es "6-5-5", lo que significa que los primeros 6 dígitos hexadecimales del KSN indican el ID del conjunto de claves (es decir, qué BDK se utilizará), los siguientes 5 son el ID de TRSM (es decir, un número de serie del dispositivo dentro del rango que se inicializa a través de un BDK común) y los últimos 5 son el contador de transacciones.
Este esquema de notación no es estrictamente preciso, porque el contador de transacciones tiene 21 bits, que no es un múltiplo par de 4 (la cantidad de bits en un dígito hexadecimal). En consecuencia, el contador de transacciones en realidad consume un bit del campo que es el ID de TRSM (en este ejemplo, eso significa que el campo ID de TRSM puede albergar 2 (5*4-1) dispositivos, en lugar de 2 (5*4) , o aproximadamente medio millón).
Además, es una práctica común en la industria utilizar solo 64 bits del KSN (probablemente por razones relacionadas con los sistemas heredados y el cifrado DES), lo que implicaría que el KSN completo se rellena a la izquierda con cuatro dígitos hexadecimales "f". Los 4 dígitos hexadecimales restantes (16 bits) están disponibles, no obstante, para los sistemas que pueden aceptarlos.
El esquema 6-5-5 mencionado anteriormente permitiría alrededor de 16 millones de BDK, 500.000 dispositivos por BDK y 1 millón de transacciones por dispositivo.