înregistrare Logare
Puncte:2
avatar Crypto

Ce poate face un atacator cu această utilizare nesigură a AES-CFB8?

drapel in
katoriw701

Cred că am găsit utilizarea nesigură a AES-CFB8 într-o aplicație la care lucrez și sper că cineva ar putea explica cum și de ce este nesigur și ce ar putea face un atacator, cum ar fi recuperarea cheii, deoarece acesta ar fi rezultatul mai rău pentru acest protocol. .

Practic, AES-CFB8 (în mod explicit fără padding) este folosit pentru a cripta un flux de date și IV/cheia sunt reutilizate între fluxurile server și client, iar IV-ul este același cu cheia. Cât de nesigur este acest lucru și este posibil ca un atac să recupereze iv/cheia din aceasta. Cheia folosită pentru AES este un secret partajat care ar putea compromite mai mult decât fluxul de pachete original, deoarece fluxul care are această posibilă utilizare nesecurizată nu este la fel de sensibil, dar ar fi o problemă mai mare dacă cheia utilizată ar fi compromisă.

public static SecretKey generateSharedSecret() {
   final KeyGenerator gen = KeyGenerator.getInstance("AES");
   gen.init(128); // AES-128
   return gen.generateKey();
}

// Decis de client și trimis într-un mod securizat la server prin RSA și validat printr-o sursă de încredere.
final SecretKey sharedSecret = generateSharedSecret();

 // Acest lucru se face atât pe server cât și pe client după ce serverul a primit secretul partajat. 
 Cipher final aesCFBEncrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBEncrypt.init(Cipher.ENCRYPT_MODE, sharedSecret, nou IvParameterSpec(sharedSecret.getEncoded()));

 final Cipher aesCFBDecrypt = Cipher.getInstance("AES/CFB8/NoPadding");
 aesCFBDecrypt.init(Cipher.DECRYPT_MODE, sharedSecret, nou IvParameterSpec(sharedSecret.getEncoded()));

 this.enableStreamEncryption(aesCFBEncrypt, aesCFBDecrypt);

M-am uitat în jur pentru probleme similare, dar niciuna pe care nu am găsit-o să se potrivească cu criteriile care mă interesează, adică utilizarea cifrului ca flux cu diferite instanțe pentru RX/TX pe client și server și utilizarea cheii ca iv fără a avea o altă cheie. cheie pentru server și client.

80
0 + 0
aes
SAI Peregrinus avatar
drapel si
SAI Peregrinus
De ce CFB? Acesta nu este un mod disponibil în mod obișnuit și nu este AE-secure, așa că răspunsul este „nu”, ignorând și celelalte probleme legate de aceasta.
0
Răspunde
drapel in
katoriw701
@sai-peregrinus Nu am idee de ce a fost folosit CFB, acest cod a fost scris acum peste un deceniu, dar cineva care nu sunt eu. Sunt conștient că fluxul în sine poate fi manipulat, dar protocolul de bază are mecanisme pentru a face acest lucru dificil sau imposibil în timp real.Să presupunem că protocolul de bază utilizează MAC-then-Encrypt pentru autentificare. Aceasta este o analiză de cod a unui program moștenit, nu o utilizare proastă a cripto-rulării automate pentru un nou protocol, dacă presupuneți asta. Multe greșeli și practici proaste au fost făcute aici și poate funcționa doar din cauza norocului, dar mă întreb despre orice atacuri practice.
0
Răspunde
drapel in
katoriw701
@SAIPeregrinus Mă interesează mai mult dacă secretul partajat folosit cu cifrul și dacă acesta poate fi recuperat, mai degrabă decât încearcă să manipuleze textul simplu dacă are sens, deoarece acestea nu sunt o problemă decât dacă cineva are control deplin și poate citi și scrie textele clare în ambele sensuri ale fluxului. Singurul motiv pentru care criptarea este folosită este din cauza încercărilor anterioare MITM prin inginerie socială care nu au cauzat niciodată vreun rău real.
0
Răspunde
Puncte:2
Maarten Bodewes avatar Crypto
drapel in
Maarten Bodewes

