Siç dihet, /dev/random, gjeneratori i numrave të rastit me qëndrim të kriptografisë (CSPRNG), ka një problem të pakëndshëm – bllokimi. Ky artikull shpjegon se si mund të zgjidhet ky problem.
Gjatë muajve të fundit, mjetet për gjenerimin e numrave të rastit në bërthamë janë përmirësuar pak, por problemet në këtë nënshkallë janë trajtuar për një periudhë më të gjerë . Ndryshimet u bënë me qëllim për të parandaluar bllokimin e gjatë të thirrjes sistemike getrandom () gjatë ngarkesës së sistemit, por arsyeja themelore për këtë ka qenë sjellja e grupit bllokues të rastit. Ndryshimi i fundit do të hiqte këtë grup, dhe pritej që ai të shkonte në bërthamën kryesore.
Andy Lutomirski publikoi versionin e tretë të ndryshimit në fund të dhjetorit. Ai sjell «dy ndryshime themelore semantike në API-të e rastit të Linux». Patch shton një flamur të ri GRND_INSECURE në thirrjen sistemore getrandom() (ndonëse Lutomirski i referohet asaj si getentropy(), e cila është e realizuar në glibc me getrandom() me flamuj të ngurtë); ky flamur bën që thirrja të kthejë gjithmonë sasinë e dhënave të kërkuara, por pa garantimin se këto të dhëna janë të rastësishme. Bërthama thjesht do të bëjë përpjekje për të ofruar të dhënat më të mira të rastësishme që ka në atë moment. «Ndoshta gjëja më e mirë që mund të bësh është ta quash atë "INSECURE" (jo të sigurt), për të parandaluar përdorimin e këtij API për gjëra që kërkojnë siguri».
Patch-at gjithashtu heqin pellgun bllokues. Aktualisht, bërthama mbështet dy pellgje të të dhënave të rastësishme, njëri përputhet me /dev/random, dhe tjetri me /dev/urandom, siç përshkruhet në këtë të vitit 2015. Pellgu bllokues është një pellg për /dev/random; leximi për këtë pajisje do të bllokohet (ka të bëjë me emrin e saj) derisa nga sistemi të mblidhet "mjaft" entropi për të kënaqur kërkesën. Lexime të mëtejshme nga ky file gjithashtu bllokohen, nëse në pellg ka pak entropi.
Heqja e rezervuarit të bllokimeve do të thotë se leximi nga /dev/random vepron si getrandom() me vlerën e flags të barabartë me zero (dhe e kthen flagun GRND_RANDOM në noop). Pas inicializimit të gjeneratorit të kriptografisë për numra të rastësishëm (CRNG), leximi nga /dev/random dhe thirrjet getrandom(…,0) nuk do të shkaktojnë bllokim dhe do të kthejnë sasinë e kërkuar të të dhënave të rastësishme.
Lutomirski thotë: «Mendoj se rezervuari bllokues i Linux ka përfunduar. CRNG i Linux gjeneron dalje që janë mjaft të mira për t'u përdorur edhe për gjenerimin e çelësave. Rezervuari bllokues nuk është më i fortë në asnjë aspekt material, dhe kërkon shumë infrastrukturë me vlerë dyshuese për ta mbajtur atë.»
Ndryshimet janë bërë me synimin që programet ekzistuese të mos vuajnë në të vërtetë, dhe në të vërtetë, problemet me pritje të gjatë për gjëra si gjenerimi i çelësave GnuPG do të zvogëlohen.
«Këto seri nuk duhet të shkelin ndonjë 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ë një rezultat që do të jetë po aq i përshtatshëm për qëllime praktike sa më parë».
Lutomirski vuri në dukje se pyetja, nëse bërthama duhet të ofrojë atë që quhet «numra të vërtetë rastësorë», mbetet ende e hapur, gjë që në një masë duhet ta bënte bërthama bllokuese. Ai sheh vetëm një arsye për këtë: «respektimin e standardeve shtetërore». Lutomirski supozoi se nëse bërthama duhet ta sigurojë këtë, atëherë duhet të bëhet përmes një interfesi krejtësisht të ndryshëm ose duhet të transferohet në hapësirën e përdoruesit, duke i ofruar atij mundësinë të nxjerrë mostra të papërpunuara ngjarjesh, që mund të përdoren për të krijuar një grup të tillë bllokimi.»
Stephan Müller sugjeroi se seti i tij për gjeneratorin e numrave të rastësishëm Linux (LRNG) (aktualisht është lëshuar versioni 26) mund të jetë një mënyrë për të ofruar numra të vërtetë të rastësishëm për aplikacionet që kanë nevojë për to. LRNG "plotëson kërkesat e 'Rekomandimeve për burimet e entropisë që përdoren për gjenerimin e bitëve të rastësishëm' SP800-90B", duke e bërë atë një zgjidhje për problemin e standardeve qeveritare.
Matthew Garrett kundërshtoi termin 'të dhëna të vërteta rastësore', 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 marrim ngjarje kuantike'.
Müller u përgjigj se ky term vjen nga standardi gjerman AIS 31 për përshkrimin e gjeneratorit të numrave të rastësishëm, i cili vetëm jep rezultat 'me të njëjtin ritëm me të cilin burimi bazë i zhurmës prodhon entropi'.
Përveç mospajtimeve të terminologjis, ekzistenca e një pool bllokimi, siç sugjerohen patch-et LRNG, do të sillte thjesht probleme të ndryshme, të paktën nëse është në dispozicion pa privilegje.
Sipas Lutomirsky: «Kjo nuk e zgjidh problemin. Nëse dy përdorues të ndryshëm ekzekutojnë programe të padobishme si gnupg, ata përfundojnë duke i shpenzuar të dy njëri-tjetrin. Shoh që aktualisht ekzistojnë dy probleme kryesore me /dev/random: ai është i ekspozuar ndaj DoS (dmth shpenzimit të burimeve, ndikimit keqdashës, apo ndonjë gjëje të ngjashme), dhe, pasi nuk kërkohen privilegje për ta përdorur, ai gjithashtu është i prirur ndaj abuzimeve. Gnupg është e gabuar, është një kolaps total. Nëse ne shtojmë një ndërfaqe të re pa privilegje që do të përdorin gnupg dhe programe të ngjashme, ne përsëri do të humbasim.»
Müller vuri në dukje se shtimi i getrandom() tani do t'i japë GnuPG mundësinë për të përdorur këtë ndërfaqe, pasi do të sigurojë garantimin e nevojshëm që pool-i të jetë inicializuar. Bazuar në diskutimet me zhvilluesin e GnuPG, Werner Koch, Müller mendon se garantia është arsyeja e vetme për të cilën GnuPG aktualisht lexon drejtpërdrejt nga /dev/random. Por nëse ka një ndërfaqe jo privilegjuese që është e ndjeshme ndaj refuzimit të shërbimit (ashtu si /dev/random sot), sipas Lutomirski, ajo do të përdoret gabimisht nga disa aplikacione.
Teodor Tsao (Theodore Yue Tak Ts’o), zhvilluesi i nënsistemit të numrave të rastësishëm në Linux, duket se e ka ndryshuar mendimin e tij për nevojën e një pool-i që bllokon. Ai tha se heqja e këtij pool-i do të lejojë një efektivitet në zhdukjen e idesë që Linux ka një generator të vërtetë numrash të rastësishëm (TRNG): «kjo nuk është pa kuptim, pasi kjo është pikërisht ajo që gjithmonë kanë bërë *BSD".
Ai është gjithashtu i shqetësuar se ofrimi i mekanizmit TRNG do të shërbejë thjesht si një kurth për zhvilluesit e aplikacioneve dhe mendon se, duke marrë parasysh llojet e ndryshme të harduerit të mbështetur nga Linux, është e pamundur të garantosh TRNG-in në bërthamë. Problemi nuk do të zgjidhet as nga mundësia e operimit me pajisje vetëm mbi baza të privilegjeve root: «Zhvilluesit e aplikacioneve tregojnë se për sigurinë e aplikacionit të tyre, duhet të instalohen si root, sepse vetëm kështu mund të keni qasje në numra 'vërtet të mirë' të rastësishëm".
Müller pyeti nëse Cao kishte hequr dorë nga implementimi i grupit bllokues, të cilin ai vetë e kishte propozuar prej kohësh. Cao u përgjigj se planifikon të marrë patch-et e Lutomirskit dhe është aktivisht kundër rikthimit të ndërfaqes bllokuese në bërthamë.
«Një bërthame nuk mund të ofrojë asnjë garanci në lidhje me nëse burimi i zhurmës është karakterizuar siç duhet. E vetmja gjë që një zhvillues GPG ose OpenSSL mund të marrë është një ndjenjë të paqartë se TRUERANDOM është 'më i mirë', dhe për sa i përket sigurisë, ata padyshim do të përpiqen ta përdorin. Në një moment, ai do të bllokohet, dhe kur ndonjë përdorues tjetër inteligjent (ndoshta një specialist në lëshimin e shpërndarjes) ta vendosë atë në një skript init dhe sistemet të ndalojnë së funksionuari, përdoruesit do të mbesin vetëm për të ankuar Linus Torvalds-it të vetë.”
Cao gjithashtu e mbështet sigurimin e një mënyre 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 atë sipas dëshirës së tyre. Ai thotë se mbledhja e entropisë nuk është një proces që mund të realizohet nga bërthama në çdo pajisje të mbështetur prej saj, gjithashtu, vetë bërthama nuk mund të vlerësojë sasinë e entropisë që sigurohet nga burime të ndryshme.
«Nuk i duhet të përziejë së bashku burime të ndryshme zhurmash, dhe natyrisht, nuk duhet të përpiqet të pohonte se di se sa bita entropie merr kur përpiqet të luajë një "lojë të çmendur entropie" në një arkitekturë CPU që është thjesht e ulët për rastet përdoruese IoT/Embedded, kur gjithçka është jashtë sinkronit me një generator kryesor, kur nuk ka ndonjë instrukcion CPU për riorganizimin ose rinamingun e regjistrit, etj.»
«Mund të flitet për ofrimin e mjeteve që përpiqen të bëjnë këto llogaritje, por këto gjëra duhet të realizohen në pajisjet e çdo përdoruesi, që për shumicën e përdoruesve të shpërndarjes është thjesht e paprakti. Nëse kjo është e destinuar vetëm për kriptografët, 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ë flasim për mënyrën se si ofrojmë ndërfaqet për kriptografët, në mënyrë që ata të mund të marrin informacionin e nevojshëm me anë të aksesit në burimet e zhurmës primare, të ndara dhe të emëruara dhe, ndoshta, ndonjë burim zhurme do të jetë në gjendje të autentifikojë veten në bibliotekë ose aplikacionin e hapësirës së përdoruesit.»
Kishte një diskutim të vogël se si mund të duket një ndërfaqe e tillë, pasi, për shembull, disa ngjarje mund të kenë pasoja në aspektin e sigurisë. Cao theksoi se kodet e skanimit të tastierës (dmth, shtypjet e çelësave) përzihen në një grup si pjesë e mbledhjes së entropisë: "Transferimi i kësaj në hapësirën e përdoruesit, madje përmes një thirrjeje sistemike me privilegje, do të ishte, të paktën, i paarsyeshëm". Ka shumë gjasa që koha e ngjarjeve të tjera mund të krijojë ndonjë rrjedhje informacioni përmes kanaleve anësore.
Kështu, krijohet përshtypja se problemi i gjatë i nëncilës së numrave të rastësishëm në Linux është në rrugën e zgjidhjes. Ndryshimet që nëncilës së numrave të rastësishëm i janë bërë kohëve të fundit, në fakt, kanë sjellë vetëm probleme DoS gjatë përdorimit të saj. Tani, ka metoda efektive për të marrë numra të rastësishëm më të mirë se çfarë ofron bërthama. Nëse TRNG ende dëshirohet për Linux, atëherë ky defekt duhet të zgjidhet në të ardhmen, por, më së shumti, nuk do të bëhet brenda bërthamës vetë.
Pak reklamë 🙂
Faleminderit që qëndroni me ne. Ju pëlqejnë artikujt tanë? Dëshironi të shihni më shumë materiale interesante? Na mbështetni duke bërë një porosi ose duke na rekomanduar njohurive tuaj, , një analog unik i serverëve entry-level, i ndërtuar për ju: (disponohen variante me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40GB DDR4).
Dell R730xd dyfish më i lirë në qendrën e të dhënave Equinix Tier IV në Amsterdam? Vetëm këtu në Holandë! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — nga $99! Lexoni rreth
Burimi: habr.com
