Când aud cuvântul „criptografie”, unii își amintesc de parola WiFi, de lacătul verde de lângă adresa site-ului lor preferat și de cât de greu e să accesezi emailul altcuiva. Alții își aduc aminte de seria de vulnerabilități din ultimii ani cu acronime sugestive (DROWN, FREAK, POODLE…), sigle stilizate și avertismentul de a-și actualiza urgent browserul.

Criptografia acoperă totul asta, dar esența constă în altceva. Esența este o linie fină între simplu și complex. Unele lucruri sunt ușor de făcut, dar greu de reparat: de exemplu, a sparge un ou. Alte lucruri sunt ușor de realizat, dar greu de corectat când lipsește o mică parte crucială: de exemplu, a deschide o ușă încuiată când „partea decisivă” este cheia. Criptografia studiază aceste situații și modalitățile de utilizare practică a acestora.

În ultimii ani, colecția de atacuri criptografice s-a transformat într-un zoologic de sigle stridente, pline de formule științifice, și a generat o senzație generală sumbră că totul este stricat. Dar, de fapt, multe dintre atacuri se bazează pe câteva principii comune, iar paginile nesfârșite de formule se reduc adesea la idei simple și ușor de înțeles.

În această serie de articole, vom examina diferite tipuri de atacuri criptografice, punând accent pe principiile de bază. În linii mari și nu neapărat în această ordine, dar vom aborda următoarele subiecte:

• Strategii de bază: atacuri prin forță brută, analiză de frecvență, interpolare, reducere și cross-protocol.
• Vulnerabilități „de marcă”: FREAK, CRIME, POODLE, DROWN, Logjam.
• Strategii avansate: atacuri oracle (atacul Wasserstein, atacul Kelsey); metoda întâlnirii la mijloc (meet-in-the-middle), atacul „zi de naștere”, bias statistic (analiză diferențială a criptografiei, analiză integrată a criptografiei etc.).
• Atacuri prin canal lateral și rudele lor apropiate, metode de analiză a defectelor.
• Atacuri asupra criptografiei cu cheie publică: rădăcina cubică, difuzare, mesaj legat, atacul Coppersmith, algoritmul Pollard – Hellman, sita numerică, atacul Wiener, atacul Bleichenbacher.

Acest articol specific acoperă materialul menționat mai sus până la atacul Kelsey.

Strategii de bază

Următoarele atacuri sunt simple în sensul că pot fi explicate practic complet fără detalii tehnice semnificative. Vom explica fiecare tip de atac în termeni foarte simpli, fără a ne adânci în exemple complexe sau variante extinse de utilizare.

Unele dintre aceste atacuri au devenit în mare parte depășite și nu au fost aplicate de mulți ani. Altele sunt veterane, continuând să apară periodic pentru dezvoltatorii de criptosisteme neavizați în secolul 21. Se poate considera că era criptografiei moderne a început odată cu apariția IBM DES — primul algoritm care a rezistat tuturor atacurilor din această listă.

Forțarea brută simplă

Schema de criptare constă din două părți: 1) o funcție de criptare care preia un mesaj (textul în clar) împreună cu o cheie, generând apoi un mesaj criptat — textul criptat; 2) o funcție de decriptare care preia textul criptat și cheia, generând textul în clar. Atât criptarea, cât și decriptarea trebuie să fie ușor de calculat cu cheia — și greu fără ea.

Să presupunem că vedem textul criptat și încercăm să-l decriptăm fără informații suplimentare (aceasta se numește atac "doar text criptat"). Dacă cumva găsim cheia corectă, atunci putem verifica cu ușurință că este într-adevăr corectă, dacă rezultatul este un mesaj rezonabil.

Rețineți că aici există două presupuneri implicite. În primul rând, că știm cum să efectuăm decriptarea, adică, cum funcționează criptosistemul. Aceasta este o presupunere standard în discuțiile despre criptografie. Ascunderea detaliilor de implementare a algoritmului de atacatori poate părea o măsură suplimentară de securitate, dar odată ce un atacator află aceste detalii, această securitate suplimentară este pierdută discret și irevocabil. Așa este principiul lui Kerckhoffs: sistemul nu ar trebui să cauzeze neplăceri în mâinile dușmanului.

În al doilea rând, presupunem că cheia corectă este singura cheie care va duce la o decriptare rezonabilă. Aceasta este de asemenea o presupunere rezonabilă; ea se îndeplinește dacă textul criptat este mult mai lung decât cheia și este bine citibil. În general, așa este în lumea reală, cu excepția cheilor enorm de nepractice sau altor manevre care este mai bine să fie lăsate deoparte (dacă nu vă place că am tăcut explicațiile, vă rugăm să consultați teorema 3.8) aici).

Având în vedere cele de mai sus, se conturează o strategie: a verifica fiecare cheie posibilă. Aceasta se numește atac prin forță brută, iar un astfel de atac funcționează garantat împotriva tuturor criptărilor practice - în cele din urmă. De exemplu, un atac prin forță brută este suficient pentru a sparge criptarea lui Cezar, o criptare antică, unde cheia este o literă din alfabet, ceea ce înseamnă puțin peste 20 de chei posibile.

Din păcate pentru criptanaliști, creșterea dimensiunii cheii protejează bine împotriva forței brute. Pe măsură ce dimensiunea cheii crește, numărul de chei posibile crește exponențial. Cu dimensiunile actuale ale cheii, o simplă forță brută nu mai este practic fezabilă. Pentru a înțelege la ce ne referim, să luăm cel mai rapid supercomputer cunoscut din mijlocul anului 2019: Summit de la IBM, cu o performanță de vârf de aproximativ 10^17 operații pe secundă. Astăzi, lungimea tipică a cheii este de 128 de biți, ceea ce înseamnă 2^128 combinații posibile. Pentru a încerca toate cheile, supercomputerul Summit ar avea nevoie de un timp care este de aproximativ 7800 de ori mai mare decât vârsta Universului.

Trebuie să considerăm forța brută un curiozitate istorică? Deloc: este un ingredient necesar în cartea de bucate a criptanalizei. Rareori întâlnești criptări atât de slabe încât să poată fi sparte doar cu o atacă inteligentă, fără a aplica forța într-o formă sau alta. Multe spargeri de succes folosesc mai întâi o metodă algoritmică pentru a slăbi criptarea țintă, apoi încep atacul prin forță brută.

Analiza frecvenței

Cele mai multe texte nu sunt gibberish. De exemplu, în texte în limba engleză există multe litere 'e' și articole 'the'; în fișiere binare - mulți biți zero ca umplutură între fragmentele de informație. Analiza frecvenței - orice atac care folosește acest fapt.

Un exemplu canonically al unei criptări vulnerabile la acest atac este simpla criptare prin substituție. În această criptare, cheia este un tabel de înlocuire a tuturor literelor. De exemplu, 'g' este înlocuit cu 'h', 'o' - cu 'j', prin urmare cuvântul 'go' devine 'hj'. Această criptare este greu de spart prin forță brută simplă, deoarece există foarte multe tabeluri de substituție posibile. Dacă te interesează matematica, lungimea eficientă a cheii este de aproximativ 88 de biți: aceasta
. Dar analiza frecvenței reușește de obicei să rezolve rapid această sarcină.

Să luăm în considerare următorul text criptat, procesat printr-un simplu cifru de substituție:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Deoarece Y se întâlnește frecvent, inclusiv la sfârșitul multor cuvinte, putem presupune preliminar că aceasta este litera e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

O pereche XD se repetă la începutul mai multor cuvinte. În special, combinația XDeLe sugerează clar cuvântul these sau there, așadar continuăm:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Apoi presupunem că L corespunde r, A — a și așa mai departe. Probabil va fi necesar să facem câteva încercări, dar comparativ cu atacul brut forțat, această atacă restaurează textul original într-un timp scurt:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Pentru unii, soluționarea acestor «criptograme» este un hobby fascinant.

