Când presupuneți că C acționează ca un adversar, este cu urechea și este capabil să construiască mesaje pe baza informațiilor dobândite, trebuie să vă proiectați protocolul cu grijă. Acest lucru rezultă din faptul că C ar putea retransmite, reda și construi mesaje. Prin urmare, trebuie să preveniți reluarea și atacurile de tip man-in-the-middle, în plus, gestionarea pentru mai multe sesiuni de protocol (simultan).
Ai realizat deja că o semnătură statică ar putea să nu fie suficientă. În esență, problema ta este motivația protocoalelor de autentificare și designul lor nu este banal: dacă arunci o privire la protocolul NeedhamâSchroeder 1 sau protocolul Woo-Lam 2 veți vedea că vectorii de atac neprevăzuți v-ar putea rupe protocolul, deoarece ambele exemple sunt nesigure în versiunile lor originale.
Practic, unele dintre cele mai bune practici pentru proiectarea protocolului securizat sunt:
- Faceți presupuneri maxim pesimiste
- Puneți expeditorul și destinatarul în mesaje (adică, cheile lor publice)
- Utilizați criptarea pentru a vă asigura că numai receptorul corect poate citi conținutul
- Folosiți non-uri / marcaje de timp pentru a obține prospețime
- Generați singuri non-uri pentru a preveni atacurile de reluare
- Semnează și criptează întotdeauna componentele împreună
Dar totuși: există protocoale considerate sigure care nu respectă toate punctele și protocoale nesigure care o fac.
În orice caz, ați dori să analizați protocolul (semi-)automat folosind, de exemplu, verificarea modelului sau demonstrarea teoremei.