Dacă cheia și IV sunt identice, atunci prima valoare intermediară după criptarea bloc care este XOR cu primul octet este, de asemenea, identică între două operațiuni de criptare.Asta înseamnă că, dacă primul octet al textului simplu este identic, atunci acest lucru va avea ca rezultat un text cifrat identic, scurgând informații unui posibil atacator.

Desigur, acest text cifrat este propagat și în registrul de deplasare care deține în prezent IV. Un octet al IV-ului este deplasat spre stânga (MSB), iar octetul de text cifrat este plasat la dreapta (LSB). Deci, acum următoarea criptare va avea ca rezultat din nou o valoare intermediară identică. Aceasta înseamnă că următorul octet identic de text clar va scurge, de asemenea, direct date și așa mai departe și așa mai departe. Desigur, dacă aveți multe mesaje atunci puteți face multe perechi, astfel încât scurgerea datelor este mai probabilă.

Numai dacă octeții de text simplu diferă între mesaje, atunci propagarea se oprește. Cu toate acestea, acești octeți finali formează o problemă în sine. Textele clare diferite au fost XOR cu valori intermediare identice pentru a crea octeții de text cifrat. Aceasta înseamnă că XOR al octeților de text cifrat are ca rezultat XOR al octeților de text simplu. Acest lucru poate scurge direct date și, din nou, cu cât se cunosc mai mulți octeți de text cifrat, cu atât se pot face mai multe combinații.

Pe partea bună: IV-ul stocat în registrul de deplasare. Deoarece este folosit doar ca intrare în cifrul bloc, este probabil ca valoarea IV și, prin urmare, cheie să fie relativ bine protejată.

Dacă sunt posibile atacuri de canal lateral de nivel scăzut, atunci Mai va fi posibil să identificați niște biți cheie în timpul operațiunii de schimbare, dar probabil că veți avea nevoie de o mulțime de operațiuni înainte de a putea extrage orice date IV/cheie. Deoarece am fost surprins de atacurile pe canale laterale înainte, cred că ar trebui să fie luat în considerare.

Nu numai că nu ar trebui să utilizați datele cheie ca IV (folosirea unui hash peste IV ar fi fost deja mai bine), dar nici nu ar trebui să reutilizați cheia în scopuri diferite.

Aș fi foarte sceptic cu privire la securitatea protocolului pe care l-ați descris din cauza acestor practici criptografice proaste - deși utilizarea modului CFB-8 este probabil deja un indiciu suficient că designerii protocolului nu știau ce făceau.

0 + 0
Maarten Bodewes avatar
drapel in
Maarten Bodewes
Cu alte cuvinte: ?REFECTĂ DE LA START...
0
Răspunde
Puncte:-1
SAI Peregrinus avatar Crypto
drapel si
SAI Peregrinus

Nu, acest lucru nu este sigur. IV-ul este trimis necriptat.Deoarece IV este folosit și ca cheie, aceasta este în esență aceeași cu trimiterea de date necriptate. Ar putea opri un atacator ocazional, dar nu va opri pe nimeni hotărât.

De asemenea, se pare că ați putea reutiliza același IV pentru mai multe mesaje. Acest lucru anulează pretențiile de securitate ale CFB, chiar dacă au fost ținute secrete. Poate doriți un mod rezistent la utilizare greșită, cum ar fi AES-GCM-SIV, dacă nu puteți garanta un nou IV pentru fiecare mesaj.

0 + 0
drapel in
katoriw701
IV-ul nu este niciodată trimis, IV-ul este același cu cheia, cu excepția cazului în care acesta este un detaliu de implementare a AES-CFB, care include IV-ul în textul cifrat, dar mă îndoiesc de asta. „De asemenea, se pare că ați putea reutiliza același IV pentru mai multe mesaje.Acest lucru anulează pretențiile de securitate ale CFB, chiar dacă au fost ținute secrete.” Aceasta este explicația despre care vreau să știu mai multe și cum se descompune? Sunt mai interesat de ce este rău, mai degrabă decât este rău, deoarece sunt conștient de reutilizarea IV și IV ca cheie (IV nu este niciodată generat aleatoriu per mesaj sau trimis).
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.