Ideea analizei frecvenței este mai fundamentală decât pare la prima vedere. Și este aplicabilă unor cifre mult mai complexe. De-a lungul istoriei, diferite construcții de cifre au încercat să reziste acestui tip de atac prin „substituție polialfabetică”. Aici, în procesul de criptare, tabela de substituție a literelor se modifică în moduri complexe, dar previzibile, care depind de cheie. Toate aceste cifre au fost, la vremea lor, considerate greu de spart; și totuși, modestul analizator de frecvențe le-a depășit pe toate.

Cel mai ambițios cifru polialfabetic din istorie și probabil cel mai cunoscut a fost cifrul „Enigma” în timpul celui de-al Doilea Război Mondial. Acesta a fost relativ complex în comparație cu predecesorii săi, dar în urma unei munci îndelungate și insistente, criptanalistii britanici l-au spart cu ajutorul analizei frecvenței. Desigur, ei nu au reușit să dezvolte un atac elegant, așa cum este cel prezentat mai sus; a trebuit să compare perechi cunoscute de texte clare și criptate (așa-numita „atac asupra textului clar”) și chiar să provoace utilizatorii „Enigmei” să cripteze mesaje specifice pentru a analiza rezultatul („atac pe baza textului clar desfășurat”). Dar aceasta nu a ușurat soarta armadelor învinselor dușmane și a submarinelor scufundate.

După această triumf, analiza frecvenței a dispărut din istoria criptoanalizei. Cifrele din era digitală modernă sunt create pentru a lucra cu biți, nu cu litere. Ceva și mai important, aceste cifre sunt concepute cu conștientizarea sumbră a ceea ce ulterior a devenit cunoscut ca legea lui Schneier: oricine poate crea un algoritm de criptare pe care nu se poate descurca singur. Nu este suficient ca sistemul de criptare să pară complex: pentru a dovedi valoarea sa, acesta trebuie să treacă printr-o revizuire brutală de securitate din partea multor criptoanaliști care vor face tot posibilul pentru a sparge cifra.

Calculurile preliminare

Să luăm orașul ipotetic Precum Heights, cu o populație de 200.000 de oameni. În fiecare casă din oraș se află bunuri valoroase în medie de 30.000 de dolari, dar nu mai mult de 50.000 de dolari. Piața de securitate din Precum este monopolizată de compania ACME Industries, care produce celebrele încuietori de uși de clasa Coyote ™. Conform analizei experților, pentru a sparge o încuietoare de clasa Coyote este nevoie de o mașină ipotetică foarte complicată, a cărei construire necesită aproximativ cinci ani și 50.000 de dolari investiți. Este orașul în siguranță?

Probabil că nu. La urma urmei, va apărea un criminal suficient de ambițios. El va raționa astfel: „Da, voi suporta cheltuieli inițiale mari. Cinci ani de așteptare răbdătoare și 50.000 de dolari. Dar la sfârșitul lucrării, voi avea acces la toată bogăția acestui oraș. Dacă îmi joc corect cărțile, atunci această investiție se va răsplăti de multe ori.”

Similară este și situația în criptografie. Atacurile împotriva unui anumit cifru sunt supuse unei analize necruțătoare a costurilor și beneficiilor. Dacă raportul este favorabil, atacul nu va avea loc. Dar atacurile care vizează simultan multe victime potențiale aproape întotdeauna se dovedesc rentabile, iar în acest caz, cea mai bună practică de proiectare este să ne asumăm că acestea au început din prima zi. Avem, practic, o versiune criptografică a legii lui Murphy: „Tot ce poate sparge cu adevărat sistemul, va sparge sistemul.”

Cel mai simplu exemplu de sistem criptografic vulnerabil la atacurile cu calcule preliminare este cifra cu algoritm fix fără utilizarea unei chei. Așa a fost în cazul cifrei lui Cezar, care doar mută fiecare literă a alfabetului cu trei litere înainte (tabelul este circular, astfel că ultima literă din alfabet este criptată cu a treia). Aici se reiterează principiul lui Kerckhoffs: imediat ce sistemul este spart, acesta este spart pentru totdeauna.

Conceptul este simplu. Chiar și un dezvoltator novice de sisteme criptografice va înțelege probabil amenințarea și se va pregăti în consecință. Dacă ne uităm la evoluția criptografiei, astfel de atacuri erau detestabile pentru majoritatea cifrelor, începând cu primele versiuni îmbunătățite ale cifrului lui Cezar și până la declinul cifrelor poli-alphabetice. Aceste atacuri și-au revenit doar odată cu venirea epocii moderne a criptografiei.

Această revenire este cauzată de doi factori. În primul rând, au apărut în sfârșit sisteme criptografice suficient de complexe în care posibilitatea exploatării după o breșă nu era atât de evidentă. În al doilea rând, criptografia a devenit atât de răspândită încât milioane de neprofesioniști luau decizii zilnic despre unde și ce părți ale criptografiei să folosească din nou. A durat ceva timp până când experții au realizat riscurile emergente și au tras alarma.

Rețineți atacul prin calcul prealabil: la sfârșitul articolului vom analiza două exemple criptografice din viața reală în care acesta a jucat un rol important.

Interpolare

În fața voastră este celebrul detectiv Sherlock Holmes, care realizează un atac prin interpolare asupra nefericitului doctor Watson:

Am intuit imediat că ați venit din Afganistan… Gândul meu a fost următorul: „Acest om este tipul de medic, dar are un aspect militar. Deci, este medic militar. Tocmai s-a întors din tropice - are un ten închis, dar acesta nu este nuanța naturală a pielii sale, deoarece încheieturile îi sunt mult mai deschise. Fața este obosită - evident, a suferit mult și a trecut printr-o boală. A fost rănit la mâna stângă - o menține nemișcată și puțin nenatural. Unde ar fi putut un doctor militar englez să sufere de privări și să primească o rană în tropice? Desigur, în Afganistan.” Întregul parcurs al gândurilor nu a durat mai mult de o secundă. Și am spus că ați venit din Afganistan, și ați fost surprins.

Din fiecare stup în parte, Holmes putea extrage foarte puține informații. El putea ajunge la concluzia sa doar examinându-le pe toate împreună. La fel funcționează atacul prin interpolare, investigând perechi cunoscute de text clar și text criptat, obținute prin aplicarea aceleași chei. Din fiecare pereche se extrag observații separate care permit formularea unei concluzii generale despre cheie. Toate aceste raționamente sunt vagi și par inutile, până când nu ajung brusc la o masă critică și conduc la o concluzie unică posibilă: oricât de incredibil ar fi, acesta trebuie să fie adevărat. După aceea, fie se dezvăluie cheia, fie procesul de decriptare devine atât de bine definit încât poate fi replicat.

Să ilustrăm cu un exemplu simplu cum funcționează interpolarea. Să presupunem că vrem să citim jurnalul personal al dușmanului nostru, Bob. El criptează fiecare număr din jurnalul său folosind un sistem criptografic simplu, pe care l-a aflat dintr-o reclamă în revista „Râsul criptografiei”. Sistemul funcționează în felul următor: Bob alege două numere care îi plac: și . De acum înainte, pentru a cripta orice număr , el calculează . De exemplu, dacă Bob a ales și , atunci cifra va fi criptată ca .

Să presupunem că pe 28 decembrie am observat că Bob scrie ceva în jurnalul său. Când termină, vom lua discret jurnalul său și să privim ultima înregistrare:

Data: 235/520

Dragă jurnal,

