När du hör ordet "kryptografi" kommer vissa människor ihåg sitt WiFi-lösenord, det gröna hänglåset bredvid adressen till deras favoritwebbplats och hur svårt det är att komma in i någon annans e-post. Andra minns en rad sårbarheter de senaste åren med talande förkortningar (DROWN, FREAK, POODLE...), snygga logotyper och en varning om att omedelbart uppdatera din webbläsare.

Kryptografi täcker allt, men essensen av i en annan. Poängen är att det finns en fin linje mellan enkelt och komplext. Vissa saker är lätta att göra, men svåra att sätta ihop igen, som att bryta ett ägg. Andra saker är lätta att göra men svåra att få tillbaka när en liten, viktig, avgörande del 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 användas i praktiken.

Under de senaste åren har samlingen av kryptografiska attacker förvandlats till ett zoo av flashiga logotyper, fyllda med formler från vetenskapliga tidningar, och gett upphov till en allmän dyster känsla av att allt är trasigt. Men i själva verket är många av attackerna baserade på några allmänna principer, och oändliga sidor med formler kokas ofta ner till lättbegripliga idéer.

I denna artikelserie kommer vi att titta på de olika typerna av kryptografiska attacker, med tonvikt på de grundläggande principerna. I allmänna termer och inte exakt i denna ordning, men vi kommer att täcka följande:

• Grundläggande strategier: brute force, frekvensanalys, interpolation, nedgradering och korsprotokoll.
• Varumärkessårbarheter: FREAK, BROTT, PUDDEL, DRUNKNA, Logjam.
• Avancerade strategier: orakelattacker (Vodenet attack, Kelsey attack); meet-in-the-middle-metod, födelsedagsattack, statistisk bias (differentiell kryptoanalys, integral kryptoanalys, etc.).
• Sidokanalattacker och deras nära anhöriga, metoder för misslyckandeanalys.
• Attacker på kryptografi med publik nyckel: kubrot, broadcast, relaterat meddelande, Coppersmith-attack, Pohlig-Hellman-algoritm, nummersil, Wiener-attack, Bleichenbacher-attack.

Denna speciella artikel täcker ovanstående material fram till Kelseys attack.

Grundläggande strategier

Följande attacker är enkla i den meningen att de nästan helt kan förklaras utan mycket tekniska detaljer. Låt oss förklara varje typ av attack i de enklaste termerna, utan att gå in på komplexa exempel eller avancerade användningsfall.

Vissa av dessa attacker har i stort sett blivit föråldrade och har inte använts på många år. Andra är oldtimers som fortfarande regelbundet smyger på intet ont anande utvecklare av kryptosystem på 21-talet. Eran av modern kryptografi kan anses ha börjat med tillkomsten av IBM DES, det första chiffer som stod emot alla attacker på denna lista.

Enkel brute force

Krypteringsschemat består av två delar: 1) krypteringsfunktionen, som tar ett meddelande (klartext) kombinerat med en nyckel, och sedan skapar ett krypterat meddelande - chiffertext; 2) en dekrypteringsfunktion som tar chiffertexten och nyckeln och producerar klartext. Både kryptering och dekryptering måste vara lätta att beräkna med nyckeln – och svåra att beräkna utan den.

Låt oss anta att vi ser chiffertexten och försöker dekryptera den utan ytterligare information (detta kallas en chiffertext-attack). Om vi ​​på något magiskt sätt hittar rätt nyckel kan vi enkelt verifiera att den verkligen är korrekt om resultatet är ett rimligt meddelande.

Observera att det finns två implicita antaganden här. Först vet vi hur man utför dekryptering, det vill säga hur kryptosystemet fungerar. Detta är ett standardantagande när man diskuterar kryptografi. Att dölja chiffrets implementeringsdetaljer för angripare kan verka som en extra säkerhetsåtgärd, men när angriparen väl tar reda på dessa detaljer försvinner denna extra säkerhet tyst och oåterkalleligt. Det är hur Kerchhoffs princip: Systemet som faller i fiendens händer bör inte orsaka olägenheter.

För det andra antar vi att rätt nyckel är den enda nyckeln som kommer att leda till en rimlig dekryptering. Detta är också ett rimligt antagande; det är tillfredsställt om chiffertexten är mycket längre än nyckeln och är läsbar. Detta är vanligtvis vad som händer i den verkliga världen, förutom enorma opraktiska nycklar eller andra sken som bäst lämnas åt sidan (om du inte gillar att vi har hoppat över förklaringen, se sats 3.8 här).

Med tanke på ovanstående uppstår en strategi: kontrollera alla möjliga nycklar. Detta kallas brute force, och en sådan attack kommer garanterat att fungera mot alla praktiska chiffer – så småningom. Till exempel räcker brute force för att hacka Caesar chiffer, ett gammalt chiffer där nyckeln är en bokstav i alfabetet, vilket innebär drygt 20 möjliga nycklar.

Tyvärr för kryptoanalytiker är att öka nyckelstorleken ett bra försvar mot brute force. När nyckelstorleken ökar, ökar antalet möjliga nycklar exponentiellt. Med moderna nyckelstorlekar är enkel brute force helt opraktisk. För att förstå vad vi menar, låt oss ta den snabbaste kända superdatorn i mitten av 2019: Summit från IBM, med toppprestanda på cirka 1017 operationer per sekund. Idag är den typiska nyckellängden 128 bitar, vilket innebär 2128 möjliga kombinationer. För att söka igenom alla nycklar kommer Summit-superdatorn att behöva tid som är ungefär 7800 gånger universums ålder.

Bör brute force betraktas som en historisk kuriosa? Inte alls: det är en nödvändig ingrediens i kryptanalyskokboken. Sällan är chiffer så svaga att de bara kan brytas genom en smart attack, utan att använda våld i en eller annan grad. Många framgångsrika hack använder en algoritmisk metod för att först försvaga målchifferet och sedan utföra en brute force attack.

Frekvensanalys

De flesta texter är inte trams. Till exempel, i engelska texter finns det många bokstäver "e" och artiklar "the"; i binära filer finns det många nollbyte som utfyllnad mellan informationsbitar. Frekvensanalys är varje attack som drar fördel av detta faktum.

Det kanoniska exemplet på ett chiffer som är sårbart för denna attack är det enkla substitutionschifferet. I detta chiffer är nyckeln en tabell med alla bokstäver ersatta. Till exempel ersätts 'g' med 'h', 'o' med j, så ordet 'gå' blir 'hj'. Detta chiffer är svårt att brute force eftersom det finns så många möjliga uppslagstabeller. Om du är intresserad av matematiken är den effektiva nyckellängden cirka 88 bitar: det vill säga
. Men frekvensanalys gör oftast jobbet snabbt.

Betrakta följande chiffertext bearbetad med ett enkelt substitutionschiffer:

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

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

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

Par XD upprepas i början av flera ord. I synnerhet kombinationen XDeLe tyder tydligt på ordet these eller there, så låt oss fortsätta:

theLe ALE UGLe thWNKE WN heAJeN ANF eALth DGLAtWG ÄN ALE FLeAUt GR WN OGQL ZDWBGEGZDO

