înregistrare Logare
Puncte:0
avatar Crypto

Utilizarea secretului partajat ca date de autentificare Out-Of-Band în împerecherea Bluetooth

drapel br
obareey

Conform specificației Bluetooth, procesul de asociere începe cu Slave care trimite un pachet publicitar conectabil și apoi Master inițiază conexiunea. În autentificarea LE Legacy OOB, o cheie temporară (TK) secretă pe 128 de biți ar trebui să fie partajată prin alt canal securizat, de ex. NFC, care urmează să fie utilizat într-o autentificare la provocare-răspuns, care sună astfel:

  1. Maestrul alege Mrand aleatoriu și calculează Mconfirm = AES(TK, AES(TK, Mrand XOR p1) XOR p2)
  2. Sclavul alege Srand aleatoriu și calculează Sconfirm = AES(TK, AES(TK, Srand XOR p1) XOR p2)
  3. Maestrul trimite Mconfirm
  4. Slave trimite Sconfirm
  5. Stăpânul îl trimite pe Mrand și Slave confirmă
  6. Sclavul îl trimite pe Srand și Master confirmă
  7. Cheia pe termen scurt este calculată ca STK = AES(TK, Srand[65:128] || Mrand[65:128])
  8. Comunicarea ulterioară este criptată cu STK.

unde p1 și p2 conțin adresele Master și Slave împreună cu câteva informații despre comanda de împerechere etc.

Acum să presupunem că Maestrul și Sclavul au o cheie secretă (SK) care este inscripționată în ei din fabrică. Intenționez să trimit o date aleatoare de 128 de biți (RD) în pachetul de publicitate, astfel încât ambele părți să le poată utiliza pentru a calcula TK ca TK = AES (SK, RD). Nu am văzut această abordare în altă parte și există foarte puțină literatură despre analiza autentificării LE Legacy OOB din câte văd.

Deci, este aceasta o abordare validă? Care sunt problemele cu el?

Alte informații și ipoteze conexe:

  1. Sarcina utilă a pachetului publicitar conectabil este deja criptată și autentificată prin CCM utilizând o altă cheie, împreună cu protecția la reluare prin contor și/sau marca temporală.
  2. Există mulți stăpâni și sclavi în care stăpânii sunt în locații fixe și sclavii sunt mobili. Fiecare slave are un SK unic, iar masterii îl pot căuta dintr-o bază de date securizată.
  3. Legătura nu poate fi utilizată deoarece nu ar trebui să existe nicio interacțiune a utilizatorului pentru autentificare și cheile de legătură nu pot fi partajate între master.
  4. LE Secure Connections ar trebui să fie mai sigure, dar necesită interacțiunea utilizatorului pentru autentificare, ceea ce nu putem oferi.
  5. Conexiunea se va face la fiecare 1-10 minute pentru fiecare slave.
49
1 + 0
aes
Puncte:2
avatar Crypto
drapel us
Mikero

Acest lucru nu mi se pare un protocol de autentificare foarte bun. Puteți vizualiza $(Mrand, \textsf{AES}_{TK}(\textsf{AES}_{TK}(Mrand \oplus p_1) \oplus p_2))$ ca o încercare a unui CBC-MAC randomizat de $p_1\|p_2$, cu $Mrand$ fiind vectorul de initializare.

Din păcate, CBC-MAC randomizat este complet spart ca MAC. Să presupunem că un adversar vede un MAC valid $(R,T) = \bigl(R, \textsf{AES}_K(\textsf{AES}_K(R \oplus p_1) \oplus p_2)\bigr)$ a unui mesaj $p_1 \| p_2$. Apoi poate produce $(R \oplus \delta, T)$ care este un MAC valid al mesajului $(p_1 \oplus \delta) \| p_2$.

În afară de încercarea proastă la un MAC, acest protocol suferă de atacuri banale de reluare. Fiecare parte alege o valoare aleatorie care afectează doar propriile mesaje. Pentru a preveni reluarea, fiecare parte ar trebui să își lege mesajele de protocol la o valoare aleasă aleatorie de către alte parte.

Există chiar și un atac de reflexie. În acest protocol dacă comandantul trimite $Mrand, Mconfirm$ atunci clientul poate ecou înapoi $Srand=Mrand$ și $Sconfirm=Mconfirm$, care ar trebui să verifice corect, cu excepția cazului în care există mai multe în protocol decât menționați.

Rezultatul acestor atacuri este că un punct final crede că este împerecheat cu succes, în ciuda faptului că celălalt punct final nu cunoaște cheia în afara benzii $TK$. Totuși, atacatorul nu poate obține cheia de sesiune.

0 + 3
drapel br
obareey
Multumesc pentru raspuns. Am verificat din nou în ce constă p1 și p2. Se pare că p1 conține doar parametrii de conexiune, care ar trebui să fie constant între toate conexiunile. Deci, putem ignora orice încercare de conectare dacă p1 este diferit de cel așteptat. p2 include ambele adrese master și slave. Este suficient acest lucru pentru a preveni problema CBC-MAC randomizată?
0
Răspunde
drapel br
obareey
TK se modifică pentru fiecare sesiune în funcție de valoarea aleatoare furnizată de slave în pachetul publicitar și o cheie secretă partajată care a fost furnizată la momentul producției. Cred că previne atacurile de reluare?
0
Răspunde
drapel br
obareey
Bănuiesc că atacul prin reflexie poate fi prevenit bifând $Sconfirm \neq Mconfirm$ sau $Srand \neq Mrand$? Sper că acest lucru este implementat de furnizorul de stivă. Pot solicita un patch dacă nu este implementat.
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.