Când auziți cuvântul „criptografie”, unii oameni își amintesc parola WiFi, lacătul verde de lângă adresa site-ului lor preferat și cât de dificil este să intri în e-mailul altcuiva. Alții își amintesc o serie de vulnerabilități din ultimii ani cu abrevieri grăitoare (DROWN, FREAK, POODLE...), logo-uri elegante și un avertisment pentru a vă actualiza urgent browserul.

Criptografia acoperă totul, dar esența in alt. Ideea este că există o linie fină între simplu și complex. Unele lucruri sunt ușor de făcut, dar greu de pus la loc, cum ar fi spargerea unui ou. Alte lucruri sunt ușor de făcut, dar greu de recuperat atunci când lipsește o parte mică, importantă și crucială: de exemplu, deschiderea unei uși încuiate când „partea esențială” este cheia. Criptografia studiază aceste situații și cum pot fi utilizate în practică.

În ultimii ani, colecția de atacuri criptografice s-a transformat într-o grădină zoologică de logo-uri strălucitoare, pline de formule din lucrări științifice și a dat naștere unui sentiment general sumbru că totul este stricat. Dar, de fapt, multe dintre atacuri se bazează pe câteva principii generale și pagini nesfârșite de formule sunt adesea rezumate la idei ușor de înțeles.

În această serie de articole, vom analiza diferitele tipuri de atacuri criptografice, cu accent pe principiile de bază. În termeni generali și nu tocmai în această ordine, dar vom acoperi următoarele:

• Strategii de bază: forță brută, analiză de frecvență, interpolare, downgrade și protocoale încrucișate.
• Vulnerabilități de marcă: NIVEL, CRIMINĂ, POODLE, ÎNECĂT, BUCURĂ.
• Strategii avansate: atacurile oracolului (atacul Vodenet, atacul Kelsey); metoda întâlnirii la mijloc, atac de ziua de naștere, părtinire statistică (criptanaliza diferențială, criptoanaliza integrală etc.).
• Atacurile pe canale laterale și rudele lor apropiate, metode de analiză a eșecului.
• Atacuri la criptografia cu cheie publică: rădăcină cubă, difuzare, mesaj asociat, atac Coppersmith, algoritm Pohlig-Hellman, sită numerică, atac Wiener, atac Bleichenbacher.

Acest articol special acoperă materialul de mai sus până la atacul lui Kelsey.

Strategii de bază

Următoarele atacuri sunt simple în sensul că pot fi explicate aproape complet fără prea multe detalii tehnice. Să explicăm fiecare tip de atac în cei mai simpli termeni, fără a intra în exemple complexe sau cazuri de utilizare avansate.

Unele dintre aceste atacuri au devenit în mare parte învechite și nu au fost folosite de mulți ani. Alții sunt vechi care încă se strecoară în mod regulat la dezvoltatorii de criptosisteme nebănuiți în secolul 21. Era criptografiei moderne poate fi considerată a fi început odată cu apariția IBM DES, primul cifr care a rezistat tuturor atacurilor de pe această listă.

Forță brută simplă

Schema de criptare constă din două părți: 1) funcția de criptare, care preia un mesaj (text simplu) combinat cu o cheie, apoi creează un mesaj criptat - text cifrat; 2) o funcție de decriptare care preia textul cifrat și cheia și produce text simplu. Atât criptarea, cât și decriptarea trebuie să fie ușor de calculat cu cheia – și dificil de calculat fără ea.

Să presupunem că vedem textul cifrat și încercăm să-l decriptăm fără nicio informație suplimentară (acest lucru se numește atac doar pentru text cifrat). Dacă găsim într-un fel magic cheia corectă, 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, știm cum să efectuăm decriptarea, adică cum funcționează criptosistemul. Aceasta este o presupunere standard atunci când discutăm despre criptografie. Ascunderea detaliilor de implementare a cifrului de atacatori poate părea o măsură suplimentară de securitate, dar odată ce atacatorul își dă seama de aceste detalii, această securitate suplimentară se pierde în mod liniștit și ireversibil. Așa Principiul Kerchhoffs: Sistemul care cade în mâinile inamicului nu ar trebui să provoace inconveniente.

Î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ă; este satisfăcut dacă textul cifrat este mult mai lung decât cheia și este lizibil. De obicei, asta se întâmplă în lumea reală, cu excepția chei imense impracticabile sau alte șmecherii care sunt mai bine lăsate deoparte (dacă nu vă place că am omis explicația, consultați Teorema 3.8 aici).

Având în vedere cele de mai sus, apare o strategie: verificați fiecare cheie posibilă. Aceasta se numește forță brută și un astfel de atac este garantat să funcționeze împotriva tuturor cifrurilor practice - în cele din urmă. De exemplu, forța brută este suficientă pentru a pirata Cifrul Caesar, un cifr antic în care cheia este o literă a alfabetului, ceea ce implică puțin peste 20 de chei posibile.

Din păcate pentru criptoanalisti, creșterea dimensiunii cheii este o bună apărare împotriva forței brute. Pe măsură ce dimensiunea cheii crește, numărul de taste posibile crește exponențial. Cu dimensiunile moderne ale cheilor, forța brută simplă este complet impracticabilă. Pentru a înțelege la ce ne referim, să luăm cel mai rapid supercomputer cunoscut de la jumătatea anului 2019: Summit-ul de la IBM, cu performanțe de vârf de aproximativ 1017 operațiuni pe secundă. Astăzi, lungimea tipică a cheii este de 128 de biți, ceea ce înseamnă 2128 de combinații posibile. Pentru a căuta prin toate cheile, supercomputerul Summit va avea nevoie de un timp de aproximativ 7800 de ori mai mare decât vârsta Universului.

Ar trebui să fie considerată forța brută o curiozitate istorică? Deloc: este un ingredient necesar în cartea de bucate de criptoanaliza. Rareori cifrurile sunt atât de slabe încât să poată fi sparte doar printr-un atac inteligent, fără utilizarea forței într-o măsură sau alta. Multe hack-uri de succes folosesc o metodă algoritmică pentru a slăbi mai întâi cifra țintă și apoi pentru a efectua un atac cu forță brută.

Analiza de frecventa

Majoritatea textelor nu sunt farfurii. De exemplu, în textele în limba engleză există multe litere „e” și articole „the”; în fișierele binare, există mulți zero octeți ca umplutură între informații. Analiza de frecvență este orice atac care profită de acest fapt.

Exemplul canonic al unui cifr vulnerabil la acest atac este cifrul de substituție simplu. În acest cifr, cheia este un tabel cu toate literele înlocuite. De exemplu, „g” este înlocuit cu „h”, „o” cu j, deci cuvântul „go” devine „hj”. Acest cifru este greu de folosit cu forța brută, deoarece există atât de multe tabele de căutare posibile. Dacă sunteți interesat de matematică, lungimea efectivă a cheii este de aproximativ 88 de biți: asta este
. Dar, de obicei, analiza frecvenței își face treaba rapid.

Luați în considerare următorul text cifrat procesat cu un cifr de substituție simplu:

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

Întrucât Y apare frecvent, inclusiv la sfârșitul multor cuvinte, putem presupune provizoriu că aceasta este litera e:

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

Cuplu XD repetat la începutul mai multor cuvinte. În special, combinația XDeLe sugerează clar cuvântul these sau there, deci să continuăm:

theLe ALe UGLe THWNKE WN HeAJeN ANF eALth DGLAtWG decât ALe FleAUt GR WN OGQL ZDWBGEGZDO

