Kur përmendet "kriptografia", disa e kujtojnë fjalëkalimin e tyre të WiFi, ikonën e gjelbër pranë adresës së faqes së tyre të preferuar dhe se sa e vështirë është të hysh në emailin e dikujt tjetër. Të tjerë kujtojnë një seri dobësish të viteve të fundit me akronime që flasin (DROWN, FREAK, POODLE…), logot e modës dhe paralajmërimin për të përditësuar patjetër shfletuesin.

Kriptografia përfshin të gjitha këto, por thelbësia është në diçka tjetër. Thelbi është në mesin e asaj që është e thjeshtë dhe e komplikuar. Disa gjëra janë të lehta për tu bërë, por është e vështirë të kthehen prapa: për shembull, të thyhet një vezë. Të tjerë gjëra janë të lehta për tu bërë, por e vështirë për t'u kthyer kur mungon një pjesë vendimtare e vogël: për shembull, të hapësh një derë të mbyllur kur "pjesa vendimtare" është çelësi. Kriptografia shqyrton këto situata dhe mënyrat e përdorimit praktik të tyre.

Në vitet e fundit, koleksioni i sulmeve kriptografike u kthye në një zoo logosh që bërtasin, të mbushura me formula artikujsh shkencorë dhe krijuan një ndjesi të përgjithshme të errësirës se gjithçka është e dëmtuar. Por në të vërtetë, shumë nga sulmet bazohet në disa parime të zakonshme, dhe faqet e pafundme të formulave shpesh përfundojnë në ide të thjeshta për t'u kuptuar.

Në këtë seri artikujsh, do të shqyrtojmë lloje të ndryshme sulmesh kriptografike, me theks në parimet themelore. Në përgjithësi dhe jo domosdoshmërisht në këtë rend, ne do të diskutojmë për:

Strategjitë e baza: bruteforce, analiza e frekuencës, interpolimi, ulja dhe protokollet e kalimit.
"Dobësitë markë": FREAK, CRIME, POODLE, DROWN, Logjam.
Strategjitë e avancuara: sulmet oracle (sulmi i Vodenës, sulmi i Kelsit); metoda e takimeve në mes (meet-in-the-middle), sulmi i "ditëlindjeve", devijimi statistik (analiza diferenciale e kriptografisë, analiza integrale e kriptografisë etj.).
Sulmet përmes kanaleve anësore dhe të afërmit e tyre, metodat e analizës së dështimeve.
Sulmet në kriptografinë me çelës të hapur: rrënja kubike, transmetimi, mesazhi i lidhur, sulmi i Koppersmith, algoritmi Polygang - Hellman, sita numerike, sulmi i Wiener, sulmi i Blaykenbach.

Ky artikull specifik mbulon materialin e përmendur deri në sulmin e Kelsit.

Strategjitë e baza

Sul sulmet e ardhshme janë të thjeshta në kuptimin se mund të shpjegohen pothuajse në tërësi pa detaje teknike të veçanta. Do të shpjegojmë çdo lloj sulmi në terma shumë të thjeshtë, pa u thelluar në shembuj të komplikuar ose variante të zgjeruara të përdorimit.

Disa nga këto sulme në thelb kanë humbur aktualitetin dhe nuk janë përdorur për shumë vite. Të tjerat janë të vjetra, ende sulmojnë zhvilluesit e kriptosistemeve pa dyshim në shekullin 21. Mund të konsiderohet se epoka e kriptografisë moderne filloi me shfaqjen e IBM DES – enkriptimi i parë që përballoi të gjitha sulmet në këtë listë.

Forcimi i thjeshtë

Shtesa e enkriptimit përbëhet nga dy pjesë: 1) funksioni i enkriptimit, i cili merr një mesazh (tekst të hapur) së bashku me një çelës, dhe krijon një mesazh të enkriptuar – tekst të enkriptuar; 2) funksioni i dekriptimit, i cili merr tekstin e enkriptuar dhe çelësin dhe krijon tekstin e hapur. Të dyja proceset e enkriptimit dhe dekriptimit duhet të jenë lehtë të llogaritura me çelësin – dhe të vështira pa të.

Supozoni se ne shohim tekstin e enkriptuar dhe përpiqemi ta dekriptojmë pa informacion të mëtejshëm (kjo quhet sulmi "vetëm tekst të enkriptuar"). Nëse ndonjë mënyrë magjike gjejmë çelësin e duhur, ne mund ta verifikojmë lehtësisht nëse ai është vërtet i saktë, nëse rezultati është një mesazh i arsyeshëm.

Vini re se ka dy supozime të paqarta këtu. Së pari, ne supozojmë se dimë si të realizojmë dekriptimin, dmth, si funksionon kriptosistema. Ky është një supozim standard kur diskutohet kriptografia. Fshehja e detajeve të realizimit të enkriptimit nga sulmuesit mund të duket si një masë shtesë sigurie, por sa herë që sulmuesi zbulojnë këto detaje, kjo masë e sigurisë përfundimisht humbet pa u vënë re dhe pa kthim prapa. Kështu është parimi i Kerckhoffs: sistemi nuk duhet të shkaktojë shqetësime kur bie në duar të armikut.

Së dyti, ne supozojmë se çelësi i duhur është çelësi i vetëm që do të çojë në një dekriptim të arsyeshëm. Ky është gjithashtu një supozim i arsyeshëm; ai mbetet i vlefshëm nëse teksti i enkriptuar është shumë më i gjatë se çelësi dhe lexohet mirë. Kjo është zakonisht rasti në botën reale, përveç çelësave shumë të mëdhenj dhe të paprakatikueshëm или mashtrimeve të tjera që është më mirë të lihen mënjanë. (nëse nuk ju pëlqen që ne u shmangëm shpjegimeve, ju lutemi shikoni teoremin 3.8 këtu).

Duke marrë parasysh këtë, lind strategjia: të kontrolloni çdo çelës të mundshëm. Kjo quhet brute force, dhe një sulm i tillë garanton suksesin ndaj të gjitha kritereve praktike të enkriptimit — përfundimisht. Për shembull, brute force mjafton për të thyer enkriptimin e Cezarit, një enkriptim i lashtë, ku çelësi është një letër nga abetarja, që nënkupton pak më shumë se 20 çelësa të mundshëm.

Fatkeqësisht për kriptoanalistët, rritja e madhësisë së çelësit mbron mirë nga brute force. Me rritjen e madhësisë së çelësit, numri i mundshëm i çelësave rritet në mënyrë eksponenciale. Me madhësitë moderne të çelësave, përdorimi i thjeshtë i brute force është krejtësisht i papraktikueshëm. Për të kuptuar çfarë nënkuptojmë, le të marrim superkompjuterin më të shpejtë të njohur nga mesit të vitit 2019: Summit nga IBM, me një performancë pikore rreth 10^17 operacione në sekondë. Sot, gjatëzërsia tipike e çelësit është 128 bit, që do të thotë 2^128 kombinime të mundshme. Për të provuar të gjithë çelësat, superkompjuterit Summit do t'i nevojitej një kohë që është rreth 7800 herë më e gjatë se mosha e Universit.

Duhet të konsiderohet brute force si një kuriozitet historik? Aspak: kjo është një përbërës i domosdoshëm në librin e gatimit të kriptoanalizës. Rrallë janë enkriptimet kaq të dobëta sa të thyehen vetëm me metoda inteligjente, pa përdorur forcën në një mënyrë ose një tjetër. Shumë thyerje të suksesshme përdorin fillimisht një metodë algoritmike për të dobësuar enkriptimin që është objektiv, dhe më pas nisnin brute force.

Analiza e frekuencës

Shumica e teksteve nuk janë përzierje çorroide. Për shembull, në tekstet në anglisht ka shumë letra ‘e’ dhe artikuj ‘the’; në skedarët binarë — shumë byte të zeros në formë mbushjeje midis fragmenteve të informacionit. Analiza e frekuencës është çdo sulm që përdor këtë fakt.

Një shembull kanonik i një enkriptimi të ndjeshëm ndaj kësaj sulmi është enkriptimi i zakonshëm i zëvendësimit. Në këtë enkriptim, çelësi përfaqëson një tabelë që zëvendëson të gjitha shkronjat. Për shembull, ‘g’ zëvendësohet me ‘h’, ‘o’ — me ‘j’, Prandaj, fjala ‘go’ kthehet në ‘hj’. Ky enkriptim është shumë i vështirë për t'u thyer me brute force të thjeshtë, sepse ka shumë tabela zëvendësimi të mundshme. Nëse ju intereson matematika, gjatëzërsia efektive e çelësit është rreth 88 bit: kjo është
. Por analizën e frekuencës zakonisht përballohet me këtë detyrë shpejt.

Le të shqyrtojmë tekstin e mëposhtëm të koduar, i përpunuar me një cifër zëvendësimi të thjeshtë:

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

Duke qenë se Y ndodh shpesh, përfshirë në fund të shumë fjalëve, ne mund të supozojmë paraprakisht se kjo është letra e:

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

