Bij het woord 'cryptografie' denken sommigen aan hun WiFi-wachtwoord, het groene slotje naast het adres van hun favoriete website en hoe moeilijk het is om in iemands e-mail te komen. Anderen herinneren zich een reeks kwetsbaarheden van de afgelopen jaren met sprekende afkortingen (DROWN, FREAK, POODLE…), stijlvolle logo's en de waarschuwing om hun browser dringend bij te werken.

Cryptografie omvat dit allemaal, maar de essentie ligt elders. De essentie zit in de delicate grens tussen eenvoudig en complex. Sommige dingen zijn eenvoudig te doen, maar moeilijk weer ongedaan te maken: bijvoorbeeld, een ei breken. Andere dingen zijn gemakkelijk te doen, maar moeilijk weer terug te draaien als er een klein, cruciaal onderdeel ontbreekt: bijvoorbeeld, een gesloten deur openen wanneer het 'cruciale onderdeel' de sleutel is. Cryptografie onderzoekt deze situaties en manieren om ze praktisch toe te passen.

In de afgelopen jaren is de verzameling cryptografische aanvallen veranderd in een dierentuin van schreeuwende logo's, vol formules van wetenschappelijke artikelen, en heeft het een algemene sombere indruk gecreëerd dat alles kapot is. Maar in werkelijkheid zijn veel van de aanvallen gebaseerd op een paar gemeenschappelijke principes, en de eindeloze bladzijden met formules kunnen vaak worden teruggebracht tot eenvoudige, begrijpelijke ideeën.

In deze serie artikelen zullen we verschillende typen cryptografische aanvallen bespreken, met de nadruk op de belangrijkste principes. In grote lijnen en niet helemaal in deze volgorde, maar we zullen het volgende behandelen:

Basisstrategieën: brute force, frequentieanalyse, interpolatie, verlaagde en cross-protocollen.
"Brand" kwetsbaarheden: FREAK, CRIME, POODLE, DROWN, Logjam.
Geavanceerde strategieën: oracle-aanvallen (Wiener-aanval, Kelsey-aanval); meet-in-the-middle methode, verjaardag aanval, statistische bias (differentiële cryptanalyse, integrale cryptanalyse, enz.).
Aanvallen via zijopeningen en hun nauwe verwanten, falenanalyse-methoden.
Aanvallen op asymmetrische cryptografie: kubieke wortel, broadcast, gekoppeld bericht, Copperfield-aanval, Pollard-Hellman-algoritme, getalzeef, Wiener-aanval, Blahut-anval.

Dit specifieke artikel omvat het bovenstaande materiaal tot en met de Kelsey-aanval.

Basisstrategieën

De volgende aanvallen zijn eenvoudig in die zin dat ze vrijwel volledig kunnen worden uitgelegd zonder veel technische details. We zullen elk type aanval uitleggen in de eenvoudigste termen, zonder in complexe voorbeelden of uitgebreide gebruikssituaties te duiken.

Sommige van deze aanvallen zijn eigenlijk verouderd en al jaren niet meer toegepast. Andere zijn oude bekenden, die nog steeds regelmatig opduiken bij nietsvermoedende ontwikkelaars van cryptosystemen in de 21ste eeuw. We kunnen stellen dat het tijdperk van moderne cryptografie begon met de komst van IBM DES – de eerste cipher die alle aanvallen in deze lijst overleefde.

Eenvoudige brute force

Een encryptieschema bestaat uit twee delen: 1) een encryptiefunctie die een bericht (plaint tekst) samen met een sleutel neemt en vervolgens een versleuteld bericht – ciphertext – genereert; 2) een decryptiefunctie die ciphertext en sleutel aanneemt en plaintext genereert. Zowel de encryptie als de decryptie moeten gemakkelijk berekenbaar zijn met de sleutel – en moeilijk zonder.

Laten we aannemen dat we ciphertext zien en proberen het te ontsleutelen zonder enige aanvullende informatie (dit wordt een 'ciphertext-only' aanval genoemd). Als we op de een of andere magische manier de juiste sleutel vinden, kunnen we eenvoudig controleren of deze inderdaad correct is als het resultaat een redelijk bericht oplevert.

Merk op dat hier twee impliciete aannames zijn. Ten eerste dat we weten hoe we de decryptie moeten uitvoeren, dat wil zeggen, hoe het cryptosysteem werkt. Dit is een standaardveronderstelling bij het bespreken van cryptografie. Het verbergen van implementatiedetails van de cipher voor aanvallers kan een extra beveiligingsmaatregel lijken, maar zodra de aanvaller deze details ontdekt, is deze aanvullende beveiliging onmerkbaar en onomkeerbaar verloren. Dat is het Kerckhoffs-principe: de komst van het systeem in handen van de vijand mag geen ongemakken veroorzaken.

Ten tweede nemen we aan dat de juiste sleutel de enige sleutel is die tot een redelijke decryptie leidt. Dit is ook een redelijke veronderstelling; het geldt als de ciphertext veel langer is dan de sleutel en goed leesbaar is. Over het algemeen is dit het geval in de echte wereld, met uitzondering van gigantische onpraktische sleutels of andere trucs die beter achterwege kunnen blijven (als u het niet prettig vindt dat we de uitleg afgehandeld hebben, raadpleeg dan stelling 3.8) hier).

Gegeven het bovenstaande, ontstaat er een strategie: controleer elke mogelijke sleutel. Dit wordt brute-forcing genoemd, en zo'n aanval werkt gegarandeerd tegen alle praktische encrypties - uiteindelijk. Bijvoorbeeld, brute-forcing is voldoende om de Caesar-codering, een oude codering waarbij de sleutel een letter van het alfabet is, wat iets meer dan 20 mogelijke sleutels impliceert.

Helaas voor cryptanalisten, beschermt het vergroten van de sleutelgrootte goed tegen brute-forcing. Naarmate de sleutelgrootte toeneemt, groeit het aantal mogelijke sleutels exponentieel. Met de moderne sleutelgroottes is eenvoudige brute-forcing totaal onpraktisch. Om te begrijpen wat we bedoelen, laten we de snelste bekende supercomputer halverwege 2019 bekijken: Summit van IBM, met een piekprestaties van ongeveer 10^17 bewerkingen per seconde. Tegenwoordig is de typische sleutelgrootte 128 bits, wat betekent dat er 2^128 mogelijke combinaties zijn. Om alle sleutels te doorlopen, heeft supercomputer Summit een tijd nodig die ongeveer 7800 keer de leeftijd van het universum bedraagt.

Moet brute-forcing worden beschouwd als een historische curiositeit? Zeker niet: het is een noodzakelijk ingrediënt in het kookboek van cryptanalyse. Het komt zelden voor dat er zulke zwakke encrypties zijn dat ze alleen door een slimme aanval kunnen worden gekraakt, zonder enige mate van kracht. Veel succesvolle hacks gebruiken eerst een algoritmische methode om de doelcodering te verzwakken en voeren dan de brute-force aanval uit.

Frequentieanalyse

De meeste teksten zijn geen abracadabra. Bijvoorbeeld, in Engelstalige teksten komen veel ‘e’ letters en lidwoorden ‘the’ voor; in binaire bestanden veel nullen als opvulling tussen informatiefragmenten. Frequentieanalyse is een aanval die dit feit benut.

Een klassiek voorbeeld van een codering die kwetsbaar is voor deze aanval is de eenvoudige substitutiecodering. In deze codering is de sleutel een tabel met vervangingen van alle letters. Bijvoorbeeld, ‘g’ wordt vervangen door ‘h’, ‘o’ door ‘j’. Daarom wordt het woord ‘go’ ‘hj’. Deze codering is moeilijk te onderwerpen aan eenvoudige brute-forcing, omdat er veel mogelijke substitutietabellen zijn. Als je geïnteresseerd bent in de wiskunde, bedraagt de effectieve sleutelgrootte ongeveer 88 bits: dit is
. Maar frequentieanalyse lost deze taak doorgaans snel op.

Laten we de volgende ciphertext bekijken, verwerkt door een eenvoudige substitutiecipher:

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

