Als je het woord ‘cryptografie’ hoort, herinneren sommige mensen zich hun wifi-wachtwoord, het groene hangslot naast het adres van hun favoriete website en hoe moeilijk het is om in de e-mail van iemand anders te komen. Anderen herinneren zich een reeks kwetsbaarheden van de afgelopen jaren met veelzeggende afkortingen (DROWN, FREAK, POODLE...), stijlvolle logo's en een waarschuwing om uw browser dringend te updaten.

Cryptografie omvat het allemaal, maar de essentie in een andere. Het punt is dat er een dunne lijn is tussen eenvoudig en complex. Sommige dingen zijn gemakkelijk te doen, maar moeilijk weer in elkaar te zetten, zoals het breken van een ei. Andere dingen zijn gemakkelijk te doen, maar moeilijk terug te krijgen als een klein, belangrijk en cruciaal onderdeel ontbreekt: bijvoorbeeld het openen van een gesloten deur terwijl het ‘cruciale onderdeel’ de sleutel is. Cryptografie bestudeert deze situaties en hoe deze in de praktijk kunnen worden gebruikt.

De afgelopen jaren is de verzameling cryptografische aanvallen veranderd in een dierentuin van opvallende logo’s, gevuld met formules uit wetenschappelijke artikelen, en aanleiding gegeven tot een algemeen somber gevoel dat alles kapot is. Maar in feite zijn veel van de aanvallen gebaseerd op een paar algemene principes, en eindeloze pagina's met formules komen vaak neer op gemakkelijk te begrijpen ideeën.

In deze serie artikelen bekijken we de verschillende soorten cryptografische aanvallen, met de nadruk op de basisprincipes. In algemene termen en niet precies in deze volgorde, maar we behandelen het volgende:

• Basisstrategieën: brute kracht, frequentieanalyse, interpolatie, downgrading en cross-protocollen.
• Merkkwetsbaarheden: FREAK, MISDAAD, POEDEL, VERDRINKEN, Logjam.
• Geavanceerde strategieën: orakelaanvallen (Vodenet-aanval, Kelsey-aanval); meet-in-the-middle-methode, verjaardagsaanval, statistische bias (differentiële cryptanalyse, integrale cryptanalyse, enz.).
• Zijkanaalaanvallen en hun naaste familieleden, technieken voor faalanalyse.
• Aanvallen op cryptografie met openbare sleutels: kubuswortel, uitzending, gerelateerd bericht, Coppersmith-aanval, Pohlig-Hellman-algoritme, getallenzeef, Wiener-aanval, Bleichenbacher-aanval.

Dit specifieke artikel behandelt het bovenstaande materiaal tot aan de aanval van Kelsey.

Basisstrategieën

De volgende aanvallen zijn eenvoudig in die zin dat ze vrijwel volledig kunnen worden verklaard zonder veel technische details. Laten we elk type aanval in de eenvoudigste bewoordingen uitleggen, zonder in te gaan op complexe voorbeelden of geavanceerde gebruiksscenario's.

Sommige van deze aanvallen zijn grotendeels achterhaald en worden al jaren niet meer gebruikt. Anderen zijn oldtimers die in de 21e eeuw nog steeds regelmatig nietsvermoedende ontwikkelaars van cryptosystemen besluipen. Er kan worden aangenomen dat het tijdperk van de moderne cryptografie is begonnen met de komst van IBM DES, het eerste cijfer dat alle aanvallen op deze lijst heeft doorstaan.

Simpel brute kracht

Het versleutelingsschema bestaat uit twee delen: 1) de versleutelingsfunctie, waarbij een bericht (plaintext) gecombineerd met een sleutel wordt gebruikt en vervolgens een gecodeerd bericht wordt aangemaakt: cijfertekst; 2) een decoderingsfunctie die de cijfertekst en sleutel gebruikt en platte tekst produceert. Zowel encryptie als decryptie moeten gemakkelijk te berekenen zijn met de sleutel, en moeilijk te berekenen zonder de sleutel.

Laten we aannemen dat we de cijfertekst zien en proberen deze te decoderen zonder enige aanvullende informatie (dit wordt een aanval met alleen cijfertekst genoemd). Als we op de een of andere manier op magische wijze de juiste sleutel vinden, kunnen we gemakkelijk verifiëren dat deze inderdaad correct is als het resultaat een redelijk bericht is.

Merk op dat er hier twee impliciete aannames zijn. Ten eerste weten we hoe we decodering moeten uitvoeren, dat wil zeggen hoe het cryptosysteem werkt. Dit is een standaardaanname bij het bespreken van cryptografie. Het verbergen van de implementatiedetails van het cijfer voor aanvallers lijkt misschien een extra beveiligingsmaatregel, maar zodra de aanvaller deze details ontdekt, gaat deze extra beveiliging stilletjes en onomkeerbaar verloren. Dat is hoe Kerchhoffs-principe: Het systeem dat in handen van de vijand valt, mag geen overlast veroorzaken.

Ten tweede gaan we ervan uit dat de juiste sleutel de enige sleutel is die tot een redelijke decodering zal leiden. Dit is ook een redelijke veronderstelling; men is tevreden als de cijfertekst veel langer is dan de sleutel en leesbaar is. Dit is meestal wat er in de echte wereld gebeurt, behalve enorme onpraktische toetsen of andere shenanigans die het beste terzijde kunnen worden gelaten (als je het niet leuk vindt dat we de uitleg hebben overgeslagen, zie dan Stelling 3.8 hier).

Gezien het bovenstaande ontstaat er een strategie: controleer elke mogelijke sleutel. Dit wordt brute kracht genoemd, en zo'n aanval werkt gegarandeerd tegen alle praktische cijfers - uiteindelijk. Brute kracht is bijvoorbeeld voldoende om te hacken Caesar-cijfer, een oud cijfer waarbij de sleutel één letter van het alfabet is, wat iets meer dan twintig mogelijke sleutels impliceert.

Helaas voor cryptanalisten is het vergroten van de sleutelgrootte een goede verdediging tegen brute kracht. Naarmate de sleutelgrootte toeneemt, neemt het aantal mogelijke sleutels exponentieel toe. Met moderne sleutelformaten is eenvoudig brute kracht volkomen onpraktisch. Om te begrijpen wat we bedoelen, nemen we de snelst bekende supercomputer van medio 2019: Top van IBM, met piekprestaties van ongeveer 1017 bewerkingen per seconde. Tegenwoordig is de typische sleutellengte 128 bits, wat 2128 mogelijke combinaties betekent. Om alle sleutels te doorzoeken heeft de Summit-supercomputer tijd nodig die ongeveer 7800 keer zo oud is als het heelal.

Moet brute kracht als een historische curiositeit worden beschouwd? Helemaal niet: het is een noodzakelijk ingrediënt in het cryptanalyse-kookboek. Zelden zijn cijfers zo zwak dat ze alleen kunnen worden verbroken door een slimme aanval, zonder het gebruik van enige mate van geweld. Veel succesvolle hacks gebruiken een algoritmische methode om eerst het doelcijfer te verzwakken en vervolgens een brute force-aanval uit te voeren.

Frequentie analyse

De meeste teksten zijn geen wartaal. In Engelse teksten zijn er bijvoorbeeld veel letters 'e' en lidwoorden 'the'; in binaire bestanden zijn er veel nulbytes als opvulling tussen stukjes informatie. Frequentieanalyse is elke aanval die van dit feit profiteert.

Het canonieke voorbeeld van een cijfer dat kwetsbaar is voor deze aanval is het eenvoudige vervangingscijfer. In dit cijfer is de sleutel een tabel waarin alle letters zijn vervangen. 'g' wordt bijvoorbeeld vervangen door 'h', 'o' door j, dus het woord 'go' wordt 'hj'. Dit cijfer is moeilijk te brute kracht omdat er zoveel mogelijke opzoektabellen zijn. Als je geïnteresseerd bent in de wiskunde: de effectieve sleutellengte is ongeveer 88 bits: dat is het
. Maar frequentieanalyse klaart de klus meestal snel.

Beschouw de volgende cijfertekst, verwerkt met een eenvoudig vervangingscijfer:

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

Sinds Y vaak voorkomt, ook aan het einde van veel woorden, kunnen we voorlopig aannemen dat dit de letter is e:

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

Paar XD herhaald aan het begin van een aantal woorden. Met name de combinatie XDeLe suggereert het woord duidelijk these of there, dus laten we doorgaan:

theLe ALe UGLe ThWNKE WN HEAJeN ANF eALth DGLAtWG dan ALe FLeAUt GR WN OGQL ZDWBGEGZDO

Laten we dat verder aannemen L komt overeen met r, A - a enzovoort. Het zal waarschijnlijk een paar pogingen kosten, maar vergeleken met een volledige brute force-aanval herstelt deze aanval de originele tekst in een mum van tijd:

er zijn meer dingen in hemel en aarde horatio dan waarvan je in jouw filosofie droomt

Voor sommigen is het oplossen van dergelijke ‘cryptogrammen’ een spannende hobby.

Het idee van frequentieanalyse is fundamenteler dan het op het eerste gezicht lijkt. En het is van toepassing op veel complexere cijfers. Door de geschiedenis heen hebben verschillende codeontwerpen geprobeerd een dergelijke aanval tegen te gaan met behulp van "polyalfabetische substitutie". Hier wordt tijdens het versleutelingsproces de lettervervangingstabel gewijzigd op complexe maar voorspelbare manieren die afhankelijk zijn van de sleutel. Al deze cijfers werden als moeilijk in één keer te kraken beschouwd; en toch versloeg een bescheiden frequentieanalyse ze uiteindelijk allemaal.

Het meest ambitieuze polyalfabetische cijfer uit de geschiedenis, en waarschijnlijk het bekendste, was het Enigma-cijfer uit de Tweede Wereldoorlog. Het was relatief complex vergeleken met zijn voorgangers, maar na veel hard werken hebben Britse cryptanalisten het gekraakt met behulp van frequentieanalyse. Natuurlijk konden ze geen elegante aanval ontwikkelen zoals hierboven getoond; ze moesten bekende paren platte tekst en cijfertekst vergelijken (de zogenaamde "plaintext-aanval"), en zelfs Enigma-gebruikers ertoe aanzetten bepaalde berichten te coderen en het resultaat te analyseren (de "gekozen platte tekst-aanval"). Maar dit maakte het lot van de verslagen vijandelijke legers en gezonken onderzeeërs er niet gemakkelijker op.

Na deze triomf verdween de frequentieanalyse uit de geschiedenis van de cryptanalyse. Cijfers in het moderne digitale tijdperk zijn ontworpen om met bits te werken, niet met letters. Wat nog belangrijker is, deze cijfers zijn ontworpen met het duistere begrip van wat later bekend werd De wet van Schneier: Iedereen kan een versleutelingsalgoritme maken dat hij of zij zelf niet kan kraken. Het is niet genoeg voor het encryptiesysteem leek moeilijk: om zijn waarde te bewijzen, moet het een meedogenloze veiligheidsbeoordeling ondergaan door veel cryptanalisten die hun best zullen doen om het cijfer te kraken.

Voorlopige berekeningen

Neem de hypothetische stad Precom Heights, met 200 inwoners. Elk huis in de stad bevat gemiddeld $ 000 aan waardevolle spullen, maar niet meer dan $ 30. De beveiligingsmarkt in Precom wordt gemonopoliseerd door ACME Industries, die de legendarische deursloten uit de Coyote™-klasse produceert. Volgens de analyse van deskundigen kan een slot van de Coyote-klasse alleen worden gebroken door een zeer complexe hypothetische machine, waarvan de creatie ongeveer vijf jaar en $000 aan investeringen vergt. Is de stad veilig?

Hoogstwaarschijnlijk niet. Uiteindelijk zal er een tamelijk ambitieuze crimineel verschijnen. Hij zal als volgt redeneren: “Ja, ik zal grote kosten vooraf maken. Vijf jaar geduldig wachten en $ 50. Maar als ik klaar ben, heb ik toegang tot alle rijkdom van deze stad. Als ik mijn kaarten goed speel, zal deze investering zichzelf vele malen terugbetalen.”

Hetzelfde geldt voor cryptografie. Aanvallen op een bepaald cijfer zijn onderworpen aan een meedogenloze kosten-batenanalyse. Als de verhouding gunstig is, zal de aanval niet plaatsvinden. Maar aanvallen die in één keer tegen veel potentiële slachtoffers werken, werpen bijna altijd vruchten af, in welk geval de beste ontwerppraktijk is om aan te nemen dat ze vanaf de eerste dag zijn begonnen. We hebben in wezen een cryptografische versie van de wet van Murphy: "Alles wat het systeem daadwerkelijk kan breken, zal het systeem breken."

Het eenvoudigste voorbeeld van een cryptosysteem dat kwetsbaar is voor een precomputation-aanval is een constant-keyless cipher. Dit was het geval bij Het cijfer van Caesar, waarmee elke letter van het alfabet eenvoudigweg drie letters naar voren wordt geschoven (de tabel is in een lus opgenomen, zodat de laatste letter van het alfabet als derde wordt gecodeerd). Ook hier komt het Kerchhoffs-principe om de hoek kijken: als een systeem eenmaal is gehackt, is het voor altijd gehackt.

Het concept is eenvoudig. Zelfs een beginnende ontwikkelaar van cryptosystemen zal de dreiging waarschijnlijk herkennen en zich dienovereenkomstig voorbereiden. Kijkend naar de evolutie van de cryptografie waren dergelijke aanvallen ongepast voor de meeste cijfers, vanaf de eerste verbeterde versies van het Caesar-cijfer tot de teloorgang van polyalfabetische cijfers. Dergelijke aanvallen keerden pas terug met de komst van het moderne tijdperk van de cryptografie.

Dit rendement is te danken aan twee factoren. Ten eerste verschenen er eindelijk voldoende complexe cryptosystemen, waarbij de mogelijkheid van exploitatie na hacking niet voor de hand lag. Ten tweede werd cryptografie zo wijdverspreid dat miljoenen leken elke dag beslissingen namen over waar en welke delen van de cryptografie ze opnieuw moesten gebruiken. Het duurde enige tijd voordat deskundigen zich de risico's realiseerden en alarm sloegen.

Denk aan de precomputation-aanval: aan het einde van het artikel zullen we twee cryptografische voorbeelden uit de praktijk bekijken waarin deze een belangrijke rol speelde.

Interpolatie

Hier is de beroemde detective Sherlock Holmes, die een interpolatieaanval uitvoert op de ongelukkige Dr. Watson:

Ik vermoedde meteen dat je uit Afghanistan kwam... Mijn gedachtegang was als volgt: “Deze man is een dokter van type, maar hij heeft een militaire achtergrond. Een militaire dokter dus. Hij is net uit de tropen aangekomen - zijn gezicht is donker, maar dit is niet de natuurlijke tint van zijn huid, aangezien zijn polsen veel witter zijn. Het gezicht is verwilderd - hij heeft duidelijk veel geleden en heeft last gehad van ziekte. Hij raakte gewond aan zijn linkerhand - hij houdt hem roerloos en een beetje onnatuurlijk vast. Waar in de tropen kon een Engelse militaire arts ontberingen doorstaan ​​en gewond raken? Natuurlijk, in Afghanistan." De hele gedachtegang duurde nog geen seconde. En dus zei ik dat je uit Afghanistan kwam, en je was verrast.

Holmes kon heel weinig informatie uit elk stukje bewijsmateriaal afzonderlijk halen. Hij kon alleen tot zijn conclusie komen door ze allemaal samen te beschouwen. Een interpolatieaanval werkt op dezelfde manier door bekende leesbare tekst- en cijfertekstparen te onderzoeken die uit dezelfde sleutel voortkomen. Uit elk paar worden individuele waarnemingen gehaald die het mogelijk maken een algemene conclusie over de sleutel te trekken. Al deze conclusies zijn vaag en lijken nutteloos totdat ze plotseling een kritische massa bereiken en tot de enig mogelijke conclusie leiden: hoe ongelooflijk het ook is, het moet waar zijn. Hierna wordt de sleutel onthuld, of wordt het decoderingsproces zo verfijnd dat het kan worden gerepliceerd.

Laten we met een eenvoudig voorbeeld illustreren hoe interpolatie werkt. Laten we zeggen dat we het persoonlijke dagboek van onze vijand, Bob, willen lezen. Hij codeert elk nummer in zijn dagboek met behulp van een eenvoudig cryptosysteem dat hij leerde kennen uit een advertentie in het tijdschrift 'A Mock of Cryptography'. Het systeem werkt als volgt: Bob kiest twee getallen die hij leuk vindt: и . Vanaf nu kunt u elk nummer coderen , het berekent . Als Bob bijvoorbeeld kiest и en vervolgens het nummer wordt gecodeerd als .

