Si Ă«shtĂ« e njohur, /dev/random, njĂ« gjeneruesi tĂ« numrave psevdor tĂ« rastĂ«sishĂ«m qĂ« Ă«shtĂ« kriptografikisht i sigurt (CSPRNG), ka njĂ« problem tĂ« pakĂ«ndshĂ«m â bllokimet. Ky artikull shpjegon se si mund ta zgjidhni kĂ«tĂ« problem.
Gjatë disa muajve të fundit, mjetet për gjenerimin e numrave të rastit në bërthamë janë riparuar pak, por problemet në këtë nënsistem po zgjidheshin për një periudhë më të gjerë. Ndryshimet më u bënë me qëllim që të parandalohet bllokimi i zgjatur i thirrjes së sistemit getrandom() gjatë ngarkimit të sistemit, por arsyeja nënkuptuese e kësaj ishte sjellja e mbushjes bllokuese të rasteve të rastshme. Një patch i fundit do të eliminonte këtë mbushje, dhe pritej që ai të kalonte në bërthamën kryesore.
Andy Lutomirski publikoi versionin e tretĂ« tĂ« patch-it nĂ« fund tĂ« dhjetorit. Ai bĂ«n âdy ndryshime kryesore semantike nĂ« API-tĂ« e numrave tĂ« rastit nĂ« Linuxâ. Patch-i shton njĂ« flamur tĂ« ri GRND_INSECURE nĂ« thirrjen e sistemit getrandom() (ndonĂ«se Lutomirski e quan atĂ« getentropy(), e cila implementohet nĂ« glibc pĂ«rmes getrandom() me flamuj tĂ« ngurtĂ«); ky flamur detyron thirrjen tĂ« kthejĂ« gjithmonĂ« numrin e kĂ«rkuar tĂ« tĂ« dhĂ«nave, por pa garanci se ato tĂ« dhĂ«na janĂ« tĂ« rastĂ«sishme. BĂ«rthama thjesht do tĂ« pĂ«rpiqet tĂ« ofrojĂ« tĂ« dhĂ«nat mĂ« tĂ« rastĂ«sishme qĂ« ka nĂ« atĂ« moment. âNdoshta, gjĂ«ja mĂ« e mirĂ« qĂ« mund tĂ« bĂ«het Ă«shtĂ« ta quajmĂ« atĂ« 'INSECURE' (jo i sigurt), pĂ«r tĂ« penguar pĂ«rdorimin e kĂ«tij API pĂ«r gjĂ«ra qĂ« kĂ«rkojnĂ« siguri.â
Patch-et gjithashtu eliminojnë mbushjen bllokuese. Aktualisht, bërthama mbështet dy mbushje të të dhënave të rastit, njëra është /dev/random dhe tjetra është /dev/urandom, siç përshkruhet në këtë 2015. Mbushja bllokuese është një mbushje për /dev/random; leximi për këtë aparat do të bllokohet (kuptohet nga emri i tij) derisa të grumbullohet 'mjaft' entropi për të përmbushur kërkesën. Leximet e mëtejshme nga ky skedë gjithashtu bllokohen, nëse nuk ka mjaft entropi në mbushje.
ShkĂ«putja e pishinĂ«s sĂ« bllokimit do tĂ« thotĂ« se leximi nga /dev/random sillet si getrandom() me vlerĂ«n e flamurit zero (dhe e shndĂ«rron flamurin GRND_RANDOM nĂ« noop). Pas inicializimit tĂ« gjeneratorit tĂ« rastĂ«sishĂ«m kriptografik (CRNG), leximi nga /dev/random dhe thirrjet getrandom(âŠ,0) nuk do tĂ« bllokohen dhe do tĂ« kthejnĂ« sasinĂ« e kĂ«rkuar tĂ« tĂ« dhĂ«nave tĂ« rastĂ«sishme.
Lutomirski thotë: «Unë mendoj se pishina bllokuese e Linux-it është e tejkaluar. CRNG i Linux-it gjeneron të dhëna që janë mjaft të mira për t'i përdorur edhe për gjenerimin e çelësave. Pishina bllokuese nuk është më e fuqishme në asnjë aspekt të rëndësishëm dhe për ta mbajtur atë kërkohet shumë infrastrukturë me vlerë të dyshimtë».
Ndryshimet janë bërë me qëllimin që programet ekzistuese të mos preken në të vërtetë, dhe në fakt, problemet me pritjen e gjatë të gjërave si gjenerimi i çelësave GnuPG do të jenë më pak të shpeshta.
«Këto seri nuk duhet të dëmtojnë asnjë program ekzistues. /dev/urandom mbetet i pandryshuar. /dev/random ende bllokohet menjëherë pas ngarkimit, por bllokohet më pak se më parë. getentropy() me flamujt ekzistues do të kthejë rezultat që do të jetë po aq i përshtatshëm për qëllime praktike si më parë».
Lutomirski vuri në dukje se pyetja në lidhje me nëse bërthama duhet të ofrojë atë që quhet "numra të rastësishëm të vërtetë" mbetet ende e hapur, e cila në një farë measure do të duhej të bëhej nga bërthama bllokuese. Ai sheh për këtë vetëm një arsye: "përputhja me standardet shtetërore". Lutomirski sugjeroi se nëse bërthama duhet ta sigurojë këtë, atëherë duhet të bëhet në një ndërfaqe krejtësisht tjetër ose duhet të transferohet në hapësirën e përdoruesit, duke i dhënë atij mundësinë të nxjerrë mostra të papërpunuara ngjarjesh që mund të përdoren për të krijuar një pishinë të tillë bllokuese.
Stefan MĂŒller sugjeroi se seti i tij PĂ«r gjeneratorin e numrave tĂ« rastit Linux (LRNG) (aktualisht nĂ« versionin 26), ai mund tĂ« jetĂ« njĂ« mĂ«nyrĂ« pĂ«r tĂ« siguruar numra tĂ« vĂ«rtetĂ« tĂ« rastit pĂ«r aplikacione qĂ« kanĂ« nevojĂ« pĂ«r to. LRNG "plotĂ«son kĂ«rkesat e 'Rekomandimeve pĂ«r burimet e entropisĂ« tĂ« pĂ«rdorura pĂ«r gjenerimin e bitĂ«ve tĂ« rastit' SP800-90B", duke e bĂ«rĂ« atĂ« njĂ« zgjidhje pĂ«r problemin e standardeve tĂ« shtetit.
Matthew Garrett kishte një kundërshtim ndaj termit 'të dhëna të vërteta të rastit', duke theksuar se pajisjet e zgjedhura në parim mund të modelohen mjaft saktësisht për t'i bërë ato të parashikueshme: 'ne këtu nuk po merremi me ngjarje kuantike'.
MĂŒller pĂ«rgjigji se ky term e ka origjinĂ«n nga standardi gjerman AIS 31 pĂ«r tĂ« pĂ«rshkruar gjeneratorin e numrave tĂ« rastit, i cili jep vetĂ«m rezultatet "me tĂ« njĂ«jtĂ«n shpejtĂ«si qĂ« burimi i zhurmĂ«s prodhon entropi".
Përveç keqkuptimeve të terminologjisë, ekzistenca e një pule bllokimi, siç propozohen në patch-ët LRNG, do të çonte thjesht në probleme të ndryshme, së paku nëse është e aksesueshme pa privilegje.
Siç tha Lutomirski: "Kjo nuk e zgjidh problemin. Nëse dy përdorues të ndryshëm ekzekutojnë programe të tjera të padobishme, si gnupg, ata thjesht do të shterojnë njëri-tjetrin. Unë shoh që aktualisht ekzistojnë dy probleme kryesore me /dev/random: ai është i prirur ndaj DoS (dmth. shterimi i burimeve, ndikim të dëmshëm ose diçka të ngjashme) dhe, pasi nuk kërkohen privilegje për përdorimin e tij, ai gjithashtu është i prirur ndaj abuzimeve. Gnupg është gabim, është një kollaps i plotë. Nëse ne shtojmë një ndërfaqe të re të papërjashtuar që do të përdorin gnupg dhe programe të ngjashme, ne do të humbasim përsëri."
MĂŒller vuri nĂ« dukje se shtimi i getrandom() tani do t'i lejojĂ« GnuPG tĂ« pĂ«rdorĂ« kĂ«tĂ« ndĂ«rfaqe, pasi ajo do tĂ« sigurojĂ« garancinĂ« e nevojshme qĂ« puli Ă«shtĂ« inicializuar. NĂ« bazĂ« tĂ« diskutimeve me zhvilluesin e GnuPG Werner Koch, MĂŒller mendon se garancia Ă«shtĂ« arsyeja e vetme pse GnuPG aktualisht lexon drejtpĂ«rdrejt nga /dev/random. Por nĂ«se ka njĂ« ndĂ«rfaqe tĂ« papĂ«rjashtuar qĂ« Ă«shtĂ« e prirur ndaj refuzimit tĂ« shĂ«rbimit (siç Ă«shtĂ« sot /dev/random), atĂ«herĂ« sipas Lutomirski, ajo do tĂ« pĂ«rdoret nĂ« mĂ«nyrĂ« tĂ« gabuar nga disa aplikacione.
Teodor Tsao (Theodore Yue Tak Tsâo), zhvilluesi i nĂ«nkomponentit tĂ« numrave tĂ« rastit nĂ« Linux, duket se ka ndryshuar mendje pĂ«r nevojĂ«n e njĂ« pooli bllokues. Ai tha se heqja e kĂ«tij pooli do tĂ« lejojĂ« tĂ« largohet nĂ« mĂ«nyrĂ« efektive ideja se Linux ka njĂ« gjenerator tĂ« vĂ«rtetĂ« numrash tĂ« rastit (TRNG): «kjo nuk Ă«shtĂ« njĂ« absurditet, sepse pikĂ«risht kjo Ă«shtĂ« ajo qĂ« gjithmonĂ« kanĂ« bĂ«rĂ« *BSD".
Ai gjithashtu është i shqetësuar se ofrimi i një mekanizmi TRNG do të shërbejë thjesht si një kurth për zhvilluesit e aplikacioneve dhe mendon se, në të vërtetë, duke marrë parasysh tipo të ndryshme hardueri të mbështetur nga Linux, nuk është e mundur të garantohet TRNG në bërthamë. Problemi nuk do të zgjidhet as nga mundësia e punës me harduerin vetëm mbi privilegjet root: «Zhvilluesit e aplikacioneve sugjerojnë që aplikacioni i tyre për qëllime sigurie të instalohet si root, sepse vetëm kështu mund të kesh akses në numra të rastit "me të vërtetë të mirë".
MĂŒller pyeti nĂ«se Tsao e kishte tĂ«rhequr implementimin e poolit bllokues, tĂ« cilin ai vetĂ« e kishte propozuar prej kohĂ«sh. Tsao u pĂ«rgjigj se planifikon tĂ« marrĂ« patch-at e Lutomirskit dhe Ă«shtĂ« aktivisht kundĂ«r rikthimit tĂ« ndĂ«rfaqes bllokuese nĂ« bĂ«rthamĂ«.
«BĂ«rthama nuk mund tĂ« japĂ« garanci se Ă«shtĂ« karakterizuar burimi i zhurmĂ«s nĂ« mĂ«nyrĂ« tĂ« duhur. E vetmja gjĂ« qĂ« mund tĂ« marrĂ« njĂ« zhvillues i GPG ose OpenSSL Ă«shtĂ« njĂ« ndjesi e paqartĂ« se TRUERANDOM Ă«shtĂ« "mĂ« i mirĂ«", dhe pĂ«rderisa ata duan mĂ« shumĂ« siguri, padyshim qĂ« do tĂ« pĂ«rpiqen ta pĂ«rdorin atĂ«. NĂ« njĂ« pikĂ«, ai do tĂ« bllokohet, dhe kur ndonjĂ« pĂ«rdorues tjetĂ«r i zgjuar (ndoshta njĂ« specialist i çlirimit tĂ« shpĂ«rndarjes) e vendos atĂ« nĂ« skriptin init dhe sistemet ndalen sĂ« funksionuari, pĂ«rdoruesve do tâu mbetet vetĂ«m tĂ« ankohen te Linus Torvalds".
Tsao gjithashtu mbështet ofrimin e një metode për kriptografët dhe ata që vërtet kanë nevojë për TRNG, për të mbledhur entropinë e tyre në hapësirën e përdoruesit për ta përdorur sipas dëshirës së tyre. Ai thotë se mbledhja e entropisë nuk është një proces që mund të kryhet nga bërthama në të gjitha harduerët që mbështet, përveç se vetë bërthama nuk mund të vlerësojë sasinë e entropisë që ofrohet nga burime të ndryshme.
«Bërthama nuk duhet të përziej burime të ndryshme noise së bashku, dhe natyrisht nuk duhet të përpiqet të mbajë pretendime se sa bitë entropie merr kur përpiqet të luajë një "lojë të shkëputur entropie" në një arkitekturë CPU të thjeshtë deri në tmerr për rastet e përdorimit IoT/Embedded, kur gjithçka është e pa sinkronizuar me një gjenerator master të vetëm, kur nuk ka asnjë udhëzim CPU për riorganizimin ose rinominimin e regjistrit, etj.».
«Mund të flitet për ofrimin e mjeteve që përpiqen të bëjnë këto llogaritje, por gjëra të tilla duhet të realizohen në harduerin e çdo përdoruesi, që për shumicën e përdoruesve të distribucionit është thjesht e pa praktikueshme. Nëse kjo është e destinuar vetëm për kriptografët, atëherë le të bëhet në hapësirën e tyre të përdoruesit. Dhe le të mos e thjeshtojmë GPG, OpenSSL etj., në mënyrë që të gjithë të thonë: "ne duam 'rastësinë e vërtetë' dhe nuk pranojmë më pak". Mund të flitet se si ne ofrojmë ndërfaqe kriptografëve për të mundësuar që ata të marrin informacionin e nevojshëm falë qasjes në burimet primare të noise, të ndara dhe të emëruara, dhe ndoshta se ndonjë mënyrë burimi noise mund të autentifikojë veten në bibliotekën ose aplikacionin e hapësirës së përdoruesit».
Ndodhi njĂ« diskutim i vogĂ«l se si mund tĂ« duket njĂ« ndĂ«rfaqe e tillĂ«, pasi, pĂ«r shembull, disa ngjarje mund tĂ« kenĂ« pasoja nĂ« lidhje me sigurinĂ«. Cao theksoi se kodet e skanimit tĂ« tastierĂ«s (dmth. shtypjet e çelĂ«save) pĂ«rzihen nĂ« njĂ« rezervuar si pjesĂ« e mbledhjes sĂ« entropisĂ«: «Transferta e kĂ«tij nĂ« hapĂ«sirĂ«n e pĂ«rdoruesit, edhe pĂ«rmes njĂ« thirrjeje tĂ« privilegjuar sistemore, do tĂ« ishte, tĂ« paktĂ«n, e pakujdesshme». ĂshtĂ« e mundshme qĂ« edhe koha e ngjarjeve tĂ« tjera tĂ« krijojĂ« ndonjĂ« rrjedhje informacioni pĂ«r kanalĂ«t anĂ«sorĂ«.
Kështu, krijohet përshtypja se një problem i vjetër me nën-sisteminin e numrave të rastësishëm në Linux po shkon drejt zgjidhjes. Ndryshimet që nën-sistemi i numrave të rastësishëm ka përjetuar kohët e fundit, në fakt, kanë sjellë vetëm probleme DoS gjatë përdorimit të tij. Tani, janë shfaqur mënyra efektive për të marrë numra të rastësishëm më të mirë që bërthama mund të ofrojë. Nëse TRNG është ende e dëshiruara për Linux, atëherë ky defekt do të duhet të zgjidhet në të ardhmen, por me shumë të ngjarë, kjo nuk do të bëhet brenda vetë bërthamës.
Pak reklamĂ« đ
Faleminderit që po qëndroni me ne. Ju pëlqen artikujt tanë? Doni të shihni më shumë materiale interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar tek miqtë tuaj, , një analog unik i serverëve entry-level që e kemi shpikur për Ju: (opcionet me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4 janë të disponueshme).
Dell R730xd dyfish mĂ« i lirĂ« nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave Equinix Tier IV nĂ« Amsterdam? VetĂ«m te ne nĂ« HolandĂ«! Dell R420 â 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB â nga $99! Lexoni rreth
Burimi: habr.com
