Demonstrând că un protocol nu este atacabil

Luați în considerare următorul protocol:

1. $A\rightarrow B: \{N_A,A\}_{pk(B)}$

2. $B\săgeată la dreapta A: \{N_B,N_A\}_{pk(A)}$

3. $A\săgeată la dreapta B: hash(N_B, A, B)$

unde se intenţionează ca atunci când fie $A$ sau $B$ și-a îndeplinit propriul rol în protocol, li se asigură că celălalt a participat la protocol cu ​​ei și că $N_A$ și $N_B$ sunt non-uri aleatorii generate de $A$ și $B$. $\{X\}_{Y}$ înseamnă că $X$ este criptat sub cheie $Y$.

Știu cu siguranță că nu există niciun atac pentru acest protocol, dar nu sunt sigur cum să-l dovedesc.

Fără capacități clar definite de atacator și nici garanții de securitate ale diferitelor componente (criptare cu cheie publică, funcție hash etc.). Nu este ușor de spus dacă acest protocol este sau nu „atașabil”.

Având în vedere că ni se oferă „cartă blanche”, voi arăta două atacuri PITM bazate pe diferite modele de securitate și atacatori.

Modelul general al atacatorului: presupun un atacator cu control deplin al rețelei, acesta poate injecta, reordona, modifica și în alt mod șterge mesajele. Mai mult, atacatorului i se permite să „înregistreze” noi utilizatori oricând.

Atacul 1: legarea greșită a identității și necesitatea unui PKE securizat mai mult decât CPA

După cum este scris, se pare că protocolul ar trebui să fie sigur atâta timp cât este utilizată o schemă PKE „securizată”. Cu toate acestea, noțiunea de bază de securitate ca și în securitatea semantică nu este suficientă. La un nivel înalt, la sfârșitul atacului, $A$ crede că vorbesc cu $B$, in timp ce $B$ crede că vorbesc cu atacatorul spune $E$.

Pentru a face acest lucru, vom prezenta un PKE securizat CPA pentru care atacul este posibil. Lăsa $\matematic E$ să fie o schemă PKE „hibridă” (în rest, bazată) pe o funcție de trapă. Unde criptarea mesajului $m$ sub $pk$, constă aproximativ în generarea unei valori aleatorii $s$ apoi generați o cheie de criptare simetrică $k = H(s)$. $k$ este apoi folosit pentru a cripta mesajul cu un algoritm de tip stream cipher, creând un text cifrat $c$. Textul cifrat final din schema PKE este $$\{m\}_{pk} = (enc_{PKE}(pk, s), c)$$ Atacul funcționează după cum urmează.

1. $ A\rightarrow B: c_1 = \{N_A,A\}_{pk(B)} $
2. Atacatorul interceptează acest mesaj, creează un nou utilizator $E$, modifică textul cifrat la o valoare $c_1'$ astfel încât să decripteze la $N_A, E$. Acest lucru este posibil, deoarece folosim un cifru de flux. (De asemenea, presupunem, de exemplu, că nonce și identitățile sunt de lungimi fixe etc...)
3. $B$ decriptează mesajul și pare $E's$ identitate, prin urmare, al doilea mesaj este trimis $E$
4. $B \rightarrow E: c_2 = \{N_A. N_B\}_{pk_E}$.
5. $E$ decriptează $c_2$, și primește non-urile.
6. $E \rightarrow A: c_2' = \{N_A, N_B\}_{pk_A}$
7. $A \rightarrow B: c_3 = H(N_B, A, B)$
8. $E$ intercpetă dropbs $c_3$ si trimite $c_3' = H(N_B, E, B)$

Din fluxul de deasupra, priveliștea $A$ este la fel ca și cum ar interacționa cu $B$, în timp ce vederea de $B$ este ca și cum ar interacționa cu $E$.

Atacul 2: Expunerea secretă pe termen lung și integritatea compromisului cheie

Aici capacitățile atacatorului sunt consolidate și permitem compromisul cheilor secrete pe termen lung. Acum, evident, dacă $sk_A$ este compromisă (și $A$ încă nu știe) atacatorul poate imprima $A$ după plac; totusi pare normal sa ne asteptam ca daca $A$ conduce o sesiune cu un onest $B$, $A$ ar trebui să aibă siguranța cu cine a vorbit. Cu toate acestea, în acest atac, compromis de $sk_A$ implică faptul că atacatorul poate imprima pe oricine $A$.

Ideea de bază ca mai sus este că, un atacator PITM va putea decripta al doilea mesaj $\{N_A, N_B\}_{pk_A}$. Atacatorul poate încheia acum interacțiunea cu $A$ și „tăiați firul” spre B. În consecință, $A$ crede că vorbesc $B$ în timp ce vorbea de fapt cu B.

Voi presupune multe despre protocol care nu sunt explicite în întrebare. Declar câteva dintre acestea în a doua secțiune a acestui răspuns. De asemenea, nu voi face argumentele mele prea detaliate.

Asigurarea dorită este

(participanții) sunt asigurați că celălalt a participat la protocol cu ei

