AES CBC: Când să utilizați noul IV

Încerc să îmi dau seama când să folosesc un nou IV pentru o comunicare AES-CBC și dacă abordarea mea este sigură.

Aici este citat de la Thomas Pornin de la o întrebare similară:

Deci, pentru a rezuma: trebuie să alegeți un IV nou, aleatoriu (cu a generator criptografic puternic) ori de câte ori sunteți pe cale să criptați date în text clar care au fost obținute după ce au trimis prin fir blocul criptat anterior.

Am nevoie de lămuriri în acest sens. Configurația mea actuală sunt două dispozitive care comunică între ele folosind o schemă de comandă/răspuns (master și slave). Sclavul are un adevărat generator de numere aleatorii.

Ideea mea este că masterul solicită un IV de la sclav pe care apoi îl folosește pentru a cripta o comandă. Sclavul decriptează comanda și apoi folosește ultimul text cifrat al comenzii ca un IV pentru criptarea acesteia, văzând practic comanda și răspunsul ca un flux continuu. După transmiterea răspunsului, slave creează un nou IV care poate fi apoi solicitat din nou de către master.

Este sigur? Mulțumiri!

Probabil că nu este înțelept să-l lași pe celălalt participant să-ți aleagă IV. Dacă nimic altceva, atacatorul ar putea forța reutilizarea IV.

Mai frecvent, schemele de provocare și răspuns introduc provocarea în textul simplu și lasă cheia/IV folosită așa cum este prescris. Faptul că celălalt participant poate cripta o provocare aleasă aleatoriu este, în general, o dovadă a deținerii unei chei.

Se pare că aveți o oarecare îngrijorare că răspunsul sclavului ar trebui într-un fel să fie legat de răspunsul stăpânului. Un protocol comun la care mă pot gândi aici ar fi protocolul cu clichet dublu. Unde (aproximativ) textele simple informează un pas de derivare a cheii pe care ambele părți îl urmăresc în mod independent.

Dacă nu ai un canal securizat, atunci nu poți avea încredere în IV-ul pe care ți-l trimite cealaltă parte, pentru că un atacator ar putea foarte bine să-l manipuleze. Chiar dacă aveți un canal securizat, cealaltă parte ar putea să nu fie considerată deosebit de demnă de încredere.

Dacă dispozitivul dvs. principal are un fel de CSPRNG, indiferent dacă este alimentat de un adevărat generator de numere aleatoare sau nu, îl puteți folosi. În caz contrar, dacă puteți avea un fel de contor persistent, o modalitate ușoară de a gestiona acest lucru este să utilizați o funcție de derivare a cheilor precum HKDF. Pur și simplu utilizați cheia partajată ca intrare de entropie în funcția de derivare a cheii, utilizați contorul ca sare și apoi generați ambii o cheie nouă și IV pentru fiecare mesaj. Trimiteți contorul în loc de IV-ul cu mesajul, iar cealaltă parte vă poate obține cheia.

Acest lucru poate funcționa chiar dacă nu aveți un contor persistent dacă dispozitivul principal are un ceas de încredere. Puteți utiliza un marcaj de timp plus un contor mai efemer sau orice alt tip de date care este garantat să nu se repete și să le utilizați în HKDF. Apoi, trimiteți asta împreună cu mesajul și ambele părți pot conveni asupra cheii secrete și IV.

După cum menționez pentru totdeauna, puteți utiliza și un protocol cu ​​clichet dublu, deși acesta este mai complex. De asemenea, necesită ca ambele părți, cel puțin inițial, să aibă un CSPRNG, deoarece veți avea nevoie de unul pentru cheile Diffie-Hellman.