Når du hører ordet "kryptografi", husker noen folk sitt WiFi-passord, den grønne hengelåsen ved siden av adressen til favorittnettstedet deres, og hvor vanskelig det er å komme inn i andres e-post. Andre husker en rekke sårbarheter de siste årene med talende forkortelser (DROWN, FREAK, POODLE...), stilige logoer og en advarsel om å raskt oppdatere nettleseren din.

Kryptografi dekker alt, men essensen av i en annen. Poenget er at det er en fin linje mellom enkelt og komplekst. Noen ting er enkle å gjøre, men vanskelige å sette sammen igjen, som å knekke et egg. Andre ting er enkle å gjøre, men vanskelig å få tilbake når en liten, viktig, avgjørende del mangler: for eksempel å åpne en låst dør når den "avgjørende delen" er nøkkelen. Kryptografi studerer disse situasjonene og hvordan de kan brukes i praksis.

De siste årene har samlingen av kryptografiske angrep blitt til en dyrehage av prangende logoer, fylt med formler fra vitenskapelige artikler, og gitt opphav til en generell dyster følelse av at alt er ødelagt. Men faktisk er mange av angrepene basert på noen få generelle prinsipper, og endeløse sider med formler er ofte kokt ned til lettfattelige ideer.

I denne artikkelserien skal vi se på de ulike typene kryptografiske angrep, med vekt på de grunnleggende prinsippene. Generelt og ikke akkurat i denne rekkefølgen, men vi vil dekke følgende:

• Grunnleggende strategier: brute force, frekvensanalyse, interpolering, nedgradering og kryssprotokoller.
• Merkede sårbarheter: FREAK, KRIM, PUDLE, DRUKNE, Logjam.
• Avanserte strategier: orakelangrep (Vodenet-angrep, Kelsey-angrep); møte-i-midt-metoden, bursdagsangrep, statistisk skjevhet (differensiell kryptoanalyse, integrert kryptoanalyse, etc.).
• Sidekanalangrep og deres nære slektninger, feilanalysemetoder.
• Angrep på offentlig nøkkelkryptering: kuberot, kringkasting, relatert melding, Coppersmith-angrep, Pohlig-Hellman-algoritme, tallsikt, Wiener-angrep, Bleichenbacher-angrep.

Denne spesielle artikkelen dekker materialet ovenfor frem til Kelseys angrep.

Grunnleggende strategier

De følgende angrepene er enkle i den forstand at de nesten kan forklares fullstendig uten store tekniske detaljer. La oss forklare hver type angrep på de enkleste vilkårene, uten å gå inn på komplekse eksempler eller avanserte brukstilfeller.

Noen av disse angrepene har stort sett blitt foreldet og har ikke vært brukt på mange år. Andre er gammeldagse som fortsatt jevnlig sniker seg inn på intetanende kryptosystemutviklere i det 21. århundre. Tiden med moderne kryptografi kan anses å ha startet med bruken av IBM DES, den første chifferen som tålte hvert angrep på denne listen.

Enkel brute force

Krypteringsskjemaet består av to deler: 1) en krypteringsfunksjon som tar en melding (ren tekst) kombinert med en nøkkel og deretter produserer en kryptert melding – chiffertekst; 2) en dekrypteringsfunksjon som tar chifferteksten og nøkkelen og produserer klarteksten. Både kryptering og dekryptering må være enkle å beregne med nøkkelen – og vanskelig å finne ut uten den.

La oss anta at vi ser chifferteksten og prøver å dekryptere den uten tilleggsinformasjon (dette kalles kun chiffertekstangrep). Hvis vi på en magisk måte finner den riktige nøkkelen, kan vi enkelt verifisere at den faktisk er riktig hvis resultatet er en rimelig melding.

Merk at det er to implisitte antakelser her. For det første vet vi hvordan vi skal utføre dekryptering, det vil si hvordan kryptosystemet fungerer. Dette er en standard antagelse når man diskuterer kryptografi. Å skjule implementeringsdetaljene til chifferen for angripere kan virke som et ekstra sikkerhetstiltak, men når angriperen finner ut av disse detaljene, går denne ekstra sikkerheten stille og irreversibelt tapt. Det er hvordan Kerchhoffs prinsipp: Systemet som faller i fiendens hender bør ikke forårsake ulempe.

For det andre antar vi at riktig nøkkel er den eneste nøkkelen som vil føre til en rimelig dekryptering. Dette er også en rimelig antagelse; det er fornøyd hvis chifferteksten er mye lengre enn nøkkelen og er lesbar. Dette er vanligvis det som skjer i den virkelige verden, bortsett fra enorme upraktiske nøkler eller andre shenanigans som er best å la være (hvis du ikke liker vår avvisning av forklaringer, se setning 3.8 her).

Gitt ovenstående, oppstår en strategi: sjekk alle mulige nøkkel. Dette kalles brute force, og et slikt angrep vil garantert virke mot alle praktiske chiffer – etter hvert. For eksempel er brute force nok til å hacke Cæsar-chiffer, et gammelt chiffer hvor nøkkelen er én bokstav i alfabetet, noe som antyder litt over 20 mulige nøkler.

Dessverre for kryptoanalytikere er å øke nøkkelstørrelsen et godt forsvar mot brute force. Når nøkkelstørrelsen øker, øker antallet mulige nøkler eksponentielt. Med moderne nøkkelstørrelser er enkel brute force helt upraktisk. For å forstå hva vi mener, la oss ta den raskeste kjente superdatamaskinen fra midten av 2019: Summit fra IBM, med toppytelse på rundt 1017 operasjoner per sekund. I dag er den typiske nøkkellengden 128 biter, som betyr 2128 mulige kombinasjoner. For å søke gjennom alle tastene, vil Summit-superdatamaskinen trenge tid som er omtrent 7800 ganger universets alder.

Bør brute force anses som en historisk kuriositet? Ikke i det hele tatt: det er en nødvendig ingrediens i kryptanalyse-kokeboken. Sjelden er chiffer så svake at de bare kan brytes ved et smart angrep, uten bruk av makt i en eller annen grad. Mange vellykkede hacks bruker en algoritmisk metode for å svekke målchifferet først, og deretter utføre et brute force-angrep.

Frekvensanalyse

De fleste tekster er ikke vrøvl. For eksempel, i engelske tekster er det mange bokstaver 'e' og artikler 'the'; i binære filer er det mange nullbyte som utfylling mellom informasjonsbiter. Frekvensanalyse er ethvert angrep som utnytter dette faktum.

Det kanoniske eksemplet på et chiffer som er sårbart for dette angrepet, er det enkle substitusjons-chifferet. I denne chifferen er nøkkelen en tabell med alle bokstavene erstattet. For eksempel er 'g' erstattet med 'h', 'o' erstattes med j, så ordet 'go' blir 'hj'. Denne chifferen er vanskelig å brute force fordi det er så mange mulige oppslagstabeller. Hvis du er interessert i matematikk, er den effektive nøkkellengden omtrent 88 biter: altså
. Men frekvensanalyse gjør som regel jobben raskt.

Tenk på følgende chiffertekst behandlet med en enkel substitusjonsjiffer:

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

Siden Y forekommer ofte, inkludert på slutten av mange ord, kan vi tentativt anta at dette er bokstaven e:

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

par XD gjentas i begynnelsen av flere ord. Spesielt kombinasjonen XDeLe tyder tydelig på ordet these eller there, så la oss fortsette:

theLe ALE UGLe thWNKE WN heAJeN ANF eALth DGLAtWG ENN ALE FLEAUT GR WN OGQL ZDWBGEGZDO