Să presupunem în continuare că L соответствует r, A - a și așa mai departe. Probabil că va fi nevoie de câteva încercări, dar, în comparație cu un atac complet de forță brută, acest atac restabilește textul original în cel mai scurt timp:

sunt mai multe lucruri în cer și pe pământ horatio decât se visează în filosofia ta

Pentru unii, rezolvarea unor astfel de „criptograme” este un hobby interesant.

Ideea analizei de frecvență este mai fundamentală decât pare la prima vedere. Și se aplică unor cifruri mult mai complexe. De-a lungul istoriei, diferite modele de cifrare au încercat să contracareze un astfel de atac folosind „substituție polialfabetică”. Aici, în timpul procesului de criptare, tabelul de înlocuire a literelor este modificat în moduri complexe, dar previzibile, care depind de cheie. Toate aceste cifruri au fost considerate dificil de spart la un moment dat; și totuși analiza de frecvență modestă i-a învins în cele din urmă pe toți.

Cel mai ambițios cifr polialfabetic din istorie, și probabil cel mai faimos, a fost cifrul Enigma al celui de-al Doilea Război Mondial. Era relativ complex în comparație cu predecesorii săi, dar după multă muncă grea, criptoanalistii britanici l-au spart folosind analiza de frecvență. Desigur, nu au putut dezvolta un atac elegant ca cel prezentat mai sus; au trebuit să compare perechi cunoscute de text clar și text cifrat (așa-numitul „atac de text simplu”), provocând chiar utilizatorii Enigma să cripteze anumite mesaje și să analizeze rezultatul („atacul ales cu textul simplu”). Dar acest lucru nu a ușurat soarta armatelor inamice învinse și a submarinelor scufundate.

După acest triumf, analiza frecvenței a dispărut din istoria criptoanalizei. Cifrurile din era digitală modernă sunt concepute pentru a funcționa cu biți, nu cu litere. Mai important, aceste cifruri au fost concepute cu înțelegerea întunecată a ceea ce mai târziu a devenit cunoscut ca legea lui Schneier: Oricine poate crea un algoritm de criptare pe care ei înșiși nu îl pot rupe. Nu este suficient pentru sistemul de criptare părea dificil: pentru a-și dovedi valoarea, trebuie să treacă printr-o revizuire nemiloasă a securității de către mulți criptoanalisti care vor face tot posibilul pentru a sparge cifrul.

Calcule preliminare

Luați ipoteticul oraș Precom Heights, cu o populație de 200 de locuitori. Fiecare casă din oraș conține în medie obiecte de valoare în valoare de 000 de dolari, dar nu mai mult de 30 de dolari. Piața de securitate din Precom este monopolizată de ACME Industries, care produce legendarele încuietori din clasa Coyote™. Potrivit analizei experților, un lacăt din clasa Coyote poate fi spart doar de o mașină ipotetică foarte complexă, a cărei creare necesită aproximativ cinci ani și investiții de 000 de dolari. Este orașul în siguranță?

Cel mai probabil nu. În cele din urmă, va apărea un criminal destul de ambițios. El va raționa astfel: „Da, voi suporta costuri inițiale mari. Cinci ani de așteptare cu pacienți și 50 000 de dolari, dar când termin, voi avea acces la toată bogăția acestui oraș. Dacă îmi joc cărțile corect, această investiție se va amortiza de mai multe ori.”

Același lucru este valabil și în criptografie. Atacurile împotriva unui anumit cifr sunt supuse unei analize nemilos raport cost-beneficiu. Dacă raportul este favorabil, atacul nu va avea loc. Dar atacurile care funcționează împotriva multor victime potențiale în același timp dau rezultate aproape întotdeauna, caz în care cea mai bună practică de proiectare este să presupunem că au început din prima zi. Avem, în esență, o versiune criptografică a Legii lui Murphy: „Orice lucru care poate rupe de fapt sistemul va rupe sistemul”.

Cel mai simplu exemplu de criptosistem care este vulnerabil la un atac de precalculare este un cifru constant fără cheie. Acesta a fost cazul cu Cifrul lui Cezar, care pur și simplu mută fiecare literă a alfabetului cu trei litere înainte (tabelul este în buclă, astfel încât ultima literă din alfabet este criptată a treia). Aici intră din nou în joc principiul Kerchhoffs: odată ce un sistem este piratat, acesta este piratat pentru totdeauna.

Conceptul este simplu. Chiar și un dezvoltator de criptosistem începător va recunoaște probabil amenințarea și se va pregăti în consecință. Privind la evoluția criptografiei, astfel de atacuri au fost nepotrivite pentru majoritatea cifrurilor, de la primele versiuni îmbunătățite ale cifrului Caesar până la declinul cifrurilor polialfabetice. Astfel de atacuri au revenit doar odată cu apariția erei moderne a criptografiei.

Această întoarcere se datorează a doi factori. În sfârșit, au apărut în sfârșit criptosisteme suficient de complexe, unde posibilitatea de exploatare după hacking nu era evidentă. În al doilea rând, criptografia a devenit atât de răspândită încât milioane de laici au luat decizii în fiecare zi cu privire la unde și ce părți ale criptografiei să reutilizeze. A durat ceva timp până când experții și-au dat seama de riscuri și să dea alarma.

Amintiți-vă de atacul precalcular: la sfârșitul articolului vom analiza două exemple criptografice din viața reală în care a jucat un rol important.

Interpolare

Iată-l pe celebrul detectiv Sherlock Holmes, care efectuează un atac de interpolare asupra nefericitului doctor Watson:

Am ghicit imediat că ați venit din Afganistan... Gândurile mele a fost următoarea: „Omul ăsta este medic după tip, dar are o poziție militară. Deci, un medic militar. Tocmai a sosit de la tropice - fața lui este întunecată, dar aceasta nu este nuanța naturală a pielii, deoarece încheieturile sale sunt mult mai albe. Fața este slăbită - evident, a suferit mult și a suferit de boală. A fost rănit în mâna stângă - o ține nemișcat și puțin nefiresc. Unde la tropice ar putea un medic militar englez să sufere greutăți și să fie rănit? Desigur, în Afganistan”. Întregul tren al gândurilor nu a durat nici măcar o secundă. Și așa am spus că ai venit din Afganistan și ai fost surprins.

Holmes putea extrage foarte puține informații din fiecare dovadă în mod individual. El a putut ajunge la concluzia sa doar luându-le în considerare pe toate împreună. Un atac de interpolare funcționează în mod similar prin examinarea perechilor de text simplu și de text cifrat cunoscute care rezultă din aceeași cheie. Din fiecare pereche se extrag observatii individuale care permit tragerea unei concluzii generale despre cheie. Toate aceste concluzii sunt vagi și par inutile până când ajung brusc la o masă critică și conduc la singura concluzie posibilă: oricât de incredibilă ar fi, trebuie să fie adevărată. După aceasta, fie cheia este dezvăluită, fie procesul de decriptare devine atât de rafinat î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 inamicului nostru, Bob. El criptează fiecare număr din jurnalul său folosind un sistem criptografic simplu despre care a aflat dintr-o reclamă din revista „A Mock of Cryptography”. Sistemul funcționează astfel: Bob alege două numere care îi plac: и . De acum înainte, pentru a cripta orice număr , calculează . De exemplu, dacă Bob a ales и , apoi numărul va fi criptat ca .

Să zicem că pe 28 decembrie am observat că Bob zgâria ceva în jurnal. Când a terminat, îl vom ridica în liniște și vom urmări ultima intrare:

Data: 235/520

