Comprensione dei numeri di serie chiave (KSN) in chiave univoca derivata per transazione (DUKPT)

Question

Comprensione dei numeri di serie chiave (KSN) in chiave univoca derivata per transazione (DUKPT)

Naviga le tue risposte

#1 da (4 voti)

2

Ho una serie di domande relative ai numeri di serie chiave (KSN) in DUKPT :

I KSN hanno una lunghezza di 8-10 byte. Le implementazioni precedenti sono 8 byte mentre quelle più recenti sono 10 byte. Rischio di essere incompatibile con qualche vecchio sistema se creo KSN lunghi 10 byte?
I KSN hanno 3 componenti: un contatore di transazioni a 21 bit e i bit rimanenti sono per l'ID set di chiavi e l'ID TRSM (Tamper Resistant Security Module). Per un KSN a 8 byte la convenzione tipica è di 24 bit per l'ID del set di chiavi e 19 bit per l'ID TRSM. Ciò significa circa 16 milioni di chiavi di derivazione base (BDK) e dispositivi 500K. Per me questa allocazione ha pro e contro. I contro sono che non avrò mai BDK 16M e se l'azienda ha successo è abbastanza possibile avere > Dispositivi 500K. Il vantaggio è che ci costringe a non utilizzare lo stesso BDK su più di 500K dispositivi che limita l'esposizione di un BDK che viene compromesso. Leggo che c'è flessibilità nel numero di bit assegnati all'ID del set di chiavi rispetto all'ID TRSM. Quindi sono tentato di scambiare l'allocazione in modo tale da poter avere fino a 500K BDK e dispositivi 16M. Ma vedo anche molte implementazioni open source di DUKPT che presuppongono una divisione di 24-19-21 bit. Queste implementazioni si interromperanno se non seguirò la convenzione. Consiglieresti di limitarmi alla convenzione?
Esiste un modo standard per impostare gli ID del set di chiavi o ogni entità proprietaria di un BDK presenta una sua convenzione? Posso assegnare il set di chiavi ID = 1 al mio primissimo BDK e poi incrementarlo di 1 per ogni nuovo BDK? O questa strategia è troppo ingenua?
C'è un modo standard per impostare l'ID TRSM? Posso assegnare TRSM ID = 1 per il primissimo dispositivo iniettato usando un nuovo BDK e quindi incrementarlo di 1 per ogni nuovo BDK?

cryptography encryption des

posta Fayez 01.07.2015 - 06:59

fonte

1 risposta

Leggi altre domande sui tag cryptography encryption des

Leggibile a macchina, utente non leggibile - file XML Condivisione chiave di derivata base derivata per transazione (DUKPT) derivata (BDK) con un partner

score 4 · Accepted Answer

8/10 byte . Lo standard ha sempre avuto KSN 10 byte (80 bit), ma ha permesso valori più piccoli riempiti a sinistra con 0xFF, e molte persone hanno fatto o usano 8 byte. Non sono in grado di dire che in entrambi i casi c'è uno schema chiaro. Se qualcuno dei dispositivi (o sistemi) che ci si aspetta di gestire sono limitati a 8 byte, quindi si usano 8 byte. Come sotto, in ogni caso è sostanzialmente arbitrario.
Hai ragione quasi tutti sembrano usare xx-19-21 bit che per 8 byte è 24-19-21 bit. Ricorda che DUKPT era originariamente progettato per ATM che costano molte migliaia di dollari, quindi 512K non era un limite fastidioso; ora le persone lo usano per le scatole di fiammiferi. Tecnicamente solo la controparte (xx-21) è importante per la crittografia quindi puoi spostare l'altro limite (i)? se i tuoi programmi, API, partner, ecc. possono gestirlo. OTOH se ti attieni alla convenzione, che è più semplice, niente dice che i diversi KSI devono sempre mappare a diversi BDK. Puoi avere [FFFF]ABAB00-mmmmm è il primo dispositivo 512K per BDK A , ABAB01-mmmmm è il secondo 512K, ecc., ABAB50 è il primo batch per BDK B , ecc. Finché hai solo bisogno di gestire decine o forse un centinaio di lotti (oltre 50 milioni di dispositivi), questo va bene. Se avessi bisogno di più di 500+ milioni allora mi preoccuperei, ma a quel punto avresti abbastanza potere da modificare.
Inizialmente l'idea era che KSI identificasse la banca o la sottoparte di una banca (bancomat, ricorda) ed essere globalmente unica quindi qualsiasi crittogramma nella rete di compensazione si autoidentificherà / verificherà a chi "appartiene". Oggigiorno KSI è praticamente diventato arbitrario, quindi sì scegli quello che ti piace . Tranne che suggerisco di non usare un valore che abbia zero iniziali; troppe cose tendono a pensare a condurre degli zeri un valore dall'aspetto numerico (persino esadecimale) non è significativo e li rilascia.
ID TRSM (o id del dispositivo): sì basta usare numeri sequenziali. Ma attenzione, spesso vieni mostrato i 21-19 bit visualizzati in esadecimale come -00000-ttttt e -00001-ttttt sono dispositivo 0, -00002-ttttt plus sono dispositivo 1, ... -FFFFE-ttttt plus sono dispositivo 0x7FFFF.