Låt oss vidare anta det L motsvarar r, A - a och så vidare. Det kommer förmodligen att ta några försök, men jämfört med en full brute force attack, återställer denna attack den ursprungliga texten på nolltid:

det finns fler saker i himlen och jorden horatio än vad du drömmer om i din filosofi

För vissa är att lösa sådana "kryptogram" en spännande hobby.

Idén med frekvensanalys är mer grundläggande än det verkar vid första anblicken. Och det gäller mycket mer komplexa chiffer. Genom historien har olika chifferdesigner försökt motverka en sådan attack med "polyalfabetisk substitution". Här, under krypteringsprocessen, modifieras bokstavsersättningstabellen på komplexa men förutsägbara sätt som beror på nyckeln. Alla dessa chiffer ansågs svåra att bryta på en gång; och ändå besegrade blygsam frekvensanalys så småningom dem alla.

Det mest ambitiösa polyalfabetiska chifferet i historien, och förmodligen det mest kända, var Enigma-chifferet från andra världskriget. Det var relativt komplext jämfört med sina föregångare, men efter mycket hårt arbete knäckte brittiska kryptoanalytiker det med hjälp av frekvensanalys. Naturligtvis kunde de inte utveckla en elegant attack som den som visas ovan; de var tvungna att jämföra kända par av klartext och chiffertext (den så kallade "klartextattacken"), vilket till och med provocerade Enigma-användare att kryptera vissa meddelanden och analysera resultatet ("den valda klartextattacken"). Men detta gjorde inte de besegrade fiendearméernas och sänkta ubåtarnas öde lättare.

Efter denna triumf försvann frekvensanalys från kryptoanalysens historia. Chiffer i den moderna digitala tidsåldern är designade för att fungera med bitar, inte bokstäver. Ännu viktigare är att dessa chiffer designades med den mörka förståelsen av vad 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 krypteringssystemet verkade svårt: för att bevisa sitt värde måste det genomgå en skoningslös säkerhetsgranskning av många kryptoanalytiker som kommer att göra sitt bästa för att knäcka chiffret.

Preliminära beräkningar

Ta den hypotetiska staden Precom Heights, med 200 000 invånare. Varje hem i staden innehåller i genomsnitt 30 000 USD värdesaker, men inte mer än 50 000 USD Säkerhetsmarknaden i Precom monopoliseras av ACME Industries, som tillverkar de legendariska Coyote™-klassens dörrlås. Enligt expertanalys kan ett lås av Coyote-klass bara brytas av en mycket komplex hypotetisk maskin, vars skapande kräver cirka fem år och $50 000 i investeringar. Är staden säker?

Troligtvis nej. Så småningom dyker det upp en ganska ambitiös brottsling. Han kommer att resonera så här: "Ja, jag kommer att dra på mig stora initiala kostnader. Fem år av tålmodig väntan och 50 000 USD. Men när jag är klar har jag tillgång till all den här stadens rikedom. Om jag spelar mina kort rätt kommer den här investeringen att betala sig själv många gånger om.”

Detsamma gäller i kryptografi. Attacker mot ett visst chiffer är föremål för en hänsynslös kostnads-nyttoanalys. Om förhållandet är gynnsamt kommer attacken inte att inträffa. Men attacker som fungerar mot många potentiella offer på en gång lönar sig nästan alltid, i vilket fall bästa designpraxis är att anta att de startade från dag ett. Vi har i huvudsak en kryptografisk version av Murphys lag: "Allt som faktiskt kan bryta systemet kommer att bryta systemet."

Det enklaste exemplet på ett kryptosystem som är sårbart för en förberäkningsattack är ett konstant nyckellöst chiffer. Detta var fallet med Caesars chiffer, som helt enkelt flyttar varje bokstav i alfabetet tre bokstäver framåt (tabellen är loopad, så den sista bokstaven i alfabetet krypteras på tredje plats). Här kommer återigen Kerchhoffs princip in i bilden: när ett system väl har hackats hackas det för alltid.

Konceptet är enkelt. Även en nybörjare av kryptosystemutvecklare kommer sannolikt att känna igen hotet och förbereda sig därefter. Om man tittar på utvecklingen av kryptografi var sådana attacker olämpliga för de flesta chiffer, från de första förbättrade versionerna av Caesar-chifferet tills nedgången av polyalfabetiska chiffer. Sådana attacker återkom först med tillkomsten av den moderna eran av kryptografi.

Denna avkastning beror på två faktorer. För det första dök det äntligen upp tillräckligt komplexa kryptosystem, där möjligheten till exploatering efter hackning inte var uppenbar. För det andra blev kryptografi så utbrett att miljontals lekmän fattade beslut varje dag om var och vilka delar av kryptografin som skulle återanvändas. Det tog lite tid innan experter insåg riskerna och slog larm.

Kom ihåg precomputation-attacken: i slutet av artikeln kommer vi att titta på två verkliga kryptografiska exempel där den spelade en viktig roll.

Interpolation

Här är den berömda detektiven Sherlock Holmes, som utför en interpolationsattack på den olycklige Dr. Watson:

Jag gissade direkt att du hade kommit från Afghanistan... Min tankegång var följande: ”Den här mannen är läkare till sin typ, men han har en militär bäring. Alltså en militärläkare. Han har precis kommit från tropikerna - hans ansikte är mörkt, men det här är inte den naturliga nyansen på hans hud, eftersom hans handleder är mycket vitare. Ansiktet är utslitet - uppenbarligen har han lidit mycket och lidit av sjukdom. Han blev sårad i vänster hand - han håller den orörlig och lite onaturligt. Var i tropikerna kunde en engelsk militärläkare drabbas av svårigheter och bli sårad? Naturligtvis i Afghanistan." Hela tankegången tog inte ens en sekund. Och så jag sa att du kom från Afghanistan, och du blev förvånad.

Holmes kunde extrahera mycket lite information från varje bevis individuellt. Han kunde bara nå sin slutsats genom att betrakta dem alla tillsammans. En interpolationsattack fungerar på liknande sätt genom att undersöka kända klartext- och chiffertextpar som är resultatet av samma nyckel. Från varje par extraheras individuella observationer som möjliggör en allmän slutsats om nyckeln som kan dras. Alla dessa slutsatser är vaga och verkar värdelösa tills de plötsligt når en kritisk massa och leder till den enda möjliga slutsatsen: hur otroligt det än är så måste det vara sant. Efter detta avslöjas antingen nyckeln, eller så blir dekrypteringsprocessen så förfinad att den kan replikeras.

Låt oss illustrera med ett enkelt exempel hur interpolation fungerar. Låt oss säga att vi vill läsa vår fiendes personliga dagbok, Bob. Han krypterar varje nummer i sin dagbok med ett enkelt kryptosystem som han lärde sig om från en annons i tidningen "A Mock of Cryptography". Systemet fungerar så här: Bob väljer två nummer som han gillar: и . Från och med nu, för att kryptera vilket nummer som helst , räknar den ut . Till exempel om Bob valde и , sedan numret kommer att krypteras som .

Låt oss säga att den 28 december märkte vi att Bob skrapade något i sin dagbok. När han är klar, tar vi tyst upp den och tittar på det sista inlägget:

Datum: 235/520

Kära dagbok,

Idag var en bra dag. Genom 64 idag har jag en dejt med Alisa som bor i lägenhet 843. Jag tror verkligen att hon kan vara det 26!

Eftersom vi menar mycket allvar med att följa Bob på hans dejt (vi är båda 15 i det här scenariot), är det viktigt att känna till datumet och Alices adress. Lyckligtvis märker vi att Bobs kryptosystem är sårbart för en interpolationsattack. Vi kanske inte vet и , men vi vet dagens datum, så vi har två klartext-chiffertext-par. Det vet vi nämligen krypterad in Och - kl . Detta är vad vi kommer att skriva ner:

Eftersom vi är 15 år gamla känner vi redan till ett system av två ekvationer med två okända, vilket i det här läget är tillräckligt för att hitta и utan problem. Varje klartext-chiffertext-par sätter en begränsning på Bobs nyckel, och de två begränsningarna tillsammans är tillräckliga för att helt återställa nyckeln. I vårt exempel är svaret и (på , Alltså 26 i dagboken motsvarar ordet "den ena", det vill säga "den samme" - ca. körfält).

Interpolationsattacker är naturligtvis inte begränsade till sådana enkla exempel. Varje kryptosystem som reducerar till ett välförstått matematiskt objekt och en lista med parametrar riskerar en interpolationsattack – ju mer förståeligt objektet är, desto högre är risken.

Nykomlingar klagar ofta över att kryptografi är "konsten att designa saker så fula som möjligt." Interpolationsattacker är förmodligen till stor del skyldiga. Bob kan antingen använda en elegant matematisk design eller hålla sin dejt med Alice privat – men tyvärr kan du oftast inte ha det åt båda hållen. Detta kommer att bli mycket tydligt när vi så småningom kommer till ämnet kryptografi med offentliga nyckel.

Korsprotokoll/nedgradering

I Now You See Me (2013) försöker en grupp illusionister lura bort den korrupta försäkringsmagnaten Arthur Tressler från hela sin förmögenhet. För att få tillgång till Arthurs bankkonto måste illusionisterna antingen ange hans användarnamn och lösenord eller tvinga honom att dyka upp personligen på banken och delta i upplägget.

Båda alternativen är mycket svåra; Killarna är vana vid att uppträda på scen och att inte delta i underrättelseoperationer. Så de väljer det tredje möjliga alternativet: deras medbrottsling ringer banken och låtsas vara Arthur. Banken ställer flera frågor för att verifiera identiteten, såsom farbrors namn och namnet på det första husdjuret; våra hjältar i förväg de extraherar enkelt denna information från Arthur med hjälp av smart social ingenjörskonst. Från och med denna tidpunkt spelar utmärkt lösenordssäkerhet inte längre någon roll.

(Enligt en urban legend som vi personligen har verifierat och verifierat, stötte kryptografen Eli Beaham en gång på en bankkassör som insisterade på att ställa en säkerhetsfråga. När kassan frågade efter namnet på sin mormors mormor började Beaham diktera: "Kapital X, litet y, tre...").

Det är samma sak i kryptografi, om två kryptografiska protokoll används parallellt för att skydda samma tillgång, och det ena är mycket svagare än det andra. Det resulterande systemet blir sårbart för en cross-protocol attack, där ett svagare protokoll attackeras för att komma till priset utan att röra det starkare.

I vissa komplexa fall räcker det inte att bara kontakta servern med ett svagare protokoll, utan kräver ofrivilligt deltagande av en legitim klient. Detta kan organiseras med hjälp av den så kallade nedgraderingsattacken. För att förstå denna attack, låt oss anta att våra illusionister har en svårare uppgift än i filmen. Låt oss anta att en bankanställd (kassörska) och Arthur stötte på några oförutsedda omständigheter, vilket resulterade i följande dialog:

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

Kassör: Bra. Ta en titt på din personliga hemliga kodbok, sidan 28, ord 3. Alla följande meddelanden kommer att krypteras med detta specifika ord som nyckel. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV...

Rånare: Hej, hej, vänta, vänta. Är detta verkligen nödvändigt? Kan vi inte bara prata som vanliga människor?

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

Rånare: Jag bara... titta, jag hade en usel dag, okej? Jag är en VIP-klient och jag är inte på humör att gräva igenom dessa dumma kodböcker.

Kassör: Bra. Om du insisterar, mr Tressler. Vad vill du?

Rånare: Snälla, jag skulle vilja donera alla mina pengar till Arthur Tressler National Victims Fund.

(Paus).

Kassör: Är det klart nu. Ange din PIN-kod för stora transaktioner.

Rånare: Min vad?

Kassör: På din personliga begäran kräver transaktioner av denna storlek en PIN-kod för stora transaktioner. Den här koden fick du när du öppnade ditt konto.

Rånare:... Jag tappade det. Är detta verkligen nödvändigt? Kan du inte bara godkänna affären?

Kassör: Nej. Jag är ledsen, mr Tressler. Återigen, detta är säkerhetsåtgärden du bad om. Om du vill kan vi skicka en ny PIN-kod till din brevlåda.

Våra hjältar skjuter upp operationen. De avlyssnar flera av Tresslers stora transaktioner i hopp om att höra PIN-koden; men varje gång förvandlas konversationen till kodat skratt innan något intressant sägs. Äntligen, en vacker dag, sätts planen i verket. De väntar tålmodigt på det ögonblick när Tressler måste göra en stor transaktion över telefon, han går på linjen, och sedan...

Tressler: Hallå. Jag skulle vilja slutföra en fjärrtransaktion, tack.

Kassör: Bra. Ta en titt på din personliga hemliga kodbok, sida...

(Tjuven trycker på knappen; kassörskans röst förvandlas till ett obegripligt ljud).

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

Tressler: Förlåt, jag förstod inte riktigt. Igen? På vilken sida? Vilket ord?

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

Tressler: Vad?

Kassör: Ord nummer tjugo @$#@$#%#$.

Tressler: Allvarligt! Redan tillräckligt! Du och ditt säkerhetsprotokoll är någon slags cirkus. Jag vet att du bara kan prata med mig som vanligt.

Kassör: Jag rekommenderar inte…

Tressler: Och jag råder dig inte att slösa bort min tid. Jag vill inte höra mer om detta förrän du åtgärdat dina telefonlinjeproblem. Kan vi slutföra den här affären eller inte?

Kassör:… Ja. Bra. Vad vill du?

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

Kassör: En minut tack. Det är en stor sak. Ange din PIN-kod för stora transaktioner.

Tressler: Vad? Åh, precis. 1234.

Här är en attack nedåt. Det svagare protokollet "tala bara direkt" var tänkt som alternativ vid nödsituation. Och ändå är vi här.

Du kanske undrar vem som vid sitt fulla sinne skulle designa ett riktigt "säkert tills du frågar något annat"-system som det som beskrivs ovan. Men precis som en fiktiv bank tar risker för att behålla kunder som inte gillar kryptografi, dras system i allmänhet ofta mot krav som är likgiltiga eller till och med rent av säkerhetsfientliga.