Pika XD përsëritet në fillim të disa fjalëve. Në veçanti, kombinimi XDeLe qartë nënkupton fjalën these или there, prandaj vazhdojmë:

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

Më pas supozoni se L përputhet me r, A — a edhe kështu me radhë. Me të vërtetë, do të ketë disa përpjekje, por krahasuar me një brute force të plotë, kjo sulm i rikthen tekstin origjinal në kohë të shkurtër:

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

Për disa, zgjidhja e të tilla «kriptogramëve» është një hobi interesant.

Ideja e analizës së frekuencës është më themelore sesa duket në një shikim të parë. Ajo është e aplikueshme për cifra shumë më komplekse. Gjatë gjithë historisë, konstruktime të ndryshme të cifrave kanë përpiqur të përballen me një sulm të tillë duke përdorur «zëvendësimin poli-alfabetik». Në këtë proces, tabela e zëvendësimit të shkronjave ndryshon në mënyra komplekse, por të parashikueshme, që varen nga çelësi. Të gjitha këto cifra dikur ishin konsideruar të vështira për t'u thyer; dhe megjithatë, analiza e modeste e frekuencës i ka mundur ato përfundimisht.

Cifra më ambicioze poli-alfabetike në histori dhe ndoshta më e njohura ishte cifra «Enigma» gjatë Luftës së Dytë Botërore. Ajo ishte relativisht e ndërlikuar krahasuar me paraardhësit e saj, por si rezultat i punës së gjatë dhe të vazhdueshme, kriptoanalistët britanikë e thyen atë përmes analizës së frekuencës. Sigurisht, ata nuk mundën të zhvillonin një sulm elegant, siç përshkruhet lart; ata u detyruan të krahasojnë çifte të njohura të teksteve të hapura dhe të koduara (shtimi i njohur si «sulmi i bazuar në tekstet e hapura») dhe madje të provokojnë përdoruesit e «Enigmës» të kodonin mesazhe të caktuara duke analizuar rezultatin («sulmi i bazuar në tekstin e përzgjedhur të hapur»). Por kjo nuk e lehtësoi fatin e ushtrive të mundura të armiqve dhe të nëndetëseve të fundosura.

Pas këtij triumfi, analiza e frekuencës zhduket nga historia e kriptoanalizës. Shifrat e epokës digjitale moderne janë krijuar për të punuar me bitët, jo me shkronjat. Çfarë është edhe më e rëndësishme, këto shifra janë zhvilluar me një kuptim të errët të asaj që më vonë u bë e njohur si ligji i Shnaierit: çdo njeri mund të krijojë një algoritëm të enkriptimit që vetë nuk mund ta thyejë. Nuk është e mjaftueshme që sistemi i enkriptimit të duket komplikuar: për të dëshmuar vlerën e tij, ai duhet të kalojë një rishikim të pamëshirshëm të sigurisë nga shumë kriptoanalistë që do të bëjnë gjithçka për të thyer shifrën.

Përllogaritjet paraprake

Le t'i japim një qytet hipotetik, Prekom Heights, me një popullsi prej 200,000 njerëzish. Në çdo shtëpi të qytetit ndodhen objekte me vlerë në mesatarisht $30,000, por jo më shumë se $50,000. Tregu i sigurisë në Preko është monopolizuar nga kompania ACME Industries, e cila prodhon zamkët legjendare të klasës Coyote ™. Sipas analizës ekspertëve, zamku i klasës Coyote mund të thyehet vetëm nga një makinë shumë komplekse hipotetike, krijimi i së cilës kërkon rreth pesë vjet dhe investime prej $50,000. A është qyteti në siguri?

Me sa duket, jo. Në fund të fundit, do të dalë një kriminel mjaft ambicioz. Ai do të arsyetojë në këtë mënyrë: "Po, unë do të kem shpenzime të mëdha paraprakisht. Pesë vjet pritje të durueshme dhe $50,000. Por pas përfundimit të punës, unë do të kem qasje te të gjitha pasuritë e këtij qyteti. Nëse luaj mirë kartat e mia, ky investim do të kthehet shumëfish."

Po ashtu edhe në kriptografi. Sulmet kundër një shifre të caktuar përballen me një analizë të pamëshirshme të kostove dhe përfitimeve. Nëse raporti është i favorshëm, sulmi nuk do të ndodhë. Por sulmet që veprojnë menjëherë kundër shumë viktimave të mundshme, pothuajse gjithmonë shpërblehen, dhe në këtë rast, praktika më e mirë e projektimit është të supozosh se ato kanë filluar që në ditën e parë. Ne kemi në thelb një version kriptografik të ligjit të Mërfyt: "Çdo gjë që mund të thyejë sistemin, do ta thyejë atë".

Shembulli më i thjeshtë i një kripto-sistemi të ndjeshëm ndaj sulmit me përllogaritje paraprake është shifra me një algoritëm konstant pa përdorimin e çelësit. Kështu ndodhi me shifrën e Cezarit, i cili vetëm lëviz çdo shkronjë të alfabetit tre shkronja përpara (tabela është e mbyllur, kështu që shkronja e fundit e alfabetit kodifikohet si e treta). Këtu përsëri shfaqet parimi i Kerckhoffs-it: sa herë që sistemi është thyer, ai është thyer përherë.

Koncepci është e thjeshtë. Edhe një zhvillues fillestar i kriptosistemave, me siguri do të jetë i vetëdijshëm për kërcënimin dhe do të përgatitet sipas nevojës. Nëse e shohim evolucionin e kriptografisë, këto sulme kanë qenë të papërshtatshme për shumicën e kodimeve, duke filluar nga versionet e përmirësuara të kodit të Cezarit, deri te rënia e kodimeve poli-alfa. Këto sulme u rikthyen vetëm me nisjen e epokës moderne të kriptografisë.

Ky rikthim është shkaktuar nga dy faktorë. Së pari, përfundimisht aret adhaurish të mjaftueshme të kriptosistemave, ku mundësia e eksploatimit pas thyerjes nuk ishte e qartë. Së dyti, kriptografia ka marrë një përhapje të tillë që miliona njerëz të paqëndrueshëm marrin çdo ditë vendime, ku dhe cilat pjesë të kriptografisë të përdoren përsëri. Kaloi një kohë para se ekspertët të kuptonin rreziqet që kishin lindur dhe të ngrinin alarmin.

Mbani mend sulmin me parakalkulime: në fund të artikullit, ne do të shqyrtojmë dy shembuj kriptografikë nga jeta reale, ku ai luajti një rol të rëndësishëm.

Interpolimi

Para jush është detektivi i famshëm Sherlock Holmes, që realizon një sulm me interpolim ndaj mjekut të pafat Watson:

Njëherë e kuptova se keni ardhur nga Afganistani... Rrjedha e mendimeve të mia ishte kështu: «Ky njeri për nga tipi është mjek, por stili i tij është ushtarak. Pra, mjek ushtarak. Ai sapo ka ardhur nga tropiket - fytyra e tij është e errët, por ky nuk është nuancë natyrale e lëkurës së tij, pasi ky i fundit është shumë më i bardhë. Fytyra e tij është e lodhur - duket se ka kaluar shumë dhe ka vuajtur nga një sëmundje. Ka marrë një plagë në dorën e majtë - mbush dorën e tij dhe paksa të pazakontë. Ku mund të ketë vuajtur një mjek ushtarak anglez nga tropiket dhe të ketë marrë plagë? Sigurisht, në Afganistan». E gjithë rrjedha e mendimeve nuk zuri më shumë se një sekondë. Dhe ja, tha se keni ardhur nga Afganistani, dhe ju u habitët.

Nga çdo kutinë veçmas, Holmes mund të nxjerrë shumë pak informacion. Ai mund të arrijë në përfundimin e tij vetëm duke i konsideruar të gjitha së bashku. Në mënyrë të ngjashme funksionon sulmi me interpolim, duke shqyrtuar çiftet e njohura të teksteve të hapura dhe të enkriptuara, të marra si rezultat i aplikimit të të njëjtit çelës. Nga çdo çift nxirren vëzhgime të veçanta, të cilat lejojnë të bëhet një përfundim i përgjithshëm për çelësin. Të gjitha këto arsyetime janë të paqarta dhe duken të pandihmuara derisa papritmas të arrijnë një masë kritike dhe të çojnë në përfundimin e vetëm të mundshëm: çfarëdo qoftë, ai duhet të jetë e vërtetë. Pas kësaj, ose zbulohet çelësi ose procesi i dekriptuar bëhet aq i zhvilluar sa mund të reprodukohet.

Le të ilustrojmë me një shembull të thjeshtë se si funksionon interpolimi. Supozoni se duam të lexojmë ditarin personal të armikut tonë, Bobit. Ai enkripton çdo numër në ditarin e tij duke përdorur një sistem të thjeshtë kriptografik, për të cilin ka dëgjuar nga një reklamë në revistën "Tallje me Kriptografinë". Sistemi funksionon si më poshtë: Bobi zgjedh dy numra që i pëlqejnë: dhe . Nga ky moment, për të enkriptuar çdo numër , ai llogarit . Për shembull, nëse Bobi zgjodhi dhe , cifra do të enkriptohet si .

