Aleatorie și autentificare pe ieșiri cu valoare scurtă (48 de biți)

Vreau să implementez un client care generează valori aleatoare pe 48 de biți și să le trimit ca mesaje difuzate. Presupunem, de asemenea, că există un receptor legitim care primește acele valori (deci, există un fel de pre-autentificare care a avut loc deja, dar nu are importanță aici. De asemenea, putem presupune că clientul/receptorul împărtășește o cheie comună $K$). Deoarece acestea sunt mesaje difuzate, înseamnă, de asemenea, că oricine poate intercepta acele valori. Aș dori ca aceste valori să aibă două proprietăți:

1. Este dificil pentru un atacator să ghicească următoarea valoare aleatorie din secvență
2. Receptorul ar trebui să poată verifica dacă aceste valori provin într-adevăr de la clientul specific

Mă gândeam la o schemă simplă care face următoarele:

Client

1. $t$ = AES-CTR($K$, nonce||counter, random_plaintext)â

2. $r = t â K$ (păstrați ultimii 48 de biți)

3. Difuzare $t, r$

Folosesc AES-CTR pentru a genera un șir temporar cu aspect aleatoriu $t$ și apoi XOR-l cu cheia încă o dată pentru a genera valoarea mea aleatoare.Apoi păstrez ultimii 48 de biți și îi transmit pe amândoi $t$ și $r$. Atunci receptorul poate pur și simplu:

Receptor

1. $r' = t â K$ (păstrați ultimii 48 de biți)
2. Verifica $r' == r$

Dacă verificarea reușește atunci el autentifică clientul pentru că numai el cunoaște aceeași cheie $K$. De asemenea, valoarea fiind o ieșire a AES-CTR ar trebui să fie destul de aleatorie, ceea ce înseamnă că este foarte dificil pentru cineva să ghicească următorul.

Această schemă îndeplinește cerințele mele? Trunchierea ultimilor 48 de biți prezintă un risc de securitate?

Această schemă îndeplinește cerințele mele? Trunchierea ultimilor 48 de biți prezintă un risc de securitate?

Schema este ruptă de un adversar pasiv care primește o singură pereche $(t,r)$. Observați că ultimii 48 de biți ai cheii pot fi recuperați ca $K[:48] = t \oplus r$. Prin urmare, atacatorul poate trimite acum arbitrar $(t^*, r^*)$ valori pe care receptorul le va accepta. Reamintind că verificatorul face următoarele

$r' = t' \oplus K$ (păstrați doar ultimii 48 de biți); verifica $r = r'$

Vedem că nu este necesară cunoașterea restului cheii.

În plus, valorile de 48 de biți oferă o protecție scăzută împotriva coliziunilor, dar asta poate fi bine pentru aplicația dvs....

Reluare: un atac mai simplu este reluarea perechii $(r, t)$. Descrierea nu spune cum verifică receptorul pentru acest lucru.

Soluție potențială: Din descrierea inițială, se pare că receptorul este destul de limitat din punct de vedere computațional și pot calcula doar xors sunt cei mai mulți și nu AES-CTR, de exemplu. Ceea ce ar fi ciudat cu următoarele

Deci, există un fel de pre-autentificare care a avut loc deja, dar nu are importanță aici

Oricum, o posibilă soluție este utilizarea a două funcții pseudo-aleatoare dacă receptorul poate face mai mult decât xors. (Mă îndoiesc că este sigur...). Inițial, extindeți $K$ în $K_1, K_2, K_3$ de lungime adecvată.

Expeditorul face următoarele

1. $r =$ AES-CTR$(K_1, contor)$ (păstrați ultimii 48 de biți)
2. trimite $contor, r, \tau = HMAC(K_2, contor,r)$

Receptorul face următoarele

1. La primire $r, \tau$, verifica $\tau$
2. Contorul de cecuri a crescut
3. Rederive $r$.

Cateva observatii:

• Difuzarea aici nici măcar nu este necesară dacă expeditorul și receptorul sunt cineva care împărtășește un ceas.
• Alternativa are câteva probleme când vine vorba de robustețe în cazul unei reporniri, așa cum a subliniat într-un comentariu al lui Paul.