Detta är exakt vad som hände med SSLv2-protokollet 1995. Den amerikanska regeringen har länge börjat se kryptografi som ett vapen som bäst hålls borta från utländska och inhemska fiender. Kodbitar godkändes individuellt för export från USA, ofta med villkoret att algoritmen medvetet försvagades. Netscape, utvecklaren av den mest populära webbläsaren, Netscape Navigator, fick tillstånd för SSLv2 endast med den naturligt sårbara 512-bitars RSA-nyckeln (och 40-bitars för RC4).

I slutet av millenniet hade reglerna lättat och tillgång till modern kryptering blev allmänt tillgänglig. Men klienter och servrar har stödt försvagad "export"-kryptering i flera år på grund av samma tröghet som upprätthåller stöd för alla äldre system. Klienter trodde att de kunde stöta på en server som inte stödde något annat. Servrarna gjorde samma sak. Naturligtvis dikterar SSL-protokollet att klienter och servrar aldrig ska använda ett svagt protokoll när ett bättre är tillgängligt. Men samma utgångspunkt gällde Tressler och hans bank.

Denna teori hittade sin väg in i två högprofilerade attacker som skakade säkerheten för SSL-protokollet 2015, båda upptäckta av Microsofts forskare och INRIA. Först avslöjades detaljer om FREAK-attacken i februari, följt tre månader senare av en annan liknande attack som heter Logjam, som vi kommer att diskutera mer i detalj när vi går vidare till attacker mot kryptografi med publik nyckel.

Sårbarhet FREAK (även känd som "Smack TLS") uppdagades när forskare analyserade TLS klient/server-implementeringar och upptäckte en nyfiken bugg. I dessa implementeringar, om klienten inte ens ber om att använda svag exportkryptografi, men servern fortfarande svarar med sådana nycklar, säger klienten "Oh well" och byter till en svag chiffersvit.

Vid den tiden ansågs exportkryptering allmänt vara föråldrad och förbjuden, så attacken kom som en total chock och påverkade många viktiga domäner, inklusive Vita huset, IRS och NSA-webbplatserna. Ännu värre, det visar sig att många sårbara servrar optimerar prestanda genom att återanvända samma nycklar snarare än att generera nya för varje session. Detta gjorde det möjligt, efter att ha nedgraderat protokollet, att utföra en pre-computation attack: att knäcka en nyckel förblev relativt dyrt ($100 och 12 timmar vid tidpunkten för publicering), men den praktiska kostnaden för att attackera anslutningen reducerades avsevärt. Det räcker att välja servernyckeln en gång och knäcka krypteringen för alla efterföljande anslutningar från det ögonblicket.

Och innan vi går vidare finns det en avancerad attack som måste nämnas...

Oracle attack

Moxie Marlinspike mest känd som fadern till den plattformsoberoende kryptomeddelandeappen Signal; men vi gillar personligen en av hans mindre kända innovationer - principen om kryptografisk undergång (Kryptografisk undergångsprincip). För att parafrasera något kan vi säga detta: "Om protokollet fungerar några utför en kryptografisk operation på ett meddelande från en potentiellt skadlig källa och beter sig annorlunda beroende på resultatet, är det dömt." Eller i en skarpare form: "Ta inte information från fienden för bearbetning, och om du måste, visa åtminstone inte resultatet."

Låt oss lämna buffertspill, kommandoinjektioner och liknande åt sidan; de ligger utanför ramen för denna diskussion. Brott mot "doomprincipen" leder till allvarliga kryptografihack på grund av att protokollet beter sig exakt som förväntat.

Som ett exempel, låt oss ta en fiktiv design med ett sårbart substitutionschiffer och sedan demonstrera en möjlig attack. Även om vi redan har sett en attack på ett substitutionschiffer med hjälp av frekvensanalys, är det inte bara "ett annat sätt att bryta samma chiffer." Tvärtom är orakelattacker en mycket modernare uppfinning, tillämpbar på många situationer där frekvensanalys misslyckas, och vi kommer att se en demonstration av detta i nästa avsnitt. Här väljs det enkla chifferet endast för att göra exemplet tydligare.

Så Alice och Bob kommunicerar med hjälp av ett enkelt substitutchiffer med en nyckel som bara de känner till. De är mycket strikta när det gäller längden på meddelanden: de är exakt 20 tecken långa. Så de kom överens om att om någon ville skicka ett kortare meddelande, skulle de lägga till lite dummytext i slutet av meddelandet för att göra det exakt 20 tecken. Efter lite diskussion beslutade de att de bara skulle acceptera följande dummytexter: a, bb, ccc, dddd etc. Således är en dummytext av vilken längd som helst känd.

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 dummytext. Om så inte är fallet svarar de med ett lämpligt felmeddelande. Om textlängden och dummytexten är ok, läser mottagaren själva meddelandet och skickar ett krypterat svar.

Under attacken utger sig angriparen som Bob och skickar falska meddelanden till Alice. Meddelanden är fullständigt nonsens - angriparen har inte nyckeln, och kan därför inte förfalska ett meningsfullt meddelande. Men eftersom protokollet bryter mot undergångsprincipen kan en angripare fortfarande få Alice att avslöja nyckelinformationen, som visas nedan.

Rånare: PREWF ZHJKL MMMN. LA

Alice: Ogiltig dummytext.

Rånare: PREWF ZHJKL MMMN. LB

Alice: Ogiltig dummytext.

Rånare: PREWF ZHJKL MMMN. LC

Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Inbrottstjuven har ingen aning om vad Alice just sa, men noterar att symbolen C måste överensstämma a, eftersom Alice accepterade dummytexten.

Rånare: REWF ZHJKL MMMN. LAA

Alice: Ogiltig dummytext.

Rånare: REWF ZHJKL MMMN. LBB

Alice: Ogiltig dummytext.

Efter ett antal försök...

Rånare: REWF ZHJKL MMMN. LGG

Alice: Ogiltig dummytext.

Rånare: 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 b eftersom Alice accepterade dummytexten.

Och så vidare tills angriparen vet innebörden av varje karaktär.

Vid första anblicken liknar metoden en vald klartextattack. I slutändan väljer angriparen chiffertexterna och servern bearbetar dem lydigt. Den största skillnaden som gör dessa attacker genomförbara i den verkliga världen är att angriparen inte behöver tillgång till själva transkriptionen – ett serversvar, även ett så ofarligt som "Ogiltig dummytext", är tillräckligt.

Även om denna speciella attack är lärorik, häng dig inte för mycket på detaljerna i "dummy text"-schemat, det specifika kryptosystem som används eller den exakta sekvensen av meddelanden som skickas av angriparen. Grundtanken är hur Alice reagerar olika utifrån klartextens egenskaper, och gör det utan att verifiera att motsvarande chiffertext faktiskt kom från en betrodd part. Således låter Alice angriparen pressa hemlig information ur hennes svar.