Astăzi a fost o zi bună. În 64 zile am o întâlnire cu Alice, care locuiește în apartamentul 843. Chiar cred că ea ar putea fi 26!

Deoarece suntem foarte hotărâți să-l urmărim pe Bob la întâlnirea lui (în acest scenariu avem 15 ani), este esențial să aflăm data, precum și adresa lui Alice. Din fericire, observăm că sistemul criptografic al lui Bob este vulnerabil la atacuri prin interpolare. Poate că nu știm și , dar știm data de astăzi, deci avem două perechi de „text clar - text criptat”. Mai precis, știm că este criptat în , iar — în . Așa că vom nota:

Deoarece avem 15 ani, știm deja despre sistemul de două ecuații cu două necunoscute, ceea ce în această situație este suficient pentru a găsi și fără probleme majore. Fiecare pereche „text deschis - text criptat” impune o restricție asupra cheii lui Bob, iar două restricții împreună sunt suficiente pentru a restaura complet cheia. În exemplul nostru, răspunsul și (la , așa că 26 în jurnal corespunde cu cuvântul ‘cel’ sau ‘cea’, adică ‘aceasta’ - n. trad.)

Atacurile de interpolare, desigur, nu se limitează la astfel de exemple simple. Fiecare criptosistem care se reduce la un obiect matematic bine înțeles și o listă de parametri este expus riscului de atacuri de interpolare - cu cât obiectul este mai clar, cu atât riscul este mai mare.

Începătorii se plâng adesea că criptografia este „arta de a proiecta cele mai urâte lucruri”. Probabil că atacurile de interpolare sunt parțial responsabile pentru aceasta. Bob poate fie să utilizeze un design matematic elegant, fie să păstreze confidențialitatea întâlnirii cu Alice - dar din păcate, de obicei nu poți obține ambele rezultate. Acest lucru va deveni extrem de clar când în cele din urmă vom trece la criptografia cu cheie publică.

Cross-protocol / downgrade

În filmul „Iluzia înșelăciunii” (2013), un grup de iluzioniști încearcă să înșele pentru a obține întreaga avere a coruptului magnat al asigurărilor Arthur Tressler. Pentru a accesa contul bancar al lui Arthur, iluzioniștii trebuie fie să prezinte numele de utilizator și parola lui, fie să-l facă să se prezinte personal la bancă și să participe la plan.

Ambele opțiuni sunt foarte dificile; băieții sunt obișnuiți să performeze pe scenă, nu să participe la operațiuni ale agențiilor de securitate. Prin urmare, ei aleg a treia opțiune posibilă: asociatul lor sună la bancă și se dă drept Arthur. Banca pune câteva întrebări pentru a verifica identitatea, cum ar fi numele unchiului și numele primului animal de companie; eroii noștri recuperează ușor aceste informații de la Arthur printr-o ingenioasă inginerie socială. De la acest moment, securitatea excelentă a parolei nu mai contează.

(Conform unei legende urbane, pe care am verificat-o personal, criptograful Eli Biham a avut odată de-a face cu un casier de bancă care insista asupra stabilirii unei întrebări secrete. Când casierul a întrebat numele bunicii pe linie maternă, Biham a început să dicteze: „X mare, y mică, trei…”).

De asemenea, în criptografie, dacă pentru protejarea aceleași active se utilizează simultan două protocoale criptografice, dintre care unul este mult mai slab decât celălalt. Sistemul final devine vulnerabil la un atac între protocoale, în care este atacat protocolul mai slab pentru a ajunge la premiu, fără a atinge protocolul mai puternic.

În unele cazuri complexe, nu este suficient doar să te conectezi la server printr-un protocol mai slab, ci este necesară participarea involuntară a clientului legitim. Acest lucru poate fi organizat prin așa-numita atac de degradare (downgrade). Pentru a înțelege acest atac, să presupunem că magicianii noștri au o sarcină mai complexă decât în film. Să presupunem că angajatul băncii (casierul) și Arthur s-au confruntat cu anumite circumstanțe neprevăzute, rezultând un dialog de genul:

Hacker: Alo? Este Arthur Tressler. Aș dori să-mi recuperez parola.

Casierul: Perfect. Te rog, uită-te în cartea ta personală de coduri secrete, pagina 28, cuvântul 3. Toate mesajele următoare vor fi criptate folosind acest cuvânt specific ca și cheie. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Hacker: Hei, hei, așteaptă, așteaptă. Este chiar necesar? Nu putem pur și simplu să vorbim ca oamenii normali?

Casierul: Nu recomand să faci asta.

Hacker: Eu doar… ascultă, am avut o zi proastă, înțelegi? Sunt un client VIP și nu am dispoziția necesară să mă tot învârt în aceste cărți stupide de coduri.

Casierul: Bine. Dacă insiști, domnul Tressler. Ce poți dori?

Hacker: Te rog, aș dori să transfer toate banii mei în Fondul Național pentru Victimele lui Arthur Tressler.

(Pauză).

Casierul: Așadar, înțeleg. Te rog, indică PIN-ul tău pentru tranzacții mari.

Hacker: Ce?

Casierul: La cererea ta personală, tranzacțiile de această dimensiune necesită introducerea unui PIN pentru tranzacții mari. Acest cod ți-a fost dat la deschiderea contului.

Hacker:… L-am pierdut. Este chiar necesar? Nu poți doar să aprobi tranzacția?

Casierul: Nu. Îmi pare rău, domnul Tressler. Din nou, aceasta este o măsură de securitate pe care ai cerut-o. Dacă dorești, putem trimite un nou PIN la căsuța ta poștală.

Eroii noștri amână operațiunea. Ei ascultă câteva tranzacții mari ale lui Tressler, sperând să audă codul PIN; dar de fiecare dată conversația se transformă într-un amestec criptat, înainte de a auzi ceva interesant. În sfârșit, într-o zi frumoasă pun planul în aplicare. Ei așteaptă cu răbdare momentul în care Tressler trebuie să facă o tranzacție mare prin telefon, se conectează la linie, iar apoi…

Tressler: Bună ziua. Aș dori să efectuez o tranzacție de la distanță, vă rog.

Casierul: Excelent. Vă rog, consultați-vă cartea personală de coduri secrete, pagina…

(Hackerul apasă butonul; vocea casei de marcat se transformă într-un zgomot indistinct).

Casierul: — #@$#@$#*@$$@#* va fi criptat cu acest cuvânt ca și cheie. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Îmi pare rău, nu am înțeles foarte bine. Încă o dată? Pe ce pagină? Ce cuvânt?

Casierul: Este pagina @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Ce?

Casierul: Cuvântul numărul douzeci @$#@$#%#$.

Tressler: Serios! Destul! Protocolul tău de securitate e un fel de circ. Știu că poți pur și simplu să vorbești normal cu mine.

Casierul: Nu îți recomand…

Tressler: Dar eu nu îți recomand să-mi pierzi timpul. Nu vreau să mai aud despre asta până când nu rezolvați problemele cu linia voastră telefonică. Putem să facem afacerea asta sau nu?

Casierul:… da. Bine. Ce doriți?

Tressler: Aș dori să transfer 20.000 de dolari către compania Lord Business Investments, numărul contului…

Casierul: Un moment, vă rog. Este o afacere mare. Vă rog, indicați-vă codul PIN pentru tranzacții mari.

Tressler: Ce? Ah, da. 1234.

Iată un atac la reducere. Protocolul mai slab de „vorbește direct” a fost gândit ca opțiune de rezervă. Și totuși, suntem aici.

Poți pune întrebarea, cine în mintea sănătoasă ar proiecta un sistem real de tip „sigur, până când se cere contrar”, așa cum este descris mai sus. Dar la fel cum banca fictivă își asumă riscuri pentru a păstra clienții care nu iubesc criptografia, sistemele în general tind adesea spre cerințe care sunt indiferente sau chiar ostile securității.

