Kur flitet për "kriptografinë", disa njerëz përmendin fjalëkalimin e tyre WiFi, simbasin e gjelbër pranë adresës së faqeve të preferuara dhe sa e vështirë është të hysh në postën e dikujt tjetër. Të tjerët kujtojnë një seri vulnerabilitetesh të viteve të fundit me akronime që flasin (DROWN, FREAK, POODLE…), logot stilistike dhe paralajmërimin se duhet të përditësojnë menaxherin e tyre të shfletimit.

Kriptografia përfshin të gjitha këto, por thelbi është ndryshe. Thelbi qëndron në një kufi të hollë mes të thjeshtës dhe të komplikuarës. Disa gjëra janë të lehta për t'u bërë, por të vështira për t'u kthyer mbrapsht: për shembull, të thyhet një vezë. Të tjera janë të lehta për t'u realizuar, por të vështira për t'u rikthyer, kur një pjesë e vogël vendimtare mungon: për shembull, të hapës një derë të kyçur kur "pjesa vendimtare" është çelësi. Kriptografia studion këto situata dhe mënyrat për t'i praktikuar ato.

Gjatë viteve të fundit, koleksioni i sulmeve kriptografike është shndërruar në një zoo logosh që bërtasin, të mbushura me formula shkencore dhe ka prodhuar një ndjenjë të përgjithshme pesimiste se gjithçka është prishur. Por në të vërtetë, shumë nga sulmet janë të bazuara në disa parime të zakonshme dhe faqet e pafundme me formula shpesh reduktohen në ide që janë të lehta për t'u kuptuar.

Në këtë seri artikujsh ne do të shqyrtojmë llojet e ndryshme të sulmeve kriptografike, duke u fokusuar në parimet themelore. Në terma të përgjithshëm dhe jo domosdoshmërisht në këtë rend, ne do të flasim për këtë:

Strategjitë bazë: brute-force, analiza e frekuencave, interpolimi, zvogëlimi dhe ndërprotokollet.
Vulnerabilitetet "Markë": FREAK, CRIME, POODLE, DROWN, Logjam.
Strategjitë e avancuara: sulmet e orakullit (sulmi i Vodenë, sulmi i Kelsit); metoda e takimit në mes (meet-in-the-middle), sulmi i "ditëlindjeve", devijimi statistikor (analiza diferenciale e kriptografisë, analiza integrale e kriptografisë, etj.).
Sulmet përmes kanaleve të jashtme dhe të afërmit e tyre, metodat e analizës së dështimeve.
Sulmet në kriptografinë me çelës të hapur: rrënja kubike, dërgimi, mesazhi i lidhur, sulmi i Koppersmith, algoritmi i Poligës - Hellman, sita numerike, sulmi i Wiener, sulmi i Bleichenbacher.

Ky artikull i veçantë mbulon materialin e përmendur më sipër deri në sulmin e Kelsit.

Strategjitë bazë

Sulmi të ardhshëm janë të thjeshta në kuptimin që mund të shpjegohen pothuajse plotësisht pa detaje teknike të veçanta. Do të shpjegojmë çdo lloj sulmi në terma të thjeshtë, pa u thelluar në shembuj kompleksë ose variante të zgjeruara.

Disa nga këto sulme kanë humbur kryesisht relevancën dhe nuk janë përdorur prej shumë vjetësh. Të tjera—me përvojë, ende përhapen rregullisht te zhvilluesit e kriptosistemit të pavëmendshëm në shekullin 21. Epoka e kriptografisë moderne mund të konsiderohet se ka filluar me shfaqjen e IBM DES—kripta e parë që i përballoi të gjitha sulmet në këtë listë.

Bruit forcimi i thjeshtë

Skema e enkriptimit përbëhet nga dy pjesë: 1) funksioni i enkriptimit, i cili merr mesazhin (tekstin e hapur) në kombinim me çelësin dhe më pas krijon një mesazh të koduar—tekstin e koduar; 2) funksioni i dekryptimit, i cili merr tekstin e koduar dhe çelësin dhe krijon tekstin e hapur. Të dy enkriptimi dhe dekryptimi duhet të jenë të lehtë për t'u llogaritur me çelësin—dhe të vështira pa të.

Le të supozojmë se shohim një tekst të enkriptuar dhe po përpiqemi ta deshifrojmë atë pa ndonjë informacion shtesë (kjo quhet sulm «vetëm tekst i enkriptuar»). Nëse në një mënyrë magjike gjejmë çelësin e duhur, atëherë 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 këtu ka dy supozime të njohura. Së pari, se dimë si të kryejmë deshifrimin, pra, si funksionon sistemi i enkriptuar. Kjo është një supozim standard kur diskutohet kriptografia. Fshehja e detajeve të zbatimit të enkriptimit nga sulmuesit mund të duket si një masë shtesë sigurie, por sapo një sulmues të zbulojë këto detaje, kjo siguri shtesë humbet në mënyrë të padukshme dhe të pariparueshme. Ky është principi i Kerckhoffsit: përcjellja e sistemit në duar armike nuk duhet të krijojë shqetësime.

Së pari, ne supozojmë se çelësi i saktë ë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 zbatohet nëse teksti i koduar është shumë më i gjatë se çelësi dhe është i lehtë për t'u lexuar. Në përgjithësi, kjo ndodh në botën reale, përveç çelësave të mëdhenj e të paprakting ose manipulimeve të tjera që është më mirë të lihen mënjanë (nëse nuk ju pëlqen që ne kemi shmangur shpjegimet, ju lutemi shikoni teoremin 3.8 këtu).

Duke marrë parasysh gjithçka më sipër, lind një strategji: të kontrollosh çdo çelës të mundshëm. Kjo quhet bruteforce, dhe një sulm i tillë garanton funksionimin ndaj të gjithë kodimeve praktikisht — përfundimisht. Për shembull, bruteforce është i mjaftueshëm për të thyer kodin e Cezarit, një kod të lashtë, ku çelësi është një shkronjë nga alfabeti, që nënkupton pak mbi 20 çelësa të mundshëm.

Fatkeq për analistët e kriptografisë, rritja e madhësisë së çelësit mbron mirë nga sulmet brute. 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, një sulm i thjeshtë me forcë brute është krejtësisht i pamundur. Për të kuptuar se çfarë kemi parasysh, le të marrim superkompjuterin më të shpejtë të njohur në mes të vitit 2019: Summit i IBM, me një kapacitet pik të rreth 10^17 operacioneve në sekondë. Sot, gjatësia tipike e çelësit është 128 bit, që do të thotë 2^128 kombinime të mundshme. Për të provuar të gjitha çelësat, superkompjuterit Summit do t'i nevojitej një kohë që është rreth 7800 herë më e gjatë se mosha e Universit.

A duhet ta konsiderojmë sulmin me forcë brute si një kuriositet historik? Aspak: është një përbërës i nevojshëm në librin e gatimit të kriptoanalizës. Rrallë ndodhin aq të dobëta sa që ato mund të thyen vetëm me një sulm inteligjent, pa përdorur forcën në një mënyrë ose në një tjetër. Shumë thyerje të suksesshme fillojnë me një metodë algoritmike për të dobësuar enkriptimin e synuar dhe më pas fillojnë sulmin me forcë brute.

Analiza frekuenciale

Shumica e teksteve nuk janë të pakuptueshme. Për shembull, në tekstet në anglisht ka shumë shkronja 'e' dhe artikuj 'the'; në skedarët binarë ka shumë byte zero si mbushës midis fragmenteve të informacionit. Analiza frekuenciale është çdo sulm që shfrytëzon këtë fakt.

Një shembull kanonik i një cifri të cenueshëm për këtë sulm është cifri i zakonshëm i zëvendësimit. Në këtë cifër, çelësi përbën një tabelë me zëvendësimin e të gjitha shkronjave. Për shembull, 'g' zëvendësohet me 'h', 'o' me 'j', kështu që fjala 'go' shndërrohet në 'hj'. Ky cifër është i vështirë për t'u sulmuar me forcë brutale, pasi ekziston shumë tabela të mundshme zëvendësimi. Nëse jeni të interesuar në matematikë, gjatësia efektive e çelësit është rreth 88 bit: kjo
. Por analiza frekuenciale zakonisht e përfundon shpejt detyrën.

Le të shqyrtojmë këtë tekst cifri, të përpunuar me cifrin e zakonshëm të zëvendësimit:

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

Për shkak se Y shfaqet shpesh, përfshirë në fund të shumë fjalëve, ne mund të supozojmë paraprakisht se kjo është shkronja e:

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

Për çift XD përsëritet në fillim të disa fjalëve. Në veçanti, kombinimi XDeLe qartë sugjeron fjalën këto ose atje, prandaj vazhdojmë:

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