Laten we zeggen dat we op 28 december merkten dat Bob iets in zijn dagboek aan het krabbelen was. Als hij klaar is, pakken we hem rustig op en bekijken de laatste inzending:

datum: 235/520

Lief Dagboek,

Vandaag was een goede dag. Door 64 vandaag heb ik een date met Alisa, die in een appartement woont 843. Ik denk echt dat ze dat zou kunnen zijn 26!

Omdat we Bob heel serieus willen volgen op zijn date (in dit scenario zijn we 15 jaar oud), is het van cruciaal belang om zowel de datum als het adres van Alice te weten. Gelukkig merken we dat het cryptosysteem van Bob kwetsbaar is voor een interpolatieaanval. Misschien weten we het niet и , maar we weten de datum van vandaag, dus we hebben twee paren in leesbare tekst en cijfertekst. Dat weten we namelijk versleuteld En - in . Dit is wat we zullen opschrijven:

Sinds we 15 jaar oud zijn, kennen we al een stelsel van twee vergelijkingen met twee onbekenden, wat in deze situatie voldoende is om te vinden и probleemloos. Elk paar leesbare tekst en cijfertekst legt een beperking op de sleutel van Bob, en de twee beperkingen samen zijn voldoende om de sleutel volledig te herstellen. In ons voorbeeld is het antwoord и (Bij , zodat 26 in het dagboek komt overeen met het woord 'die ene', dat wil zeggen "dezelfde" - ongeveer. rijbaan).

Interpolatieaanvallen blijven uiteraard niet beperkt tot zulke eenvoudige voorbeelden. Elk cryptosysteem dat zich reduceert tot een goed begrepen wiskundig object en een lijst met parameters loopt het risico van een interpolatieaanval: hoe begrijpelijker het object, hoe groter het risico.

Nieuwkomers klagen vaak dat cryptografie ‘de kunst is om dingen zo lelijk mogelijk te ontwerpen’. Interpolatie-aanvallen zijn waarschijnlijk grotendeels de schuldige. Bob kan een elegant wiskundig ontwerp gebruiken of zijn date met Alice privé houden, maar helaas kun je meestal niet beide kanten op. Dit zal overduidelijk worden als we uiteindelijk bij het onderwerp van publieke-sleutelcryptografie komen.

Cross-protocol/downgrade

In Now You See Me (2013) probeert een groep illusionisten de corrupte verzekeringsmagnaat Arthur Tressler zijn hele fortuin af te troggelen. Om toegang te krijgen tot Arthur's bankrekening, moeten de illusionisten ofwel zijn gebruikersnaam en wachtwoord opgeven, ofwel hem dwingen persoonlijk bij de bank te verschijnen en aan het plan deel te nemen.

Beide opties zijn erg moeilijk; De jongens zijn gewend om op het podium op te treden en niet deel te nemen aan inlichtingenoperaties. Dus kiezen ze voor de derde mogelijke optie: hun handlanger belt de bank en doet zich voor als Arthur. De bank stelt verschillende vragen om de identiteit te verifiëren, zoals de naam van de oom en de naam van het eerste huisdier; onze helden alvast ze halen deze informatie gemakkelijk uit Arthur met behulp van slimme social engineering. Vanaf dit punt doet uitstekende wachtwoordbeveiliging er niet meer toe.

