Condivisione chiave di derivata base derivata per transazione (DUKPT) derivata (BDK) con un partner

Se B desidera specificamente i dati crittografati end-to-end dal dispositivo di campo a loro, allora in effetti hai bisogno di dispositivi iniettati sotto un BDK noto a B - o generato e dato a B , o B generato da solo e fornito a te o ai tuoi fornitori / impianti di iniezione - e preferibilmente non utilizzato da o condiviso con nessun altro.

Non dici che tipo (i) di dispositivi e utenti / impostazioni ti interessano. Ho visto (negli Stati Uniti) alcuni dispositivi di vendita al dettaglio / point-of-sale (magstripe "swipe" e pinpad, a volte EMV) che possono essere iniettati con due chiavi del dispositivo, sotto due diversi BDK. Ma quelli che ho visto tendevano ad essere la fascia più alta (quindi più costosa), e hai ancora il problema di scegliere quale chiave usare per una determinata transazione / data-item, che di solito significa qualche altro sistema che si interfaccia con gli umani coinvolti, come un registratore di cassa / cassa, che viene modificato per prendere questa decisione e comandare il dispositivo.

Se B è preoccupato solo per i dati crittografati sempre in modo che non siano vulnerabili agli attacchi, potrebbero essere soddisfatti per trattare il tuo server come un singolo dispositivo (insolitamente occupato) in la loro rete - cioè ti assegnano una chiave iniziale (e il corrispondente KSN iniziale) sotto loro BDK; ottieni ogni transazione crittografata dal dispositivo con una chiave BDK-A, decrittografala e immediatamente re-encrypt sotto la chiave BDK-B, e invialo a B.

Se utilizzi un HSM per la tua crittografia e per grandi volumi di dati sensibili ai pagamenti, questo è spesso fornito come un'unica operazione chiamata "translate" - cioè, anziché "decifrare sotto la chiave # 3" quindi "crittografare con la chiave # 17", il tuo software può richiedere "tradurre dalla chiave # 3 alla chiave n. 17", e quindi il testo in chiaro non è mai visibile nella tua CPU / memory / swap, solo all'interno dell'HSM dedicato e protetto da hardware.

A seconda dei volumi di transazione questo potrebbe bruciare abbastanza velocemente i valori un po 'meno di 2 ^ 21 del TCTR, quindi B potrebbe doverti inviare un altro "dispositivo" (o forse diversi) ogni mese o settimana o qualsiasi altra cosa, utilizzando un meccanismo che sia al contempo sicuro e il più automatizzato possibile per evitare errori. Dovresti assolutamente provare ad avere ogni nuova chiave pronta almeno una settimana prima che ti aspetti di averne bisogno, preferibilmente di più, nel caso in cui picchi di volume o qualche guasto ti costringano a passare presto. Ma se stanno facendo soldi sulle transazioni che li mandi, e presumibilmente non accetterebbero altrimenti la tua attività, dovrebbero essere in grado di gestirli.

DUKPT Lo schema Unico derivato per transazione (DUKPT) viene utilizzato in un ambiente POS (punto vendita). Come indica il nome, la chiave univoca derivata per transazione genera una nuova chiave per ogni transazione. Questa tecnica prevede l'uso di Base Derivation Key (BDK) e Key Serial Number (KSN). Su ciascuna transazione, il PIN pad genera una nuova chiave di crittografia derivata da un BDK segreto e un KSN non segreto. Cifra il PIN con questa chiave, quindi inoltra sia il PIN crittografato che il numero di serie della chiave all'acquirer. Il vantaggio di DUKPT è che se viene scoperta una di queste chiavi di crittografia una tantum, solo una transazione verrà compromessa, nessuna delle altre transazioni dallo stesso dispositivo POS potrebbe essere decodificata con quella chiave. Si noti che viene utilizzato il metodo ANSI X9.24-1: 2009 per derivazione chiave DUKPT.

Chiave di derivazione di base

L'host dell'acquirente ha la responsabilità di mantenere la chiave di derivazione di base. In HSM, la chiave di crittografia monouso generata dalla voce PIN viene "derivata", utilizzando la chiave di derivazione di base originale e il numero di serie chiave fornito dalla voce PIN. Nelle applicazioni pratiche, l'host acquirer avrebbe diversi BDK, possibilmente per diversi dispositivi di inserimento PIN. Durante l'elaborazione delle transazioni, è importante che l'acquirente sappia quale BDK è stato utilizzato per inizializzare o iniettare nel dispositivo di immissione PIN originario. Per ottenere ciò, l'identificatore della chiave di derivazione di base è incorporato nella stringa del numero di serie chiave.

Per ciascuna transazione, l'host acquirente estrarrà dalla memoria interna la chiave di derivazione di base crittografata appropriata identificata dall'ID BDK della stringa KSN. L'host dell'acquirente deve trovare una corrispondenza all'interno dell'elenco crittografico BDK (profilo BDK gestito nell'host acquirente). Se una corrispondenza non viene trovata nel database, la transazione verrà rifiutata. Ulteriori informazioni su: link

Un modo per mantenere sia la sicurezza che il controllo è quello di fornire al processore B un HSM fisico da installare nel proprio data center, ma che per contratto appartiene a voi. Questo ha due enormi vantaggi.

1. La sicurezza del dispositivo è una tua decisione e un HSM garantisce che non possa essere violato dal processore.
2. Dal momento che sei il proprietario del dispositivo, sei libero di cambiare i processori di pagamento in base strettamente ai motivi commerciali. Se l'azienda vuole cambiare processori alla fine di un contratto, devi semplicemente riavere il tuo HSM. Non c'è bisogno di una costosa reintroduzione delle chiavi nelle migliaia di terminali già distribuiti e dei ritardi a lungo termine che ciò potrebbe creare.

Ciò sarà costoso, ovviamente, ma più economico dei problemi che altre soluzioni potrebbero creare.