Når ordet «kryptografi» nævnes, tænker nogle på deres WiFi-adgangskode, den grønne hængelås ved siden af adressen på deres yndlingswebsted og hvor svært det er at få adgang til en andens e-mail. Andre husker rækken af sårbarheder fra de seneste år med talende forkortelser (DROWN, FREAK, POODLE…), stilfulde logoer og advarslen om straks at opdatere webbrowseren.

Kryptografi dækker alt dette, men essensen ligger et andet sted. Essensen er den fine grænse mellem det simple og det komplekse. Nogle ting er lette at udføre, men svære at tilbageføre: for eksempel at knække et æg. Andre ting er lette at gøre, men svære at tilbageføre, når den lille vigtige afgørende del mangler: for eksempel at åbne en låst dør, når «den afgørende del» er nøglen. Kryptografi undersøger disse situationer og måder at praktisk anvende dem på.

I løbet af de seneste år er samlingen af kryptografiske angreb blevet til en zoologisk have af skrigende logoer, fyldt med formler fra videnskabelige artikler, hvilket har skabt en generel dyster følelse af, at alt er brudt ned. Men i virkeligheden er mange af angrebene baseret på nogle få fælles principper, og de uendelige sider med formler kan ofte reduceres til enkle lettilgængelige idéer.

I denne artikelserie vil vi se på forskellige typer af kryptografiske angreb, med fokus på de grundlæggende principper. I brede træk og ikke nødvendigvis i denne rækkefølge, vil vi dække følgende emner:

Grundlæggende strategier: brute force, frekvensanalyse, interpolation, nedtrapning og krydsprotokoller.
«Brand», sårbarheder: FREAK, CRIME, POODLE, DROWN, Logjam.
Avancerede strategier: orakelangreb (Waters-angreb, Kelsey-angreb); meet-in-the-middle-metode, fødselsdagsangreb, statistisk skævhed (differential kryptanalyse, integral kryptanalyse osv.).
Angreb via sidekanaler og deres nært beslægtede metoder til fejlanalyse.
Angreb på offentlig nøglekryptografi: kubisk rod, broadcast, relateret besked, Coppersmiths angreb, Pollard-Hellman-algoritme, numerisk si, Wieners angreb, Blychenbachers angreb.

Denne specifikke artikel dækker ovennævnte materiale op til Kelsey-angrebet.

Grundlæggende strategier

De følgende angreb er enkle i den forstand, at de næsten helt kan forklares uden særlige tekniske detaljer. Vi vil forklare hver type angreb i de enkleste termer uden at gå ind i komplekse eksempler eller udvidede anvendelsesmuligheder.

Nogle af disse angreb er stort set blevet irrelevante og er ikke blevet anvendt i mange år. Andre er gammelkendte, og de sniger sig stadig regelmæssigt ind på intetanende kryptosystemudviklere i det 21. århundrede. Man kan mene, at æraen for moderne kryptografi begyndte med lanceringen af IBM DES - den første kryptering, der modstod alle angreb på denne liste.

Simpel brute force

Krypteringsskemaet består af to dele: 1) en krypteringsfunktion, der tager en besked (klartekst) sammen med en nøgle, og derefter genererer en krypteret besked - ciphertekst; 2) en dekrypteringsfunktion, der tager ciphertekst og nøglen og genererer klarteksten. Både kryptering og dekryptering skal være lette at beregne med nøglen - og svære uden.

Antag, at vi ser ciphertekst og forsøger at dekryptere den uden nogen yderligere information (dette kaldes en "kun ciphertekst" angreb). Hvis vi på en magisk måde finder den rigtige nøgle, kan vi nemt verificere, at den virkelig er korrekt, hvis resultatet er en rimelig besked.

Bemærk, at der her er to underliggende antagelser. For det første, at vi ved, hvordan dekryptering udføres, altså hvordan kryptosystemet fungerer. Dette er en standard antagelse, når man diskuterer kryptografi. At skjule detaljerne i krypteringens implementering fra angribere kan synes som en ekstra sikkerhedsforanstaltning, men så snart en angriber finder ud af disse detaljer, går denne ekstra sikkerhed stille og roligt tabt. Sådan er Kerckhoffs' princip: at systemets overtagelse af fjenden ikke bør medføre besvær.

For det andet antager vi, at den rigtige nøgle er den eneste nøgle, der fører til en rimelig dekryptering. Dette er også en rimelig antagelse; det gælder, hvis ciphertekst er meget længere end nøglen og er letlæselig. Generelt er det ofte tilfældet i den virkelige verden, bortset fra kolossale urealistiske nøgler eller andre manipulationer, som er bedre at lade ligge. (hvis du ikke kan lide, at vi afviste forklaringerne, så se teorem 3.8 her).

Givet det ovenstående, opstår der en strategi: at kontrollere hver mulig nøgle. Dette kaldes brute force, og sådan et angreb arbejder garanteret mod alle praktiske krypteringer — i sidste ende. For eksempel er brute force tilstrækkeligt til at bryde Cæsar-krypteringen, en gammel kryptering, hvor nøglen er et enkelt bogstav fra alfabetet, hvilket indebærer lidt over 20 mulige nøgler.

Desværre for kryptanalytikere beskytter en stigning i nøglens størrelse godt mod brute force. Efterhånden som størrelsen på nøglen vokser, stiger antallet af mulige nøgler eksponentielt. Med moderne nøglestørrelser er simpel brute force helt urealistisk. For at forstå, hvad vi mener, tage den hurtigste kendte supercomputer i midten af 2019: Summit fra IBM, med en topydelse på omkring 10^17 operationer per sekund. I dag er den typiske nøglelængde 128 bit, hvilket betyder 2^128 mulige kombinationer. For at gennemgå alle nøgler ville supercomputeren Summit have brug for tid, der er cirka 7800 gange længere end universets alder.

Skal vi betragte brute force som et historisk kuriosum? Absolut ikke: det er en nødvendig ingrediens i kryptografiens opskriftbog. Sådanne svage krypteringer, at de kun kan brydes med smarte angreb, uden brug af brute force i en eller anden form, forekommer sjældent. Mange succesfulde brud anvender først en algoritmisk metode for at svække den målrettede kryptering og derefter køre brute force.

Frekvensanalyse

De fleste tekster er ikke nonsense. For eksempel er der i engelsksprogede tekster mange bogstaver ‘e’ og artiklerne ‘the’; i binære filer er der mange nulbyte som fyldstof mellem informationsfragmenter. Frekvensanalyse er enhver angreb, der udnytter denne kendsgerning.

Et klassisk eksempel på en kryptering, der er sårbar over for denne type angreb, er simpel substitutionskryptering. I denne kryptering repræsenterer nøgle en tabel, der erstatter alle bogstaver. For eksempel, ‘g’ erstattes med ‘h’, ‘o’ med ‘j’. Derfor bliver ordet ‘go’ til ‘hj’. Denne kryptering er svær at bryde med simpel brute force, da der er meget mange mulige substitutions-tabeller. Hvis du er interesseret i matematik, er den effektive nøglelængde omkring 88 bit: dette
. Men hyppighedsanalyse klarer normalt hurtigt opgaven.

Lad os overveje den følgende krypterede tekst, der er behandlet med en simpel substitutionscypher:

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

Da Y forekommer ofte, herunder i slutningen af mange ord, kan vi preliminært antage, at dette er bogstavet e:

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

Par XD gentages i starten af flere ord. Specifikt antyder kombinationen XDeLe tydeligt et ord these eller there, så vi fortsætter:

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