O astfel de poveste s-a întâmplat cu protocolul SSLv2 în 1995. Guvernul SUA a început de mult să considere criptografia ca pe o armă, pe care este mai bine să o păstrezi departe de dușmanii externi și interni. Fragmentele de cod erau aprobate pentru export din SUA, adesea cu condiția de a slăbi intenționat algoritmul. Compania Netscape, dezvoltatorul celui mai popular browser Netscape Navigator, a primit permisiunea pentru SSLv2 doar cu o cheie RSA de 512 biți (și 40 biți pentru RC4) inițial vulnerabilă.

Până la sfârșitul mileniului, regulile s-au mai îmblânzit, iar accesul la criptarea modernă a devenit pe scară largă disponibil. Cu toate acestea, clienții și serverele au menținut timp de mulți ani criptografia slăbită «de export» din cauza aceleași inerții care păstrează suportul pentru orice sistem învechit. Clienții credeau că pot întâlni un server care să nu suporte altceva. Serverele făceau la fel. Firesc, protocolul SSL dictase că clienții și serverele nu ar trebui niciodată să folosească un protocol slab atunci când este disponibil unul mai bun. Dar aceeași premisă a fost valabilă pentru Tressler și banca sa.

Această teorie a fost aplicată în două atacuri celebre, care, unul după altul, au zguduit securitatea protocolului SSL în 2015, ambele descoperite de cercetătorii Microsoft și INRIA. Inițial, în februarie, au fost divulgate detalii despre atacul FREAK, iar trei luni mai târziu – un alt atac similar numit Logjam, pe care îl vom discuta mai detaliat când vom trece la atacurile asupra criptografiei cu cheie publică.

Vulnerabilitatea FREAK (cunoscută și ca «Smack TLS») a apărut atunci când cercetătorii au analizat implementările client/server TLS și au descoperit o eroare ciudată. În aceste implementări, dacă clientul nu solicită chiar să folosească criptografia slăbită de export, dar serverul răspunde totuși cu astfel de chei – clientul spune «Bine», și trece la un set de cifruri slăbit.

La vremea respectivă, toată lumea considera că criptografia de export era învechită și interzisă, astfel că atacul a fost un adevărat șoc și a afectat multe domenii importante, inclusiv site-urile Casei Albe, agenției fiscale a SUA și NSA. Mai rău, s-a dovedit că multe servere vulnerabile optimizau performanța, reutilizând aceleași chei, fără a genera altele noi pentru fiecare sesiune. Acest lucru a permis, după scăderea protocolului, să aibă loc și un atac cu precomputare: spargerea unei chei rămânea relativ costisitoare (100 USD și 12 ore la momentul publicării), dar costul practic al atacului asupra conexiunii a scăzut semnificativ. Era suficient să găsești o dată cheia serverului - și să spargi criptarea pentru toate conexiunile ulterioare de la acel moment.

Și înainte de a continua, trebuie menționată o atac avansat...

Atacul oracolului

Moxie Marlinspike este cel mai cunoscut ca fiind părintele criptomessenger-ului multiplatformă Signal; dar personal, ne place una dintre inovațiile sale mai puțin cunoscute - principiul doom-ului criptografic (Principiul Doom Criptografic). Reformulând puțin, putem spune așa: „Dacă protocolul execută orice operațiune criptografică asupra unui mesaj dintr-o sursă potențial dăunătoare și se comportă diferit în funcție de rezultat, acesta esteSORTIT eșecului.” Sau într-o formă mai drastică: „Nu lua de la dușman informații pentru procesare, iar dacă ai fost nevoit, atunci cel puțin nu arăta rezultatul.”

Să lăsăm deoparte suprasarcinile, injecțiile de comenzi și așa mai departe; acestea depășesc cadrul acestei discuții. Încălcarea „principiului doom-ului” duce la spargeri grave de criptografie, deoarece protocolul se comportă exact așa cum este de așteptat.

De exemplu, să luăm o construcție fictivă cu un cifru de substituție vulnerabil, iar apoi să demonstrăm un atac posibil. Deși am văzut deja un atac asupra cifrului de substituție prin analiza frecvenței, acesta nu este doar „o altă modalitate de a sparge același cifru”. Dimpotrivă, atacurile oracolului sunt o invenție mult mai modernă, aplicabilă în numeroase situații în care analiza frecvenței eșuează, și vom vedea o demonstrație a acestui lucru în secțiunea următoare. Aici, un cifru simplu este ales doar pentru a face exemplul mai ușor de înțeles.

Așadar, Alice și Bob comunică printr-un simplu cifru de substituție, folosind o cheie cunoscută doar de ei. Ei sunt foarte stricti cu lungimea mesajelor: aceasta este exact 20 de caractere. Prin urmare, au convenit că, dacă cineva dorește să trimită un mesaj mai scurt, trebuie să adauge un text fals la sfârșitul mesajului, astfel încât acesta să aibă exact 20 de caractere. După ceva discuții, ei au decis că vor accepta doar următoarele texte false: a, bb, ccc, dddd etc. Astfel, textul fals necesar poate fi cunoscut în orice lungime.

Când Alice sau Bob primesc un mesaj, ei verifică mai întâi că mesajul are lungimea corectă (20 de caractere), iar sufixul este un text fals corect. Dacă nu este așa, răspund cu un mesaj corespunzător de eroare. Dacă lungimea textului și textul fals sunt în regulă, destinatarul citeste mesajul și trimite un răspuns criptat.

În timpul atacului, un atacator se dă drept Bob și trimite mesaje false către Alice. Mesajele sunt complet absurde - atacatorul nu are cheia și, prin urmare, nu poate falsifica un mesaj semnificativ. Dar, deoarece protocolul încalcă principiul fatalității, atacatorul poate totuși să o înșele pe Alice astfel încât să dezvăluie informații despre cheie, așa cum se arată mai jos.

Hacker: PREWF ZHJKL MMMN. LA

Alice: Text fals invalid.

Hacker: PREWF ZHJKL MMMN. LB

Alice: Text fals invalid.

Hacker: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Atacatorul nu are idee ce a spus tocmai Alice, dar observă că simbolul C trebuie să corespundă a, deoarece Alice a acceptat textul fals.

Hacker: REWF ZHJKL MMMN. LAA

Alice: Text fals invalid.

Hacker: REWF ZHJKL MMMN. LBB

Alice: Text fals invalid.

După mai multe încercări…

Hacker: REWF ZHJKL MMMN. LGG

Alice: Text fals invalid.

Hacker: REWF ZHJKL MMMN. LHH

Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Din nou, atacatorul nu are idee ce a spus tocmai Alice, dar observă că H ar trebui să se potrivească cu b, deoarece Alice a acceptat textul fals.

Și așa mai departe, până când atacatorul află valoarea fiecărui simbol.

La prima vedere, metoda seamănă cu un atac bazat pe un text clar ales. În cele din urmă, atacatorul alege ciphertext-uri, iar serverul le procesează obedient. Principala diferență care face aceste atacuri viabile în lumea reală este că atacatorului nu îi este necesar accesul la decriptarea efectivă — un răspuns al serverului este suficient, chiar și unul inofensiv, cum ar fi „Textul fictiv incorect”.

Deși acest atac specific este instructiv, nu ar trebui să ne concentrăm prea mult pe specificitatea schemei „textului fictiv”, pe criptosistemul specific utilizat sau pe exactitatea secvenței de mesaje trimise de atacator. Ideea principală constă în modul în care Alice reacționează diferit, bazându-se pe proprietățile textului clar, făcând acest lucru fără a verifica faptul că ciphertext-ul corespunzător a fost de fapt primit de la o parte de încredere. Astfel, Alice permite atacatorului să extragă informații secrete din răspunsurile sale.