Tani le të supozojmë se L përputhet r, A — a dhe kështu me radhë. Ndoshta do të duhet të bëni disa përpjekje, por krahasuar me një bruteforce të plotë, kjo sulm rikthen tekstin origjinal në kohë të shkurtër:

ka më shumë gjëra në qiell dhe tokë, Horatio, sesa janë të ëndërruara në filozofinë tuaj

Për disa, zgjidhja e këtyre 'kriptogramëve' është një hobi tërheqës.

Ideja e analizës së frekuencës është më themelore se sa duket në një shikim të parë. Ajo është e aplikueshme për enigma shumë më të komplikuara. Gjatë gjithë historisë, konstruksione të ndryshme të enigmave kanë përpiquar t'i rezistojnë një sulmi të tillë përmes 'zëvendësimit polialfabetik'. Këtu, gjatë procesit të enkriptimit, tabela e zëvendësimit të shkronjave ndryshon në mënyra komplekse, por të parashikueshme, që varen nga çelësi. Të gjitha këto enigma në kohën e tyre ishin të konsideruara të vështira për t'u thyer; megjithatë, analiza e thjeshtë e frekuencës përfundimisht i ka kapërcyer ato.

Një nga kodet më ambicioze poli-alfa në histori dhe ndoshta më i njohuri, ishte kodi "Enigma" gjatë Luftës së Dytë Botërore. Ai ishte relativisht i komplikuar në krahasim me paraardhësit, por si rezultat i një pune të gjatë dhe të palodhur, analistët britanikë të kriptografisë e thyen atë me anë të analizës së frekuencës. Sigurisht, ata nuk qenë në gjendje të zhvillonin një sulm të elegancshëm, siç u tregua më sipër; ata duhej të krahasojnë çiftet e njohura të teksteve të hapura dhe të koduara (e njohur si "sulmi i bazuar në tekstin e hapur") dhe madje të provokojnë përdoruesit e "Enigma" të kodonin mesazhe të caktuara për të analizuar rezultatin ("sulmi i bazuar në tekstin e hapur të rastësishëm"). Por kjo nuk e lehtësoi fatin e ushtrive të mundura të armiqve dhe të nëndetëses së mbytur.

Pas këtij triumfi, analiza e frekuencës zhduku nga historia e kriptografisë. Kodet e epokës moderne digjitale janë krijuar për të punuar me bita, jo me letra. Çfarë është më e rëndësishme, këto kode janë projektuara me një kuptim të errët të asaj që më vonë u bë e njohur si ligji i Shnajerit: çdo kush mund të krijojë një algoritëm enkriptimi që nuk mund ta thyejë vetë. Nuk mjafton që sistemi i enkriptimit të duket i komplikuar: për të provuar vlerën e tij, ai duhet të kalojë një rishikim të pamëshirshëm të sigurisë nga shumë kriptoanalistë, të cilët do të bëjnë gjithçka për ta thyer enkriptimin.

Kalkulimet paraprake

Le të marrim qytetin hipotezik Prekom Heights me popullsi 200,000. Në secilën shtëpi të qytetit ndodhen pasuri me një mesatare prej $30,000, por jo më shumë se $50,000. Tregu i sigurisë në Preko është monopolizuar nga kompanitë ACME Industries, e cila prodhon blloqet legjendare të derës së klasës Coyote ™. Sipas analizave ekspertëve, blloku i klasës Coyote mund të thyehet vetëm nga një makine shumë të komplikuar, krijimi i së cilës kërkon afërsisht pesë vjet dhe $50,000 investime. A është qyteti në siguri?

Me siguri jo. Në fund të fundit, do të dalë një kriminel mjaft ambicioz. Ai do të mendojë: “Po, do të kem shpenzime të mëdha paraprake. Pesë vjet pritjeje të duruar dhe $50,000. Por pas përfundimit të punës, do të kem qasje te të gjitha pasuritë e këtij qyteti. Nëse i luaj mirë kartat e mia, kjo investim do të kthehet me shumëfish.

Po ashtu edhe në kriptografi. Sulmet ndaj një algoritmi të caktuar analizohen pa mëshirë për kosto dhe përfitime. Nëse raporti është në favor, sulmi nuk do të ndodhë. Por sulmet që godasin menjëherë shumë potenciale viktima, pothuajse gjithmonë ia vlejnë, dhe në këtë rast praktika më e mirë e dizajnit është të supozosh se ato kanë filluar që në ditën e parë. Kemi, në thelb, një version të ligjit të Murphy-t në kriptografi: 'Gjithçka që mund të prishë sistemin, do ta prishë sistemin.'

Një shembull më i thjeshtë i një sistemi kriptoje, i ndjeshëm ndaj sulmeve me llogaritje paraprake, është algoritmi me një metodë të përhershme pa përdorimin e çelësit. Kështu ka ndodhur me cifrën e Cezarit, i cili thjesht e zhvendos secilën shkronjë të alfabetit për tre shkronja përpara (tabela është e lidhur, kështu që shkronja e fundit në alfabet shifrohet nga e treta). Këtu persëri shfaqet parimi i Kerckhoffsit: sa herë që sistemi është thyer, ai është thyer përherë.

Koncepci është e thjeshtë. Edhe një zhvillues i fillestarit të sistemeve të kriptografisë, me siguri, është në dijeni të kërcënimit dhe do të përgatitet përkatësisht. Nëse shikoni evolucionin e kriptografisë, sulme të tilla kanë qenë të pavend për shumicën e cifrave, duke filluar nga versionet e përmirësuara të cifrës së Cezarit, deri në rënien e cifrave poli-alfa. Këto sulme janë rikthyer vetëm me fillimin e epokës moderne të kriptografisë.

Ky rikthim është shkaktuar nga dy faktorë. Së pari, përfundimisht, janë shfaqur sisteme kriptografike mjaft të komplikuara, ku mundësia e shfrytëzimit pas thyerjes nuk ishte e qartë. Së dyti, kriptografia ka marrë një përhapje të tillë, saqë miliona jo-profesionistë çdo ditë merrnin vendime për ku dhe cilat pjesë të kriptografisë të përdornin përsëri. Kaluar një kohë, për ekspertët ka qenë e qartë se janë shfaqur rreziqe dhe kanë ngritur alarm.

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

Interpolimi

Para juaj është detektivi i njohur Sherlock Holmes, i cili po bën një sulm me interpolim ndaj doktorit të papërgatitur Watson:

Menjëherë e kuptova se ishit nga Afganistani… Rrjedha e mendimeve të mia ishte kështu: «Ky njeri është, nga tipi, një mjek, por silueta e tij është ushtarake. Pra, mjek ushtarak. Ai sapo ka ardhur nga tropikët — fytyra i është errësuar, por kjo nuk është hije natyrore e lëkurës së tij, pasi kyçet e tij janë shumë më të bardha. Fytyra është e dobësuar — duket se ka kaluar mjaft vështirësi dhe ka përjetuar sëmundje. Është plagosur në duar të majtë — e ndan atë pa lëvizur dhe pak thelbësisht natyrshëm. Ku mund ta ketë kaluar një mjek ushtarak britanik vështirësi dhe të marrë një plagë nën tropikë? Sigurisht, në Afganistan». E gjithë rrjedha e mendimeve nuk zuri më shumë se një sekondë. Dhe ja, thashë që keni ardhur nga Afganistani, dhe ju u surprizuat.

Nga çdo provë të veçantë, Holmes mund të nxjerrë shumë pak informacion. Ai mund të arrijë në përfundimin e tij vetëm duke shqyrtuar të gjitha ato së bashku. Po ashtu funksionon sulmi me interpolim, duke shqyrtuar çiftet e njohura të teksteve të hapura dhe të enkriptura, të marra si rezultat i aplikimit të së njëjtës çelës. Nga secili çift, nxirren vëzhgime të veçanta që lejojnë të arrihet një përfundim i përgjithshëm mbi çelësin. Të gjitha këto arsyetime janë të paqarta dhe duken të padobishme, derisa papritur arrijnë në një masë kritike dhe çojnë në një përfundim të vetëm të mundshëm: siçdo që të jetë i pabesueshëm, ai duhet të jetë i vërtetë. Pas kësaj, ose çelësi zbulon ose procesi i dekodimit bëhet aq i përpunuar, saqë mund të shumëzohet.

Të ilustrojmë me një shembull të thjeshtë si funksionon interpolimi. Le të supozojmë se duam të lexojmë ditarin personal të armikut tonë, Bobit. Ai kodon çdo numër në ditarin e tij me një sistem të thjeshtë kriptografik që e mësoi nga një reklamë në revistën 'Tallja me Kriptografinë'. Sistemi funksionon si më poshtë: Bobi zgjedh dy numra që i pëlqejnë: dhe . Që nga ky moment, për të koduar çdo numër , ai llogarit . Për shembull, nëse Bobi zgjodhi dhe , atëherë numri do të kodosh si .