Aangezien Y komt vaak voor, vooral aan het eind van veel woorden, we kunnen voorlopig veronderstellen dat dit de letter e:

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

Een paar XD komt veel voor aan het begin van verschillende woorden. In het bijzonder suggereert de combinatie XDeLe duidelijk het woord these of there, dus gaan we verder:

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

Verder veronderstellen we dat L overeenkomt met , die de eerste regel van het verzoek, de headers en de gegevens scheidt., A — a enzovoort. Het is waarschijnlijk dat er meerdere pogingen nodig zijn, maar vergeleken met een volledige brute-force is deze aanval in staat om de oorspronkelijke tekst in recordtijd te herstellen:

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

Voor sommigen is het oplossen van dergelijke 'cryptogrammen' een boeiend hobby.

Het idee van frequentieanalyse is fundamenteler dan het op het eerste gezicht lijkt. Het is ook toepasbaar op veel complexere ciphers. Door de geschiedenis heen hebben verschillende cryptografische constructies geprobeerd deze aanval te weerstaan met behulp van 'polyalfabetische substitutie'. Hierin wordt de vervangingsmatrix voor letters op complexe, maar voorspelbare manieren gewijzigd, afhankelijk van de sleutel. Al deze ciphers werden ooit als moeilijk te kraken beschouwd; en toch overwon de bescheiden frequentieanalyse uiteindelijk allemaal.

De meest ambitieuze polyalfabetische cipher in de geschiedenis en waarschijnlijk de bekendste, was de 'Enigma'-cipher tijdens de Tweede Wereldoorlog. Deze was relatief complex in vergelijking met zijn voorgangers, maar na langdurig en hard werken wisten de Britse cryptanalisten deze te kraken met behulp van frequentieanalyse. Natuurlijk konden ze geen elegante aanval ontwikkelen zoals hierboven getoond; ze moesten bekende paren van open en versleutelde teksten vergelijken (de zogenaamde 'aanval op basis van open teksten') en zelfs gebruikers van de 'Enigma' aanmoedigen om bepaalde berichten te versleutelen en de resultaten te analyseren ('aanval op basis van aangepast open tekst'). Maar dit verlichtte het lot van de verslagen legers van de vijand en gezonken onderzeeërs niet.

Na deze triomf verdween frequentieanalyse uit de geschiedenis van de cryptografie. De cijfers van het moderne digitale tijdperk zijn ontworpen om met bits te werken, en niet met letters. Wat nog belangrijker is, deze cijfers zijn ontwikkeld met een duister begrip van wat later bekend zou worden als de wet van Schneier: iedereen kan een versleutelingsalgoritme maken dat hijzelf niet kan kraken. Het is niet genoeg dat het versleutelingssysteem complex lijkt : om zijn waarde te bewijzen, moet het een meedogenloze veiligheidsbeoordeling ondergaan door veel cryptanalisten die alles op alles zetten om de code te kraken.

Voorafgaande berekeningen

Laten we de hypothetische stad Prekom Heights nemen met een bevolking van 200.000 mensen. In elk huis in de stad bevinden zich waardevolle spullen ter waarde van gemiddeld $30.000, maar niet meer dan $50.000. De beveiligingsmarkt in Prekom is gemonopoliseerd door ACME Industries, dat legendarische Coyote ™ deurop sloten produceert. Volgens deskundige analyses kan een Coyote-sloten alleen worden gebroken door een zeer complexe hypothetische machine, waarvan de ontwikkeling ongeveer vijf jaar en $50.000 aan investeringen kost. Is de stad veilig?

Waarschijnlijk niet. Uiteindelijk zal er een ambitieus misdadiger opduiken. Hij zal denken: 'Ja, ik moet flinke opstapelkosten maken. Vijf jaar geduld hebben en $50.000. Maar aan het einde van de klus heb ik toegang tot de hele rijkdom van deze stad. Als ik mijn kaarten goed speel, zal deze investering zich meer dan terugbetalen.'

Hetzelfde geldt voor cryptografie. Aanvallen tegen een specifieke code worden onderworpen aan een meedogenlijke kosten-batenanalyse. Als de verhouding gunstig is, vindt er geen aanval plaats. Maar aanvallen die gericht zijn op veel potentiële slachtoffers, betalen zich bijna altijd terug, en in dat geval is de beste ontwerppraktijk om te veronderstellen dat ze vanaf de eerste dag zijn begonnen. We hebben in wezen de cryptografische versie van de wet van Murphy: 'Alles wat een systeem daadwerkelijk kan breken, zal het systeem breken.'

Een eenvoudig voorbeeld van een cryptosysteem dat kwetsbaar is voor aanvallen met voorafgaande berekeningen, is een code met een vast algoritme zonder gebruik van een sleutel. Dit was het geval met de Caesar code, die elke letter van het alfabet met drie letters naar voren verschuift (de tabel is cirkelvormig, dus de laatste letter in het alfabet wordt versleuteld door de derde). Hier verschijnt opnieuw het principe van Kerckhoffs: zodra het systeem is gehackt, is het voor altijd gekraakt.

Het concept is eenvoudig. Zelfs een beginnende ontwikkelaar van cryptosystemen zal waarschijnlijk de dreiging begrijpen en zich dienovereenkomstig voorbereiden. Als we kijken naar de evolutie van cryptografie, waren dergelijke aanvallen ongepast voor de meeste coderingen, beginnend met de eerste verbeterde versies van de Caesar-codering tot de neergang van polyalfabetische coderingen. Dergelijke aanvallen kwamen pas terug met de moderne era van cryptografie.

Deze terugkeer is te wijten aan twee factoren. Ten eerste zijn er eindelijk complexe genoeg cryptosystemen ontstaan, waarbij de mogelijkheid van exploitatie na een inbraak niet voor de hand lag. Ten tweede heeft cryptografie zo’n brede verspreiding gekregen dat miljoenen leken dagelijks beslissingen namen over waar en welke delen van cryptografie hergebruikt moesten worden. Het duurde een tijdje voordat experts de opgekomen risico’s realizeerden en alarm sloegen.

Onthoud de aanvallen met precomputatie: aan het einde van het artikel zullen we twee cryptografische voorbeelden uit het echte leven bekijken, waar deze een belangrijke rol speelde.

Interpolatie

Voor u staat de beroemde detective Sherlock Holmes, die een interpolatie-aanval uitvoert op de ongelukkige Dr. Watson:

Ik realiseerde me meteen dat u uit Afghanistan kwam... Mijn gedachtegang was als volgt: ‘Deze man is een arts, maar zijn houding is militair. Dus, een militaire arts. Hij is net aangekomen uit de tropen – zijn gezicht is bruin, maar dat is geen natuurlijke huidskleur, want zijn polsen zijn veel witters. Zijn gezicht is uitgeput, – hij heeft duidelijk veel doorstaan en ziekte meegemaakt. Hij is gewond aan zijn linkerarm – houdt deze stil en een beetje onnatuurlijk. Waar zou een Engelse militaire arts in de tropen hebben kunnen lijden en gewond raken? Natuurlijk in Afghanistan.’ Het hele gedachteproces duurde niet langer dan een seconde. En toen zei ik dat u uit Afghanistan kwam, waarop u verrast was.

Uit elke bijenkorf kon Holmes heel weinig informatie halen. Hij kon pas tot zijn conclusie komen nadat hij ze allemaal samen beschouwde. Zo werkt de interpolatie-aanval, waarbij bekende paren van open en versleutelde tekst worden onderzocht, verkregen door het toepassen van dezelfde sleutel. Uit elk paar worden afzonderlijke observaties gehaald die het mogelijk maken om een algemene conclusie over de sleutel te trekken. Al deze redeneringen zijn vaag en lijken nutteloos, totdat ze plotseling een kritische massa bereiken en leiden tot de enige mogelijke conclusie: hoe ongelooflijk het ook lijkt, het moet waar zijn. Daarna wordt ofwel de sleutel onthuld, of het decryptieproces wordt zo verfijnd dat het kan worden gerepliceerd.