Dragă Jurnal,

Azi a fost o zi buna. Prin 64 azi am o intalnire cu Alisa, care locuieste intr-un apartament 843. Chiar cred că ar putea fi 26!

Deoarece suntem foarte serioși să-l urmăm pe Bob la întâlnirea lui (amândoi avem 15 ani în acest scenariu), este esențial să cunoaștem data și adresa Alicei. Din fericire, observăm că criptosistemul lui Bob este vulnerabil la un atac de interpolare. S-ar putea să nu știm и , dar știm data de astăzi, așa că avem două perechi text simplu-text cifrat. Și anume, știm asta criptat în Și - în . Iată ce vom scrie:

De când avem 15 ani, știm deja despre un sistem de două ecuații cu două necunoscute, care în această situație este suficient pentru a găsi и fara probleme. Fiecare pereche text simplu-text cifrat plasează o constrângere pe cheia lui Bob, iar cele două constrângeri împreună sunt suficiente pentru a recupera complet cheia. În exemplul nostru răspunsul este и (la , asa de 26 în jurnal corespunde cuvântului „celul”, adică „același” - cca. BANDĂ).

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

Nou-veniții se plâng adesea că criptografia este „arta de a proiecta lucruri cât mai urâte posibil”. Atacurile de interpolare sunt probabil în mare parte de vină. Bob poate fie să folosească un design matematic elegant, fie să-și păstreze întâlnirea cu Alice privată - dar, din păcate, de obicei nu o poți avea în ambele sensuri. Acest lucru va deveni foarte clar când vom ajunge în cele din urmă la subiectul criptografiei cu cheie publică.

Protocol încrucișat/downgrade

În Now You See Me (2013), un grup de iluzioniști încearcă să-l escrocheze pe magnatul corupt al asigurărilor Arthur Tressler din întreaga sa avere. Pentru a avea acces la contul bancar al lui Arthur, iluzioniștii trebuie fie să-i furnizeze numele de utilizator și parola, fie să-l oblige să apară personal la bancă și să ia parte la schemă.

Ambele variante sunt foarte dificile; Băieții sunt obișnuiți să cânte pe scenă și să nu participe la operațiuni de informații. Așa că aleg a treia opțiune posibilă: complicele lor sună la bancă și se preface a fi Arthur. Banca pune mai multe întrebări pentru a verifica identitatea, cum ar fi numele unchiului și numele primului animal de companie; eroii noștri în avans extrag cu ușurință aceste informații de la Arthur folosind o inginerie socială inteligentă. Din acest moment, securitatea excelentă a parolei nu mai contează.