În acest scenariu, multe lucruri pot fi schimbate. Simbolurile la care Alice răspunde, sau chiar diferența în comportamentul ei, sau chiar criptosistemul utilizat. Dar principiul va rămâne același, iar atacul va rămâne viabil într-o formă sau alta. Implementarea de bază a acestui atac a ajutat la descoperirea unor erori de securitate, pe care le vom examina în curând; dar mai întâi ar trebui să învățăm câteva lecții teorice. Cum se poate folosi acest „scenariul lui Alice” într-un atac care ar putea funcționa pe un criptaj modern? Este posibil acest lucru, chiar și în teorie?

În 1998, criptograful elvețian Daniel Bleichenbacher a răspuns afirmativ la această întrebare. El a demonstrat un atac de tip oracle asupra unui criptosistem cu cheie publică RSA larg utilizat, folosind o anumită schemă de mesaje. În unele implementări RSA, serverul răspunde cu mesaje diferite de eroare, în funcție de faptul dacă textul clar se conformează schemei sau nu; acest lucru a fost suficient pentru a realiza atacul.

Patru ani mai târziu, în 2002, criptograful francez Serge Vaudenay a demonstrat un atac de tip oracol, aproape identic cu cel descris mai sus în scenariul lui Alice - cu excepția faptului că, în locul unui algoritm fictiv, a spart o întreagă clasă respectabilă de algoritmi moderni de criptare pe care oamenii îi folosesc efectiv. Într-adevăr, atacul lui Vaudenay vizează algoritmii cu dimensiune fixă de intrare ("algoritmi cu blocuri"), atunci când sunt folosiți în aşa-numitul "mod de criptare CBC" și cu o anumită schemă populară de padding, în principal echivalentă cu cea din scenariul lui Alice.

De asemenea, în 2002, criptograful american John Kelsey - coautor Twofish — a propus diferite atacuri de tip oracol asupra sistemelor care comprimă mesajele și apoi le criptează. Cel mai notabil dintre ele a fost atacul care folosea ceea ce se poate deduce frecvent despre lungimea inițială a textului deschis din lungimea textului criptat. În teorie, acest lucru permite realizarea unui atac de tip oracol care recuperează părți ale textului inițial.

Iată o descriere mai detaliată a atacurilor lui Vaudenay și Kelsey (vom oferi o descriere mai amănunțită a atacului lui Bleichenbacher când vom trece la atacurile asupra criptografiei cu cheie publică). În ciuda tuturor eforturilor noastre, textul devine oarecum tehnic; așadar, dacă ceea ce s-a spus până acum este suficient pentru tine, poți sări peste următoarele două secțiuni.

Atacul lui Vaudenay

Pentru a înțelege atacul lui Vaudenay, trebuie întâi să discutăm puțin mai în detaliu despre algoritmii cu blocuri și modurile de criptare. "Algoritmul cu blocuri" este, așa cum s-a menționat, un algoritm care primește o cheie și o intrare de o anumită lungime fixă ("lungimea blocului") și produce un bloc criptat de aceeași lungime. Algoritmii cu blocuri sunt utilizați pe scară largă și sunt considerați relativ siguri. Fostul algoritm DES, considerat primul algoritm modern de criptare, a fost un algoritm cu blocuri. Așa cum s-a menționat mai sus, același lucru este valabil și pentru AES, utilizat pe scară largă astăzi.

Din păcate, cifrurile pe blocuri au o slăbiciune flagrantă. Dimensiunea tipică a unui bloc este de 128 de biți, sau 16 caractere. Este evident că criptografia modernă necesită lucrul cu date de intrare de dimensiuni mai mari, iar aici apar modurile de criptare. Modul de criptare este, în esență, un hack: este un mod de a aplica un cifru pe blocuri, care acceptă date de intrare doar de o anumită dimensiune, la date de intrare de lungime arbitrară.

Atacul Wodena se concentrează pe modul popular CBC (Cipher Block Chaining, modul de legare a blocurilor de text criptat). Atacul consideră cifrul pe blocuri de bază ca fiind o cutie neagră magică de neegalat și ocolește complet securitatea acestuia.

Iată un grafic care arată cum funcționează modul CBC:

Plusul încercuit reprezintă operația XOR (exclusive OR). De exemplu, al doilea bloc de text criptat a fost obținut:

1. Prin efectuarea operației XOR pe al doilea bloc de text deschis cu primul bloc de text criptat.
2. Criptând blocul obținut folosind cifrul pe blocuri, aplicând cheia.

Deoarece CBC folosește intens operația binară XOR, haideți să profităm de ocazie pentru a ne aminti câteva dintre proprietățile sale:

• Idempotentă:
• Comutativitate:
• Asociativitate:
• Auto-inversabilitate:
• Pe byte: byte n din = (byte n din ) (byte n din )

În general, aceste proprietăți implică faptul că, dacă avem o ecuație care include operații XOR și o necunoscută, aceasta poate fi rezolvată. De exemplu, dacă știm că cu necunoscuta și cunoscutele și , atunci ne putem baza pe proprietățile menționate mai sus pentru a rezolva ecuația pentru . Aplicând XOR pe ambele părți ale ecuației cu , obținem . În curând, toate acestea vor deveni foarte relevante.

Între scenariul nostru cu Alice și atacul Wodena există două diferențe nesemnificative și o diferență principală. Două nesemnificative:

• În scenariul lui Alice, se aștepta ca textele deschise să se termine cu caracterele a, bb, ccc și așa mai departe. În atacul Wodena, victima, în schimb, se așteaptă ca textele deschise să se termine cu N de byte N (adică hexazecimal 01 sau 02 02, sau 03 03 03 și așa mai departe). Aceasta este o diferență pur cosmetică.
• În scenariul Alinei, era ușor de spus dacă Alina a primit mesajul, pe baza răspunsului „Text fals incorect”. Atacul Vodene necesită o analiză mai profundă, iar implementarea precisă pe partea victimei este crucială; dar pentru a simplifica, să presupunem că această analiză este totuși posibilă.

Diferența principală:

• Deoarece nu folosim același sistem criptografic, legătura între octeții de text criptat controlați de atacatori și secrete (cheia și textul în clar) va fi evident diferită. Prin urmare, atacatorul va trebui să folosească o altă strategie în generarea textelor criptate și interpretarea răspunsurilor serverului.

Aceasta este principala diferență — ultimul fragment al puzzle-ului pentru a înțelege atacul Vodene, așa că să ne gândim pentru un moment la motivul și modul în care ar putea fi organizat un atac oracle asupra CBC.

Să presupunem că avem un text criptat CBC din 247 blocuri și dorim să-l decriptăm. Putem trimite mesaje false către server, așa cum înainte trimiteam mesaje false Alinei. Serverul va decripta mesajele pentru noi, dar nu va arăta decriptarea — în schimb, din nou, ca și în cazul Alinei, serverul va comunica doar un bit de informație: dacă textul în clar are umplere validă sau nu.

Rețineți că în scenariul Alinei aveam următoarele relații:

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = text{plaintext}$$display$$

Să numim aceasta „ecuația Alinei”. Noi controlam textul criptat; serverul (Alina) ne oferea informații neclare despre textul în clar primit; și acest lucru ne-a permis să deducem informații despre ultimul factor — cheia. Prin analogie, dacă putem găsi o astfel de legătură pentru scenariul CBC, atunci am putea extrage unele informații secrete și acolo.