Laten we aan de hand van een eenvoudig voorbeeld illustreren hoe interpolatie werkt. Stel dat we het persoonlijke dagboek van onze vijand, Bob, willen lezen. Hij versleutelt elk getal in zijn dagboek met een eenvoudig cryptosysteem dat hij uit een reclame in het tijdschrift 'Een grap over cryptografie' heeft geleerd. Het systeem werkt als volgt: Bob kiest twee getallen die hij leuk vindt: en . Voortaan, om een getal te versleutelen, , berekent hij . Bijvoorbeeld, als Bob voor en heeft gekozen, dan wordt het cijfer versleuteld als .

Stel dat we op 28 december opmerken dat Bob iets in zijn dagboek krabbelt. Wanneer hij klaar is, kunnen we het ongemerkt pakken en de laatste aantekening bekijken:

Datum: 235/520
Lieve dagboek,
Vandaag was een goede dag. Over 64 dagen heb ik een afspraak met Alice, die in het appartement woont 843. Ik denk echt dat ze 26!

Aangezien we heel serieus van plan zijn om Bob te volgen tijdens zijn afspraak (in dit scenario zijn we 15 jaar oud), is het van cruciaal belang om de datum en het adres van Alice te achterhalen. Gelukkig merken we op dat Bob's cryptosysteem kwetsbaar is voor een interpolatie-aanval. We weten misschien niet en , maar we kennen de datum van vandaag, dus hebben we twee paren 'open tekst - ciphertext'. Namelijk, we weten dat wordt versleuteld tot , met behulp van 1 bit, gelijk aan 0, — tot . Dit zullen we opschrijven:

Aangezien we 15 jaar oud zijn, weten we al van het systeem van twee vergelijkingen met twee onbekenden, wat in deze situatie genoeg is om het te vinden. en zonder enige problemen. Elk paar ‘heldere tekst-encryptietekst’ legt een beperking op de sleutel van Bob, en twee beperkingen samen zijn voldoende om de sleutel volledig te herstellen. In ons voorbeeld is het antwoord en (bij , zodat 26 in het dagboek overeenkomt met het woord ‘de enige’, dat wil zeggen ‘deze’ - opmerking vertaler).

Interpolatietaanvallen zijn natuurlijk niet beperkt tot dergelijke eenvoudige voorbeelden. Elke cryptosysteem dat kan worden teruggebracht tot een goed begrepen wiskundig object en een lijst met parameters, is kwetsbaar voor een interpolatietaanval - hoe beter het object te begrijpen is, hoe groter het risico.

Beginners klagen vaak dat cryptografie ‘de kunst is van het ontwerpen van zoveel mogelijk lelijke dingen’. Dit is waarschijnlijk grotendeels te wijten aan interpolatie-aanvallen. Bob kan ofwel een elegante wiskundige opzet gebruiken, of de geheimhouding van zijn ontmoeting met Alice behouden - maar helaas is het meestal niet mogelijk om beide te krijgen. Dit zal bijzonder duidelijk worden wanneer we uiteindelijk het onderwerp van cryptografie met openbare sleutels behandelen.

Cross-protocol/downgrade

In de film ‘Now You See Me’ (2013) probeert een groep illusionisten de volledige rijkdom van de corrupte verzekeringsmagnaat Arthur Tressler te stelen. Om toegang te krijgen tot Arthurs bankrekening, moeten de illusionisten ofwel zijn gebruikersnaam en wachtwoord verstrekken, of hem dwingen om persoonlijk naar de bank te komen en deel te nemen aan de oplichting.

Beide opties zijn erg moeilijk; de jongens zijn gewend om op het podium te staan en niet deel te nemen aan operaties van inlichtingendiensten. Daarom kiezen ze voor een derde mogelijke optie: hun kompaan belt de bank en doet zich voor als Arthur. De bank stelt enkele vragen ter verificatie, zoals de naam van de oom en de naam van het eerste huisdier; onze helden vergemakkelijken deze informatie gemakkelijk bij Arthur via handige sociale engineering.. Vanaf dat moment heeft uitstekende wachtwoordbeveiliging geen betekenis meer.

(Volgens de stadslegende, die we persoonlijk hebben gecontroleerd en bevestigd, kwam cryptograaf Eli Biham ooit een bankcassière tegen die erop stond een geheim vraag in te stellen. Toen de cassière vroeg naar de naam van zijn grootmoeder aan de moederszijde, begon Biham te dicteren: ‘Hoofdletter X, kleine y, drie…’).

Even in cryptography, if two cryptographic protocols are used simultaneously to protect the same asset, and one is significantly weaker than the other, the resulting system becomes vulnerable to a cross-protocol attack, where the weaker protocol is attacked to reach the prize without touching the stronger one.

In some complex cases, simply connecting to the server via the weaker protocol is not enough; it requires the involuntary participation of a legitimate client. This can be organized through what's known as a downgrade attack. To understand this attack, let’s assume our illusionists have a more complex task than in the movie. Suppose unexpected circumstances arose between the bank employee (the teller) and Arthur, resulting in the following dialogue:

Hacker: Hello? This is Arthur Tresler. I would like to recover my password.
Teller: Great. Please look in your personal secret codebook, page 28, word 3. All subsequent messages will be encrypted using this specific word as a key. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV...
Hacker: Hey, wait, wait. Is this really necessary? Can’t we just talk like normal people?
Teller: I wouldn’t recommend doing that.
Hacker: I just... listen, I had a terrible day, okay? I’m a VIP client and not in the mood to dig through these stupid code books.
Teller: Alright. If you insist, Mr. Tresler. What can I do for you?
Hacker: Please, I would like to transfer all my money to the National Fund for the Victims of Arthur Tresler.
(Pause).
Teller: Alright, understood. Please provide your PIN code for large transactions.
Hacker: My what?
Teller: By your personal request, transactions of this size require the entry of a PIN code for large transactions. This code was issued to you when you opened your account.
Hacker:... I lost it. Is this really necessary? Can’t you just approve the transaction?
Teller: No. I’m sorry, Mr. Tresler. Again, this is a security measure you requested. If you’d like, we can send a new PIN code to your mailbox.

Onze helden stellen de operatie uit. Ze luisteren naar verschillende grote transacties van Tressler, in de hoop de pincode te horen; maar elke keer vervalt het gesprek in een onbegrijpelijke code voordat er iets interessants klinkt. Uiteindelijk, op een mooie dag, voeren ze het plan uit. Ze wachten geduldig op het moment dat Tressler een grote telefonische transactie moet uitvoeren; hij sluit zich aan bij de lijn, en dan...

Tressler: Hallo. Ik zou graag een afstandstransactie willen maken, alstublieft.
Teller: Geweldig. Kijk alstublieft in uw persoonlijke boek van geheime codes, pagina...
(De hacker drukt op de knop; de stem van de kassier verandert in onsamenhangend geruis).
Teller: — #@$#@$#*@$$@#* zal worden gecodeerd met dit woord als sleutel. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Sorry, ik begrijp het niet helemaal. Nog een keer? Op welke pagina? Welk woord?
Teller: Dat is pagina @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Wat?
Teller: Woord nummer twintig @$#@$#%#$.
Tressler: Serieus! Stop daar al mee! Jij en je beveiligingsprotocol - het is een circus. Ik weet dat je gewoon normaal met me kunt praten.
Teller: Ik raad dat niet aan…
Tressler: En ik raad je aan niet mijn tijd te verspillen. Ik wil hier niet meer over horen totdat je de problemen met je telefonie hebt opgelost. Kunnen we deze deal maken of niet?
Teller:... ja. Goed. Wat wilt u?
Tressler: Ik wil graag $20.000 overmaken naar het bedrijf Lord Business Investments, rekeningnummer...
Teller: Een momentje, alstublieft. Dit is een grote transactie. Geef alstublieft uw pincode voor grote transacties op.
Tressler: Wat? Oh ja, natuurlijk. 1234.

Hier is de aanval 'verlaag'. Een zwakker protocol 'praat gewoon eerlijk' was bedoeld als optie noodoplossing. En toch zijn we hier.

