Quan escolteu la paraula "criptografia", algunes persones recorden la seva contrasenya de WiFi, el cadenat verd al costat de l'adreça del seu lloc web preferit i el difícil que és entrar al correu electrònic d'una altra persona. Altres recorden una sèrie de vulnerabilitats dels darrers anys amb abreviatures il·lustratives (DROWN, FREAK, POODLE...), logotips elegants i un avís per actualitzar urgentment el navegador.

La criptografia ho cobreix tot, però l'essència en un altre. La qüestió és que hi ha una línia fina entre simple i complex. Algunes coses són fàcils de fer però difícils de tornar a reunir, com trencar un ou. Altres coses són fàcils de fer però difícils de recuperar quan falta una part petita, important i crucial: per exemple, obrir una porta tancada amb clau quan la "part crucial" és la clau. La criptografia estudia aquestes situacions i com es poden utilitzar a la pràctica.

En els darrers anys, la col·lecció d'atacs criptogràfics s'ha convertit en un zoològic de logotips cridaners, ple de fórmules d'articles científics, i ha donat lloc a una ombrívola sensació general que tot està trencat. Però de fet, molts dels atacs es basen en uns quants principis generals, i moltes pàgines de fórmules es redueixen a idees fàcils d'entendre.

En aquesta sèrie d'articles, analitzarem els diferents tipus d'atacs criptogràfics, posant èmfasi en els principis bàsics. En termes generals i no exactament en aquest ordre, però tractarem el següent:

• Estratègies bàsiques: força bruta, anàlisi de freqüència, interpolació, degradació i protocols creuats.
• Vulnerabilitats de marca: FREAK, CRIME, POODLE, OFEFING, Logjam.
• Estratègies avançades: atacs d'oracle (atac de Vodenet, atac de Kelsey); mètode de trobada al mig, atac d'aniversari, biaix estadístic (criptanàlisi diferencial, criptoanàlisi integral, etc.).
• Atacs al canal lateral i els seus parents propers, mètodes d'anàlisi de fallades.
• Atacs a la criptografia de clau pública: arrel cúbica, difusió, missatge relacionat, atac Coppersmith, algorisme de Pohlig-Hellman, tamís numèric, atac de Wiener, atac de Bleichenbacher.

Aquest article en particular cobreix el material anterior fins a l'atac de Kelsey.

Estratègies bàsiques

Els atacs següents són senzills en el sentit que es poden explicar gairebé completament sense gaire detall tècnic. Expliquem cada tipus d'atac en els termes més senzills, sense entrar en exemples complexos o casos d'ús avançats.

Alguns d'aquests atacs han quedat en gran part obsolets i no s'han utilitzat durant molts anys. Altres són antics que encara s'acosten regularment a desenvolupadors de criptosistemes desprevinguts al segle XXI. Es pot considerar que l'era de la criptografia moderna va començar amb l'arribada d'IBM DES, el primer xifrat que va resistir tots els atacs d'aquesta llista.

Força bruta simple

L'esquema de xifratge consta de dues parts: 1) la funció de xifratge, que pren un missatge (text pla) combinat amb una clau, i després crea un missatge xifrat: text xifrat; 2) una funció de desxifrat que pren el text xifrat i la clau i produeix text pla. Tant el xifratge com el desxifrat han de ser fàcils de calcular amb la clau, i difícils de calcular sense ella.

Suposem que veiem el text xifrat i intentem desxifrar-lo sense cap informació addicional (això s'anomena atac només de text xifrat). Si d'alguna manera trobem màgicament la clau correcta, podem comprovar fàcilment que és correcta si el resultat és un missatge raonable.

Tingueu en compte que aquí hi ha dues suposicions implícites. En primer lloc, sabem com realitzar el desxifrat, és a dir, com funciona el sistema criptogràfic. Aquesta és una hipòtesi estàndard quan es parla de criptografia. Ocultar els detalls d'implementació del xifrat als atacants pot semblar una mesura de seguretat addicional, però una vegada que l'atacant descobreix aquests detalls, aquesta seguretat addicional es perd de manera silenciosa i irreversible. Així és com Principi de Kerchhoff: El sistema que cau en mans de l'enemic no hauria de causar molèsties.

En segon lloc, suposem que la clau correcta és l'única clau que conduirà a un desxifrat raonable. Aquesta també és una suposició raonable; queda satisfet si el text xifrat és molt més llarg que la clau i és llegible. Això sol ser el que passa al món real, excepte enormes claus poc pràctiques o altres travessias que val més deixar de banda (si no us agrada que ens hem saltat l'explicació, vegeu el teorema 3.8). aquí).

Tenint en compte l'anterior, sorgeix una estratègia: comprovar totes les claus possibles. Això s'anomena força bruta, i es garanteix que aquest atac funcionarà contra tots els xifratges pràctics, eventualment. Per exemple, la força bruta és suficient per piratejar Xifrat de César, un antic xifrat on la clau és una lletra de l'alfabet, la qual cosa implica una mica més de 20 claus possibles.

Malauradament per als criptoanalistes, augmentar la mida de la clau és una bona defensa contra la força bruta. A mesura que augmenta la mida de la clau, el nombre de claus possibles augmenta exponencialment. Amb mides de tecles modernes, la força bruta simple és completament impracticable. Per entendre què volem dir, prenem el superordinador més ràpid conegut a mitjans del 2019: Cimera d'IBM, amb un rendiment màxim d'unes 1017 operacions per segon. Avui, la longitud típica de la clau és de 128 bits, el que significa 2128 combinacions possibles. Per cercar totes les claus, el superordinador Summit necessitarà un temps aproximadament 7800 vegades l'edat de l'Univers.

S'ha de considerar la força bruta una curiositat històrica? En absolut: és un ingredient necessari al llibre de cuina de criptoanàlisi. Poques vegades els xifres són tan febles que només es poden trencar amb un atac intel·ligent, sense l'ús de la força en un grau o un altre. Molts pirates reeixits utilitzen un mètode algorítmic per debilitar primer el xifrat objectiu i després realitzar un atac de força bruta.

Anàlisi de freqüència

La majoria dels textos no són ximpleries. Per exemple, als textos en anglès hi ha moltes lletres 'e' i articles 'the'; als fitxers binaris, hi ha molts zero bytes com a farciment entre peces d'informació. L'anàlisi de freqüència és qualsevol atac que aprofita aquest fet.

L'exemple canònic d'un xifratge vulnerable a aquest atac és el xifrat de substitució simple. En aquest xifrat, la clau és una taula amb totes les lletres substituïdes. Per exemple, "g" es substitueix per "h", "o" per j, de manera que la paraula "anar" es converteix en "hj". Aquest xifrat és difícil de força brut perquè hi ha moltes taules de cerca possibles. Si esteu interessats en les matemàtiques, la longitud efectiva de la clau és d'uns 88 bits: això és
. Però l'anàlisi de freqüència normalment fa la feina ràpidament.

Considereu el següent text xifrat processat amb un xifrat de substitució simple:

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

Des Y ocorre amb freqüència, inclòs al final de moltes paraules, podem suposar provisionalment que aquesta és la lletra e:

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

Parella XD repetit al començament de diverses paraules. En particular, la combinació XDeLe suggereix clarament la paraula these o there, així que continuem:

theLe ALe UGLe THWNKE WN HeAJeN ANF EALth DGLAtWG QUE ALE FleAUt GR WN OGQL ZDWBGEGZDO

