2012-07-31 86 views
11

Como dice el título, intento descifrar los datos de seguimiento cifrados de DUKPT procedentes de un escáner habilitado con DUKPT.Descifrado Datos de seguimiento cifrados DUKPT

Tengo el estándar ANSI (X9.24) para DUKPT y he implementado con éxito la capacidad de generar el IPEK de KSN y BDK. Además, he implementado con éxito la capacidad de generar las teclas de solicitud y respuesta MAC izquierda y derecha mediante XORing las claves de cifrado PIN. Por último, puedo generar el EPB.

A partir de aquí, no entiendo cómo generar la solicitud y respuesta MAC desde las teclas I/D que he generado.

Por último, una vez que llego a ese paso, ¿qué viene después? ¿Cuándo tengo la clave que descifra los datos de la pista enviados por un dispositivo habilitado para DUKPT?

Conozco el Simulador de Thales y jPOS. Mi código actualmente hace referencia al Simulador de Thales para hacer todo su trabajo. Pero, el proceso de descifrado de archivos simplemente no devuelve los datos esperados.

Si alguien puede ofrecer alguna información sobre el descifrado de datos de seguimiento, sería muy apreciado.

http://thalessim.codeplex.com/

http://jpos.org/

Respuesta

34

que pasaba demasiado tiempo al estudio de la especificación X9.24 horrible y finalmente consiguió tanto el cifrado y descifrado de trabajo con ejemplos y comercialización de mi vendedor rápidamente decidido cambiar de proveedor. Como es un estándar, uno pensaría que la implementación de cualquiera sería la misma. Deseo. De todos modos, hay variaciones sobre cómo se implementan las cosas. Tienes que estudiar la letra pequeña para asegurarte de que estás trabajando las cosas de la otra manera.

Pero esa no es su pregunta.

Primero, si necesita descifrar una pista de datos de una tarjeta de crédito, probablemente esté interesado en producir una clave que descifre los datos en base a la Clave de derivación de base súper secreta original. Eso no tiene nada que ver con la generación MAC y solo se menciona al pasar en esa especificación espantosa. Necesita generar el IPEK para ese número de serie de clave e ID de dispositivo y aplicar repetidamente el "Proceso de generación de clave no reversible" de la especificación si los bits se establecen en la parte contraria del número de serie de clave completa del HSM.

Esa parte de mi código es el siguiente: (Lo siento por la larga lista en un mensaje.)

/* 
* Bit "zero" set (this is a 21 bit register)(ANSI counts from the left) 
* This will be used to test each bit of the encryption counter 
* to decide when to find another key. 
*/ 
testBit=0x00100000; 
/* 
* We have to "encrypt" the IPEK repeatedly to find the current key 
* (See Section A.3). Each time we encrypt (generate a new key), 
* we need to use the all prior bits to the left of the current bit. 
* The Spec says we will have a maximum of ten bits set at any time 
* so we should not have to generate more than ten keys to find the 
* current encryption key. 
*/ 
cumBits=0; 
/* 
* For each of the 21 possible key bits, 
* if it is set, we need to OR that bit into the cumulative bit 
* variable and set that as the KSN count and "encrypt" again. 
* The encryption we are using the goofy ANSI Key Generation 
* subroutine from page 50. 
*/ 
for(int ii=0; ii<21; ii++) 
{ 
    if((keyNumber&testBit) != 0) 
    { 
     char ksr[10]; 
     char eightByte[8]={0}; 

     cumBits |= testBit; 
     ksn.count=cumBits; /* all bits processed to date */ 

     memcpy(ksr, &ksn,10);  /* copy bit structure to char array*/ 
     memcpy(crypt,&ksr[2],8); /* copy bytes 2 through 9 */ 

     /* 
     * Generate the new Key overwriting the old. 
     * This will apply the "Non-reversible Key Generation Process" 
     * to the lower 64 bits of the KSN. 
     */ 
     keyGen(&key, &crypt, &key); 
    } 
    testBit>>=1; 
} 

Dónde keyNumber es la contracorriente desde el ksn ksn es una estructura de 80 bits que contiene el número de serie de clave de 80 bits de HSM crypt es un bloque de datos de 64 bits Lo tengo de tipo DES_cblock ya que estoy usando openSSL. La clave es una estructura DES_cblock doble de 128 bits. La rutina keyGen es casi textual de la subrutina local "Proceso de generación de clave no reversible" en la página 50 de la especificación.

Al final de esto, la variable clave contendrá la clave que se puede usar para el descifrado, casi. Los tipos que escribieron la especificación agregaron un comportamiento "variante" a la tecla para mantenernos alerta. Si la clave se va a utilizar para descifrar una secuencia de datos, como una pista de tarjeta de crédito, necesitará XOR bytes 5 y 13 con 0xFF y Triple DES cifrará la clave consigo misma (modo ECB).Mi código es el siguiente:

DOUBLE_KEY keyCopy; 
char *p; 
p=(char*)&key; 
p[ 5]^=0xff; 
p[13]^=0xff; 
keyCopy=key; 
des3(&keyCopy, (DES_cblock *)&key.left, &key.left); 
des3(&keyCopy, (DES_cblock *)&key.right, &key.right); 

Si está usando este para descifrar un bloque PIN, tendrá que XOR bytes 7 y 15 con 0xFF. (No estoy seguro al 100% de que esto no se aplique también para el modo de transmisión, pero mi proveedor lo está dejando de lado.)

Si es un bloque PIN, se cifrará con 3-DES en modo ECB. Si se trata de una secuencia de datos, se cifrará en modo CBC con un vector de inicialización cero.

(¿Mencioné que no me importa mucho la especificación?) Es interesante observar que el lado de encriptación podría usarse en un módulo de seguridad no resistente al hardware, si el lado del servidor (arriba) recuerda y rechaza las claves que se han utilizado previamente. La tecnología es bastante ordenada. La especificación de ANSI deja algo que desear, pero la tecnología está bien.

Buena suerte. /Bob Bryan

+1

Eso es algo de información fantástica. Gracias por tomarse el tiempo para responder con tanto detalle. Definitivamente voy a seguir adelante con su trabajo provisto. – bdeetz

+1

Desearía darle mil votos. El mejor recurso en internet. – Jonathan

Cuestiones relacionadas