(Conform unei legende urbane pe care am verificat-o și verificată personal, criptograful Eli Beaham a întâlnit odată un casier de bancă care a insistat să pună o întrebare de securitate. Când casierul a cerut numele bunicii sale materne, Beaham a început să dicteze: „Majuscul X, y mic, trei... ").

Este același lucru în criptografie, dacă două protocoale criptografice sunt utilizate în paralel pentru a proteja același activ, iar unul este mult mai slab decât celălalt. Sistemul rezultat devine vulnerabil la un atac încrucișat, în care un protocol mai slab este atacat pentru a ajunge la premiu fără a-l atinge pe cel mai puternic.

În unele cazuri complexe, nu este suficient să contactați serverul folosind un protocol mai slab, ci necesită participarea involuntară a unui client legitim. Acest lucru poate fi organizat folosind așa-numitul atac de downgrade. Pentru a înțelege acest atac, să presupunem că iluzioniștii noștri au o sarcină mai dificilă decât în ​​film. Să presupunem că un angajat al băncii (casier) și Arthur s-au confruntat cu niște circumstanțe neprevăzute, ducând la următorul dialog:

Hoț: Buna ziua? Acesta este Arthur Tressler. Aș dori să-mi resetați parola.

Casier: Grozav. Vă rugăm să aruncați o privire la cartea personală de coduri secrete, pagina 28, cuvântul 3. Toate mesajele următoare vor fi criptate folosind acest cuvânt ca cheie. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Hoț: Hei, hei, așteaptă, așteaptă. Este chiar necesar acest lucru? Nu putem vorbi ca oameni normali?

Casier: Nu recomand să faci asta.

Hoț: Eu doar... uite, am avut o zi proastă, bine? Sunt client VIP și nu am chef să caut prin aceste cărți de coduri stupide.

Casier: Amenda. Dacă insistați, domnule Tressler. Ce vrei?

Hoț: Vă rog, aș dori să-mi donez toți banii Fondului Național pentru Victime Arthur Tressler.

(Pauză).

Casier: Este clar acum? Vă rugăm să furnizați codul PIN pentru tranzacțiile mari.

Hoț: Al meu ce?

Casier: La cererea dumneavoastră personală, tranzacțiile de această dimensiune necesită un PIN pentru tranzacțiile mari. Acest cod ți-a fost dat când ți-ai deschis contul.

Hoț:... Am pierdut. Este chiar necesar acest lucru? Nu poți să aprobi afacerea?

Casier: Nu. Îmi pare rău, domnule Tressler. Din nou, aceasta este măsura de securitate pe care ați cerut-o. Dacă doriți, vă putem trimite un nou cod PIN în căsuța dvs. poștală.

Eroii noștri amână operațiunea. Ei ascultă cu urechea câteva dintre tranzacțiile mari ale lui Tressler, sperând să audă PIN-ul; dar de fiecare dată când conversația se transformă în farfurie codificată înainte de a se spune ceva interesant. În sfârșit, într-o bună zi, planul este pus în aplicare. Ei așteaptă cu răbdare momentul în care Tressler trebuie să facă o tranzacție mare prin telefon, el intră în linie și apoi...

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

Casier: Grozav. Vă rugăm să aruncați o privire la cartea dvs. personală de coduri secrete, pagina...

(Hoțul apasă butonul; vocea casierului se transformă în zgomot de neînțeles).

Casier: - #@$#@$#*@$$@#* va fi criptat cu acest cuvânt ca cheie. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Scuze, nu prea am inteles. Din nou? Pe ce pagina? Ce cuvant?

Casier: Aceasta este pagina @#$@#*$)#*#@()#@$(#@*$(#@*).

Tressler: Ce?

Casier: Cuvântul numărul douăzeci @$#@$#%#$.

Tressler: Serios! Destul deja! Tu și protocolul tău de securitate sunteți un fel de circ. Știu că poți vorbi cu mine în mod normal.

Casier: nu recomand…

Tressler: Și nu te sfătuiesc să-mi pierzi timpul. Nu vreau să aud mai multe despre asta până nu remediați problemele cu linia telefonică. Putem finaliza această afacere sau nu?

Casier:… Da. Amenda. Ce vrei?

Tressler: Aș dori să transfer 20 USD către Lord Business Investments, numărul de cont...

Casier: Un minut te rog. Este mare lucru. Vă rugăm să furnizați codul PIN pentru tranzacțiile mari.

Tressler: Ce? Ah, exact. 1234.

Iată un atac descendent. Protocolul mai slab „vorbește direct” a fost conceput ca opțiune în caz de urgență. Și totuși iată-ne.

S-ar putea să vă întrebați cine în mintea lor sănătoasă ar proiecta un adevărat sistem „seif până când li se cere altfel” precum cel descris mai sus. Dar, așa cum o bancă fictivă își asumă riscuri pentru a păstra clienții cărora nu le place criptografia, sistemele, în general, gravitează adesea către cerințe care sunt indiferente sau chiar de-a dreptul ostile securității.

Este exact ceea ce s-a întâmplat cu protocolul SSLv2 în 1995. Guvernul SUA a început de mult să vadă criptografia ca pe o armă care este cel mai bine ținută departe de inamicii străini și interni. Bucăți de cod au fost aprobate individual pentru export din Statele Unite, adesea cu condiția ca algoritmul să fie slăbit în mod deliberat. Netscape, dezvoltatorul celui mai popular browser, Netscape Navigator, a primit permisiunea pentru SSLv2 numai cu cheia RSA de 512 biți în mod inerent vulnerabilă (și 40 de biți pentru RC4).

Până la sfârșitul mileniului, regulile s-au relaxat și accesul la criptarea modernă a devenit disponibil pe scară largă. Cu toate acestea, clienții și serverele au suportat criptografia „export” slăbită de ani de zile datorită aceleiași inerții care menține suportul pentru orice sistem moștenit. Clienții credeau că ar putea întâlni un server care nu acceptă nimic altceva. Serverele au procedat la fel. Desigur, protocolul SSL dictează că clienții și serverele nu ar trebui să folosească niciodată un protocol slab atunci când este disponibil unul mai bun. Dar aceeași premisă s-a aplicat lui Tressler și băncii sale.

Această teorie și-a găsit drumul în două atacuri importante care au zguduit securitatea protocolului SSL în 2015, ambele descoperite de cercetătorii Microsoft și INRIA. Mai întâi, detaliile atacului FREAK au fost dezvăluite în februarie, urmate trei luni mai târziu de un alt atac similar numit Logjam, despre care vom discuta mai detaliat când vom trece la atacurile asupra criptografiei cu cheie publică.

Vulnerabilitate CIUDĂȚENIE (cunoscut și sub denumirea de „Smack TLS”) a apărut când cercetătorii au analizat implementările client/server TLS și au descoperit o eroare curioasă. În aceste implementări, dacă clientul nici măcar nu cere să folosească o criptografie slabă de export, dar serverul încă răspunde cu astfel de chei, clientul spune „Oh, bine” și trece la o suită de cifră slabă.

La acea vreme, criptografia de export era considerată în general învechită și interzisă, așa că atacul a venit ca un șoc total și a afectat multe domenii importante, inclusiv site-urile de la Casa Albă, IRS și NSA. Și mai rău, se dovedește că multe servere vulnerabile optimizau performanța prin reutilizarea acelorași chei, în loc să genereze altele noi pentru fiecare sesiune. Acest lucru a făcut posibilă, după retrogradarea protocolului, să se efectueze un atac pre-calcul: cracarea unei chei a rămas relativ costisitoare (100 USD și 12 ore în momentul publicării), dar costul practic al atacării conexiunii a fost redus semnificativ. Este suficient să selectați cheia serverului o dată și să spargeți criptarea pentru toate conexiunile ulterioare din acel moment.

Și înainte de a merge mai departe, există un atac avansat care trebuie menționat...

Atacul Oracle

Moxie Marlinspike cel mai cunoscut ca părintele aplicației de mesagerie cripto-platformă Signal; dar personal ne place una dintre inovațiile sale mai puțin cunoscute - principiul sortimentului criptografic (Principiul Criptografic Doom). Pentru a parafraza ușor, putem spune așa: „Dacă protocolul funcționează orice efectuează o operațiune criptografică asupra unui mesaj dintr-o sursă potențial rău intenționată și se comportă diferit în funcție de rezultat, este condamnat.” Sau într-o formă mai clară: „Nu luați informații de la inamic pentru procesare și, dacă trebuie, atunci cel puțin nu arătați rezultatul”.

Să lăsăm deoparte debordările de tampon, injecțiile de comandă și altele asemenea; ele depăşesc sfera acestei discuţii. Încălcarea „principiului doom” duce la hack-uri grave de criptare datorită faptului că protocolul se comportă exact așa cum era de așteptat.

Ca exemplu, să luăm un design fictiv cu un cifr de substituție vulnerabil și apoi să demonstrăm un posibil atac. Deși am văzut deja un atac asupra unui cifr de substituție folosind analiza frecvenței, nu este doar „o altă modalitate de a sparge același cifr”. Dimpotrivă, atacurile oracle sunt o invenție mult mai modernă, aplicabilă multor situații în care analiza frecvenței eșuează și vom vedea o demonstrație în acest sens în secțiunea următoare. Aici cifrul simplu este ales doar pentru a face exemplul mai clar.

Așadar, Alice și Bob comunică folosind un cifr de substituție simplu folosind o cheie cunoscută doar de ei. Sunt foarte stricte în ceea ce privește lungimea mesajelor: au exact 20 de caractere. Așa că au fost de acord că, dacă cineva dorea să trimită un mesaj mai scurt, ar trebui să adauge un text fals la sfârșitul mesajului pentru a avea exact 20 de caractere. După câteva discuții, au decis că vor accepta doar următoarele texte false: a, bb, ccc, dddd etc. Astfel, se cunoaște un text inactiv de orice lungime necesară.

Când Alice sau Bob primesc un mesaj, ei verifică mai întâi dacă mesajul are lungimea corectă (20 de caractere) și că sufixul este textul inactiv corect. Dacă nu este cazul, atunci ei răspund cu un mesaj de eroare corespunzător. Dacă lungimea textului și textul inactiv sunt ok, destinatarul citește mesajul însuși și trimite un răspuns criptat.

În timpul atacului, atacatorul își face identitatea lui Bob și îi trimite mesaje false lui Alice. Mesajele sunt complet aiurea - atacatorul nu are cheia și, prin urmare, nu poate falsifica un mesaj semnificativ. Dar, deoarece protocolul încalcă principiul doom, un atacator o poate prinde în capcană pe Alice să dezvăluie informațiile cheie, așa cum se arată mai jos.

Hoț: PREWF ZHJKL MMMN. LA

Alice: Text fals nevalid.

Hoț: PREWF ZHJKL MMMN. LB

Alice: Text fals nevalid.

Hoț: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Hoțul habar nu are ce tocmai a spus Alice, dar notează că simbolul C trebuie să corespundă a, deoarece Alice a acceptat textul fals.

Hoț: REWF ZHJKL MMMN. LAA

Alice: Text fals nevalid.

Hoț: REWF ZHJKL MMMN. LBB

Alice: Text fals nevalid.

Dupa o serie de incercari...

Hoț: REWF ZHJKL MMMN. LGG

Alice: Text fals nevalid.

Hoț: 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 tocmai a spus Alice, dar observă că H trebuie să se potrivească cu b, deoarece Alice a acceptat textul fals.

Și așa mai departe până când atacatorul cunoaște semnificația fiecărui personaj.

La prima vedere, metoda seamănă cu un atac de text simplu ales. În cele din urmă, atacatorul selectează textele cifrate, iar serverul le procesează cu ascultare. Principala diferență care face ca aceste atacuri să fie viabile în lumea reală este că atacatorul nu are nevoie de acces la transcrierea propriu-zisă – un răspuns de server, chiar și unul la fel de inofensiv precum „Text inactiv invalid”, este suficient.

Deși acest atac special este instructiv, nu vă agățați prea mult de specificul schemei de „text fals”, de criptosistemul specific utilizat sau de secvența exactă a mesajelor trimise de atacator. Ideea de bază este modul în care Alice reacționează diferit pe baza proprietăților textului simplu și face acest lucru fără a verifica dacă textul cifrat corespunzător provine de fapt de la o parte de încredere. Astfel, Alice îi permite atacatorului să stoarce informații secrete din răspunsurile ei.

Sunt multe care pot fi schimbate în acest scenariu. Simbolurile la care reacționează Alice, sau chiar diferența de comportament, sau chiar criptosistemul folosit. Dar principiul va rămâne același, iar atacul în ansamblu va rămâne viabil într-o formă sau alta. Implementarea de bază a acestui atac a ajutat la descoperirea mai multor erori de securitate, pe care le vom analiza în scurt timp; dar mai întâi sunt câteva lecții teoretice de învățat. Cum să folosești acest „script Alice” fictiv într-un atac care poate funcționa pe un cifru modern real? Este acest lucru posibil, chiar și în teorie?

În 1998, criptograful elvețian Daniel Bleichenbacher a răspuns afirmativ la această întrebare. El a demonstrat un atac oracol asupra criptosistemului larg utilizat de chei publice RSA, folosind o schemă specifică de mesaje. În unele implementări RSA, serverul răspunde cu mesaje de eroare diferite, în funcție de dacă textul simplu se potrivește cu schema sau nu; asta a fost suficient pentru a duce la bun sfârșit atacul.

Patru ani mai târziu, în 2002, criptograful francez Serge Vaudenay a demonstrat un atac oracol aproape identic cu cel descris în scenariul Alice de mai sus - cu excepția faptului că, în loc de un cifru fictiv, a spart o întreagă clasă respectabilă de cifruri moderne pe care oamenii de fapt sunt folosite. În special, atacul lui Vaudenay vizează cifrurile cu dimensiunea de intrare fixă ​​(„cifre bloc”) atunci când sunt folosite în așa-numitul „mod de criptare CBC” și cu o anumită schemă de umplutură populară, practic echivalentă cu cea din scenariul Alice.

Tot în 2002, criptograful american John Kelsey - co-autor Doi pești — a propus diverse atacuri oracle asupra sistemelor care comprimă mesajele și apoi le criptează. Cel mai notabil dintre acestea a fost un atac care a profitat de faptul că este adesea posibil să se deducă lungimea originală a textului simplu din lungimea textului cifrat. În teorie, acest lucru permite un atac oracol care recuperează părți din textul simplu original.

Mai jos oferim o descriere mai detaliată a atacurilor Vaudenay și Kelsey (vom oferi o descriere mai detaliată a atacului Bleichenbacher atunci când trecem la atacurile asupra criptografiei cu cheie publică). În ciuda eforturilor noastre, textul devine oarecum tehnic; deci, dacă cele de mai sus sunt suficiente pentru tine, sări peste următoarele două secțiuni.

Atacul lui Vodene

Pentru a înțelege atacul Vaudenay, trebuie mai întâi să vorbim puțin despre cifrurile bloc și modurile de criptare. Un „cifr de bloc” este, după cum sa menționat, un cifr care preia o cheie și o intrare de o anumită lungime fixă ​​(„lungimea blocului”) și produce un bloc criptat de aceeași lungime. Cifrurile bloc sunt utilizate pe scară largă și sunt considerate relativ sigure. DES, acum retras, considerat primul cifr modern, a fost un cifru bloc. După cum am menționat mai sus, același lucru este valabil și pentru AES, care este utilizat pe scară largă astăzi.

Din păcate, cifrurile bloc au o slăbiciune flagrantă. Dimensiunea tipică a blocului este de 128 de biți sau 16 caractere. Evident, criptografia modernă necesită lucrul cu date de intrare mai mari și aici intră în joc modurile de criptare. Modul de criptare este, în esență, un hack: este o modalitate de a aplica într-un fel un cifru bloc care acceptă doar intrare de o anumită dimensiune la intrare de o lungime arbitrară.

Atacul lui Vodene se concentrează pe modul de operare popular CBC (Cipher Block Chaining). Atacul tratează cifrul bloc de bază ca pe o cutie neagră magică, inexpugnabilă și ocolește complet securitatea acestuia.

Iată o diagramă care arată cum funcționează modul CBC:

Plusul încercuit semnifică operația XOR (SAU exclusiv). De exemplu, al doilea bloc de text cifrat este primit:

1. Prin efectuarea unei operații XOR pe al doilea bloc de text simplu cu primul bloc de text cifrat.
2. Criptarea blocului rezultat cu un cifru bloc folosind o cheie.

Deoarece CBC folosește atât de mult operația binară XOR, să luăm un moment pentru a ne aminti câteva dintre proprietățile sale:

• Idempotenta:
• Comutativitate:
• Asociativitate:
• Auto-reversibilitate:
• Dimensiunea octetului: octet n de = (octetul n al ) (octetul n al )

De obicei, aceste proprietăți implică faptul că, dacă avem o ecuație care implică operații XOR și o necunoscută, aceasta poate fi rezolvată. De exemplu, dacă știm asta cu necunoscutul si faimos и , 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 , primim . Toate acestea vor deveni foarte relevante într-un moment.

Există două diferențe minore și o diferență majoră între scenariul nostru Alice și atacul lui Vaudenay. Două minore:

• În scenariu, Alice se aștepta ca textele clare să se termine cu personajele a, bb, ccc și așa mai departe. În atacul Wodene, victima se așteaptă în schimb ca textele clare să se termine de N ori cu N octeți (adică, hexazecimal 01 sau 02 02, sau 03 03 03 și așa mai departe). Aceasta este o diferență pur cosmetică.
• În scenariul Alice, a fost ușor de spus dacă Alice a acceptat mesajul prin răspunsul „Text fals incorect”. În atacul lui Vodene, este nevoie de mai multe analize și este importantă implementarea precisă din partea victimei; dar de dragul conciziei, să considerăm un dat că această analiză este încă posibilă.

Diferența principală:

• Deoarece nu folosim același criptosistem, relația dintre octeții de text cifrat controlați de atacator și secrete (cheie și text simplu) va fi evident diferită. Prin urmare, atacatorul va trebui să folosească o strategie diferită atunci când creează texte cifrate și interpretează răspunsurile serverului.

Această diferență majoră este piesă finală a puzzle-ului pentru a înțelege atacul Vaudenay, așa că haideți să ne gândim de ce și cum poate fi lansat un atac oracol asupra CBC în primul rând.

Să presupunem că ni se oferă un text cifrat CBC de 247 de blocuri și dorim să-l decriptăm. Putem trimite mesaje false către server, la fel cum am putea trimite mesaje false lui Alice înainte. Serverul va decripta mesajele pentru noi, dar nu va arăta decriptarea - în schimb, din nou, ca și în cazul Alice, serverul va raporta doar un bit de informații: dacă textul simplu are padding valid sau nu.

Luați în considerare că în scenariul lui Alice am avut următoarele relații:

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

Să numim asta „ecuația lui Alice”. Am controlat textul cifrat; serverul (Alice) a scurs informații vagi despre textul simplu primit; iar acest lucru ne-a permis să deducem informații despre ultimul factor – cheia. Prin analogie, dacă putem găsi o astfel de conexiune pentru scenariul CBC, s-ar putea să putem extrage și acolo câteva informații secrete.

Din fericire, există într-adevăr relații pe care le putem folosi. Luați în considerare rezultatul apelului final pentru a decripta un cifr de bloc și notați această ieșire ca . De asemenea, notăm blocuri de text simplu și blocuri de text cifrat . Mai aruncați o privire la diagrama CBC și observați ce se întâmplă:

Să numim asta „ecuația CBC”.

În scenariul lui Alice, prin monitorizarea textului cifrat și urmărirea scurgerii de text simplu corespunzătoare, am reușit să lansăm un atac care a recuperat al treilea termen din ecuație - cheia. În scenariul CBC, monitorizăm și textul cifrat și observăm scurgeri de informații pe textul simplu corespunzător. Dacă analogia este valabilă, putem obține informații despre .

Să presupunem că ne-am restaurat cu adevărat , ce atunci? Ei bine, atunci putem tipări întregul bloc de text simplu dintr-o dată (), prin simpla intrare (pe care le avem) și
primit în ecuația CBC.

Acum că suntem optimiști în ceea ce privește planul general de atac, este timpul să elaborăm detaliile. Vă rugăm să acordați atenție modului în care informațiile în text clar sunt scurse pe server. În scriptul lui Alice, scurgerea a avut loc deoarece Alice ar răspunde cu mesajul corect numai dacă $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ se termina cu linia a (Sau, bb, și așa mai departe, dar șansele ca aceste condiții să fie declanșate din întâmplare au fost foarte mici). Similar cu CBC, serverul acceptă umplutura dacă și numai dacă se termină în hexazecimal 01. Deci, să încercăm același truc: trimiterea de texte cifrate false cu propriile noastre valori false până când serverul acceptă umplerea.

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

Acum folosim proprietatea XOR byte-byte:

Cunoaștem primul și al treilea termen. Și am văzut deja că acest lucru ne permite să recuperăm termenul rămas - ultimul octet din :

Acest lucru ne oferă, de asemenea, ultimul octet al blocului final de text simplu prin ecuația CBC și proprietatea octet cu octet.

Am putea lăsa asta și să fim mulțumiți că am atacat un cifr teoretic puternic. Dar, de fapt, putem face mult mai mult: putem de fapt recupera tot textul. Acest lucru necesită un truc care nu era în scenariul original al lui Alice și nu este necesar pentru atacul oracolului, dar merită totuși învățat.

Pentru a-l înțelege, mai întâi rețineți că rezultatul ieșirii valorii corecte a ultimului octet este avem o nouă abilitate. Acum, când falsificăm texte cifrate, putem manipula ultimul octet al textului simplu corespunzător. Din nou, aceasta este legată de ecuația CBC și de proprietatea octet cu octet:

Deoarece acum cunoaștem al doilea termen, ne putem folosi controlul asupra primului pentru a-l controla pe al treilea. Pur și simplu calculăm:

Nu am putut face asta înainte pentru că nu aveam încă ultimul octet .

Cum ne va ajuta acest lucru? Să presupunem că acum creăm toate textele cifrate astfel încât în ​​textele clare corespunzătoare ultimul octet este egal cu 02. Serverul acceptă acum padding doar dacă textul simplu se termină cu 02 02. Deoarece am corectat ultimul octet, acest lucru se va întâmpla doar dacă penultimul octet al textului simplu este și 02. Continuăm să trimitem blocuri false de text cifrat, schimbând penultimul octet, până când serverul acceptă padding pentru unul dintre ele. În acest moment obținem:

Și restabilim penultimul octet la fel ca si ultima a fost restaurata. Continuăm în același spirit: corectăm ultimii doi octeți ai textului simplu la 03 03, repetăm ​​acest atac pentru al treilea octet de la sfârșit și așa mai departe, restabilind în cele din urmă complet .

Dar restul textului? Vă rugăm să rețineți că valoarea este de fapt $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Putem pune orice alt bloc în schimb , iar atacul va avea succes. De fapt, putem cere serverului să facă $inline$text{BLOCK_DECRYPT}$inline$ pentru orice date. În acest moment, jocul sa terminat - putem decripta orice text cifrat (aruncă o altă privire la diagrama de decriptare CBC pentru a vedea asta; și rețineți că IV-ul este public).

Această metodă particulară joacă un rol crucial în atacul oracolului pe care îl vom întâlni mai târziu.

Atacul lui Kelsey

Amicul nostru John Kelsey a expus principiile care stau la baza multor atacuri posibile, nu doar detaliile unui atac specific asupra unui anumit cifr. A lui Articolul 2002 al anului este un studiu al posibilelor atacuri asupra datelor comprimate criptate. Credeai că informația că datele au fost comprimate înainte de criptare nu a fost suficientă pentru a efectua un atac? Se pare că este suficient.

Acest rezultat surprinzător se datorează a două principii. În primul rând, există o corelație puternică între lungimea textului simplu și lungimea textului cifrat; pentru multe cifruri egalitate exactă. În al doilea rând, atunci când se efectuează compresia, există, de asemenea, o corelație puternică între lungimea mesajului comprimat și gradul de „zgomot” al textului simplu, adică proporția de caractere care nu se repetă (termenul tehnic este „entropie mare” ).

Pentru a vedea principiul în acțiune, luați în considerare două texte clare:

Text simplu 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Text simplu 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Să presupunem că ambele texte clare sunt comprimate și apoi criptate. Obțineți două texte cifrate rezultate și trebuie să ghiciți care text cifrat se potrivește cu textul simplu:

Text cifrat 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Text cifrat 2: DWKJZXYU

Răspunsul este clar. Dintre texte clare, doar textul simplu 1 ar putea fi comprimat în lungimea slabă a celui de-al doilea text cifrat. Ne-am dat seama de asta fără să știm nimic despre algoritmul de compresie, cheia de criptare sau chiar cifrul în sine. În comparație cu ierarhia posibilelor atacuri criptografice, acest lucru este un fel de nebunie.

Kelsey mai subliniază că, în anumite circumstanțe neobișnuite, acest principiu poate fi folosit și pentru a efectua un atac oracol. În special, descrie modul în care un atacator poate recupera textul simplu secret dacă poate forța serverul să cripteze datele din formular (textul simplu urmat de în timp ce el deține controlul și poate verifica cumva lungimea rezultatului criptat.

Din nou, ca și alte atacuri ale oracolului, avem relația:

Din nou, controlăm un termen (), vedem o mică scurgere de informații despre un alt membru (text cifrat) și încercăm să-l recuperăm pe ultimul (text simplu). În ciuda analogiei, aceasta este o situație oarecum neobișnuită în comparație cu alte atacuri ale oracolului pe care le-am văzut.

Pentru a ilustra modul în care ar putea funcționa un astfel de atac, să folosim o schemă de compresie fictivă cu care tocmai am venit: TOYZIP. Acesta caută linii de text care au apărut anterior în text și le înlocuiește cu trei octeți de substituent care indică unde să găsească o instanță anterioară a liniei și de câte ori apare acolo. De exemplu, linia helloworldhello poate fi comprimat în helloworld[00][00][05] Lungime de 13 octeți în comparație cu cei 15 octeți inițiali.

Să presupunem că un atacator încearcă să recupereze textul simplu al unui formular password=..., unde parola în sine este necunoscută. Conform modelului de atac al lui Kelsey, un atacator ar putea cere serverului să comprima și apoi să cripteze mesajele formular (text simplu urmat de ), unde  - text liber. Când serverul a terminat de funcționare, acesta raportează lungimea rezultatului. Atacul decurge astfel:

Hoț: Vă rugăm să comprimați și să criptați textul simplu fără nicio umplutură.

Server: Lungimea rezultatului 14.

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este atașat password=a.

Server: Lungimea rezultatului 18.

Crackerul notează: [original 14] + [trei octeți care au înlocuit password=] + a

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este adăugat password=b.

Server: Lungimea rezultatului 18.

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este adăugat password=с.

Server: Lungimea rezultatului 17.

Crackerul notează: [original 14] + [trei octeți care au înlocuit password=c]. Aceasta presupune că textul simplu original conține șirul password=c. Adică parola începe cu o literă c

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este adăugat password=сa.

Server: Lungimea rezultatului 18.

Crackerul notează: [original 14] + [trei octeți care au înlocuit password=с] + a

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este adăugat password=сb.

Server: Lungimea rezultatului 18.

(… Ceva timp mai târziu…)

Hoț: Vă rugăm să comprimați și să criptați textul simplu la care este adăugat password=со.

Server: Lungimea rezultatului 17.

Crackerul notează: [original 14] + [trei octeți care au înlocuit password=co]. Folosind aceeași logică, atacatorul ajunge la concluzia că parola începe cu literele co

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

Cititorul ar fi iertat să creadă că acesta este un exercițiu pur academic și că un astfel de scenariu de atac nu ar apărea niciodată în lumea reală. Din păcate, după cum vom vedea în curând, este mai bine să nu renunțăm la criptografie.

Vulnerabilitatea mărcii: CRIME, POODLE, DROWN

În cele din urmă, după ce am studiat teoria în detaliu, putem vedea cum aceste tehnici sunt aplicate în atacurile criptografice din viața reală.

CRIMA

Dacă atacul vizează browserul și rețeaua victimei, unele vor fi mai ușoare, iar altele mai dificile. De exemplu, este ușor să vezi traficul victimei: stai cu el în aceeași cafenea cu WiFi. Din acest motiv, victimelor potențiale (adică tuturor) li se recomandă, în general, să folosească o conexiune criptată. Va fi mai dificil, dar totuși posibil, să faceți solicitări HTTP în numele victimei către un site terță parte (de exemplu, Google). Atacatorul trebuie să atragă victima către o pagină web rău intenționată cu un script care face cererea. Browserul web va furniza automat cookie-ul de sesiune corespunzător.

Acest lucru pare uimitor. Dacă Bob s-ar duce la evil.com, ar putea scriptul de pe acest site să ceară Google să îi trimită prin e-mail parola lui Bob [email protected]? Ei bine, în teorie da, dar în realitate nu. Acest scenariu se numește atac de falsificare a cererii pe site-uri (Solicitare de falsificare inter-site, CSRF), și a fost popular pe la mijlocul anilor '90. Astăzi dacă evil.com încearcă acest truc, Google (sau orice site care se respectă) va răspunde, de obicei, cu: „Genial, dar simbolul tău CSRF pentru această tranzacție va fi... um... три триллиона и семь. Vă rugăm să repetați acest număr.” Browserele moderne au ceva numit „politică de aceeași origine” prin care scripturile de pe site-ul A nu au acces la informațiile trimise de site-ul B. Deci, scriptul de pe evil.com pot trimite cereri către google.com, dar nu poate citi răspunsurile sau nu poate finaliza efectiv tranzacția.

Trebuie să subliniem că, dacă Bob nu folosește o conexiune criptată, toate aceste protecții sunt lipsite de sens. Un atacator poate citi pur și simplu traficul lui Bob și poate recupera cookie-ul de sesiune Google. Cu acest cookie, pur și simplu va deschide o nouă filă Google fără a-și părăsi propriul browser și va uzurpa identitatea lui Bob fără a întâlni politici neplăcute de aceeași origine. Dar, din nefericire pentru un hoț, acest lucru devine din ce în ce mai puțin obișnuit. Internetul în ansamblu a declarat de mult război conexiunilor necriptate, iar traficul de ieșire al lui Bob este probabil criptat, indiferent dacă îi place sau nu. În plus, încă de la începutul implementării protocolului a fost și trafic s-a micsorat înainte de criptare; aceasta a fost o practică comună pentru a reduce latența.

Aici intră în joc CRIMA (Raport de compresie Infoleak Made Easy, scurgere simplă prin raportul de compresie). Vulnerabilitatea a fost dezvăluită în septembrie 2012 de cercetătorii de securitate Juliano Rizzo și Thai Duong. Am examinat deja întreaga bază teoretică, ceea ce ne permite să înțelegem ce au făcut și cum. Un atacator ar putea forța browserul lui Bob să trimită cereri către Google și apoi să asculte răspunsurile în rețeaua locală într-o formă comprimată, criptată. Prin urmare avem:

Aici atacatorul controlează cererea și are acces la sniffer-ul de trafic, inclusiv dimensiunea pachetului. Scenariul fictiv al lui Kelsey a prins viață.

Înțelegând teoria, autorii CRIME au creat un exploit care poate fura cookie-uri de sesiune pentru o gamă largă de site-uri, inclusiv Gmail, Twitter, Dropbox și Github. Vulnerabilitatea a afectat majoritatea browserelor web moderne, ducând la lansarea de corecții care au îngropat în tăcere caracteristica de compresie în SSL, astfel încât să nu fie folosită deloc. Singurul protejat de vulnerabilitate a fost venerabilul Internet Explorer, care nu a folosit niciodată compresia SSL.

PUDEL

În octombrie 2014, echipa de securitate Google a făcut furori în comunitatea de securitate. Ei au reușit să exploateze o vulnerabilitate a protocolului SSL care a fost corectată cu mai bine de zece ani în urmă.

Se pare că, în timp ce serverele rulează noul TLSv1.2 strălucitor, mulți au lăsat suport pentru SSLv3 moștenit pentru compatibilitate cu Internet Explorer 6. Am vorbit deja despre atacurile de downgrade, așa că vă puteți imagina ce se întâmplă. O sabotare bine orchestrată a protocolului de strângere de mână și serverele sunt gata să revină la vechiul SSLv3, anulând în esență ultimii 15 ani de cercetare de securitate.

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

Transport Layer Security (TLS) este cel mai important protocol de securitate de pe Internet. [..] aproape fiecare tranzacție pe care o faceți pe Internet depinde de TLS. [..] Dar TLS nu a fost întotdeauna TLS. Protocolul și-a început viața în Netscape Communications numit „Secure Sockets Layer” sau SSL. Se zvonește că prima versiune a SSL a fost atât de groaznică încât dezvoltatorii au strâns toate imprimările codului și le-au îngropat într-un depozit secret din New Mexico. În consecință, prima versiune disponibilă public a SSL este de fapt versiunea SSL 2. Este destul de înfricoșător și [..] a fost un produs de la mijlocul anilor 90, pe care criptografii moderni îl consideră „epocile întunecate ale criptografiei" Multe dintre cele mai odioase atacuri criptografice despre care știm astăzi nu au fost încă descoperite. Drept urmare, dezvoltatorii protocolului SSLv2 au fost lăsați să-și găsească drumul în întuneric și s-au confruntat o mulțime de monștri îngrozitori - spre supărarea lor și în beneficiul nostru, deoarece atacurile asupra SSLv2 au lăsat lecții neprețuite pentru următoarea generație de protocoale.

În urma acestor evenimente, în 1996, un Netscape frustrat a reproiectat protocolul SSL de la zero. Rezultatul a fost SSL versiunea 3, care a remediat mai multe probleme de securitate cunoscute ale predecesorului său.

Din fericire pentru hoți, „câțiva” nu înseamnă „toți”. În general, SSLv3 a furnizat toate elementele de bază necesare pentru a lansa un atac Vodene. Protocolul folosea un cifr de bloc în modul CBC și o schemă de umplutură nesigură (aceasta a fost corectată în TLS; de aici și necesitatea unui atac de downgrade). Dacă vă amintiți schema de umplutură din descrierea noastră originală a atacului Vaudenay, schema SSLv3 este foarte asemănătoare.

Dar, din păcate pentru hoți, „similar” nu înseamnă „identic”. Schema de completare SSLv3 este „N octeți aleatori urmați de numărul N”. Încercați, în aceste condiții, să selectați un bloc imaginar de text cifrat și să parcurgeți toți pașii schemei originale a lui Vaudene: veți constata că atacul extrage cu succes ultimul octet din blocul corespunzător de text simplu, dar nu merge mai departe. Decriptarea fiecărui octet al 16-lea al textului cifrat este un truc grozav, dar nu este o victorie.

În fața eșecului, echipa Google a recurs la o ultimă soluție: a trecut la un model de amenințare mai puternic – cel folosit în CRIME. Presupunând că atacatorul este un script care rulează în fila browserului victimei și poate extrage cookie-uri de sesiune, atacul este încă impresionant. În timp ce modelul de amenințare mai larg este mai puțin realist, am văzut în secțiunea anterioară că acest model special este fezabil.

Având în vedere aceste capacități mai puternice de atacator, atacul poate continua acum. Rețineți că atacatorul știe unde apare cookie-ul de sesiune criptat în antet și controlează lungimea solicitării HTTP care o precede. Prin urmare, este capabil să manipuleze cererea HTTP astfel încât ultimul octet al cookie-ului să fie aliniat cu sfârșitul blocului. Acum acest octet este potrivit pentru decriptare. Puteți adăuga pur și simplu un caracter la cerere, iar penultimul octet al cookie-ului va rămâne în același loc și este potrivit pentru selectare folosind aceeași metodă. Atacul continuă în acest mod până când fișierul cookie este complet restaurat. Se numește POODLE: Padding Oracle on Downgraded Legacy Encryption.

ÎNECA

După cum am menționat, SSLv3 avea defectele sale, dar era fundamental diferit de predecesorul său, deoarece SSLv2 cu scurgeri era un produs al unei alte epoci. Acolo poți întrerupe mesajul din mijloc: соглашусь на это только через мой труп s-a transformat in соглашусь на это; clientul și serverul ar putea să se întâlnească online, să stabilească încredere și să facă schimb de secrete în fața atacatorului, care apoi le-ar putea uzura cu ușurință pe ambele. Există și problema cu criptografia de export, despre care am menționat-o când ne gândim la FREAK. Acestea erau Sodoma și Gomora criptografice.

În martie 2016, o echipă de cercetători din diferite domenii tehnice s-a reunit și a făcut o descoperire uluitoare: SSLv2 este încă folosit în sistemele de securitate. Da, atacatorii nu mai puteau downgrade sesiunile TLS moderne la SSLv2, deoarece acea gaură a fost închisă după FREAK și POODLE, dar se pot conecta la servere și pot iniția ei înșiși sesiunile SSLv2.

Vă puteți întreba, de ce ne pasă ce fac ei acolo? Au o sesiune vulnerabilă, dar nu ar trebui să afecteze alte sesiuni sau securitatea serverului - nu? Ei bine, nu chiar. Da, așa ar trebui să fie în teorie. Dar nu - pentru că generarea de certificate SSL impune o anumită povară, rezultând că multe servere folosesc aceleași certificate și, ca urmare, aceleași chei RSA pentru conexiunile TLS și SSLv2. Pentru a înrăutăți lucrurile, din cauza unei erori OpenSSL, opțiunea „Dezactivare SSLv2” din această implementare populară SSL nu a funcționat de fapt.

Acest lucru a făcut posibil un atac încrucișat asupra TLS, numit ÎNECA (Decriptarea RSA cu criptare obsoletă și slăbită, decriptarea RSA cu criptare învechită și slăbită). Amintiți-vă că acest lucru nu este același lucru cu un atac scurt; atacatorul nu trebuie să acționeze ca un „om la mijloc” și nu trebuie să implice clientul pentru a participa la o sesiune nesigură. Atacatorii pur și simplu inițiază o sesiune SSLv2 nesigură cu serverul înșiși, atacă protocolul slab și recuperează cheia privată RSA a serverului. Această cheie este valabilă și pentru conexiunile TLS și, din acest moment, niciun nivel de securitate TLS nu va împiedica compromiterea acesteia.

Dar pentru a-l sparge, aveți nevoie de un atac de lucru împotriva SSLv2, care vă permite să recuperați nu numai traficul specific, ci și cheia secretă a serverului RSA. Deși aceasta este o configurație complexă, cercetătorii au putut alege orice vulnerabilitate care a fost complet închisă după SSLv2. Au găsit până la urmă o variantă potrivită: atacul Bleichenbacher, despre care am menționat mai devreme și pe care îl vom explica în detaliu în articolul următor. SSL și TLS sunt protejate de acest atac, dar unele caracteristici aleatorii ale SSL, combinate cu chei scurte în criptografia de export, au făcut posibilă o implementare specifică a DROWN.

La momentul publicării, 25% dintre site-urile de top ale Internetului erau afectate de vulnerabilitatea DROWN, iar atacul putea fi efectuat cu resurse modeste disponibile chiar și pentru hackeri singuratici răutăcioși. Recuperarea cheii RSA a serverului a necesitat opt ​​ore de calcul și 440 USD, iar SSLv2 a trecut de la caduc la radioactiv.

Stai, dar Heartbleed?

Acesta nu este un atac criptografic în sensul descris mai sus; Aceasta este o depășire a tamponului.

Să luam o pauză

Am început cu câteva tehnici de bază: forță brută, interpolare, downgrade, cross-protocol și precalculare. Apoi ne-am uitat la o tehnică avansată, poate componenta principală a atacurilor criptografice moderne: atacul oracol. Am petrecut destul de mult timp să ne dăm seama - și am înțeles nu numai principiul de bază, ci și detaliile tehnice ale două implementări specifice: atacul Vaudenay asupra modului de criptare CBC și atacul Kelsey asupra protocoalelor de criptare pre-compresie.

În revizuirea atacurilor de downgrade și de precalculare, am subliniat pe scurt atacul FREAK, care folosește ambele metode prin faptul că site-urile țintă degradează la chei slabe și apoi reutiliza aceleași chei. Pentru următorul articol, vom salva atacul Logjam (foarte similar), care vizează algoritmii de cheie publică.

Am analizat apoi alte trei exemple de aplicare a acestor principii. În primul rând, CRIME și POODLE: două atacuri care s-au bazat pe capacitatea atacatorului de a injecta text simplu arbitrar lângă textul simplu țintă, apoi examinează răspunsurile serverului și atunci,folosind metodologia de atac oracle, exploatați aceste informații rare pentru a recupera parțial textul simplu. CRIME a urmat calea atacului lui Kelsey asupra compresiei SSL, în timp ce POODLE a folosit în schimb o variantă a atacului lui Vaudenay asupra CBC cu același efect.

Ne-am îndreptat apoi atenția asupra atacului DROWN încrucișat, care stabilește o conexiune la server folosind protocolul SSLv2 moștenit și apoi recuperează cheile secrete ale serverului folosind atacul Bleichenbacher. Am omis deocamdată detaliile tehnice ale acestui atac; precum Logjam, va trebui să aștepte până când vom înțelege bine criptosistemele cu chei publice și vulnerabilitățile acestora.

În articolul următor vom vorbi despre atacuri avansate precum întâlnirea la mijloc, criptoanaliza diferențială și atacurile de ziua de naștere. Să facem o incursiune rapidă în atacurile pe canale laterale și apoi să trecem la partea distractivă: criptosistemele cu cheie publică.

Sursa: www.habr.com