Supozoni se më 28 dhjetor vërejmë që Bobi po gërvisht diçka në ditarin e tij. Kur ai përfundon, ne do ta marrim atë pa u vënë re dhe do të shohim shënimin e fundit:

Data: 235/520
Ditar i dashur,
Sot ishte një ditë e mirë. Pas 64 dite për veçori kam një takim me Alisën, e cila jeton në apartamentin 843. Unë vërtet mendoj se ajo mund të jetë 26!

Duke marrë parasysh se ne jemi shumë seriozisht të vendosur të ndjekim Bobin në takimin e tij (në këtë skenar ne jemi 15 vjeç), është kritikisht e rëndësishme të dimë datën, si dhe adresën e Alisës. Për fat të mirë, ne vërejmë se sistemi i kriptografisë i Bobit është i ndjeshëm ndaj sulmit të interpolimit. Ne ndoshta nuk e dimë dhe , por ne e dimë datën e sotme, kështu që kemi dy çifte "tekst të hapur - tekst të enkriptuar". Në veçanti, ne e dimë se enkriptohet në , ndërsa — në . Çfarë do ta shkruajmë:

Duke marrë parasysh se ne jemi 15 vjeç, ne tashmë e dimë për sistemin e dy ekuacioneve me dy të panjohura, që është e mjaftueshme në këtë rast për të gjetur dhe pa probleme të mëdha. Çdo çift «teksti i hapur-cifrimi» vendos një kufizim për çelësin e Bobit, dhe dy kufizime së bashku mjaftojnë për të rikuperuar plotësisht çelësin. Në shembullin tonë, përgjigja dhe (në , kështu që 26 në ditarin përputhet me fjalën ‘ai’, e cila do të thotë «ai i saktë» — shën. ed.).

Sulmet e interpolimit, sigurisht, nuk kufizohen në shembuj kaq të thjeshtë. Çdo sistem kriptografik, i cili reduktohet në një objekt matematikor të njohur mirë dhe një listë parametrash, është në rrezik nga sulmet e interpolimit — sa më e qartë të jetë objekti, aq më i lartë është rreziku.

Fillestarët shpesh ankohen se kriptografia është «art i projektimit sa më të shëmtuar». Probabil është shumë në faj sulmet e interpolimit. Bobi mund ta përdorë një dizajn matematikor të elegancës, ose të mbajë privatësinë e takimit me Alison — por fatkeqësisht, zakonisht nuk është e mundur të marrësh edhe njëherë të dyja. Kjo do të bëhet shumë e qartë kur përfundimisht të kalojmë në temën e kriptografisë me çelës të hapur.

Kryq-protokoll/shkallëzim

Në filmin «Iluzioni i mashtrimit» (2013), një grup iluzionistësh përpiqet të mashtrojë dhe të marrë gjithë pasurinë e një magnati të korruptuar të sigurimeve, Arthur Tressler. Për të aksesuar llogarinë bankare të Arthur-it, iluzionistët duhet të paraqesin ose emrin e përdoruesit dhe fjalëkalimin e tij, ose ta detyrojnë atë të shfaqet personalisht në bankë dhe të marrë pjesë në plan.

Të dy opsionet janë shumë të vështira; djemtë janë mësuar të performojnë në skenë, e jo të marrin pjesë në operacione shërbimesh sekrete. Prandaj ata zgjedhin një opsion të tretë të mundshëm: aleati i tyre telefonon bankën dhe identifikohet si Arthur. Banka bën disa pyetje për verifikimin e identitetit, si emri i xhaxhait dhe emri i kafshës së parë shtëpiake; heronjtë tanë paraprakisht e nxjerrin lehtësisht këtë informacion nga Arthur me anë të inxhinierisë sociale të zgjuar. Që nga ky moment, sigurimi i shkëlqyer i fjalëkalimit nuk ka më rëndësi.

(Sipas legjendës urbane, të cilën ne e kemi kontrolluar dhe konfirmuar personalisht, kriptografi Eli Biham përballi një kasier banke që insistonte në vendosjen e një pyetjeje sekrete. Kur kasieri pyeti emrin e gjyshes nga ana e nënës, Biham filloi të jepte: «X e madhe, y e vogël, tre…»).

Edhe në kriptografi, nëse për të mbrojtur një aktiv të njëjtë përdoren paralelisht dy protokollë kriptografikë, ku njëri është shumë më i dobët se tjetri, sistemi përfundimtar bëhet i ndjeshëm ndaj një sulmi ndër-protokoll, kur sulmohet protokolli më i dobët për të arritur në objekt, pa prekur atë më të fortin.

Në disa raste të ndërlikuara, nuk mjafton thjesht të lidhemi me serverin përmes një protokolli më të dobët, por është e nevojshme që klienti legjitim të ndihmojë pa dashje. Kjo mund të organizohet përmes asaj që quhet sulm për ulje të sigurisë (downgrade). Për të kuptuar këtë sulm, le të supozojmë se iluzionistët tanë kanë një detyrë më të komplikuar se në film. Supozoni se ka ndodhur një situatë e papritur midis një punonjësi banke (kasier) dhe Arturit, duke ndodhur kështu një dialog:

Hacker: Halo? Këtu është Arthur Tressler. Do doja të rivendosja fjalëkalimin tim.
Kasieri: E shkëlqyer. Ju lutem, shikoni në librin tuaj personal të kodeve sekrete, faqe 28, fjala 3. Të gjitha mesazhet e mëvonshme do të jenë të koduara me këtë fjalë si çelës. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hacker: Hej, hej, pse t'u ndalojmë? A është vërtet e nevojshme? Ajo mund të flasim si njerëz normalë?
Kasieri: Nuk e rekomandoj këtë.
Hacker: Unë thjesht… dëgjo, kam pasur një ditë të keqe, e kupton? Unë jam një klient VIP dhe nuk jam në humör për t'u marrë me këto libra të budallallëkut.
Kasieri: Mirë. Nëse insistoni, zoti Tressler. Çfarë dëshironi?
Hacker: Ju lutem, do doja të transferoja gjithë paratë e mia në Fondin Kombëtar të Viktimave të Arthur Tressler.
(Pauzë).
Kasieri: Pra, e kuptoj. Ju lutem, tregon pin-in tuaj për transaksionet e mëdha.
Hacker: Cila është ajo?
Kasieri: Sipas kërkesës suaj, transaksionet e këtij lloji kërkojnë hyrjen e pin-it për transaksione të mëdha. Ky kod ju është dhënë kur keni hapur llogarinë.
Hacker:… e kam humbur. A është vërtet e nevojshme? A nuk mund ta miratoni për shkak të besimit?
Kasieri: Jo. Më vjen keq, zoti Tressler. Përsëri, kjo është një masë sigurie që keni kërkuar. Nëse dëshironi, mund të dërgojmë një pin të ri në kutinë tuaj postare.

Heronjt tanë vonojnë operacionin. Ata dëgjojnë disa transaksione të mëdha të Treslerit, duke shpresuar të dëgjojnë kodin pin; por çdo herë biseda shndërrohet në një zhurmë të koduar, përpara se të dëgjohet diçka interesante. Së fundi, në një ditë të bukur, ata vijnë në veprim. Ata presin me durim momentin kur Tresleri duhet të bëjë një transaksion të madh telefonik, ai lidhet me linjën, dhe pastaj…

Tresleri: Përshëndetje. Do doja të kryej një transaksion të largët, ju lutem.
Kasieri: Shkëlqyeshëm. Ju lutem, shikoni në librin tuaj personal të kodit sekret, fjala…
(Hacker-i shtyp butonin; zëri i kasieres shndërrohet në një zhurmë të paqartë).
Kasieri: — #@$#@$#*@$$@#* do të kodifikohet me këtë fjalë si çelësi. AAAYRR PLRQRZ MMNJK LOJBAN…
Tresleri: Më falni, nuk e kuptova shumë mirë. Një herë tjetër? Në cilën faqe? Cila është fjala?
Kasieri: Kjo është faqja @#$@#*$)#*#@()#@$(#@*$(#@*.
Tresleri: Çfarë?
Kasieri: Fjala numër njëzet @$#@$#%#$.
Tresleri: Seriozisht! Mjaft më! Ti me protokollet e tua të sigurisë — kjo është një cirk. E di që mund të flasësh normalisht me mua.
Kasieri: Nuk rekomandoj…
Tresleri: E unë nuk të rekomandoj të harxhosh kohën time. Nuk dua të dëgjoj më për këtë, derisa të rregulloni problemet me linjën tuaj telefonike. A mund të kryejmë këtë marrëveshje apo jo?
Kasieri:… po. Mirë. Çfarë dëshiron?
Tresleri: Dëshiroj të transferoj $20,000 në kompaninë Lord Business Investments, numri i llogarisë…
Kasieri: Një moment, ju lutem. Kjo është një marrëveshje e madhe. Ju lutem, specifikoni kodin tuaj pin për transaksione të mëdha.
Tresleri: Çfarë? Ah, e sigurt. 1234.