(Volgens een stadslegende die we persoonlijk hebben geverifieerd en geverifieerd, kwam cryptograaf Eli Beaham ooit een bankmedewerker tegen die erop stond een veiligheidsvraag te stellen. Toen de kassier naar de naam van zijn grootmoeder van moederskant vroeg, begon Beaham te dicteren: ‘Hoofdletter X, kleine y, drie... ").

Hetzelfde geldt voor cryptografie, als twee cryptografische protocollen parallel worden gebruikt om hetzelfde bezit te beschermen, en de ene veel zwakker is dan de andere. Het resulterende systeem wordt kwetsbaar voor een protocoloverschrijdende aanval, waarbij een zwakker protocol wordt aangevallen om de prijs te pakken te krijgen zonder het sterkere protocol aan te raken.

In sommige complexe gevallen is het niet voldoende om eenvoudigweg contact op te nemen met de server via een zwakker protocol, maar is de onvrijwillige deelname van een legitieme client vereist. Dit kan worden georganiseerd met behulp van de zogenaamde downgrade-aanval. Laten we, om deze aanval te begrijpen, aannemen dat onze illusionisten een moeilijkere taak hebben dan in de film. Laten we aannemen dat een bankmedewerker (kassier) en Arthur met onvoorziene omstandigheden te maken kregen, resulterend in de volgende dialoog:

Inbreker: Hallo? Dit is Arthur Tressler. Ik wil graag mijn wachtwoord opnieuw instellen.

Kassa: Geweldig. Kijk eens in uw persoonlijke geheime codeboek, pagina 28, woord 3. Alle volgende berichten worden gecodeerd met dit specifieke woord als sleutel. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Inbreker: Hé, hé, wacht, wacht. Is dit echt nodig? Kunnen we niet gewoon praten als normale mensen?

Kassa: Ik raad niet aan dit te doen.

Inbreker: Ik... kijk, ik heb een slechte dag gehad, oké? Ik ben een VIP-klant en ik heb geen zin om door deze stomme codeboeken te bladeren.

Kassa: Prima. Als u erop staat, meneer Tressler. Wat wil je?

Inbreker: Alsjeblieft, ik wil graag al mijn geld doneren aan het Arthur Tressler National Victims Fund.

(Pauze).

Kassa: Is het nu duidelijk. Geef bij grote transacties uw pincode op.

Inbreker: Mijn Wat?

Kassa: Op uw persoonlijk verzoek is voor transacties van deze omvang bij grote transacties een pincode vereist. Deze code heeft u gekregen toen u uw account opende.

Inbreker:... Ik ben het kwijt. Is dit echt nodig? Kun je de deal niet gewoon goedkeuren?

Kassa: Nee. Het spijt me, meneer Tressler. Nogmaals, dit is de beveiligingsmaatregel waar u om vroeg. Als u wilt, kunnen wij een nieuwe pincode naar uw mailbox sturen.

Onze helden stellen de operatie uit. Ze luisteren naar verschillende grote transacties van Tressler, in de hoop de pincode te horen; maar elke keer verandert het gesprek in gecodeerd gebrabbel voordat er iets interessants wordt gezegd. Eindelijk, op een mooie dag, wordt het plan in praktijk gebracht. Ze wachten geduldig op het moment dat Tressler een grote transactie moet doen via de telefoon, hij aan de lijn komt, en dan...

Tressler: Hallo. Ik wil graag een transactie op afstand voltooien.

Kassa: Geweldig. Kijk eens naar uw persoonlijke geheime codeboek, pagina...

(De inbreker drukt op de knop; de stem van de kassamedewerker verandert in onverstaanbaar geluid).

Kassa: - #@$#@$#*@$$@#* wordt gecodeerd met dit woord als sleutel. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Sorry, ik begreep het niet helemaal. Opnieuw? Op welke pagina? Welk woord?

Kassa: Dit is de pagina @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Wat?

Kassa: Woord nummer twintig @$#@$#%#$.

Tressler: Ernstig! Al genoeg! Jij en je beveiligingsprotocol zijn een soort circus. Ik weet dat je gewoon normaal tegen me kunt praten.

Kassa: Ik raad het niet aan…

Tressler: En ik raad je niet aan mijn tijd te verspillen. Ik wil hier niets meer over horen totdat je de problemen met je telefoonlijn hebt opgelost. Kunnen we deze deal rondmaken of niet?

Kassa:… Ja. Prima. Wat wil je?

Tressler: Ik wil graag $20 overmaken naar Lord Business Investments, rekeningnummer...

Kassa: Een minuutje alstublieft. Het is een groot probleem. Geef bij grote transacties uw pincode op.

Tressler: Wat? O, precies. 1234.

Hier is een neerwaartse aanval. Het zwakkere protocol "spreek gewoon rechtstreeks" werd voorgesteld als optie bij noodgevallen. En toch zijn we hier.

Je vraagt ​​je misschien af ​​wie bij zijn volle verstand een echt ‘veilig tot anders gevraagd’-systeem zou ontwerpen, zoals hierboven beschreven. Maar net zoals een fictieve bank risico's neemt om klanten te behouden die niet van cryptografie houden, neigen systemen in het algemeen vaak naar eisen die onverschillig zijn of zelfs ronduit vijandig tegenover de veiligheid staan.

Dit is precies wat er in 2 gebeurde met het SSLv1995-protocol. De Amerikaanse regering begint cryptografie al lang te zien als een wapen dat het beste buiten de handen van buitenlandse en binnenlandse vijanden kan worden gehouden. Stukjes code werden individueel goedgekeurd voor export vanuit de Verenigde Staten, vaak met de voorwaarde dat het algoritme opzettelijk werd afgezwakt. Netscape, de ontwikkelaar van de populairste browser, Netscape Navigator, kreeg alleen toestemming voor SSLv2 met de inherent kwetsbare 512-bit RSA-sleutel (en 40-bit voor RC4).

Tegen het einde van het millennium waren de regels versoepeld en werd de toegang tot moderne encryptie algemeen beschikbaar. Clients en servers ondersteunen echter al jaren verzwakte ‘export’-cryptografie vanwege dezelfde traagheid die de ondersteuning voor elk oud systeem in stand houdt. Klanten dachten dat ze een server zouden tegenkomen die niets anders ondersteunde. De servers deden hetzelfde. Uiteraard schrijft het SSL-protocol voor dat clients en servers nooit een zwak protocol mogen gebruiken als er een beter protocol beschikbaar is. Maar hetzelfde uitgangspunt gold voor Tressler en zijn bank.

Deze theorie vond zijn weg naar twee spraakmakende aanvallen die de veiligheid van het SSL-protocol in 2015 opschudden, beide ontdekt door Microsoft-onderzoekers en INRIA. Eerst werden in februari details van de FREAK-aanval onthuld, drie maanden later gevolgd door een andere soortgelijke aanval genaamd Logjam, die we in meer detail zullen bespreken als we verder gaan met aanvallen op cryptografie met openbare sleutels.

Kwetsbaarheid FREAK (ook bekend als "Smack TLS") kwam aan het licht toen onderzoekers TLS-client/server-implementaties analyseerden en een merkwaardige bug ontdekten. Als de client bij deze implementaties niet eens vraagt ​​om zwakke exportcryptografie te gebruiken, maar de server nog steeds met dergelijke sleutels reageert, zegt de client 'Ach,' en schakelt over naar een zwakke coderingssuite.

Destijds werd exportcryptografie algemeen als verouderd en verboden beschouwd, dus de aanval kwam als een complete schok en trof veel belangrijke domeinen, waaronder het Witte Huis, de IRS en NSA-sites. Erger nog, het blijkt dat veel kwetsbare servers de prestaties optimaliseerden door dezelfde sleutels te hergebruiken in plaats van voor elke sessie nieuwe te genereren. Dit maakte het mogelijk om, na het downgraden van het protocol, een pre-computation-aanval uit te voeren: het kraken van één sleutel bleef relatief duur ($100 en 12 uur op het moment van publicatie), maar de praktische kosten van het aanvallen van de verbinding werden aanzienlijk verminderd. Het is voldoende om één keer de serversleutel te selecteren en vanaf dat moment de codering voor alle volgende verbindingen te kraken.

En voordat we verder gaan, is er één geavanceerde aanval die moet worden genoemd...

Orakel aanval

Moxie Marlijnspike vooral bekend als de vader van de platformonafhankelijke crypto-berichtenapp Signal; maar persoonlijk houden we van een van zijn minder bekende innovaties: principe van cryptografische ondergang (Cryptografisch doemprincipe). Om het enigszins te parafraseren kunnen we dit zeggen: “Als het protocol werkt elk een cryptografische bewerking uitvoert op een bericht van een potentieel kwaadaardige bron en zich afhankelijk van het resultaat anders gedraagt, is het gedoemd." Of in scherpere vorm: “Neem geen informatie van de vijand ter verwerking, en als het moet, laat dan in ieder geval het resultaat niet zien.”

Laten we bufferoverflows, commando-injecties en dergelijke buiten beschouwing laten; ze vallen buiten het bestek van deze discussie. Schending van het ‘doomprincipe’ leidt tot ernstige cryptografie-hacks vanwege het feit dat het protocol zich precies gedraagt ​​zoals verwacht.

Laten we als voorbeeld een fictief ontwerp nemen met een kwetsbaar vervangingscijfer en vervolgens een mogelijke aanval demonstreren. Hoewel we al een aanval op een vervangingscijfer hebben gezien met behulp van frequentieanalyse, is het niet alleen maar 'een andere manier om hetzelfde cijfer te kraken'. Integendeel, orakelaanvallen zijn een veel modernere uitvinding, toepasbaar in veel situaties waarin frequentieanalyse mislukt, en we zullen hiervan in de volgende sectie een demonstratie zien. Hier is alleen het eenvoudige cijfer gekozen om het voorbeeld duidelijker te maken.

Dus Alice en Bob communiceren met behulp van een eenvoudig vervangingscijfer met behulp van een sleutel die alleen zij kennen. Ze zijn erg streng over de lengte van berichten: ze zijn precies 20 tekens lang. Ze waren het er dus over eens dat als iemand een korter bericht wilde sturen, hij een dummytekst aan het einde van het bericht moest toevoegen, zodat het precies 20 tekens lang was. Na enige discussie besloten ze dat ze alleen de volgende proefteksten zouden accepteren: a, bb, ccc, dddd enz. Zo is een proeftekst van elke gewenste lengte bekend.

Wanneer Alice of Bob een bericht ontvangen, controleren ze eerst of het bericht de juiste lengte heeft (20 tekens) en of het achtervoegsel de juiste dummytekst is. Als dit niet het geval is, reageren ze met een passende foutmelding. Als de tekstlengte en de dummytekst in orde zijn, leest de ontvanger het bericht zelf en verzendt een gecodeerd antwoord.

Tijdens de aanval doet de aanvaller zich voor als Bob en stuurt valse berichten naar Alice. De berichten zijn complete onzin: de aanvaller heeft de sleutel niet en kan daarom geen betekenisvolle boodschap vervalsen. Maar aangezien het protocol het doemprincipe schendt, kan een aanvaller Alice nog steeds in de val lokken om de belangrijkste informatie te onthullen, zoals hieronder weergegeven.

Inbreker: PREWF ZHJKL MMMN. LA

Alice: Ongeldige dummytekst.

Inbreker: PREWF ZHJKL MMMN. LB

Alice: Ongeldige dummytekst.

Inbreker: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

De inbreker heeft geen idee wat Alice net zei, maar merkt op dat het symbool is C moet overeenkomen a, aangezien Alice de proeftekst accepteerde.

Inbreker: REWF ZHJKL MMMN. LAA

Alice: Ongeldige dummytekst.

Inbreker: REWF ZHJKL MMMN. LBB

Alice: Ongeldige dummytekst.

Na een aantal pogingen...

Inbreker: REWF ZHJKL MMMN. LGG

Alice: Ongeldige dummytekst.

Inbreker: REWF ZHJKL MMMN. LHH

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

Nogmaals, de aanvaller heeft geen idee wat Alice zojuist zei, maar merkt op dat H moet overeenkomen met b aangezien Alice de dummytekst heeft geaccepteerd.

En zo verder totdat de aanvaller de betekenis van elk personage kent.

Op het eerste gezicht lijkt de methode op een gekozen aanval in platte tekst. Uiteindelijk selecteert de aanvaller de cijferteksten en verwerkt de server deze gehoorzaam. Het belangrijkste verschil dat deze aanvallen in de echte wereld levensvatbaar maakt, is dat de aanvaller geen toegang nodig heeft tot het daadwerkelijke transcript. Een serverreactie, zelfs zo onschadelijk als 'Ongeldige dummytekst', is voldoende.

Hoewel deze specifieke aanval leerzaam is, moet je je niet te veel bezighouden met de details van het 'dummytekst'-schema, het specifieke cryptosysteem dat wordt gebruikt of de exacte volgorde van de berichten die door de aanvaller worden verzonden. Het basisidee is hoe Alice anders reageert op basis van de eigenschappen van de leesbare tekst, en doet dit zonder te verifiëren dat de bijbehorende cijfertekst daadwerkelijk van een vertrouwde partij afkomstig is. Zo laat Alice de aanvaller geheime informatie uit haar antwoorden persen.

Er kan veel veranderd worden in dit scenario. De symbolen waarop Alice reageert, of het verschil in haar gedrag, of zelfs het gebruikte cryptosysteem. Maar het principe zal hetzelfde blijven, en de aanval als geheel zal in een of andere vorm levensvatbaar blijven. De basisimplementatie van deze aanval hielp bij het blootleggen van verschillende beveiligingsbugs, die we binnenkort zullen bekijken; maar eerst moeten er enkele theoretische lessen worden geleerd. Hoe gebruik je dit fictieve ‘Alice-script’ in een aanval die kan werken op een echt modern cijfer? Is dit zelfs mogelijk, zelfs in theorie?

In 1998 beantwoordde de Zwitserse cryptograaf Daniel Bleichenbacher deze vraag bevestigend. Hij demonstreerde een orakelaanval op het veelgebruikte publieke sleutel cryptosysteem RSA, met behulp van een specifiek berichtenschema. In sommige RSA-implementaties reageert de server met verschillende foutmeldingen, afhankelijk van of de leesbare tekst overeenkomt met het schema of niet; dit was genoeg om de aanval uit te voeren.

Vier jaar later, in 2002, demonstreerde de Franse cryptograaf Serge Vaudenay een orakelaanval die vrijwel identiek was aan de aanval beschreven in het Alice-scenario hierboven - behalve dat hij in plaats van een fictief cijfer een hele respectabele klasse van moderne cijfers brak die mensen feitelijk gebruiken. De aanval van Vaudenay richt zich met name op cijfers met een vaste invoergrootte ("blokcijfers") wanneer deze worden gebruikt in de zogenaamde "CBC-coderingsmodus" en met een bepaald populair opvulschema, dat in principe gelijkwaardig is aan dat in het Alice-scenario.

Ook in 2002 werd de Amerikaanse cryptograaf John Kelsey co-auteur Twofish – stelde verschillende orakelaanvallen voor op systemen die berichten comprimeren en vervolgens versleutelen. De meest opvallende hiervan was een aanval waarbij gebruik werd gemaakt van het feit dat het vaak mogelijk is om de oorspronkelijke lengte van de leesbare tekst af te leiden uit de lengte van de cijfertekst. In theorie maakt dit een orakelaanval mogelijk die delen van de originele leesbare tekst herstelt.

Hieronder geven we een meer gedetailleerde beschrijving van de Vaudenay- en Kelsey-aanvallen (we zullen een meer gedetailleerde beschrijving geven van de Bleichenbacher-aanval als we verder gaan met aanvallen op publieke-sleutelcryptografie). Ondanks onze inspanningen wordt de tekst enigszins technisch; dus als het bovenstaande genoeg voor je is, sla dan de volgende twee secties over.

Vodene's aanval

Om de Vaudenay-aanval te begrijpen, moeten we eerst wat meer praten over blokcijfers en encryptiemodi. Een "blokcijfer" is, zoals gezegd, een cijfer dat een sleutel en een invoer van een bepaalde vaste lengte ("bloklengte") nodig heeft en een gecodeerd blok van dezelfde lengte produceert. Blokcodes worden veel gebruikt en als relatief veilig beschouwd. De nu gepensioneerde DES, beschouwd als het eerste moderne cijfer, was een blokcijfer. Zoals hierboven vermeld, geldt hetzelfde voor AES, dat tegenwoordig veel wordt gebruikt.

Helaas hebben blokcijfers één opvallende zwakte. De typische blokgrootte is 128 bits of 16 tekens. Het is duidelijk dat moderne cryptografie het werken met grotere invoergegevens vereist, en dit is waar versleutelingsmodi een rol gaan spelen. De versleutelingsmodus is in wezen een hack: het is een manier om op de een of andere manier een blokcode toe te passen die alleen invoer van een bepaalde grootte accepteert op invoer van een willekeurige lengte.

De aanval van Vodene is gericht op de populaire CBC-modus (Cipher Block Chaining). De aanval behandelt het onderliggende blokcijfer als een magische, onneembare zwarte doos en omzeilt de beveiliging ervan volledig.

Hier is een diagram dat laat zien hoe de CBC-modus werkt:

Het omcirkelde plusje geeft de XOR-bewerking (exclusieve OR) aan. Het tweede blok cijfertekst wordt bijvoorbeeld ontvangen:

1. Door een XOR-bewerking uit te voeren op het tweede leesbare tekstblok met het eerste cijfertekstblok.
2. Het resulterende blok coderen met een blokcijfer met behulp van een sleutel.

Omdat CBC zo intensief gebruik maakt van de binaire XOR-bewerking, nemen we even de tijd om enkele eigenschappen ervan in herinnering te brengen:

• Idempotentie:
• Commutativiteit:
• Associativiteit:
• Zelf-omkeerbaarheid:
• Bytegrootte: byte n van = (byte n van ) (byte n van )

Deze eigenschappen impliceren doorgaans dat als we een vergelijking hebben met XOR-bewerkingen en één onbekende, deze kan worden opgelost. Als we dat weten bijvoorbeeld met het onbekende en beroemd и , dan kunnen we vertrouwen op de bovengenoemde eigenschappen hierboven om de vergelijking op te lossen . Door XOR aan beide kanten van de vergelijking toe te passen met , we krijgen . Dit zal allemaal binnen enkele ogenblikken zeer relevant worden.

Er zijn twee kleine verschillen en één groot verschil tussen ons Alice-scenario en de aanval van Vaudenay. Twee kleine:

• In het script verwachtte Alice dat platte teksten zouden eindigen met de personages a, bb, ccc enzovoort. Bij de Wodene-aanval verwacht het slachtoffer in plaats daarvan dat de platte tekst N keer eindigt met de N byte (dat wil zeggen, hexadecimaal 01 of 02 02, of 03 03 03, enzovoort). Dit is puur een cosmetisch verschil.
• In het Alice-scenario was het gemakkelijk om te zien of Alice het bericht had geaccepteerd door het antwoord 'Onjuiste dummytekst'. Bij de aanval van Vodene is meer analyse nodig en is een nauwkeurige implementatie aan de kant van het slachtoffer belangrijk; maar laten we kortheidshalve ervan uitgaan dat deze analyse nog steeds mogelijk is.

Grootste verschil:

• Omdat we niet hetzelfde cryptosysteem gebruiken, zal de relatie tussen de door de aanvaller bestuurde cijfertekstbytes en de geheimen (sleutel en leesbare tekst) uiteraard anders zijn. Daarom zal de aanvaller een andere strategie moeten gebruiken bij het maken van cijferteksten en het interpreteren van serverreacties.

Dit grote verschil is het laatste stukje van de puzzel om de Vaudenay-aanval te begrijpen, dus laten we even nadenken over waarom en hoe een orakelaanval op CBC überhaupt kan worden opgezet.

Stel dat we een CBC-cijfertekst van 247 blokken krijgen en deze willen decoderen. We kunnen nepberichten naar de server sturen, net zoals we voorheen nepberichten naar Alice konden sturen. De server zal de berichten voor ons decoderen, maar zal de decodering niet tonen - in plaats daarvan zal de server, net als bij Alice, slechts één stukje informatie rapporteren: of de leesbare tekst geldige opvulling heeft of niet.

Bedenk dat we in het scenario van Alice de volgende relaties hadden:

$$display$$text{SIMPLE_SUBSTITUTION}(tekst{cijfertekst},tekst{sleutel}) = tekst{plaintext}$$display$$

Laten we dit 'Alice's vergelijking' noemen. Wij controleerden de cijfertekst; de server (Alice) lekte vage informatie over de ontvangen platte tekst; en hierdoor konden we informatie afleiden over de laatste factor: de sleutel. Naar analogie, als we een dergelijke connectie voor het CBC-script kunnen vinden, kunnen we daar misschien ook wat geheime informatie uithalen.

Gelukkig zijn er echt relaties die we kunnen gebruiken. Beschouw de uitvoer van de laatste oproep om een ​​blokcijfer te decoderen en geef deze uitvoer aan als . We duiden ook blokken platte tekst aan en cijfertekstblokken . Kijk nog eens naar het CBC-diagram en merk op wat er gebeurt:

Laten we dit de ‘CBC-vergelijking’ noemen.

In het scenario van Alice konden we, door de cijfertekst te monitoren en het bijbehorende lek in de leesbare tekst te bekijken, een aanval opzetten die de derde term in de vergelijking – de sleutel – terugvond. In het CBC-scenario monitoren we ook de cijfertekst en observeren we informatielekken op de bijbehorende leesbare tekst. Als de analogie klopt, kunnen we er informatie over verkrijgen .

Laten we aannemen dat we echt hersteld zijn , wat dan? Welnu, dan kunnen we het hele laatste blok platte tekst in één keer afdrukken (), gewoon door in te voeren (die we hebben) en
ontvangen in de CBC-vergelijking.

Nu we optimistisch zijn over het algemene aanvalsplan, is het tijd om de details uit te werken. Let op hoe de leesbare informatie precies op de server wordt gelekt. In het script van Alice vond het lek plaats omdat Alice alleen reageerde met het juiste bericht als $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ eindigde met de regel a (Of bb, enzovoort, maar de kans dat deze omstandigheden door toeval werden veroorzaakt, was zeer klein). Net als bij CBC accepteert de server de opvulling als en slechts als eindigt op hexadecimaal 01. Laten we dus dezelfde truc proberen: valse cijferteksten sturen met onze eigen valse waarden totdat de server de vulling accepteert.

Wanneer de server een opvulling accepteert voor een van onze nepberichten, betekent dit dat:

Nu gebruiken we de byte-byte XOR-eigenschap:

We kennen de eerste en derde term. En we hebben al gezien dat we hierdoor de resterende term - de laatste byte - kunnen herstellen :

Dit geeft ons ook de laatste byte van het laatste leesbare tekstblok via de CBC-vergelijking en de byte-voor-byte-eigenschap.

We zouden het daarbij kunnen laten en tevreden zijn dat we een aanval hebben uitgevoerd op een theoretisch sterk cijfer. Maar in feite kunnen we veel meer doen: we kunnen daadwerkelijk de hele tekst herstellen. Dit vereist een truc die niet in het originele script van Alice zat en die niet vereist is voor de orakelaanval, maar het is nog steeds de moeite waard om te leren.

Om dit te begrijpen, moet u eerst opmerken dat het resultaat van het uitvoeren van de juiste waarde van de laatste byte is we hebben een nieuw vermogen. Bij het vervalsen van cijferteksten kunnen we nu de laatste byte van de overeenkomstige leesbare tekst manipuleren. Nogmaals, dit houdt verband met de CBC-vergelijking en de byte-voor-byte-eigenschap:

Omdat we nu de tweede term kennen, kunnen we onze controle over de eerste gebruiken om de derde te beheersen. Wij berekenen eenvoudig:

We konden dit voorheen niet doen omdat we de laatste byte nog niet hadden .

Hoe zal dit ons helpen? Stel dat we nu alle cijferteksten zo creëren dat in de overeenkomstige leesbare teksten de laatste byte gelijk is aan 02. De server accepteert nu alleen opvulling als de platte tekst eindigt met 02 02. Omdat we de laatste byte hebben gecorrigeerd, gebeurt dit alleen als de voorlaatste byte van de leesbare tekst ook 02 is. We blijven valse cijfertekstblokken verzenden, waarbij we de voorlaatste byte veranderen, totdat de server de opvulling voor een ervan accepteert. Op dit punt krijgen we:

En we herstellen de voorlaatste byte net zoals de vorige werd hersteld. We gaan in dezelfde geest verder: we corrigeren de laatste twee bytes van de leesbare tekst naar 03 03, herhalen we deze aanval voor de derde byte vanaf het einde enzovoort, om uiteindelijk volledig te herstellen .

Hoe zit het met de rest van de tekst? Houd er rekening mee dat de waarde is eigenlijk $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. We kunnen er elk ander blok voor in de plaats plaatsen , en de aanval zal nog steeds succesvol zijn. In feite kunnen we de server vragen om $inline$text{BLOCK_DECRYPT}$inline$ uit te voeren voor alle gegevens. Op dit punt is het spel voorbij: we kunnen elke cijfertekst ontsleutelen (kijk nog eens naar het CBC-decoderingsdiagram om dit te zien; en merk op dat de IV openbaar is).

Deze specifieke methode speelt een cruciale rol in de orakelaanval die we later zullen tegenkomen.

Kelsey's aanval

Onze sympathieke John Kelsey legde de principes uit die ten grondslag liggen aan veel mogelijke aanvallen, niet alleen de details van een specifieke aanval op een specifiek cijfer. Zijn 2002-artikel van het jaar is een onderzoek naar mogelijke aanvallen op gecodeerde gecomprimeerde gegevens. Dacht u dat de informatie dat de gegevens vóór de versleuteling waren gecomprimeerd, niet voldoende was om een ​​aanval uit te voeren? Het blijkt dat dat genoeg is.

Dit verrassende resultaat is te danken aan twee principes. Ten eerste is er een sterke correlatie tussen de lengte van de leesbare tekst en de lengte van de cijfertekst; voor veel cijfers exacte gelijkheid. Ten tweede is er, wanneer er compressie wordt uitgevoerd, ook een sterke correlatie tussen de lengte van het gecomprimeerde bericht en de mate van ‘ruis’ van de leesbare tekst, dat wil zeggen het aandeel niet-herhalende karakters (de technische term is ‘hoge entropie’). ).