Lad os herefter antage, at L svarer til r, A — en og så videre. Det vil sandsynligvis kræve flere forsøg, men sammenlignet med en komplet brute force, genopretter denne angrebsteknik den oprindelige tekst på kort tid:

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

For nogle er løsningen på sådanne "kryptogrammer" et fascinerende hobby.

Ideen om hyppighedsanalyse er mere fundamental, end det ser ud ved første øjekast. Den er anvendelig til meget mere komplekse koder. Gennem historien har forskellige krypteringskonstruktioner forsøgt at modstå sådanne angreb ved hjælp af "polyalfabetisk substitution". Her ændres substitutionsbordet for bogstaverne under krypteringen på komplekse, men forudsigelige måder, der afhænger af nøglen. Alle disse koder blev engang anset for svære at bryde; alligevel overvandt den beskedne hyppighedsanalyse dem alle til sidst.

Den mest ambitiøse polyalfabetiske kode i historien og sandsynligvis den mest kendte var "Enigma"-koden under Anden Verdenskrig. Den var relativt kompleks i forhold til sine forgængere, men efter langvarigt og utrætteligt arbejde brydede britiske kryptanalytikere den med hyppighedsanalyse. Selvfølgelig kunne de ikke udvikle en elegant angrebsmåde, som den ovenfor viste; de måtte sammenligne kendte par af åbne og krypterede tekster (den såkaldte "åben tekst angreb") og endda provokere brugerne af "Enigma" til at kryptere bestemte beskeder med efterfølgende analyse af resultatet ("angreb baseret på tilpasset åben tekst"). Men dette lettede ikke skæbnen for de besejrede hære af fjender og de sænkede ubåde.

Efter denne triumf forsvandt frekvensanalysen fra kryptanalysens historie. Koderne i den moderne digitale æra er designet til at arbejde med bits og ikke bogstaver. Endnu vigtigere er det, at disse koder er udviklet med en dystopisk forståelse af, hvad der senere blev kendt som Schneier-loven: enhver kan skabe en krypteringsalgoritme, som de ikke selv kan bryde. Det er ikke tilstrækkeligt, at krypteringssystemet virker komplekst: for at bevise sin værdi skal det gennemgå en nådesløs sikkerhedsrevision fra mange kryptanalytikere, der vil gøre alt for at bryde koden.

Forudgående beregninger

Lad os tage den hypotetiske by Precom Heights med en befolkning på 200.000 mennesker. I hver husstand i byen er der værdigenstande til gennemsnitligt $30.000, men ikke mere end $50.000. Sikkerhedsmarkedet i Precom er monopoliseret af ACME Industries, der producerer den legendariske Coyote ™ dørklæb. Ifølge eksperternes analyse kan Coyote-klassen kun brydes af en meget kompleks hypotetisk maskine, hvis konstruktion kræver omkring fem år og $50.000 i investering. Er byen sikker?

Sandsynligvis ikke. I sidste ende vil der komme en tilstrækkeligt ambitiøs kriminel. Han vil tænke sådan: "Ja, jeg vil pådrage mig store omkostninger. Fem års tålmodig venten og $50.000. Men når arbejdet er færdigt, vil jeg have adgang til alle rigdomme i denne by. Hvis jeg spiller mine kort rigtigt, vil denne investering betale sig mange gange tilbage."

Det samme gælder for kryptografi. Angreb mod en bestemt kode underkastes en ubarmhjertelig vurdering af omkostninger og fordele. Hvis forholdet er gunstigt, vil angrebet ikke finde sted. Men angreb, der tærer på mange mulige ofre, betaler næsten altid sig, og i dette tilfælde er den bedste designpraksis at forudsætte, at de er startet fra dag ét. Vi har i det væsentlige en kryptografisk version af Murphys lov: "Alt, hvad der reelt kan bryde systemet, vil bryde systemet."

Et simpelt eksempel på et kryptosystem, der er sårbart over for angreb med forudgående beregninger, er en kode med en konstant algoritme uden brug af en nøgle. Sådan var det med Cæsarkoden, som blot forskyder hver bogstav i alfabetet tre bogstaver fremad (tabellen er cirkulær, så det sidste bogstav i alfabetet krypteres med det tredje). Her kommer endnu en gang Kerchhoff-princippet til udtryk: så snart systemet er brudt, er det brudt for altid.

Konceptet er simpelt. Selv en nybegynder i kryptografi er sandsynligvis klar over truslen og forbereder sig derefter. Hvis man ser på evolutionen af kryptografi, var sådanne angreb irrelevante for de fleste krypteringer, fra de første forbedrede versioner af Cæsar-krypteringen til nedgangen af polyalfabetiske krypteringer. Sådanne angreb kom først tilbage med den moderne æra af kryptografi.

Denne tilbagevenden skyldes to faktorer. For det første er der endelig blevet udviklet komplekse nok kryptosystemer, hvor mulighederne for udnyttelse efter brud ikke var åbenlyse. For det andet har kryptografi fået sådan en udbredelse, at millioner af ikke-professionelle hver dag træffer beslutninger om, hvor og hvilke dele af kryptografi der skal genbruges. Det tog noget tid, før eksperterne indså de opstående risici og gav alarm.

Husk angrebet med forudberegninger: i slutningen af artiklen vil vi se på to kryptografiske eksempler fra virkeligheden, hvor det spillede en vigtig rolle.

Interpolation

Foran dig står den berømte detektiv Sherlock Holmes og udfører et angreb med interpolation på den uheldige Dr. Watson:

Jeg gættede straks, at du kom fra Afghanistan... Mine tanker var som følger: «Denne mand er læge af profession, men hans fremtoning er militær. Så han er militærlæge. Han er netop kommet fra troperne - hans ansigt er mørkt, men det er ikke den naturlige farve af hans hud, da hans håndled er meget lysere. Ansigtet er udmattet - tydeligvis har han lidt meget og lidt sygdom. Han er blevet såret i venstre arm - han holder den stille og en smule unaturligt. Hvor kunne en britisk militærlæge i troperne have lidt og fået et sår? Selvfølgelig i Afghanistan». Hele tankegangen tog ikke mere end et sekund. Og så sagde jeg, at du kom fra Afghanistan, og du blev overrasket.

Fra hver enkelt skuffe kunne Holmes udlede meget lidt information. Han kunne kun nå sin konklusion ved at overveje dem alle sammen. Ligeledes fungerer interpolationsangrebet, som udforsker kendte par af åben og krypteret tekst, der er opnået ved anvendelse af den samme nøgle. Fra hvert par udtrækkes individuelle observationer, som gør det muligt at lave en samlet konklusion om nøglen. Alle disse ræsonneringer er diffuse og synes nytteløse, indtil de pludselig når en kritisk masse og fører til den eneste mulige konklusion: uanset hvor usandsynlig den måtte være, må den være sand. Herefter afsløres nøglen, eller dekrypteringsprocessen bliver så raffineret, at den kan reproduceres.

Lad os illustrere med et simpelt eksempel, hvordan interpolation fungerer. Lad os antage, at vi ønsker at læse vores fjendes, Bobs, dagbog. Han krypterer hvert nummer i sin dagbog ved hjælp af et simpelt kryptosystem, som han lærte om gennem en reklame i tidsskriftet 'Spøg med kryptografi'. Systemet fungerer på følgende måde: Bob vælger to tal, som han kan lide: og . Fra dette øjeblik, for at kryptere et hvilket som helst tal , beregner han . For eksempel, hvis Bob har valgt og , så krypteres tallet som .

