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