Din fericire, există, de fapt, relații pe care le putem folosi. Să examinăm ieșirea ultimei apel de decriptare a unui algoritm de criptare cu blocuri și să denumim aceste date ca . De asemenea, să denumim blocurile de text în clar și blocurile de text criptat . Privind din nou la diagrama CBC, observăm că se formează:

Să numim aceasta „ecuația CBC”.

În scenariul lui Alice, controlând textul criptat și observând scurgerile de informații despre textul deschis corespunzător, am reușit să organizăm un atac care a recuperat al treilea membru al ecuației – cheia. În scenariul CBC, de asemenea, controlăm textul criptat și observăm scurgeri de informații referitoare la textul deschis corespunzător. Dacă analogia este valabilă, vom putea obține informații despre .

Să presupunem că am recuperat cu adevărat , ce facem atunci? Ei bine, atunci putem să scos imediat ultimul bloc de text deschis (), introducând pur și simplu (pe care îl avem) și
obținut în ecuația CBC.

Așadar, avem o mentalitate optimistă în privința planului general de atac și acum este timpul să lucrăm la detalii. Observăm exact cum are loc scurgerea informațiilor despre textul deschis pe server. În scenariul lui Alice, scurgerea a avut loc deoarece Alice a răspuns cu mesajul corect doar dacă $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ se încheia cu șirul a (sau bb, și așa mai departe, dar șansele ca aceste condiții să se activeze întâmplător erau foarte mici). Similar cu CBC, serverul acceptă umplerea dacă și numai dacă se încheie cu hexazecimalul 01. Așadar, să încercăm aceeași trucă: să trimitem texte criptate false cu propriile noastre valori false , până când serverul acceptă umplerea.

Când serverul acceptă umplerea pentru unul dintre mesajele noastre false, asta înseamnă că:

Acum folosim proprietatea XOR pe byte-uri:

Știm primul și al treilea membru. Și am văzut deja că acest lucru permite recuperarea membrului rămas – ultimul byte din :

Acest lucru ne oferă de asemenea ultimul byte al blocului final de text deschis prin ecuația CBC și proprietatea pe byte-uri.

Am putea termina aici și ne-am putea mulțumi cu faptul că am realizat un atac asupra unei cifrări teoretic rezistente. Dar, de fapt, putem face mult mai mult: putem recupera cu adevărat tot textul. Aceasta necesită un anumit truc care nu a fost prezent în scenariul original al lui Alice și nu face parte din condițiile necesare pentru atacul oracolului, dar metoda merită totuși studiată.

Pentru a o înțelege, mai întâi observați că, ca rezultat al deducerii valorii corecte a ultimului byte Am avut o nouă capacitate. Acum, când falsificăm textul criptat, putem controla ultimul byte al textului deschis corespunzător. Din nou, acest lucru este legat de ecuația CBC și de proprietatea pe byte:

Deoarece acum știm al doilea termen, putem folosi controlul nostru asupra primului pentru a controla al treilea. Pur și simplu calculăm:

Înainte, nu puteam face acest lucru, pentru că nu aveam încă ultimul byte .

Cum ne va ajuta acest lucru? Să presupunem că acum vom genera toate texturile criptate astfel încât în textele deschise corespunzătoare ultimul byte să fie 02. Acum serverul acceptă umplerea doar dacă textul deschis se termină cu 02 02. Deoarece am corectat ultimul byte, acest lucru se va întâmpla doar dacă penultimul byte al textului deschis este, de asemenea, egal cu 02. Continuăm să trimitem blocuri de text criptat falsificate, modificând penultimul byte, până când serverul acceptă umplerea pentru unul dintre ele. În acest moment, obținem:

Și restaurăm penultimul byte exact așa cum am restaurat ultimul. Continuăm în aceeași idee: corectăm ultimele două bytes ale textului deschis la 03 03, repetăm acest atac pentru al treilea byte de la sfârșit și așa mai departe, în final restaurând complet .

Ce este cu restul textului? Rețineți că valoarea este, de fapt, $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Putem pune orice alt bloc în loc de , iar atacul va fi totuși de succes. De fapt, putem cere serverului să efectueze $inline$text{BLOCK_DECRYPT}$inline$ pentru orice date. În acest moment, jocul s-a terminat - putem decripta orice text criptat (uitați-vă din nou la diagrama de decriptare CBC pentru a verifica acest lucru; și rețineți că vectorul IV este public).

Această metodă specifică joacă un rol crucial în atacul oracolului, cu care ne vom confrunta mai târziu.

Atacul Kelsey

John Kelsey, care ne este apropiat în spirit, a expus principiile care stau la baza multor atacuri posibile, nu doar detalii specifice despre un atac specific asupra unui anumit algoritm. Articolul său din 2002 este o cercetare asupra atacurilor posibile asupra datelor criptate comprimate. Credeai că pentru a efectua un atac nu este suficientă informația că datele au fost comprimate înainte de criptare? Se pare că este suficient.

Acest rezultat uimitor se datorează două principii. În primul rând, există o corelație puternică între lungimea textului deschis și lungimea textului criptat; pentru multe cifre, egalitatea exactă. În al doilea rând, atunci când se face comprimarea, există de asemenea o corelație puternică între lungimea mesajului comprimat și gradul de „zgomot” al textului deschis, adică proporția caracterelor unice (termen tehnic - „entropie mare”).

Pentru a observa principiul în acțiune, să considerăm două texte deschise:

Text deschis 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Text deschis 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Presupunem că ambele texte deschise sunt comprimate și apoi criptate. Obțineți două texte criptate rezultate și trebuie să ghiciți care text criptat corespunde cărui text deschis:

Text criptat 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Text criptat 2: DWKJZXYU

Răspunsul este clar. Dintre texte deschise, doar textul deschis 1 ar fi putut fi comprimat la lungimea scurtă a celui de-al doilea text criptat. Am dedus acest lucru, fără a ști nimic despre algoritmul de comprimare, cheia de criptare sau chiar despre cifra în sine. Comparativ cu ierarhia atacurilor criptografice posibile, este un fel de nebunie.