La oss videre anta det L соответствует r, A - a og så videre. Det vil sannsynligvis ta noen forsøk, men sammenlignet med et full brute force-angrep, gjenoppretter dette angrepet den opprinnelige teksten på kort tid:

det er flere ting i himmel og jord horatio enn du drømmer om i din filosofi

For noen er det en spennende hobby å løse slike "kryptogrammer".

Ideen om frekvensanalyse er mer grunnleggende enn det ser ut ved første øyekast. Og det gjelder mye mer komplekse chiffer. Gjennom historien har forskjellige chifferdesign forsøkt å motvirke et slikt angrep ved å bruke "polyalfabetisk substitusjon". Her, under krypteringsprosessen, endres bokstaverstatningstabellen på komplekse, men forutsigbare måter som avhenger av nøkkelen. Alle disse chiffer ble ansett som vanskelige å bryte på en gang; og likevel beseiret beskjeden frekvensanalyse dem alle.

Det mest ambisiøse polyalfabetiske chifferet i historien, og sannsynligvis det mest kjente, var Enigma-chifferet fra andre verdenskrig. Den var relativt kompleks sammenlignet med forgjengerne, men etter mye hardt arbeid knakk britiske kryptoanalytikere den ved hjelp av frekvensanalyse. Selvfølgelig kunne de ikke utvikle et elegant angrep som det som er vist ovenfor; de måtte sammenligne kjente par av klartekst og chiffertekst (det såkalte "klartekstangrepet"), og til og med provoserte Enigma-brukere til å kryptere visse meldinger og analysere resultatet ("det valgte klartekstangrepet"). Men dette gjorde ikke skjebnen til de beseirede fiendtlige hærene og senkede ubåtene lettere.

Etter denne triumfen forsvant frekvensanalyse fra kryptoanalysens historie. Chiffere i den moderne digitale tidsalder er designet for å fungere med biter, ikke bokstaver. Enda viktigere, disse chiffer ble designet med den mørke forståelsen av det som senere ble kjent som Schneiers lov: Hvem som helst kan lage en krypteringsalgoritme som de selv ikke kan bryte. Det er ikke nok for krypteringssystemet syntes vanskelig: for å bevise sin verdi, må den gjennomgå en nådeløs sikkerhetsgjennomgang av mange kryptoanalytikere som vil gjøre sitt beste for å knekke chifferen.

Foreløpige beregninger

La oss ta en hypotetisk by Precom Heights, med 200 000 innbyggere. Hvert hjem i byen inneholder i gjennomsnitt verdisaker verdt 30 000 dollar, men ikke mer enn verdisaker verdt 50 000. Sikkerhetsmarkedet i Precom er monopolisert av ACME Industries, som produserer de legendariske Coyote™-dørlåsene. I følge ekspertanalyse kan en lås i Coyote-klassen bare brytes av en veldig kompleks hypotetisk maskin, hvis opprettelse vil kreve omtrent fem år og en investering på $50 000. Er byen trygg?

Mest sannsynlig nei. Etter hvert dukker det opp en ganske ambisiøs kriminell. Han vil resonnere slik: «Ja, jeg vil pådra meg store forhåndskostnader. Fem år med tålmodig venting, og $50 000. Men når jeg er ferdig, vil jeg ha tilgang til all rikdommen til denne byen. Hvis jeg spiller kortene mine riktig, vil denne investeringen betale seg tilbake mange ganger.»

Det samme gjelder i kryptografi. Angrep mot en bestemt chiffer er gjenstand for en hensynsløs kostnad-nytte-analyse. Hvis forholdet er gunstig, vil angrepet ikke forekomme. Men angrep som virker mot mange potensielle ofre på en gang lønner seg nesten alltid, i så fall er den beste designpraksisen å anta at de startet fra dag én. Vi har i hovedsak en kryptografisk versjon av Murphys lov: "Alt som faktisk kan bryte systemet vil bryte systemet."

Det enkleste eksemplet på et kryptosystem som er sårbart for et forhåndsberegningsangrep er en konstant nøkkelløs chiffer. Dette var tilfellet med Cæsars chiffer, som ganske enkelt flytter hver bokstav i alfabetet tre bokstaver fremover (tabellen er sløyfet, så den siste bokstaven i alfabetet er kryptert på tredjeplass). Her kommer Kerchhoffs prinsipp inn i bildet: når et system først er hacket, blir det hacket for alltid.

Konseptet er enkelt. Selv en nybegynner kryptosystemutvikler vil sannsynligvis gjenkjenne trusselen og forberede seg deretter. Ser vi på utviklingen av kryptografi, var slike angrep upassende for de fleste chiffer, fra de første forbedrede versjonene av Cæsar-chifferet til nedgangen av polyalfabetiske chiffer. Slike angrep kom først tilbake med fremveksten av den moderne epoken med kryptografi.

Denne avkastningen skyldes to faktorer. For det første dukket det endelig opp tilstrekkelig komplekse kryptosystemer, hvor muligheten for utnyttelse etter hacking ikke var åpenbar. For det andre ble kryptografi så utbredt at millioner av lekfolk tok beslutninger hver dag om hvor og hvilke deler av kryptografi som skulle gjenbrukes. Det tok litt tid før eksperter innså risikoen og slo alarm.

Husk precomputation-angrepet: på slutten av artikkelen vil vi se på to virkelige kryptografiske eksempler der det spilte en viktig rolle.

Interpolasjon

Her er den berømte detektiven Sherlock Holmes som utfører et interpolasjonsangrep på den ulykkelige Dr. Watson:

Jeg gjettet umiddelbart at du kom fra Afghanistan... Tankegangen min var som følger: «Denne mannen er en lege av type, men han har en militær peiling. Altså en militærlege. Han har nettopp kommet fra tropene - ansiktet hans er mørkt, men dette er ikke den naturlige nyansen av huden hans, siden håndleddene hans er mye hvitere. Ansiktet er utslitt - tydeligvis har han lidd mye og lidd av sykdom. Han ble såret i venstre hånd - han holder den urørlig og litt unaturlig. Hvor i tropene kunne en engelsk militærlege tåle vanskeligheter og bli såret? Selvfølgelig i Afghanistan." Hele tankerekken tok ikke et sekund. Så jeg sa at du kom fra Afghanistan, og du ble overrasket.

Holmes kunne trekke ut svært lite informasjon fra hvert bevis individuelt. Han kunne bare komme til sin konklusjon ved å vurdere dem alle sammen. Et interpolasjonsangrep fungerer på samme måte ved å undersøke kjente klartekst- og chiffertekstpar som er et resultat av samme nøkkel. Fra hvert par trekkes det ut individuelle observasjoner som gjør det mulig å trekke en generell konklusjon om nøkkelen. Alle disse konklusjonene er vage og virker ubrukelige inntil de plutselig når en kritisk masse og fører til den eneste mulige konklusjonen: uansett hvor utrolig det er, må det være sant. Etter dette avsløres enten nøkkelen, eller så blir dekrypteringsprosessen så raffinert at den kan replikeres.

La oss illustrere med et enkelt eksempel hvordan interpolasjon fungerer. La oss si at vi ønsker å lese den personlige dagboken til vår fiende, Bob. Han krypterer hvert tall i dagboken ved hjelp av et enkelt kryptosystem han lærte om fra en annonse i magasinet "A Mock of Cryptography." Systemet fungerer slik: Bob velger to tall som han liker: и . Fra nå av, for å kryptere et hvilket som helst nummer , beregner det . For eksempel hvis Bob valgte и , deretter nummeret vil bli kryptert som .

La oss si at 28. desember la vi merke til at Bob skrapet noe i dagboken sin. Når han er ferdig, tar vi den stille opp og ser på den siste oppføringen:

Дата: 235/520

Kjære dagbok,

I dag var en god dag. Gjennom 64 i dag har jeg en date med Alisa, som bor i en leilighet 843. Jeg tror virkelig hun kan være det 26!

Siden vi er veldig seriøse med å følge Bob på daten hans (vi er begge 15 i dette scenariet), er det viktig å vite datoen og Alices adresse. Heldigvis merker vi at Bobs kryptosystem er sårbart for et interpolasjonsangrep. Vi vet kanskje ikke и , men vi vet dagens dato, så vi har to klartekst-siffertekst-par. Det vet vi nemlig kryptert inn Og - inn . Dette er hva vi skal skrive ned:

Siden vi er 15 år, vet vi allerede om et system med to likninger med to ukjente, som i denne situasjonen er nok til å finne и uten problemer. Hvert klartekst-siffertekst-par legger en begrensning på Bobs nøkkel, og de to begrensningene sammen er tilstrekkelige til å gjenopprette nøkkelen fullstendig. I vårt eksempel er svaret и (på , så det 26 i dagboken tilsvarer ordet 'den ene', det vil si "den samme" - ca. kjørefelt).

Interpolasjonsangrep er selvfølgelig ikke begrenset til slike enkle eksempler. Hvert kryptosystem som reduserer til et godt forstått matematisk objekt og en liste over parametere er i fare for et interpolasjonsangrep – jo mer forståelig objektet er, desto større er risikoen.

Nykommere klager ofte over at kryptografi er «kunsten å designe ting for å være så stygge som mulig». Interpolasjonsangrep har nok i stor grad skylden. Bob kan enten bruke et elegant matematisk design eller holde daten med Alice privat – men dessverre kan du vanligvis ikke ha det begge veier. Dette vil bli helt klart når vi til slutt kommer til temaet offentlig nøkkelkryptering.

Kryssprotokoll/nedgradering

I Now You See Me (2013) forsøker en gruppe illusjonister å svindle den korrupte forsikringsmagnaten Arthur Tressler ut av hele formuen. For å få tilgang til Arthurs bankkonto må illusjonistene enten oppgi brukernavnet og passordet hans eller tvinge ham til å møte opp personlig i banken og delta i opplegget.

Begge alternativene er svært vanskelige; Gutta er vant til å opptre på scenen, og ikke delta i etterretningsoperasjoner. Så de velger det tredje mulige alternativet: deres medskyldige ringer banken og utgir seg for å være Arthur. Banken stiller flere spørsmål for å bekrefte identiteten, for eksempel onkelens navn og navnet på det første kjæledyret; våre helter på forhånd de trekker enkelt ut denne informasjonen fra Arthur ved hjelp av smart sosial ingeniørkunst. Fra dette tidspunktet er utmerket passordsikkerhet ikke lenger viktig.

