Problema di autenticazione a 4 byte

Question

Problema di autenticazione a 4 byte

#1 da (5 voti)

5

Ho un classico problema di sicurezza in cui Alice deve dimostrare la propria identità a Bob ma con requisiti e vincoli piuttosto insoliti a causa di un contesto M2M .

EDIT in grassetto

Il canale di comunicazione utilizzato tra Alice e Bob ha le seguenti caratteristiche:

solo Alice può inviare messaggi a Bob (Bob non può parlare con Alice)
di Alice sono lunghi 4 byte
Bob interrompe l'ascolto durante 10 minuti dopo aver ricevuto 10 messaggi
Alice deve dimostrare la propria identità utilizzando un solo messaggio, se possibile

Altri requisiti specifici sono:

Alice ha una CPU bassa & memoria , Bob ha una CPU elevata & memoria risorse
Il messaggio deve includere l'identità di Alice, ma senza la necessità di nasconderlo
Esiste un numero illimitato di entità Bob
C'è < 4000 entità come Alice che possono autenticare qualsiasi Bob
Gli attacchi di replica devono essere ragionevolmente prevenuti (un replay può essere possibile durante alcuni minuti dopo l'emissione ma non di più)
Va bene che Bob venga ingannato dalla forza bruta, a patto che ci sia bisogno di tempo all'avversario per farlo (cioè diversi giorni di calcolo o di nuovo tentativo)

Ecco cosa mi è venuto in mente per il messaggio Alice 4 bytes:

bits 1-20 = truncate(HMAC(date.format(dd/MM/yy hh:mm)),20) 
bits 21-32 = Alice ID (12bits = 4096 IDs)

Quando Bob riceve il messaggio, se consentiamo la deviazione di X minuti tra l'orologio di Alice e quello di Bob, Bob calcola

truncate(HMAC(date.format(dd/MM/yy hh:mm)),20)

per X / 2 minuti dopo e prima della ricezione. Quindi, ad es. X = 10 minuti, Bob calcola 10 valori. Se uno di questi valori corrisponde all'emissione di Alice, Alice viene autenticata.

L'avversario ha X / 2 ^ 20 possibilità di generare in modo casuale il buon messaggio. Poiché Bob ascolta solo 10 messaggi ogni 10 minuti, in media occorrono circa 73 giorni se la matematica è corretta (per X = 10 minuti), il che va bene.

L'attacco di riproduzione è possibile durante X / 2 minuti.

Le maggiori possibilità di collisione introdotte dal troncamento dell'HMAC a 20 bit non compromettono la chiave privata né riducono il livello di sicurezza del processo AFAIK.

Sono uno sviluppatore, non un ragazzo di sicurezza, la mia soluzione è ragionevole e la mia analisi è corretta? Ne vedi uno migliore?

authentication hmac

posta Rémy DAVID 29.07.2014 - 11:45

fonte

1 risposta

Leggi altre domande sui tag authentication hmac

Wifi ananas "Karma" Download drive-by

score 5 · Accepted Answer

Ciò che conta sono le rispettive abilità di Alice e Bob in merito a storage . Nel tuo caso, presumi che né Alice né Bob abbiano memoria; condividono un valore segreto (per HMAC), ma non hanno lo slot di lettura / scrittura da aggiornare. D'altra parte, si assume anche che Alice e Bob abbiano orologi che sono ragionevolmente precisi (a pochi minuti l'uno dall'altro).

Se Alice e Bob hanno gli orologi ma non la memoria, la soluzione è ragionevole. La tua matematica è un po 'spenta:

Se Bob consente una deviazione di X minuti, calcolerà i valori 2X + 1 , non solo X .
Gli attacchi di riproduzione sono possibili fino a 2X minuti circa, se l'orologio di Alice è troppo presto per X minuti.

Se Bob ha una memoria transitoria (RAM ...), può inoltre proteggersi dagli attacchi di replay ricordando i messaggi ricevuti negli ultimi minuti 2X : in questo modo, Bob può rilevare la riproduzione di messaggi che non sono troppo vecchi (e i vecchi messaggi verrebbero rifiutati a causa della loro età).

Se Alice e Bob hanno una memoria di lettura / scrittura permanente, allora possono usare un contatore invece di un orologio. Questo può rendere l'implementazione dell'hardware molto più semplice (gli orologi hanno bisogno di un approvvigionamento energetico costante, i contatori no).

Il tuo errore principale , tuttavia, è che stai cercando di definire il tuo protocollo. Questo, in generale, non è una buona idea. Invece, dovresti fare affidamento su protocolli esistenti, revisionati da colleghi. Pertanto, si desidera utilizzare HOTP (per la soluzione basata su contatore) o TOTP (che riutilizza internamente la meccanica HOTP). Sei caldamente incoraggiato a leggere i loro rispettivi RFC ( RFC 4226 e 6238 , rispettivamente), che sono ben scritti.

(Non eri lontano, però. La tua proposta è abbastanza vicina al TOTP, ma la crittografia è sottile, quindi usare gli standard esistenti è sempre meglio.)