Kelsey mai indică faptul că, în circumstanțe neobișnuite, acest principiu poate fi folosit și pentru a efectua un atac al oracolului. În special, el descrie cum un atacator poate recupera textul deschis secret dacă poate forța serverul să cripteze datele din formular (text deschis urmat de , în timp ce controlează și poate verifica în vreun fel lungimea rezultatului criptat.

Din nou, ca și în alte atacuri ale oracolului, avem o relație:

Din nou, controlăm un membru (), vedem o mică scurgere de informații despre celălalt membru (text criptat) și încercăm să recuperăm ultimul (text deschis). În ciuda analogiei, aceasta este o situație puțin neobișnuită față de alte atacuri ale oracolului pe care le-am văzut.

Pentru a ilustra cum un astfel de atac poate funcționa, vom folosi un algoritm de comprimare imaginar pe care tocmai l-am inventat: TOYZIP. Acesta caută secvențe de text care au apărut deja anterior în text și le înlocuiește cu trei octeți de umplutură care indică unde poate fi găsit un exemplar anterior al secvenței și de câte ori apare acolo. De exemplu, secvența helloworldhello poate fi comprimat în helloworld[00][00][05] o lungime de 13 biți în comparație cu originalul de 15 biți.

Să presupunem că un hacker încearcă să recupereze textul clar al formularului password=..., unde parola însăși este necunoscută. Conform modelului de atac Kelsey, hackerul poate cere serverului să comprime și apoi să cripteze mesajele formularului (text clar, urmat de ), unde  — text arbitrar. După ce serverul finalizează procesarea, acesta raportează lungimea rezultatului. Atacul decurge în felul următor:

Hacker: Te rog, comprima și criptează textul clar fără completări.

Serverul: Lungimea rezultatului 14.

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=a.

Serverul: Lungimea rezultatului 18.

Hackerul observă: [original 14] + [trei biți care au înlocuit password=] + a

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=b.

Serverul: Lungimea rezultatului 18.

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=с.

Serverul: Lungimea rezultatului 17.

Hackerul observă: [original 14] + [trei biți care au înlocuit password=c]. Aceasta sugerează că textul original conține șirul password=c. Așadar, parola începe cu litera c

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=сa.

Serverul: Lungimea rezultatului 18.

Hackerul observă: [original 14] + [trei biți care au înlocuit password=с] + a

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=сb.

Serverul: Lungimea rezultatului 18.

(… ceva timp mai târziu…)

Hacker: Te rog, comprima și criptează textul clar, la care s-a adăugat password=со.

Serverul: Lungimea rezultatului 17.

Hackerul observă: [original 14] + [trei biți care au înlocuit password=co]. În același mod, hackerul deduce că parola începe cu literele co

Și așa mai departe până când întreaga parolă este recuperată.

Cititorului i se poate părea că este doar un exercițiu academic și că un astfel de scenariu de atac nu va apărea niciodată în lumea reală. Din păcate, așa cum vom vedea în curând, în criptografie este mai bine să nu te lași dus de val.

Vulnerabilități de marcă: CRIME, POODLE, DROWN

În cele din urmă, după o analiză detaliată a teoriei, putem observa cum aceste metode sunt aplicate în atacuri criptografice reale.

CRIME

Dacă atacul este direcționat împotriva browserului și rețelei victimei, unele lucruri vor fi mai simple, iar altele – mai dificile. De exemplu, este ușor să vezi traficul victimei: este suficient să stai cu ea în aceeași cafenea cu WiFi. Din acest motiv, potențialelor victime (adică tuturor) li se recomandă adesea să utilizeze o conexiune criptată. Va fi mai complicat, dar totuși posibil, să efectueze cereri HTTP în numele victimei către un site extern (de exemplu, Google). Atacatorul trebuie să atragă victima pe o pagină web malițioasă cu un script care să facă solicitarea. Browserul web va oferi automat cookie-ul de sesiune corespunzător.

Pare uimitor. Dacă Bob a accesat evil.com, oare scriptul de pe acest site poate doar să îi ceară lui Google să îi trimită parola lui Bob prin e-mail la attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Furtul de cereri între site-uri, CSRF), și a fost popular în jurul anilor '90. Astăzi, dacă evil.com încearcă un astfel de truc, Google (sau orice site de bună reputație) de obicei va răspunde: „Excelent, dar token-ul tău CSRF pentru această tranzacție va fi… hmm… trei trilioane și șapte. Te rog, repetă acest număr.” Browserele moderne aplică un mecanism numit „politica aceluiași origini” (same-origin policy), conform căreia scripturile de pe site-ul A nu au acces la informațiile trimise de site-ul B. Prin urmare, scriptul de pe evil.com poate trimite cereri către google.com, dar nu poate citi răspunsurile sau, de fapt, finaliza tranzacția.

Trebuie să subliniem că, dacă Bob nu folosește o conexiune criptată, toate aceste protecții sunt inutile. Un hacker poate pur și simplu să citească traficul lui Bob și să recupereze cookie-ul de sesiune Google. Cu acest cookie, el va deschide pur și simplu un nou tab Google, fără a ieși din propriul browser, asumându-și identitatea lui Bob, fără a se confrunta cu politica enervantă de același origini. Dar, din păcate pentru hacker, astfel de cazuri devin din ce în ce mai rare. Internetul, în ansamblu, a declarat război conexiunilor necriptate de mult timp, iar traficul lui Bob este probabil criptat, indiferent dacă îi place sau nu. În plus, încă de la începutul implementării protocolului, traficul a fost de asemenea comprimat înainte de criptare; aceasta era o practică obișnuită pentru a reduce întârzierea.

Aici intervine CRIME (Compression Ratio Infoleak Made Easy, o scurgere simplă prin coeficientul de compresie). O vulnerabilitate demonstrată în septembrie 2012 de cercetătorii în securitate Giuliano Rizzo și Thai Duong. Am analizat deja întreaga bază teoretică care permite înțelegerea a ceea ce au făcut și cum. Hackerul poate determina browserul lui Bob să trimită cereri către Google și apoi să asculte răspunsurile în rețeaua locală în format comprimat și criptat. Prin urmare, avem:

Aici hackerul controlează cererea și are acces la un sniffer de trafic, inclusiv la dimensiunea pachetelor. Scenariul fictiv al lui Kelsey a devenit realitate.

Înțelegând teoria, autorii CRIME au creat un exploit care poate fura cookie-urile de sesiune pentru o gamă largă de site-uri, inclusiv Gmail, Twitter, Dropbox și Github. Vulnerabilitatea a afectat majoritatea browserelor web moderne, rezultând în lansarea de patch-uri care au îngropat pe tăcute funcția de compresie în SSL, astfel încât să nu fie utilizată deloc. Singurul protejat împotriva vulnerabilității a fost venerabilul Internet Explorer, care nici măcar nu a folosit vreodată compresia SSL.

POODLE

În octombrie 2014, echipa de securitate Google a provocat rumoare în comunitatea de securitate. Aceștia au reușit să exploateze o vulnerabilitate în protocolul SSL, corectată cu peste zece ani în urmă.

S-a dovedit că, deși pe servere rulează un TLSv1.2 nou și minunat, multe dintre acestea au lăsat suportul pentru vechiul SSLv3 pentru a asigura compatibilitatea înapoi cu Internet Explorer 6. Am discutat deja despre atacurile de downgrade, așa că vă puteți imagina ce se întâmplă. Un sabotaj bine organizat al protocolului de handshake – și serverele sunt gata să revină la vechiul SSLv3, de fapt anihilând ultimele 15 ani de cercetări în domeniul securității.

Pentru context istoric, iată un rezumat scurt al istoriei SSL până la versiunea 2 de Matthew Green:

Transport Layer Security (TLS) este cel mai important protocol de securitate de pe internet. [..] aproape fiecare tranzacție pe care o efectuați pe internet depinde de TLS. [..] Dar TLS nu a fost întotdeauna TLS. Protocolul și-a început viața în Netscape Communications sub numele de „Secure Sockets Layer” sau SSL. Se zvonește că prima versiune SSL a fost atât de horribilă încât dezvoltatorii au adunat toate printurile de cod și le-au îngropat într-un cimitir secret din New Mexico. Drept urmare, prima versiune publică a SSL este de fapt versiunea SSL 2. Este destul de înfricoșătoare, iar [..] a fost un produs din mijlocul anilor '90, pe care criptograferii moderni îl consideră ca fiind „evul întunecat al criptografiei. Multe dintre cele mai groaznice atacuri criptografice despre care știm astăzi nu fuseseră încă descoperite. Ca urmare, dezvoltatorii protocolului SSLv2 au trebuit practic să își croiască drum în întuneric și s-au confruntat cu multe monștri terifianți — cu supărarea lor și beneficiul nostru, deoarece atacurile asupra SSLv2 au lăsat lecții neprețuite pentru următoarea generație de protocoale.

După aceste evenimente, în 1996, compania Netscape, dezamăgită, a reinventat protocolul SSL de la zero. Rezultatul a fost SSL versiunea 3, care a corectat câteva probleme de securitate cunoscute ale predecesorului său.

Din fericire pentru hackeri, „câteva” nu înseamnă „toate”. În general, SSLv3 oferea toate blocurile necesare pentru a lansa atacul Wodene. Protocolul utiliza un cifru pe bloc în modul CBC și o schemă de umplere nesigură (aceasta a fost corectată în TLS; de aceea a apărut necesitatea unui atac de degradare). Dacă vă amintiți schema de umplere din prima noastră descriere a atacului Wodene, schema SSLv3 este foarte similară.