Det finns mycket som kan ändras i detta scenario. Symbolerna som Alice reagerar på, eller själva skillnaden i hennes beteende, eller till och med vilket kryptosystem som används. Men principen kommer att förbli densamma, och attacken som helhet kommer att förbli livskraftig i en eller annan form. Den grundläggande implementeringen av denna attack hjälpte till att avslöja flera säkerhetsbuggar, som vi kommer att titta på inom kort; men först finns det några teoretiska lärdomar att dra. Hur använder man detta fiktiva "Alice-manus" i en attack som kan fungera på ett riktigt modernt chiffer? Är detta ens möjligt, även i teorin?

1998 svarade den schweiziske kryptografen Daniel Bleichenbacher jakande på denna fråga. Han demonstrerade en orakelattack på det allmänt använda kryptosystemet RSA med offentlig nyckel, med hjälp av ett specifikt meddelandeschema. I vissa RSA-implementationer svarar servern med olika felmeddelanden beroende på om klartexten matchar schemat eller inte; detta räckte för att genomföra attacken.

Fyra år senare, 2002, demonstrerade den franske kryptografen Serge Vaudenay en orakelattack nästan identisk med den som beskrivs i Alice-scenariot ovan – förutom att han istället för ett fiktivt chiffer bröt en hel respektabel klass av moderna chiffer som människor faktiskt används. I synnerhet riktar Vaudenays attack in på chiffer med fast indatastorlek ("blockchiffer") när de används i så kallat "CBC-krypteringsläge" och med ett visst populärt utfyllnadsschema, i princip likvärdigt med det i Alice-scenariot.

Även 2002, den amerikanske kryptografen John Kelsey - medförfattare Tvåfiskar — föreslog olika orakelattacker på system som komprimerar meddelanden och sedan krypterar dem. Mest anmärkningsvärt bland dessa var en attack som utnyttjade det faktum att det ofta är möjligt att sluta sig till den ursprungliga längden på klartexten från chiffertextens längd. I teorin tillåter detta en orakelattack som återställer delar av den ursprungliga klartexten.

Nedan ger vi en mer detaljerad beskrivning av Vaudenay- och Kelsey-attackerna (vi kommer att ge en mer detaljerad beskrivning av Bleichenbacher-attacken när vi går vidare till attacker mot publik nyckelkryptografi). Trots våra bästa ansträngningar blir texten något teknisk; så om ovanstående är tillräckligt för dig, hoppa över de två kommande avsnitten.

Vodenes attack

För att förstå Vaudenay-attacken måste vi först prata lite mer om blockchiffer och krypteringslägen. Ett "blockchiffer" är, som nämnts, ett chiffer som tar en nyckel och en ingång av en viss fast längd ("blocklängd") och producerar ett krypterat block av samma längd. Blockchiffer används ofta och anses vara relativt säkra. Det nu pensionerade DES, som anses vara det första moderna chifferet, var ett blockchiffer. Som nämnts ovan gäller samma sak för AES, som används flitigt idag.

Tyvärr har blockchiffer en påfallande svaghet. Den typiska blockstorleken är 128 bitar eller 16 tecken. Uppenbarligen kräver modern kryptografi att man arbetar med större indata, och det är här krypteringslägen kommer in i bilden. Krypteringsläget är i grunden ett hack: det är ett sätt att på något sätt tillämpa ett blockchiffer som bara accepterar indata av en viss storlek till inmatning av en godtycklig längd.

Vodenes attack är fokuserad på det populära CBC-läget (Cipher Block Chaining). Attacken behandlar det underliggande blockchifferet som en magisk, ogenomtränglig svart låda och kringgår helt dess säkerhet.

Här är ett diagram som visar hur CBC-läge fungerar:

Det inringade pluset betecknar XOR-operationen (exklusiv ELLER). Till exempel tas det andra blocket av chiffertext emot:

1. Genom att utföra en XOR-operation på det andra klartextblocket med det första chiffertextblocket.
2. Kryptera det resulterande blocket med ett blockchiffer med hjälp av en nyckel.

Eftersom CBC använder så mycket av den binära XOR-operationen, låt oss ta en stund för att komma ihåg några av dess egenskaper:

• Idempotens:
• Kommutativitet:
• Associativitet:
• Självreversibilitet:
• Bytestorlek: byte n av = (byte n av ) (byte n av )

Vanligtvis innebär dessa egenskaper att om vi har en ekvation som involverar XOR-operationer och en okänd, kan den lösas. Till exempel om vi vet det med det okända och berömd и , då kan vi lita på ovan nämnda egenskaper för att lösa ekvationen för . Genom att tillämpa XOR på båda sidor av ekvationen med , vi får . Allt detta kommer att bli mycket relevant om ett ögonblick.

Det finns två mindre skillnader och en stor skillnad mellan vårt Alice-scenario och Vaudenays attack. Två mindre:

• I manuset förväntade sig Alice att klartexter skulle sluta med karaktärerna a, bb, ccc och så vidare. I Wodene-attacken förväntar sig offret istället att klartexterna slutar N gånger med N-byten (det vill säga hexadecimala 01 eller 02 02, eller 03 03 03, och så vidare). Detta är en ren kosmetisk skillnad.
• I Alice-scenariot var det lätt att avgöra om Alice hade accepterat meddelandet genom svaret "Felaktig dummy-text". I Vodenes attack krävs mer analys och exakt implementering på offrets sida är viktigt; men låt oss för korthetens skull ta det som givet att denna analys fortfarande är möjlig.

Huvudskillnad:

• Eftersom vi inte använder samma kryptosystem kommer relationen mellan de angriparkontrollerade chiffertextbytena och hemligheterna (nyckel och klartext) uppenbarligen att vara annorlunda. Därför måste angriparen använda en annan strategi när han skapar chiffertexter och tolkar serversvar.

Denna stora skillnad är den sista pusselbiten för att förstå Vaudenay-attacken, så låt oss ta en stund att fundera över varför och hur en orakelattack mot CBC kan utföras i första hand.

Anta att vi får en CBC-chiffertext på 247 block, och vi vill dekryptera den. Vi kan skicka falska meddelanden till servern, precis som vi kunde skicka falska meddelanden till Alice tidigare. Servern kommer att dekryptera meddelandena åt oss, men kommer inte att visa dekrypteringen - istället, igen, som med Alice, kommer servern bara att rapportera en bit information: om klartexten har giltig utfyllnad eller inte.

Tänk på att i Alices scenario hade vi följande relationer:

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

Låt oss kalla detta "Alices ekvation." Vi kontrollerade chiffertexten; servern (Alice) läckte vag information om den mottagna klartexten; och detta gjorde det möjligt för oss att härleda information om den sista faktorn - nyckeln. I analogi, om vi kan hitta en sådan koppling för CBC-skriptet, kan vi kanske extrahera hemlig information där också.

Lyckligtvis finns det verkligen relationer där ute som vi kan använda. Betrakta utdata från det sista anropet för att dekryptera ett blockchiffer och beteckna denna utdata som . Vi betecknar också block av klartext och chiffertextblock . Ta en titt på CBC-diagrammet och lägg märke till vad som händer:

Låt oss kalla detta "CBC-ekvationen."