Le të supozojmë se më 28 dhjetor vëmë re se Bobi po gdhend diçka në ditarin e tij. Kur të përfundojë, ne do ta marrim pa u vënë re dhe do të shikojmë shënimin e fundit:

Data: 235/520
I dashur ditar,
Sot ishte një ditë e mirë. Pas 64 ditësh 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ë seriozë për të ndjekur Bobin në takimin e tij (në këtë skenar ne jemi 15 vjeç), është kritikisht e rëndësishme të dimë datën dhe adresën e Alisës. Fatmirësisht, ne vërejmë se sistemi kriptografik i Bobit është i ndjeshëm ndaj sulmit të interpolimit. Mund të mos e dimë dhe , porë ne e dimë datën e sotme, kështu që kemi dy çifte "teksti i hapur - tekstin e enkriptuar". Pra, dimë që enkriptohet në , dhe — në . Kështu, do ta shkruajmë:

Pasi që kemi 15 vjet, ne tashmë e dimë për sistemin e dy ekuacioneve me dy ndryshore, që në këtë rast është e mjaftueshme për të gjetur dhe pa ndonjë problem të veçantë. Çdo çift "teksti i hapur - tekstin e enkriptuar" imponon një kufizim mbi çelësin e Bobit, dhe dy kufizime së bashku janë të mjaftueshme për të rikonstruktuar plotësisht çelësin. Në shembullin tonë, përgjigjja dhe (në , kështu që 26 në ditar përputhet me fjalën ‘the one’, pra ‘ajo e vetmja’ - shën. red.).

Sulmet e interpolimit, sigurisht, nuk kufizohen në këto shembuj kaq të thjeshtë. Çdo sistem kriptografik që reduktohet në një objekt matematikor të kuptueshëm dhe një listë parametrash, rrezikohet nga sulmi i interpolimit - sa më i qartë të jetë objekti, aq më i lartë është rreziku.

Të rinjtë shpesh ankojnë se kriptografia është "art i krijimit të gjërave sa më të shëmtuara". Gjithsesi, shumë është faji i sulmeve të interpolimit. Boba mund të përdorë një dizajn të bukur matematikor ose të ruajë konfidencialitetin e takimit me Alisën - por fatkeqësisht, zakonisht nuk mund të fitosh të dyja. Kjo do të bëhet krejt e qartë kur në fund të kalojmë në temën e kriptografisë me çelës të hapur.

Cross-protocol/jeshtrembëro

Në filmin "Illusion of Deception" (2013) një grup iluzionistësh përpiqet të mashtrojë për të marrë të gjithë pasurinë e magnatit të korruptuar të sigurimeve, Arthur Tressler. Për të aksesuar llogarinë bankare të Arthur, iluzionistët duhet të paraqesin ose emrin e përdoruesit dhe fjalëkalimin e tij, ose ta bëjnë atë të shfaqet personalisht në bankë dhe të marrë pjesë në skemë.

Të dy variantet janë shumë të vështira; djemtë janë mësuar të shfaqen në skenë, e jo të marrin pjesë në operacione të shërbimeve të fshehta. Prandaj, ata zgjedhin një mundësi të tretë: bashkëpunëtori i tyre telefonon bankën dhe pretendon se është Arturi. Banka bën disa pyetje për të verifikuar identitetin, si emri i xhaxhait dhe emri i kafshës shtëpiake të parë; heronjtë tanë këtë informacion e sigurojnë lehtësisht nga Arturi përmes një inxhinierie sociale të zgjuar. Të dhëna nga Arturi këtë informacion e sigurojnë lehtësisht përmes një inxhinierie sociale të aftë.. Nga ky moment, siguria e shkëlqyer e fjalëkalimit nuk ka më rëndësi.

(Sipas legjendës urbane, e cila ne e kemi verifikuar personalisht dhe konfirmuar, kriptografi Eli Bihem njëherë u përball me kasieren e bankës, e cila insistonte për vendosjen e një pyetjeje sekrete. Kur kasierja e pyeti emrin e gjyshes nga ana e nënës, Bihem filloi të diktojë: 'Shkronja e madhe X, e vogla y, tri…').

Në kriptografi, po ashtu, nëse për mbrojtjen e të njëjtit aktiv përdoren paralelisht dy protokolle kriptografike, ku njëri është shumë më i dobët se tjetri, sistemi përfundimtar bëhet vulnerabël ndaj një sulmi ndër-protokol, kur sulmohet protokolli më i dobët për të arritur tek shpërblimi, pa prekjen e atij më të fortë.

Në disa raste të komplikuara, nuk mjafton thjesht të lidhemi me serverin përmes një protokolli më të dobët, por kërkohet pjesëmarrja e padëshiruar e një klienti legjitim. Kjo mund të organizohet përmes asaj që quhet sulmi i rënies (downgrade). Për të kuptuar këtë sulm, le të supozojmë se iluzionistët tanë kanë një detyrë më të komplikuar se në film. Le të supozojmë se punonjësi i bankës (kasieri) dhe Arturi kanë pasur disa rrethana të paparashikuara, duke rezultuar në një dialog të tillë:

Hakeri: Halo? Kjo është Arthur Tressler. Doja të rikthej fjalëkalimin tim.
Kasieri: Shumë mirë. Të lutem, shiko në librin tënd personal të kodeve sekrete, faqe 28, fjala 3. Të gjitha mesazhet që vijnë do të jenë të koduara duke përdorur këtë fjalë të veçantë si çelës. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Hakeri: Hej-hej, priti, priti. A është kjo e vërtetë e nevojshme? A nuk mund të flasim thjesht si njerëz të zakonshëm?
Kasieri: Nuk e këshilloj këtë.
Hakeri: Unë thjesht… dëgjo, kam pasur një ditë të keqe, e kupton? Unë jam klient VIP dhe nuk jam në humor për të kërkuar në këto libra të çmendur të kodeve.
Kasieri: Mirë. Nëse insistoni, zoti Tressler. Çfarë dëshironi?
Hakeri: Ju lutem, do të doja të transferoja të gjitha paratë e mia në Fondin Kombëtar të Viktimave të Arthur Tressler.
(Pauzë).
Kasieri: Pra, e kuptoj. Ju lutem, jepni pin-in tuaj për transaksionet e mëdha.
Hakeri: Pin-in tim çfarë?
Kasieri: Me kërkesën tuaj personale, transaksionet e këtij madhësie kërkojnë hyrjen e pin-it për transaksione të mëdha. Ky kod ju është dhënë kur keni hapur llogarinë.
Hakeri:… E kam humbur. A është vërtet e nevojshme? A nuk mund ta miratoni thjesht transaksionin?
Kasieri: Jo. Më vjen keq, zoti Tressler. Përsëri, kjo është një masë sigurie që kërkuat. Nëse doni, mund të dërgojmë një pin të ri në kutinë tuaj postare.

Heronjtë tanë kanë vendosur të ndalin operacionin. Ata po përgjojnë disa transaksione të mëdha të Tressler, shpresojnë të dëgjojnë pin-in; por çdo herë biseda kthehet në një gjuhë të koduar, para se të dëgjojnë diçka interesante. Së fundi, një ditë të bukur, zbatojnë planin. Ata presin me durim momentin kur Tressler duhet të bëjë një transaksion të madh në telefon, ai lidhet në linjë, pastaj...

Tressler: Përshëndetje. Doja të bëja një transaksion të largët, ju lutem.
Kasieri: Shkëlqyeshëm. Ju lutem, shikoni në librin tuaj personal të kodeve sekrete, faqja…
(Hakeri shtyp butonin; zëri i kasieres shndërrohet në një zhurmë të paqclear.)
Kasieri: — #@$#@$#*@$$@#* do të shkruhet me këtë fjalë si çelës. AAAYRR PLRQRZ MMNJK LOJBAN…
Tressler: Më falni, nuk e kuptova plotësisht. Një herë tjetër? Në cilën faqe? Cila fjalë?
Kasieri: Kjo është faqja @#$@#*$)#*#@()#@$(#@*$(#@*.
Tressler: Çfarë?
Kasieri: Fjala numër vinte @$#@$#%#$.
Tressler: Seriozisht! Mjaft më! Ti me protokollin tënd të sigurisë — është një cirk. E di që mund ta bisedosh normalisht me mua.
Kasieri: Nuk e këshilloj...
Tressler: Dhe unë nuk të këshilloj që të humbasësh 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ë bëjmë këtë marrëveshje apo jo?
Kasieri:... po. Mirë. Çfarë dëshiron?
Tressler: Dëshiroj të transferoj $20,000 në kompaninë Lord Business Investments, numri i llogarisë…
Kasieri: Një minutë, ju lutem. Kjo është një marrëveshje e madhe. Ju lutem, jepni pin-in tuaj për transaksione të mëdha.
Tressler: Çfarë? Ah, sigurisht. 1234.