Dar, din păcate pentru hackeri, „similar” nu înseamnă „identic”. Schema de umplere SSLv3 are forma „N bytes arbitrare, urmate de numărul N”. Încearcă în aceste condiții să alegi un bloc imaginar de text criptat și să treci prin toate etapele originale ale schemei Wodene: vei descoperi că atacul extrage cu succes ultimul byte din blocul corespunzător de text deschis, dar nu merge mai departe. Decriptarea fiecărui byte de 16-byte de text criptat este un truc excelent, dar nu este o victorie.

Confruntându-se cu eșecul, echipa Google a recurs la o variantă extremă: s-au mutat la un model de amenințare mai puternic — cel folosit în CRIME. Dacă presupunem că atacatorul este un script rulat pe tab-ul browserului victimei și poate extrage cookie-uri de sesiune, atacul rămâne totuși impresionant. Deși modelul de amenințare mai larg este mai puțin realist, în secțiunea precedentă am văzut deja că acest model specific este realizabil.

Având în vedere aceste capacități mai puternice ale atacatorului, atacul poate continua. Rețineți că infractorul știe unde în antet este afișat fișierul cookie de sesiune criptat și controlează lungimea cererii HTTP anterioare. Prin urmare, el poate manipula cererea HTTP pentru a alinia ultimul octet al cookie-ului la sfârșitul blocului. Acum, acest octet este potrivit pentru decriptare. Poate adăuga pur și simplu un caracter la cerere, iar penultimul octet al cookie-ului va rămâne în aceeași poziție și va fi potrivit pentru generarea prin aceeași metodă. Atacul continuă în acest mod până când fișierul cookie este complet restaurat. Acesta se numește POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Așa cum am menționat anterior, SSLv3 avea defecte, dar se deosebea drastic de predecesorul său, deoarece SSLv2 era un produs dintr-o altă eră. Acolo putea fi întrerupt un mesaj la mijloc: o voi accepta doar pe trupul meu se transforma în o voi accepta; clientul și serverul se puteau întâlni pe internet, stabili încrederea și schimba secrete sub privirile infractorului, care apoi putea să se prezinte ușor atât ca unul, cât și ca celălalt. Existau și probleme cu criptografia de export, pe care le-am menționat când am discutat despre FREAK. Erau criptografii Sodoma și Gomora.

În martie 2016, o echipă de cercetători din diverse domenii tehnice s-a adunat și a făcut o descoperire uluitorare: SSLv2 este încă utilizat în sistemele de securitate. Da, infractorii nu mai puteau să degradeze sesiunile moderne TLS la SSLv2, deoarece această breșă a fost închisă după FREAK și POODLE, dar ei încă se puteau conecta la servere și iniția sesiunile SSLv2 de unii singuri.

Vei întrebați ce ne pasă nouă de ceea ce fac ei acolo? Au o sesiune vulnerabilă, dar asta nu ar trebui să afecteze alte sesiuni sau securitatea serverului — corect? Ei bine, nu chiar. Da, așa ar trebui să fie în teorie. Dar nu — pentru că generarea certificatelor SSL impune o anumită povară, rezultând că multe servere folosesc aceleași certificate și, prin urmare, aceleași chei RSA pentru conexiuni TLS și SSLv2. Ce este și mai grav, din cauza unei erori OpenSSL în această implementare populară a SSL, opțiunea „Dezactivează SSLv2” nu a funcționat efectiv.

Acest lucru a făcut posibil un atac între protocoale asupra TLS, denumit DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, Decriptarea RSA cu criptare învechită și slăbită). Amintim că aceasta nu este aceeași lucru ca un atac de degradare; atacatorul nu trebuie să acționeze ca un „om din mijloc” și nu trebuie să implice clientul pentru a participa la o sesiune nesigură. Infractorii inițiază pur și simplu o sesiune nesigură SSLv2 cu serverul, atacă protocolul slab și recuperează cheia privată a serverului RSA. Această cheie este, de asemenea, validă pentru conexiunile TLS, iar de acum înainte, nicio securitate TLS nu-l va salva de la compromis.

Dar pentru a compromite este nevoie de un atac funcțional împotriva SSLv2, care să permită recuperarea nu doar a traficului specific, ci și a cheii private a serverului RSA. Deși aceasta este o sarcină complexă, cercetătorii ar fi putut alege orice vulnerabilitate care a fost complet închisă după SSLv2. În cele din urmă, ei au găsit o opțiune potrivită: atacul Bleichenbacher, despre care am menționat anterior și pe care îl vom explica în detaliu în articolul următor. SSL și TLS sunt protejate împotriva acestui atac, dar unele funcții întâmplătoare ale SSL, împreună cu chei scurte în criptografia de clasă export, au făcut posibilă o anumită implementare DROWN..

La momentul publicării, 25% din cele mai importante site-uri de internet erau vulnerabile la DROWN, iar atacul putea fi efectuat cu resurse modeste, disponibile chiar și pentru hackeri solitari puțin răutăcioși. Pentru a extrage cheia RSA a serverului erau necesare opt ore de calcul și 440 USD, iar SSLv2 și-a schimbat statutul de la „îmbătrânit” la „radioactiv”.

Stai puțin, dar ce este cu Heartbleed?

Aceasta nu este o atac criptografic în sensul celor descrise mai sus; este o depășire a tamponului.

Hai să facem o pauză.

Am început cu câteva metode de bază: atacuri de tip brute-force, interpolare, downgrade, atacuri interprotocole și pre-calculare. Apoi am analizat o tehnică avansată, posibil componenta principală a atacurilor criptografice moderne: atacul oracle. Ne-a luat ceva timp să o înțelegem — și am înțeles nu doar principiul de bază, ci și detaliile tehnice ale două implementări specifice: atacul Voidenă asupra modului de criptare CBC și atacul Kelsey asupra protocoalelor de criptare cu compresie prealabilă.

În revizuirea atacurilor de downgrade și cu pre-calculări, am expus pe scurt atacul FREAK, care folosește ambele metode, deoarece site-urile țintă coboară la chei slabe și apoi reutilizează aceleași chei. Pentru articolul următor, am păstrat atacul Logjam (foarte similar), care vizează algoritmii cu chei publice.

Apoi, am analizat încă trei exemple de aplicare a acestor principii. În primul rând, CRIME și POODLE: două atacuri care se bazau pe capacitatea unui atacator de a introduce text deschis arbitrar lângă textul țintă, pentru a studia răspunsurile serverului și apoi, folosind metodologia atacului oracle, a folosi aceste informații sumare pentru a recupera parțial textul deschis. CRIME a mers pe calea atacului Kelsey asupra compresiei SSL, în timp ce POODLE a utilizat o variantă a atacului Voidenă pe CBC cu același efect.

Apoi ne-am concentrat pe atacul interprotocol DROWN, care stabilește o conexiune cu serverul printr-un protocol învechit SSLv2, apoi recuperează cheile secrete ale serverului prin atacul Bleichenbacher. Deocamdată am omis detaliile tehnice ale acestui atac; ca și Logjam, va trebui să aștepte până când vom studia bine sistemele criptografice cu chei publice și vulnerabilitățile acestora.

În următorul articol vom discuta despre atacurile avansate — cum ar fi metoda întâlnirii la mijloc (meet-in-the-middle), analiza criptografică diferențială și atacul „zilelor de naștere”. Vom face o scurtă incursiune în atacurile prin canale laterale, iar apoi ne vom ocupa de cea mai captivantă parte — sistemele criptografice cu chei publice.

Sursa: habr.com