Këtu është sulmi në rënie. Protokolli më i dobët "flisni drejtpërdrejt" është menduar si opsion në rast emergjence. Dhe megjithatë, ne jemi këtu.

Ju mund të pyesni, kush do të ishte në mendje të shëndoshë për të projektuar një sistem real si "i sigurt, derisa të kërkohet për të kundërtën", siç përshkruhet më lart. Por, ashtu si banka fiktive merr rreziqe për të mbajtur klientët që nuk i pëlqejnë kriptografinë, ashtu edhe sistemet në përgjithësi shpesh i përmbushin kërkesat që janë të paduruara ose madje hapur armiqësore ndaj sigurisë.

Një histori e tillë ndodhi me protokollin SSLv2 në vitin 1995. Qeveria e SHBA-së kishte filluar prej kohësh ta konsideronte kriptografinë si një armë, e cila ishte më mirë të mbahej larg armiqve të jashtëm dhe të brendshëm. Fragmente të kodit u miratuan për eksport nga SHBA, shpesh me kushtin e dobësimit të qëllimshëm të algoritmit. Kompanisë Netscape, zhvilluesit të shfletuesit më popullor Netscape Navigator, iu dha miratimi për SSLv2 vetëm me çelësin RSA të dobësuar prej 512 bitësh (dhe 40 bitë për RC4).

Në fund të mijëvjeçarit, rregullat u zbutën dhe aksesin në kriptografinë moderne u bë gjerësisht i arritshëm. Megjithatë, klientët dhe serverët për shumë vite mbajtën kriptografinë e dobësuar "eksportuese" për shkak të inercisë së njëjtë që ruan mbështetje për çdo sistem të vjetruar. Klientët mendojnë se mund të përballen me një server që nuk mbështet asgjë tjetër. Serverët bënin të njëjtën gjë. Sigurisht, protokolli SSL përcakton se klientët dhe serverët nuk duhet kurrë të përdorin një protokoll të dobët kur një i mirë është në dispozicion. Por e njëjta parakusht ndodhi për Tressler-in dhe bankën e tij.

Kjo teori gjeti aplikim në dy sulme të njohura, të cilat njëra pas tjetrës tronditën sigurinë e protokollit SSL në vitin 2015, të dyja të zbuluara nga hulumtuesit e Microsoft dhe INRIA. Fillimisht në shkurt u publikuan detajet e sulmit FREAK, dhe pas tre muajsh një sulmi tjetër të ngjashëm të quajtur Logjam, të cilin do ta diskutojmë më në detaje kur të kalojmë te sulmet ndaj kriptografisë me çelës të hapur.

Vulnerabiliteti FREAK (njohur gjithashtu si "Smack TLS") u shfaq kur hulumtuesit analizuan implementimet e klientëve/serverëve TLS dhe zbuluan një gabim të çuditshëm. Në këto implementime, nëse klienti as nuk kërkon të përdorë kriptografinë e dobësuar eksportuese, por serveri përsëri përgjigjet me këto çelësat - klienti thotë "Mirë, mirë" dhe kalon në një grup dobësish të kriptimit.

Në atë kohë, të gjithë e konsideronin kriptografinë eksportuese si të vjetruar dhe të ndaluar për përdorim, prandaj sulmi ishte një goditje e vërtetë dhe preku shumë fusha të rëndësishme, duke përfshirë faqet e Shtëpisë së Bardhë, administratës tatimore të SHBA-së dhe NSA-së. Më keq akoma, u zbulua se shumë serverë të prekur kishin optimizuar performancën, duke ripërdorur të njëjtat çelësa në vend që të krijonin të rinj për çdo seancë. Kjo lejoi që pas uljes së protokollit, të përfshihej edhe një sulm i paracaktuar: thyerja e një çelësi mbetej relativisht e shtrenjtë ($100 dhe 12 orë në momentin e publikimit), por kostoja praktike e sulmit ndaj lidhjes u ul ndjeshëm. Mjafton të kesh identifikuar një herë çelësin e serverit - dhe do të thyhen kodet për të gjitha lidhjet e ardhshme nga ai moment.

Dhe përpara se të vazhdojmë, duhet të përmendim një sulm të avancuar...

Sulmi Oracle

Moxie Marlinspike njihet kryesisht si babai i mesazhit kriptografik me shumë platforma Signal; por personalisht na pëlqen një prej inovacioneve të tij më pak të njohura - principi i fatit të kriptografisë (Cryptographic Doom Principle). Pak i ri-shkruar, mund të thuhet kështu: "Nëse protokolli kryen çdo operacion kriptografik mbi një mesazh nga një burim potencialisht i dëmshëm dhe sillet ndryshe në varësi të rezultatit, ai është i destinuar për dështim." Ose në një formë më të ashpër: "Mos merr informacion nga armiku për përpunim, dhe nëse duhet, atëherë të paktën mos tregoni rezultatin."

Të lëmë mënjanë shfryrjet e bufrit, injeksionet e komandave dhe gjëra të tjera të ngjashme; ato dalin jashtë kornizës së kësaj diskutimi. Shkelja e "principit të fatit të kriptografisë" çon në thyerje të rënda të kriptografisë për shkak se protokolli sillet pikërisht ashtu siç është parashikuar.

Për shembull, le të marrim një konstrukt imagjinar me një cifër të ndjeshme, dhe më pas të demonstrojmë një sulm të mundshëm. Edhe pse ne kemi parë tashmë një sulm ndaj një cifre me anë të analizës së frekuencës, kjo nuk është thjesht "një mënyrë tjetër për të thyer të njëjtën cifër". Përkundrazi, sulmet Oracle janë një shpikje shumë më moderne, të aplicueshme në shumë situata kur analiza e frekuencës dështon, dhe ne do të shohim një demonstrim të kësaj në seksionin e ardhshëm. Këtu, një cifër e thjeshtë është zgjedhur vetëm për të bërë shembullin më të kuptueshëm.

Kështu, Alisa dhe Boba komunikojnë përmes një şifre të thjeshtë zëvendësimi, duke përdorur një çelës që e dinë vetëm ata. Ata janë shumë strik të lidhur me gjatësinë e mesazheve: gjatësia e tyre është saktësisht 20 karaktere. Prandaj, ata ra dakord që nëse dikush dëshiron të dërgojë një mesazh më të shkurtër, duhet të shtojë një tekst të rremë në fund të mesazhit, në mënyrë që të jetë saktësisht 20 karaktere. Pas një debati të caktuar, ata vendosën se do të pranojnë vetëm tekstet e rreme të mëposhtme: a, bb, ccc, dddd etj. Në këtë mënyrë, është e njohur teksti i rremë i çdo gjatësie të nevojshme.

Kur Alisa ose Boba pranojnë një mesazh, ata së pari kontrollojnë që mesazhi të ketë gjatësinë e duhur (20 karaktere) dhe sufiksi të jetë tekst i rremë i saktë. Nëse kjo nuk është e tillë, ata përgjigjen me një mesazh gabimi përkatës. Nëse gjatësia e tekstit dhe teksti i rremë janë në rregull, marrësi lexon vetë mesazhin dhe dërgon një përgjigje të enkriptuar.

Gjatë procesit të sulmit, sulmuesi e quan veten Boba dhe dërgon mesazhe të rreme Alisës. Mesazhet janë një marrëzi totale - sulmuesi nuk ka çelësin, kështu që ai nuk mund të falsifikojë një mesazh kuptimplotë. Por pasi protokolli shkel parimin e fatkeqësisë, sulmuesi mund të mashtrojë Alisën që të zbulojë informacionin rreth çelësit, siç tregohet më poshtë.

Hacker: PREWF ZHJKL MMMN. LA
Alisa: Teksti i rremë është i pavlefshëm.
Hacker: PREWF ZHJKL MMMN. LB
Alisa: Teksti i rremë është i pavlefshëm.
Hacker: PREWF ZHJKL MMMN. LC
Alisa: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Sulmuesi nuk ka asnjë ide se çfarë tha Alisa, por vëren se simboli C duhet të përputhet a, pasi Alisa pranoi tekstin e rremë.

Hacker: REWF ZHJKL MMMN. LAA
Alisa: Teksti i rremë është i pavlefshëm.
Hacker: REWF ZHJKL MMMN. LBB
Alisa: Teksti i rremë është i pavlefshëm.
Pas disa përpjekjeve...
Hacker: REWF ZHJKL MMMN. LGG
Alisa: Teksti i rremë është i pavlefshëm.
Hacker: REWF ZHJKL MMMN. LHH
Alisa: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Përsëri, sulmuesi nuk ka asnjë ide se çfarë tha Alisa, por vëren se H duhet të përputhet me b, pasi Alisa pranoi tekstin e rremë.

Dhe kështu me radhë, derisa sulmuesi të mësojë vlerën e çdo simboli.

