När man hör ordet "kryptografi" tänker vissa på sitt WiFi-lösenord, den gröna hänglåset bredvid adressen till sin favoritwebbplats och hur svårt det är att komma åt någon annans e-post. Andra tänker på en rad sårbarheter de senaste åren med talande förkortningar (DROWN, FREAK, POODLE...) och stiliga logotyper som varnar för att uppdatera webbläsaren omedelbart.

Kryptografi omfattar allt detta, men essensen ligger i något annat. Essensen ligger i den fina gränsen mellan enkelt och komplext. Vissa saker är lätta att göra men svåra att återställa: till exempel att knäcka ett ägg. Andra saker är enkla att göra men svåra att återställa när den lilla, viktiga avgörande delen saknas: till exempel att öppna en låst dörr när "den avgörande delen" är nyckeln. Kryptografi studerar dessa situationer och hur de kan tillämpas praktiskt.

Under de senaste åren har samlingen av kryptografiska attacker förvandlats till en djungel av skrikande logotyper, fyllda med formler från vetenskapliga artiklar, och har skapat en allmän dyster känsla av att allt är trasigt. Men i själva verket bygger många av attackerna på några gemensamma principer, och de oändliga sidorna med formler kan ofta reduceras till enkla, förståeliga idéer.

I denna artikelserie kommer vi att titta på olika typer av kryptografiska attacker, med fokus på de grundläggande principerna. I stora drag och inte nödvändigtvis i den här ordningen, men vi kommer att täcka följande:

• Grundläggande strategier: brute-force, frekvensanalys, interpolation, nedan och cross-protokoll.
• "Brand"-sårbarheter: FREAK, CRIME, POODLE, DROWN, Logjam.
• Avancerade strategier: orakelattacker (Waterner-attacken, Kelsey-attacken); meet-in-the-middle-metoden, födelsedagsattack, statistisk förskjutning (differentiell kryptanalys, integral kryptanalys osv.).
• Sideloadattacker och deras nära släktingar, felanalysmetoder.
• Attacker mot kryptografi med offentlig nyckel: kubroten, broadcast, relaterad meddelande, Coppersmiths attack, Pollard-Hellman-algoritmen, numeriskt sikt, Wieners attack, Blaychenbachers attack.

Den här specifika artikeln täcker det ovan nämnda materialet fram till Kelsey-attacken.

Grundläggande strategier

De följande attackerna är enkla i den meningen att de kan förklaras nästan helt utan speciella tekniska detaljer. Vi kommer att förklara varje typ av attack i de enklaste termerna, utan att djupdyka i komplexa exempel eller avancerade användningsområden.

Vissa av dessa attacker har i stort sett blivit irrelevanta och har inte använts på många år. Andra – veteraner, de smyger fortfarande regelbundet på intet ont anande utvecklare av kryptosystem under 21-talet. Man kan säga att epoken för modern kryptografi började med introduktionen av IBM DES – den första kryptografiska algoritmen som motstod alla attacker på denna lista.

Enkel brute force

Krypteringsschemat består av två delar: 1) en krypteringsfunktion som tar emot ett meddelande (klart text) tillsammans med en nyckel och sedan skapar ett krypterat meddelande – ciphertext; 2) en dekrypteringsfunktion som tar emot ciphertext och nyckeln och skapar klart text. Både kryptering och dekryptering bör vara lätta att beräkna med nyckeln – och svåra utan den.

Anta att vi ser ciphertext och försöker dekryptera det utan ytterligare information (detta kallas en "endast ciphertext"-attack). Om vi på något magiskt sätt hittar den rätta nyckeln kan vi lätt verifiera att den är korrekt om resultatet är ett rimligt meddelande.

Observera att det här finns två underförstådda antaganden. För det första att vi vet hur man utför dekrypteringen, det vill säga hur kryptosystemet fungerar. Detta är en standardantagande när man diskuterar kryptografi. Att dölja detaljerna i krypteringsalgoritmen från angripare kan verka som en extra säkerhetsåtgärd, men så snart angriparen tar reda på dessa detaljer är denna extra säkerhet osynlig och oåterkallelig förlorad. Så är Kerckhoffs princip: att ifall systemet hamnar i fiendens händer ska det inte orsaka några problem.

För det andra antar vi att den rätta nyckeln är den enda nyckeln som leder till en rimlig dekryptering. Detta är också en rimlig förutsättning; den gäller om ciphertext är mycket längre än nyckeln och är lättläst. Så brukar det vara i den verkliga världen, med undantag för gigantiskt opraktiska nycklar eller andra manipulationer som är bättre att lämna därhän. (om du inte gillar att vi avfärdar förklaringar, vänligen se teorem 3.8 här).

Med detta i åtanke uppstår strategin: att kontrollera varje möjlig nyckel. Detta kallas bruteforce, och en sådan attack fungerar garanterat mot alla praktiska krypton – i slutändan. Till exempel är bruteforce tillräckligt för att bryta Caesars chiffret, en gammal chiffer där nyckeln är en bokstav från alfabetet, vilket innebär något mer än 20 möjliga nycklar.

Tyvärr för kryptanalytiker ökar storleken på nyckeln skyddet mot bruteforce. I takt med att nyckelstorleken ökar, ökar antalet möjliga nycklar exponentiellt. Med moderna nyckelstorlekar är enkel bruteforce helt orealistisk. För att förstå vad vi menar, ta den snabbaste kända superdatorn i mitten av 2019: Summit från IBM, med en toppprestanda på cirka 10^17 operationer per sekund. Idag är den typiska nyckellängden 128 bitar, vilket innebär 2^128 möjliga kombinationer. För att pröva alla nycklar skulle superdatorn Summit behöva tid som är ungefär 7800 gånger längre än universums ålder.

Ska bruteforce betraktas som en historisk kuriositet? Absolut inte: det är en nödvändig ingrediens i kryptanalysens kokbok. Det förekommer sällan så svaga chiffers att de kan brytas enbart med smart attack, utan något slags kraftansträngning. Många framgångsrika intrång använder först en algoritmisk metod för att svaga det målade chiffret och sedan körs bruteforce.

Frekvensanalys

De flesta texter är inget trams. Till exempel har engelskspråkiga texter många bokstäver 'e' och artikeln 'the'; i binära filer finns det många nollor som fyllnad mellan informationsbitar. Frekvensanalys är en vilken attack som använder denna fakta.

Ett kanoniskt exempel på ett chiffer som är sårbart för denna attack är enkelt substitutionschiffer. I detta chiffer representerar nyckeln en tabell som ersätter alla bokstäver. Till exempel, 'g' ersätts med 'h', 'o' med 'j', därför blir ordet 'go' till 'hj'. Detta chiffer är svårt att bryta med enkel bruteforce, eftersom det finns så många möjliga substitutions tabeller. Om du är intresserad av matematik, är den effektiva nyckellängden cirka 88 bitar: det är
. Men frekvensanalys hanterar vanligtvis uppgiften snabbt.

Låt oss överväga följande chiffertext, bearbetad med en enkel substitutionschiffer:

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

Eftersom Y det förekommer ofta, inklusive i slutet av många ord, kan vi preliminärt anta att det är bokstaven e:

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

Ett par XD upprepas i början av flera ord. Särskilt kombinationen XDeLe antyder tydligt ordet these eller there, så vi fortsätter:

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