I Alices scenario kunde vi, genom att övervaka chiffertexten och titta på motsvarande klartextläcka, genomföra en attack som återställde den tredje termen i ekvationen – nyckeln. I CBC-scenariot övervakar vi även chiffertexten och observerar informationsläckor på motsvarande klartext. Om analogin håller kan vi få information om .

Låt oss anta att vi verkligen återställde , vad händer då? Tja, då kan vi skriva ut hela det sista blocket av klartext på en gång (), helt enkelt genom att gå in (som vi har) och
mottagen in i CBC-ekvationen.

Nu när vi är optimistiska om den övergripande attackplanen är det dags att räkna ut detaljerna. Var uppmärksam på exakt hur klartextinformation läcker ut på servern. I Alices skript inträffade läckan eftersom Alice bara skulle svara med rätt meddelande om $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ slutade med raden a (eller bb, och så vidare, men chanserna att dessa tillstånd utlöses av en slump var mycket små). I likhet med CBC accepterar servern utfyllnaden om och endast om slutar på hexadecimal 01. Så låt oss prova samma knep: att skicka falska chiffertexter med våra egna falska värden tills servern accepterar fyllningen.

När servern accepterar en utfyllnad för ett av våra falska meddelanden betyder det att:

Nu använder vi egenskapen byte-byte XOR:

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

Detta ger oss också den sista byten i det sista klartextblocket via CBC-ekvationen och byte-by-byte-egenskapen.

Vi skulle kunna lämna det där och vara nöjda med att vi har genomfört ett angrepp på ett teoretiskt starkt chiffer. Men i själva verket kan vi göra mycket mer: vi kan faktiskt återställa all text. Detta kräver ett trick som inte fanns i Alices originalmanus och som inte krävs för orakelattacken, men det är ändå värt att lära sig.

För att förstå det, notera först att resultatet av att mata ut det korrekta värdet av den sista byten är vi har en ny förmåga. När vi nu smider chiffertexter kan vi manipulera den sista byten i motsvarande klartext. Återigen, detta är relaterat till CBC-ekvationen och egenskapen byte-för-byte:

Eftersom vi nu känner till den andra termen kan vi använda vår kontroll över den första för att kontrollera den tredje. Vi räknar helt enkelt ut:

Vi kunde inte göra detta tidigare eftersom vi inte hade den sista byten ännu .

Hur kommer detta att hjälpa oss? Antag att vi nu skapar alla chiffertexter så att den sista byten i motsvarande klartexter är lika med 02. Servern accepterar nu bara utfyllnad om klartexten slutar med 02 02. Eftersom vi korrigerade den sista byten kommer detta bara att hända om den näst sista byten i klartexten också är 02. Vi fortsätter att skicka falska chiffertextblock, ändrar den näst sista byten, tills servern accepterar utfyllnaden för en av dem. Vid det här laget får vi:

Och vi återställer den näst sista byten precis som den förra återställdes. Vi fortsätter i samma anda: vi korrigerar de två sista byten i klartexten till 03 03, upprepar vi denna attack för den tredje byten från slutet och så vidare, och slutligen återställs helt .

Hur är det med resten av texten? Observera att värdet är faktiskt $inline$text{BLOCK_DECRYPT}(text{nyckel},C_{247})$inline$. Vi kan sätta vilket annat block istället , och attacken kommer fortfarande att lyckas. Faktum är att vi kan be servern att göra $inline$text{BLOCK_DECRYPT}$inline$ för alla data. Vid det här laget är spelet över - vi kan dekryptera vilken chiffertext som helst (ta en titt på CBC-dekrypteringsdiagrammet för att se detta; och notera att IV är offentlig).

Denna speciella metod spelar en avgörande roll i orakelattacken som vi kommer att stöta på senare.

Kelseys attack

Vår sympatiske John Kelsey lade fram principerna bakom många möjliga attacker, inte bara detaljerna i en specifik attack mot ett specifikt chiffer. Hans Årets 2002 artikel är en studie av möjliga attacker på krypterad komprimerad data. Trodde du att informationen om att datan komprimerades före kryptering inte räckte för att utföra en attack? Det visar sig att det räcker.

Detta överraskande resultat beror på två principer. För det första finns det en stark korrelation mellan längden på klartexten och längden på chiffertexten; för många chiffer exakt likhet. 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 "brusighet" i klartexten, det vill säga andelen icke-repeterande tecken (den tekniska termen är "hög entropi" ).

För att se principen i praktiken, överväg två klartexter:

Klartext 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Klartext 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Låt oss anta att båda klartexterna är komprimerade och sedan krypterade. Du får två resulterande chiffertexter och måste gissa vilken chiffertext som matchar vilken klartext:

Chiffertext 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Chiffertext 2: DWKJZXYU

Svaret är tydligt. Bland klartexterna kunde endast klartext 1 komprimeras till den magra längden av den andra chiffertexten. Vi kom på detta utan att veta något om komprimeringsalgoritmen, krypteringsnyckeln eller till och med själva chiffret. Jämfört med hierarkin av möjliga kryptografiska attacker är det här ganska galet.