(Ifølge en urban legende som vi personlig har verifisert og verifisert, møtte kryptograf Eli Beaham en gang en bankteller som insisterte på å stille et sikkerhetsspørsmål. Da telleren spurte om navnet på sin mormor, begynte Beaham å diktere: «Capital X, liten y, tre ... ").

Det er det samme i kryptografi, hvis to kryptografiske protokoller brukes parallelt for å beskytte den samme ressursen, og den ene er mye svakere enn den andre. Det resulterende systemet blir sårbart for et kryssprotokollangrep, der en svakere protokoll blir angrepet for å komme til premien uten å berøre den sterkere.

I noen komplekse tilfeller er det ikke nok å bare kontakte serveren ved hjelp av en svakere protokoll, men krever ufrivillig deltakelse fra en legitim klient. Dette kan organiseres ved hjelp av det såkalte nedgraderingsangrepet. For å forstå dette angrepet, la oss anta at våre illusjonister har en vanskeligere oppgave enn i filmen. La oss anta at en bankansatt (kasserer) og Arthur møtte noen uforutsette omstendigheter, noe som resulterte i følgende dialog:

Innbruddstyv: Hallo? Dette er Arthur Tressler. Jeg vil tilbakestille passordet mitt.

Kasserer: Flott. Vennligst ta en titt på din personlige hemmelige kodebok, side 28, ord 3. Alle følgende meldinger vil bli kryptert med dette spesifikke ordet som nøkkel. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV...

Innbruddstyv: Hei, hei, vent, vent. Er dette virkelig nødvendig? Kan vi ikke bare snakke som vanlige mennesker?

Kasserer: Jeg anbefaler ikke å gjøre dette.

Innbruddstyv: Jeg bare... se, jeg hadde en elendig dag, ok? Jeg er en VIP-klient og jeg er ikke i humør til å grave i disse dumme kodebøkene.

Kasserer: Fint. Hvis du insisterer, herr Tressler. Hva vil du?

Innbruddstyv: Vær så snill, jeg vil gjerne donere alle pengene mine til Arthur Tressler National Victims Fund.

(Pause).

Kasserer: Er det klart nå. Vennligst oppgi PIN-koden for store transaksjoner.

Innbruddstyv: Min hva?

Kasserer: På din personlige forespørsel krever transaksjoner av denne størrelsen en PIN-kode for store transaksjoner. Denne koden ble gitt til deg da du åpnet kontoen din.

Innbruddstyv:... Jeg mistet den. Er dette virkelig nødvendig? Kan du ikke bare godkjenne avtalen?

Kasserer: Nei. Jeg beklager, herr Tressler. Igjen, dette er sikkerhetstiltaket du ba om. Hvis du vil, kan vi sende en ny PIN-kode til din postkasse.

Våre helter utsetter operasjonen. De avlytter flere av Tresslers store transaksjoner, i håp om å høre PIN-koden; men hver gang samtalen blir til kodet sludder før noe interessant blir sagt. Endelig, en vakker dag, settes planen ut i livet. De venter tålmodig på det øyeblikket når Tressler må foreta en stor transaksjon over telefonen, kommer han på linjen, og så...

Tressler: Hallo. Jeg vil gjerne fullføre en ekstern transaksjon.

Kasserer: Flott. Ta en titt på din personlige hemmelige kodebok, side...

(Innbruddstyven trykker på knappen; kassererens stemme blir til uforståelig støy).

Kasserer: - #@$#@$#*@$$@#* vil bli kryptert med dette ordet som nøkkel. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Beklager, jeg skjønte ikke helt. En gang til? På hvilken side? Hvilket ord?

Kasserer: Dette er siden @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Hva?

Kasserer: Ord nummer tjue @$#@$#%#$.

Tressler: Alvor! Nå er det nok! Du og sikkerhetsprotokollen din er litt av et sirkus. Jeg vet at du bare kan snakke med meg på vanlig måte.

Kasserer: Jeg anbefaler ikke…

Tressler: Og jeg anbefaler deg ikke å kaste bort tiden min. Jeg vil ikke høre mer om dette før du fikser telefonlinjeproblemene dine. Kan vi fullføre denne avtalen eller ikke?

Kasserer:… Ja. Fint. Hva vil du?

Tressler: Jeg ønsker å overføre $20 000 til Lord Business Investments, kontonummer...

Kasserer: Et minutt er du grei. Det er en stor sak. Vennligst oppgi PIN-koden for store transaksjoner.

Tressler: Hva? Å, akkurat. 1234.

Her er et nedadgående angrep. Den svakere protokollen "bare snakk direkte" ble sett for seg som alternativ i nødstilfelle. Og likevel er vi her.

Du lurer kanskje på hvem som ved sitt rette sinn ville designe et ekte "safe inntil spurt om noe annet"-system som det som er beskrevet ovenfor. Men akkurat som en fiktiv bank tar risiko for å beholde kunder som ikke liker kryptografi, trekker systemer generelt ofte mot krav som er likegyldige eller til og med direkte fiendtlige til sikkerhet.

Dette er nøyaktig hva som skjedde med SSLv2-protokollen i 1995. Den amerikanske regjeringen har lenge begynt å se på kryptografi som et våpen som best holdes unna utenlandske og innenlandske fiender. Kodestykker ble individuelt godkjent for eksport fra USA, ofte med betingelsen om at algoritmen bevisst ble svekket. Netscape, utvikleren av den mest populære nettleseren, Netscape Navigator, fikk tillatelse til SSLv2 kun med den iboende sårbare 512-biters RSA-nøkkelen (og 40-biters for RC4).

Ved slutten av årtusenet var reglene lempet og tilgang til moderne kryptering ble allment tilgjengelig. Imidlertid har klienter og servere støttet svekket "eksport"-kryptografi i årevis på grunn av den samme tregheten som opprettholder støtte for ethvert eldre system. Klienter trodde at de kunne støte på en server som ikke støttet noe annet. Serverne gjorde det samme. Selvfølgelig tilsier SSL-protokollen at klienter og servere aldri skal bruke en svak protokoll når en bedre er tilgjengelig. Men det samme premisset gjaldt Tressler og hans bank.

Denne teorien fant veien inn i to høyprofilerte angrep som rystet sikkerheten til SSL-protokollen i 2015, begge oppdaget av Microsoft-forskere og INRIA. Først ble detaljer om FREAK-angrepet avslørt i februar, etterfulgt tre måneder senere av et annet lignende angrep kalt Logjam, som vi vil diskutere mer detaljert når vi går videre til angrep på offentlig nøkkelkryptografi.

Sårbarhet FREAK (også kjent som "Smack TLS") kom til syne da forskere analyserte TLS klient/server-implementeringer og oppdaget en merkelig feil. I disse implementeringene, hvis klienten ikke en gang ber om å bruke svak eksportkryptografi, men serveren fortsatt svarer med slike nøkler, sier klienten "Oh well" og bytter til den svake chifferpakken.

På den tiden ble eksportkryptografi ansett som utdatert og off-limits, så angrepet kom som et fullstendig sjokk og påvirket mange viktige domener, inkludert Det hvite hus, IRS og NSA-nettsteder. Enda verre, det viser seg at mange sårbare servere optimaliserte ytelsen ved å gjenbruke de samme nøklene i stedet for å generere nye for hver økt. Dette gjorde det mulig, etter å ha nedgradert protokollen, å utføre et pre-beregningsangrep: Å knekke én nøkkel forble relativt dyrt ($100 og 12 timer på publiseringstidspunktet), men de praktiske kostnadene ved å angripe forbindelsen ble betydelig redusert. Det er nok å gjette servernøkkelen én gang og knekke krypteringen for alle påfølgende tilkoblinger fra det øyeblikket.

Og før vi går videre, er det ett avansert angrep som må nevnes...

Oracle angrep

Moxie Marlinspike best kjent som faren til kryptomeldingsappen Signal på tvers av plattformer; men vi personlig elsker en av hans mindre kjente innovasjoner: prinsippet om kryptografisk undergang (Kryptografisk Doom-prinsipp). For å parafrasere litt, kan vi si dette: "Hvis protokollen fungerer noen utfører en kryptografisk operasjon på en melding fra en potensielt ondsinnet kilde og oppfører seg annerledes avhengig av resultatet, er det dømt." Eller i en skarpere form: "Ikke ta informasjon fra fienden for behandling, og hvis du må, så i det minste ikke vis resultatet."

La oss legge til side bufferoverløp, kommandoinjeksjoner og lignende; de er utenfor rammen av denne diskusjonen. Brudd på «doom-prinsippet» fører til alvorlige kryptografiske hacks på grunn av at protokollen oppfører seg nøyaktig som forventet.

Som et eksempel, la oss ta et fiktivt design med et sårbart substitusjons-chiffer, og deretter demonstrere et mulig angrep. Selv om vi allerede har sett et angrep på et substitusjons-chiffer ved hjelp av frekvensanalyse, er det ikke bare «en annen måte å bryte den samme chifferen på». Derimot er orakelangrep en mye mer moderne oppfinnelse som gjelder mange situasjoner der frekvensanalyse mislykkes, og vi vil se en demonstrasjon av dette i neste avsnitt. Her er det enkle chiffer valgt kun for å gjøre eksemplet klarere.

Så Alice og Bob kommuniserer ved hjelp av en enkel erstatningssiffer ved å bruke en nøkkel som bare er kjent for dem. De er veldig strenge når det gjelder lengden på meldinger: de er nøyaktig 20 tegn lange. Så de ble enige om at hvis noen ønsket å sende en kortere melding, skulle de legge til litt dummy-tekst på slutten av meldingen for å få nøyaktig 20 tegn. Etter litt diskusjon bestemte de seg for at de bare ville godta følgende dummy-tekster: a, bb, ccc, dddd osv. Dermed er en dummy-tekst av hvilken som helst nødvendig lengde kjent.

Når Alice eller Bob mottar en melding, sjekker de først at meldingen har riktig lengde (20 tegn) og at suffikset er riktig dummy-tekst. Hvis dette ikke er tilfelle, svarer de med en passende feilmelding. Hvis tekstlengden og dummyteksten er ok, leser mottakeren selv meldingen og sender et kryptert svar.

Under angrepet utgir angriperen seg som Bob og sender falske meldinger til Alice. Meldingene er fullstendig tull – angriperen har ikke nøkkelen og kan derfor ikke forfalske en meningsfull melding. Men siden protokollen bryter med undergangsprinsippet, kan en angriper likevel fange Alice til å avsløre nøkkelinformasjonen, som vist nedenfor.

Innbruddstyv: PREWF ZHJKL MMMN. LA

Alice: Ugyldig dummy-tekst.

Innbruddstyv: PREWF ZHJKL MMMN. LB

Alice: Ugyldig dummy-tekst.

Innbruddstyv: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Innbruddstyven aner ikke hva Alice nettopp sa, men bemerker at symbolet C må samsvare a, siden Alice godtok dummy-teksten.

Innbruddstyv: REWF ZHJKL MMMN. LAA

Alice: Ugyldig dummy-tekst.

Innbruddstyv: REWF ZHJKL MMMN. LBB

Alice: Ugyldig dummy-tekst.

Etter en rekke forsøk...

Innbruddstyv: REWF ZHJKL MMMN. LGG

Alice: Ugyldig dummy-tekst.

Innbruddstyv: REWF ZHJKL MMMN. LHH

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

Igjen har angriperen ingen anelse om hva Alice nettopp sa, men bemerker at H må matche b siden Alice godtok dummyteksten.

Og så videre til angriperen vet betydningen av hver karakter.

Ved første øyekast ligner metoden et valgt klartekstangrep. Til slutt velger angriperen chiffertekstene, og serveren behandler dem lydig. Hovedforskjellen som gjør disse angrepene levedyktige i den virkelige verden er at angriperen ikke trenger tilgang til selve transkripsjonen – et serversvar, selv en så ufarlig som "Ugyldig dummy-tekst," er tilstrekkelig.

Selv om dette spesielle angrepet er lærerikt, ikke bli for hengt opp i detaljene i "dummy text"-ordningen, det spesifikke kryptosystemet som brukes, eller den nøyaktige sekvensen av meldinger sendt av angriperen. Den grunnleggende ideen er hvordan Alice reagerer forskjellig basert på egenskapene til klarteksten, og gjør det uten å verifisere at den tilsvarende chifferteksten faktisk kom fra en betrodd part. Dermed lar Alice angriperen presse hemmelig informasjon ut av svarene hennes.

Det er mye som kan endres i dette scenariet. Symbolene som Alice reagerer på, eller selve forskjellen i oppførselen hennes, eller til og med kryptosystemet som brukes. Men prinsippet vil forbli det samme, og angrepet som helhet vil forbli levedyktig i en eller annen form. Den grunnleggende implementeringen av dette angrepet hjalp til med å avdekke flere sikkerhetsfeil, som vi snart skal se på; men først er det noen teoretiske leksjoner å lære. Hvordan bruke dette fiktive "Alice-manuset" i et angrep som kan fungere på en ekte moderne chiffer? Er dette mulig, selv i teorien?

I 1998 svarte den sveitsiske kryptografen Daniel Bleichenbacher bekreftende på dette spørsmålet. Han demonstrerte et orakelangrep på det mye brukte offentlige nøkkelkryptosystemet RSA, ved å bruke et spesifikt meldingsskjema. I noen RSA-implementeringer svarer serveren med forskjellige feilmeldinger avhengig av om klarteksten samsvarer med skjemaet eller ikke; dette var nok til å gjennomføre angrepet.

Fire år senere, i 2002, demonstrerte den franske kryptografen Serge Vaudenay et orakelangrep nesten identisk med det som er beskrevet i Alice-scenarioet ovenfor - bortsett fra at i stedet for et fiktivt chiffer, brøt han en hel respektabel klasse av moderne chiffer som folk faktisk brukes. Spesielt er Vaudenays angrep rettet mot chiffer med faste inndatastørrelser ("blokkchiffer") når de brukes i såkalt "CBC-krypteringsmodus" og med et visst populært utfyllingsskjema, i utgangspunktet tilsvarende det i Alice-scenarioet.

Også i 2002 var den amerikanske kryptografen John Kelsey medforfatter Tofisk — foreslått ulike orakelangrep på systemer som komprimerer meldinger og deretter krypterer dem. Mest bemerkelsesverdig blant disse var et angrep som utnyttet det faktum at det ofte er mulig å utlede den opprinnelige lengden på klarteksten fra lengden på chifferteksten. I teorien åpner dette for et orakelangrep som gjenoppretter deler av den originale klarteksten.

Nedenfor gir vi en mer detaljert beskrivelse av Vaudenay- og Kelsey-angrepene (vi vil gi en mer detaljert beskrivelse av Bleichenbacher-angrepet når vi går videre til angrep på offentlig nøkkelkryptografi). Til tross for vår beste innsats blir teksten noe teknisk; så hvis ovenstående er nok for deg, hopp over de to neste avsnittene.

Vodenes angrep

For å forstå Vaudenay-angrepet, må vi først snakke litt mer om blokkchiffer og krypteringsmoduser. Et «blokkchiffer» er som nevnt et chiffer som tar en nøkkel og en inngang av en viss fast lengde («blokklengde») og produserer en kryptert blokk av samme lengde. Blokkchiffer er mye brukt og anses som relativt sikre. Den nå pensjonerte DES, ansett som den første moderne chifferen, var et blokkchiffer. Som nevnt ovenfor gjelder det samme for AES, som er mye brukt i dag.

Dessverre har blokkchiffer en åpenbar svakhet. Den typiske blokkstørrelsen er 128 biter eller 16 tegn. Det er klart at moderne kryptografi krever arbeid med større inngangsdata, og det er her krypteringsmoduser spiller inn. Krypteringsmodus er i hovedsak et hack: det er en måte å på en eller annen måte bruke et blokkchiffer som bare aksepterer input av en viss størrelse til input av en vilkårlig lengde.

Vodenes angrep er fokusert på den populære CBC-modusen (Cipher Block Chaining). Angrepet behandler det underliggende blokkchifferet som en magisk, uinntagelig svart boks og omgår fullstendig sikkerheten.

Her er et diagram som viser hvordan CBC-modus fungerer:

Det sirklede plusset betyr XOR (eksklusiv ELLER) operasjonen. For eksempel mottas den andre blokken med chiffertekst:

1. Ved å utføre en XOR-operasjon på den andre klartekstblokken med den første chiffertekstblokken.
2. Kryptering av den resulterende blokken med et blokkchiffer ved hjelp av en nøkkel.

Siden CBC bruker så mye av den binære XOR-operasjonen, la oss ta et øyeblikk for å huske noen av egenskapene:

• Idempotens:
• Kommutativitet:
• Assosiativitet:
• Selvreversibilitet:
• Bytestørrelse: byte n av = (byte n av ) (byte n av )

Vanligvis innebærer disse egenskapene at hvis vi har en ligning som involverer XOR-operasjoner og en ukjent, kan den løses. For eksempel hvis vi vet det med det ukjente og berømt и , så kan vi stole på de nevnte egenskapene ovenfor for å løse ligningen for . Ved å bruke XOR på begge sider av ligningen med , vi får . Alt dette vil bli veldig aktuelt om et øyeblikk.

Det er to mindre forskjeller og en stor forskjell mellom vårt Alice-scenario og Vaudenays angrep. To mindre:

• I manuset forventet Alice at klartekster skulle slutte med karakterene a, bb, ccc og så videre. I Wodene-angrepet forventer offeret i stedet at klartekstene slutter N ganger med N byte (det vil si heksadesimal 01 eller 02 02, eller 03 03 03, og så videre). Dette er en ren kosmetisk forskjell.
• I Alice-scenariet var det lett å si om Alice hadde akseptert meldingen ved å svare "Feil dummy-tekst." I Vodenes angrep kreves det mer analyser og presis implementering på offerets side er viktig; men for korthets skyld, la oss ta det som gitt at denne analysen fortsatt er mulig.

Hovedforskjell:

• Siden vi ikke bruker det samme kryptosystemet, vil forholdet mellom de angriperkontrollerte chiffertekstbytene og hemmelighetene (nøkkel og klartekst) åpenbart være annerledes. Derfor må angriperen bruke en annen strategi når han lager chiffertekster og tolker serversvar.

Denne store forskjellen er den siste brikken i puslespillet for å forstå Vaudenay-angrepet, så la oss tenke et øyeblikk på hvorfor og hvordan et orakelangrep på CBC til og med ville være mulig.

Anta at vi får en CBC-chiffertekst på 247 blokker, og vi ønsker å dekryptere den. Vi kan sende falske meldinger til serveren, akkurat som vi kunne sende falske meldinger til Alice før. Serveren vil dekryptere meldingene for oss, men vil ikke vise dekrypteringen - i stedet, igjen, som med Alice, vil serveren bare rapportere én bit informasjon: om klarteksten har gyldig utfylling eller ikke.

Tenk på at i Alices scenario hadde vi følgende forhold:

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

La oss kalle dette "Alices ligning." Vi kontrollerte chifferteksten; serveren (Alice) lekket vag informasjon om den mottatte klarteksten; og dette tillot oss å utlede informasjon om den siste faktoren - nøkkelen. I analogi, hvis vi kan finne en slik forbindelse for CBC-skriptet, kan vi kanskje trekke ut noe hemmelig informasjon der også.

Heldigvis er det virkelig relasjoner der ute som vi kan bruke. Vurder utdataene fra det siste anropet for å dekryptere et blokkchiffer og angi denne utgangen som . Vi betegner også blokker med klartekst og chiffertekstblokker . Ta en ny titt på CBC-diagrammet og legg merke til hva som skjer:

La oss kalle dette "CBC-ligningen."

I Alices scenario, ved å overvåke chifferteksten og se den tilsvarende rentekstlekkasjen, var vi i stand til å sette i gang et angrep som gjenopprettet det tredje leddet i ligningen – nøkkelen. I CBC-scenarioet overvåker vi også chifferteksten og observerer informasjonslekkasjer på den tilsvarende klarteksten. Hvis analogien holder, kan vi få informasjon om .

La oss anta at vi virkelig har restaurert , hva da? Vel, da kan vi skrive ut hele den siste blokken med klartekst på en gang (), ganske enkelt ved å skrive inn (som vi har) og
mottatt inn i CBC-ligningen.

Nå som vi er optimistiske angående den overordnede angrepsplanen, er det på tide å finne ut detaljene. Vær oppmerksom på nøyaktig hvordan klartekstinformasjon lekkes på serveren. I Alices skript oppsto lekkasjen fordi Alice bare ville svare med riktig melding hvis $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ sluttet med linjen a (eller bb, og så videre, men sjansene for at disse tilstandene ble utløst ved en tilfeldighet var svært små). I likhet med CBC aksepterer serveren utfyllingen hvis og bare hvis ender på heksadesimal 01. Så la oss prøve det samme trikset: å sende falske chiffertekster med våre egne falske verdier til serveren godtar fyllingen.

Når serveren godtar en utfylling for en av våre falske meldinger, betyr det at:

Nå bruker vi byte-byte XOR-egenskapen:

Vi kjenner første og tredje ledd. Og vi har allerede sett at dette lar oss gjenopprette den gjenværende termen - den siste byten fra :

Dette gir oss også den siste byten av den endelige klartekstblokken via CBC-ligningen og byte-for-byte-egenskapen.

Vi kunne la det ligge og være fornøyd med at vi har utført et angrep på en teoretisk sterk chiffer. Men faktisk kan vi gjøre mye mer: vi kan faktisk gjenopprette all teksten. Dette krever et triks som ikke var i Alices originale manus og som ikke er nødvendig for orakelangrepet, men det er likevel verdt å lære seg.

For å forstå det, legg først merke til at resultatet av å skrive ut den riktige verdien av den siste byten er vi har en ny evne. Nå, når vi smir chiffertekster, kan vi manipulere den siste byten i den tilsvarende klarteksten. Igjen, dette er relatert til CBC-ligningen og byte-for-byte-egenskapen:

Siden vi nå kjenner den andre termen, kan vi bruke vår kontroll over den første til å kontrollere den tredje. Vi regner ganske enkelt ut:

Vi kunne ikke gjøre dette før fordi vi ikke hadde den siste byten ennå .

Hvordan vil dette hjelpe oss? Anta at vi nå lager alle chiffertekster slik at i de tilsvarende klartekstene er den siste byten lik 02. Serveren godtar nå kun utfylling hvis klarteksten slutter med 02 02. Siden vi korrigerte den siste byten, vil dette bare skje hvis den nest siste byten i klarteksten også er 02. Vi fortsetter å sende falske chiffertekstblokker, og endrer den nest siste byten, til serveren godtar utfyllingen for en av dem. På dette tidspunktet får vi:

Og vi gjenoppretter den nest siste byten akkurat som den siste ble restaurert. Vi fortsetter i samme ånd: vi korrigerer de to siste bytene i klarteksten til 03 03, gjentar vi dette angrepet for den tredje byten fra slutten og så videre, og gjenoppretter til slutt fullstendig .

Hva med resten av teksten? Vær oppmerksom på at verdien er faktisk $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Vi kan sette hvilken som helst annen blokk i stedet , og angrepet vil fortsatt være vellykket. Faktisk kan vi be serveren om å gjøre $inline$text{BLOCK_DECRYPT}$inline$ for alle data. På dette tidspunktet er spillet over - vi kan dekryptere hvilken som helst chiffertekst (ta en ny titt på CBC-dekrypteringsdiagrammet for å se dette; og merk at IV er offentlig).

Denne spesielle metoden spiller en avgjørende rolle i orakelangrepet som vi vil møte senere.

Kelseys angrep

Vår sympatiske John Kelsey la frem prinsippene som ligger til grunn for mange mulige angrep, ikke bare detaljene i et spesifikt angrep på et spesifikt chiffer. Hans Årets 2002-artikkel er en studie av mulige angrep på kryptert komprimert data. Trodde du at informasjonen om at dataene ble komprimert før kryptering ikke var nok til å utføre et angrep? Det viser seg at det er nok.

Dette overraskende resultatet skyldes to prinsipper. For det første er det en sterk sammenheng mellom lengden på klarteksten og lengden på chifferteksten; for mange siffer nøyaktig likhet. For det andre, når komprimering utføres, er det også en sterk korrelasjon mellom lengden på den komprimerte meldingen og graden av "støy" i klarteksten, det vil si andelen ikke-repeterende tegn (det tekniske begrepet er "høy entropi" ).

For å se prinsippet i aksjon, vurder to klartekster:

Klartekst 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Klartekst 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

La oss anta at begge klartekstene er komprimert og deretter kryptert. Du får to resulterende chiffertekster og må gjette hvilken chiffertekst som samsvarer med hvilken klartekst:

Chiffertekst 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Chiffertekst 2: DWKJZXYU

Svaret er klart. Blant klartekstene var det bare klartekst 1 som kunne komprimeres til den magre lengden på den andre chifferteksten. Vi fant ut av dette uten å vite noe om komprimeringsalgoritmen, krypteringsnøkkelen eller til og med selve chifferen. Sammenlignet med hierarkiet av mulige kryptografiske angrep, er dette litt sprøtt.

Kelsey påpeker videre at under visse uvanlige omstendigheter kan dette prinsippet også brukes til å utføre et orakelangrep. Spesielt beskriver den hvordan en angriper kan gjenopprette den hemmelige klarteksten hvis han kan tvinge serveren til å kryptere skjemadataene (klarteksten etterfulgt av mens han har kontroll og kan på en eller annen måte sjekke lengden på det krypterte resultatet.

Igjen, som andre orakelangrep, har vi forholdet:

Igjen kontrollerer vi ett begrep (), ser vi en liten lekkasje av informasjon om et annet medlem (chiffertekst) og prøver å gjenopprette det siste (ren tekst). Til tross for analogien er dette en noe uvanlig situasjon sammenlignet med andre orakelangrep vi har sett.

For å illustrere hvordan et slikt angrep kan fungere, la oss bruke et fiktivt komprimeringsskjema vi nettopp kom opp med: TOYZIP. Den ser etter tekstlinjer som har dukket opp tidligere i teksten, og erstatter dem med tre plassholderbyte som indikerer hvor en tidligere forekomst av linjen skal finnes og hvor mange ganger den vises der. For eksempel linjen helloworldhello kan komprimeres til helloworld[00][00][05] 13 byte lang sammenlignet med de opprinnelige 15 byte.

Anta at en angriper prøver å gjenopprette klarteksten til et skjema password=..., hvor selve passordet er ukjent. I følge Kelseys angrepsmodell kan en angriper be serveren om å komprimere og deretter kryptere skjemameldinger (ren tekst etterfulgt av ), hvor  - fri tekst. Når serveren er ferdig med å virke, rapporterer den lengden på resultatet. Angrepet går slik:

Innbruddstyv: Vennligst komprimer og krypter klarteksten uten utfylling.

Server: Resultatlengde 14.

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=a.

Server: Resultatlengde 18.

Knekkeren bemerker: [original 14] + [tre byte som erstattet password=] + a

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=b.

Server: Resultatlengde 18.

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=с.

Server: Resultatlengde 17.

Knekkeren bemerker: [original 14] + [tre byte som erstattet password=c]. Dette forutsetter at den originale klarteksten inneholder strengen password=c. Det vil si at passordet begynner med en bokstav c

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=сa.

Server: Resultatlengde 18.

Knekkeren bemerker: [original 14] + [tre byte som erstattet password=с] + a

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=сb.

Server: Resultatlengde 18.

(… En gang senere…)

Innbruddstyv: Vennligst komprimer og krypter klarteksten som er lagt til password=со.

Server: Resultatlengde 17.

Knekkeren bemerker: [original 14] + [tre byte som erstattet password=co]. Ved å bruke samme logikk konkluderer angriperen med at passordet begynner med bokstavene co

Og så videre til hele passordet er gjenopprettet.

Leseren ville bli tilgitt for å tro at dette er en rent akademisk øvelse og at et slikt angrepsscenario aldri ville oppstå i den virkelige verden. Akk, som vi snart vil se, er det bedre å ikke gi opp kryptografi.

Merkesårbarheter: KRIMINALITET, PUDDEL, DRUKNING

Til slutt, etter å ha studert teorien i detalj, kan vi se hvordan disse teknikkene brukes i virkelige kryptografiske angrep.

FORBRYTELSE

Hvis angrepet retter seg mot offerets nettleser og nettverk, vil noen ting være enklere og noe vanskeligere. For eksempel er det lett å se offerets trafikk: bare sitt med ham på samme kafé med WiFi. Av denne grunn anbefales potensielle ofre (dvs. alle) generelt å bruke en kryptert tilkobling. Det vil være vanskeligere, men fortsatt mulig, å sende HTTP-forespørsler på vegne av offeret til en tredjepartsside (for eksempel Google). Angriperen må lokke offeret til en ondsinnet nettside med et skript som sender forespørselen. Nettleseren vil automatisk gi den riktige øktinformasjonskapselen.

Dette virker utrolig. Hvis Bob gikk til evil.com, kan skriptet på dette nettstedet bare be Google om å sende passordet til Bob på e-post [email protected]? Vel, i teorien ja, men i virkeligheten nei. Dette scenariet kalles et forfalskningsangrep på tvers av nettsteder (Forfalskning på tvers av nettstedet, CSRF), og den var populær rundt midten av 90-tallet. I dag hvis evil.com prøver dette trikset, vil Google (eller et hvilket som helst nettsted med respekt for seg selv) vanligvis svare med «Flott, men CSRF-tokenet ditt for denne transaksjonen vil være... um... три триллиона и семь. Gjenta dette nummeret." Moderne nettlesere har noe som kalles "same-origin policy" der skript på nettsted A ikke har tilgang til informasjon sendt av nettsted B. Så skriptet på evil.com kan sende forespørsler til google.com, men kan ikke lese svarene eller faktisk fullføre transaksjonen.

Vi må understreke at med mindre Bob bruker en kryptert tilkobling, er alle disse beskyttelsene meningsløse. En angriper kan ganske enkelt lese Bobs trafikk og gjenopprette Googles øktinformasjonskapsel. Med denne informasjonskapselen vil han ganske enkelt åpne en ny Google-fane uten å forlate sin egen nettleser og utgi seg for Bob uten å møte irriterende retningslinjer for samme opprinnelse. Men, dessverre for en innbruddstyv, blir dette mindre og mindre vanlig. Internett som helhet har lenge erklært krig mot ukrypterte forbindelser, og Bobs utgående trafikk er sannsynligvis kryptert, enten han liker det eller ikke. I tillegg, helt fra begynnelsen av implementeringen av protokollen, var trafikk også krympet før kryptering; dette var vanlig praksis for å redusere ventetiden.

Det er her det spiller inn FORBRYTELSE (Compression Ratio Infoleak Made Easy, enkel lekkasje gjennom kompresjonsforholdet). Sårbarheten ble avslørt i september 2012 av sikkerhetsforskerne Juliano Rizzo og Thai Duong. Vi har allerede undersøkt hele det teoretiske grunnlaget, som lar oss forstå hva de gjorde og hvordan. En angriper kan tvinge Bobs nettleser til å sende forespørsler til Google og deretter lytte til svarene på det lokale nettverket i en komprimert, kryptert form. Derfor har vi:

Her kontrollerer angriperen forespørselen og har tilgang til trafikksnifferen, inkludert pakkestørrelsen. Kelseys fiktive scenario ble levende.

For å forstå teorien, skapte forfatterne av CRIME en utnyttelse som kan stjele øktinformasjonskapsler for et bredt spekter av nettsteder, inkludert Gmail, Twitter, Dropbox og Github. Sårbarheten påvirket de fleste moderne nettlesere, noe som resulterte i at patcher ble utgitt som i det stille begravde komprimeringsfunksjonen i SSL slik at den ikke ville bli brukt i det hele tatt. Den eneste som ble beskyttet mot sårbarheten var den ærverdige Internet Explorer, som aldri brukte SSL-komprimering i det hele tatt.

POODLE

I oktober 2014 skapte Googles sikkerhetsteam bølger i sikkerhetsfellesskapet. De var i stand til å utnytte en sårbarhet i SSL-protokollen som ble lappet for mer enn ti år siden.

Det viser seg at mens serverne kjører den skinnende nye TLSv1.2, har mange etterlatt støtte for den eldre SSLv3 for bakoverkompatibilitet med Internet Explorer 6. Vi har allerede snakket om nedgraderingsangrep, så du kan forestille deg hva som skjer. En godt orkestrert sabotasje av handshake-protokollen og serverne er klare til å gå tilbake til gode gamle SSLv3, noe som i hovedsak angret de siste 15 årene med sikkerhetsforskning.

For historisk sammenheng, her er et kort sammendrag av historien til SSL opp til versjon 2 fra Matthew Green:

Transport Layer Security (TLS) er den viktigste sikkerhetsprotokollen på Internett. [..] nesten hver transaksjon du gjør på Internett avhenger av TLS. [..] Men TLS var ikke alltid TLS. Protokollen begynte sitt liv i Netscape Communications kalt "Secure Sockets Layer" eller SSL. Ryktene sier at den første versjonen av SSL var så forferdelig at utviklerne samlet alle utskriftene av koden og begravde dem på et hemmelig deponi i New Mexico. Som en konsekvens er den første offentlig tilgjengelige versjonen av SSL faktisk versjon SSL 2. Det er ganske skummelt, og [..] det var et produkt fra midten av 90-tallet, som moderne kryptografer ser på som "mørke tidsalder av kryptografi" Mange av de mest avskyelige kryptografiske angrepene vi vet om i dag er ennå ikke oppdaget. Som et resultat ble utviklerne av SSLv2-protokollen i hovedsak overlatt til å famle seg frem i mørket, og de møtte mange forferdelige monstre - til deres sorg og vår fordel, siden angrepene på SSLv2 ga uvurderlige lærdommer for neste generasjons protokoller.

Etter disse hendelsene, i 1996, redesignet et frustrert Netscape SSL-protokollen fra bunnen av. Resultatet ble SSL versjon 3, som fikset flere kjente sikkerhetsproblemer fra forgjengeren.

Heldigvis for innbruddstyver betyr ikke «noen få» «alle». Totalt sett ga SSLv3 alle nødvendige byggeklosser for å starte et Vodene-angrep. Protokollen brukte et blokkchiffer i CBC-modus og et usikkert utfyllingsskjema (dette ble korrigert i TLS; derav behovet for et nedgraderingsangrep). Hvis du husker utfyllingsskjemaet i vår originale beskrivelse av Vaudenay-angrepet, er SSLv3-skjemaet veldig likt.

Men dessverre for innbruddstyver betyr ikke "liknende" "identisk". SSLv3-utfyllingsskjemaet er "N tilfeldige byte etterfulgt av tallet N". Prøv, under disse forholdene, å velge en imaginær blokk med chiffertekst og gå gjennom alle trinnene i Vaudenes opprinnelige opplegg: du vil finne at angrepet vellykket trekker ut den siste byten fra den tilsvarende blokken med klartekst, men går ikke videre. Å dekryptere hver 16. byte med chiffertekst er et flott triks, men det er ikke en seier.

Overfor feil, tyr Google-teamet til en siste utvei: de byttet til en kraftigere trusselmodell - den som ble brukt i CRIME. Forutsatt at angriperen er et skript som kjører i offerets nettleserfane og kan trekke ut øktinformasjonskapsler, er angrepet fortsatt imponerende. Mens den bredere trusselmodellen er mindre realistisk, så vi i forrige avsnitt at denne modellen er gjennomførbar.

Gitt disse kraftigere angriperegenskapene, kan angrepet nå fortsette. Merk at angriperen vet hvor den krypterte øktinformasjonskapselen vises i overskriften og kontrollerer lengden på HTTP-forespørselen som går foran den. Derfor er den i stand til å manipulere HTTP-forespørselen slik at den siste byten av informasjonskapselen er på linje med slutten av blokken. Nå er denne byten egnet for dekryptering. Du kan ganske enkelt legge til ett tegn i forespørselen, og den nest siste byten til informasjonskapselen forblir på samme sted og er egnet for valg med samme metode. Angrepet fortsetter på denne måten til informasjonskapselfilen er fullstendig gjenopprettet. Det heter POODLE: Padding Oracle on Downgraded Legacy Encryption.

DRUKNE

Som vi nevnte, hadde SSLv3 sine feil, men den var fundamentalt forskjellig fra forgjengeren, siden den lekke SSLv2 var et produkt fra en annen epoke. Der kan du avbryte meldingen i midten: соглашусь на это только через мой труп omgjort til соглашусь на это; klienten og serveren kunne møtes på nettet, etablere tillit og utveksle hemmeligheter foran angriperen, som deretter enkelt kunne etterligne begge. Det er også problemet med eksportkryptografi, som vi nevnte da vi vurderte FREAK. Disse var kryptografiske Sodoma og Gomorra.

I mars 2016 kom et team av forskere fra ulike tekniske felt sammen og gjorde en oppsiktsvekkende oppdagelse: SSLv2 brukes fortsatt i sikkerhetssystemer. Ja, angripere kunne ikke lenger nedgradere moderne TLS-økter til SSLv2 siden det hullet ble lukket etter FREAK og POODLE, men de kan fortsatt koble til servere og starte SSLv2-økter selv.

Du kan spørre, hvorfor bryr vi oss om hva de gjør der? De har en sårbar sesjon, men det skal ikke påvirke andre økter eller sikkerheten til serveren – ikke sant? Vel, ikke helt. Ja, sånn skal det være i teorien. Men nei - fordi generering av SSL-sertifikater påfører en viss byrde, noe som resulterer i at mange servere bruker de samme sertifikatene og som et resultat de samme RSA-nøklene for TLS- og SSLv2-tilkoblinger. For å gjøre vondt verre, på grunn av en OpenSSL-feil, fungerte ikke "Deaktiver SSLv2"-alternativet i denne populære SSL-implementeringen.

Dette muliggjorde et kryssprotokollangrep på TLS, kalt DRUKNE (Dekryptering av RSA med foreldet og svekket kryptering, dekryptering av RSA med foreldet og svekket kryptering). Husk at dette ikke er det samme som et kort angrep; angriperen trenger ikke å opptre som en "mann i midten" og trenger ikke involvere klienten for å delta i en usikker økt. Angripere starter ganske enkelt en usikker SSLv2-økt med serveren selv, angriper den svake protokollen og gjenoppretter serverens private RSA-nøkkel. Denne nøkkelen er også gyldig for TLS-tilkoblinger, og fra dette tidspunktet vil ingen mengde TLS-sikkerhet forhindre at den blir kompromittert.

Men for å knekke det, trenger du et fungerende angrep mot SSLv2, som lar deg gjenopprette ikke bare spesifikk trafikk, men også den hemmelige RSA-servernøkkelen. Selv om dette er et komplekst oppsett, kunne forskerne velge hvilken som helst sårbarhet som ble fullstendig lukket etter SSLv2. De fant til slutt et passende alternativ: Bleichenbacher-angrepet, som vi nevnte tidligere og som vi vil forklare i detalj i neste artikkel. SSL og TLS er beskyttet mot dette angrepet, men noen tilfeldige funksjoner i SSL, kombinert med korte nøkler i eksport-grade kryptografi, gjorde det mulig en spesifikk implementering av DROWN.

På publiseringstidspunktet var 25 % av Internetts beste nettsteder berørt av DROWN-sårbarheten, og angrepet kunne utføres med beskjedne ressurser tilgjengelig for selv rampete ensomme hackere. Å hente serverens RSA-nøkkel krevde åtte timer med beregning og $440, og SSLv2 gikk fra foreldet til radioaktivt.

Vent, hva med Heartbleed?

Dette er ikke et kryptografisk angrep i den forstand som er beskrevet ovenfor; Dette er et bufferoverløp.

La oss ta en pause

Vi startet med noen grunnleggende teknikker: brute force, interpolering, nedgradering, kryssprotokoll og forhåndsberegning. Deretter så vi på en avansert teknikk, kanskje hovedkomponenten i moderne kryptografiske angrep: orakelangrepet. Vi brukte ganske lang tid på å finne ut av det – og forsto ikke bare det underliggende prinsippet, men også de tekniske detaljene i to spesifikke implementeringer: Vaudenay-angrepet på CBC-krypteringsmodusen og Kelsey-angrepet på pre-komprimeringskrypteringsprotokoller.

I gjennomgangen av nedgraderings- og forhåndsberegningsangrep, skisserte vi kort FREAK-angrepet, som bruker begge metodene ved å la målnettsteder nedgradere til svake nøkler og deretter gjenbruke de samme nøklene. For den neste artikkelen vil vi lagre (svært likt) Logjam-angrepet, som retter seg mot offentlige nøkkelalgoritmer.

Vi så på ytterligere tre eksempler på anvendelsen av disse prinsippene. Først, CRIME og POODLE: to angrep som var avhengig av angriperens evne til å injisere vilkårlig klartekst ved siden av målklarteksten, undersøk deretter serverens svar og deretter, ved å bruke orakelangrepsmetodikk, utnytte denne sparsomme informasjonen til, delvis å gjenopprette klarteksten. CRIME gikk veien til Kelseys angrep på SSL-komprimering, mens POODLE i stedet brukte en variant av Vaudenays angrep på CBC med samme effekt.

Deretter vendte vi oppmerksomheten mot DROWN-angrepet på tvers av protokoller, som etablerer en tilkobling til serveren ved hjelp av den eldre SSLv2-protokollen og deretter gjenoppretter serverens hemmelige nøkler ved hjelp av Bleichenbacher-angrepet. Vi har hoppet over de tekniske detaljene i dette angrepet foreløpig; som Logjam, vil det måtte vente til vi har en god forståelse av offentlige nøkkelkryptosystemer og deres sårbarheter.

I neste artikkel skal vi snakke om avanserte angrep som møte-i-midten, differensiell kryptoanalyse og bursdagsangrep. La oss ta et raskt innblikk i sidekanalangrep, og så komme til kjøttet av saken: offentlige nøkkelkryptosystemer.

Kilde: www.habr.com