Vidare antar vi att L motsvarar är lika med noll., A — a osv. Det kommer troligen att krävas flera försök, men jämfört med fullständig brute force återskapar denna attack den ursprungliga texten på kort tid:

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

För vissa är lösningen av sådana "kryptogram" en fascinerande hobby.

Idén med frekvensanalys är mer grundläggande än den först verkar. Och den kan tillämpas på mycket mer komplexa chiffer. Genom historien har olika chifferkonstruktioner försökt stå emot denna typ av attack med hjälp av "polyalfabetisk substitution". Här förändras bokstavsersättningstabellen under kryptering på komplexa men förutsägbara sätt som beror på nyckeln. Alla dessa chiffer ansågs en gång svåra att bryta; och ändå övervann den blygsamma frekvensanalysen till slut alla.

Det mest ambitiösa polyalfabetiska chiffret i historien och sannolikt det mest kända var "Enigma"-chiffret under andra världskriget. Det var relativt komplext jämfört med sina föregångare, men efter lång och hård kamp lyckades brittiska kryptanalytiker bryta det med hjälp av frekvensanalys. Naturligtvis kunde de inte utveckla en elegant attack som den som visades ovan; de var tvungna att jämföra kända par av klartext och chiffertext (den så kallade "öppna textens attack") och även provocera "Enigma"-användare att kryptera specifika meddelanden för att analysera resultaten ("validerad öppentext-attack"). Men det lättade inte ödet för de besegrade arméerna hos fienden och de sänkta ubåtarna.

Efter denna triumf försvann frekvensanalys ur kryptografiens historia. Chiffer från den moderna digitala eran är skapade för att arbeta med bitar, inte bokstäver. Vad som är ännu viktigare är att dessa chiffer utvecklades med en dyster förståelse av det som senare blev känt som Schneiers lag: vem som helst kan skapa en krypteringsalgoritm som de själva inte kan bryta. Det räcker inte för att kryptosystemet verkar komplicerat: för att bevisa sitt värde måste det genomgå en obarmhärtig säkerhetsöversikt av många kryptanalytiker som kommer att göra allt för att knäcka chifferet.

Förhandsberäkningar

Låt oss ta den hypotetiska staden Prekom Heights med en befolkning på 200 000 människor. I varje hem i staden finns värdesaker i genomsnitt värda $30 000, men högst $50 000. Säkerhetsmarknaden i Prekom är monopoliserad av företaget ACME Industries, som tillverkar de legendariska dörrlåsen av Coyote ™-klass. Enligt expertanalys kan ett lås av Coyote-klass brytas endast av en mycket avancerad hypotetisk maskin, vars skapande tar omkring fem år och $50 000 i investeringar. Är staden säker?

Sannolikt inte. I slutändan kommer det att dyka upp en tillräckligt ambitiös brottsling. Han kommer att resonera så här: "Ja, jag kommer att få stora initiala kostnader. Fem års tålmodigt väntande och $50 000. Men när arbetet är klart kommer jag att ha tillgång till all denna rikedom i staden. Om jag spelar mina kort rätt, så kommer denna investering att betala sig mångdubbelt."

På samma sätt i kryptografi. Attacker mot ett specifikt chiffer genomgår en obarmhärtig kostnads- och nyttovärdering. Om förhållandet är gynnsamt sker ingen attack. Men attacker som riktar sig mot många potentiella offer lönar sig nästan alltid, och i dessa fall är bästa designpraxis att anta att de har påbörjats från första dagen. Vi har i grunden en kryptografisk version av Murphys lag: "Allt som kan knäcka systemet kommer att knäcka systemet."

Ett enkelt exempel på ett kryptosystem som är sårbart för attacker med förhandsberäkningar är chiffer med en konstant algoritm utan nyckelanvändning. Så var fallet med Cæsar-chiffret, som helt enkelt flyttar varje bokstav i alfabetet tre steg framåt (tabellen är cirkulär, så den sista bokstaven i alfabetet kodas av den tredje). Här visar principen för Kerckhoffs sig återigen: så snart systemet är genombrottet, är det genombrottet för alltid.

Konceptet är enkelt. Även en nybörjare inom kryptografisk utveckling kommer troligtvis att förstå hotet och förbereda sig på lämpligt sätt. Om man ser på utvecklingen av kryptografi, var sådana attacker irrelevanta för de flesta chiffer, från de tidiga förbättrade versionerna av Caesar-chiffret fram tills nedgången av polyalfabetiska chiffer. Dessa attacker återkom först med den moderna kryptografins ankomst.

Denna återkomst beror på två faktorer. För det första har det äntligen uppstått tillräckligt komplexa kryptosystem där möjligheten till utnyttjande efter ett genombrott inte var uppenbar. För det andra har kryptografi blivit så utbredd att miljontals lekmän varje dag fattar beslut om var och vilka delar av kryptografi som ska användas på nytt. Det tog ett tag innan experterna insåg de uppkomna riskerna och larmade.

Kom ihåg attacken med förberäkning: i slutet av artikeln kommer vi att titta på två kryptografiska exempel från verkliga livet där den spelade en viktig roll.

Interpolation

Framför dig står den berömda detektiven Sherlock Holmes, som genomför en attack med interpolation på den olycklige doktor Watson:

Jag insåg genast att ni kom från Afghanistan... Den tankebanor jag följde var: "Den här personen är en läkare, men hans uppenbarelse är militär. Så han är en militär läkare. Han har just kommit från tropikerna - hans ansikte är solbränt, men det är inte en naturlig nyans av hans hud, för hans handleder är mycket ljusare. Hans ansikte är utmattat - uppenbarligen har han genomlidit och överlevt en sjukdom. Han har skadat sin vänstra arm - han håller den stilla och lite onaturligt. Var kan en brittisk militär läkare ha lidit av entropier och fått ett sår i tropikerna? Självklart, Afghanistan." Hela tanken tog inte mer än en sekund. Och så sade jag att ni kom från Afghanistan och ni blev överraskad.

Från varje bikupa kunde Holmes utvinna mycket lite information. Han kunde endast komma till sin slutsats efter att ha granskat dem alla tillsammans. På liknande sätt fungerar interpolationattacker, som undersöker kända par av öppen och krypterad text som fåtts genom att använda samma nyckel. Från varje par utvinns separata observationer, som möjliggör en sammanfattande slutsats om nyckeln. Alla dessa slutsatser är vaga och framstår som värdelösa, tills de plötsligt når en kritisk massa och leder till den enda möjliga slutsatsen: hur otroligt det än kan verka, så måste den vara sann. Antingen avslöjas nyckeln efter detta, eller så blir dekrypteringsprocessen så arbetad att den går att replikera.

Låt oss illustrera med ett enkelt exempel hur interpolation fungerar. Antag att vi vill läsa vår fiendes dagbok, Bob. Han krypterar varje nummer i sin dagbok med hjälp av ett enkelt kryptosystem som han fått veta om från en annons i tidningen "Skratta åt kryptografi". Systemet fungerar på följande sätt: Bob väljer två nummer som han gillar: och . Från och med nu, för att kryptera ett nummer , beräknar han . Till exempel, om Bob väljer och , kommer siffran att krypteras som .

Anta att vi den 28 december märker att Bob skriver något i sin dagbok. När han är klar, kommer vi diskret att ta den och titta på den senaste anteckningen:

Datum: 235/520

Kära dagbok,

Idag har varit en bra dag. Om 64 dagar har jag en dejt med Alice, som bor på adressen 843. Jag tror verkligen att hon kan vara 26!

Eftersom vi är väldigt seriösa med att följa Bob på hans dejt (i det här scenariot är vi 15 år gamla), är det kritiskt viktigt att få veta datumet samt Alices adress. Lyckligtvis märker vi att Bobs kryptosystem är sårbart för en interpolationattack. Vi kanske inte känner till och , men vi vet vad dagens datum är, så vi har två par av "öppen text – krypterad text". Det vill säga, vi vet att krypteras som , och — i . Vilket vi skriver ner:

Eftersom vi är 15 år gamla känner vi redan till systemet med två ekvationer med två okända, vilket är tillräckligt i detta fall för att hitta och utan några problem. Varje par av "öppen text-krypterad text" sätter ett begränsning på Bobs nyckel, och två begränsningar tillsammans är tillräckliga för att helt återställa nyckeln. I vårt exempel är svaret och (vid , så att 26 i dagboken motsvarar ordet 'den enda', det vill säga "den specifika" — anm. övers.

Interpolationsattacker är förstås inte begränsade till så enkla exempel. Varje kryptosystem som kan reduceras till ett välkänt matematiskt objekt och en lista över parametrar är i risksonen för interpolationsattacker — ju mer förståeligt objektet är, desto högre är risken.

Nykomlingar klagar ofta på att kryptografi är "konsten att designa så fula saker som möjligt." Sannolikt är mycket av skylden på interpolationsattacker. Bob kan antingen använda en elegant matematisk design eller bevara sin integritet i mötet med Alice — men tyvärr kan man oftast inte få båda. Detta kommer att bli uppenbart när vi till sist går över till ämnet kryptografi med öppen nyckel.

Cross-protokoll/nedsättning

I filmen "Illusionens mästare" (2013) försöker en grupp illusionister lura till sig hela förmögenheten av den korrumperade försäkringsmagnaten Arthur Tressler. För att få tillgång till Arthurs bankkonto måste illusionisterna antingen presentera hans användarnamn och lösenord, eller få honom att personligen dyka upp i banken och delta i planen.

Båda alternativen är mycket svåra; killarna är vana vid att uppträda på scen, snarare än att delta i underrättelseoperationer. Därför väljer de det tredje möjliga alternativet: deras medhjälpare ringer till banken och utger sig för att vara Arthur. Banken ställer några frågor för att verifiera identiteten, såsom namnen på hans farbror och första husdjur; våra hjältar får i förhand lätt den informationen från Arthur genom skicklig social ingenjörskonst. Från och med nu spelar inte en utmärkt lösenordssäkerhet längre någon roll.

(Enligt en stadslegend som vi personligen har kontrollerat och bekräftat, stötte kryptografen Eli Biham en gång på en banktjänsteman som krävde att ställa en säkerhetsfråga. När banktjänstemannen frågade namnet på hans mormor på mödernet, började Biham diktera: "Versal X, liten y, tre...").

Så är det också inom kryptografi; om två kryptografiska protokoll används parallellt för att skydda samma tillgång, där det ena är betydligt svagare än det andra, blir det slutliga systemet sårbart för en korsprotokollsattack, där det svagare protokollet attackeras för att nå målet utan att röra det starkare.

I vissa komplicerade fall räcker det inte att bara kontakta servern via det svagare protokollet, utan det krävs ofrivilligt deltagande från den legitima kunden. Detta kan organiseras genom så kallad nedgraderingsattack. För att förstå denna attack, anta att våra illusionister har en mer komplex uppgift än i filmen. Anta att en bankanställd (kassör) och Arthur har stött på oförutsedda omständigheter, vilket resulterar i följande dialog:

Hacker: Hallå? Det är Arthur Tressler. Jag skulle vilja återställa mitt lösenord.

Kassör: Utmärkt. Vänligen titta i din personliga bok med hemliga koder, sida 28, ord 3. Alla följande meddelanden kommer att vara krypterade med detta specifika ord som nyckel. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Hacker: Ehh, vänta, vänta. Är det verkligen nödvändigt? Kan vi inte bara prata som normala människor?

Kassör: Jag rekommenderar inte att du gör det.

Hacker: Jag bara... lyssna, jag har haft en dålig dag, okej? Jag är en VIP-kund och inte på humör för att bläddra i dessa dumma kodböcker.

Kassör: Okej. Om du insisterar, herr Tressler. Vad kan jag hjälpa dig med?

Hacker: Snälla, jag skulle vilja överföra alla mina pengar till den nationella fonden för offren för Arthur Tressler.

(Paus).

Kassör: Okej, jag förstår. Vänligen ange din PIN-kod för stora transaktioner.

Hacker: Min vad?

Kassör: På din personliga begäran kräver transaktioner av den storleken att du anger en PIN-kod för stora transaktioner. Denna kod gavs till dig när du öppnade ditt konto.

Hacker:… Jag har tappat den. Är det verkligen nödvändigt? Kan du inte bara godkänna transaktionen?

Kassör: Nej. Jag ber om ursäkt, herr Tressler. Återigen, det här är en säkerhetsåtgärd som du bad om. Om du vill kan vi skicka en ny PIN-kod till din postlåda.

Våra hjältar skjuter upp operationen. De lyssnar på flera stora transaktioner från Tressler och hoppas få höra PIN-koden; men varje gång blir samtalet till ett kryptiskt babbel innan något intressant hörs. Till slut, en vacker dag, sätter de planen i verket. De väntar tålmodigt på ögonblicket när Tressler ska göra en stor telefontransaktion, han kopplar upp sig, och sedan...

Tressler: Hej. Jag skulle vilja göra en fjärrtransaktion, tack.

Kassör: Utmärkt. Vänligen kolla i din personliga bok med hemliga koder, sida…

(Hackern trycker på en knapp; kassörens röst omvandlas till otydlig brus).

Kassör: — #@$#@$#*@$$@#* kommer att krypteras med detta ord som nyckel. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Förlåt, jag förstod inte riktigt. Kan du upprepa? Vilken sida? Vilket ord?

Kassör: Det är sida @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: Vad?

Kassör: Ordningsnummer tjugo @$#@$#%#$.

Tressler: På allvar! Sluta nu! Ditt säkerhetsprotokoll är ett skämt. Jag vet att du kan prata ordentligt med mig.

Kassör: Jag rekommenderar inte…

Tressler: Och jag rekommenderar inte att du slösar min tid. Jag vill inte höra mer om det här förrän du har löst problemen med din telefonlinje. Kan vi genomföra den här affären eller inte?

Kassör:...ja. Bra. Vad önskar du?

Tressler: Jag skulle vilja överföra $20 000 till företaget Lord Business Investments, kontonummer...

Kassör: Ett ögonblick, tack. Det här är en stor affär. Vänligen ange din PIN-kod för stora transaktioner.

Tressler: Vad? Åh, just det. 1234.

Här kommer en nedåtgående attack. Det svagare protokollet "prata bara rakt" var avsett som alternativ nödlösning. Och ändå är vi här.

Man kan undra vem som är i sin rätta skapelse som skulle designa ett verkligt system av typen "säkert tills du ber om motsatsen", som beskrivs ovan. Men precis som att den fiktiva banken tar en risk för att behålla kunder som inte gillar kryptografi, så lutar sig system generellt ofta mot krav som är likgiltiga eller till och med öppet fientliga mot säkerhet.

En sådan historia inträffade med protokollet SSLv2 år 1995. Den amerikanska regeringen hade länge sett på kryptografi som ett vapen som bör hållas borta från både externa och interna fiender. Separata kodbitar godkändes för export från USA, ofta under förutsättning att algoritmen medvetet försvagades. Företaget Netscape, utvecklaren av den mest populära webbläsaren Netscape Navigator, fick tillstånd att använda SSLv2 endast med en ursprungligen sårbar RSA 512-bitars nyckel (och 40 bitar för RC4).

I slutet av årtusendet mjukades reglerna upp och tillgången till modern kryptering blev allmänt tillgänglig. Trots detta fortsatte klienter och servrar under många år att stödja den försvagade "exportkrypteringen" på grund av samma tröghet som gör att gammal teknik fortsätter att stödjas. Klienterna antog att de kunde stöta på servrar som inte stödde något annat. Servrar gjorde detsamma. Självklart föreskriver SSL-protokollet att klienter och servrar aldrig ska använda ett svagt protokoll när ett bättre är tillgängligt. Men samma förutsättning gällde för Tresstler och hans bank.

Denna teori tillämpades i två uppmärksammade attacker som på rad skakade säkerheten i SSL-protokollet under 2015, båda upptäcktes av forskare från Microsoft och INRIA. Först avslöjades detaljer om FREAK-attacken i februari, och tre månader senare kom en annan liknande attack kallad Logjam, som vi kommer att diskutera mer ingående när vi går vidare till attacker på offentliga nycklar.

Sårbarhet FREAK (även känd som "Smack TLS") uppstod när forskare analyserade TLS-klient/serverimplementationer och upptäckte en intressant bugg. I dessa implementationer, om klienten inte ens begär att använda svag exportkryptering, men servern ändå svarar med sådana nycklar – säger klienten "Okej då" och går över till en svag krypteringsuppsättning.

Vid den tiden ansågs exportkryptografi vara föråldrad och förbjuden att använda, så attacken blev en riktig chock och påverkade många viktiga domäner, inklusive Vita husets, USAs skatteverks och NSA:s webbplatser. Ännu värre var att många sårbara servrar optimerade prestanda genom att återanvända samma nycklar istället för att skapa nya för varje session. Detta gjorde det möjligt att genomföra en ytterligare attack med förberäkning efter att protokollet hade sänkts: att knäcka en enda nyckel var fortfarande relativt dyrt (100 USD och 12 timmar vid publiceringstillfället), men den praktiska kostnaden för attacken på en anslutning minskade betydligt. Det räckte med att knäcka servernyckeln en gång - och kryptera för alla efterföljande anslutningar från det ögonblicket.

Och innan vi går vidare bör en avancerad attack nämnas ...

Orakelsattacken

Moxie Marlinspike är mest känd som fadern till den plattformsoberoende kryptomeddelaren Signal; men personligen gillar vi en av hans mindre kända innovationer - principen för kryptografisk död (Cryptographic Doom Principle). Lite omformulerat kan man säga så här: "Om ett protokoll utför någon kryptografisk operation på meddelande från en potentiellt skadlig källa och beter sig på ett olika sätt beroende på utfallet, så är det dömt att misslyckas." Eller i en mer drastisk form: "Ta inte emot information från fienden för bearbetning, och om du måste, visa åtminstone inte resultatet."

Vi lämnar buffertöverflöden, kommandoinjektioner och liknande åt sidan; de ligger utanför denna diskussion. Att bryta mot "principen för död" leder till allvarliga kryptografiska intrång eftersom protokollet beter sig precis som det är avsett.

Som exempel tar vi en påhittad konstruktion med en sårbar substitutionskryptering och visar sedan en möjlig attack. Även om vi redan har sett en attack på substitutionskrypteringen med hjälp av frekvensanalys, är detta inte bara "ett annat sätt att bryta samma kryptering". Tvärtom, orakelsattacker är en mycket mer modern uppfinning, tillämplig i många situationer där frekvensanalys misslyckas, och vi kommer att se en demonstration av detta i nästa avsnitt. Här är den enkla krypteringen vald enbart för att göra exemplet tydligare.

Så, Alice och Bob kommunicerar med hjälp av en enkel substitutionschiffer, som använder en nyckel som bara de känner till. De är mycket strikta med längden på meddelanden: deras längd är exakt 20 tecken. Så de kom överens om att om någon vill skicka ett kortare meddelande, måste de lägga till någon slags fejktext i slutet av meddelandet så att det blir exakt 20 tecken. Efter en del diskussion bestämde de att de endast skulle acceptera följande fejktexter: a, bb, ccc, dddd och så vidare. På så sätt är den fejkade texten känd i alla nödvändiga längder.

När Alice eller Bob får ett meddelande kontrollerar de först att meddelandet har rätt längd (20 tecken) och att suffixet är rätt fejktext. Om inte, svarar de med ett motsvarande felmeddelande. Om längden på texten och fejktexten är ok, läser mottagaren meddelandet och skickar ett krypterat svar.

Under attacken låtsas en angripare vara Bob och skickar falska meddelanden till Alice. Meddelandena är rena nonsens – angriparen har ingen nyckel och kan därför inte förfalska ett meningsfullt meddelande. Men eftersom protokollet bryter mot osäkerhetsprincipen kan angriparen ändå lura Alice att avslöja information om nyckeln, som visas nedan.

Hacker: PREWF ZHJKL MMMN. LA

Alice: Ogiltig fejktext.

Hacker: PREWF ZHJKL MMMN. LB

Alice: Ogiltig fejktext.

Hacker: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Angriparen har ingen aning om vad Alice just sa, men noterar att tecknet C måste matcha a, eftersom Alice accepterade fejktexten.

Hacker: REWF ZHJKL MMMN. LAA

Alice: Ogiltig fejktext.

Hacker: REWF ZHJKL MMMN. LBB

Alice: Ogiltig fejktext.

Efter flera försök…

Hacker: REWF ZHJKL MMMN. LGG

Alice: Ogiltig fejktext.

Hacker: REWF ZHJKL MMMN. LHH

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

Återigen har angriparen ingen aning om vad Alice just sa, men noterar att H måste matcha med b, eftersom Alice accepterade fejktexten.

Och så vidare, tills angriparen lär sig betydelsen av varje tecken.

Vid första anblick verkar metoden likna en attack baserad på anpassad klartext. I slutändan försöker angriparen att få fram chiffertext, och servern bearbetar dem lydigt. Den grundläggande skillnaden som gör dessa attacker möjliga i verkliga situationer är att angriparen inte behöver tillgång till den faktiska avkodningen – det räcker med ett svar från servern, även om det är något så ofarligt som "Felaktig dummytext".

Även om denna specifika attack är lärorik, bör man inte fokusera för mycket på detaljerna i "dummytextschemat", den specifika kryptografiska metoden som används eller den exakta sekvensen av meddelanden som skickas av angriparen. Huvidpoängen är hur Alice reagerar på olika sätt beroende på egenskaperna hos klartexten, och gör detta utan att kontrollera att den motsvarande chiffertexten faktiskt har mottagits från en betrodd part. På så sätt låter Alice angriparen pressa ut hemlig information från hennes svar.

Mycket kan förändras i det här scenariot. Symbolerna som Alice reagerar på, skillnaderna i hennes beteende eller till och med den kryptografiska metoden som används. Men principen förblir densamma, och attacken kommer överlag att förbli möjlig i någon form. Den grundläggande implementationen av denna attack har hjälpt till att avslöja flera säkerhetsbrister som vi snart kommer att undersöka; men först bör vi ta till oss några teoretiska lärdomar. Hur kan detta påhittade "Alicescenario" användas i en attack som kan fungera på ett verkligt modernt chiffer? Är detta ens möjligt, även i teorin?

År 1998 bekräftade den schweiziska kryptografen Daniel Bleichenbacher denna fråga. Han demonstrerade en orakelsattack i det allmänt använda offentliga nyckelsystemet RSA, med en viss meddelandeschema. I vissa implementationer av RSA svarar servern med olika felmeddelanden, beroende på om klartexten överensstämmer med schemat eller inte; det var tillräckligt för att genomföra en attack.

Fyra år senare, 2002, demonstrerade den franska kryptografen Serge Vaudenay en orakelsattack som nästan var identisk med den som beskrivs ovan i Alicias scenario – med den skillnaden att han istället för en påhittad kryptering knäckte en hel respektabel klass av moderna krypteringar som människor faktiskt använder. Specifikt riktar sig Vaudenays attack mot krypton med fast inmatningsstorlek ("blockkryptering") när de används i det som kallas "CBC-krypteringsläge" och med ett visst populärt fyllnadsschema, som huvudsakligen motsvarar det i Alicias scenario.

Även 2002 föreslog den amerikanske kryptografen John Kelsey – medförfattare Twofish – olika orakelsattacker på system som komprimerar meddelanden och sedan krypterar dem. Den mest anmärkningsvärda bland dem var en attack som utnyttjade det faktum att man ofta kan dra slutsatsen om den ursprungliga längden på klartexten från längden på den krypterade texten. I teorin gör detta det möjligt att genomföra en orakelsattack som återskapar delar av den ursprungliga klartexten.

Nedan ger vi en mer detaljerad beskrivning av Vaudenays och Kelseys attacker (vi kommer att ge en mer detaljerad beskrivning av Blайхенбахers attack när vi går till attacker mot offentlig nyckelkryptografi). Trots våra ansträngningar blir texten något teknisk; därför, om det som ovan räcker för dig, hoppa över de följande två avsnitten.

Vaudenays attack

För att förstå Vaudenays attack behöver vi först prata lite mer om blockkrypteringar och krypteringslägen. "Blockkryptering" är, som nämnts tidigare, en kryptering som tar en nyckel och en inmatning av viss fast längd ("blocklängd") och ger en krypterad block av samma längd. Blockkrypteringar är mycket använda och anses relativt säkra. Det numera pensionerade DES, som anses vara den första moderna krypteringen, var en blockkryptering. Samma sak gäller för AES, som är allmänt använt idag.

Tyvärr har blockchiffer en åpenbar svaghet. Typisk blockstorlek är 128 bitar, eller 16 tecken. Det är uppenbart att modern kryptering kräver att man arbetar med indata av större storlek, och det är här krypteringslägena kommer in i bilden. Krypteringsläge är i huvudsak en hack; det är ett sätt att på något sätt tillämpa ett blockchiffer, som tar emot indata av en viss storlek, på indata av godtycklig längd.

Vodena-attacken riktar sig mot det populära läget CBC (Cipher Block Chaining, blockkedjande chiffer). Attacken betraktar det underliggande blockchiffret som en magisk, oåtkomlig svart ruta och kringgår helt dess säkerhet.

Här är en diagram som visar hur CBC-läget fungerar:

En omgiven plussymbol betyder XOR-operationen (exklusivt "eller"). Till exempel, den andra blocken av chiffertexten erhölls genom:

1. Att utföra XOR-operationen på den andra blocken av klartexten med den första blocken av chiffertexten.
2. Att kryptera den erhållna blocken med hjälp av blockchiffret, med nyckeln.

Eftersom CBC utnyttjar XOR-binära operationen så intensivt, låt oss ta tillfället i akt att påminna oss om några av dess egenskaper:

• Idempotens:
• Kommutativitet:
• Associativitet:
• Självöverföring:
• Byte för byte: byte n från = (byte n från ) (byte n från )

Generellt innebär dessa egenskaper att om vi har en ekvation som inkluderar XOR-operationer och ett okänt, kan det lösas. Till exempel, om vi vet att med ett okänt och kända och , så kan vi luta oss mot de ovan nämnda egenskaperna för att lösa ekvationen för . Genom att tillämpa XOR på båda sidor av ekvationen med , får vi . Om ett ögonblick kommer allt detta att bli mycket relevant.

Det finns två obetydliga skillnader och en huvudskillnad mellan vårt Alice-scenario och Vodena-attacken. De två obetydliga:

• I scenariot förväntade sig Alice att klartexterna slutade med tecken a, bb, ccc och så vidare. I Vodena-attacken förväntar sig offret istället att klartexterna slutar med N gånger byte N (det vill säga hexadecimalt 01 eller 02 02, eller 03 03 03 och så vidare). Detta är en rent kosmetisk skillnad.
• I Alice-scenariot var det enkelt att avgöra om Alice tog emot meddelandet, utifrån svaret "Fel falsk text". I Vodene-angreppet krävs en större analys och det är viktigt med en exakt implementering på offrets sida; men för korthetens skull antar vi att denna analys fortfarande är möjlig.

Det främsta skillnaden:

• Eftersom vi inte använder samma kryptosystem kommer sambandet mellan de kontrollerade byte som angriparen har av den krypterade texten och hemligheterna (nyckeln och klartexten) att vara annorlunda. Därför måste angriparen använda en annan strategi för att skapa chiffertext och tolka serverns svar.

Den här huvudskillnaden är den sista biten av pusslet för att förstå Vodene-angreppet, så låt oss för ett ögonblick tänka på varför och hur ett orakelangrepp på CBC kan organiseras överhuvudtaget.

Låt oss anta att vi har en CBC-chiffertext med 247 block, och vi vill dekryptera den. Vi kan skicka falska meddelanden till servern, precis som vi tidigare kunde skicka falska meddelanden till Alice. Servern kommer att dekryptera meddelandena för oss, men kommer inte att visa dekrypteringen – istället, återigen som i fallet med Alice, kommer servern bara att ge oss en bit information: om klartexten har en giltig fyllning eller inte.

Tänk på att vi i Alice-scenariot hade följande relationer:

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

Vi kallar detta "Alices ekvation". Vi kontrollerade chiffertexten; servern (Alice) läckte vag information om den mottagna klartexten; och detta gjorde att vi kunde härleda information om den sista faktorn – nyckeln. På samma sätt, om vi kan hitta ett sådant samband för CBC-scenariot, kan vi extrahera viss hemlig information där också.

Lyckligtvis finns det verkligen relationer som vi kan använda. Låt oss titta på utdata från den slutliga dekrypteringsanropen av blockchiffret och kalla dessa data för . Låt oss också kalla blocken av klartext och blocken av chiffertext . Ta en titt på CBC-diagrammet igen och notera vad som uppstår:

Vi kallar detta "CBC-ekvationen".

I Alice-scenariet, där vi kontrollerar chiffertexten och övervakar läckan av information om den motsvarande öppna texten, kunde vi organisera en attack som återställde den tredje termen i ekvationen - nyckeln. I CBC-scenariot kontrollerar vi också chiffertexten och observerar läckor av information om den motsvarande öppna texten. Om analogin stämmer kan vi få information om .

Anta att vi faktiskt har återställt , vad skulle då hända? Tja, då kan vi direkt återge hela den senaste blocket av den öppna texten (), bara genom att ge (som vi har) och
den erhållna i CBC-ekvationen.

Så vi är optimistiskt inställda på den övergripande attackplanen, och det har blivit dags att arbeta med detaljerna. Vi noterar på vilket exakt sätt information om den öppna texten läcker från servern. I Alice-scenariot inträffade läckan eftersom Alice endast svarade med det korrekta meddelandet om $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ slutade med strängen a (eller bb, och så vidare, men chansen för ett slumpmässigt utfall av dessa villkor var mycket liten). På samma sätt med CBC, accepterar servern att fylla i om och endast om slutar med hexadecimala 01. Så låt oss prova samma trick: att skicka fejkade chiffertexter med våra egna fejkade värden , tills servern accepterar fyllningen.

När servern accepterar fyllningen för ett av våra fejkade meddelanden betyder det att:

Nu använder vi egenskapen av byte-för-byte XOR:

Vi känner till den första och tredje termen. Och vi har redan sett att detta gör att vi kan återställa den kvarvarande termen - den sista byten från :

Detta ger oss också den sista byten av den slutliga blocken av den öppna texten genom CBC-ekvationen och egenskapen av byte-för-byte.

Vi skulle kunna avsluta här och nöja oss med att ha genomfört en attack på en teoretiskt säker chiffer. Men faktiskt kan vi göra mycket mer: vi kan verkligen återställa hela texten. Det kräver ett visst trick som inte fanns med i det ursprungliga Alice-scenariet och som inte ingår i de obligatoriska villkoren för orakelangrepp, men metoden är fortfarande värd att studera.

För att förstå det, observera först att resultatet av att härleda det korrekta värdet för den sista byten Vi har fått en ny möjlighet. Nu, när det gäller att förfalska chiffertexter, kan vi manipulera den sista byten av den motsvarande öppna texten. Återigen beror detta på CBC-ekvationen och egenskapen av bytevis:

Eftersom vi nu känner till den andra termen kan vi använda vår kontroll över den första för att styra den tredje. Vi beräknar bara:

Tidigare kunde vi inte göra detta, eftersom vi inte hade den sista byten än. .

Hur hjälper oss detta? Låt oss anta att vi nu kommer att skapa alla chiffertexter så att den motsvarande öppna textens sista byten är 02. Nu accepterar servern fyllning endast om den öppna texten slutar på 02 02. Eftersom vi har korrigerat den sista byten kommer detta endast att ske om den näst sista byten av den öppna texten också är 02. Vi fortsätter att skicka förfalskade chifferblock och ändrar den näst sista byten tills servern accepterar fyllningen för ett av dem. Vid detta ögonblick får vi:

Och vi återställer den näst sista byten på exakt samma sätt som vi återställde den sista. Vi fortsätter i samma anda: vi korrigerar de sista två byten av den öppna texten till 03 03, upprepar denna attack för den tredje från slutet byten och så vidare, och återställer så småningom helt. .

Vad sägs om resten av texten? Observera att värdet egentligen är $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Vi kan sätta in vilket annat block som helst istället för , och attacken kommer fortfarande att vara framgångsrik. Faktum är att vi kan be servern att utföra $inline$text{BLOCK_DECRYPT}$inline$ för vilken data som helst. Vid detta ögonblick är spelet över - vi kan dekryptera vilken chiffertext som helst (titta gärna på diagrammet för CBC-dekryptering för att bekräfta detta; och observera att IV-vektorn är offentlig).

Denna specifika metod spelar en avgörande roll i oracle-attacken som vi kommer att stöta på senare.

Kelsi-attacken

Denna själsfrände till oss, John Kelsi, redogjorde för principerna bakom många möjliga attacker, och inte bara detaljerna för en specifik attack mot ett specifikt chiffer. Hans artikel från 2002 är en studie av möjliga attacker mot krypterade komprimerade data. Trodde du att det inte räcker med att ha information om att data var komprimerad före kryptering för att genomföra en attack? Det visade sig vara tillräckligt.

Det här fantastiska resultatet beror på två principer. För det första finns det en stark korrelation mellan längden på den öppna texten och längden på chiffertexten, vilket för många chiffer är exakt likadant. För det andra, när komprimering utförs, finns det också en stark korrelation mellan längden på det komprimerade meddelandet och graden av "brus" i den öppna texten, det vill säga andelen unika tecken (den tekniska termen är "stor entropi").

För att se principen i praktiken, låt oss titta på två öppna texter:

Öppen text 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Öppen text 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Anta att båda öppna texterna komprimeras och sedan krypteras. Du får två resulterande chiffertexter och måste gissa vilken chiffertext som motsvarar vilken öppen text:

Chiffertext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Chiffertext 2: DWKJZXYU

Svaret är tydligt. Bland de öppna texterna kunde endast öppen text 1 ha komprimerats till den korta längden av den andra chiffertexten. Vi kom fram till detta utan att veta något om komprimeringsalgoritmen, krypteringsnyckeln, eller ens själva chiffern. Jämfört med hierarkin av potentiella kryptografiska attacker är detta en sorts galenskap.

Kelsey påpekar vidare att under vissa ovanliga omständigheter kan denna princip också användas för att genomföra en orakelangrepp. Specifikt beskriver han hur en angripare kan återställa den hemliga öppna texten om han kan få servern att kryptera dataformulär (öppen text, följd av , medan han kontrollerar och på något sätt kan verifiera längden på det krypterade resultatet.

Återigen, som i andra orakelangrepp har vi en relation:

Återigen kontrollerar vi en medlem (), ser en liten läcka av information om en annan medlem (chiffertexten) och försöker återställa den senare (öppen text). Trots likheten är detta en något ovanlig situation jämfört med andra orakelangrepp som vi har sett.

För att illustrera hur en sådan attack kan fungera, använder vi ett påhittat komprimeringssystem som vi just har kommit på: TOYZIP. Det letar efter textsträngar som redan har dykt upp tidigare i texten och ersätter dem med tre byte-fyllare som anger var man kan hitta ett tidigare exemplar av strängen och hur många gånger den förekommer där. Till exempel strängen helloworldhello kan komprimeras till helloworld[00][00][05] en längd av 13 byte jämfört med originalet på 15 byte.

Anta att en hackare försöker återställa den öppna texten i formuläret password=..., där själva lösenordet är okänt. Enligt Kelsey attackmodellen kan hackaren be servern att komprimera och sedan kryptera formulärmeddelandena (öppen text följt av ), där  — är godtycklig text. När servern har slutfört arbetet meddelar den längden på resultatet. Attacken går till så här:

Hacker: Vänligen komprimera och kryptera den öppna texten utan några padding.

Servern: Resultatlängd 14.

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=a.

Servern: Resultatlängd 18.

Hackaren noterar: [original 14] + [tre byte som ersatte password=] + a

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=b.

Servern: Resultatlängd 18.

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=c.

Servern: Resultatlängd 17.

Hackaren noterar: [original 14] + [tre byte som ersatte password=c]. Detta antyder att den ursprungliga öppna texten innehåller strängen password=c. Det vill säga att lösenordet börjar med bokstaven c

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=ca.

Servern: Resultatlängd 18.

Hackaren noterar: [original 14] + [tre byte som ersatte password=c] + a

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=cb.

Servern: Resultatlängd 18.

(… en tid senare…)

Hacker: Vänligen komprimera och kryptera den öppna texten som har lagts till password=co.

Servern: Resultatlängd 17.

Hackaren noterar: [original 14] + [tre byte som ersatte password=co]. Enligt samma logik drar hackaren slutsatsen att lösenordet börjar med bokstäverna co

Och så vidare tills hela lösenordet har återställts.

Det kan vara förståeligt för läsaren att tro att detta är en rent akademisk övning och att ett sådant angreppsscenario aldrig kommer att inträffa i verkliga världen. Tyvärr, som vi snart kommer att se, är det bäst att inte göra några antaganden inom kryptografi.

Märkesåterkommande sårbarheter: CRIME, POODLE, DROWN

Slutligen, efter att ha granskat teorin noggrant, kan vi se hur dessa metoder tillämpas i verkliga kryptografiska attacker.

CRIME

Om attacken riktar sig mot offerets webbläsare och nätverk, kommer vissa saker att vara enklare och andra - svårare. Till exempel är det lätt att se offret's trafik: det räcker med att sitta med dem på samma café med WiFi. Av denna anledning rekommenderas det vanligtvis att potentiella offer (dvs. alla) använder en krypterad anslutning. Det kommer att vara svårare, men fortfarande möjligt, att utföra HTTP-förfrågningar i offrets namn till en annan webbplats (till exempel Google). Angriparen måste locka offret till en skadlig webbsida med ett skript som gör förfrågan. Webbläsaren kommer automatiskt att tillhandahålla motsvarande sessionscookie.

Det verkar otroligt. Om Bob besöker evil.com, kan skriptet på denna webbplats verkligen be om att Google skickar Bobs lösenord via e-post till attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), och det var populärt runt mitten av 90-talet. Idag, om evil.com någon försöker ett sådant trick, svarar Google (eller vilken respekterad webbplats som helst) vanligtvis: "Bra, men din CSRF-token för den här transaktionen kommer att vara... hmm... tre triljoner och sju. Vänligen upprepa detta nummer." Moderna webbläsare tillämpar något som kallas "same-origin policy", vilket innebär att skript på webbplats A inte får åtkomst till information som skickas från webbplats B. Därför kan skript på evil.com skicka förfrågningar till google.com, men kan inte läsa svaren eller faktiskt slutföra transaktionen.

Vi måste betona att om Bob inte använder en krypterad anslutning är alla dessa skydd meningslösa. Hackaren kan helt enkelt läsa Bobs trafik och återfå Googles sessionskaka. Med denna kaka kan han enkelt öppna en ny flik på Google utan att logga ut från sin egen webbläsare och utge sig för att vara Bob, utan att stöta på besvärliga same-origin policyer. Men, tyvärr för hackaren, händer detta allt mer sällan. Internet har övergripande förklarat krig mot okrypterade anslutningar, och Bobs utgående trafik är troligen krypterad, oavsett om han gillar det eller inte. Dessutom har trafiken i den initiala implementeringen av protokollet också komprimerats innan krypteringen; det var en vanlig praxis för att minska fördröjningen.

Här kommer CRIME (Compression Ratio Infoleak Made Easy, enkel läcka via kompressionsförhållande) in i bilden. En sårbarhet som upptäcktes i september 2012 av säkerhetsforskare Juliano Rizzo och Thai Duong. Vi har redan gått igenom hela den teoretiska grunden som gör att vi kan förstå vad de gjorde och hur. Hackaren kan få Bobs webbläsare att skicka förfrågningar till Google, och sedan avlyssna svaren i det lokala nätverket i komprimerad och krypterad form. Så här har vi:

Här kontrollerar hackaren förfrågan och har åtkomst till trafiksniffaren, inklusive paketstorlekar. Den påhittade scenarion Kelsi har blivit verklighet.

Genom att förstå teorin skapade författarna till CRIME en exploit som kan stjäla sessionscookies för ett brett spektrum av webbplatser, inklusive Gmail, Twitter, Dropbox och Github. Sårbarheten påverkade de flesta moderna webbläsare, vilket ledde till att patchar släpptes som tyst begravde komprimeringsfunktionen i SSL så att den överhuvudtaget inte användes. Den enda som var skyddad mot sårbarheten var den anrika Internet Explorer, som aldrig använde SSL-komprimering.

POODLE

I oktober 2014 väckte Googles säkerhetsteam uppmärksamhet i säkerhetssamhället. De lyckades utnyttja en sårbarhet i SSL-protokollet som åtgärdades för mer än tio år sedan.

Det visade sig att trots att den senaste TLSv1.2 fungerade på servrarna, så lämnade många stöd för det föråldrade SSLv3 för bakåtkompatibilitet med Internet Explorer 6. Vi har redan pratat om nedgraderingsattacker, så ni kan tänka er vad som pågår. Ett välorganiserat sabotage av handskakningsprotokollet – och servrarna är redo att återvända till det gamla SSLv3, vilket i praktiken avskaffar de senaste 15 åren av säkerhetsforskning.

För historisk kontext, här är en kort sammanfattning av SSL-historien fram till version 2 av Matthew Green:

Transport Layer Security (TLS) är det viktigaste säkerhetsprotokollet på internet. [..] nästan varje transaktion som du genomför på internet beror på TLS. [..] Men TLS har inte alltid varit TLS. Protokollet började sitt liv i Netscape Communications under namnet "Secure Sockets Layer" eller SSL. Rykten säger att den första versionen av SSL var så fruktansvärd att utvecklarna samlade alla kodtryck och begravde dem på en hemlig soptipp i New Mexico. Följaktligen är den första offentliga versionen av SSL faktiskt versionen SSL 2. Den är ganska skräckinjagande, och [..] det var en produkt från mitten av 90-talet som moderna kryptografer betraktar som "mörka tider för kryptografi". Många av de mest avskyvärda kryptografiska attackerna som vi känner till idag hade ännu inte upptäckts. Som en följd var utvecklarna av SSLv2 i princip tvungna att känna sig fram i mörkret, och de stötte på många fruktansvärda monster – till deras förfäran och vår fördel, eftersom attackerna på SSLv2 gav ovärderliga lärdomar till nästa generation av protokoll.

Efter dessa händelser, år 1996, omarbetade det besvikna företaget Netscape SSL-protokollet från grunden. Resultatet blev SSL version 3, som åtgärdade flera kända säkerhetsproblem med sin föregångare.

Tyvärr för hackare innebär "flera" inte "alla". Sammantaget tillhandahöll SSLv3 alla nödvändiga byggstenar för att genomföra en Vodenä-attack. Protokollet använde en blockchiffer i CBC-läge och en osäker fyllningsschema (detta åtgärdades i TLS; därav behovet av en nedgraderingsattack). Om du minns fyllningsschemat i vår ursprungliga beskrivning av Vodenä-attacken, så är SSLv3:s schema mycket likt.

Men, tyvärr för hackare, betyder "liknande" inte "identisk". Fyllningsschemat för SSLv3 ser ut så här: "N godtyckliga byte, följt av nummer N". Försök i sådana förhållanden att välja en imaginär block av krypterad text och gå igenom alla steg i det ursprungliga Vodenä-schemat: du kommer att upptäcka att attacken framgångsrikt extraherar det sista bytet från motsvarande block av klartext, men inte längre. Att dekryptera varje 16:e byte av den krypterade texten är ett utmärkt trick, men det är ingen seger.

Konfronterad med misslyckandet valde Google-teamet det extrema alternativet: de växlade till en kraftfullare hotmodell — den som användes i CRIME. Anta att angriparen är ett skript som körs på offrets webbläsartab och att det kan extrahera sessionscookies, attacken förblir ändå imponerande. Även om den bredare hotmodellen är mindre realistisk, har vi redan sett i föregående avsnitt att just denna specifika modell är genomförbar.

Med tanke på dessa kraftfulla möjligheter för hackaren kan attacken nu fortsätta. Observera att angriparen vet var den krypterade sessionens cookie-fil visas i rubriken, och han kontrollerar längden på den föregående HTTP-förfrågan. Därför kan han manipulera HTTP-förfrågan så att den sista byten av cookien justeras med slutet av blocket. Nu är denna byte redo för avkodning. Man kan helt enkelt lägga till en symbol till begäran, och den näst sista byten av cookien förblir på samma plats och kan användas för att pröva detsamma. Attacken fortsätter på detta sätt tills cookie-filen är helt återställd. Detta kallas POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Som vi redan nämnt hade SSLv3 brister, men den skilde sig radikalt från sin föregångare, eftersom det läckande SSLv2 var en produkt från en annan tid. Där kunde man avbryta meddelandet i mitten: jag går med på det bara över min död förvandlades till jag går med på det; klient och server kunde mötas på internet, etablera förtroende och utbyta hemligheter inför ögonen på en angripare, som sedan lätt kunde utge sig för både den ena och den andra. Det fanns också problem med exportkryptografi, som vi nämnde när vi diskuterade FREAK. Det var kryptografiskt Sodom och Gomorra.

I mars 2016 samlades ett team av forskare från olika tekniska områden och gjorde en anmärkningsvärd upptäckte: SSLv2 används fortfarande i säkerhetssystem. Ja, angripare kunde inte längre sänka moderna TLS-sessioner till SSLv2, eftersom denna lucka stängdes efter FREAK och POODLE, men de kan fortfarande ansluta till servrar och initiera SSLv2-sessioner själva.

Du kanske frågar, vad bryr vi oss om vad de gör där? De har en sårbar session, men det borde inte påverka andra sessioner eller serverns säkerhet — eller hur? Tja, inte riktigt. Ja, så borde det vara i teorin. Men nej — för att generering av SSL-certifikat medför en viss börda, vilket gör att många servrar använder samma certifikat och därmed samma RSA-nycklar för TLS- och SSLv2-anslutningar. Vad som är ännu värre, på grund av en bugg i OpenSSL fungerade faktiskt alternativet 'Stäng av SSLv2' inte i denna populära implementation av SSL.

Det möjliggjorde en korsprotokollattack på TLS, som kallades DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, avkoda RSA med föråldrad och försvagad kryptering). Vi påminner om att detta inte är detsamma som en nedgraderingsattack; hackaren behöver inte agera som «man-in-the-middle» och behöver inte involvera klienten för att delta i en osäker session. Brottslingar initierar helt enkelt själva en osäker SSLv2-session med servern, attackerar den svaga protokollen och återställer den privata RSA-servernyckeln. Denna nyckel är också giltig för TLS-anslutningar, och från och med detta ögonblick kan ingen TLS-säkerhet rädda den från att hackas.