Këtu është një sulm në rënie. Protokolli më i dobët “thjesht flisni drejtpërdrejt” ishte menduar si opsioni për rast të fundit. Dhe megjithatë, jemi këtu.

Ju mund të pyesni, kush është në mendje të shëndoshë që do të projektonte një sistem të tillë të tipit "i sigurt, derisa të kërkohet e kundërta", siç përshkruhet më sipër. Por ashtu si bankat imagjinare marrin rrezik për të mbajtur klientët që nuk i pëlqejnë kriptografinë, ashtu edhe sistemet në përgjithësi shpesh priren të përmbushin kërkesat që janë indiferente ose madje haptazi armiqësore ndaj sigurisë.

Një histori e tillë ndodhi me protokollin SSLv2 në vitin 1995. Qeveria e SHBA kishte filluar prej kohësh ta trajtonte kriptografinë si armë, e cila ishte më mirë të mbahej larg armiqve të jashtëm dhe të brendshëm. Fragmente kodi, përveçse miratonin eksportin nga SHBA, shpesh i nënshtroheshin kushteve të qëllimshme për dobësimin e algoritmit. Kompanitë Netscape, zhvilluese e shfletuesit më të njohur Netscape Navigator, iu dha miratimi për SSLv2 vetëm me një çelës RSA 512 bit të fillimisht të brishtë (dhe 40 bit për RC4).

Në fund të mijëvjeçarit, rregullat u zbutën dhe aksesimi në kriptimin modern u bë gjerësisht i disponueshëm. Megjithatë, klientët dhe serverët për shumë vite mbajtën kriptimin e dobësuar "eksport" për shkak të të njëjtës inercie që mban në mbështetje çdo sistem të vjetruar. Klientët mendonin se mund të takonin një server që nuk mbështeste asgjë tjetër. Serverët bënë të njëjtën gjë. Sigurisht, protokolli SSL parashikon që klientët dhe serverët kurrë nuk duhet të përdorin një protokoll të dobët kur një më i mirë është në dispozicion. Por e njëjta premisë vepronte edhe për Tressler dhe bankën e tij.

Kjo teori u aplikua në dy sulme të mëdha, 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. Së pari, në shkurt u publikuan detajet e sulmit FREAK, dhe pas tre muajsh një sulm tjetër të ngjashëm me emrin Logjam, të cilin do ta diskutojmë më në detaje kur kalojmë në sulmet ndaj kriptografisë me çelës të hapur.

Vulnerabiliteti FREAK (në të njëjtën mënyrë e njohur si «Smack TLS») u shfaq kur kërkuesit analizuan implementimet e klientit/serverit TLS dhe zbuluan një defekt interesante. Në këto implementime, nëse klienti as nuk kërkon përdorimin e kriptografisë së dobët të eksportit, por serveri gjithsesi përgjigjet me ato çelësa — klienti thotë «Mirë» dhe kalon në një grup të dobët të cipherave.

Në atë kohë, të gjithë e konsideronin kriptografinë e eksportit si të vjetruar dhe të ndaluar për t'u përdorur, kështu që sulmi u bë një shok i vërtetë dhe preku shumë fusha të rëndësishme, duke përfshirë faqet e Shtëpisë së Bardhë, IRS dhe NSA. Më e keqja, doli se shumë serverë të prekshëm ishin optimizuar për performancë duke ripërdorur të njëjtët çelësa, në vend të krijimit të të rinjve për çdo seancë. Kjo lehtësoi gjithashtu një sulm me parakalkulim: thyerja e një çelësi mbeti relativisht e shtrenjtë (100 $ dhe 12 orë në momentin e publikimit), por kostoja praktike e sulmit ndaj një lidhjeje u ul ndjeshëm. Mjafton të gjesh një herë çelësin e serverit — dhe të thyhet kriptimi për të gjitha lidhjet e mëvonshme që nga ajo moment.

Dhe para se të vazhdojmë më tej, duhen përmendur disa sulme të avancuara…

Sulmi i orakullit

Moxie Marlinspike është më së shumti i njohur si babai i mesazhereve kriptografike me platforma të ndryshme Signal; por personalisht na pëlqen një nga risitë e tij më pak të njohura — parimi i shkatërrimit kriptografik (Cryptographic Doom Principle). Duke e përshtatur pak, 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 dënuar’. Ose në një formë më të ashpër: ‘Mos merr informacion nga armiku për përpunim, dhe nëse e bën, së paku mos e tregoni rezultatin’.

Lëmë mënjanë mbushjet e buffers, injeksionet e komandave dhe kështu me radhë; ato e kalojnë këtë diskutim. Shkelja e ‘parimit të shkatërrimit’ çon në thyerje serioze të kriptografisë, për shkak se protokolli sillet pikërisht ashtu siç është e parashikuar.

Për shembull, le të marrim një konstrukcion të imagjinuar me një enkriptim të dobët zëvendësimi dhe pastaj të demonstrojmë një sulm të mundshëm. Ndërsa kemi parë tashmë një sulm ndaj enkriptimit të zëvendësimit përmes analizës së frekuencës, kjo nuk është vetëm 'një mënyrë tjetër për të thyer të njëjtin enkriptim'. Përkundrazi, sulmet Oracle janë një shpikje shumë më moderne, e cila është e aplikueshme në shumë situata kur analiza e frekuencës dështon, dhe do të shohim një demonstrim të kësaj në seksionin e ardhshëm. Në këtë rast, enkriptimi i thjeshtë është zgjedhur vetëm për ta bërë shembullin më të kuptueshëm.

Pra, Alisa dhe Boba po komunikojnë përmes një enkriptimi të thjeshtë zëvendësimi, duke përdorur një çelës që është i njohur vetëm për ta. Ata janë shumë të kujdesshëm për gjatësi e mesazheve: gjatësi e tyre është pikërisht 20 karaktere. Prandaj, ata ranë dakord që nëse dikush dëshiron të dërgojë një mesazh më të shkurtër, duhet të shtojë ndonjë tekst të rremë në fund të mesazhit që të jetë pikërisht 20 karaktere. Pas disa diskutimesh, ata vendosën se do të pranonin vetëm tekstet e rreme të mëposhtme: a, bb, ccc, dddd etj. Kështu, teksti i rremë i çdo nevoje të gjatë është i njohur.

Kur Alice ose Bobo merr një mesazh, së pari ata kontrollojnë nëse mesazhi ka gjatësi të saktë (20 karaktere) dhe sufiksi është tekst i saktë dëshmues. Nëse jo, ata përgjigjen me një mesazh gabimi përkatës. Nëse gjatësi dhe tekst dëshmues janë të rregullt, marrësi lexon mesazhin dhe dërgon një përgjigje të enkriptuar.

Në procesin e sulmit, sulmuesi e paraqet veten si Bobo dhe dërgon mesazhe të rreme për Alice. Mesazhet janë krejtësisht pa kuptim, sepse sulmuesi nuk ka çelësin dhe prandaj nuk mund të falsifikojë një mesazh të dobishëm. Por për shkak se protokolli shkel parimin e fatkeqësisë, sulmuesi prapë mund ta joshë Alicen në grackë, në mënyrë që ajo të zbulojë informacionin rreth çelësit, siç tregohet më poshtë.

Hakeri: PREWF ZHJKL MMMN. LA
Alice: Teksti i dëshmuesit është i pavlefshëm.
Hakeri: PREWF ZHJKL MMMN. LB
Alice: Teksti i dëshmuesit është i pavlefshëm.
Hakeri: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

Sulmuesi nuk ka asnjë ide se çfarë tha Alice, por vëren që simboli C duhet të përputhet a, pasi Alice pranoi tekstin dëshmues.

Hakeri: REWF ZHJKL MMMN. LAA
Alice: Teksti i dëshmuesit është i pavlefshëm.
Hakeri: REWF ZHJKL MMMN. LBB
Alice: Teksti i dëshmuesit është i pavlefshëm.
Pas një serie përpjekjesh…
Hakeri: REWF ZHJKL MMMN. LGG
Alice: Teksti i dëshmuesit është i pavlefshëm.
Hakeri: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Edhe kështu, hakeri nuk ka asnjë idenë se çfarë tha Alice, por vëren se H duhet të përputhet me b, pasi Alice pranoi tekstin e rremë.

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

