Protocollo di accoppiamento sicuro del dispositivo

Question

Protocollo di accoppiamento sicuro del dispositivo

#1 da (4 voti)
#2 da (1 voti)
#3 da (1 voti)

3

Devo implementare un accoppiamento sicuro tra due dispositivi basato su un breve codice PIN condiviso senza terze parti attendibili. Se pensi al modo in cui i dispositivi bluetooth si accoppiano non sarai lontano - il mio dispositivo visualizza un codice, ti dico "il codice è 40YA", lo inserisci sul tuo dispositivo e abbiamo una connessione sicura .

Il protocollo deve proteggere contro MITM e attacchi di intercettazione e il PIN deve rimanere valido e protetto per almeno alcune ore. In altre parole, se è possibile un attacco offline sul PIN, è necessario che siano necessarie almeno alcune ore.

Esiste un tale protocollo? Punti bonus se un non-crittografo ragionevolmente brillante può capirlo. :)

Aggiornamento: lo scambio di chiavi Diffie-Hellman è ciò che sto cercando?

cryptography mobile network key-exchange

posta n8gray 28.06.2012 - 09:06

fonte

3 risposte

Leggi altre domande sui tag cryptography mobile network key-exchange

I file di log della LAMP contengono talvolta informazioni sensibili? Ftp ha costantemente chiesto un file .exe, cosa posso fare?

score 4 · Answer 1

La risposta di David e ulteriori ricerche mi hanno portato al protocollo EKE (Encrypted Key Exchange) descritto da Bellovin & Merritt qui:

link

e da Wikipedia qui:

link

EKE è progettato specificamente per questo tipo di attività - amplificando una breve password condivisa in un collegamento completamente sicuro. Il protocollo è stato brevettato ma il brevetto è scaduto nel 2011. Ora esiste un RFC per l'utilizzo di EKE con EAP:

link

score 1 · Answer 2

Un'estremità genera una sfida casuale e la trasmette dall'altra parte.
Un lato visualizza un PIN casuale, l'altro richiede il PIN.
L'hash della sfida combinata con il PIN viene quindi utilizzato come chiave di crittografia per il messaggio successivo (anch'esso protetto HMAC, proprio come SSL). Il lato che ha richiesto il PIN invia un messaggio "connesso" crittografato con l'hash e contenente un nonce casuale. L'altra parte risponde con un'accettazione.
Ulteriori comunicazioni sono crittografate con il nonce.

Nessun attacco MITM è possibile perché se il MITM non manomette i dati, non conosce la chiave, e quindi non può modificare alcun dato senza corrompere il protocollo ma se manomette i dati, egli non avrà il messaggio connesso corretto da inviare.

Il lato che invia la sfida può conservarlo e mantenerlo valido per tutto il tempo desiderato. Nessun attacco offline è possibile perché la sfida non contiene dati PIN e la risposta è basata sul nonce casuale che un utente malintenzionato offline non può sapere.

score 1 · Answer 3

Seguirò da vicino Bluetooth > v2.1 qui. Significa che hai le seguenti fasi:

Scambio di chiavi Diffie-Hellman non autenticato tra i tuoi due dispositivi. Al termine del DHE, ogni dispositivo calcola una funzione hash (crittograficamente sicura) sul tasto DH condiviso. Questo hash può quindi essere chiamato "PIN" o qualsiasi altra cosa, ma è not informazioni segrete!
Un dispositivo ora visualizza l'hash e puoi confrontarlo con l'hash sull'altro dispositivo oppure immettere l'hash sull'altro dispositivo e confrontare il dispositivo.
In entrambi i casi, se l'hash non corrisponde su entrambi i lati, si interrompe l'esecuzione dell'associazione.

Ciò che è bello di questo approccio è che non richiede alcuna informazione segreta, sia in-band che out-of-band. Inoltre, la sicurezza relativamente debole di un PIN breve (noto anche come hash) è rilevante solo durante il processo di accoppiamento breve. Quindi, un utente malintenzionato dovrebbe eseguire un MiTM attivo durante lo scambio di chiavi DH e trovare i parametri di Diffie Hellman che, insieme ai parametri di Alice e Bobs, hanno lo stesso valore. Dal momento che probabilmente controllerà solo uno dei valori iniziali di Diffie Hellman (quello in cui inizia lo scambio), potrebbe non essere nemmeno possibile.