dar voi elimina cu ei, deoarece acest lucru nu este clar și nu văd nicio definiție precisă a acesteia pe care cripto o poate întâlni (este întotdeauna posibil ca un Man-in-the-Midle să transmită mesaje neschimbate). Îl voi înlocui cu de când a început protocolul, care nu trebuie confundat cu cel mult mai puternic în modul în care decurge în mod normal protocolul.

La pasul 1, $N_A$ a fost ales aleatoriu de $A$ și criptat sub $pk(B)$, ca parte a textului simplu al $\{N_A,A\}_{buc(B)}$. Numai asa $A$ sau o entitate care are un anumit grad de capacitate de a descifra $\{N_A,A\}_{buc(B)}$, doar asta $B$, poate ști orice despre $N_A$ pe langa lungimea ei. Astfel, când la încheierea pasului 2, $A$ primește ceva care descifrează la $N_A$și știu că nu au folosit $N_A$ în alt scop decât generarea mesajului pasului 1, au asigurarea că $B$ a participat la protocol. Nu voi face această asigurare cantitativă, rezervând-o pentru cealaltă direcție.

La pasul 2, $N_B$ a fost ales aleatoriu de $B$ și criptat sub $pk(A)$, ca parte a textului simplu al $\{N_B,N_A\}_{buc(A)}$. Numai asa $B$ sau o entitate care are un anumit grad de capacitate de a descifra $\{N_B,N_A\}_{buc(A)}$, doar asta $A$, poate ști orice despre $N_B$ pe langa lungimea ei. Presupunând
 (a) hash-ul este un oracol aleatoriu cu lățime de ieșire $k_H$,
 (b) $N_B$ a fost aleasă uniform la întâmplare și are lățime $k_N$,
 (c) orice adversar are un avantaj limitat de $\epsilon$ împotriva criptării,
apoi a spus adversarul ca probabilitate delimitată de $2^{-k_H}+2^{-k_N}+\epsilon$ pentru a găsi exact valoarea hash-ului pasului 3. Astfel, când la încheierea pasului 3, $B$ găsește o asemenea valoare pentru hașul pe care îl recalculează și știu că nu l-au folosit $N_B$ în alt scop decât generarea mesajului pasului 2, au asigurarea că $A$ a participat la protocol.

Dacă acest raționament este corect, pasul 3 ar putea fi simplificat la $A\săgeată la dreapta B:\ hash(N_B)$. Dacă nu, vreau să știu de ce! Acest lucru nu trebuie interpretat ca o sugestie pentru a face această simplificare: includerea identităților în ceea ce este hashed poate doar ajuta și văd vag că poate bloca unele modificări intenționate ale protocolului, doar că nu de tipul care încalcă asigurarea de securitate, așa cum am reiterat. aceasta.

Lista parțială de ipoteze care nu sunt menționate în întrebare

• Adăugare tardivă: cheile publice sunt cunoscute și de încredere înainte de începerea protocolului.
• Adăugare târzie: Cifrul este securizat IND-CCA2. Deoarece nu am nicio certitudine dacă putem scăpa cu o proprietate mai mică, prefer să greșesc pe partea sigură.
• Așa cum adesea lăsați nedeclarați în analiza protocolului, destinatarii mesajelor
  • încercați decriptarea și anulați dacă aceasta nu reușește (cum o face decriptarea multor cifruri IND-CCA2)
  • analizați mesajele descifrate conform convenției stabilite pentru generarea lor și anulați dacă aceasta nu reușește
  • verificați valorile primite față de valoarea lor așteptată dacă sunt cunoscute dintr-un pas anterior sau pot fi calculate în alt mod (cum se întâmplă pentru hash-ul pasului 3 pe $B$ lateral) și avortați la nici un meci. Nu pare necesar ca o astfel de comparație să se facă în timp constant.
  • sau/și reutilizați valoarea menționată pentru variabilele cu același nume în pașii următori.
• În textul simplu al mesajelor criptate, semnul virgulă simbolizează o formă de concatenare cu prevederea că din rezultat rămâne posibilă divizarea în punctul în care a avut loc concatenarea, de ex. deoarece unul dintre cele două mesaje concatenate are o dimensiune fixă. Acest lucru nu pare necesar pentru semnul virgulă utilizat în mesajul hashing la pasul 3.
• În mesaje, $A$ și $B$ sunt identitățile participanților eponimi.
• Entitățile își folosesc cheile private numai în scopul decriptării mesajelor pe care le primesc.
• După pasul 1, $B$ decide ce cheie publică utilizează pentru criptare la pasul 2 și către ce destinatar să trimită la acel pas, pe baza celei de-a doua părți $A$ a mesajului descifrat de la pasul 1 și anulează dacă nu cunosc cheia publică corespunzătoare. Nu este necesar pentru securitatea protocolului, după cum s-a declarat că ei verifică că această a doua parte nu este propria lor identitate.
• Dacă participanții încearcă mai multe conexiuni simultane, așa cum fac de obicei serverele, se presupune că păstrează variabile separate pentru fiecare instanță de protocol. Nu văd niciun motiv pentru care nu ar fi OK ca încercările multiple de conectare în care se angajează o entitate să fie în direcții potențial diferite.
• Nu țin cont de canalele secundare care nu au fost deja discutate, atacurile de defecte și erorile de implementare.