Me parë, metoda duket si një sulm i bazuar në tekst të hapur të zgjedhur. Në fund të fundit, sulmuesi zgjedh tekstet e koduara, dhe serveri i përpunon ato në mënyrë të mençur. Diferenca kryesore që i bën këto sulme të realizueshme në botën reale është se sulmuesi nuk ka nevojë për qasje në dekodimin e vërtetë — mjafton të marrë një përgjigje nga serveri, madje edhe një të tillë të padëmshme si "Teksti i shpikur është gabim."

Megjithëse ky sulm i veçantë është edukativ, nuk duhet te merret shumë me specifikat e skemës "teksti i shpikur", sistemin e kriptografisë që përdoret, ose sekuencën e saktë të mesazheve që dërgon sulmuesi. Ideja kryesore qëndron në atë se si reagojnë ndikimi i Alisë në mënyra të ndryshme bazuar në vetitë e tekstit të hapur, dhe e bën këtë pa verifikuar që teksti përkatës i koduar është marrë nga një palë e besuar. Kështu, Alia e lejon sulmuesin të nxjerrë informacion të fshehtë nga përgjigjet e saj.

Në këtë skenar, mund të ketë shumë ndryshime. Simbolet që Alia reagon ndaj tyre, apo ndryshimi në sjelljen e saj, apo madje edhe sistemi i kriptografisë që përdoret. Por parimi do të mbetet i njëjtë, dhe sulmi në tërësi do të mbetet i realizueshëm në një formë ose një tjetër. Implementimi themelor i këtij sulmi ndihmoi në identifikimin e disa gabimeve të sigurisë, të cilat do t'i shqyrtojmë së shpejti; por së pari, duhet të mësojmë disa mësime teorike. Si mund të përdoret ky "skenar i Alisë" në një sulm që mund të funksionojë në një kriptim modern të vërtetë? A është e mundur kjo në të vërtetë, madje edhe në teori?

Në vitin 1998, kriptografi zviceran Daniel Bleichenbacher përgjigji pozitivisht në këtë pyetje. Ai demonstroi një sulm orakulli në një sistem të kriptografisë me çelës publik RSA, duke përdorur një skemë të caktuar mesazhesh. Në disa implementime të RSA, serveri përgjigjet me mesazhe gabimi të ndryshëm, në varësi nëse teksti i hapur i përgjigjet skemës apo jo; kjo ishte e mjaftueshme për të kryer sulmin.

Katër vjet më vonë, në vitin 2002, kriptografi francez Serge Vaudenay demonstroi një sulm orakulli, pothuajse identik me atë që u përmend më lart në skenarin e Alicës – me përjashtim të faktit se, në vend të një cifre të shpikur, ai thau një klasë të tërë të respektuar të cifravëve modernë, të cilat njerëzit realisht përdorin. Në veçanti, sulmi i Vaudenay ishte i drejtuar ndaj cifrave me një madhësi të fiksuar hyrëse (“cifrave blloku”), kur ato përdoren në atë që quhet “reja e enkriptimit CBC” dhe me një skemë mbushjeje të caktuar, kryesisht ekuivalente me atë që është në skenarin e Alicës.

Po ashtu, në vitin 2002, kriptografi amerikan John Kelsey – bashkëautor Twofish – propozi kërcënime të ndryshme orakulli ndaj sistemeve që kompresojnë mesazhet dhe pastaj i enkriptojnë ato. Më e dukshmja ndër to ishte një sulm, i cili përdorte atë që shpesh mund të nxirret gjatë gjatësi origjinale të tekstit të hapur nga gjatësia e tekstit të enkriptuar. Në teori, kjo lejon kryerjen e një sulmi orakulli që rikthen pjesë të tekstit origjinal të hapur.