Në një shikim të parë, metoda duket si një sulm i bazuar në tekstin e hapur të përzgjedhur. Në fund të fundit, sulmuesi përzgjedh tekstet e koduara, dhe serveri i përpunon ato pa ndërlikime. Dallimi kryesor që i bën këto sulme të mundshme në botën reale është se sulmuesi nuk ka nevojë për qasje në dekriptim të vërtetë — mjafton përgjigjja e serverit, madje edhe një e tillë kaq e padëmshme si "Teksti i rremë është gabim."

Edhe pse kjo sulm specifik është edukative, nuk duhet të përqendroheni shumë në detajet e skemës "tekst fals", në kriptosistemin e përdorur ose në sekuencën e saktë të mesazheve të dërguara nga sulmuesi. Ideja kryesore qëndron se si Aleksi reagon ndryshe, duke u bazuar në karakteristikat e teksteve të hapura, dhe e bën këtë pa verifikuar nëse teksti përkatës i koduar vjen në të vërtetë nga një palë të besueshme. Kështu, Aleksi i lejon sulmuesit të nxjerrë informacione sekrete nga përgjigjet e saj.

Në këtë skenar mund të ndryshoni shumë gjëra. Simbolet që reagojnë nga Alisa, apo vetë ndryshimi në sjelljen e saj, apo madje edhe sistemi kriptografik që përdoret. Por parimi do të mbetet i njëjtë, dhe sulmi në përgjithësi do të mbetet i vlefshëm në një formë ose në tjetër. Realizimi bazë i këtij sulmi ndihmoi për të zbuluar disa gabime sigurie, të cilat do t'i shqyrtojmë së shpejti; por përpara kësaj, duhet të mësojmë disa mësime teorike. Si ta përdorim këtë "skenar të Alisës" në një sulm që mund të funksionojë mbi një kodim modern? Është vallë e mundur, madje dhe në teori?

Në vitin 1998, kriptografi zviceran Daniel Bleichenbacher e përfundoi pozitivisht këtë pyetje. Ai demonstroi një sulm oracle në një sistem kriptografik të përdorur gjerësisht me çelës publik RSA, duke përdorur një skemë të caktuar mesazhesh. Në disa implementime të RSA, serveri përgjigjet me mesazhe të ndryshme gabimi, në varësi të faktit nëse teksti i hapur përputhet me skemën apo jo; kjo ishte e mjaftueshme për të realizuar sulmin.

Katër vjet më vonë, në vitin 2002, kriptografi francez Serge Vaudenay demonstroi një sulm orakulli, pothuajse identik me atë që përshkruhet më sipër në skenarin e Alicës — me përjashtim se në vend të një cifre të sajuar, ai thëri një klasë të tërë respektonte të kriptografive moderne që njerëzit vërtetë i përdorin. Veçanërisht, sulmi i Vaudenay synon kriptografit me madhësi fikse hyrjeje ("kriptografit bllok") kur ata përdoren në atë që quhet "modi i enkriptimit CBC" dhe me një skemë të caktuar mbushjeje të njohur, kryesisht ekuivalente me atë në skenarin e Alicës.

Gjithashtu në vitin 2002, kriptografi amerikan John Kelsey — bashkëautor Twofish — propozoi sulme të ndryshme orakulli ndaj sistemeve që kompresojnë mesazhet e më pas i enkriptojnë ato. Më e dukshme mes tyre ishte sulmi që shfrytëzonte faktin se shpesh mund të përfundohej gjatësia origjinale e 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ë poshtë ofrojmë një përshkrim më të detajuar të sulmeve Vodene dhe Kelsi (do të japim një përshkrim më të detajuar të sulmit Bleichenbacher kur kalojmë te sulmet në kriptografinë me çelës të hapur). Pavarësisht të gjitha përpjekjeve tona, teksti bëhet paksa teknik; prandaj, nëse informacionet e mësipërme janë të mjaftueshme për ju, kaloni dy seksionet e ardhshme.

Sulmi Vodene

Për të kuptuar sulmin Vodene, fillimisht duhet të flasim pak më për blloqet e kriptografisë dhe modalitetet e enkriptimit. "Blloku i kriptografisë" është, siç është përmendur, një kriptografi që merr një çelës dhe një hyrje me një gjatësi të caktuar fikse ("gjashtësia e bllokut") dhe jep një bllok të enkriptuar me të njëjtën gjatësi. Blloqet e kriptografisë përdoren gjerësisht dhe konsiderohen relativisht të sigurta. DES-i, i cili tani është tërhequr nga përdorimi, konsiderohet si kriptografi e parë moderne, ishte bllok. Ashtu siç përmendet më sipër, e njëjta gjë vlen edhe për AES, i cili përdoret shumë sot.

Fatkeqësisht, algoritmet bllok kanë një dobësi të dukshme. Madhësia tipike e bllokut është 128 bit, ose 16 karaktere. Është e qartë se kriptografia moderne kërkon të punojë me të dhëna hyrëse që kanë madhësi më të madhe, dhe këtu hyjnë në përdorim modet e enkriptimit. Moda e enkriptimit - në thelb është një zgjidhje: është një mënyrë për të aplikuar në një farë forme algoritmin bllok, i cili pranon vetëm të dhëna hyrëse të një madhësie të caktuar, në të dhëna hyrëse me gjatësi të rastësishme.

Sulmi Vodenë është i fokusuar në modin e njohur CBC (Cipher Block Chaining, moda e ndërlidhjes së bllokut të tekstit të enkriptuar). Sulmi e trajton algoritmin bllok të bazës si një kuti magjike të paafërt dhe e anashkalon plotësisht sigurinë e tij.

Ja një diagram që tregon se si funksionon moda CBC:

Përzgjatja e rrethuar tregon operacionin XOR (përjashtues "O`). Për shembull, blloku i dytë i tekstit të enkriptuar është marrë:

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

Duke CBC përdor intensivisht operacionin binar XOR, le të shfrytëzojmë këtë moment për të kujtuar disa nga veçoritë e tij:

Idempotenca:
Komutativiteti:
Asociativiteti:
Vetë-zhvlerësimi:
Për byte: byte n nga = (byte n nga ) (byte n nga )

Në përgjithësi, këto veçori nënkuptojnë që nëse kemi një ekuacion që përfshin operacione XOR dhe një të panjohur, mund ta zgjidhim atë. Për shembull, nëse dimë se me të panjohur dhe të njohura dhe , atëherë mund të mbështetemi në veçoritë e mësipërme për të zgjidhur ekuacionin për . Duke aplikuar XOR në të dyja anët e ekuacionit me , arrijmë . Nga një moment, gjithçka do të bëhet shumë e rëndësishme.

Në skenarin tonë të Alice dhe sulmin e Vodenë, ka dy dallime të vogla dhe një dallim kryesor. Dy dallime të vogla:

Në skenarin e Alice, ajo priste që tekstet e hapura të përfundonin me simbolet a, bb, ccc dhe kështu me radhë. Në sulmin e Vodenë, viktima në vend të kësaj pret që tekstet e hapura të përfundonin N herë me byte N (domethënë, 01 ose 02 02, ose 03 03 03 dhe kështu me radhë). Ky është një dallim krejtësisht kozmetik.
Në skenarin e Alicës, ishte e lehtë të thuhej nëse Alicia pranoi mesazhin, nga përgjigja "Teksti i gabuar i mbushur". Në sulmin Vodena është e nevojshme një analizë më e thelluar dhe realizimi i saktë në anën e viktimës është i rëndësishëm; por për shkak të shkurtimit, le të supozojmë se kjo analizë ende është e mundur.

Dallimi kryesor:

Duke qenë se ne nuk po përdorim të njëjtën kriptosistemë, lidhja midis bajtave të kontrolluar nga sulmuesi të tekstit të koduar dhe sekretet (çelësi dhe teksti i hapur) do të jetë ndryshe, sigurisht. Prandaj, sulmuesi do të duhet të përdorë një strategji tjetër për të krijuar tekste të koduara dhe për të interpretuar përgjigjet e serverit.

Ky është dallimi kryesor — fragmenti i fundit i enigmës për të kuptuar sulmin Vodena, kështu që le të mendojmë për një moment se pse dhe si mund të organizohet një sulm orakulli mbi CBC.

Supozoni se kemi një tekst të koduar CBC me 247 blloqe, dhe duam ta çkodojmë atë. Ne mund të dërgojmë mesazhe të rreme në server, ashtu siç mund të dërgonim mesazhe të rreme Aliçës. Serveri do të na çkodojë mesazhet, por nuk do të tregojë çkodimin — në vend të kësaj, si në rastin e Aliçës, serveri do të na informojë vetëm për një bit informacioni: nëse teksti i hapur ka mbushje të pranueshme apo jo.

Kujtoni se në skenarin e Aliçës, kishim këto lidhje:

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

Le të quajmë këtë «barazimin e Aliçës». Ne kontrollonim tekstin e koduar; serveri (Aliça) tregonte informacion të paqartë rreth tekstit të hapur të pranuar; dhe kjo na lejoi të nxjerrim informacion mbi faktorët e fundit — çelësin. Në mënyrë të ngjashme, nëse mund të gjejmë një lidhje të tillë për skenarin CBC, mund të nxjerrim ndonjë informacion sekret aty.

Fatmirësisht, atje vërtet ekzistojnë lidhje që mund t’i përdorim. Le të shqyrtojmë daljet e thirrjes përfundimtare të çkodimit të një blloku të koduar dhe t’i quajmë këto të dhëna si . Po ashtu, le të quajmë blloqet e tekstit të hapur dhe blloqet e shifruar . Shikoni përsëri diagramën CBC dhe vëreni se çfarë rezulton:

Le ta quajmë këtë «barazimin CBC».

Në skenarin e Alisës, duke kontrolluar tekstin e koduar dhe duke vëzhguar rrjedhjen e informacionit mbi tekstin e hapur përkatës, arritëm të organizojmë një sulm që rindërtoi anëtarin e tretë të barazimit — çelësin. Në skenarin CBC ne gjithashtu kontrollojmë tekstin e koduar dhe vëzhgojmë rrjedhjet e informacionit për tekstin e hapur përkatës. Nëse analogjia është në vend, do të jemi në gjendje të marrim informacion mbi .

Supozoni se ne me të vërtetë e rindërtuam , çfarë ndodh pastaj? Mirë, atëherë ne mund ta nxjerrim menjëherë të gjithë bllokun e fundit të tekstit të hapur (), duke futur vetëm (të cilin e kemi) dhe
të marrë në barazimin CBC.

Pra, jemi optimistë në lidhje me planin e përgjithshëm të sulmit, dhe tani është koha të punojmë mbi detajet. Vëmendje se si ndodh rrjedhja e informacionit mbi tekstin e hapur në server. Në skenarin e Alisës, rrjedhja ndodhi sepse Alisa përgjigjej me mesazhin e duhur vetëm nëse $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ përfundonte me një varg. a (ose bb, dhe kështu me radhë, por shanset për një aktivizim të rastësishëm të këtyre kushteve ishin shumë të vogla). Po ashtu me CBC, serveri pranon mbushjen vetëm nëse përfundon me hexadecimal 01. Pra, le të provojmë të njëjtin treg: dërgimin e teksteve të falsifikuara me vlerat tona të falsifikuara , derisa serveri të pranojë mbushjen.

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

Tani, përdorim pronësinë byte-jes XOR:

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

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

Ne mund të përfundojmë këtu dhe të kënaqemi me faktin se kemi kryer një sulm ndaj një sistemi teorikisht të fortë të kodimit. Por në të vërtetë ne mund të bëjmë shumë më tepër: ne mund të rikuperojmë të gjithë tekstin. Kjo kërkon një hile të caktuar që nuk ishte në skenarin origjinal të Alicës dhe nuk është pjesë e kushteve të detyrueshme të sulmit Oracle, por metoda është ende e vlefshme për t’u studiuar.

Për ta kuptuar këtë, fillimisht fokusohuni në rezultatin e prodhimit të vlerës së duhur të bajtës së fundit. Ne tani kemi një aftësi të re. Tani, kur manipulojmë me ciphertext-in, mund të kontrollojmë bajtën e fundit të tekstit të hapur përkatës. Sërish, kjo ka të bëjë me ekuacionin CBC dhe pronën e bajtave:

Tani që ne e dimë anëtarin e dytë, mund ta përdorim kontrollin tonë mbi të parin për të menaxhuar të tretin. Simple, thjesht llogarisim:

Më parë ne nuk mund të bënim këtë, sepse nuk e kishim bajtën e fundit. .

Si na ndihmon kjo? Le të supozojmë se tani do të krijojmë të gjithë ciphertext-at në mënyrë që në tekstet përkatëse të hapura, bajta e fundit të jetë 02. Tani serveri pranon mbushjen vetëm nëse teksti i hapur përfundon me 02 02. Sepse kemi korrigjuar bajtën e fundit, kjo do të ndodhte vetëm nëse bajta e parafundit e tekstit të hapur gjithashtu është e barabartë me 02. Ne vazhdojmë të dërgojmë blloqe të rreme të ciphertext-it, duke ndryshuar bajtën e parafundit derisa serveri të pranojë mbushjen për njërin prej tyre. Në këtë moment, ne marrim:

Dhe ne rikthejmë bajtin e parafundit po aq saktë sa rikthyem të fundit. Vazhdoni në të njëjtën frymë: 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 e rikthyer plotësisht .

Çfarë ndodh me tekstin e mbetur? Vini re se vlera në të vërtetë është $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Ne mund të vendosim çdo blok tjetër në vend të , dhe sulmi do të jetë sërish i suksesshëm. Në fakt, mund të kërkojmë nga serveri të bëjë $inline$text{BLOCK_DECRYPT}$inline$ për çdo të dhënë. Në këtë pikë, loja ka përfunduar — ne mund të dekriptojmë çdo tekst të enkriptuar (shikoni përsëri diagramin e dekriptimeve të CBC për ta verifikuar këtë; dhe vini re se vektori IV është publik).

Ky metodë specifike luan një rol vendimtar në sulmin oracle, me të cilin do të ndeshemi më vonë.

Sulmi i Kelsey

John Kelsey, i afërt me ne në frymë, përshkroi parimet që qëndrojnë pas shumë sulmeve të mundshme, jo vetëm detajet e hollësishme të një sulmi konkret ndaj një algoritmi të veçantë. Artikulli i tij i vitit 2002 — është një studim mbi sulmet e mundshme ndaj të dhënave të kompresuara dhe të enkriptuara. A keni menduar se për të realizuar një sulm, nuk është e mjaftueshme vetëm informacioni se të dhënat u kompresuan para enkriptimit? Duket se është mjaftueshëm.

Ky rezultat tërheqës është për shkak të dy principeve. Së pari, ekziston një korrelacion i fortë midis gjatësi të tekstit të hapur dhe gjatësi të tekstit të enkriptuar; për shumë enkripta, barazia e saktë. Së dyti, kur bëhet kompresimi, ka gjithashtu një korrelacion të fortë midis gjatësi të mesazhit të kompresuar dhe shkallës së "zhurmës" së tekstit të hapur, pra, pjesës së simboleve të pakthyeshme (termin teknik — "entropi e madhe").

Për të parë principin 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 pastaj të enkriptuara. Ju merrni dy rezultatet e enkriptuara dhe duhet të gjeni se cili tekst i enkriptuar i përket cilit tekst të hapur:

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

Kuptimi është i qartë. Nga tekstet e hapura, vetëm teksti i hapur 1 mund të ishte kompresuar deri në gjatësi të shkurtër të tekstit të koduar të dytë. Ne e zbuluam këtë, pa ditur asgjë për algoritmin e kompresimit, çelësin e enkriptimit ose madje edhe për vetë enkriptimin. Krahasuar me hierarkinë e sulmeve të mundshme kriptografike, kjo është njëfarë çmendurie.

Kelsey gjithashtu thekson se në rrethana të caktuara të pazakonta, ky parim mund të përdoret gjithashtu për të kryer një sulm orakulli. Në veçanti, ai përshkruan se si një sulmues mund të rikuperojë tekstin sekret të hapur nëse mund ta detyrojë serverin të enkriptojë të dhënat e formularit (teksti i hapur, që ndjek , nëse ai kontrollon dhe mund të verifikojë ndonjë mënyrë gjatësi të rezultatit të enkriptuar.

Përsëri, si në sulmet e tjera të orakullit, kemi një raport:

Përsëri, ne kontrollojmë një anëtar (), shohim një rrjedhje të vogël informacioni mbi një anëtar tjetër (teksti i koduar) dhe përpiqemi të rikuperojmë të fundit (teksti i hapur). Megjithëse është një analogji, kjo është një situatë disi e pazakontë krahasuar me sulmet e tjera të orakullit që kemi parë.

Për të ilustruar si mund të funksionojë një sulm i tillë, le të përdorim një skemë fiktive kompresimi që sapo e krijuam: TOYZIP. Ajo kërkon rreshta teksti që kanë shfaqur tashmë më parë në tekst dhe i zëvendëson ata me tre byte mbushjeje që tregojnë ku të gjejmë një shembull më të hershëm të rreshtit dhe sa herë shfaqet atje. Për shembull, rreshti helloworldhello mund të kompresohet në helloworld[00][00][05] me një gjatësi 13 byte krahasuar me origjinalin 15-byte.

Supozoni se një haker përpiqet të rikthejë 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 që të kompresojë dhe më pas të enkriptojë mesazhet e formularit (teksti i hapur, i ndjekur nga ), ku — është një tekst arbitrar. Kur serveri mbaron punë, ai njofton gjatësi e rezultatit. Sulmi vazhdon kështu:

Hakeri: Të lutem, kompreso dhe enkripto tekstin e hapur pa asnjë mbushje.
Serveri: Gjatësia e rezultatit është 14.
Hakeri: Të lutem, kompreso dhe enkripto tekstin e hapur, të cilit i është shtuar password=a.
Serveri: Gjatësia e rezultatit është 18.

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

Hakeri: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, të cilit i është shtuar password=b.
Serveri: Gjatësia e rezultatit është 18.
Hakeri: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, të cilit i është shtuar password=c.
Serveri: Gjatësia e rezultatit është 17.

Hakeri vë re: [origjinali 14] + [tre byte që kanë zëvendësuar password=c]. Kjo nënkupton se teksti origjinal i hapur përmban një varg password=c. Do të thotë që fjalëkalimi fillon me shkronjën me

Hakeri: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, të cilit i është shtuar password=ca.
Serveri: Gjatësia e rezultatit është 18.

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

Hakeri: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, të cilit i është shtuar password=cb.
Serveri: Gjatësia e rezultatit është 18.

(… një kohë më vonë…)

Hakeri: Ju lutem, kompresoni dhe enkriptoni tekstin e hapur, të cilit i është shtuar password=ço.
Serveri: Gjatësia e rezultatit është 17.

Hakeri vë re: [origjinali 14] + [tre byte që kanë zëvendësuar password=co]. Sipas të njëjtës logjikë, hakeri arrin në përfundimin se fjalëkalimi fillon me shkronjat co

Dhe kështu me radhë deri sa të rikuperohet gjithë fjalëkalimi.

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

Vulnerabilitetet e markave: CRIME, POODLE, DROWN

Në fund, pas një studimi të detajuar të teorisë, ne mund të shohim se si këto metoda përdoren në sulme të vërteta kriptografike.

CRIME

Nëse sulmi është i përqendruar në shfletuesin dhe rrjetin e viktimës, disa gjëra do të jenë më të thjeshta, ndërsa disa do të jenë më të vështira. Për shembull, të shohësh trafikun e viktimës është e lehtë: mjafton të jesh së bashku me të në të njëjtin kafe me WiFi. Për këtë arsye, viktimave të mundshme (dmth. të gjithëve) zakonisht u rekomandohet të përdorin një lidhje të enkriptuar. Do të jetë më e komplikuar, por prapë e mundshme, kryerja e kërkesave HTTP në emër të viktimës në ndonjë faqe tjetër (për shembull, Google). Sulmuesi duhet ta tërheqë viktimën në një faqe të keqe me një skenar që do të bëjë kërkesën. Shfletuesi i internetit do të sigurojë automatikisht kolaudimin përkatës të sesionit.

Kjo duket e pabesueshme. Nëse Bob shkon në evil.com, a mundet që skenari në këtë faqe të thërrasë thjesht Google të dërgojë fjalëkalimin e Bobit përmes emailit në attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Cross-Site Request Forgery, CSRF), dhe ai ishte popullor rreth mesit të viteve '90. Sot, nëse evil.com provon një manovër të tillë, Google (ose çdo faqe që e meriton veten) zakonisht do t'i përgjigjet: “Shumë mirë, por tokeni juaj CSRF për këtë transaksion do të jetë… mmm… tri trilion e shtatë. Ju lutemi, përsërisni këtë numër». Shfletuesit modernë përdorin diçka të quajtur “politika e origjinës së njëjtë” (same-origin policy), sipas së cilës skriptet në sitin A nuk kanë akses në informacionin e dërguar nga siti B. Prandaj, skripti në evil.com mund të dërgojë kërkesa te google.com, por nuk mund të lexojë përgjigjet ose në fakt të përfundojë transaksionin.

Duhet theksuar se nëse Bob nuk përdor një lidhje të enkriptuar, të gjitha këto mbrojtje janë të kotë. Një haker mund thjesht të lexojë trafikun e Bobit dhe të rimarrë cookies e sesionit të Google. Me këtë cookie, ai thjesht do të hapë një skedë të re në Google, pa dalë nga shfletuesi i tij, dhe do të imitojë Bobin, pa u përballur me politikat e bezdisshme të same-origin policy. Por, fatkeqësisht për hakerin, kjo ndodh gjithnjë e më pak. Interneti në tërësi ka shpallur një luftë ndaj lidhjeve të paenkriptuara, dhe trafiku i Bobit për dënimin e tij ka të ngjarë të jetë i enkriptuar, pëlqeu ai këtë apo jo. Për më tepër, që në fillim të implikimit të protokollit, trafiku gjithashtu u kompresua para enkriptimit; kjo ishte një praktikë e zakonshme për të ulur vonesat.

Këtu hyn CRIME (Compression Ratio Infoleak Made Easy, thjesht shfletimi përmes raportit të kompresimit). Një dobësi e demonstruar nga hulumtuesit e sigurisë Giuliano Rizzo dhe Thai Duong në Shtator 2012. Ne kemi shqyrtuar tashmë të gjithë bazën teorike që lejon të kuptojmë se çfarë bënë ata 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 dhe të enkriptuar. Prandaj, kemi:

Këtu, hakeri kontrollon kërkesën dhe ka akses në sniffin e trafikut, duke përfshirë madhësinë e pakove. Skenari imagjinativ i Kelsey u bë realitet.

Duke kuptuar teorinë, autorët e CRIME krijuan një exploit që mund të vjedhë cookie-t e seancës për një varg të gjerë faqesh, duke përfshirë Gmail, Twitter, Dropbox dhe Github. Dobësia preku shumicën e shfletuesve modernë të uebit, duke rezultuar në lëshimin e patch-eve që heshtur varrosën funksionin e kompresimit në SSL, për ta bërë që të mos përdorej fare. I vetmi që ishte i mbrojtur nga dobësia ishte Internet Explorer-i, i cili kurrë nuk kishte përdorur kompresim SSL.

POODLE

Në tetor 2014, ekipi i sigurisë së Google i dha një shqetësim komunitetit të sigurisë. Ata arritën të shfrytëzojnë një vulnerabilitet në protokollin SSL, i cili ishte rregulluar më shumë se një dekadë më parë.

Doli se, megjithëse serverët përdornin TLSv1.2 të ri dhe të shkëlqyer, shumë kishin lënë mbështetje për SSLv3 të vjetëruar për shkak të kompatibilitetit me Internet Explorer 6. Ne kemi folur tashmë për sulmet e degradimit, kështu që mund të imagjinoni se çfarë po ndodhte. Një sabotazh i mirëorganizuar i protokollit të dorezës - dhe serverët janë të gatshëm të rikthehen te vjetër i mirë SSLv3, në efekt duke anuluar 15 vitet e fundit të kërkimeve në fushën e sigurisë.

Për kontekstin historik, këtu është 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. Ka thashetheme se versioni i parë i SSL ishte aq i tmerrshëm, saqë zhvilluesit mblodhën të gjitha kopjet 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, të cilat kriptografët modernë i konsiderojnë si «shekujt e errët të kriptografisë». Shumë nga sulmet më të tmerrshme kriptografike, të cilat ne i dimë sot, ende nuk ishin zbuluar. Si pasojë, zhvilluesit e protokollit SSLv2 duhej esencialisht të gjenin rrugën e tyre në errësirë, dhe ata u përballën me mjaft monstruozitete të tmerrshme — për zemërimin e tyre dhe përfitimin tonë, pasi sulmet ndaj SSLv2 lanë mësime të çmuara për brezin pasardhës të protokolleve.

Pas këtyre ngjarjeve, në vitin 1996, kompania Netscape e zhgënjyer ripërpunoi protokollin SSL nga e para. Rezultati ishte SSL versioni 3, i cili korrigjoi disa probleme të njohura të sigurisë të paraprakut të tij.

Fatmirësisht për hakerët, "disa" nuk do të thotë "të gjithë". Përgjithësisht, SSLv3 ofronte të gjithë komponentët e nevojshëm për të realizuar sulmin Vodenë. Protokolli përdorte një enkriptues block në mënyrën CBC dhe një skemë mbushjeje të pasigurta (këto janë rregulluar në TLS; prandaj, erdhi nevoja për një sulm të uljes). Nëse e mbani mend skemën e mbushjes në përshkrimin tonë fillestar të sulmit Vodenë, skema SSLv3 është shumë e ngjashme.

Por, fatkeqësisht për hakerët, "e ngjashme" nuk do të thotë "identike". Skema e mbushjes së SSLv3 ka formën "N bajta të rastit, të ndjekura nga numri N". Provoni në këto kushte të zgjidhni një bllok imagjinar të tekstit të enkriptuar dhe të kaloni nëpër të gjitha fazat e skemës origjinale të Vodenë: do të zbuloni se sulmi arrin të nxjerrë byte-n e fundit nga blloku përkatës i tekstit të hapur, por nuk shkon më tej. Dekriptime e çdo byte-i të 16-të të tekstit të enkriptuar është një truk i shkëlqyer, por kjo nuk është një fitore.

Kur u ballafaqua me dështimin, ekipi i Google-it përdori një alternativë ekstreme: ata kaluan në një model kërcënimi më të fuqishëm — atë që ishte përdorur në CRIME. Nëse supozojmë se sulmuesi është një skrit që ekzekutohet në skedën e shfletuesit të viktimës, dhe ai mund të nxjerrë cookie-t e seancës, sulmi mbetet akoma mbresëlënës. Megjithëse modeli i gjerë i kërcënimit është më pak realist, në kapitullin e kaluar ne kemi parë se ky model i veçantë është i realizueshëm.

Duke përkundrazi, duke pasur këto mundësi më të fuqishme të hakimit, tani sulmi mund të vazhdojë. Mbani parasysh se sulmuesi e di se ku në titull paraqitet skedari i koduar i sesionit të cookies, dhe kontrollon gjatësi e kërkesës HTTP që e paraprin. Prandaj, ai është i aftë të manipuloj kërkesën HTTP në mënyrë që të përputhë bajtin e fundit të cookies me fundin e bllokut. Tani ky bajt është i përshtatshëm për deshifrimin. Thjesht mund të shtoni një simbol në kërkesë dhe bajti para fundit të cookies do të mbetet në të njëjtin vend dhe do të jetë i përshtatshëm për zgjedhjen me të njëjtin metodë. Sulmi vazhdon kështu deri sa skedari i cookies të rikuperohet plotësisht. Kjo quhet POODLE: Padding Oracle on Downgraded Legacy Encryption, orakulli i mbushjes në enkriptimin e vjetër të ulur.

DROWN

Siç e përmendëm më parë, SSLv3 kishte disavantazhe, por ai ishte thelbësisht ndryshe nga paraardhësi i tij, pasi SSLv2 i ndotur ishte një produkt i një epoke tjetër. Atje mund të ndërpritej mesazhi në gjysmë: pa negociatë do të pranoja këtë vetëm mbi trupin tim shkëputej në pa negociatë do ta pranoja këtë; klienti dhe serveri mund të takoheshin në internet, të krijonin besim dhe të exchange sekrete para syve të një sulmuesi, i cili më pas lehtë do t'i paraqiste veten si njëri apo tjetri. Ka edhe problemin me kriptografinë eksportuese, që e përmendëm kur diskutuam për FREAK. Këto ishin kriptografitë e Sodomit dhe Gomorës.

Në mars 2016, një ekip hulumtuesish nga fusha të ndryshme teknike u mblodh dhe bëri një zbulim të habitshëm: SSLv2 akoma po përdoret në sistemet e sigurisë. Po, sulmuesit nuk mund të ulën më sesionet moderne TLS në SSLv2, sepse kjo vrimë u mbyll pas FREAK dhe POODLE, por ata ende mund të lidhen me serverët dhe të fillojnë sesione SSLv2 vetë.

Do të pyesni, çfarë na intereson se çfarë bëjnë ata? Ata kanë një seancë të ndjeshme, por kjo nuk duhet të ndikojë në seanca të tjera apo në sigurinë e serverit — apo jo? Epo, jo saktësisht. Po, duhet të jetë kështu në teori. Por jo — sepse gjenerimi i certifikatave SSL sjell një ngarkesë të caktuar, duke bërë që shumë serverë të përdorin të njëjtat certifikata dhe, si rezultat, të njëjtat çelësa RSA për lidhjet TLS dhe SSLv2. Çfarë është edhe më keq, për shkak të një defekti në OpenSSL, kjo implementim popullor i SSL në fakt nuk funksiononte opsioni "Çaktivizo SSLv2".

Kjo bëri të mundur një sulm të ndërprerë në TLS, të quajtur DROWN (Dekripto RSA me Kriptim të Pashëndetshëm dhe të Dobësuar, dekription RSA me kriptim të vjetruar dhe të dobësuar). Le të kujtojmë se kjo nuk është e njëjtë me sulmin e uljes; sulmuesi nuk ka nevojë të veprojë si një «njeri në mes» dhe nuk duhet të përfshijë klientin për të marrë pjesë në një seancë të pasigurt. Keqbërësit thjesht iniciativën e një seance të pasigurt SSLv2 me serverin, sulmojnë protokollin e dobët dhe rikuperojnë çelësin privat të serverit RSA. Ky çelës është gjithashtu i vlefshëm për lidhjet TLS, dhe nga ky moment asnjë siguri TLS nuk do ta shpëtojë atë nga thyerja.

Por për thyerjen e nevojitet një sulm efektiv ndaj SSLv2, që lejon rikuperimin jo vetëm të trafikut të veçantë, por edhe çelësit sekret të serverit RSA. Megjithëse kjo është një ngjarje e komplikuar, studiusit mund të zgjidhnin çdo dobësi që ishte plotësisht e mbyllur pas SSLv2. Në fund të fundit, ata gjetën një opsion të përshtatshëm: sulmi i Blychenbacherit, për të cilin përmendëm më parë dhe që do ta shpjegojmë në artikullin e ardhshëm. SSL dhe TLS janë të mbrojtura nga ky sulm, por disa funksione të rastit të SSL në kombinim me çelësa të shkurtër në kriptografinë e klasës së eksporteve, e bënë të mundur. implementimin e caktuar DROWN.

Në momentin e publikimit, 25% e faqeve kryesore të internetit ishin të prekur nga dobësia DROWN, dhe sulmi mund të realizohej me resurse modeste, të disponueshme madje edhe për hakerët e vetëm të guximshëm. Për të nxjerrë çelësin RSA të serverit, nevojiteshin tetë orë llogaritjesh dhe 440 dollarë, ndërsa SSLv2 ndryshoi statusin nga "i vjetruar" në "radioaktiv".

Po për Heartbleed?

Kjo nuk është një sulm kriptografik në kuptimin e lartpërmendur; është një mbivendosje e buffers.

Të bëjmë një pauzë

Filluam me disa metoda bazë: bruteforce, interpolim, ulje, ndër-protokoll dhe parakalkulime. Më pas shqyrtuam një teknikë të avancuar, ndoshta komponentin kryesor të sulmeve moderne kriptografike: kjo është sulmi oracle. U merrem ndjeshëm me të — dhe kuptuam jo vetëm parimin në themel, por edhe detajet teknike të dy implementimeve specifike: sulmi i Wodenae ndaj mënyrës së enkriptimit CBC dhe sulmi i Kelsey ndaj protokolleve të enkriptimit me kompresim paraprak.

Gjatë shqyrtimit të sulmeve të uljes dhe me llogaritjet paraprake, paraqitëm shkurtimisht sulmin FREAK, i cili përdor të dyja metodat, pasi faqet e synuara u tejkaluan për çelësa të dobët dhe më pas i ripërdorën të njëjtët çelësa. Për artikullin tjetër, ne lanë sulmin Logjam (më të ngjashëm), i cili synon algoritmet me çelës publik.

Më pas shqyrtuam edhe tri shembuj të tjerë të aplikimit të këtyre parimeve. Së pari, CRIME dhe POODLE: dy sulme që varen nga aftësia e sulmuesit të integrojë tekst të rastësishëm pranë tekstit të synuar, dhe më pas të studiojë përgjigjet e serverit dhe atëherë, duke përdorur metodologjinë e sulmit Oracle, të përdorin këtë informacion të vogël për rikuperimin e pjesshëm të tekstit të hapur. CRIME shkoi në rrugën e sulmit të Kelsey mbi kompresimin SSL, ndërsa POODLE përdori një variant të sulmit të Vodenë mbi CBC me të njëjtin efekt.

Më pas, ne i kushtuam vëmendje sulmit me protokollin DROWN, i cili vendos një lidhje me serverin përmes protokollit të vjeter SSLv2 dhe më pas rikthen çelësat sekretë të serverit përmes sulmit të Bliechenbacher. Deri tani, ne e anashkalonim detajin teknik të këtij sulmi; ashtu si Logjam, do të duhet të presë derisa të studiojmë mirë kriptosistemat me çelës publik dhe dobësitë e tyre.

Në artikullin në vazhdim do të flasim për sulme më të avancuara — si teknika e përballjes në mes (meet-in-the-middle), kriptoanaliza diferenciale dhe sulmi i "ditëlindjeve". Do të bëj një shkak të shkurtër në sulmet përmes kanaleve të jashtme, dhe pastaj do të merremi me frytet më të shijshme — kriptosistemat me çelës publik.

Burimi: habr.com