Suposem, a més, que L correspon r, A - a etcètera. Probablement caldrà uns quants intents, però en comparació amb un atac de força bruta complet, aquest atac restaura el text original en molt poc temps:

hi ha més coses al cel i a la terra horatio de les que somies en la teva filosofia

Per a alguns, resoldre aquests "criptogrames" és un hobby emocionant.

La idea de l'anàlisi de freqüència és més fonamental del que sembla a primera vista. I s'aplica a xifratges molt més complexos. Al llarg de la història, diversos dissenys de xifratge han intentat contrarestar aquest atac mitjançant la "substitució polialfabètica". Aquí, durant el procés de xifratge, la taula de substitució de lletres es modifica de maneres complexes però predictibles que depenen de la clau. Tots aquests xifrats es consideraven difícils de trencar alhora; i tanmateix, l'anàlisi de freqüència modesta finalment els va derrotar a tots.

El xifrat polialfabètic més ambiciós de la història, i probablement el més famós, va ser el xifrat Enigma de la Segona Guerra Mundial. Era relativament complex en comparació amb els seus predecessors, però després de molt treball dur, els criptoanalistes britànics el van trencar mitjançant l'anàlisi de freqüència. Per descomptat, no podien desenvolupar un atac elegant com el que es mostra més amunt; van haver de comparar parells coneguts de text pla i xifrat (l'anomenat "atac de text pla"), fins i tot provocant que els usuaris d'Enigma xifressin determinats missatges i analitzessin el resultat (l'"atac de text pla escollit"). Però això no va facilitar el destí dels exèrcits enemics derrotats i dels submarins enfonsats.

Després d'aquest triomf, l'anàlisi de freqüència va desaparèixer de la història de la criptoanàlisi. Els xifratges a l'era digital moderna estan dissenyats per funcionar amb bits, no amb lletres. Més important encara, aquests xifratges es van dissenyar amb la fosca comprensió del que més tard es coneixia llei de Schneier: Qualsevol pot crear un algorisme de xifratge que ell mateix no pot trencar. No n'hi ha prou amb el sistema de xifratge semblant difícil: per demostrar la seva vàlua, s'ha de sotmetre a una revisió de seguretat despietada per part de molts criptoanalistes que faran tot el possible per trencar el xifrat.

Càlculs previs

Preneu la hipotètica ciutat de Precom Heights, amb una població de 200 habitants. Cada casa de la ciutat conté una mitjana de 000 dòlars d'objectes de valor, però no més de 30 dòlars. El mercat de seguretat de Precom està monopolitzat per ACME Industries, que produeix els llegendaris panys de portes de la classe Coyote™. Segons l'anàlisi d'experts, un pany de la classe Coiote només es pot trencar amb una màquina hipotètica molt complexa, la creació de la qual requereix uns cinc anys i 000 dòlars d'inversió. La ciutat és segura?

Molt probablement no. Finalment, apareixerà un criminal força ambiciós. Raonarà així: “Sí, incorreré en grans costos inicials. Cinc anys d'espera de pacients i 50 dòlars, però quan acabi, tindré accés a tota la riquesa d'aquesta ciutat. Si jugo bé les meves cartes, aquesta inversió es pagarà per si mateixa moltes vegades".

El mateix passa amb la criptografia. Els atacs contra un xifrat particular estan subjectes a una anàlisi cost-benefici despietada. Si la proporció és favorable, l'atac no es produirà. Però els atacs que funcionen contra moltes víctimes potencials alhora gairebé sempre donen els seus fruits, en aquest cas la millor pràctica de disseny és suposar que van començar des del primer dia. Tenim essencialment una versió criptogràfica de la Llei de Murphy: "Qualsevol cosa que realment pugui trencar el sistema trencarà el sistema".

L'exemple més senzill d'un criptosistema que és vulnerable a un atac de precomputació és un xifratge sense clau constant. Aquest va ser el cas amb xifrat de Cèsar, que simplement mou cada lletra de l'alfabet tres lletres cap endavant (la taula està en bucle, de manera que l'última lletra de l'alfabet queda xifrada tercera). Aquí de nou entra en joc el principi de Kerchhoffs: una vegada que un sistema és piratejat, és piratejat per sempre.

El concepte és senzill. Fins i tot un desenvolupador de criptosistemes novells probablement reconeixerà l'amenaça i es prepararà en conseqüència. Tenint en compte l'evolució de la criptografia, aquests atacs eren inadequats per a la majoria de xifres, des de les primeres versions millorades del xifrat Cèsar fins a la decadència dels xifratges polialfabètics. Aquests atacs només van tornar amb l'arribada de l'era moderna de la criptografia.

Aquest retorn es deu a dos factors. En primer lloc, finalment van aparèixer criptosistemes prou complexos, on la possibilitat d'explotació després de la pirateria no era evident. En segon lloc, la criptografia es va estendre tant que milions de laics prenen decisions cada dia sobre on i quines parts de la criptografia reutilitzar. Va passar un temps abans que els experts es van adonar dels riscos i van donar l'alarma.

Recordeu l'atac de precomputació: al final de l'article veurem dos exemples criptogràfics de la vida real on va tenir un paper important.

Interpolació

Aquí teniu el famós detectiu Sherlock Holmes, realitzant un atac d'interpolació contra el desafortunat doctor Watson:

Immediatament vaig endevinar que venies de l'Afganistan... El meu pensament va ser el següent: “Aquest home és metge per tipus, però té una posició militar. Per tant, un metge militar. Acaba d'arribar dels tròpics: la seva cara és fosca, però aquest no és el to natural de la seva pell, ja que els seus canells són molt més blancs. La cara és demacrada, evidentment, ha patit molt i ha patit una malaltia. Va ser ferit a la mà esquerra: la manté immòbil i una mica antinatural. On als tròpics podria un metge militar anglès suportar les dificultats i resultar ferit? Per descomptat, a l'Afganistan". Tot el tren del pensament no va trigar ni un segon. Així que vaig dir que venies de l'Afganistan i t'ha sorprès.

Holmes podia extreure molt poca informació de cada evidència individualment. Només va poder arribar a la seva conclusió considerant-los tots junts. Un atac d'interpolació funciona de manera similar examinant parells coneguts de text pla i xifrat que resulten de la mateixa clau. De cada parella s'extreuen observacions individuals que permeten extreure una conclusió general sobre la clau. Totes aquestes conclusions són vagues i semblen inútils fins que de sobte assoleixen una massa crítica i porten a l'única conclusió possible: per increïble que sigui, ha de ser cert. Després d'això, o bé es revela la clau o el procés de desxifrat es torna tan refinat que es pot replicar.

Il·lustrem amb un exemple senzill com funciona la interpolació. Diguem que volem llegir el diari personal del nostre enemic, Bob. Xifra tots els números del seu diari utilitzant un sistema criptogràfic senzill que va conèixer a partir d'un anunci a la revista "A Mock of Cryptography". El sistema funciona així: Bob tria dos nombres que li agraden: и . A partir d'ara, per xifrar qualsevol número , calcula . Per exemple, si en Bob va triar и , després el número es xifrarà com .

Diguem que el 28 de desembre vam notar que en Bob estava ratllant alguna cosa al seu diari. Quan hagi acabat, ho recollirem en silenci i veurem l'última entrada:

Data: 235/520

Estimat diari,

Avui ha sigut un bon dia. A través de 64 avui tinc una cita amb l'Alisa, que viu en un pis 843. Realment crec que podria ser-ho 26!

Com que som molt seriosos a l'hora de seguir en Bob a la seva cita (tots dos tenim 15 anys en aquest escenari), és fonamental conèixer la data i l'adreça de l'Alice. Afortunadament, observem que el criptosistema de Bob és vulnerable a un atac d'interpolació. Potser no ho sabem и , però sabem la data d'avui, així que tenim dos parells de text pla i xifrat. És a dir, això ho sabem xifrat en I - dins . Això és el que anotarem:

Des que tenim 15 anys ja coneixem un sistema de dues equacions amb dues incògnites, que en aquesta situació n'hi ha prou per trobar и sense cap problema. Cada parella de text sense format-text xifrat posa una restricció a la clau de Bob, i les dues restriccions juntes són suficients per recuperar completament la clau. En el nostre exemple la resposta és и (a les , i que 26 al diari correspon a la paraula "el mateix", és a dir, "el mateix" - aprox. carril).

Els atacs d'interpolació, per descomptat, no es limiten a exemples tan senzills. Cada sistema criptogràfic que es redueix a un objecte matemàtic ben entès i una llista de paràmetres corre el risc d'un atac d'interpolació: com més comprensible sigui l'objecte, més gran serà el risc.

Els nouvinguts sovint es queixen que la criptografia és "l'art de dissenyar coses tan lleig com sigui possible". Els atacs d'interpolació probablement són en gran part els culpables. Bob pot utilitzar un disseny matemàtic elegant o mantenir la seva cita amb l'Alice en privat, però, per desgràcia, normalment no ho pots fer de les dues maneres. Això quedarà molt clar quan finalment arribem al tema de la criptografia de clau pública.

Protocol creuat/downgrade

A Now You See Me (2013), un grup d'il·lusionistes intenten estafar el corrupte magnat de les assegurances Arthur Tressler de tota la seva fortuna. Per accedir al compte bancari d'Arthur, els il·lusionistes han de proporcionar el seu nom d'usuari i contrasenya o bé obligar-lo a presentar-se personalment al banc i participar en l'esquema.

Les dues opcions són molt difícils; Els nois estan acostumats a actuar a l'escenari i no participar en operacions d'intel·ligència. Així que trien la tercera opció possible: el seu còmplice truca al banc i es fa passar per Arthur. El banc fa diverses preguntes per verificar la identitat, com ara el nom de l'oncle i el nom de la primera mascota; els nostres herois per endavant extreuen fàcilment aquesta informació d'Arthur mitjançant una enginyeria social intel·ligent. A partir d'aquest moment, l'excel·lent seguretat de la contrasenya ja no importa.

