Compartir clave única derivada derivada por transacción (DUKPT) Clave de derivación base (BDK) con un socio

Si B desea específicamente que los datos estén encriptados de extremo a extremo del dispositivo de campo a ellos, entonces de hecho, necesita dispositivos inyectados bajo un BDK conocido por B, ya sea que usted haya generado y entregado a B , o B se generó a sí mismo y se lo entregó a usted o a su proveedor (es) / instalación (es) de inyección y, de preferencia, no ha sido utilizado ni compartido con nadie más.

No dice qué tipo (s) de dispositivos y usuarios / configuración le preocupa. He visto (en EE. UU.) Algunos dispositivos de venta minorista / puntos de venta ("banda magnética" y pinpad, a veces EMV) que pueden inyectarse con dos teclas de dispositivo, bajo dos BDK diferentes. Pero los que vi tendían a ser el más alto (por lo tanto, más caros), y todavía tiene el problema de elegir qué clave utilizar para una transacción / elemento de datos dado, lo que generalmente significa algún otro Sistema que está interactuando con los humanos involucrados, como una caja registradora / caja, que se modifica para tomar esta decisión y controlar el dispositivo.

Si a B solo le preocupa que los datos estén encriptados todo el tiempo , por lo que no es vulnerable a los ataques, es posible que estén satisfechos de tratar a su servidor como un único dispositivo (inusualmente ocupado) en su red, es decir, le asignan una clave inicial (y KSN inicial correspondiente) bajo su BDK; usted obtiene cada transacción cifrada por el dispositivo con una clave BDK-A, la descifra y la cifra inmediatamente bajo la clave BDK-B, y la envía hasta B.

Si está utilizando un HSM para su criptografía, y para grandes volúmenes de datos sensibles al pago, debería hacerlo a menudo como una sola operación llamada "traducir" - es decir, en lugar de "descifrar bajo la clave # 3", luego "cifrar bajo la clave # 17", su software puede solicitar "traducir de la clave # 3 a la clave # 17", y entonces el texto plano nunca es visible en su CPU / memory / swap, solo dentro del HSM dedicado y protegido por hardware.

Dependiendo de sus volúmenes de transacciones, esto podría quemar los valores de TCTR algo menos que 2 ^ 21 bastante rápido, por lo que B puede tener que enviarle otra clave de "dispositivo" (o quizás varias) cada mes o semana o lo que sea, usar algún mecanismo que sea seguro y lo más automatizado posible para evitar errores. Definitivamente, debe tratar de tener cada nueva llave lista al menos una semana antes de esperar que la necesite, preferiblemente más, en caso de que los picos de volumen o alguna falla lo obligue a cambiar antes de tiempo. Pero si están ganando dinero con las transacciones que les envías, y presumiblemente no aceptarían tu negocio de otra manera, deberían poder administrar.

DUKPT El Esquema de clave única derivada por transacción (DUKPT) se utiliza en un entorno de punto de venta (POS). Como su nombre lo indica, la clave única derivada por transacción genera una nueva clave para cada transacción. Esta técnica implica el uso de la Clave de Derivación Base (BDK) y el Número de Serie Clave (KSN). En cada transacción, el teclado PIN genera una nueva clave de cifrado que se deriva de un BDK secreto y un KSN no secreto. Encripta el PIN con esta clave, y luego reenvía tanto el PIN encriptado como el número de serie de la clave al adquirente. El beneficio de DUKPT es que si se descubre una de estas claves de cifrado de una sola vez, solo se comprometerá una transacción, ninguna de las otras transacciones desde el mismo dispositivo POS podrá descifrar con esa clave. Tenga en cuenta que se utiliza el método ANSI X9.24-1: 2009 para la derivación de clave de PIN DUKPT.

Clave de derivación base

El host del Adquirente tiene la responsabilidad de mantener la Clave de Derivación Base. En HSM, la clave de cifrado de una sola vez generada por la entrada de PIN se “deriva”, utilizando la Clave de Derivación de Base original y el Número de Serie de la Clave suministrado por la entrada de PIN. En aplicaciones prácticas, el host del adquirente tendría varios BDK, posiblemente para diferentes dispositivos de entrada de PIN. Al procesar transacciones, es importante que el adquirente sepa qué BDK se utilizó para inicializar o inyectar en el dispositivo de entrada de PIN de origen. Para lograr esto, el identificador de Clave de Derivación de Base está incrustado en la cadena del Número de Serie de la Clave.

Para cada transacción, el host del adquirente extraerá del almacenamiento interno la clave de derivación básica cifrada apropiada identificada por el ID de BDK de la cadena KSN. El host del Adquirente debe encontrar una coincidencia dentro de la lista de criptogramas BDK (el perfil BDK se mantiene en el host del Adquirente). Si no se encuentra una coincidencia en la base de datos, la transacción será rechazada. Más información en: enlace

Una forma de mantener la seguridad y el control es proporcionar al procesador B un HSM físico que instalen en su centro de datos, pero que le pertenezca contractualmente. Esto tiene dos grandes ventajas.

1. La seguridad del dispositivo es su decisión, y un HSM garantiza que el procesador no pueda violarlo.
2. Dado que es el propietario del dispositivo, puede cambiar los procesadores de pagos basándose estrictamente en razones comerciales. Si la empresa desea cambiar los procesadores al final de un contrato, simplemente retire su HSM. No es necesario reiniciar costosamente las llaves en sus miles de terminales ya implementadas, y los retrasos a largo plazo que esto generaría.

Esto será costoso, por supuesto, pero más barato que los problemas que podrían crear otras soluciones.