Je kunt je afvragen wie in zijn recht mindert zo'n echt systeem zou ontwerpen van 'veilig totdat je vraagt om het omgekeerde', zoals hierboven beschreven. Maar net zoals een fictieve bank risico's neemt om klanten te behouden die niet van cryptografie houden, zo buigen systemen vaak naar eisen die onverschillig of zelfs openlijk vijandig staan tegenover veiligheid.

Zo'n verhaal gebeurde in 1995 met het SSLv2-protocol. De Amerikaanse overheid was al lang begonnen cryptografie als een wapen te beschouwen, dat beter uit de buurt van externe en interne vijanden kon worden gehouden. Fragmenten van de code werden afzonderlijk goedgekeurd voor export uit de VS, vaak onder de voorwaarde dat het algoritme opzettelijk werd verzwakt. Bedrijven zoals Netscape, de ontwikkelaar van de populairste browser Netscape Navigator, kregen alleen toestemming voor SSLv2 met een aanvankelijke kwetsbare RSA-sleutel van 512 bits (en 40 bits voor RC4).

Tegen het einde van het millennium werden de regels versoepeld en werd de toegang tot moderne encryptie algemeen beschikbaar. Toch hielden klanten en servers gedurende vele jaren vast aan verzwakte 'export'-cryptografie, door dezelfde inertie die elke verouderde systeem in stand houdt. Klanten dachten dat ze een server konden tegenkomen die niets anders ondersteunde. Servers deden hetzelfde. Natuurlijk dicteert het SSL-protocol dat klanten en servers nooit een zwak protocol moeten gebruiken wanneer er een betere beschikbaar is. Maar dezelfde veronderstelling gold voor Tresstler en zijn bank.

Deze theorie vond toepassing in twee spraakmakende aanvallen die het SSL-protocol in 2015 achtereenvolgens schokten, beide ontdekt door onderzoekers van Microsoft en INRIA. Eerst werden in februari de details van de FREAK-aanval onthuld en drie maanden later nog een soortgelijke aanval genaamd Logjam, die we zullen bespreken zodra we het hebben over aanvallen op publieke cryptografie.

Kwetsbaarheid FREAK (ook bekend als 'Smack TLS') kwam aan het licht toen onderzoekers de implementaties van client/server TLS analyseerden en een interessante fout ontdekten. In deze implementaties, als de client zelfs niet vraagt om zwakke exportcryptografie te gebruiken, maar de server nog steeds met zulke sleutels reageert - zegt de client 'Nou, prima' en schakelt over naar een zwakke cipher suite.

In die tijd beschouwde iedereen exportcryptografie als verouderd en verboden voor gebruik, waardoor de aanval een echte schok was en veel belangrijke domeinen raakte, inclusief de websites van het Witte Huis, de belastingdienst van de VS en de NSA. Nog erger, het bleek dat veel kwetsbare servers de prestaties optimaliseerden door dezelfde sleutels herhaaldelijk te gebruiken in plaats van nieuwe te genereren voor elke sessie. Dit stelde de aanvallers in staat, na het verlagen van het protocol, zelfs een aanval met voorcalculatie 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 een aanval op een verbinding daalden aanzienlijk. Het was voldoende om één keer de serversleutel te raden - en de versleuteling voor alle daaropvolgende verbindingen vanaf dat moment te kraken.

En voordat we verder gaan, moeten we een geavanceerde aanval noemen...

De orakelaanval

Moxie Marlinspike is het meest bekend als de vader van de cross-platform cryptomessenger Signal; maar persoonlijk houden we van een van zijn minder bekende innovaties - het principe van cryptografische doom (Cryptographic Doom Principle). Iets anders verwoord, kun je het als volgt zeggen: 'Als een protocol een cryptografische bewerking uitvoert op een bericht uit een potentieel schadelijke bron en zich anders gedraagt afhankelijk van het resultaat, is het gedoemd.' Of in scherpere bewoordingen: 'Neem geen informatie van de vijand om te verwerken, en als je dat doet, laat dan in ieder geval het resultaat niet zien.'

Laten we bufferoverlopen, commandoinjecties en dergelijke achterwege laten; deze vallen buiten het bereik van deze discussie. Het schenden van het 'doom-principe' leidt tot ernstige cryptografische inbreuken omdat het protocol precies zo gedraagt zoals het zou moeten.

Als voorbeeld nemen we een fictieve constructie met een kwetsbare substitutieversleuteling, en demonstreren vervolgens een mogelijke aanval. Hoewel we al een aanval op de substitutieversleuteling hebben gezien met behulp van frequentieanalyse, is dit niet zomaar 'een andere manier om dezelfde versleuteling te kraken'. Integendeel, orakelaanvallen zijn een veel moderner uitvinding, toepasbaar in vele situaties waarin frequentieanalyse mislukt, en we zullen dit demonstreren in het volgende hoofdstuk. Hier is de eenvoudige versleuteling alleen gekozen om het voorbeeld begrijpelijker te maken.

Dus, Alice en Bob communiceren met behulp van een eenvoudige substitutiecode, waarbij ze een sleutel gebruiken die alleen zij kennen. Ze zijn erg streng over de lengte van de berichten: de lengte is precies 20 tekens. Daarom hebben ze afgesproken dat als iemand een korter bericht wil verzenden, deze een soort neptekst aan het einde van het bericht moet toevoegen, zodat het precies 20 tekens is. Na enige discussie hebben ze besloten dat ze alleen de volgende nepteksten zullen accepteren: a, bb, ccc, dddd enzovoort. Op die manier is de neptekst van elke gewenste lengte bekend.

Wanneer Alice of Bob een bericht ontvangt, controleren ze eerst of het bericht de juiste lengte heeft (20 tekens) en of de suffix de juiste neptekst is. Als dat niet het geval is, geven ze een overeenkomstig foutbericht terug. Als de lengte van de tekst en de neptekst in orde zijn, leest de ontvanger het eigenlijke bericht en stuurt een versleuteld antwoord.

Tijdens de aanval doet de aanvaller zich voor als Bob en stuurt nepberichten naar Alice. De berichten zijn complete nonsens — de aanvaller heeft de sleutel niet en kan daarom geen betekenisvol bericht vervalsen. Maar omdat het protocol het principe van onzekerheid schendt, kan de aanvaller Alice toch in een val lokken zodat zij informatie over de sleutel onthult, zoals hieronder getoond.

Hacker: PREWF ZHJKL MMMN. LA
Alice: Ongeldige neptekst.
Hacker: PREWF ZHJKL MMMN. LB
Alice: Ongeldige neptekst.
Hacker: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

De aanvaller heeft geen idee wat Alice net zei, maar merkt op dat het teken C moet overeenkomen met a, omdat Alice de neptekst heeft geaccepteerd.

Hacker: REWF ZHJKL MMMN. LAA
Alice: Ongeldige neptekst.
Hacker: REWF ZHJKL MMMN. LBB
Alice: Ongeldige neptekst.
Na verschillende pogingen…
Hacker: REWF ZHJKL MMMN. LGG
Alice: Ongeldige neptekst.
Hacker: 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 net zei, maar merkt op dat H moet overeenkomen met b, omdat Alice de neptekst heeft geaccepteerd.

En zo gaat het door, totdat de aanvaller de betekenis van elk teken ontdekt.

Op het eerste gezicht lijkt de methode op een aanval op basis van gekozen platte tekst. Uiteindelijk past de aanvaller versleutelde teksten toe, en de server verwerkt deze gehoorzaam. Het belangrijkste verschil dat deze aanvallen levensvatbaar maakt in de echte wereld, is dat de aanvaller geen toegang hoeft te hebben tot de daadwerkelijke decryptie — een antwoord van de server, zelfs zo onschuldig als "Onjuiste dummy-tekst", is voldoende.

Hoewel deze specifieke aanval leerzaam is, moet men niet te veel focussen op de details van het "dummy-tekst" schema, de specifieke gebruikte cryptosysteem of de exacte volgorde van berichten die door de aanvaller zijn verzonden. Het belangrijkste idee is hoe Alice verschillend reageert op basis van de eigenschappen van de platte tekst, en dit doet ze zonder te controleren of de overeenkomstige versleutelde tekst daadwerkelijk van een vertrouwde partij afkomstig is. Op deze manier stelt Alice de aanvaller in staat om geheime informatie uit haar antwoorden te persen.