. Antag, at den 28. december bemærkede vi, at Bob skrev noget i sin dagbog. Når han er færdig, sniger vi os til at tage den og se den seneste optegnelse:

Dato: 235/520
Kærlig dagbog,
I dag var det en god dag. Om 64 dage har jeg en date med Alice, som bor i lejlighed 843. Jeg tror virkelig, at hun kan være 26!

Da vi ganske seriøst ønsker at overvåge Bob på hans date (i dette scenarie er vi 15 år gamle), er det kritisk vigtigt at finde ud af datoen samt Alices adresse. Heldigvis bemærker vi, at Bobs kryptosystem er sårbart over for interpolationsangreb. Vi må muligvis ikke kende og , men vi kender dagens dato, så vi har to par 'åben tekst - krypteret tekst'. Det vil sige, at vi ved, at krypteres til , og — i . Hvilket vi vil skrive ned:

Da vi er 15 år, ved vi allerede om systemet med to ligninger med to ubekendte, hvilket i denne situation er tilstrækkeligt til at finde. og uden større problemer. Hver par "klar tekst-krypteret tekst" pålægger en begrænsning på Bobs nøgle, og to begrænsninger sammen er tilstrækkelige til fuldstændigt at genskabe nøglen. I vores eksempel svar og (ved , så 26 i dagbogen svarer til ordet 'the one', det vil sige "den ene" — red.

Interpolationsangreb er selvfølgelig ikke begrænset til så enkle eksempler. Hver kryptosystem, der reduceres til et godt forståeligt matematik objekt og en liste af parametre, er i risiko for interpolationsangreb — jo mere forståeligt objektet er, desto højere er risikoen.

Begyndere klager ofte over, at kryptografi er "kunsten at designe så grimme ting som muligt". Sandsynligvis er angreb på interpolation meget medskyldige. Bob kan vælge enten at bruge et elegant matematisk design eller at beskytte privatlivets fred for sit møde med Alice — men desværre, man kan som regel ikke få begge dele. Dette bliver meget klart, når vi til sidst bevæger os hen til emnet kryptering med offentlig nøgle.

Krydskommando/nedgradering

I filmen "Illusions of Deception" (2013) forsøger en gruppe illusionister at bedrage og stjæle hele formuen fra den korrupte forsikringsmagnat Arthur Tressler. For at få adgang til Arthurs bankkonto skal illusionisterne enten præsentere sit brugernavn og adgangskode eller tvinge ham til personligt at møde op i banken og deltage i planen.

Begge valgmuligheder er meget svære; fyrene er vant til at optræde på scenen, ikke at deltage i efterretningstjenester. Derfor vælger de den tredje mulighed: deres medhjælper ringer til banken og later som om han er Arthur. Banken stiller et par kontrolspørgsmål som f.eks. navnet på onklen og navnet på det første kæledyr; vores helte får nemt denne information ud af Arthur ved hjælp af smart social engineering. Fra dette punkt bliver god adgangskode-sikkerhed ikke længere vigtig.

(Ifølge en bymyte, som vi personligt har tjekket og bekræftet, stødte kryptografen Eli Biham engang på en bankmand, der insisterede på at etablere et hemmeligt spørgsmål. Da bankmanden spurgte om navnet på bedstemor på mors side, begyndte Biham at diktere: „Store X, lille y, tre…“).

I kryptografi, hvis to kryptografiske protokoller bruges parallelt til at beskytte den samme aktiv, hvor den ene er meget svagere end den anden, bliver det samlede system sårbart over for en krydsprotokol-angreb. Dette sker, når den svagere protokol angribes for at nå frem til præmien uden at berøre den stærkere.

I nogle komplekse tilfælde er det ikke tilstrækkeligt blot at oprette forbindelse til serveren via den svagere protokol; der kræves et utilsigtet deltagelse fra den legitime kunde. Dette kan organiseres ved hjælp af en såkaldt nedgraderingsangreb (downgrade). For at forstå dette angreb, lad os antage, at vores illusionister har en mere kompleks opgave end i filmen. Antag, at en bankmedarbejder (kasserer) og Arthur står over for nogle uventede omstændigheder, hvilket resulterer i denne dialog:

Hacker: Hej? Det er Arthur Tresler. Jeg vil gerne gendanne mit kodeord.
Kasserer: Fint. Venligst kig i din personlige bog med hemmelige koder, side 28, ord 3. Alle følgende meddelelser vil være krypteret med dette specifikke ord som nøgle. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Hey hey, vent lidt. Er det virkelig nødvendigt? Kan vi ikke bare tale som normale mennesker?
Kasserer: Det ville jeg ikke anbefale at gøre.
Hacker: Jeg er bare… hør, jeg har haft en dårlig dag, okay? Jeg er VIP-klient og er ikke i humør til at rode med de tåbelige kodebøger.
Kasserer: Okay. Hvis du insisterer, hr. Tresler. Hvad kan jeg gøre for dig?
Hacker: Venligst, jeg vil gerne overføre alle mine penge til Det Nationale Fond for Ofre for Arthur Tresler.
(Pause).
Kasserer: Okay, forstået. Venligst oplys din pin-kode for store transaktioner.
Hacker: Min hvad?
Kasserer: Efter din personlige anmodning kræver transaktioner af denne størrelse indtastning af pin-koden for store transaktioner. Denne kode blev givet til dig ved åbningen af kontoen.
Hacker:… Jeg har tabt den. Er det virkelig nødvendigt? Kan du ikke bare godkende transaktionen?
Kasserer: Nej. Jeg beklager, hr. Tresler. Igen, det er en sikkerhedsforanstaltning, som du anmodede om. Hvis du ønsker det, kan vi sende en ny pin-kode til din postkasse.

Vore helte udsætter operationen. De lytter til flere store transaktioner fra Tressler og håber at høre PIN-koden; men hver gang bliver samtalen til uforståelig mumlen, før der bliver sagt noget interessant. Endelig, en smuk dag, sættes planen i gang. De venter tålmodigt på det øjeblik, hvor Tressler skal foretage en stor telefontransaktion, han går på linjen, og så…

Tressler: Hej. Jeg vil gerne foretage en fjerntransaktion, tak.
Kasserer: Perfekt. Venligst se i din personlige hemmelige kodebog, side…
(Hacker trykker på knappen; kassereren ændrer stemme til uforståeligt støj).
Kasserer: — #@$#@$#*@$$@#* vil blive krypteret med dette ord som nøgle. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Undskyld, jeg forstod ikke helt. Kan du gentage? Hvilken side? Hvilket ord?
Kasserer: Det er side @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Hvad?
Kasserer: Ord nummer tyve @$#@$#%#$.
Tressler: Det er alvorligt! Kom nu! Jeres sikkerhedsprotokol er en slags cirkus. Jeg ved, at du bare kan tale normalt med mig.
Kasserer: Jeg vil ikke anbefale…
Tressler: Og jeg anbefaler ikke, at du spilder min tid. Jeg vil ikke høre mere om dette, før I har fikset problemerne med jeres telefonlinje. Kan vi få denne aftale igennem eller ej?
Kasserer:… ja. Okay. Hvad kan jeg hjælpe dig med?
Tressler: Jeg vil gerne overføre $20,000 til firmaet Lord Business Investments, kontonummer…
Kasserer: Et øjeblik, tak. Det er en stor handel. Angiv venligst din PIN-kode for store transaktioner.
Tressler: Hvad? Åh, selvfølgelig. 1234.

Her er et angreb for nedadgående. Den svagere protokol 'bare sig det lige ud' var ment som mulighed en nødplan. Og alligevel er vi her.

Man kan spørge, hvem der i sund fornuft ville designe et faktisk system som 'sikkert, indtil der bliver bedt om det', som beskrevet ovenfor. Men ligesom en fiktiv bank påtager sig risikoen for at beholde kunder, der ikke bryder sig om kryptografi, så bøjer systemer sig ofte mod krav, der er ligeglade med eller endda åbent modsat sikkerhed.

En sådan historie fandt sted med SSLv2-protokollen i 1995. Den amerikanske regering havde længe set på kryptografi som et våben, der bedst bør holdes væk fra både eksterne og interne fjender. Kodefragmenter blev individuelt godkendt til eksport fra USA, ofte under betingelse af, at algoritmen blev svækket med vilje. Netscape, udvikleren af den mest populære browser Netscape Navigator, fik tilladelse til SSLv2 kun med en oprindeligt sårbar RSA 512-bit nøgle (og 40 bit for RC4).

Ved årtusindeskiftet blev reglerne lempet, og adgangen til moderne kryptering blev bredt tilgængelig. Ikke desto mindre havde klienter og servere i mange år opretholdt svækket 'eksport'-kryptografi på grund af den samme inerti, der førte til opretholdelse af enhver forældet system. Klienter troede, de kunne støde på en server, der ikke understøttede noget andet. Servere gjorde det samme. Selvfølgelig dikterer SSL-protokollen, at klienter og servere aldrig bør bruge en svag protokol, når der er en bedre tilgængelig. Men den samme præmis gjaldt for Tressler og hans bank.

Denne teori blev anvendt i to opsigtsvækkende angreb, der én efter én rystede sikkerheden omkring SSL-protokollen i 2015, begge opdaget af Microsoft-forskere og INRIA. Først i februar blev detaljerne om FREAK-angrebet offentliggjort, og tre måneder senere endnu et lignende angreb kaldet Logjam, som vi vil diskutere mere detaljeret, når vi når frem til angreb på offentlig nøglekryptografi.

Sårbarhed FREAK (også kendt som 'Smack TLS') viste sig, da forskere analyserede TLS-klient/server-implementationer og opdagede en underlig fejl. I disse implementationer, hvis klienten ikke engang beder om at bruge svag eksportkryptografi, men serveren stadig svarer med sådanne nøgler – siger klienten 'Nå, okay' og skifter til det svage sæt af krypteringer.

Dengang blev eksportkryptografi betragtet som forældet og forbudt at bruge, så angrebet kom som et chok og berørte mange vigtige domæner, herunder hjemmesiderne for Det Hvide Hus, den amerikanske skattemyndighed og NSA. Værre var det, at mange udsatte servere havde optimeret ydeevnen ved at genbruge de samme nøgler i stedet for at skabe nye til hver session. Dette muliggjorde efter nedgraderingen af protokollen også et forudberegningsangreb: at bryde én nøgle forblev relativt dyrt (100 $ og 12 timer på tidspunktet for offentliggørelsen), men de praktiske omkostninger ved et angreb på forbindelsen faldt betydeligt. Det var nok at knække servernøglen én gang — og bryde krypteringen for alle efterfølgende forbindelser fra det øjeblik.

Og før vi går videre, skal vi nævne et avanceret angreb ...

Oracle-angreb

Moxie Marlinspike er bedst kendt som faderen til den tværgående kryptomessenger Signal; men vi har personligt en forkærlighed for et af hans mindre kendte innovationer — princippet om kryptografisk undergang (Cryptographic Doom Principle). Let omformuleret kan man sige: "Hvis protokollen udfører enhver kryptografisk operation på en besked fra en potentielt skadelig kilde og opfører sig forskelligt afhængigt af resultatet, så er den dømt." Eller i mere dramatiske termer: "Tag ikke information fra fjenden til behandling, og hvis du er nødt til, så vis i det mindste ikke resultatet."

Lad os se bort fra bufferoverskridelser, kommandointjek og lignende; de ligger uden for denne diskussion. At overtræde "undergangs princippet" fører til alvorlige brud på kryptografi, fordi protokollen opfører sig præcist som tiltænkt.

Som et eksempel kan vi tage en opdigtet konstruktion med en sårbar substitueringscipher, og så demonstrere et muligt angreb. Selvom vi allerede har set et angreb på substitueringscipheren ved hjælp af frekvensanalyse, er dette ikke bare "en anden måde at bryde den samme cipher på". Tværtimod er oracle-angreb et meget mere moderne opfindelse, der kan anvendes på mange situationer, hvor frekvensanalyse fejler, og vi vil se en demonstration af dette i det næste afsnit. Her er den enkle cipher valgt kun for at gøre eksemplet mere forståeligt.

Så, Alice og Bob kommunikerer med en simpel substitutionskode, der bruger en nøgle, som kun de kender. De er meget strenge med længden på beskederne: deres længde er præcist 20 tegn. Derfor har de aftalt, at hvis nogen ønsker at sende en kortere besked, skal de tilføje en eller anden fiktiv tekst til slutningen af beskeden, så den er præcist 20 tegn. Efter noget diskussion besluttede de, at de kun ville acceptere følgende fiktive tekster: en, bb, ccc, dddd og så videre. Dermed er den fiktive tekst kendt i den nødvendige længde.

Når Alice eller Bob modtager en besked, kontrollerer de først, at beskeden har den korrekte længde (20 tegn), og at suffixet er den korrekte fiktive tekst. Hvis ikke, svarer de med en passende fejlmeddelelse. Hvis længden på teksten og den fiktive tekst er i orden, læser modtageren selve beskeden og sender et krypteret svar.

Under et angreb udgiver angriberen sig for at være Bob og sender falske beskeder til Alice. Beskederne er totalt nonsens - angriberen har ikke nøglen, og derfor kan han ikke forfalske en meningsfuld besked. Men da protokollen overtræder princippet om katastrofe, kan angriberen stadig narre Alice til at afsløre oplysninger om nøglen, som vist nedenfor.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Ugyldig fiktiv tekst.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Ugyldig fiktiv tekst.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Angriberen har ingen idé om, hvad Alice lige har sagt, men bemærker, at tegn C skal matche en, da Alice accepterede den fiktive tekst.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Ugyldig fiktiv tekst.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Ugyldig fiktiv tekst.
Efter flere forsøg…
Hacker: REWF ZHJKL MMMN. LGG
Alice: Ugyldig fiktiv tekst.
Hacker: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Igen har angriberen ingen idé om, hvad Alice lige har sagt, men bemærker, at H skal matche b, da Alice accepterede den fiktive tekst.

Og så videre, indtil angriberen kender betydningen af hvert tegn.

Ved første øjekast minder metoden om en angreb baseret på tilpasset plaintext. I sidste ende finder en angriber de krypterede tekster, som serveren lydigt behandler. Den primære forskel, der gør disse angreb levedygtige i den virkelige verden, er, at angriberen ikke har brug for adgang til selve dekrypteringen - det er tilstrækkeligt med et serversvar, selv noget så harmløst som «Forkert dummytekst».

Selvom dette specifikke angreb er lærerigt, bør man ikke hænge for meget fast i detaljerne i «dummytekst»-skemaet, den specifikke kryptosystem der anvendes, eller den præcise rækkefølge af beskeder sendt af angriberen. Hovedideen er, hvordan Alice reagerer forskelligt baseret på egenskaberne af plaintext, og gør dette uden at tjekke om den relevante krypterede tekst faktisk er modtaget fra en betroet part. På den måde tillader Alice angriberen at presse hemmelig information ud fra hendes svar.

I dette scenarie kan der ændres meget. Symbolerne, som Alice reagerer på, eller selve forskellen i hendes adfærd, eller endda det anvendte kryptosystem. Men princippet vil forblive det samme, og angrebet vil generelt forblive levedygtigt i en eller anden form. Den grundlæggende implementering af dette angreb har hjulpet med at opdage flere sikkerhedsfejl, som vi snart vil se på; men først bør vi lære nogle teoretiske lektioner. Hvordan kan dette opdigtede «Alices scenario» bruges i et angreb, der kan fungere på en moderne kryptering? Er det overhovedet muligt, selv i teori?

I 1998 svarede den schweiziske kryptograf Daniel Bleichenbacher bekræftende på dette spørgsmål. Han demonstrerede et orakelangreb i et vidt anvendt offentlig-nøgle kryptosystem RSA, ved hjælp af et bestemt beskedskema. I nogle implementeringer af RSA svarer serveren med forskellige fejlmeldinger, afhængigt af om plaintexten overholder skemaet eller ej; dette var tilstrækkeligt til at udføre angrebet.

Fire år senere, i 2002, demonstrerede den franske kryptograf Serge Vaudenay en orakelangreb, der var næsten identisk med det, der er beskrevet ovenfor i Alicias scenarie - bortset fra at han i stedet for en opdigtet kryptering brød et helt respekteret sæt af moderne krypteringer, som folk faktisk bruger. Specifikt målrettede Vaudenays angreb mod krypteringer med fast inputstørrelse ('blokke krypteringer'), når de anvendes i den såkaldte 'CBC-krypteringsmetode' og med en bestemt populær fyldeskema, der stort set svarer til det, der er beskrevet i Alicias scenarie.

Også i 2002 foreslog den amerikanske kryptograf John Kelsey - medforfatter. Twofish – forskellige orakelangreb på systemer, der komprimerer meddelelser og derefter krypterer dem. Den mest bemærkelsesværdige blandt dem var et angreb, der udnyttede, at den oprindelige længde af klarteksten ofte kunne udledes fra længden af den krypterede tekst. Teoretisk set muliggør dette et orakelangreb, som gendanner dele af den oprindelige klartekst.

Her giver vi en mere detaljeret beskrivelse af angrebene fra Vaudenay og Kelsey (vi vil give en mere detaljeret beskrivelse af Bleichenbachers angreb, når vi kommer til angreb på asymmetrisk kryptografi). På trods af alle vores bestræbelser bliver teksten en smule teknisk; derfor, hvis det ovenstående er tilstrækkeligt for dig, så spring de næste to afsnit over.

Vaudenays angreb

For at forstå Vaudenays angreb, er det nødvendigt først at tale lidt mere om blokkrypteringer og krypteringsmetoder. 'Blokkryptering' er, som nævnt, en kryptering, der tager en nøgle og inddata af en bestemt fast længde ('bloklængde') og afleverer en krypteret blok af samme længde. Blokkrypteringer er bredt anvendt og betragtes som relativt sikre. Den nu pensionerede DES, som anses for at være den første moderne kryptering, var en blokbaseret kryptering. Som nævnt ovenfor er det samme gældende for AES, der i dag er meget udbredt.

Desværre har blokchiffer en åbenlys svaghed. Den typiske blokstørrelse er 128 bit eller 16 tegn. Det er åbenbart, at moderne kryptografi kræver at arbejde med inddata af større størrelse, og her kommer krypteringsmetoder ind i billedet. En krypteringsmetode er i bund og grund et hack: det er en måde at anvende et blokchiffer, som kun accepterer inddata af en bestemt størrelse, på inddata af vilkårlig længde.

Vodené-angrebet er rettet mod den populære arbejdsmåde CBC (Cipher Block Chaining, blokchiffrets kædning). Angrebet betragter det underliggende blokchiffer som en magisk uigennemtrængelig sort boks og omgår fuldstændigt dets sikkerhed.

Her er et diagram, der viser, hvordan CBC-metoden fungerer:

Den omkransede plus betyder XOR-operationen (eksklusiv "ELLER"). For eksempel er den anden blok af chifferteksten opnået ved:

At udføre XOR-operationen på den anden blok af klartekst med den første blok af chiffertekst.
At kryptere den resulterende blok med et blokchiffer ved hjælp af nøgle.

Da CBC så intensivt bruger binær XOR-operationen, lad os benytte lejligheden til at minde om nogle af dens egenskaber:

Idempotens:
Kommutativitet:
Associativitet:
Selv-inversion:
Byte-for-byte: byte n fra = (byte n fra ) (byte n fra )

Generelt implicerer disse egenskaber, at hvis vi har en ligning, der inkluderer XOR-operationer og en ukendt værdi, kan den løses. For eksempel, hvis vi ved, at med en ukendt og kendte og , så kan vi stole på de ovennævnte egenskaber for at løse ligningen for . Ved at anvende XOR på begge sider af ligningen med , får vi . Om et øjeblik vil alt dette blive meget relevant.

Mellem vores Alice-scenario og Vodené-angrebet er der to uvæsentlige forskelle og én hovedforskel. To uvæsentlige:

I Alices scenario forventede hun, at klarteksterne afsluttedes med tegnene en, bb, ccc og så videre. I Vodené-angrebet forventer offeret i stedet, at klarteksterne afsluttes med N gange byte N (det vil sige hex 01 eller 02 02, eller 03 03 03 og så videre). Dette er udelukkende en kosmetisk forskel.
I Alice-scenariet var det let at sige, om Alice modtog beskeden, baseret på svaret "Forkert fiktion tekst". I Vodené-angrebet kræves der en større analyse, og den præcise implementering på offerets side er vigtig; men for kortfattethed kan vi antage, at denne analyse stadig er mulig.

Den vigtigste forskel:

Da vi ikke bruger det samme kryptosystem, vil forbindelsen mellem de kontrollerede ondsindede bytes af krypteret tekst og hemmelighederne (nøgle og klartekst) åbenlyst være anderledes. Derfor bliver angriberen nødt til at bruge en anden strategi, når de skaber chiffertekster og fortolker serverens svar.

Denne vigtigste forskel er det sidste stykke puslespil for at forstå angrebet Vodené, så lad os et øjeblik tænke over, hvorfor og hvordan et oracle-angreb på CBC overhovedet kan organiseres.

Lad os antage, at vi har en CBC-chiffertekst bestående af 247 blokke, og vi ønsker at dekryptere den. Vi kan sende falske beskeder til serveren, ligesom vi tidligere kunne sende falske beskeder til Alice. Serveren vil dekryptere beskederne for os, men vil ikke vise dekrypteringen — i stedet vil serveren, ligesom i tilfældet med Alice, kun give én bit information: om der er en gyldig fyldning i klarteksten eller ej.

Bemærk, at vi i Alice-scenariet havde følgende relationer:

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

Lad os kalde dette "Alice-ligningen". Vi kontrollerede chifferteksten; serveren (Alice) afslørede uskarp information om den modtagne klartekst; og dette gjorde det muligt for os at udlede information om den sidste faktor — nøgle. Tilsvarende, hvis vi kan finde en sådan forbindelse for CBC-scenariet, kunne vi udtrække nogle hemmelige oplysninger der.

Heldigvis findes der faktisk relationer, som vi kan bruge. Lad os se på output fra den endelige dekrypteringsopkald af blokcifferet og betegne disse data som . Lad os også betegne blokke af klartekst og blokke af chiffertekst . Se igen på CBC-diagrammet og bemærk, hvad der sker:

Lad os kalde dette "CBC-ligningen".

I Alice-scenariet, ved at kontrollere chifferteksten og observere lækager af information om den tilsvarende klarskrift, var vi i stand til at organisere et angreb, der gendannede den tredje komponent i ligningen - nøglen. I CBC-scenariet kontrollerer vi også chifferteksten og observerer lækager af information om den tilsvarende klarskrift. Hvis analogien holder, kan vi få information om .

Lad os antage, at vi faktisk har gendannet , hvad så? Nå, så kan vi straks udtrække hele den sidste blok af klarskrift (), blot ved at indtaste (som vi har) og
den opnåede i CBC-ligningen.

Så vi er optimistiske med hensyn til den overordnede angrebsplan, og det er tid til at arbejde på detaljerne. Vi bemærker, hvordan der præcist sker lækager af information om klarskrift på serveren. I Alice-scenariet skete lækagen, fordi Alice kun svarede med det rigtige svar, hvis $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ sluttede med strengen en (eller bb, osv., men chancerne for tilfældigt at udløse disse betingelser var meget små). Tilsvarende i CBC accepterer serveren fyldningen, hvis og kun hvis slutter med en hexadecimal 01. Lad os prøve det samme trick: at sende falske chiffertekster med vores egne falske værdier , indtil serveren accepterer fyldningen.

Når serveren accepterer fyldningen for en af vores falske meddelelser, betyder det, at:

Lad os nu bruge egenskaben ved byte-for-byte XOR:

Vi kender den første og tredje komponent. Og vi har allerede set, at dette gør det muligt at gendanne den resterende komponent - den sidste byte fra :

Dette giver os også den sidste byte af den endelige blok klarskrift gennem CBC-ligningen og byte-for-byte egenskaben.

Vi kunne afslutte her og være tilfredse med, at vi har udført et angreb på en teoretisk sikker kryptering. Men i virkeligheden kan vi gøre meget mere: vi kan faktisk gendanne hele teksten. Dette kræver et bestemt trick, som ikke var i det originale Alice-scenario, og som ikke indgår i de obligatoriske betingelser for orakelangreb, men metoden er stadig værd at undersøge.

For at forstå dette skal du først bemærke, at resultatet af at udlede den korrekte værdi af den sidste byte Vi har en ny evne. Nu kan vi styre den sidste byte af den tilsvarende klare tekst, når vi forfalsker chiffertekstene. Dette er igen relateret til CBC-ligningen og byte-by-byte egenskaben:

Da vi nu kender det andet medlem, kan vi bruge vores kontrol over det første til at styre det tredje. Vi beregner simpelthen:

Tidligere kunne vi ikke gøre dette, fordi vi endnu ikke havde den sidste byte. .

Hvordan hjælper dette os? Antag, at vi nu genererer alle chiffertekster, så den tilsvarende klare teksts sidste byte er 02. Serveren accepterer nu fyldningen kun, hvis den klare tekst slutter med 02 02. Da vi har rettet den sidste byte, vil dette kun ske, hvis den næstsidste byte af den klare tekst også er lig med 02. Vi fortsætter med at sende falske chifferblokke, idet vi ændrer den næstsidste byte, indtil serveren accepterer fyldningen for en af dem. På det tidspunkt får vi:

Og vi gendanner den næstsidste byte på præcist samme måde som vi gendannede den sidste. Vi fortsætter i samme ånd: retter de sidste to bytes af den klare tekst til 03 03, gentager dette angreb for den tredje fra slutbyte og så videre, indtil vi fuldstændigt gendanner .

Hvad med resten af teksten? Bemærk, at værdien faktisk er $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Vi kan sætte enhver anden blok i stedet for , og angrebet vil stadig være succesfuldt. I virkeligheden kan vi bede serveren om at udføre $inline$text{BLOCK_DECRYPT}$inline$ for vilkårlige data. På det tidspunkt er spillet slut – vi kan dekryptere enhver chiffertekst (tag et kig på dekrypteringsdiagrammet for CBC for at bekræfte dette; og bemærk, at IV-vektoren er offentligt tilgængelig).

Denne specifikke metode spiller en afgørende rolle i oracle-angrebet, som vi vil møde senere.

Kelsey-angrebet

Den åndeligt beslægtede John Kelsey udlagde principperne bag mange mulige angreb, ikke kun de detaljerede aspekter af et specifikt angreb på en bestemt chiffer. Hans artikel fra 2002 er en undersøgelse af mulige angreb på krypterede komprimerede data. Troede du, at der kun var behov for én oplysning til at udføre et angreb, nemlig at dataene var komprimeret før kryptering? Det viser sig, at det er nok.

Dette forbløffende resultat skyldes to principper. For det første er der en stærk korrelation mellem længden af den åbne tekst og længden af chifferteksten; for mange koder er der præcist lighed. For det andet, når der udføres kompression, er der også en stærk korrelation mellem længden af den komprimerede besked og graden af "støj" i den åbne tekst, det vil sige andelen af unikke tegn (teknisk term - "stor entropi").

For at se princippet i aktion, lad os overveje to åbne tekster:

Åben tekst 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Åben tekst 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Lad os antage, at begge åbne tekster er komprimeret og derefter krypteret. Du får to resulterende chiffertekster og skal gætte, hvilken chiffertekst der svarer til hvilken åben tekst:

Chiffertekst 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Chiffertekst 2: DWKJZXYU

Svaret er klart. Blandt de åbne tekster kunne kun åben tekst 1 være blevet komprimeret til den beskedne længde af den anden chiffertekst. Vi fandt ud af dette uden at vide noget om komprimeringsalgoritmen, krypteringsnøglen eller endda selve koden. Sammenlignet med hierarkiet af mulige kryptografiske angreb er dette en form for vanvid.

Kelsey angiver desuden, at under visse usædvanlige omstændigheder kan dette princip også bruges til at udføre et orakelangreb. Især beskriver han, hvordan en angriber kan genoprette den hemmelige åben tekst, hvis han kan få serveren til at kryptere data fra en formular (åben tekst efterfulgt af , mens han kontrollerer og kan på en eller anden måde kontrollere længden af den krypterede resultat.

Igen, ligesom i andre orakelangreb, har vi et forhold:

Igen, vi kontrollerer et medlem (), ser en lille lækage af information om det andet medlem (chiffertekst) og forsøger at genoprette det sidste (åben tekst). På trods af analogien er det en noget usædvanlig situation sammenlignet med andre orakelangreb, vi har set.

For at illustrere, hvordan et sådant angreb kan fungere, bruger vi et fiktivt kompressionsskema, som vi lige har opfundet: TOYZIP. Det søger efter tekststrenge, der tidligere er blevet vist i teksten, og erstatter dem med tre fyldbytes, der angiver, hvor man kan finde en tidligere forekomst af strengen, og hvor mange gange den optræder der. For eksempel strengen helloworldhello kan komprimeres til helloworld[00][00][05] en længde på 13 byte i forhold til originalen på 15 byte.

Lad os antage, at en hacker forsøger at genskabe den åbne tekst af formularen password=..., hvor selve adgangskoden er ukendt. I henhold til Kelsey-angrebsmodellen kan hackeren anmode serveren om at komprimere og derefter kryptere formularbeskederne (den åbne tekst efterfulgt af ), hvor — vilkårlig tekst. Når serveren er færdig, rapporterer den længden af resultatet. Angrebet fortsætter således:

Hacker: Venligst komprimer og krypter den åbne tekst uden nogen fyld.
Server: Resultatlængde 14.
Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=a.
Server: Resultatlængde 18.

Hackeren bemærker: [original 14] + [tre bytes, der erstattede password=] + en

Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=b.
Server: Resultatlængde 18.
Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=с.
Server: Resultatlængde 17.

Hackeren bemærker: [original 14] + [tre bytes, der erstattede password=c]. Dette antyder, at den originale åbne tekst indeholder strengen password=c. Det vil sige, at adgangskoden begynder med bogstavet c

Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=сa.
Server: Resultatlængde 18.

Hackeren bemærker: [original 14] + [tre bytes, der erstattede password=с] + en

Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=сb.
Server: Resultatlængde 18.

(… noget tid senere…)

Hacker: Venligst komprimer og krypter den åbne tekst, som har tilføjet password=со.
Server: Resultatlængde 17.

Hackeren bemærker: [original 14] + [tre bytes, der erstattede password=co]. I henhold til den samme logik konkluderer hackeren, at adgangskoden begynder med bogstaverne co

Og så videre, indtil hele adgangskoden er genskabt.

Det er forståeligt for læseren at tro, at dette kun er en akademisk øvelse, og at et sådant angrebsscenario aldrig vil opstå i den virkelige verden. Desværre, som vi snart vil se, er det bedst ikke at tage fejl i kryptografi.

Brandbare sårbarheder: CRIME, POODLE, DROWN

Endelig, efter en grundig gennemgang af teorien, kan vi se, hvordan disse metoder anvendes i virkelige kryptografiske angreb.

CRIME

Hvis angrebet er rettet mod browseren og offerets netværk, vil noget være lettere, og noget vil være sværere. For eksempel er det let at se offerets trafik: bare sidde i det samme café med dem med WiFi. Derfor anbefales det generelt til potentielle ofre (dvs. alle) at bruge en krypteret forbindelse. Det vil være mere kompliceret, men stadig muligt at udføre HTTP-anmodninger på vegne af offeret til en anden hjemmeside (f.eks. Google). Angriberen skal lokke offeret til en ondsindet webside med et script, der laver anmodningen. Webbrowseren vil automatisk give den relevante sessionscookie.

Det virker forbløffende. Hvis Bob besøgte evil.com, kan denne script på denne hjemmeside virkelig bede Google om at sende Bobs adgangskode via e-mail til angriber@ondskab.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), og det var populært cirka i midten af 90'erne. I dag, hvis evil.com man prøver et sådant trick, vil Google (eller enhver respektabel hjemmeside) normalt svare: „Fint, men din CSRF-token til denne transaktion vil være… øh… tre trillioner og syv. Venligst gentag dette nummer.” Moderne browsere anvender noget, der hedder „samme oprindelse politik” (same-origin policy), som betyder, at scripts på hjemmeside A ikke får adgang til oplysninger sendt af hjemmeside B. Derfor kan scriptet på evil.com send anmodninger til google.com, men kan ikke læse svarene eller faktisk afslutte transaktionen.

Vi må understrege, at hvis Bob ikke bruger en krypteret forbindelse, så er alle disse sikkerhedsforanstaltninger meningsløse. Angriberen kan blot læse Bobs trafik og genskabe Googles session cookie. Med denne cookie kan han bare åbne et nyt faneblad i Google, uden at logge ud af sin egen browser, og udgive sig for Bob uden at støde på de irriterende samme oprindelse politikker. Men, desværre for angriberen, sker dette stadig sjældnere. Internettet har længe erklæret krig mod ukrypterede forbindelser, og Bobs udgående trafik er sandsynligvis krypteret, uanset om han kan lide det eller ej. Desuden har trafik siden protokolens indførelse også blive komprimeret før kryptering; dette har været almindelig praksis for at reducere latenstid.

Her kommer CRIME (Compression Ratio Infoleak Made Easy, simpel lækage gennem komprimeringsforhold). Sårbarheden, som sikkerhedsforskerne Giuliano Rizzo og Thai Duong præsenterede i september 2012. Vi har allerede gennemgået hele den teoretiske baggrund, der gør det muligt at forstå, hvad de gjorde, og hvordan. Angriberen kan få Bobs browser til at sende anmodninger til Google og derefter lytte til svarene i det lokale netværk i komprimeret, krypteret form. Så derfor har vi:

Her kontrollerer angriberen anmodningen og har adgang til trafik snifferen, inklusive størrelsen af pakkerne. Det fiktive scenarie fra Kelsey er blevet realiseret.

Ved at forstå teorien skabte forfatterne til CRIME et exploit, der kan stjæle sessionscookies for en bred vifte af websteder, herunder Gmail, Twitter, Dropbox og Github. Sårbarheden ramte de fleste moderne webbrowser, hvilket resulterede i, at der blev udgivet patches, der stille begravede kompressionsfunktionen i SSL, så den overhovedet ikke blev brugt. Den eneste, der var beskyttet mod sårbarheden, var den hæderkronede Internet Explorer, som aldrig har brugt SSL-kompression.

POODLE

I oktober 2014 gav Googles sikkerhedsteam et væsentligt ryst på sikkerhedssamfundet. De formåede at udnytte en sårbarhed i SSL-protokollen, der blev rettet for mere end ti år siden.

Det viste sig, at selvom serverne kørte med den skønne nye TLSv1.2, efterlod mange support til den forældede SSLv3 for at opretholde bagudkompatibilitet med Internet Explorer 6. Vi har allerede nævnt nedgraderingsangreb, så du kan forestille dig, hvad der sker. En velorganiseret sabotage af handshakesprotokollen - og serverne er klar til at gå tilbage til gode gamle SSLv3, hvilket i realiteten annullerer de seneste 15 års forskning inden for sikkerhed.

For historisk kontekst, her er et kort resumé af SSL-historien indtil version 2 af Matthew Green:

Transport Layer Security (TLS) er den vigtigste sikkerhedsprotokol på internettet. [..] næsten hver transaktion, du foretager på internettet, afhænger af TLS. [..] Men TLS har ikke altid været TLS. Protokollen begyndte sit liv i Netscape Communications under navnet "Secure Sockets Layer" eller SSL. Der går rygter om, at den første version af SSL var så frygtelig, at udviklerne samlede alle koderne og begravede dem på en hemmelig losseplads i New Mexico. Som følge heraf er den første offentlige version af SSL faktisk versionen SSL 2. Den er ret skræmmende, og [..] det var et produkt fra midten af 90'erne, som moderne kryptografer betragter som "mørke tidsaldre inden for kryptografi". Mange af de mest afskyelige kryptografiske angreb, som vi kender i dag, var endnu ikke blevet opdaget. Derfor måtte udviklerne af SSLv2 i bund og grund famle sig frem i mørket, og de stødte på mange forfærdelige monstre — til deres fortrydelse og vores fordel, da angrebene på SSLv2 efterlod uvurderlige lektioner til næste generations protokoller.

Efter disse begivenheder, i 1996, reviderede det skuffede firma Netscape SSL-protokollen fra bunden. Resultatet blev SSL version 3, som rettede flere kendte sikkerhedsproblemer fra sin forgænger.

Heldigvis for hackere betyder "flere" ikke "alle". Generelt gav SSLv3 alle de nødvendige byggesten til at udføre en Vodené-attack. Protokollen anvendte en blokchiffer i CBC-tilstand og en usikker fyldningsskema (dette blev rettet i TLS; derfor opstod behovet for en nedgraderingattack). Hvis du husker fyldningsskemaet fra vores oprindelige beskrivelse af Vodené-angrebet, er SSLv3's skema meget lig.

Men desværre for hackere betyder "lig" ikke "identisk." SSLv3's fyldningsskema har formen "N vilkårlige bytes, efterfulgt af tallet N." Prøv i sådanne omstændigheder at vælge en imaginær blok af krypteret tekst og gennemgå alle trin i det oprindelige Vodené-scheme: du vil opdage, at angrebet succesfuldt udtrækker den sidste byte fra den tilsvarende blok af klartekst, men ikke går længere. At dekryptere hver 16. byte af krypteret tekst er et fremragende trick, men det er ikke en sejr.

I mødet med fiaskoen greb Google-teamet til en ekstrem løsning: de gik over til en mere kraftfuld trusselmodel - den, der blev anvendt i CRIME. Hvis vi antager, at angriberen er et script, der kører på offerets browserfane, og han kan udtrække sessioncookies, er angrebet stadig imponerende. Selvom den bredere trusselmodel er mindre realistisk, har vi allerede set i det forrige afsnit, at denne specielle model er gennemførlig.

Med sådanne kraftigere muligheder for en hacker kan angrebet nu fortsætte. Det skal bemærkes, at angriberen ved, hvor den krypterede session cookie fil vises i headeren, og han styrer længden af den forgående HTTP-anmodning. Derfor er han i stand til at manipulere HTTP-anmodningen, så den sidste byte af cookien justeres i forhold til slutningen af blokken. Nu er denne byte klar til dekryptering. Man kan blot tilføje et tegn til anmodningen, og den næstsidste byte af cookien forbliver på samme sted og kan bruges til at gætte på samme måde. Angrebet fortsætter således, indtil cookie-filen er fuldt genoprettet. Dette kaldes POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Som vi allerede har nævnt, havde SSLv3 nogle mangler, men den adskilte sig radikalt fra sin forgænger, fordi det hullete SSLv2 var et produkt fra en anden æra. Her kunne man afbryde meddelelsen halvvejs: vil jeg kun acceptere dette over mit lig blev til jeg vil acceptere dette; klienten og serveren kunne mødes på internettet, etablere tillid og udveksle hemmeligheder foran øjnene på angriberen, der derefter let kunne udgive sig for at være den ene eller den anden. Der var også problemet med eksportkryptering, som vi nævnte i forbindelse med FREAK. Det var et krypterings-Sodom og Gomorra.

I marts 2016 samlede et team af forskere fra forskellige tekniske områder sig og gjorde en bemærkelsesværdig opdagelse: SSLv2 bruges stadig i sikkerhedssystemer. Ja, angribere kunne ikke længere nedgradere moderne TLS-sessioner til SSLv2, da dette hul blev lukket efter FREAK og POODLE, men de kan stadig forbinde til servere og initiere SSLv2-sessioner selv.

Du spørger måske, hvad vi har at gøre med, hvad de laver? De har en sårbar session, men det skulle ikke påvirke andre sessioner eller serverens sikkerhed — rigtigt? Nå, ikke helt. Ja, sådan burde det være i teorien. Men nej — fordi genereringen af SSL-certifikater medfører en bestemt byrde, hvilket resulterer i, at mange servere bruger de samme certifikater og som følge heraf de samme RSA-nøgler til TLS- og SSLv2-forbindelser. Endnu værre, på grund af en fejl i OpenSSL, fungerede den populære implementering af SSLs mulighed for at "deaktivere SSLv2" faktisk ikke.

Dette har gjort det muligt at udføre en tværprotokolangreb på TLS, som blev kaldt DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, dekryptering af RSA med forældet og svækket kryptering). Lad os minde om, at dette ikke er det samme som en nedgraderingsangreb; angriberen behøver ikke at agere som "manden i midten" og behøver ikke at involvere klienten i en usikker session. Angriberne initierer blot selv en usikker SSLv2-session med serveren, angriber den svage protokol og genopretter den hemmelige server RSA-nøgle. Denne nøgle er også gyldig for TLS-forbindelser, og fra dette øjeblik vil ingen TLS-sikkerhed redde den fra brud.