Men för att hacka krävs en fungerande attack mot SSLv2 som återställer inte bara specifik trafik utan även den hemliga RSA-servernyckeln. Även om detta är en komplex uppgift kunde forskarna välja vilken sårbarhet som helst som fullständigt stängdes efter SSLv2. I slutändan fann de ett lämpligt alternativ: Bleichenbacher-attacken, som vi nämnde tidigare och kommer att förklara mer detaljerat i nästa artikel. SSL och TLS är skyddade mot denna attack, men vissa slumpmässiga funktioner i SSL i kombination med korta nycklar i exportklasskryptering gjorde det möjligt för en viss implementering av DROWN.

Vid tidpunkten för publiceringen var 25 % av de största webbplatserna på internet sårbara för DROWN, och attacken kunde genomföras med blygsamma resurser, tillgängliga även för busiga hackare. För att extrahera serverns RSA-nyckel krävdes åtta timmars beräkningar och $440, och SSLv2 ändrade status från «föråldrad» till «radioaktiv».

Vänta, vad sägs om Heartbleed?

Det är inte en kryptografisk attack i den mening som beskrivits ovan; det handlar om en buffertöverflöd.

Låt oss ta en paus

Vi började med några grundläggande metoder: brute force, interpolation, nedgradering, korsprotokoll och förberäkningar. Sedan granskade vi en avancerad teknik, som kanske är huvudkomponenten i moderna kryptografiska attacker: orakelattacken. Vi har ägnat ganska mycket tid åt den - och förstått inte bara principen bakom, utan också de tekniska detaljerna i två specifika implementationer: Vadena-attacken på CBC-krypteringsläge och Kelsis attacker på krypteringsprotokoll med förkomprimering.