Om het principe in actie te zien, overweeg twee leesbare teksten:

Platte tekst 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Platte tekst 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Laten we aannemen dat beide leesbare teksten zijn gecomprimeerd en vervolgens gecodeerd. Je krijgt twee resulterende cijferteksten en moet raden welke cijfertekst overeenkomt met welke leesbare tekst:

Cijfertekst 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Cijfertekst 2: DWKJZXYU

Het antwoord is duidelijk. Van de leesbare teksten kon alleen leesbare tekst 1 worden gecomprimeerd tot de magere lengte van de tweede cijfertekst. We kwamen hier achter zonder iets te weten over het compressie-algoritme, de coderingssleutel of zelfs het cijfer zelf. Vergeleken met de hiërarchie van mogelijke cryptografische aanvallen is dit nogal gek.

Kelsey wijst er verder op dat dit principe onder bepaalde ongebruikelijke omstandigheden ook kan worden gebruikt om een ​​orakelaanval uit te voeren. In het bijzonder wordt beschreven hoe een aanvaller de geheime leesbare tekst kan herstellen als hij de server kan dwingen de formuliergegevens te coderen (de leesbare tekst gevolgd door terwijl hij de controle heeft en kan op de een of andere manier de lengte van het gecodeerde resultaat controleren.

Nogmaals, net als bij andere orakelaanvallen hebben we de relatie:

Opnieuw controleren we één term (), zien we een klein lek aan informatie over een ander lid (cijfertekst) en proberen we de laatste te herstellen (plaintext). Ondanks de analogie is dit een enigszins ongebruikelijke situatie vergeleken met andere orakelaanvallen die we hebben gezien.

Laten we, om te illustreren hoe zo'n aanval zou kunnen werken, een fictief compressieschema gebruiken dat we zojuist hebben bedacht: TOYZIP. Het zoekt naar tekstregels die eerder in de tekst zijn verschenen en vervangt deze door drie tijdelijke bytes die aangeven waar een eerder exemplaar van de regel te vinden is en hoe vaak deze daar voorkomt. De lijn bijvoorbeeld helloworldhello kan worden gecomprimeerd helloworld[00][00][05] 13 bytes lang vergeleken met de oorspronkelijke 15 bytes.

Stel dat een aanvaller de leesbare tekst van een formulier probeert te herstellen password=..., waarbij het wachtwoord zelf onbekend is. Volgens het aanvalsmodel van Kelsey kan een aanvaller de server vragen formulierberichten te comprimeren en vervolgens te coderen (plaintext gevolgd door ) waar  - vrije tekst. Wanneer de server klaar is met werken, rapporteert hij de lengte van het resultaat. De aanval gaat als volgt:

Inbreker: Comprimeer en versleutel de leesbare tekst zonder opvulling.

Server: Resultaatlengte 14.

Inbreker: Comprimeer en codeer de platte tekst waaraan deze is toegevoegd password=a.

Server: Resultaatlengte 18.

De cracker merkt op: [origineel 14] + [drie bytes die vervangen zijn password=] + a

Inbreker: Comprimeer en codeer de platte tekst waaraan wordt toegevoegd password=b.

Server: Resultaatlengte 18.

Inbreker: Comprimeer en codeer de platte tekst waaraan wordt toegevoegd password=с.

Server: Resultaatlengte 17.

De cracker merkt op: [origineel 14] + [drie bytes die vervangen zijn password=c]. Hierbij wordt ervan uitgegaan dat de originele leesbare tekst de string bevat password=c. Dat wil zeggen dat het wachtwoord begint met een letter c

Inbreker: Comprimeer en codeer de platte tekst waaraan wordt toegevoegd password=сa.

Server: Resultaatlengte 18.

De cracker merkt op: [origineel 14] + [drie bytes die vervangen zijn password=с] + a

Inbreker: Comprimeer en codeer de platte tekst waaraan wordt toegevoegd password=сb.

Server: Resultaatlengte 18.

(… Enige tijd later…)

Inbreker: Comprimeer en codeer de platte tekst waaraan wordt toegevoegd password=со.

Server: Resultaatlengte 17.

De cracker merkt op: [origineel 14] + [drie bytes die vervangen zijn password=co]. Met behulp van dezelfde logica concludeert de aanvaller dat het wachtwoord met de letters begint co

En zo verder totdat het volledige wachtwoord is hersteld.

Het zou de lezer vergeven zijn als hij zou denken dat dit een puur academische exercitie is en dat een dergelijk aanvalsscenario zich in de echte wereld nooit zou voordoen. Helaas, zoals we snel zullen zien, is het beter om cryptografie niet op te geven.

Merkkwetsbaarheden: CRIME, POEDEL, VERDRINKEN

Nadat we de theorie in detail hebben bestudeerd, kunnen we eindelijk zien hoe deze technieken worden toegepast in echte cryptografische aanvallen.

MISDRIJF

Als de aanval gericht is op de browser en het netwerk van het slachtoffer, zullen sommige gemakkelijker en andere moeilijker zijn. Zo is het verkeer van het slachtoffer gemakkelijk te zien: ga gewoon met hem in hetzelfde café met wifi zitten. Om deze reden wordt potentiële slachtoffers (dus iedereen) over het algemeen geadviseerd een gecodeerde verbinding te gebruiken. Het zal moeilijker zijn, maar nog steeds mogelijk, om namens het slachtoffer HTTP-verzoeken in te dienen bij een site van derden (bijvoorbeeld Google). De aanvaller moet het slachtoffer naar een kwaadaardige webpagina lokken met een script dat het verzoek doet. De webbrowser levert automatisch de juiste sessiecookie.

Dit lijkt geweldig. Als Bob erheen ging evil.com, kan het script op deze site Google gewoon vragen om het wachtwoord van Bob te e-mailen [email protected]? Nou ja, in theorie wel, maar in werkelijkheid niet. Dit scenario wordt een cross-site request forgery-aanval genoemd (Vervalsing van verzoeken op meerdere sites, CSRF), en het was populair rond het midden van de jaren negentig. Vandaag als evil.com Als u deze truc probeert, zal Google (of een zichzelf respecterende website) meestal reageren met: 'Geweldig, maar uw CSRF-token voor deze transactie zal... eh... три триллиона и семь. Herhaal dit nummer." Moderne browsers hebben iets dat een ‘same-origin-beleid’ wordt genoemd, waarbij scripts op site A geen toegang hebben tot informatie verzonden door website B. Dus het script op evil.com kunt verzoeken sturen naar google.com, maar kan de reacties niet lezen of de transactie daadwerkelijk voltooien.

We moeten benadrukken dat, tenzij Bob een gecodeerde verbinding gebruikt, al deze beveiligingen zinloos zijn. Een aanvaller kan eenvoudig het verkeer van Bob lezen en de sessiecookie van Google herstellen. Met deze cookie opent hij eenvoudigweg een nieuw Google-tabblad zonder zijn eigen browser te verlaten en doet hij zich voor als Bob zonder hinderlijk same-origin-beleid tegen te komen. Maar helaas voor een inbreker komt dit steeds minder vaak voor. Het internet als geheel heeft lang de oorlog verklaard aan niet-gecodeerde verbindingen, en het uitgaande verkeer van Bob is waarschijnlijk gecodeerd, of hij dat nu leuk vindt of niet. Bovendien was er vanaf het allereerste begin van de implementatie van het protocol ook verkeer kromp vóór encryptie; dit was een gangbare praktijk om de latentie te verminderen.

Dit is waar het in het spel komt MISDRIJF (Compressieverhouding Infoleak Made Easy, eenvoudige lekkage door de compressieverhouding). De kwetsbaarheid werd in september 2012 onthuld door beveiligingsonderzoekers Juliano Rizzo en Thai Duong. We hebben de hele theoretische basis al onderzocht, waardoor we kunnen begrijpen wat ze deden en hoe. Een aanvaller kan de browser van Bob dwingen verzoeken naar Google te sturen en vervolgens in een gecomprimeerde, gecodeerde vorm naar de reacties op het lokale netwerk te luisteren. Daarom hebben we:

Hier beheert de aanvaller het verzoek en heeft hij toegang tot de verkeerssniffer, inclusief de pakketgrootte. Kelsey's fictieve scenario kwam tot leven.

De auteurs van CRIME begrepen de theorie en creëerden een exploit die sessiecookies kan stelen voor een breed scala aan sites, waaronder Gmail, Twitter, Dropbox en Github. De kwetsbaarheid trof de meeste moderne webbrowsers, waardoor er patches werden uitgebracht die de compressiefunctie in SSL stilletjes verborgen hielden, zodat deze helemaal niet zou worden gebruikt. De enige die tegen het beveiligingslek werd beschermd, was de eerbiedwaardige Internet Explorer, die helemaal nooit SSL-compressie gebruikte.

POEDEL

In oktober 2014 zorgde het beveiligingsteam van Google voor veel ophef in de beveiligingsgemeenschap. Ze konden misbruik maken van een kwetsbaarheid in het SSL-protocol die ruim tien jaar geleden was gepatcht.

Het blijkt dat, hoewel de servers het glimmende nieuwe TLSv1.2 draaien, velen de ondersteuning voor de oude SSLv3 hebben verlaten voor achterwaartse compatibiliteit met Internet Explorer 6. We hebben het al gehad over downgrade-aanvallen, dus je kunt je voorstellen wat er aan de hand is. Een goed georkestreerde sabotage van het handshake-protocol en de servers zijn klaar om terug te keren naar de goede oude SSLv3, waarmee in wezen de afgelopen 15 jaar aan beveiligingsonderzoek ongedaan wordt gemaakt.

Voor historische context, hier is een korte samenvatting van de geschiedenis van SSL tot en met versie 2 van Matthew Green:

Transport Layer Security (TLS) is het belangrijkste beveiligingsprotocol op internet. [..] vrijwel elke transactie die u op internet doet, is afhankelijk van TLS. [..] Maar TLS was niet altijd TLS. Het protocol begon zijn leven in Netscape Communicatie genaamd "Secure Sockets Layer" of SSL. Het gerucht gaat dat de eerste versie van SSL zo verschrikkelijk was dat de ontwikkelaars alle afdrukken van de code verzamelden en deze op een geheime stortplaats in New Mexico begroeven. Als gevolg hiervan is dit feitelijk de eerste publiekelijk beschikbare versie van SSL versie SSL2. Het is behoorlijk eng, en [..] het was een product uit het midden van de jaren negentig, dat moderne cryptografen beschouwen als "donkere tijden van cryptografie" Veel van de meest gruwelijke cryptografische aanvallen die we vandaag de dag kennen, zijn nog niet ontdekt. Als gevolg hiervan moesten de ontwikkelaars van het SSLv2-protocol in wezen in het ongewisse blijven, en werden ze geconfronteerd veel verschrikkelijke monsters - tot hun ergernis en in ons voordeel, aangezien de aanvallen op SSLv2 waardevolle lessen hebben achtergelaten voor de volgende generatie protocollen.

Na deze gebeurtenissen ontwierp een gefrustreerde Netscape in 1996 het SSL-protocol helemaal opnieuw. Het resultaat was SSL-versie 3, die verschillende bekende beveiligingsproblemen van zijn voorganger opgelost.

Gelukkig voor inbrekers betekent ‘een paar’ niet ‘allemaal’. Over het geheel genomen leverde SSLv3 alle noodzakelijke bouwstenen om een ​​Vodene-aanval te lanceren. Het protocol gebruikte een blokcodering in CBC-modus en een onveilig opvulschema (dit werd gecorrigeerd in TLS; vandaar de noodzaak van een downgrade-aanval). Als u zich het opvulschema uit onze oorspronkelijke beschrijving van de Vaudenay-aanval herinnert, lijkt het SSLv3-schema sterk op elkaar.

Maar helaas voor inbrekers betekent ‘soortgelijk’ niet ‘identiek’. Het SSLv3-opvullingsschema is "N willekeurige bytes gevolgd door het getal N". Probeer onder deze omstandigheden een denkbeeldig blok cijfertekst te selecteren en doorloop alle stappen van Vaudene's oorspronkelijke plan: je zult merken dat de aanval met succes de laatste byte uit het overeenkomstige blok leesbare tekst haalt, maar niet verder gaat. Het ontsleutelen van elke 16e byte van de cijfertekst is een geweldige truc, maar het is geen overwinning.

Geconfronteerd met een mislukking nam het Google-team zijn toevlucht tot een laatste redmiddel: ze schakelden over op een krachtiger dreigingsmodel: dat van CRIME. Ervan uitgaande dat de aanvaller een script is dat op het browsertabblad van het slachtoffer draait en sessiecookies kan extraheren, is de aanval nog steeds indrukwekkend. Hoewel het bredere dreigingsmodel minder realistisch is, hebben we in de vorige paragraaf gezien dat dit specifieke model haalbaar is.

Gezien deze krachtigere aanvallercapaciteiten kan de aanval nu worden voortgezet. Houd er rekening mee dat de aanvaller weet waar de gecodeerde sessiecookie in de header verschijnt en de lengte van het daaraan voorafgaande HTTP-verzoek bepaalt. Daarom kan het het HTTP-verzoek zo manipuleren dat de laatste byte van de cookie wordt uitgelijnd met het einde van het blok. Nu is deze byte geschikt voor decodering. U kunt eenvoudig één teken aan het verzoek toevoegen, en de voorlaatste byte van de cookie blijft op dezelfde plaats en is geschikt voor selectie via dezelfde methode. De aanval gaat op deze manier door totdat het cookiebestand volledig is hersteld. Het heet POODLE: Padding Oracle on Downgraded Legacy Encryption.

VERDRINKEN

Zoals we al zeiden, had SSLv3 zijn gebreken, maar het was fundamenteel anders dan zijn voorganger, aangezien de lekkende SSLv2 een product uit een ander tijdperk was. Daar zou je het bericht in het midden kunnen onderbreken: соглашусь на это только через мой труп veranderd in соглашусь на это; de client en de server kunnen elkaar online ontmoeten, vertrouwen opbouwen en geheimen uitwisselen in het bijzijn van de aanvaller, die vervolgens gemakkelijk beide kan nabootsen. Er is ook het probleem met exportcryptografie, dat we noemden bij het overwegen van FREAK. Dit waren de cryptografische Sodom en Gomorra.

In maart 2016 kwam een ​​team van onderzoekers uit verschillende technische vakgebieden samen en deed een verrassende ontdekking: SSLv2 wordt nog steeds gebruikt in beveiligingssystemen. Ja, aanvallers konden moderne TLS-sessies niet langer downgraden naar SSLv2 sinds dat gat na FREAK en POODLE was gedicht, maar ze kunnen nog steeds verbinding maken met servers en zelf SSLv2-sessies initiëren.

Je vraagt ​​je misschien af: wat maakt het ons uit wat ze daar doen? Ze hebben een kwetsbare sessie, maar dit zou geen invloed moeten hebben op andere sessies of de veiligheid van de server, toch? Nou ja, niet helemaal. Ja, zo zou het in theorie moeten zijn. Maar nee, want het genereren van SSL-certificaten brengt een bepaalde last met zich mee, waardoor veel servers dezelfde certificaten gebruiken en als gevolg daarvan dezelfde RSA-sleutels voor TLS- en SSLv2-verbindingen. Tot overmaat van ramp werkte de optie "SSLv2 uitschakelen" in deze populaire SSL-implementatie vanwege een OpenSSL-bug niet echt.

Dit maakte een protocoloverschrijdende aanval op TLS mogelijk, genaamd VERDRINKEN (Decryptie van RSA met verouderde en verzwakte encryptie, decryptie van RSA met verouderde en verzwakte encryptie). Bedenk dat dit niet hetzelfde is als een korte aanval; de aanvaller hoeft niet als ‘man in the middle’ op te treden en hoeft de cliënt niet te betrekken om deel te nemen aan een onveilige sessie. Aanvallers starten eenvoudigweg zelf een onveilige SSLv2-sessie met de server, vallen het zwakke protocol aan en herstellen de RSA-privésleutel van de server. Deze sleutel is ook geldig voor TLS-verbindingen, en vanaf dit moment kan geen enkele TLS-beveiliging voorkomen dat deze wordt aangetast.

Maar om het te kraken heb je een werkende aanval tegen SSLv2 nodig, waarmee je niet alleen specifiek verkeer kunt herstellen, maar ook de geheime RSA-serversleutel. Hoewel dit een complexe opzet is, konden de onderzoekers elke kwetsbaarheid kiezen die na SSLv2 volledig gesloten was. Uiteindelijk vonden ze een geschikte optie: de Bleichenbacher-aanval, die we eerder noemden en die we in het volgende artikel in detail zullen toelichten. SSL en TLS zijn beschermd tegen deze aanval, maar enkele willekeurige functies van SSL, gecombineerd met korte sleutels in cryptografie op exportniveau, maakten het mogelijk een specifieke implementatie van DROWN.

Op het moment van publicatie werd 25% van de topsites op internet getroffen door de DROWN-kwetsbaarheid, en de aanval kon worden uitgevoerd met bescheiden middelen die zelfs door ondeugende, eenzame hackers beschikbaar waren. Het ophalen van de RSA-sleutel van de server vergde acht uur rekenwerk en $440, en SSLv2 ging van verouderd naar radioactief.

Wacht, hoe zit het met Heartbleed?

Dit is geen cryptografische aanval in de hierboven beschreven zin; Dit is een bufferoverflow.

Laten we een pauze nemen

We zijn begonnen met enkele basistechnieken: brute force, interpolatie, downgraden, cross-protocol en precomputation. Vervolgens keken we naar één geavanceerde techniek, misschien wel het belangrijkste onderdeel van moderne cryptografische aanvallen: de orakelaanval. We hebben er behoorlijk wat tijd aan besteed om dit uit te zoeken - en begrepen niet alleen het onderliggende principe, maar ook de technische details van twee specifieke implementaties: de Vaudenay-aanval op de CBC-coderingsmodus en de Kelsey-aanval op pre-compressie-coderingsprotocollen.

Bij het beoordelen van downgrade- en precomputation-aanvallen hebben we kort de FREAK-aanval geschetst, die beide methoden gebruikt door doelsites te laten downgraden naar zwakke sleutels en vervolgens dezelfde sleutels opnieuw te gebruiken. Voor het volgende artikel zullen we de (zeer vergelijkbare) Logjam-aanval bewaren, die zich richt op algoritmen met openbare sleutels.

Vervolgens hebben we nog drie voorbeelden bekeken van de toepassing van deze principes. Ten eerste, CRIME en POODLE: twee aanvallen die afhankelijk waren van het vermogen van de aanvaller om willekeurige leesbare tekst naast de doeltekst te injecteren, en vervolgens de reacties van de server te onderzoeken en danGebruik de orakel-aanvalsmethodologie om deze schaarse informatie te exploiteren om de leesbare tekst gedeeltelijk te herstellen. CRIME volgde de route van Kelsey's aanval op SSL-compressie, terwijl POODLE in plaats daarvan een variant van Vaudenay's aanval op CBC gebruikte met hetzelfde effect.

Vervolgens hebben we onze aandacht gericht op de cross-protocol DROWN-aanval, die een verbinding met de server tot stand brengt met behulp van het oudere SSLv2-protocol en vervolgens de geheime sleutels van de server herstelt met behulp van de Bleichenbacher-aanval. We hebben de technische details van deze aanval voorlopig overgeslagen; Net als Logjam zal het moeten wachten totdat we een goed begrip hebben van cryptosystemen met publieke sleutels en hun kwetsbaarheden.

In het volgende artikel zullen we het hebben over geavanceerde aanvallen zoals meet-in-the-middle, differentiële cryptanalyse en verjaardagsaanvallen. Laten we een korte blik werpen op zijkanaalaanvallen en dan verdergaan met het leuke gedeelte: cryptosystemen met publieke sleutels.

Bron: www.habr.com