Men for et brud er der brug for en fungerende angreb på SSLv2, som gør det muligt at genoprette ikke kun specifik trafik, men også den hemmelige server RSA-nøgle. Selvom dette er en kompleks opgave, kunne forskerne vælge enhver sårbarhed, der blev helt lukket efter SSLv2. Til sidst fandt de en passende mulighed: Bleichenbacher-angrebet, som vi tidligere har nævnt og vil uddybe i næste artikel. SSL og TLS er beskyttet mod dette angreb, men nogle tilfældige funktioner i SSL sammen med korte nøgler i eksportkryptering gjorde det muligt en bestemt implementering af DROWN.

På tidspunktet for offentliggørelsen var 25% af de øverste websteder på internettet sårbare over for DROWN, og angrebet kunne udføres med beskedne ressourcer, der var tilgængelige selv for frustrerede enkeltstående hackere. For at udvinde serverens RSA-nøgle krævedes der otte timers beregning og $440, og SSLv2 skiftede status fra "forældet" til "radioaktiv".

Vent, hvad med Heartbleed?

Det er ikke et kryptografisk angreb i den forstand, som beskrevet ovenfor; det er et buffer-overløb.

Lad os tage en pause

Vi begyndte med nogle grundlæggende metoder: brute force, interpolation, nedgradering, tværprotokol og forudberegning. Derefter så vi på en avanceret teknik, muligvis hovedkomponenten i moderne kryptografiske angreb: det er orakelangrebet. Vi har arbejdet ret længe med det - og forstod ikke kun princippet bag, men også de tekniske detaljer i to specifikke implementeringer: Wattenberg-angrebet på CBC-krypteringsmetoden og Kelsey-angrebet på krypteringsprotokoller med forudkomprimering.