I sammanfattning av attacker mot nedgradering och med förhandsberäkningar, har vi kort beskrivit FREAK-attacken som använder båda metoderna, eftersom de målsatta sidorna faller tillbaka till svaga nycklar och sedan återanvänder samma nycklar. För nästa artikel har vi lämnat (mycket liknande) Logjam-attacken, som riktar sig mot algoritmer med offentliga nycklar.

Sedan granskade vi ytterligare tre exempel på tillämpningen av dessa principer. Först CRIME och POODLE: två attacker som förlitade sig på angriparens förmåga att injicera godtycklig klartext bredvid mål-klartexten, för att sedan studera serverns svar och sedan, med hjälp av orakelattackens metodologi, använda denna magra information för delvis återställning av klartexten. CRIME följde Kelsey-attackens väg mot SSL-komprimering, medan POODLE istället använde en variant av Vodehnäs attack mot CBC med samma effekt.

Därefter uppmärksammade vi den korsprotokollattack DROWN, som upprättar en anslutning med servern via den föråldrade protokollet SSLv2 och sedan återhåller serverns hemliga nycklar med hjälp av Bleichenbachers attack. Vid detta tillfälle har vi utelämnat de tekniska detaljerna för denna attack; precis som Logjam får den vänta tills vi noggrant har studerat kryptosystem med offentliga nycklar och deras sårbarheter.

I nästa artikel kommer vi att diskutera avancerade attacker - såsom meet-in-the-middle-metoden, differentialkryptoanalys och födelsedagsattacken. Vi gör ett kort besök vid attacker genom sidokanaler, och sedan börjar vi på det mest intressanta - kryptosystem med offentliga nycklar.

Källa: habr.com