Comprensión de los números de serie clave (KSN) en clave única derivada por transacción (DUKPT)

Question

Comprensión de los números de serie clave (KSN) en clave única derivada por transacción (DUKPT)

Navega tus respuestas

#1 de dave_thompson_085 (4 votos)

2

Tengo varias preguntas con respecto a los números de serie clave (KSN) en DUKPT :

Los KSN tienen una longitud de 8 a 10 bytes. Las implementaciones más antiguas tienen 8 bytes, mientras que las más nuevas tienen 10 bytes. ¿Me arriesgo a ser incompatible con algún sistema antiguo si creo KSN de 10 bytes?
Los KSN tienen 3 componentes: un contador de transacciones de 21 bits y los bits restantes son para la identificación del conjunto de claves y la identificación del Módulo de seguridad resistente a la manipulación (TRSM). Para un KSN de 8 bytes, la convención típica es de 24 bits para la ID de conjunto de claves y 19 bits para la ID de TRSM. Esto significa alrededor de 16M Claves de derivación base (BDK) y dispositivos de 500K. Para mí esta asignación tiene sus pros y sus contras. Las desventajas son que nunca tendré 16M BDK y si el negocio tiene éxito, es muy posible tener > 500K dispositivos. La ventaja es que nos obliga a no utilizar el mismo BDK en más de 500K dispositivos, lo que limita la exposición de un BDK comprometido. Leí que hay flexibilidad en la cantidad de bits que se asignan a la ID del conjunto de claves frente a la ID de TRSM. Así que estoy tentado a intercambiar la asignación de modo que podamos tener hasta 500K BDK y 16M dispositivos. Pero también veo muchas implementaciones de código abierto de DUKPT que suponen una división de 24-19-21 bits. Esas implementaciones se romperían si no cumpliera con la convención. ¿Recomendaría que me limite a cumplir con lo convencional?
¿Existe alguna forma estándar para establecer los ID de conjunto de claves o cada entidad que posee un BDK tiene su propia convención? ¿Puedo asignar ID de conjunto de claves = 1 a mi primer BDK y luego incrementarlo en 1 para cada nuevo BDK? ¿O es esa estrategia demasiado ingenua?
¿Hay alguna forma estándar de configurar la ID de TRSM? ¿Puedo asignar TRSM ID = 1 para el primer dispositivo inyectado con un nuevo BDK y luego incrementarlo en 1 por cada nuevo BDK?

cryptography encryption des

pregunta Fayez 01.07.2015 - 06:59

fuente

1 respuesta

Lea otras preguntas en las etiquetas cryptography encryption des

¿Se pueden vincular los certificados de cliente a un certificado de servidor específico? ¿Este token CSRF generado se consideraría criptográficamente sólido?

score 4 · Accepted Answer

8/10 bytes . El estándar siempre ha tenido KSN 10 bytes (80 bits), pero permitió valores más pequeños rellenados a la izquierda con 0xFF, y muchas personas hicieron o usan 8 bytes. No estoy en posición de decir que hay un patrón claro de cualquier manera. Si alguno de los dispositivos (o sistemas) con los que espera tratar están limitados a 8 bytes, entonces sí, use 8 bytes. Como se muestra a continuación, es básicamente arbitrario ahora de todos modos.
Tienes razón, casi todo el mundo parece utilizar xx-19-21 bits , que para 8 bytes es de 24-19-21 bits. Recuerda que DUKPT era originalmente diseñado para cajeros automáticos que cuestan muchos miles de dólares, por lo que 512K no era un límite problemático; ahora la gente lo usa para cajas de cerillas. Técnicamente, solo la parte del contador (xx-21) es importante para el cifrado. para que pueda cambiar los otros límites (ies?) si sus programas, API, socios, etc. pueden manejarlo. OTOH si se adhiere a la convención, lo que es más fácil, nada dice que los diferentes KSI deben asignarse siempre a diferentes BDK. Puede tener [FFFF]ABAB00-mmmmm son los primeros dispositivos 512K para BDK A , ABAB01-mmmmm es el segundo 512K, etc. ABAB50 es el primer lote de BDK B , etc. Siempre y cuando solo necesite administrar decenas o quizás cien lotes (más de 50 millones de dispositivos) esto está bien. Si necesitaras más de 500 millones o más, entonces me preocuparía, pero para entonces tendrías suficiente poder para cambiar esto.
Originalmente, la idea era que KSI identificaría el banco o la subparte de un banco (cajeros automáticos, recuerde) y sería único a nivel mundial. por lo tanto, cualquier criptograma en la red de compensación se autoidentificaría / verificaría a quién "pertenece". Hoy en día, KSI se ha vuelto básicamente arbitrario, así que sí, elige lo que te gusta . Excepto que sugiero no usar un valor que tenga ceros iniciales; demasiadas cosas tienden a pensar en los ceros iniciales un valor de aspecto numérico (incluso de aspecto hexadecimal) no es significativo y descárguelo.
ID TRSM (o identificación del dispositivo): sí, solo usa números secuenciales. Pero cuidado que a menudo se muestran los 21-19 bits mostrados en hexadecimal como -00000-ttttt y -00001-ttttt son dispositivo 0, -00002-ttttt más son dispositivo 1, ... -FFFFE-ttttt más son dispositivo 0x7FFFF.