In dit scenario kan er veel veranderen. De symbolen waarop Alice reageert, of het verschil in haar gedrag, of zelfs het gebruikte cryptosysteem. Maar het principe blijft hetzelfde, en de aanval zal in zijn geheel levensvatbaar blijven, in welke vorm dan ook. De basisimplementatie van deze aanval heeft geholpen om verschillende beveiligingsfouten te ontdekken, die we binnenkort zullen bespreken; maar eerst moeten we enkele theoretische lessen verteren. Hoe kan dit denkbeeldige "Alice-scenario" worden gebruikt in een aanval die in staat is effectief te zijn op een moderne cryptografie? Is dat zelfs theoretisch mogelijk?

In 1998 bevestigde de Zwitserse cryptograaf Daniel Bleichenbacher deze vraag positief. Hij demonstreerde een oracle-aanval op het veelgebruikte RSA-systeem met open sleutels, met behulp van een bepaald berichtenschema. In sommige implementaties van RSA reageert de server met verschillende foutberichten, afhankelijk van of de platte tekst aan het schema voldoet of niet; dit was voldoende om de aanval uit te voeren.

Vier jaar later, in 2002, demonstreerde de Franse cryptograaf Serge Vaudenay een oracle-aanval die bijna identiek was aan het scenario van Alice — behalve dat hij in plaats van een fictieve cipher een heel respectabel klasse van moderne ciphers heeft gekraakt die mensen daadwerkelijk gebruiken. In het bijzonder richtte de aanval van Vaudenay zich op ciphers met een vaste invoergrootte (‘block ciphers’) wanneer ze worden gebruikt in de zogenaamde ‘CBC-versleuteling modus’ en met een bepaalde populaire vulschema, voornamelijk gelijkwaardig aan dat in het scenario van Alice.

In 2002 stelde ook de Amerikaanse cryptograaf John Kelsey - mede-auteur Twofish — verschillende oracle-aanvallen voor op systemen die berichten comprimeren en vervolgens versleutelen. De meest opmerkelijke onder hen was een aanval die gebruik maakte van het feit dat de oorspronkelijke lengte van de platte tekst vaak kan worden afgeleid uit de lengte van de versleutelde tekst. In theorie maakt dit een oracle-aanval mogelijk die delen van de oorspronkelijke platte tekst herstelt.

Hieronder geven we een meer gedetailleerde beschrijving van de aanvallen van Vaudenay en Kelsey (we zullen een gedetailleerdere beschrijving van de aanval van Bleichenbacher geven wanneer we over aanvallen op publieke sleutelcryptografie praten). Ondanks al onze inspanningen wordt de tekst enigszins technisch; dus als het bovenstaande voor jou voldoende is, sla dan de volgende twee secties over.

Aanval van Vaudenay

Om de aanval van Vaudenay te begrijpen, moeten we eerst iets dieper ingaan op block ciphers en versleuteling modi. Een ‘block cipher’ is, zoals eerder vermeld, een cipher die een sleutel en invoer van een bepaalde vaste lengte (‘block length’) accepteert en een versleuteld blok van dezelfde lengte produceert. Block ciphers worden veel gebruikt en worden als relatief veilig beschouwd. De inmiddels gepensioneerde DES, die als de eerste moderne cipher wordt beschouwd, was een block cipher. Zoals eerder vermeld, geldt hetzelfde voor AES, dat vandaag de dag veel wordt gebruikt.

Helaas hebben blockciphers een duidelijke zwakte. De typische blokgrootte is 128 bit, of 16 tekens. Het is duidelijk dat moderne cryptografie moet werken met invoergegevens van grotere omvang, en hier komen de versleutelmodi in het spel. Een versleutelmodus is in wezen een hack: het is een manier om een blockcipher, dat alleen input van een bepaalde grootte accepteert, toe te passen op invoergegevens van willekeurige lengte.

De Waternaar-aanval richt zich op de populaire CBC-modus (Cipher Block Chaining, ketenmodus van blokken ciphertext). De aanval beschouwt de onderliggende blockcipher als een magische ontoegankelijke zwarte doos en omzeilt volledig zijn beveiliging.

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

Het omcirkelde plusteken betekent de XOR-operatie (exclusieve 'OF'). Bijvoorbeeld, het tweede blok ciphertext wordt verkregen door:

De XOR-operatie uit te voeren op het tweede blok van de plaintext met het eerste blok van de ciphertext.
Het verkregen blok te versleutelen met behulp van de blockcipher, met de sleutel.

Aangezien CBC zo intensief gebruikmaakt van de binaire XOR-operatie, laten we de gelegenheid aangrijpen om enkele van zijn eigenschappen op te frissen:

Idempotentie:
Commutativiteit:
Associativiteit:
Inversie:
Per byte: byte n van = (byte n van ) (byte n van )

In het algemeen impliceren deze eigenschappen dat als we een vergelijking hebben die XOR-operaties en één onbekende bevat, we deze kunnen oplossen. Bijvoorbeeld, als we weten dat met een onbekende en bekende en , dan kunnen we vertrouwen op de bovengenoemde eigenschappen om de vergelijking op te lossen voor . Door XOR van beide zijden van de vergelijking met toe te passen, krijgen we . Over een moment zal dit allemaal heel relevant worden.

Er zijn twee onbeduidende verschillen en één belangrijke afwijking tussen ons Alice-scenario en de Waternaar-aanval. Twee onbeduidende verschillen:

In het scenario verwachtte Alice dat de plaintexts eindigen met de tekens a, bb, ccc enzovoort. In de Waternaar-aanval verwacht het slachtoffer echter dat de plaintexts eindigen met N keer byte N (dat wil zeggen hexadecimaal 01 of 02 02, of 03 03 03, enzovoort). Dit is een puur cosmetisch verschil.
In het scenario van Alice was het eenvoudig te zeggen of Alice het bericht heeft aangenomen, aan de hand van het antwoord "Onjuiste dummytekst". In de Waterne-aanval is meer analyse vereist en is een nauwkeurige uitvoering aan de kant van het slachtoffer belangrijk; maar voor de beknoptheid nemen we aan dat deze analyse nog steeds mogelijk is.

Het belangrijkste verschil:

Aangezien we niet dezelfde cryptosysteem gebruiken, zal de verbinding tussen de door de aanvaller gecontroleerde bytes van de gecodeerde tekst en de geheimen (sleutel en platte tekst) duidelijk anders zijn. Daarom zal de aanvaller een andere strategie moeten gebruiken bij het creëren van gecodeerde teksten en het interpreteren van de serverreacties.

Dit belangrijkste verschil is het laatste deel van de puzzel om de Waterne-aanval te begrijpen, dus laten we even nadenken over de reden en de manier waarop je überhaupt een orakelaanval op CBC kunt organiseren.

Stel dat we een CBC-gecodeerde tekst hebben van 247 blokken, en we willen deze ontcijferen. We kunnen vervalste berichten naar de server sturen, zoals we eerder vervalste berichten naar Alice konden sturen. De server zal de berichten voor ons ontcijferen, maar zal de ontcijfering niet tonen — in plaats daarvan, net als in het geval van Alice, zal de server ons alleen één bit informatie geven: of de platte tekst een geldige padding heeft of niet.

Houd er rekening mee dat we in het scenario van Alice de volgende relaties hadden:

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

Laten we dit "Alice's vergelijking" noemen. We controleerden de gecodeerde tekst; de server (Alice) gaf vaag informatie over de ontvangen platte tekst; en dit stelde ons in staat om informatie over de laatste factor — de sleutel — af te leiden. Evenzo, als we zo'n relatie kunnen vinden voor het CBC-scenario, zouden we daar ook enige geheime informatie kunnen extraheren.