Kelsey påpekar vidare att under vissa ovanliga omständigheter kan denna princip också användas för att utföra en orakelattack. I synnerhet beskriver den hur en angripare kan återställa den hemliga klartexten om han kan tvinga servern att kryptera formulärdata (klartexten följt av medan han har kontroll och kan på något sätt kontrollera längden på det krypterade resultatet.

Återigen, som andra orakelattacker, har vi förhållandet:

Återigen kontrollerar vi en term (), ser vi ett litet läckage av information om en annan medlem (chiffertext) och försöker återställa den sista (klartext). Trots analogin är detta en något ovanlig situation jämfört med andra orakelattacker vi har sett.

För att illustrera hur en sådan attack kan fungera, låt oss använda ett fiktivt komprimeringsschema som vi precis kom på: TOYZIP. Den letar efter textrader som har förekommit tidigare i texten och ersätter dem med tre platshållarbyte som anger var man kan hitta en tidigare instans av raden och hur många gånger den förekommer där. Till exempel linjen helloworldhello kan komprimeras till helloworld[00][00][05] 13 byte lång jämfört med de ursprungliga 15 byte.

Anta att en angripare försöker återställa klartexten i ett formulär password=..., där lösenordet i sig är okänt. Enligt Kelseys attackmodell kan en angripare be servern att komprimera och sedan kryptera formulärmeddelanden (klartext följt av ) var  - fri text. När servern har slutat fungera rapporterar den längden på resultatet. Attacken går så här:

Rånare: Vänligen komprimera och kryptera klartexten utan någon utfyllnad.

Server: Resultatlängd 14.

Rånare: Komprimera och kryptera den klartext som läggs till password=a.

Server: Resultatlängd 18.

Knäckaren noterar: [original 14] + [tre byte som ersatte password=] + a

Rånare: Komprimera och kryptera den klartext som läggs till password=b.

Server: Resultatlängd 18.

Rånare: Komprimera och kryptera den klartext som läggs till password=с.

Server: Resultatlängd 17.

Knäckaren noterar: [original 14] + [tre byte som ersatte password=c]. Detta förutsätter att den ursprungliga klartexten innehåller strängen password=c. Det vill säga att lösenordet börjar med en bokstav c

Rånare: Komprimera och kryptera den klartext som läggs till password=сa.

Server: Resultatlängd 18.

Knäckaren noterar: [original 14] + [tre byte som ersatte password=с] + a

Rånare: Komprimera och kryptera den klartext som läggs till password=сb.

Server: Resultatlängd 18.

(… Någon gång senare…)

Rånare: Komprimera och kryptera den klartext som läggs till password=со.

Server: Resultatlängd 17.

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

Och så vidare tills hela lösenordet är återställt.

Läsaren skulle få förlåtelse för att tro att detta är en rent akademisk övning och att ett sådant attackscenario aldrig skulle uppstå i den verkliga världen. Tyvärr, som vi snart kommer att se, är det bättre att inte ge upp kryptografi.

Varumärkes sårbarheter: BROTT, PUDDEL, DRUNKNING

Slutligen, efter att ha studerat teorin i detalj, kan vi se hur dessa tekniker tillämpas i verkliga kryptografiska attacker.

BROTTSLIGHET

Om attacken är riktad mot offrets webbläsare och nätverk blir en del lättare och en del svårare. Till exempel är det lätt att se offrets trafik: sitt bara med honom på samma kafé med WiFi. Av denna anledning rekommenderas i allmänhet potentiella offer (dvs alla) att använda en krypterad anslutning. Det kommer att bli svårare, men fortfarande möjligt, att göra HTTP-förfrågningar på uppdrag av offret till någon tredje parts webbplats (till exempel Google). Angriparen måste locka offret till en skadlig webbsida med ett skript som gör begäran. Webbläsaren tillhandahåller automatiskt motsvarande sessionscookie.

Det här verkar fantastiskt. Om Bob gick till evil.com, kan skriptet på den här webbplatsen bara be Google att maila Bobs lösenord till [email protected]? Tja, i teorin ja, men i verkligheten nej. Det här scenariot kallas en förfalskningsattack för begäranden över flera platser (Förfalskning av begäran över flera platser, CSRF), och det var populärt runt mitten av 90-talet. Idag om evil.com försöker det här tricket, kommer Google (eller någon webbplats med självrespekt) vanligtvis att svara: "Bra, men din CSRF-token för den här transaktionen kommer att vara... um... три триллиона и семь. Vänligen upprepa detta nummer." Moderna webbläsare har något som kallas "same-origin policy" där skript på webbplats A inte har tillgång till information som skickas av webbplats B. Så skriptet på evil.com kan skicka förfrågningar till google.com, men kan inte läsa svaren eller faktiskt slutföra transaktionen.

Vi måste betona att om inte Bob använder en krypterad anslutning är alla dessa skydd meningslösa. En angripare kan helt enkelt läsa Bobs trafik och återställa Googles sessionscookie. Med denna cookie kommer han helt enkelt att öppna en ny Google-flik utan att lämna sin egen webbläsare och imitera Bob utan att stöta på irriterande policyer för samma ursprung. Men tyvärr för en inbrottstjuv blir detta mindre och mindre vanligt. Internet som helhet har länge förklarat krig mot okrypterade anslutningar, och Bobs utgående trafik är förmodligen krypterad, vare sig han gillar det eller inte. Dessutom, från början av implementeringen av protokollet, var trafik också krympte före kryptering; detta var vanlig praxis för att minska latensen.

Det är här det spelar in BROTTSLIGHET (Compression Ratio Infoleak Made Easy, enkelt läckage genom kompressionsförhållandet). Sårbarheten avslöjades i september 2012 av säkerhetsforskarna Juliano Rizzo och Thai Duong. Vi har redan undersökt hela den teoretiska grunden, vilket gör att vi kan förstå vad de gjorde och hur. En angripare kan tvinga Bobs webbläsare att skicka förfrågningar till Google och sedan lyssna på svaren på det lokala nätverket i en komprimerad, krypterad form. Därför har vi:

Här styr angriparen begäran och har tillgång till trafiksniffaren, inklusive paketstorleken. Kelseys fiktiva scenario kom till liv.

För att förstå teorin skapade författarna till CRIME en exploatering som kan stjäla sessionscookies för ett brett utbud av webbplatser, inklusive Gmail, Twitter, Dropbox och Github. Sårbarheten påverkade de flesta moderna webbläsare, vilket resulterade i att patchar släpptes som tyst begravde komprimeringsfunktionen i SSL så att den inte skulle användas alls. Den enda som skyddades från sårbarheten var den ärevördiga Internet Explorer, som aldrig använde SSL-komprimering alls.

PUDEL

I oktober 2014 gjorde Googles säkerhetsteam vågor i säkerhetsgemenskapen. De kunde utnyttja en sårbarhet i SSL-protokollet som hade korrigerats för mer än tio år sedan.

Det visar sig att medan servrarna kör den skinande nya TLSv1.2, har många lämnat stöd för den äldre SSLv3 för bakåtkompatibilitet med Internet Explorer 6. Vi har redan pratat om nedgraderingsattacker, så du kan föreställa dig vad som händer. Ett välorganiserat sabotage av handskakningsprotokollet och servrarna är redo att återvända till gamla goda SSLv3, vilket i stort sett upphäver de senaste 15 årens säkerhetsforskning.

För historiska sammanhang, här är en kort sammanfattning av historien om SSL upp till version 2 från Matthew Green:

Transport Layer Security (TLS) är det viktigaste säkerhetsprotokollet på Internet. [..] nästan varje transaktion du gör på Internet beror på TLS. [..] Men TLS var inte alltid TLS. Protokollet började sitt liv i Netscape Communications kallas "Secure Sockets Layer" eller SSL. Rykten säger att den första versionen av SSL var så hemsk att utvecklarna samlade in alla utskrifter av koden och grävde ner dem på en hemlig soptipp i New Mexico. Som en konsekvens är den första allmänt tillgängliga versionen av SSL faktiskt version SSL 2. Det är ganska skrämmande, och [..] det var en produkt från mitten av 90-talet, som moderna kryptografer betraktar som "kryptografins mörka åldrar" Många av de mest avskyvärda kryptografiska attackerna vi känner till idag har ännu inte upptäckts. Som ett resultat fick utvecklarna av SSLv2-protokollet i huvudsak famla sig fram i mörkret, och de stod inför massor av hemska monster - till deras förtret och vår fördel, eftersom attackerna på SSLv2 gav ovärderliga lärdomar för nästa generations protokoll.

Efter dessa händelser, 1996, gjorde ett frustrerat Netscape om SSL-protokollet från början. Resultatet blev SSL version 3, vilket fixade flera kända säkerhetsproblem från sin föregångare.

Lyckligtvis för inbrottstjuvar betyder "några" inte "alla". Sammantaget tillhandahöll SSLv3 alla nödvändiga byggstenar för att starta en Vodene-attack. Protokollet använde ett CBC-lägesblockchiffer och ett osäkert utfyllnadsschema (detta korrigerades i TLS; därav behovet av en nedgraderingsattack). Om du kommer ihåg utfyllnadsschemat i vår ursprungliga beskrivning av Vaudenay-attacken, är SSLv3-schemat väldigt likt.

Men tyvärr för inbrottstjuvar betyder "liknande" inte "identiskt". SSLv3-utfyllnadsschemat är "N slumpmässiga byte följt av siffran N". Försök, under dessa förhållanden, att välja ett tänkt block med chiffertext och gå igenom alla steg i Vaudenes ursprungliga schema: du kommer att upptäcka att attacken framgångsrikt extraherar den sista byten från motsvarande block av klartext, men går inte längre. Att dekryptera var 16:e byte av chiffertexten är ett bra trick, men det är ingen seger.

Inför misslyckanden tog Google-teamet till en sista utväg: de bytte till en mer kraftfull hotmodell - den som används i CRIME. Förutsatt att angriparen är ett skript som körs i offrets webbläsarflik och kan extrahera sessionscookies, är attacken fortfarande imponerande. Även om den bredare hotmodellen är mindre realistisk, såg vi i föregående avsnitt att just denna modell är genomförbar.

Med tanke på dessa mer kraftfulla angriparegenskaper kan attacken nu fortsätta. Observera att angriparen vet var den krypterade sessionskakan visas i rubriken och kontrollerar längden på HTTP-begäran som föregår den. Därför kan den manipulera HTTP-begäran så att den sista byten av cookien är i linje med slutet av blocket. Nu är denna byte lämplig för dekryptering. Du kan helt enkelt lägga till ett tecken till begäran, och den näst sista byten av kakan kommer att förbli på samma plats och är lämplig för val med samma metod. Attacken fortsätter på detta sätt tills cookiefilen är helt återställd. Den heter POODLE: Padding Oracle on Downgraded Legacy Encryption.

DRUNKNA

Som vi nämnde hade SSLv3 sina brister, men den var fundamentalt annorlunda än sin föregångare, eftersom den läckande SSLv2 var en produkt från en annan era. Där kunde du avbryta meddelandet i mitten: соглашусь на это только через мой труп förvandlats till соглашусь на это; klienten och servern kan mötas online, skapa förtroende och utbyta hemligheter inför angriparen, som sedan enkelt kan utge sig för båda. Det finns också problemet med exportkryptografi, som vi nämnde när vi övervägde FREAK. Dessa var kryptografiska Sodom och Gomorra.

I mars 2016 samlades ett team av forskare från olika tekniska områden och gjorde en häpnadsväckande upptäckt: SSLv2 används fortfarande i säkerhetssystem. Ja, angripare kunde inte längre nedgradera moderna TLS-sessioner till SSLv2 eftersom det hålet stängdes efter FREAK och POODLE, men de kan fortfarande ansluta till servrar och initiera SSLv2-sessioner själva.

Du kanske frågar, varför 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 säkerheten på servern – eller hur? Tja, inte riktigt. Ja, det är så det borde vara i teorin. Men nej - eftersom generering av SSL-certifikat innebär en viss börda, vilket resulterar i att många servrar använder samma certifikat och som ett resultat samma RSA-nycklar för TLS- och SSLv2-anslutningar. För att göra saken värre, på grund av en OpenSSL-bugg, fungerade inte alternativet "Inaktivera SSLv2" i denna populära SSL-implementering.

Detta möjliggjorde en korsprotokollattack på TLS, kallad DRUNKNA (Dekryptera RSA med föråldrad och försvagad kryptering, dekryptera RSA med föråldrad och försvagad kryptering). Kom ihåg att detta inte är detsamma som en kort attack; angriparen behöver inte agera som en "man i mitten" och behöver inte involvera klienten för att delta i en osäker session. Angripare initierar helt enkelt en osäker SSLv2-session med servern själva, attackerar det svaga protokollet och återställer serverns privata RSA-nyckel. Denna nyckel är också giltig för TLS-anslutningar, och från och med denna tidpunkt kommer ingen mängd TLS-säkerhet att förhindra att den äventyras.

Men för att knäcka det behöver du en fungerande attack mot SSLv2, som låter dig återställa inte bara specifik trafik, utan också den hemliga RSA-servernyckeln. Även om detta är en komplex installation, kunde forskarna välja vilken sårbarhet som helst som stängdes helt efter SSLv2. De hittade så småningom ett lämpligt alternativ: Bleichenbacher-attacken, som vi nämnde tidigare och som vi kommer att förklara i detalj i nästa artikel. SSL och TLS är skyddade från denna attack, men vissa slumpmässiga funktioner i SSL, i kombination med korta nycklar i exportklassad kryptografi, gjorde det möjligt en specifik implementering av DROWN.

Vid tidpunkten för publiceringen var 25 % av Internets främsta webbplatser påverkade av sårbarheten DROWN, och attacken kunde utföras med blygsamma resurser tillgängliga för även busiga ensamma hackare. Att hämta serverns RSA-nyckel krävde åtta timmars beräkning och $440, och SSLv2 gick från föråldrat till radioaktivt.

Vänta, hur är det med Heartbleed?

Detta är inte en kryptografisk attack i den mening som beskrivs ovan; Detta är ett buffertspill.

Låt oss ta en paus

Vi började med några grundläggande tekniker: brute force, interpolation, nedgradering, korsprotokoll och förberäkning. Sedan tittade vi på en avancerad teknik, kanske huvudkomponenten i moderna kryptografiska attacker: orakelattacken. Vi ägnade ganska lång tid åt att ta reda på det – och förstod inte bara den bakomliggande principen, utan också de tekniska detaljerna i två specifika implementeringar: Vaudenay-attacken på CBC-krypteringsläget och Kelsey-attacken på krypteringsprotokoll för förkomprimering.

När vi granskade nedgraderings- och precomputation-attacker, beskrev vi kort FREAK-attacken, som använder båda metoderna genom att låta målwebbplatser nedgradera till svaga nycklar och sedan återanvända samma nycklar. För nästa artikel kommer vi att spara (mycket liknande) Logjam-attacken, som riktar sig till algoritmer för offentliga nyckel.

Vi tittade sedan på ytterligare tre exempel på tillämpningen av dessa principer. Först, BROTT och PUDLE: två attacker som förlitade sig på angriparens förmåga att injicera godtycklig klartext bredvid målets klartext, undersök sedan serverns svar och sedan, med hjälp av oracle attack metodik, utnyttja denna sparsamma information för att delvis återställa klartexten. CRIME gick vägen för Kelseys attack mot SSL-komprimering, medan POODLE istället använde en variant av Vaudenays attack mot CBC med samma effekt.

Vi riktade sedan vår uppmärksamhet mot DROWN-attacken över protokoll, som upprättar en anslutning till servern med det äldre SSLv2-protokollet och sedan återställer serverns hemliga nycklar med Bleichenbacher-attacken. Vi har hoppat över de tekniska detaljerna i denna attack för nu; Liksom Logjam kommer det att behöva vänta tills vi har en god förståelse för kryptosystem med publika nyckel och deras sårbarheter.

I nästa artikel kommer vi att prata om avancerade attacker som möte-i-mitten, differentiell kryptoanalys och födelsedagsattacker. Låt oss ta ett snabbt utflykt till sidokanalattacker och sedan gå vidare till den roliga delen: kryptosystem med offentliga nyckel.

Källa: will.com