Më pas, do të ofrojmë një përshkrim më të detajuar të sulmeve të Vaudenay dhe Kelsey (do t'i japim një përshkrim më të detajuar të sulmit të Blayhenbacher, kur të kalojmë në sulmet ndaj kriptografisë me çelës të hapur). Pavarësisht nga të gjitha përpjekjet tona, teksti bëhet disi teknik; prandaj, nëse përmbajtja e mësipërme është e mjaftueshme për ju, kaloni dy seksionet e mëposhtme.

Sulmi i Vaudenay

Për të kuptuar sulmin e Vaudenay, së pari duhet të flasim pak më shumë për cifrat bllok dhe reja të enkriptimit. "Cifra bllok" është, siç u përmend më parë, një cifër që merr një çelës dhe një hyrje të caktuar me gjatësi fikse (“gjatësia e bllokut”) dhe jep një bllok të enkriptuar të së njëjtës gjatësi. Cifrat bllok përdoren gjerësisht dhe konsiderohen relativisht të sigurta. DES i pensionuar, i cili konsiderohet si cifra e parë moderne, ishte një bllok. Siç u përmend më lart, e njëjta gjë është e vërtetë për AES, i cili përdoret gjerësisht sot.

Fatke, algoritmet bllok kanë një dobësi të dukshme. Madhësia tipike e bllokut është 128 bit, ose 16 karaktere. Në mënyrë të qartë, kriptografia moderne kërkon të punojë me të dhëna hyrëse më të mëdha, dhe këtu hyn në lojë modalitetet e enkriptimit. Modaliteti i enkriptimit është, në thelb, një hile: është një mënyrë për të aplikuar në ndonjë mënyrë algoritmin bllok, i cili pranon të dhëna hyrëse vetëm të një madhësie të caktuar, në të dhëna hyrëse të gjatë arbitrare.

Sulmi Vodënè është i fokusuar në modalitetin e njohur CBC (Cipher Block Chaining, modaliteti i lidhjes së bllokut të enkriptimit). Sulmi shqyrton algoritmin bllok si një kuti magjike hermetike dhe i kalon plotësisht sigurinë e tij.

Këtu është një diagram që tregon se si funksionon modaliteti CBC:

Plus i rrethuar tregon operacionin XOR (përjashtues "O"). Për shembull, blloku i dytë i enkriptimit është marrë:

Duke kryer operacionin XOR midis bllokut të dytë të tekstit të hapur dhe bllokut të parë të enkriptimit.
Duke e enkriptuar bllokun e marrë me algoritmin bllok, duke përdorur çelësin.

Pasi që CBC përdor intensively operacionin binar XOR, le të marrim një moment për t'u rikujtuar disa nga pronësitë e tij:

Idempotenca:
Komutativiteti:
Asociativiteti:
Inverzibiliteti:
Me byte: byte n nga = (byte n nga ) (byte n nga )

Në përgjithësi, këto pronësi nënkuptojnë se nëse kemi një ekuacion që përfshin operacione XOR dhe një të panjohur, ai mund të zgjidhet. Për shembull, nëse dimë se me një të panjohur dhe me të njohura dhe , atëherë mund të mbështetemi në pronësitë e lartpërmendura për të zgjidhur ekuacionin për . Duke aplikuar XOR në të dyja anët e ekuacionit me , ne marrim . Pas një momenti, gjithçka do të bëhet shumë aktuale.

Mes skenarit tonë të Alice dhe sulmit Vodënè ka dy dallime të vogla dhe një ndryshim të madh. Dy të vogla:

Në skenarin e Alice, ajo priste që tekstet e hapura të përfundonin me karakteret a, bb, ccc dhe kështu me radhë. Në sulmin Vodënè, viktima në vend të kësaj pret që tekstet e hapura të përfundojnë N herë me byte N (në thelb hexadecimal 01 ose 02 02, apo 03 03 03 dhe kështu me radhë). Ky është një ndryshim krejtësisht kozmetik.
Në skenarin e Alicës, ishte e lehtë të thuhej nëse Alicia e pranoi mesazhin duke u bazuar në përgjigjen "Teksti i pavërtetë." Në sulmin Vodena, kërkohet një analizë më e thellë dhe realizimi i saktë është i rëndësishëm në anën e viktimës; por për shkak të shkurtësisë, le të supozojmë që kjo analizë është ende e mundshme.

Dallimi kryesor:

Pasi ne nuk përdorim të njëjtin sistem kriptografik, lidhja midis byte-ve të kontrolluara nga sulmuesi të tekstit të koduar dhe sekreteve (çelësi dhe teksti i hapur), padyshim do të jetë e ndryshme. Prandaj, sulmuesi do të duhet të përdorë një strategji tjetër për të krijuar tekstet e koduara dhe për të interpretuar përgjigjet e shërbimit.

Ky është dallimi kryesor - fragmenti i fundit i enigmes për të kuptuar sulmin Vodena, prandaj le të mendojmë për një moment përse dhe si është e mundur të organizohet një sulm oracle në CBC.

Supozoni se kemi një tekst të koduar CBC me 247 bllokë, dhe ne duam ta dekriptojmë atë. Ne mund të dërgojmë mesazhe false në server, ashtu siç mund të dërgonim mesazhe false Alicës më parë. Serveri do të dekriptojë mesazhet për ne, por nuk do të tregojë dekodimin - përkundrazi, po ashtu siç ndodhte me Alicën, serveri do të raportojë vetëm një bit informacioni: nëse teksti i hapur ka plotësim të lejueshëm apo jo.

Kujtoni se në skenarin e Alicës ne kishim marrëdhëniet e mëposhtme:

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

Le ta quajmë këtë "barazimin e Alicës". Ne kontrollonim tekstin e koduar; serveri (Alicia) shpërndante informacion të paqartë mbi tekstin e hapur të marrë; dhe kjo na lejoi të nxjerrim informacionin mbi faktorët e fundit - çelësin. Po ashtu, nëse do të mund të gjenim një lidhje të tillë për skenarin CBC, atëherë do të mund të nxirrnim disa informacione sekrete atje.

Fatmirësisht, vërtet ka marrëdhënie që mund t'i përdorim. Le të shqyrtojmë daljet e thirrjes përfundimtare të dekriptimeve të algoritmit të bllokut dhe t'i emërtojmë këto si . Po ashtu, le ta emërtojmë bllokun e tekstit të hapur dhe blloqet e tekstit të koduar . Shikoni përsëri diagramin CBC dhe vini re se çfarë rezultati merrni:

Le ta quajmë këtë "barazimin e CBC."

Në skenarin e Alicës, duke kontrolluar tekstin e enkriptuar dhe duke vëzhguar rrjedhjen e informacionit mbi tekstin e hapur të përkatshëm, ne arritëm të organizojmë një sulm që rifitova anëtarin e tretë të ekuacionit - çelësi. Në skenarin CBC ne gjithashtu kontrollojmë tekstin e enkriptuar dhe vëzhgojmë rrjedhjet e informacionit mbi tekstin e hapur të përkatshëm. Nëse analogjia është në vend, ne do të kemi mundësinë të marrim informacion mbi .

Supozoni se ne vërtet kemi rifituar , çfarë ndodh pastaj? Mirë, atëherë ne mund të nxjerrim menjëherë të gjithë bllokun e fundit të tekstit të hapur (), thjesht duke futur (i cili është në dispozicion) dhe
të fituar në ekuacionin CBC.

Pra, ne jemi optimistë në lidhje me planin e përgjithshëm të sulmit, dhe tani është koha për të punuar mbi detajet. Ne kushtojmë vëmendje mënyrës se si ndodh rrjedhja e informacionit mbi tekstin e hapur në server. Në skenarin e Alicës, rrjedhja ndodhi sepse Alicia përgjigjej me një mesazh të saktë vetëm nëse $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ përfundonte me stringun a (ose bb, dhe kështu me radhë, por shanset për të ngjarë rastësisht këto kushte ishin shumë të vogla). Po ashtu me CBC, serveri pranon mbushjen, nëse dhe vetëm nëse përfundon me hexadecimal. 01Pra, le të provonim të njëjtin truk: dërgimin e teksteve të enkriptuar false me vlerat tona false , deri sa serveri të pranojë mbushjen.

Kur serveri pranon mbushjen për ndonjë nga mesazhet tona false, kjo do të thotë se:

Tani përdorim pronën e XOR-it me byte:

Ne e dimë anëtarin e parë dhe të tretë. Dhe ne tashmë e kemi parë se kjo na lejon të rifitimi anëtarin e mbetur - bajtin e fundit nga :

Kjo gjithashtu na jep bajtin e fundit të bllokut përfundimtar të tekstit të hapur përmes ekuacionit CBC dhe pronësisë me byte.

Ne mund të përfundojmë këtu dhe të jemi të kënaqur me faktin se kemi realizuar një sulm mbi një enkriptim që teorikisht është i qëndrueshëm. Por në të vërtetë, ne mund të bëjmë shumë më tepër: ne mund të rifitojmë në të vërtetë të gjithë tekstin. Kjo kërkon një truk të caktuar që nuk ishte në skenarin origjinal të Alicës dhe nuk është një kërkesë e detyrueshme për sulmin e orakullit, por metoda është akoma për t'u studiuar.

Për ta kuptuar këtë, fillimisht kënë vëmendje se si rezultati i nxjerrjes së vlerës së saktë të bajtit të fundit Ne kemi një aftësi të re. Tani, kur falsifikojmë tekstet e kriptimit, mund të menaxhojmë bajtun e fundit të tekstit të hapur përkatës. Përsëri, kjo është e lidhur me ekuacionin CBC dhe pronën e bajtëve:

Pasi tashmë e dimë anëtarin e dytë, mund të përdorim kontrollin tonë mbi të parin për të menaxhuar të tretin. Thjesht llogarisim:

Më parë nuk mund ta bënim këtë, sepse nuk kishim bajtun e fundit .

Si na ndihmon kjo? Le të supozuam se tani do të krijojmë të gjitha tekstet e kriptimit në mënyrë që në tekstet e hapura përkatëse bajti i fundit të jetë 02. Tani serveri pranon mbushjen vetëm nëse teksti i hapur përfundon me 02 02. Pasi kemi korrigjuar bajtin e fundit, kjo do të ndodhë vetëm nëse bajti i parafundit të tekstit të hapur gjithashtu është 02. Vazhdon të dërgojmë blloqe tekstesh të falsifikuara, duke ndryshuar bajtin e parafundit, derisa serveri të pranojë mbushjen për një nga to. Në këtë moment ne marrim:

Dhe ne rikuperojmë bajtin e parafundit po ashtu siç rikuperuam bajtin e fundit. Vazhdon në të njëjtën mënyrë: e korrigjojmë dy bajtët e fundit të tekstit të hapur në 03 03, përsërisim këtë sulm për bajtin e tretë nga fundi dhe kështu me radhë, duke rikuperuar plotësisht .

Çfarë do të thotë për tekstin tjetër? Vini re se vlera në të vërtetë është $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Ne mund të vendosim çdo bllok tjetër në vend të , dhe sulmi do të jetë sërish i suksesshëm. Në të vërtetë, mund të kërkojmë nga serveri të bëjë $inline$text{BLOCK_DECRYPT}$inline$ për të dhëna të çdo lloji. Në këtë moment, loja ka përfunduar - ne mund të deshifrojmë çdo tekst të kriptimit (shikoni përsëri diagramin e deshifrimit CBC për të siguruar këtë; dhe vini re se vektori IV është publik).

Ky metodë specifike luan një rol të rëndësishëm në sulmin e orakullit, me të cilin do të përballemi më vonë.

Sulmi i Kelsit

Një person i dashur për ne, John Kelsey, ka shpjeguar parimet që qëndrojnë pas shumë sulmeve të mundshme, dhe jo vetëm detajet specifike të një sulmi konkret ndaj një cifri të veçantë. Artikulli i tij në vitin 2002 është një studim mbi sulmet e mundshme ndaj të dhënave të kompresuara të kriptuara. Mendoni se për të kryer një sulm mjafton vetëm informata se të dhënat ishin kompresuar para kriptimit? Në dukje, mjafton.

Ky rezultat i jashtëzakonshëm është i përcaktuar nga dy parime. Së pari, ekziston një korrelacion i fortë midis gjatësi të tekstit të hapur dhe gjatësi të tekstin e enkriptuar; për shumë algoritme, barazia e saktë. Së dyti, kur kryhet kompresimi, gjithashtu ekziston një korrelacion i fortë midis gjatësi të mesazhit të kompresuar dhe shkallës së „zhurmës” së tekstit të hapur, domethënë përqindjes së simboleve të pa përsëritura (termini teknik - „entropi e lartë”).

Për të parë parimin në veprim, le të shqyrtojmë dy tekste të hapura:

Teksti i hapur 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Teksti i hapur 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supozoni se të dy tekstet e hapura janë kompresuar dhe më pas janë enkriptuar. Ju merrni dy rezultate të tekstit të enkriptuar dhe duhet të guessni se cili tekst i enkriptua i korrespondon cilit tekst të hapur:

Teksti i enkriptuar 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Teksti i enkriptuar 2: DWKJZXYU

Përgjigja është e qartë. Mes teksteve të hapura vetëm teksti i hapur 1 mund të ishte kompresuar në një gjatësi të varfër si teksti i dytë të enkriptuar. Ne e kuptuam këtë, pa ditur asgjë për algoritmin e kompresimit, çelësin e enkriptimit apo madje vetë algoritmin. Në krahasim me hierarkinë e mundshme të sulmeve kriptografike, kjo është një lloj çmendurie.

Kelsi më tej tregon se nën rrethana të caktuara të pazakonta, ky parim gjithashtu mund të përdoret për të kryer një sulm oracle. Në veçanti, ai përshkruan se si një sulmues mund të rifitojë tekstin e hapur sekret, nëse mund të bëjë që serveri të enkriptojë të dhënat e formularit (teksti i hapur, pasuar nga , ndërsa ai kontrollon dhe mund në një farë mënyre të verifikojë gjatësi e rezultatit të enkriptuar.

Sidoqoftë, si në sulmet e tjera oracle, ne kemi një raport:

Sërish, ne kontrollojmë një anëtar (), shohim një rrjedhje të vogël informacioni mbi anëtarin tjetër (teksti i enkriptuar) dhe përpiqemi të rikthejmë të fundit (teksti i hapur). Pavarësisht nga analogjia, kjo është një situatë disi e pazakontë krahasuar me sulmet e tjera oracle që kemi parë.

Për të ilustruar se si mund të funksionojë një sulm i tillë, le të përdorim një skemë të imagjinuar kompresimi, që sapo e krijuam: TOYZIP. Ai kërkon vargjet e tekstit që kanë shfaqur më parë në tekst dhe i zëvendëson ato me tre byte gjithësuese, të cilat tregojnë se ku të gjendet një ekzemplar më i hershëm i vargut dhe sa herë është shfaqur atje. Për shembull, vargu helloworldhello mund të kompresohet në helloworld[00][00][05] gjatësia e 13 byte në krahasim me origjinalin 15-byte.

Le të supozojmë se një haker po përpiqet të rimarrë tekstin e hapur të formularit password=..., ku vetë fjalëkalimi është i panjohur. Sipas modelit të sulmit të Kelsey, hakeri mund të kërkojë nga serveri të kompresojë dhe pastaj të enkriptojë mesazhet e formularit (teksti i hapur, i ndjekur nga ), ku — është tekst arbitrar. Kur serveri përfundon punën, ai njofton gjatësi e rezultatit. Sulmi vazhdon si më poshtë:

Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur pa ndonjë mbushje.
Serveri: Gjatësia e rezultatit 14.
Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=a.
Serveri: Gjatësia e rezultatit 18.

Hakeri vë re: [origjinali 14] + [tre byte që zëvendësuan password=] + a

Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=b.
Serveri: Gjatësia e rezultatit 18.
Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=c.
Serveri: Gjatësia e rezultatit 17.

Hakeri vë re: [origjinali 14] + [tre byte që zëvendësuan password=c]. Kjo sugjeron se teksti origjinal i hapur përmban stringun password=c. Kështu, fjalëkalimi fillon me shkronjën c

Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=ca.
Serveri: Gjatësia e rezultatit 18.

Hakeri vë re: [origjinali 14] + [tre byte që zëvendësuan password=c] + a

Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=cb.
Serveri: Gjatësia e rezultatit 18.

(… pak më vonë…)

Hacker: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, i cili ka password=co.
Serveri: Gjatësia e rezultatit 17.

Hakeri vë re: [origjinali 14] + [tre byte që zëvendësuan password=co]. Nga e njëjta logjikë, hakeri konkludon se fjalëkalimi fillon me shkronjat co

Dhe kështu me radhë deri sa të rimarrë të gjithë fjalëkalimin.

Lexuesit i duket arsyeshëm të mendojë se kjo është një ushtrim krejtësisht akademik dhe një skenar i tillë sulmi nuk do të ndodhë kurrë në botën reale. Fatkeqësisht, siç do të shohim së shpejti, në kriptografi është më mirë të mos bësh asnjë premtim.

Ndjeshmërinë e markave: CRIME, POODLE, DROWN

Më në fund, pas një studimi të detajuar teorik, ne mund të shohim se si këto metoda aplikohen në sulme kriptografike në realitet.

CRIME

Nëse sulmi është i orientuar ndaj shfletuesit dhe rrjetit të viktimës, disa gjëra do të jenë më të lehta, disa më të vështira. Për shembull, të shohësh trafikun e viktimës është e lehtë: mjafton të ulesh së bashku me të në të njëjtin kafe me WiFi. Për këtë shkak, viktimave të mundshme (dmth. të gjithë) zakonisht u rekomandohet të përdorin një lidhje të enkriptuar. Do të jetë më e vështirë, por prapë e mundshme, kryerja e kërkesave HTTP në emër të viktimës për një faqe të jashtme (p.sh., Google). Krimineli duhet ta joshë viktimën në një faqe të keqe të internetit me një skenar që do të bëjë kërkesën. Shfletuesi i internetit automatikisht do të ofrojë cookies të sesionit përkatëse.

Kjo duket e habitshme. Nëse Bob ka hyrë në evil.com, a mund të jetë skenari në këtë faqe që thjesht kërkon nga Google të dërgojë fjalëkalimin e Bobit nëpërmjet emailit në attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Vjedhja e Kërkesave në Rrethin e Kryqëzimeve, CSRF), dhe ai ishte i njohur rreth mesit të viteve '90. Sot, nëse evil.com provon një truk të tillë, Google (ose ndonjë faqe e respektueshme) zakonisht do të përgjigjet: «Shkëlqyer, por tokeni juaj CSRF për këtë transaksion do të jetë… mmm… tri trilion e shtatë. Ju lutem, përsëritni këtë numër». Browsers modernë aplikojnë diçka të quajtur «politika e të njëjtit origjinë» (same-origin policy), sipas së cilës skenari në faqen A nuk ka qasje në informacionin e dërguar nga uebi B. Prandaj, skenari në evil.com mund të dërgojë kërkesa në google.com, por nuk mund të lexojë përgjigjet ose në fakt të përfundojë transaksionin.

Duhet theksuar se nëse Bobi nuk përdor një lidhje të enkriptuar, të gjitha këto mbrojtje janë të pavlera. Hakeri mund thjesht të lexojë trafikun e Bobit dhe të rikuperojë cookies sesioni të Google. Me atë cookie ai mund të hapë një tab të re në Google, pa e mbyllur shfletuesin e tij dhe të shfaqë veten si Bob, pa u përballur me politikat e bezdisshme të të njëjtit originë. Por, fatkeqësisht për hakerin, diçka e tillë ndodh gjithnjë e më rrallë. Interneti në përgjithësi ka shpallur një luftë ndaj lidhjeve të paenkriptuara, dhe trafiku i Bobit është shumë gjasë i enkriptuar, pëlqefshin kjo apo jo. Për më tepër, që nga fillimi i zbatimit të protokollit, trafiku gjithashtu është kompresuar para enkriptimit; kjo ishte një praktikë e zakonshme për të ulur vonesën.

Këtu hyn në lojë CRIME (Informacioni i Lehtësuar për Proporcionalitetin e Kompresimit, lehtësim i thjeshtë përmes faktorëve të kompresimit). Një dobësi që u demonstruar në shtator 2012 nga hulumtuesit e sigurisë Juliano Rizzo dhe Thai Duong. Ne tashmë kemi sqaruar tërë bazën teorike që lejon të kuptohet se çfarë ata bënë dhe si. Hakeri mund të bëjë që shfletuesi i Bobit të dërgojë kërkesa në Google dhe pastaj të përgjojë përgjigjet në rrjetin lokal në formë të kompresuar, të enkriptuar. Prandaj kemi:

Këtu hakeri kontrollon kërkesën dhe ka qasje në sniffin e trafikut, duke përfshirë madhësinë e pakove. Skema imagjinare e Kelsit u bë realitet.

Duke teorinë, autorët e CRIME krijuan një exploit që mund të vjedhë cookies sesioni për një gamë të gjerë faqesh, duke përfshirë Gmail, Twitter, Dropbox dhe Github. Kjo dobësi preku pothuajse të gjitha shfletuesit modernë të internetit, duke rezultuar në publikimin e patches që heshtazi e shpërfili funksionalitetin e kompresimit në SSL, që nuk u përdor fare. E vetmja që ishte e mbrojtur nga kjo dobësi ishte Internet Explorer, i cili kurrë nuk kishte përdorur kompresimin SSL.

POODLE

Në tetor 2014, ekipi i sigurisë në Google shkaktoi shqetësim në komunitetin e sigurisë. Ata munden të shfrytëzojnë një dobësi në protokollin SSL, të cilin e rregulluan më shumë se një dekadë më parë.

Doli që megjithëse në serverë punonte një TLSv1.2 të shkëlqyer, shumë kishin lënë mbështetje për SSLv3 të vjetruar për shkak të përputhshmërisë me Internet Explorer 6. Ne kemi folur tashmë për sulmet e de-rangimit, kështu që mund ta imagjinoni atë që ndodhte. Një sabotazh i mirë-organizuar i protokollit të dorëzimit – dhe serverët janë të gatshëm të kthehen në SSLv3 të vjetër, duke anuluar në esencë 15 vitet e fundit të hulumtimeve në fushën e sigurisë.

Për kontekstin historik, ja një përmbledhje e shkurtër e historisë së SSL deri në versionin 2 nga Matthew Green:

Transport Layer Security (TLS) është protokolli më i rëndësishëm i sigurisë në internet. [..] pothuajse çdo transaksion që bëni në internet varet nga TLS. [..] Por TLS nuk ka qenë gjithmonë TLS. Protokolli filloi jetën e tij në Netscape Communications me emrin "Secure Sockets Layer" ose SSL. Thuhen se versioni i parë i SSL ishte aq i tmerrshëm, saqë zhvilluesit mblodhen të gjitha printet e kodit dhe i varrosën në një varrezë sekrete në New Mexico. Si rezultat, versioni i parë publik i SSL në të vërtetë është versioni SSL 2. Ai është mjaft i frikshëm, dhe [..] ishte një produkt i mesit të viteve '90 që kriptografët modernë e shqyrtojnë si "shekujt e errët të kriptografisë". Shumë nga sulmet më të këqija kriptografike që njohim sot ende nuk ishin zbuluar. Si rezultat, zhvilluesit e protokollit SSLv2 duhej esencialisht të gjenin mënyrën e tyre në errësirë, dhe ata u përballën me shumë monster të tmerrshëm — për keqardhjen e tyre dhe përfitimin tonë, pasi sulmet ndaj SSLv2 lanë mësime të paçmuara për brezin pasardhës të protokollëve.

Pas këtyre ngjarjeve, në vitin 1996, kompania Netscape, e pakënaqur, e riemëroi protokollin SSL nga e para. Rezultati ishte SSL versioni 3, i cili korrigjoi disa probleme të njohura të sigurisë të paraardhësit të tij.

Fatmirësisht për hakerët, «disa» nuk do të thotë «të gjithë». Në përgjithësi, SSLv3 ofronte të gjitha blloqet e nevojshme për të realizuar një sulm të Vodenë. Protokolli përdorte një algoritëm bllokues në modin CBC dhe një skemë mbushjeje të pasigurt (kjo u korrigjua në TLS; si rrjedhojë, lind nevoja për sulm të uljes). Nëse e mbani mend skemën e mbushjes në përshkrimin tonë fillestar të sulmit të Vodenë, skema SSLv3 është shumë e ngjashme.

Por, për fat të keq për hakerët, «ngjashme» nuk do të thotë «identike». Skema e mbushjes SSLv3 ka formën «N bajta të rastësishme, të ndjekura nga numri N». Provoni të zgjidhni një bllok imagjinar të tekstit të enkriptuar në këto kushte dhe kaloni nëpër të gjitha fazat e skemës origjinale të Vodenë: do të zbuloni se sulmi nxjerr me sukses bajtin e fundit nga blloku përkatës i tekstit të hapur, por nuk shkon më tej. Dekriptimi i çdo bajti të 16-të të tekstit të enkriptuar është një hile e shkëlqyer, por kjo nuk është një fitore.

Duke u përballur me një dështim, ekipi i Google u tha të kalonte në një model kërcënimi më të fuqishëm — atë që ishte përdorur në CRIME. Nëse supozojmë se sulmuesi është një skemë e ekzekutuar në skedarin e shfletuesit të viktimës, dhe ai mund të nxjerrë cookie-t e sesionit, sulmi ende mbetet mbresëlënës. Ndërsa modeli më i gjerë i kërcënimit është më pak realist, ne tashmë kemi parë në seksionin e mëparshëm se ky model i veçantë është i realizueshëm.

Duke, duke y obligat, e sulmonit mund të vazhdojë. Mbani mend se sulmuesi e di ku shfaqet skedari i kukive të sesionit të enkriptuar në krye dhe kontrollon gjatësinë e kërkesës HTTP që e paraprin atë. Prandaj, ai është në gjendje të manipulojë kërkesën HTTP në mënyrë që të rreshtojë bajtin e fundit të kukit në përputhje me fundin e bllokut. Tani ky bajt është i përshtatshëm për dekriptim. Thjesht mund të shtoni një simbol në kërkesë, dhe bajti para fundit të kukit do të mbetet në të njëjtin vend dhe i përshtatshëm për përshtatjen e metodës së njëjtë. Sulmi vazhdon në këtë mënyrë derisa skedari i kukive të rikthehet plotësisht. Kjo quhet POODLE: Padding Oracle on Downgraded Legacy Encryption, oracle i mbushjes në enkriptim të ulur të vjetruar.

DROWN

Siç e përmendëm, SSLv3 kishte mangësi, por ishte ndryshe nga paraardhësi i tij, pasi SSLv2 i vrarë ishte një produkt i një epoke tjetër. Atje mund të ndërpritet një mesazh në mes: pranoj këtë vetëm mbi trupin tim kthehej në pranoj këtë; klienti dhe serveri mund të takoheshin në internet, të ngrinin besim dhe të shkëmbenin sekrete përpara syve të sulmuesit, i cili më pas lehtë mund të shfaqej si të dy. Kishte gjithashtu një problem me kriptografinë e eksportit, të cilin e përmendëm gjatë shqyrtimit të FREAK. Kjo ishte një Kriptografi Sodom dhe Gomorra.

Në mars 2016, një ekip kërkuesish nga fusha të ndryshme teknike u mblodh dhe bëri një zbulim të jashtëzakonshëm: SSLv2 ende përdoret në sistemet e sigurisë. Po, sulmuesit tashmë nuk mund të ulnin sesionet moderne TLS në SSLv2, pasi kjo hapësirë ishte mbyllur pas FREAK dhe POODLE, por ata ende mund të lidhen me serverët dhe të fillojnë sesione SSLv2 vetë.

Do you ask what we care about what they are doing there? They have a vulnerable session, but this shouldn't affect other sessions or the security of the server — right? Well, not exactly. Yes, that's how it should be in theory. But no — because the generation of SSL certificates imposes a certain burden, resulting in many servers using the same certificates and, consequently, the same RSA keys for TLS and SSLv2 connections. Worse still, due to a bug in OpenSSL in this popular implementation of SSL, the option to 'Disable SSLv2' effectively didn't work.

This made possible a cross-protocol attack on TLS, which was named DROWN (Decrypting RSA with Obsolete and Weakened eNcryption). Remember, this is not the same as a downgrade attack; the hacker does not need to act as a 'man-in-the-middle' and does not need to involve the client in a vulnerable session. Attackers simply initiate an insecure SSLv2 session with the server themselves, exploit the weak protocol, and recover the private server RSA key. This key is also valid for TLS connections, and from that moment on, no TLS security will save it from being compromised.

But to compromise, an effective attack against SSLv2 is needed, which allows the recovery of not only specific traffic but also the secret server RSA key. Although this is a complex scenario, researchers could choose any vulnerability, which was completely patched after SSLv2. Eventually, they found a suitable option: the Bleichenbacher attack, which we mentioned earlier and will explain in detail in the next article. SSL and TLS are protected from this attack, but some random SSL features combined with short export-grade cryptography keys made possible a specific implementation of DROWN.

At the time of publication, 25% of the top websites on the internet were vulnerable to DROWN, and the attack could be carried out with modest resources available even to mischievous lone hackers. Eight hours of computation and $440 were required to obtain the server's RSA key, and SSLv2 changed its status from 'deprecated' to 'radioactive'.

Wait, what about Heartbleed?

This is not a cryptographic attack in the sense described above; it is a buffer overflow.

Let's take a break

Filluam me disa metoda themelore: bruteforce, interpolim, ulje, ndërprotokol dhe paracaktim. Më pas shqyrtuam një teknikë të avancuar, ndoshta komponenti kryesor i sulmeve moderne në kriptografi: ky është sulmi i orakullit. Kemi kaluar një kohë të gjatë me të — dhe kuptuam jo vetëm parimin pas saj, por edhe detajet teknike të dy realizimeve specifike: sulmi i Vodenë në modin e enkriptimit CBC dhe sulmi i Kelsey ndaj protokolleve të enkriptimit me kompresim paraprak.

Gjatë rishikimit të sulmeve të uljes dhe me llogaritje paraprake, përmendëm përmbledhtas sulmin FREAK, i cili përdor të dyja metodat, ndërsa sitet e synuara ulin nivelin në çelësa të dobët dhe pastaj e ripërdorin të njëjtin çelës. Për artikullin tjetër, kemi lënë një (shumë të ngjashme) sulm Logjam, i cili synon algoritmet me çelës të hapur.

Më pas shqyrtuam edhe tri shembuj të tjerë të aplikimit të këtyre parimeve. E para, CRIME dhe POODLE: dy sulme që mbështeten në aftësinë e hakerit për të futur tekst të rastësishëm afër tekstit të synuar dhe pastaj studiuar përgjigjet e serverit dhe atëherë, duke përdorur metodologjinë e sulmit të orakullit, për të përdorur këtë informacion të thjeshtë për rikuperimin e pjesshëm të tekstit të hapur. CRIME ndoqi rrugën e sulmit të Kelsey ndaj kompresimit SSL, ndërsa POODLE përdori një variant të sulmit të Vodenë në CBC me të njëjtin efekt.

Më pas i kushtuam vëmendje sulmit ndërprotokolar DROWN, i cili vendos një lidhje me serverin përmes protokollit të vjetruar SSLv2 dhe pastaj rikuperon çelësat sekretë të serverit duke përdorur sulmin e Balychenbaher. Deri në këtë pikë, kemi kaluar përmbajtjen teknike të këtij sulmi; ashtu si Logjam, do të duhet të presë derisa të studiojmë mirë sistemet kriptografike me çelës të hapur dhe dobësitë e tyre.

Në artikullin e ardhshëm do të flasim për sulmet e avancuara — si metoda e takimit në mes (meet-in-the-middle), analiza diferenciale e kriptografisë dhe sulmi i 'ditëlindjeve'. Do të bëjmë një përshpejtim të shkurtër në sulmet përmes kanaleve anësore, dhe pastaj do të fillojmë me gjëra më të mira — sistemet kriptografike me çelës të hapur.

Burimi: habr.com