Gelukkig zijn er inderdaad relaties die we kunnen gebruiken. Laten we de uitvoer van de uiteindelijke aanroep van de ontcijfering van de blockcipher aanduiden als . Laten we ook de blokken van de platte tekst aanduiden als en de blokken van de gecodeerde tekst . Kijk nog eens naar de CBC-diagram en let op wat eruit komt:

Laten we dit "CBC's vergelijking" noemen.

In Alice's scenario, controlling the ciphertext and observing leaks of information about the corresponding plaintext, we were able to organize an attack that recovered the third element of the equation — the key. In the CBC scenario, we also control the ciphertext and observe leaks of information regarding the corresponding plaintext. If the analogy holds, we can obtain information about .

Let's assume we actually restored , what then? Well, then we can immediately output the entire last block of plaintext (), simply by entering (which we have) and
obtained in the CBC equation.

So, we feel optimistic about the overall attack plan, and it's time to work out the details. We note how information about the plaintext is leaking on the server. In Alice's scenario, the leak occurred because Alice only responded with the correct message if $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ ended with the string a (of bb, and so on, but the chances of these conditions occurring by chance were very slim). Similarly with CBC, the server accepts padding if and only if ends with hexadecimal 01. So, let's try the same trick: sending fake ciphertexts with our own fake values , until the server accepts the padding.

When the server accepts padding for one of our fake messages, it means that:

Now let's use the byte-wise property of XOR:

We know the first and third elements. And we have already seen that this allows us to recover the remaining element — the last byte from :

This also gives us the last byte of the final block of plaintext through the CBC equation and the byte-wise property.

We could stop here and be satisfied that we conducted an attack on a theoretically secure cipher. But in reality, we can do much more: we can actually recover the entire text. This requires a certain trick that was not in the original Alice scenario and is not part of the mandatory conditions of the oracle attack, but the method is still worth studying.

To understand it, first note that as a result of deriving the correct value of the last byte Wij hebben een nieuwe mogelijkheid gekregen. Nu kunnen we bij het vervalsen van ciphertexts de laatste byte van de bijbehorende plaintext beheren. Dit heeft weer te maken met de CBC-vergelijking en de bytegewijze eigenschap:

Aangezien we nu de tweede term kennen, kunnen we onze controle over de eerste gebruiken om de derde te beheren. We berekenen gewoon:

Vroeger konden we dit niet doen, omdat we nog niet beschikten over de laatste byte. .

Hoe zal dit ons helpen? Stel dat we nu alle ciphertexts creëren zodat de bijbehorende plaintexts eindigen op 02. Nu accepteert de server de padding alleen als de plaintext eindigt op 02 02. Omdat we de laatste byte hebben gecorrigeerd, zal dit alleen gebeuren als de op een na laatste byte van de plaintext ook gelijk is aan 02. We blijven vervalste ciphertextblokken sturen, waarbij we de op een na laatste byte wijzigen, totdat de server padding accepteert voor een van hen. Op dat moment krijgen we:

En we herstellen de op een na laatste byte op precies dezelfde manier als we de laatste hebben hersteld. We gaan door in hetzelfde tempo: we corrigeren de laatste twee bytes van de plaintext naar 03 03, herhalen deze aanval voor de derde van de laatste byte, en ga zo maar door, totdat we volledig herstellen. .

Wat betreft de rest van de tekst? Merk op dat de waarde in feite $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$ is. We kunnen elke andere block in plaats van , en de aanval zal nog steeds succesvol zijn. In feite kunnen we de server vragen om $inline$text{BLOCK_DECRYPT}$inline$ voor welke gegevens dan ook. Op dat moment is het spel voorbij - we kunnen elke ciphertext ontsleutelen (kijk nog eens naar het CBC-decryptiediagram om dit te bevestigen; en let op dat de IV-vector openbaar is).

Deze specifieke methode speelt een cruciale rol in de oracle-aanval, waarmee we later te maken zullen krijgen.

Kelsey-aanval

De voor ons geestverwante John Kelsey heeft de principes uiteengezet die ten grondslag liggen aan veel mogelijke aanvallen, en niet alleen de gedetailleerde specifics van een specifieke aanval op een specifieke cipher. Zijn artikel uit 2002 is een onderzoek naar mogelijke aanvallen op versleutelde, gecomprimeerde gegevens. Dacht je dat je voor een aanval niet meer informatie nodig had dan dat de gegevens waren gecomprimeerd vóór de versleuteling? Blijkbaar is dat voldoende.

Dit verbazingwekkende resultaat is te danken aan twee principes. Ten eerste is er een sterke correlatie tussen de lengte van de platte tekst en de lengte van de ciphertext; voor veel encrypties is er zelfs een exacte gelijkheid. Ten tweede, wanneer compressie plaatsvindt, is er ook een sterke correlatie tussen de lengte van het gecomprimeerde bericht en de mate van 'ruis' in de platte tekst, dat wil zeggen de verhouding van unieke symbolen (technische term - 'hogere entropie').

Om het principe in actie te zien, laten we kijken naar twee platte teksten:

Platte tekst 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Platte tekst 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Stel dat beide platte teksten zijn gecomprimeerd en vervolgens gecodeerd. Je krijgt twee resulterende ciphertexts en moet raden welke ciphertext bij welke platte tekst hoort:

Ciphertext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Ciphertext 2: DWKJZXYU

Het antwoord is duidelijk. Van de platte teksten zou alleen platte tekst 1 kunnen zijn gecomprimeerd tot de karige lengte van de tweede ciphertext. We hebben dit vastgesteld zonder kennis van het compressie-algoritme, de encryptiesleutel, of zelfs de encryptie zelf. In vergelijking met de hiërarchie van mogelijke cryptografische aanvallen is dit een soort waanzin.