I gennemgangen af angreb på svækkelse og med forudgående beregninger har vi kort opsummeret FREAK-angrebet, som bruger begge metoder, da de målrettede websteder falder tilbage til svage nøgler og derefter genbruger de samme nøgler. Til den næste artikel har vi forladt det (meget lignende) Logjam-angreb, som retter sig mod algoritmer med offentlige nøgler.

Derefter så vi på yderligere tre eksempler på anvendelse af disse principper. For det første CRIME og POODLE: to angreb, der stolede på angriberens evne til at indsætte vilkårlig klartekst ved siden af den målrettede klartekst, for så at studere serverens svar og derefter, ved at bruge orakelangrebsmetodologien, bruge denne sparsomme information til delvist at genoprette klarteksten. CRIME fulgte angrebsmetoden fra Kelsey angående SSL-komprimering, mens POODLE derimod brugte en variant af Waternecks CBC-angreb med samme effekt.

Derefter rettede vi opmærksomheden mod DROWN-angrebet, som etablerer forbindelse til serveren via den forældede SSLv2-protokol og derefter genopretter hemmelige servernøgler med Blyeckenbachers angreb. Indtil nu har vi sprunget de tekniske detaljer om dette angreb over; ligesom Logjam må det vente, indtil vi har studeret kryptosystemer med offentlige nøgler og deres sårbarheder grundigt.

I den næste artikel vil vi tale om avancerede angreb — såsom meet-in-the-middle metoden, differentiel kryptanalyse og fødselsdagsangreb. Vi vil tage en kort tur ind i angreb via sidekanaler, og derefter springe ind i det mest interessante — kryptosystemer med offentlige nøgler.

Kilde: habr.com