(Segons una llegenda urbana que hem verificat i verificat personalment, el criptògraf Eli Beaham es va trobar una vegada amb un caixer del banc que va insistir a posar una pregunta de seguretat. Quan el caixer li va demanar el nom de la seva àvia materna, Beaham va començar a dictar: ​​“Capital X, y petita, tres... ").

Passa el mateix en criptografia, si s'utilitzen dos protocols criptogràfics en paral·lel per protegir el mateix actiu, i un és molt més feble que l'altre. El sistema resultant esdevé vulnerable a un atac de protocol creuat, on s'ataca un protocol més feble per arribar al premi sense tocar el més fort.

En alguns casos complexos, no n'hi ha prou amb contactar amb el servidor mitjançant un protocol més feble, sinó que requereix la participació involuntària d'un client legítim. Això es pot organitzar mitjançant l'anomenat atac de degradació. Per entendre aquest atac, suposem que els nostres il·lusionistes tenen una tasca més difícil que a la pel·lícula. Suposem que un empleat del banc (caixer) i Arthur es van trobar amb algunes circumstàncies imprevistes, que van donar lloc al següent diàleg:

lladre: Hola? Aquest és Arthur Tressler. M'agradaria restablir la meva contrasenya.

Caixer: Genial. Si us plau, mireu el vostre llibre de codis secrets personals, pàgina 28, paraula 3. Tots els missatges següents s'encriptaran utilitzant aquesta paraula específica com a clau. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

lladre: Ei, ei, espera, espera. És realment necessari? No podem parlar com gent normal?

Caixer: No recomano fer això.

lladre: Només... mira, vaig tenir un dia pèssim, d'acord? Sóc un client VIP i no tinc ganes d'explorar aquests estúpids llibres de codis.

Caixer: Bé. Si insisteix, senyor Tressler. Què vols?

lladre: Si us plau, m'agradaria donar tots els meus diners al Fons Nacional de Víctimes Arthur Tressler.

(Pausa).

Caixer: Està clar ara? Proporcioneu el vostre PIN per a transaccions grans.

lladre: El meu que?

Caixer: A petició personal, les transaccions d'aquesta mida requereixen un PIN per a transaccions grans. Aquest codi se't va donar quan vas obrir el teu compte.

lladre:... L'he perdut. És realment necessari? No pots aprovar l'acord?

Caixer: No. Ho sento, senyor Tressler. De nou, aquesta és la mesura de seguretat que vau demanar. Si vols, podem enviar un nou codi PIN a la teva bústia de correu.

Els nostres herois posposen l'operació. Escolten diverses de les grans transaccions de Tressler, amb l'esperança d'escoltar el PIN; però cada vegada que la conversa es converteix en un galimat codificat abans que es digui res interessant. Finalment, un bon dia, el pla es posa en marxa. Esperen pacientment el moment en què Tressler ha de fer una transacció important per telèfon, es posa en línia i després...

Tressler: Hola. M'agradaria completar una transacció a distància, si us plau.

Caixer: Genial. Si us plau, fes un cop d'ull al teu llibre de codis secrets personals, pàgina...

(El lladre prem el botó; la veu del caixer es converteix en un soroll inintel·ligible).

Caixer: - #@$#@$#*@$$@#* es xifrarà amb aquesta paraula com a clau. AAAYRR PLRQRZ MMNJK LOJBAN...

Tressler: Ho sento, no ho vaig entendre bé. De nou? A quina pàgina? Quina paraula?

Caixer: Aquesta és la pàgina @#$@#*$)#*#@()#@$(#@*$(#@*).

Tressler: Què?

Caixer: Paraula número vint @$#@$#%#$.

Tressler: De debò! Ja n'hi ha prou! Tu i el teu protocol de seguretat sou una mena de circ. Sé que pots parlar amb mi normalment.

Caixer: No recomano…

Tressler: I no us aconsello que perdeu el meu temps. No vull saber res més sobre això fins que no solucioneu els problemes de la vostra línia telefònica. Podem concretar aquest acord o no?

Caixer:… Sí. Bé. Què vols?

Tressler: M'agradaria transferir 20 dòlars a Lord Business Investments, número de compte...

Caixer: Un minut siusplau. És una gran cosa. Proporcioneu el vostre PIN per a transaccions grans.

Tressler: Què? Ah, exactament. 1234.

Aquí hi ha un atac a la baixa. Es va imaginar el protocol més feble "només parla directament". opció en cas d'emergència. I tanmateix aquí estem.

Potser us preguntareu qui, en el seu bon sentit, dissenyaria un veritable sistema "segur fins que se li demani el contrari" com el descrit anteriorment. Però de la mateixa manera que un banc fictici s'arrisca per retenir clients que no els agrada la criptografia, els sistemes en general solen gravitar cap a requisits que són indiferents o fins i tot francament hostils a la seguretat.

Això és exactament el que va passar amb el protocol SSLv2 el 1995. El govern dels EUA fa temps que comença a veure la criptografia com una arma que es manté millor allunyada dels enemics nacionals i estrangers. Els fragments de codi es van aprovar individualment per exportar-los des dels Estats Units, sovint amb la condició que l'algoritme es debilités deliberadament. Netscape, el desenvolupador del navegador més popular, Netscape Navigator, va rebre permís per a SSLv2 només amb la clau RSA de 512 bits inherentment vulnerable (i de 40 bits per a RC4).

A finals del mil·lenni, les regles s'havien relaxat i l'accés al xifratge modern es va fer àmpliament disponible. No obstant això, els clients i servidors han suportat des de fa anys la criptografia d'"exportació" debilitat a causa de la mateixa inèrcia que manté el suport per a qualsevol sistema heretat. Els clients creien que podrien trobar-se amb un servidor que no admetia res més. Els servidors van fer el mateix. Per descomptat, el protocol SSL dicta que els clients i servidors no haurien d'utilitzar mai un protocol feble quan hi hagi un de millor disponible. Però la mateixa premissa s'aplicava a Tressler i al seu banc.

Aquesta teoria va trobar el seu camí en dos atacs d'alt perfil que van sacsejar la seguretat del protocol SSL el 2015, tots dos descoberts per investigadors de Microsoft i INRIA. En primer lloc, els detalls de l'atac FREAK es van revelar al febrer, seguit tres mesos més tard d'un altre atac similar anomenat Logjam, que parlarem amb més detall quan passem als atacs a la criptografia de clau pública.

Vulnerabilitat MONSTRE (també conegut com "Smack TLS") va sortir a la llum quan els investigadors van analitzar les implementacions de client/servidor de TLS i van descobrir un error curiós. En aquestes implementacions, si el client ni tan sols demana utilitzar una criptografia d'exportació feble, però el servidor encara respon amb aquestes claus, el client diu "Bé" i canvia a una suite de xifratge feble.

En aquell moment, la criptografia d'exportació es considerava àmpliament obsoleta i fora de límits, de manera que l'atac va ser un xoc total i va afectar molts dominis importants, inclosos els llocs de la Casa Blanca, l'IRS i la NSA. Encara pitjor, resulta que molts servidors vulnerables optimitzaven el rendiment reutilitzant les mateixes claus en lloc de generar-ne de noves per a cada sessió. Això va permetre, després de rebaixar el protocol, dur a terme un atac previ al càlcul: trencar una clau continuava sent relativament car (100 dòlars i 12 hores en el moment de la publicació), però el cost pràctic d'atacar la connexió es va reduir significativament. N'hi ha prou amb seleccionar la clau del servidor una vegada i trencar el xifratge per a totes les connexions posteriors a partir d'aquest moment.

I abans de continuar, hi ha un atac avançat que cal esmentar...

Atac de l'oracle

Moxie Marlinspike més conegut com el pare de l'aplicació de missatgeria criptogràfica multiplataforma Signal; però personalment ens agrada una de les seves innovacions menys conegudes: principi de la fatalitat criptogràfica (Principi Criptogràfic Doom). Parafrasejant lleugerament, podem dir això: “Si el protocol funciona cap realitza una operació criptogràfica sobre un missatge d'una font potencialment maliciosa i es comporta de manera diferent segons el resultat, està condemnat". O en una forma més nítida: "No prenguis informació de l'enemic per processar-la i, si cal, almenys no mostris el resultat".

Deixem de banda els desbordaments de buffer, les injeccions d'ordres i similars; estan fora de l'abast d'aquesta discussió. La violació del "principi de la perdició" comporta seriosos pirates de criptografia a causa del fet que el protocol es comporta exactament com s'esperava.

Com a exemple, prenem un disseny fictici amb un xifrat de substitució vulnerable i, a continuació, demostrem un possible atac. Tot i que ja hem vist un atac a un xifrat de substitució mitjançant anàlisi de freqüència, no és només "una altra manera de trencar el mateix xifrat". Al contrari, els atacs d'oracle són una invenció molt més moderna, aplicable a moltes situacions on l'anàlisi de freqüència falla, i veurem una demostració d'això a la secció següent. Aquí s'escull el xifrat simple només per fer l'exemple més clar.

Així, l'Alice i el Bob es comuniquen mitjançant un xifrat de substitució senzill amb una clau que només ells coneixen. Són molt estrictes quant a la longitud dels missatges: tenen exactament 20 caràcters. Així que van acordar que si algú volia enviar un missatge més curt, hauria d'afegir un text simulat al final del missatge per fer-lo exactament 20 caràcters. Després d'una discussió, van decidir que només acceptarien els següents textos simulats: a, bb, ccc, dddd etc. Així, es coneix un text simulat de qualsevol longitud requerida.

Quan l'Alice o el Bob reben un missatge, primer comproven que el missatge té la longitud correcta (20 caràcters) i que el sufix és el text simulat correcte. Si aquest no és el cas, responen amb un missatge d'error adequat. Si la longitud del text i el text simulat són correctes, el destinatari llegeix el missatge i envia una resposta xifrada.

Durant l'atac, l'atacant es fa passar per Bob i envia missatges falsos a l'Alice. Els missatges són un disbarat total: l'atacant no té la clau i, per tant, no pot forjar un missatge significatiu. Però com que el protocol viola el principi de la perdició, un atacant encara pot atrapar l'Alice perquè reveli la informació clau, tal com es mostra a continuació.

lladre: PREWF ZHJKL MMMN. LA

Alícia: Text simulat no vàlid.

lladre: PREWF ZHJKL MMMN. LB

Alícia: Text simulat no vàlid.

lladre: PREWF ZHJKL MMMN. LC

Alícia: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

El lladre no té ni idea del que acaba de dir l'Alice, però assenyala que el símbol C ha de coincidir amb a, ja que l'Alícia va acceptar el text simulat.

lladre: REWF ZHJKL MMMN. LAA

Alícia: Text simulat no vàlid.

lladre: REWF ZHJKL MMMN. LBB

Alícia: Text simulat no vàlid.

Després de diversos intents...

lladre: REWF ZHJKL MMMN. LGG

Alícia: Text simulat no vàlid.

lladre: REWF ZHJKL MMMN. LHH

Alícia: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

De nou, l'atacant no té ni idea del que acaba de dir l'Alice, però assenyala que H ha de coincidir amb b ja que l'Alice va acceptar el text simulat.

I així successivament fins que l'atacant conegui el significat de cada personatge.

A primera vista, el mètode s'assembla a un atac de text pla escollit. Al final, l'atacant selecciona els textos xifrats i el servidor els processa amb obediència. La principal diferència que fa que aquests atacs siguin viables al món real és que l'atacant no necessita accés a la transcripció real; una resposta del servidor, fins i tot una tan innòcua com "Text fictici no vàlid", és suficient.

Tot i que aquest atac en particular és instructiu, no us quedeu massa pendent de les especificitats de l'esquema de "text simulat", del sistema criptogràfic específic utilitzat o de la seqüència exacta de missatges enviats per l'atacant. La idea bàsica és com l'Alice reacciona de manera diferent en funció de les propietats del text pla, i ho fa sense verificar que el text xifrat corresponent prové realment d'una part de confiança. Així, l'Alice permet a l'atacant extreure informació secreta de les seves respostes.

Hi ha moltes coses que es poden canviar en aquest escenari. Els símbols als quals reacciona l'Alice, o la mateixa diferència en el seu comportament, o fins i tot el criptosistema utilitzat. Però el principi seguirà sent el mateix, i l'atac en conjunt es mantindrà viable d'una forma o una altra. La implementació bàsica d'aquest atac va ajudar a descobrir diversos errors de seguretat, que veurem en breu; però primer cal aprendre algunes lliçons teòriques. Com utilitzar aquest "script d'Alice" fictici en un atac que pot funcionar amb un xifrat modern real? Això és possible, fins i tot en teoria?

El 1998, el criptògraf suís Daniel Bleichenbacher va respondre afirmativament aquesta pregunta. Va demostrar un atac d'oracle al sistema criptogràfic de clau pública àmpliament utilitzat RSA, utilitzant un esquema de missatge específic. En algunes implementacions RSA, el servidor respon amb diferents missatges d'error segons si el text sense format coincideix amb l'esquema o no; això va ser suficient per dur a terme l'atac.

Quatre anys més tard, el 2002, el criptògraf francès Serge Vaudenay va demostrar un atac d'oracle gairebé idèntic al descrit a l'escenari d'Alice anterior, excepte que en lloc d'un xifrat fictici, va trencar tota una classe respectable de xifratge modern que la gent realment s'utilitza. En particular, l'atac de Vaudenay es dirigeix ​​a xifratges de mida d'entrada fixa ("xifratge de blocs") quan s'utilitzen en l'anomenat "mode de xifratge CBC" i amb un determinat esquema de farciment popular, bàsicament equivalent al de l'escenari d'Alice.

També el 2002, el criptògraf nord-americà John Kelsey - coautor twofish — va proposar diversos atacs d'oracle a sistemes que comprimeixen missatges i després els xifren. El més notable d'entre aquests va ser un atac que va aprofitar el fet que sovint és possible inferir la longitud original del text pla a partir de la longitud del text xifrat. En teoria, això permet un atac d'oracle que recupera parts del text pla original.

A continuació oferim una descripció més detallada dels atacs de Vaudenay i Kelsey (donarem una descripció més detallada de l'atac de Bleichenbacher quan passem als atacs a la criptografia de clau pública). Malgrat els nostres millors esforços, el text esdevé una mica tècnic; així que si l'anterior és suficient per a vostè, salteu les dues seccions següents.

L'atac de Vodene

Per entendre l'atac de Vaudenay, primer hem de parlar una mica més sobre els xifrats de blocs i els modes de xifratge. Un "xifrat de bloc" és, com s'ha dit, un xifrat que pren una clau i una entrada d'una determinada longitud fixa ("longitud de bloc") i produeix un bloc xifrat de la mateixa longitud. Els xifrats de blocs s'utilitzen àmpliament i es consideren relativament segurs. El DES ja retirat, considerat el primer xifrat modern, era un xifrat de blocs. Com s'ha esmentat anteriorment, el mateix passa amb AES, que s'utilitza àmpliament avui dia.

Malauradament, els xifratge de blocs tenen una debilitat evident. La mida de bloc típica és de 128 bits o 16 caràcters. Òbviament, la criptografia moderna requereix treballar amb dades d'entrada més grans, i aquí és on entren en joc els modes de xifratge. El mode de xifratge és essencialment un pirateig: és una manera d'aplicar d'alguna manera un xifrat de blocs que només accepta entrada d'una certa mida a entrada d'una longitud arbitrària.

L'atac de Vodene se centra en el popular mode d'operació CBC (Cipher Block Chaining). L'atac tracta el xifrat de blocs subjacent com una caixa negra màgica i inexpugnable i passa per alt la seva seguretat.

Aquí teniu un diagrama que mostra com funciona el mode CBC:

El signe més encerclat significa l'operació XOR (OR exclusiu). Per exemple, es rep el segon bloc de text xifrat:

1. Realitzant una operació XOR al segon bloc de text pla amb el primer bloc de text xifrat.
2. Xifrat del bloc resultant amb un xifrat de blocs mitjançant una clau.

Com que CBC fa un ús tan intens de l'operació XOR binària, dediquem un moment a recordar algunes de les seves propietats:

• Idempotència:
• Commutativitat:
• Associativitat:
• Autoreversibilitat:
• Mida del byte: byte n de = (byte n de ) (byte n de )

Normalment, aquestes propietats impliquen que si tenim una equació que implica operacions XOR i una desconeguda, es pot resoldre. Per exemple, si ho sabem amb el desconegut i famós и , llavors podem confiar en les propietats esmentades anteriorment per resoldre l'equació . Aplicant XOR als dos costats de l'equació amb , obtenim . Tot això serà molt rellevant en un moment.

Hi ha dues diferències menors i una diferència important entre el nostre escenari d'Alice i l'atac de Vaudenay. Dos menors:

• Al guió, l'Alice esperava que els textos clars acabessin amb els personatges a, bb, ccc etcètera. En l'atac de Wodene, la víctima espera que els textos en pla acabin N vegades amb N byte (és a dir, hexadecimal 01 o 02 02, o 03 03 03, etc.). Aquesta és purament una diferència estètica.
• En l'escenari d'Alice, era fàcil saber si l'Alícia havia acceptat el missatge amb la resposta "Text fictici incorrecte". En l'atac de Vodene, cal més anàlisi i és important una implementació precisa per part de la víctima; però per a la brevetat, donem per fet que aquesta anàlisi encara és possible.

Diferència principal:

• Com que no estem utilitzant el mateix sistema criptogràfic, la relació entre els bytes de text xifrat controlats per l'atacant i els secrets (clau i text pla) serà òbviament diferent. Per tant, l'atacant haurà d'utilitzar una estratègia diferent a l'hora de crear textos xifrats i d'interpretar les respostes del servidor.

Aquesta gran diferència és la peça final del trencaclosques per entendre l'atac de Vaudenay, així que dediquem un moment a pensar per què i com es pot muntar un atac d'oracle a CBC en primer lloc.

Suposem que ens donen un text xifrat CBC de 247 blocs i volem desxifrar-lo. Podem enviar missatges falsos al servidor, igual que abans podríem enviar missatges falsos a l'Alice. El servidor desxifrarà els missatges per nosaltres, però no mostrarà el desxifrat; en canvi, de nou, com passa amb l'Alice, el servidor només informarà d'un bit d'informació: si el text pla té un farciment vàlid o no.

Tingueu en compte que en l'escenari d'Alice teníem les següents relacions:

$$visualització$$text{SIMPLE_SUBSTITUTION}(text{text xifrat},text{clau}) = text{text pla}$$visualització$$

Anomenem-ho "l'equació d'Alice". Hem controlat el text xifrat; el servidor (Alice) va filtrar informació vaga sobre el text pla rebut; i això ens va permetre deduir informació sobre l'últim factor: la clau. Per analogia, si podem trobar aquesta connexió per al guió de CBC, també podríem extreure informació secreta allà.

Per sort, realment hi ha relacions que podem utilitzar. Considereu la sortida de la trucada final per desxifrar un xifrat de blocs i denoteu aquesta sortida com a . També denotem blocs de text pla i blocs de text xifrat . Fes una altra ullada al diagrama CBC i observa què passa:

Anomenem-ho "equació CBC".

En l'escenari d'Alice, supervisant el text xifrat i observant la filtració de text en pla corresponent, vam poder organitzar un atac que recuperava el tercer terme de l'equació: la clau. En l'escenari CBC, també monitoritzem el text xifrat i observem filtracions d'informació al text pla corresponent. Si l'analogia és vàlida, podem obtenir informació sobre .

Suposem que realment hem restaurat , llavors que? Bé, llavors podem imprimir tot l'últim bloc de text sense format alhora (), simplement entrant (que tenim) i
rebut a l'equació CBC.

Ara que som optimistes sobre el pla general d'atac, és hora d'esbrinar els detalls. Si us plau, presteu atenció a com es filtra exactament la informació de text pla al servidor. A l'script d'Alice, la filtració es va produir perquè Alice només respondria amb el missatge correcte si $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ acabava amb la línia a (O bb, etcètera, però les possibilitats que aquestes condicions es desencadenissin per casualitat eren molt petites). De manera similar a CBC, el servidor accepta el farciment si i només si acaba en hexadecimal 01. Per tant, provem el mateix truc: enviar textos xifrats falsos amb els nostres propis valors falsos fins que el servidor accepti el farcit.

Quan el servidor accepta un farciment per a un dels nostres missatges falsos, vol dir que:

Ara fem servir la propietat XOR byte-byte:

Coneixem el primer i el tercer terme. I ja hem vist que això ens permet recuperar el terme restant: l'últim byte :

Això també ens dóna l'últim byte del bloc final de text pla mitjançant l'equació CBC i la propietat byte a byte.

Podríem deixar-ho així i estar satisfets que hem fet un atac a un xifrat teòricament fort. Però de fet podem fer molt més: podem recuperar tot el text. Això requereix un truc que no estava al guió original d'Alice i que no és necessari per a l'atac de l'oracle, però val la pena aprendre.

Per entendre-ho, primer tingueu en compte que el resultat de la sortida del valor correcte de l'últim byte és tenim una nova capacitat. Ara, quan falsegem textos xifrats, podem manipular l'últim byte del text pla corresponent. De nou, això està relacionat amb l'equació CBC i la propietat byte a byte:

Com que ara coneixem el segon terme, podem utilitzar el nostre control sobre el primer per controlar el tercer. Simplement calculem:

No ho podíem fer abans perquè encara no teníem l'últim byte .

Com ens ajudarà això? Suposem que ara creem tots els textos xifrats de manera que en els textos en pla corresponents l'últim byte sigui igual a 02. El servidor ara només accepta el farciment si el text sense format acaba amb 02 02. Com que hem corregit l'últim byte, això només passarà si el penúltim byte del text pla també és 02. Continuem enviant blocs de text xifrat falsos, canviant el penúltim byte, fins que el servidor accepta el farciment d'un d'ells. En aquest punt obtenim:

I restaurem el penúltim byte igual que l'últim va ser restaurat. Continuem amb el mateix esperit: corregim els dos últims bytes del text pla a 03 03, repetim aquest atac durant el tercer byte des del final i així successivament, finalment restaurant-nos completament .

Què passa amb la resta del text? Tingueu en compte que el valor és en realitat $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Podem posar qualsevol altre bloc en el seu lloc , i l'atac encara tindrà èxit. De fet, podem demanar al servidor que faci $inline$text{BLOCK_DECRYPT}$inline$ per a qualsevol dada. En aquest punt, s'ha acabat el joc: podem desxifrar qualsevol text xifrat (fegeu una altra ullada al diagrama de desxifrat de CBC per veure-ho; i tingueu en compte que l'IV és públic).

Aquest mètode en particular juga un paper crucial en l'atac de l'oracle que trobarem més endavant.

L'atac de Kelsey

El nostre simpàtic John Kelsey va exposar els principis subjacents a molts possibles atacs, no només els detalls d'un atac específic a un xifrat específic. Seva Article de 2002 de l'any és un estudi de possibles atacs a dades comprimides xifrades. Creieu que la informació que les dades estaven comprimides abans del xifratge no era suficient per dur a terme un atac? Resulta que n'hi ha prou.

Aquest resultat sorprenent es deu a dos principis. En primer lloc, hi ha una forta correlació entre la longitud del text pla i la longitud del text xifrat; per a molts xifres igualtat exacta. En segon lloc, quan es realitza la compressió, també hi ha una forta correlació entre la longitud del missatge comprimit i el grau de "sorollós" del text pla, és a dir, la proporció de caràcters que no es repeteixen (el terme tècnic és "alta entropia" ).

Per veure el principi en acció, considereu dos textos clars:

Text pla 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Text pla 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Suposem que tots dos textos sense format estan comprimits i després xifrats. Obteniu dos textos xifrats resultants i heu d'endevinar quin text xifrat coincideix amb quin text pla:

Text xifrat 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Text xifrat 2: DWKJZXYU

La resposta és clara. Entre els textos clars, només el text sense format 1 es podia comprimir a la poca longitud del segon text xifrat. Ho vam esbrinar sense saber res sobre l'algorisme de compressió, la clau de xifratge o fins i tot el xifratge. En comparació amb la jerarquia de possibles atacs criptogràfics, això és una mica boig.

Kelsey assenyala a més que en determinades circumstàncies inusuals aquest principi també es pot utilitzar per dur a terme un atac d'oracle. En particular, descriu com un atacant pot recuperar el text sense format secret si pot forçar el servidor a xifrar les dades del formulari (el text sense format seguit de mentre ell té el control i d'alguna manera pot comprovar la durada del resultat xifrat.

De nou, com altres atacs d'oracle, tenim la relació:

De nou, controlem un terme (), veiem una petita filtració d'informació sobre un altre membre (text xifrat) i intentem recuperar l'últim (text pla). Malgrat l'analogia, aquesta és una situació una mica inusual en comparació amb altres atacs d'oracles que hem vist.

Per il·lustrar com podria funcionar un atac d'aquest tipus, utilitzem un esquema de compressió fictici que acabem de crear: TOYZIP. Busca línies de text que han aparegut anteriorment al text i les substitueix per tres bytes de marcador de posició que indiquen on trobar una instància anterior de la línia i quantes vegades hi apareix. Per exemple, la línia helloworldhello es pot comprimir en helloworld[00][00][05] 13 bytes de llarg en comparació amb els 15 bytes originals.

Suposem que un atacant intenta recuperar el text pla d'un formulari password=..., on la contrasenya és desconeguda. Segons el model d'atac de Kelsey, un atacant podria demanar al servidor que comprimeixi i després xifra els missatges del formulari (text en pla seguit de ), on  - text lliure. Quan el servidor ha acabat de funcionar, informa de la durada del resultat. L'atac és així:

lladre: Si us plau, comprimiu i xifra el text sense cap mena de farciment.

Servidor: Durada del resultat 14.

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'adjunta password=a.

Servidor: Durada del resultat 18.

El cracker assenyala: [original 14] + [tres bytes que s'han substituït password=] + a

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'afegeix password=b.

Servidor: Durada del resultat 18.

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'afegeix password=с.

Servidor: Durada del resultat 17.

El cracker assenyala: [original 14] + [tres bytes que s'han substituït password=c]. Això suposa que el text pla original conté la cadena password=c. És a dir, la contrasenya comença amb una lletra c

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'afegeix password=сa.

Servidor: Durada del resultat 18.

El cracker assenyala: [original 14] + [tres bytes que s'han substituït password=с] + a

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'afegeix password=сb.

Servidor: Durada del resultat 18.

(… Algun temps després…)

lladre: Si us plau, comprimiu i xifra el text sense format al qual s'afegeix password=со.

Servidor: Durada del resultat 17.

El cracker assenyala: [original 14] + [tres bytes que s'han substituït password=co]. Amb la mateixa lògica, l'atacant conclou que la contrasenya comença per les lletres co

I així successivament fins que es restableixi tota la contrasenya.

Es perdonaria al lector que pensi que es tracta d'un exercici purament acadèmic i que un escenari d'atac d'aquest tipus mai es plantejaria en el món real. Per desgràcia, com aviat veurem, és millor no renunciar a la criptografia.

Vulnerabilitats de la marca: CRIME, POODLE, DROWN

Finalment, després d'estudiar la teoria en detall, podem veure com s'apliquen aquestes tècniques en atacs criptogràfics de la vida real.

CRIMA

Si l'atac està dirigit al navegador i la xarxa de la víctima, alguns seran més fàcils i altres més difícils. Per exemple, és fàcil veure el trànsit de la víctima: només cal seure amb ell a la mateixa cafeteria amb WiFi. Per aquest motiu, generalment es recomana a les víctimes potencials (és a dir, tothom) utilitzar una connexió xifrada. Serà més difícil, però encara possible, fer sol·licituds HTTP en nom de la víctima a algun lloc de tercers (per exemple, Google). L'atacant ha d'atreure la víctima a una pàgina web maliciosa amb un script que fa la sol·licitud. El navegador web proporcionarà automàticament la galeta de sessió adequada.

Això sembla increïble. Si en Bob anés evil.com, podria l'script d'aquest lloc només demanar a Google que enviï per correu electrònic la contrasenya de Bob [email protected]? Bé, en teoria sí, però en realitat no. Aquest escenari s'anomena atac de falsificació de sol·licituds entre llocs (Sol·licitud de falsificació entre llocs, CSRF), i va ser popular a mitjans dels anys 90. Avui si evil.com prova aquest truc, Google (o qualsevol lloc web que es precie) normalment respondrà amb: "Genial, però el teu testimoni CSRF per a aquesta transacció serà... um... три триллиона и семь. Si us plau, repeteix aquest número". Els navegadors moderns tenen una cosa anomenada "política del mateix origen" per la qual els scripts del lloc A no tenen accés a la informació enviada pel lloc web B. Per tant, l'script en evil.com pot enviar sol·licituds a google.com, però no pot llegir les respostes ni completar la transacció.

Hem de subratllar que tret que Bob utilitzi una connexió xifrada, totes aquestes proteccions no tenen sentit. Un atacant pot simplement llegir el trànsit de Bob i recuperar la galeta de sessió de Google. Amb aquesta galeta, simplement obrirà una nova pestanya de Google sense sortir del seu propi navegador i suplantarà la identitat de Bob sense trobar polítiques molestes del mateix origen. Però, malauradament per a un lladre, això és cada cop menys comú. Internet en conjunt ha declarat durant molt de temps la guerra a les connexions no xifrades, i probablement el trànsit de sortida de Bob estigui xifrat, li agradi o no. A més, des del primer moment de la implantació del protocol, també hi va haver trànsit es va encongir abans del xifratge; aquesta era una pràctica habitual per reduir la latència.

Aquí és on entra en joc CRIMA (Compression Ratio Infoleak Made Easy, fuga simple a través de la relació de compressió). La vulnerabilitat va ser revelada el setembre de 2012 pels investigadors de seguretat Juliano Rizzo i Thai Duong. Ja hem examinat tota la base teòrica, que ens permet entendre què van fer i com. Un atacant podria forçar el navegador d'en Bob a enviar sol·licituds a Google i després escoltar les respostes a la xarxa local d'una forma comprimida i xifrada. Per tant tenim:

Aquí l'atacant controla la sol·licitud i té accés al rastreig de trànsit, inclosa la mida del paquet. L'escenari fictici de Kelsey va cobrar vida.

Entenent la teoria, els autors de CRIME van crear un exploit que pot robar galetes de sessió per a una àmplia gamma de llocs, inclosos Gmail, Twitter, Dropbox i Github. La vulnerabilitat va afectar la majoria dels navegadors web moderns, i va provocar que es van publicar pedaços que van enterrar silenciosament la funció de compressió a SSL perquè no s'utilitzi en absolut. L'únic protegit de la vulnerabilitat era el venerable Internet Explorer, que mai va utilitzar la compressió SSL.

poodle

L'octubre de 2014, l'equip de seguretat de Google va fer onades a la comunitat de seguretat. Van poder explotar una vulnerabilitat del protocol SSL que s'havia pegat fa més de deu anys.

Resulta que mentre els servidors estan executant el nou i brillant TLSv1.2, molts han deixat el suport per a l'herència SSLv3 per a la compatibilitat amb Internet Explorer 6. Ja hem parlat dels atacs de rebaixes, així que us podeu imaginar què està passant. Un sabotatge ben orquestrat del protocol d'encaixada i els servidors estan preparats per tornar al bon vell SSLv3, desfent essencialment els darrers 15 anys d'investigació de seguretat.

Pel context històric, aquí teniu un breu resum de la història de SSL fins a la versió 2 de Matthew Green:

Transport Layer Security (TLS) és el protocol de seguretat més important d'Internet. [..] gairebé totes les transaccions que feu a Internet depenen de TLS. [..] Però TLS no sempre va ser TLS. El protocol va començar la seva vida a Comunicacions de Netscape anomenat "Secure Sockets Layer" o SSL. Diuen els rumors que la primera versió de SSL va ser tan terrible que els desenvolupadors van recollir totes les impressions del codi i les van enterrar en un abocador secret a Nou Mèxic. Com a conseqüència, la primera versió de SSL disponible públicament és en realitat versió SSL 2. Fa bastant por, i [..] va ser un producte de mitjans dels anys 90, que els criptògrafs moderns consideren "era fosca de la criptografia" Molts dels atacs criptogràfics més atroces que coneixem avui encara no s'han descobert. Com a resultat, els desenvolupadors del protocol SSLv2 es van deixar essencialment per obrir-se camí a les fosques i es van enfrontar un munt de monstres terribles - per al seu disgust i benefici nostre, ja que els atacs a SSLv2 van deixar lliçons inestimables per a la propera generació de protocols.

Arran d'aquests esdeveniments, el 1996, un Netscape frustrat va redissenyar el protocol SSL des de zero. El resultat va ser SSL versió 3, que va solucionar diversos problemes de seguretat coneguts del seu predecessor.

Afortunadament per als lladres, "uns quants" no vol dir "tots". En general, SSLv3 va proporcionar tots els blocs de construcció necessaris per llançar un atac de Vodene. El protocol utilitzava un xifratge de blocs en mode CBC i un esquema de farciment insegur (això es va corregir a TLS; d'aquí la necessitat d'un atac de rebaixa). Si recordeu l'esquema de farciment a la nostra descripció original de l'atac de Vaudenay, l'esquema SSLv3 és molt similar.

Però, malauradament per als lladres, "similar" no vol dir "idèntic". L'esquema de farciment SSLv3 és "N bytes aleatoris seguits del número N". Intenteu, en aquestes condicions, seleccionar un bloc imaginari de text xifrat i seguir tots els passos de l'esquema original de Vaudene: trobareu que l'atac extreu amb èxit l'últim byte del bloc de text pla corresponent, però no va més enllà. Desxifrar cada 16 byte del text xifrat és un gran truc, però no és una victòria.

Davant el fracàs, l'equip de Google va recórrer a l'últim recurs: van canviar a un model d'amenaça més potent: el que s'utilitza a CRIME. Suposant que l'atacant és un script que s'executa a la pestanya del navegador de la víctima i pot extreure galetes de sessió, l'atac segueix sent impressionant. Tot i que el model d'amenaça més ampli és menys realista, vam veure a la secció anterior que aquest model en particular és factible.

Donades aquestes capacitats d'atacant més potents, l'atac ara pot continuar. Tingueu en compte que l'atacant sap on apareix la galeta de sessió xifrada a la capçalera i controla la durada de la sol·licitud HTTP que la precedeix. Per tant, és capaç de manipular la sol·licitud HTTP perquè l'últim byte de la galeta estigui alineat amb el final del bloc. Ara aquest byte és adequat per al desxifrat. Només podeu afegir un caràcter a la sol·licitud i el penúltim byte de la galeta romandrà al mateix lloc i és adequat per a la selecció mitjançant el mateix mètode. L'atac continua d'aquesta manera fins que el fitxer de galetes es restaura completament. Es diu POODLE: Padding Oracle on Downgraded Legacy Encryption.

OFEGAR

Com hem esmentat, SSLv3 tenia els seus defectes, però era fonamentalment diferent del seu predecessor, ja que el SSLv2 amb fuites era un producte d'una època diferent. Allà podeu interrompre el missatge al mig: соглашусь на это только через мой труп convertit en соглашусь на это; el client i el servidor podrien reunir-se en línia, establir confiança i intercanviar secrets davant de l'atacant, que després podria suplantar fàcilment tots dos. També hi ha el problema amb la criptografia d'exportació, que hem esmentat quan considerem FREAK. Aquestes eren criptogràfiques Sodoma i Gomorra.

El març de 2016, un equip d'investigadors de diferents camps tècnics es va reunir i va fer un descobriment sorprenent: SSLv2 encara s'utilitza en sistemes de seguretat. Sí, els atacants ja no podien degradar les sessions TLS modernes a SSLv2, ja que aquest forat es va tancar després de FREAK i POODLE, però encara poden connectar-se als servidors i iniciar les sessions SSLv2 ells mateixos.

Us preguntareu, per què ens importa el que hi fan? Tenen una sessió vulnerable, però no hauria d'afectar altres sessions ni la seguretat del servidor, oi? Bé, no del tot. Sí, així hauria de ser en teoria. Però no, perquè generar certificats SSL imposa una certa càrrega, de manera que molts servidors utilitzen els mateixos certificats i, com a resultat, les mateixes claus RSA per a connexions TLS i SSLv2. Per empitjorar les coses, a causa d'un error d'OpenSSL, l'opció "Desactiva SSLv2" d'aquesta popular implementació SSL no va funcionar.

Això va fer possible un atac de protocol creuat a TLS, anomenat OFEGAR (Desxifrant RSA amb encriptació obsoleta i debilitat, desxifrant RSA amb xifratge obsolet i debilitat). Recordeu que això no és el mateix que un atac curt; l'atacant no necessita actuar com un "home al mig" i no necessita implicar el client per participar en una sessió insegura. Els atacants simplement inicien una sessió SSLv2 insegura amb el propi servidor, ataquen el protocol feble i recuperen la clau privada RSA del servidor. Aquesta clau també és vàlida per a connexions TLS i, a partir d'aquest moment, cap quantitat de seguretat TLS evitarà que es vegi compromesa.

Però per trencar-lo, necessiteu un atac de treball contra SSLv2, que us permeti recuperar no només el trànsit específic, sinó també la clau secreta del servidor RSA. Tot i que es tracta d'una configuració complexa, els investigadors podrien triar qualsevol vulnerabilitat que es tanqués completament després de SSLv2. Finalment van trobar una opció adequada: l'atac de Bleichenbacher, que hem comentat anteriorment i que explicarem amb detall en el següent article. SSL i TLS estan protegits d'aquest atac, però algunes característiques aleatòries de SSL, combinades amb claus curtes en criptografia de grau d'exportació, van fer possible una implementació específica de DROWN.

En el moment de la publicació, el 25% dels principals llocs d'Internet estaven afectats per la vulnerabilitat DROWN, i l'atac es podria dur a terme amb recursos modestos disponibles fins i tot per als pirates informàtics solitaris entremaliats. La recuperació de la clau RSA del servidor va requerir vuit hores de càlcul i 440 dòlars, i SSLv2 va passar d'obsolet a radioactiu.

Espera, què passa amb Heartbleed?

Aquest no és un atac criptogràfic en el sentit descrit anteriorment; Això és un desbordament de memòria intermèdia.

Fem un descans

Vam començar amb algunes tècniques bàsiques: força bruta, interpolació, degradació, protocol creuat i precàlcul. Després vam analitzar una tècnica avançada, potser el component principal dels atacs criptogràfics moderns: l'atac oracle. Vam passar força temps a esbrinar-ho, i vam entendre no només el principi subjacent, sinó també els detalls tècnics de dues implementacions específiques: l'atac de Vaudenay al mode de xifratge CBC i l'atac de Kelsey als protocols de xifratge de precompressió.

En revisar els atacs de degradació i precomputació, vam descriure breument l'atac FREAK, que utilitza ambdós mètodes fent que els llocs objectiu redueixin a claus febles i després reutilitzin les mateixes claus. Per al següent article, guardarem l'atac Logjam (molt similar), que s'adreça als algorismes de clau pública.

Després vam mirar tres exemples més d'aplicació d'aquests principis. Primer, CRIME i POODLE: dos atacs que es basaven en l'habilitat de l'atacant per injectar text pla arbitrari al costat del text sense format objectiu, després examinar les respostes del servidor i llavors, utilitzant la metodologia d'atac d'oracle, aprofiteu aquesta informació escassa per recuperar parcialment el text pla. CRIME va seguir la ruta de l'atac de Kelsey a la compressió SSL, mentre que POODLE va utilitzar una variant de l'atac de Vaudenay a CBC amb el mateix efecte.

A continuació, vam centrar la nostra atenció en l'atac DROWN de protocol creuat, que estableix una connexió amb el servidor mitjançant el protocol SSLv2 heretat i després recupera les claus secretes del servidor mitjançant l'atac Bleichenbacher. De moment ens hem omès els detalls tècnics d'aquest atac; com Logjam, s'haurà d'esperar fins que tinguem una bona comprensió dels criptosistemes de clau pública i les seves vulnerabilitats.

En el següent article parlarem d'atacs avançats com ara els atacs de trobada al mig, la criptoanàlisi diferencial i els atacs d'aniversari. Fem una incursió ràpida als atacs de canals laterals i, després, passem a la part divertida: els criptosistemes de clau pública.

Font: www.habr.com