Kelsey wijst er verder op dat onder bepaalde ongewone omstandigheden dit principe ook kan worden gebruikt voor het uitvoeren van een oracle-aanval. In het bijzonder beschrijft hij hoe een aanvaller de geheime platte tekst kan herstellen als hij de server kan dwingen om formuliergegevens (platte tekst gevolgd door , terwijl hij controle heeft over en op de een of andere manier de lengte van het versleutelde resultaat kan verifiëren.

Ook hier hebben we, net als bij andere oracle-aanvallen, een verhouding:

We hebben weer een lid onder controle (), zien een kleine informatielek over het andere lid (de ciphertext) en proberen de laatste (platte tekst) te herstellen. Ondanks de analogie is dit een enigszins ongebruikelijke situatie in vergelijking met andere oracle-aanvallen die we hebben gezien.

Om te illustreren hoe een dergelijke aanval kan werken, gebruiken we een fictief compressie-algoritme dat we net hebben bedacht: TOYZIP. Het zoekt naar tekstregels die eerder in de tekst zijn verschenen en vervangt ze door drie vulbytes die aangeven waar een eerdere exemplaar van de regel te vinden is en hoe vaak deze daar voorkomt. Bijvoorbeeld, de regel helloworldhello kan worden gecomprimeerd in helloworld[00][00][05] een lengte van 13 bytes in vergelijking met het originele 15 bytes.

Stel dat een aanvaller probeert de platte tekst van het formulier te herstellen password=..., waarbij het wachtwoord zelf onbekend is. Volgens het Kelsey-aanvalmodel kan de aanvaller de server vragen om de berichten van het formulier te comprimeren en vervolgens te versleutelen (platte tekst, gevolgd door ), waarbij — willekeurige tekst is. Wanneer de server klaar is, geeft deze de lengte van de output aan. De aanval verloopt als volgt:

Hacker: Gelieve de platte tekst zonder enige opvulling te comprimeren en te versleutelen.
Server: Lengte van de output 14.
Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=a.
Server: Lengte van de output 18.

De aanvaller merkt op: [origineel 14] + [drie bytes, die vervingen password=] + a

Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=b.
Server: Lengte van de output 18.
Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=с.
Server: Lengte van de output 17.

De aanvaller merkt op: [origineel 14] + [drie bytes, die vervingen password=c]. Dit suggereert dat de originele platte tekst de string bevat password=c. Dat wil zeggen, het wachtwoord begint met de letter c

Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=сa.
Server: Lengte van de output 18.

De aanvaller merkt op: [origineel 14] + [drie bytes, die vervingen password=с] + a

Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=сb.
Server: Lengte van de output 18.

(… enige tijd later…)

Hacker: Gelieve de platte tekst te comprimeren en te versleutelen, waaraan is toegevoegd password=со.
Server: Lengte van de output 17.

De aanvaller merkt op: [origineel 14] + [drie bytes, die vervingen password=co]. Volgens dezelfde logica komt de aanvaller tot de conclusie dat het wachtwoord begint met de letters co

Enzovoort totdat het volledige wachtwoord is hersteld.

De lezer zou het kunnen vergeven te denken dat dit een puur academische oefening is en dat een dergelijk aanvalsscenario zich nooit in de echte wereld zou voordoen. Helaas, zoals we binnenkort zullen zien, is het beter om in de cryptografie niet te veel te zeggen.

Merkspecifieke kwetsbaarheden: CRIME, POODLE, DROWN

Ten slotte, na een grondige studie van de theorie, kunnen we bekijken hoe deze technieken worden toegepast in echte cryptografische aanvallen.

CRIME

Als de aanval gericht is op de browser en het netwerk van het slachtoffer, zal het een aantal dingen gemakkelijker maken, en andere moeilijker. Bijvoorbeeld, het is eenvoudig om het verkeer van het slachtoffer te zien: het is voldoende om in hetzelfde café met WiFi bij hen te zitten. Om deze reden wordt potentiële slachtoffers (d.w.z. iedereen) meestal aangeraden om een versleutelde verbinding te gebruiken. Het zal moeilijker zijn, maar nog steeds mogelijk, om HTTP-verzoeken namens het slachtoffer naar een externe website (bijvoorbeeld Google) te sturen. De aanvaller moet het slachtoffer lokken naar een kwaadaardige webpagina met een script dat het verzoek zal doen. De webbrowser zal automatisch de bijbehorende sessiecookie verstrekken.

Het lijkt verbazingwekkend. Als Bob inlogt op evil.com, kan een script op deze website Google eenvoudig vragen om Bobs wachtwoord per e-mail te versturen naar attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), en dit was populair in het midden van de jaren '90. Tegenwoordig, als evil.com zo’n truc probeert, zal Google (of elke fatsoenlijke website) meestal antwoorden: "Prima, maar jouw CSRF-token voor deze transactie is... uhm... drie triljoen en zeven. Herhaal dit nummer alstublieft." Moderne browsers maken gebruik van iets dat "same-origin policy" wordt genoemd, wat betekent dat scripts op site A geen toegang krijgen tot informatie die door website B is verzonden. Daarom kan een script op evil.com verzoeken indienen naar google.com, maar kan geen antwoorden lezen of de transactie daadwerkelijk voltooien.

We moeten benadrukken dat als Bob geen versleutelde verbinding gebruikt, al deze bescherming nutteloos is. De aanvaller kan gewoon Bobs verkeer lezen en de Google-sessiecookie herstellen. Met deze cookie kan hij gewoon een nieuw tabblad in Google openen, zonder uit zijn eigen browser uit te loggen, en zich voordoen als Bob, zonder de vervelende beperkingen van de same-origin policy te ontmoeten. Maar helaas voor de aanvaller komt dat steeds minder vaak voor. Het internet heeft al lang de oorlog verklaard aan niet-versleutelde verbindingen, en Bobs uitgaande verkeer is waarschijnlijk versleuteld, of hij dat nu leuk vindt of niet. Bovendien werd bij de introductie van het protocol ook gecomprimeerd voor de versleuteling; dit was een gangbare praktijk om de latency te verminderen.

Hier komt CRIME (Compression Ratio Infoleak Made Easy, eenvoudige lekkage via compressieverhouding) in beeld. Een kwetsbaarheid die in september 2012 werd aangetoond door beveiligingsonderzoekers Giuliano Rizzo en Thai Duong. We hebben de hele theoretische basis besproken die nodig is om te begrijpen wat zij deden en hoe. De aanvaller kan de browser van Bob dwingen verzoeken naar Google te sturen en vervolgens de antwoorden in het lokale netwerk op te vangen in een gecomprimeerde, versleutelde vorm. Daarom hebben we:

Hier controleert de aanvaller het verzoek en heeft toegang tot de verkeerssniffer, inclusief de grootte van de pakketten. Het fictieve scenario van Kelsey is tot leven gekomen.

Door de theorie te begrijpen, hebben de auteurs van CRIME een exploit gecreëerd die sessiecookies kan stelen voor een breed scala aan websites, waaronder Gmail, Twitter, Dropbox en Github. De kwetsbaarheid heeft de meeste moderne webbrowsers getroffen, wat heeft geleid tot patches die de compressiefunctie in SSL stilzwijgend hebben begraven, zodat deze helemaal niet meer werd gebruikt. De enige die beschermd was tegen de kwetsbaarheid, was de eerbiedwaardige Internet Explorer, die SSL-compressie nooit heeft gebruikt.

POODLE

In oktober 2014 zorgde het beveiligingsteam van Google voor opschudding in de beveiligingsgemeenschap. Ze konden een kwetsbaarheid in het SSL-protocol uitbuiten, die meer dan tien jaar geleden was verholpen.

Het bleek dat hoewel op servers de geweldige nieuwe TLSv1.2 draait, velen de ondersteuning voor het verouderde SSLv3 in stand lieten voor backward compatibility met Internet Explorer 6. We hebben het al gehad over downgrade-aanvallen, dus je kunt je voorstellen wat er gebeurde. Een goed georganiseerde sabotage van het handshake-protocol - en de servers zijn klaar om terug te keren naar het oude vertrouwde SSLv3, waarbij in wezen de laatste 15 jaar aan veiligheidsresearch werd teruggedraaid.

Voor de historische context, hier is een kort overzicht van de geschiedenis van SSL tot versie 2 door Matthew Green:

Transport Layer Security (TLS) is het belangrijkste beveiligingsprotocol op het internet. [..] bijna elke transactie die je online uitvoert, is afhankelijk van TLS. [..] Maar TLS was niet altijd TLS. Het protocol begon zijn leven in Netscape Communications onder de naam "Secure Sockets Layer" of SSL. Er wordt gefluisterd dat de eerste versie van SSL zo vreselijk was dat de ontwikkelaars alle code-afdrukken verzamelden en deze op een geheim kerkhof in New Mexico begroeven. Als gevolg hiervan is de eerste openbare versie van SSL daadwerkelijk versie SSL 2. Het is vrij eng, en [..] het was een product uit het midden van de jaren '90, dat moderne cryptografen beschouwen als "de donkere eeuwen van de cryptografie". Veel van de meest afschuwelijke cryptografische aanvallen die we vandaag de dag kennen, waren toen nog niet ontdekt. Als gevolg hiervan moesten de ontwikkelaars van het SSLv2-protocol in wezen hun weg in het donker vinden, en ze kwamen veel verschrikkelijke monsters tegen — tot hun ontzetting en tot onze winst, aangezien aanvallen op SSLv2 onschatbare lessen hebben achtergelaten voor de volgende generatie protocollen. — tot hun spijt en tot ons voordeel, aangezien aanvallen op SSLv2 onschatbare lessen hebben achtergelaten voor de volgende generatie protocollen.

Na deze gebeurtenissen, in 1996, herwerkte het teleurgestelde bedrijf Netscape het SSL-protocol vanaf nul. Het resultaat was SSL versie 3, die verschillende bekende beveiligingsproblemen van zijn voorganger verholpen heeft..

Gelukkig voor hackers betekent 'verschillende' niet 'alle'. Over het algemeen bood SSLv3 alle noodzakelijke bouwstenen voor het uitvoeren van de Watern-aanval. Het protocol gebruikte een blokcipher in CBC-modus en een onveilige vulmethode (dit werd verholpen in TLS; daaruit volgde de noodzaak voor een downgrade-aanval). Als je je de vulmethode herinnert uit onze eerdere beschrijving van de Watern-aanval, lijkt de SSLv3-vulmethode erg op.

Maar helaas voor hackers betekent 'erg op' niet 'identiek'. De vulmethode van SSLv3 is 'N willekeurige bytes, gevolgd door het getal N'. Probeer onder dergelijke omstandigheden een denkbeeldig versleuteld tekstblok te kiezen en door alle fasen van de oorspronkelijke Watern-schema te gaan: je zult ontdekken dat de aanval met succes de laatste byte uit het overeenkomstige blok van de platte tekst extraheert, maar niet verder gaat. Het ontsleutelen van elke 16e byte van de versleutelde tekst is een geweldige truc, maar dat is geen overwinning.

Geconfronteerd met deze mislukking besloot het Google-team een drastische maatregel te nemen: ze schakelden over op een krachtiger bedreigingsmodel — dat gebruikt werd in CRIME. Stel je voor dat de aanvaller een script is dat draait op het tabblad van de browser van het slachtoffer, en dat het sessiecookies kan extraheren; toch blijft de aanval indrukwekkend. Hoewel het bredere bedreigingsmodel minder realistisch is, hebben we in het vorige gedeelte al gezien dat dit specifieke model haalbaar is.

Gezien de krachtigere mogelijkheden van de aanvaller, kan de aanval nu doorgaan. Houd er rekening mee dat de aanvaller weet waar de versleutelde sessiecookie in de header wordt weergegeven en de lengte van de voorafgaande HTTP-aanroep beheert. Daarom kan hij de HTTP-aanroep manipuleren zodat de laatste byte van de cookie overeenkomt met het einde van het blok. Deze byte is nu geschikt voor decryptie. Je kunt eenvoudig een karakter aan de aanroep toevoegen, en de op een na laatste byte van de cookie blijft op dezelfde plek en kan met dezelfde methode worden gebroken. De aanval gaat door totdat de cookie volledig is hersteld. Dit wordt POODLE genoemd: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Zoals we al noemden, had SSLv3 tekortkomingen, maar het was radicaal anders dan zijn voorganger, aangezien het lekke SSLv2 een product uit een andere tijd was. Daar kon het bericht halverwege worden beëindigd: ik ga daar alleen mee akkoord over mijn lijk veranderde in ik ga daar mee akkoord; de cliënt en de server konden elkaar op internet ontmoeten, vertrouwen opbouwen en geheimen uitwisselen voor de ogen van de aanvaller, die zich vervolgens gemakkelijk als de een of de ander kon voordoen. Ook was er het probleem met exportcryptografie, dat we al hebben genoemd bij de bespreking van FREAK. Dit waren cryptografische Sodom en Gomorra.

In maart 2016 kwam een team van onderzoekers uit verschillende technische gebieden samen en deed een verbazingwekkende ontdekking: SSLv2 wordt nog steeds gebruikt in beveiligingssystemen. Ja, aanvallers konden moderne TLS-sessies niet meer verlagen naar SSLv2, omdat deze kwetsbaarheid na FREAK en POODLE was verholpen, maar ze kunnen nog steeds verbinding maken met servers en zelf SSLv2-sessies initiëren.

Je vraagt je misschien af waarom we ons zorgen zouden maken over wat zij daar doen? Ze hebben een kwetsbare sessie, maar dat zou geen invloed moeten hebben op andere sessies of de serverbeveiliging - toch? Nou, niet precies. Ja, dat zou theoretisch zo moeten zijn. Maar nee - omdat het genereren van SSL-certificaten bepaalde lasten met zich meebrengt, waardoor veel servers dezelfde certificaten en bijgevolg dezelfde RSA-sleutels voor TLS- en SSLv2-verbindingen gebruiken. Wat nog erger is, is dat door een bug in OpenSSL in deze populaire implementatie de optie 'SSLv2 uitschakelen' feitelijk niet werkte.

Dit maakte een cross-protocol aanval op TLS mogelijk, die de naam kreeg DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, ofwel de decryptie van RSA met verouderde en verzwakte encryptie). Ter herinnering, dit is niet hetzelfde als een downgrade-aanval; de aanvaller hoeft zich niet als 'man-in-the-middle' op te stellen en hoeft de cliënt niet te betrekken bij een onveilige sessie. Aanvallers initiëren gewoon zelf een onveilige SSLv2-sessie met de server, vallen het zwakke protocol aan en herstellen de private server RSA-sleutel. Deze sleutel is ook geldig voor TLS-verbindingen, en vanaf dat moment zal geen enkele TLS-beveiliging hem beschermen tegen inbraak.

Maar voor de inbraak is er een werkende aanval tegen SSLv2 nodig, waarmee niet alleen specifieke traffic kan worden hersteld, maar ook de geheime server RSA-sleutel. Hoewel dit een gecompliceerde opzet is, konden onderzoekers elke kwetsbaarheid kiezen die volledig was afgesloten na SSLv2. Uiteindelijk vonden ze een geschikte optie: de Bleichenbacher-aanval, die we eerder hebben genoemd en die we in het volgende artikel in detail zullen uitleggen. SSL en TLS zijn beschermd tegen deze aanval, maar enkele willekeurige SSL-functies in combinatie met korte sleutels in export-class cryptografie maakten het mogelijk een bepaalde implementatie van DROWN.

Op het moment van publiceren waren 25% van de topwebsites van het internet kwetsbaar voor DROWN, en de aanval kon worden uitgevoerd met bescheiden middelen, beschikbaar zelfs voor ondeugende solo-hackers. Voor het extraheren van de RSA-sleutel van de server waren acht uur rekenkracht en $440 nodig, en SSLv2 veranderde de status van 'verouderd' naar 'radioactief'.

Wacht even, wat is er met Heartbleed?

Dit is geen cryptografische aanval in de zin zoals hierboven beschreven; het is een buffer overflow.

Laten we een pauze nemen

We begonnen met enkele basis methoden: brute force, interpolatie, degradatie, cross-protocol en pre-computations. Vervolgens bekeken we een geavanceerde techniek, mogelijk een belangrijk onderdeel van moderne cryptografische aanvallen: de oracle-aanval. We hebben er vrij lang over nagedacht - en begrepen niet alleen het principe erachter, maar ook de technische details van twee specifieke implementaties: de Waterner-aanval op de CBC-codering modus en de Kelsey-aanval op codering protocollen met voorafgaande compressie.

Bij het bespreken van aanvallen op degradatie en met voorafgaande berekeningen hebben we kort de FREAK-aanval samengevat, die beide methoden gebruikt, omdat doelwebsites worden terugverwezen naar zwakke sleutels en vervolgens dezelfde sleutels opnieuw gebruiken. Voor het volgende artikel hebben we de (tamelijk vergelijkbare) Logjam-aanval achtergelaten, die gericht is op algoritmen met een openbare sleutel.

Daarna hebben we nog drie voorbeelden bekeken van het toepassen van deze principes. Ten eerste, CRIME en POODLE: twee aanvallen die vertrouwden op het vermogen van de aanvaller om willekeurige platte tekst in te voegen naast de doel platte tekst, en dan de serverreacties te onderzoeken en vervolgens, met behulp van de methodologie van de oracle-aanval, deze schaarse informatie te gebruiken om deels de platte tekst te herstellen. CRIME volgde de Kelsey-aanval op SSL-compresie, terwijl POODLE in plaats daarvan een variant van de Waterner-aanval op CBC gebruikte met hetzelfde effect.

Daarna richtten we onze aandacht op de cross-protocol DROWN-aanval, die verbinding maakt met de server via het verouderde SSLv2-protocol en vervolgens geheime server sleutels herstelt met de Bleichenbacher-aanval. Tot nu toe hebben we de technische details van deze aanval overgeslagen; net als Logjam moet het wachten totdat we de cryptosystemen met openbare sleutels en hun kwetsbaarheden goed bestuderen.

In het volgende artikel zullen we praten over geavanceerde aanvallen - zoals de meet-in-the-middle methode, differentiële cryptanalyse en de 'verjaardagsaanval'. We zullen een korte blik werpen op aanvallen via zijkanalen en dan gaan we aan de slag met de meest interessante - cryptosystemen met openbare sleutels.

Bron: habr.com