/dev/random, një gjenerues i numrave pseudo të rastësishëm kriptografikisht i sigurt (CSPRNG), dihet se ka një problem të bezdisshëm: bllokimin. Ky artikull shpjegon se si mund ta zgjidhni atë.
Gjatë muajve të fundit, pajisjet e gjenerimit të numrave të rastësishëm në kernel janë ripërpunuar pak, por problemet në këtë nënsistem janë zgjidhur gjatë rrjedhës së gjerë. . Më së shumti janë bërë për të parandaluar bllokimin e thirrjes së sistemit getrandom() për një kohë të gjatë kur sistemi niset, por arsyeja themelore për këtë ishte sjellja bllokuese e grupit të rastësishëm. Një rregullim i fundit do ta kishte hequr këtë grup dhe do të pritej të shkonte drejt bërthamës kryesore.
Andy Lutomirski publikoi versionin e tretë të patch-it në fund të dhjetorit. Ai kontribuon "dy ndryshime të mëdha semantike në API-të e rastësishme të Linux". Patch-i shton një flamur të ri GRND_INSECURE në thirrjen e sistemit getrandom() (edhe pse Lutomirsky i referohet si getentropy(), i cili zbatohet në glibc duke përdorur getrandom() me flamuj fiks); ky flamur bën që thirrja të kthejë gjithmonë sasinë e të dhënave të kërkuara, por pa garantuar që të dhënat janë të rastësishme. Kerneli thjesht do të bëjë çmos për të prodhuar të dhënat më të mira të rastësishme që ka në kohën e caktuar. "Ndoshta gjëja më e mirë për të bërë është ta quash atë "të pasigurt" (i pasigurt) për të parandaluar që kjo API të përdoret për gjëra që kanë nevojë për siguri."
Arna gjithashtu heqin pishinën bllokuese. Kerneli aktualisht mban dy grupe të dhënash të rastësishme, njëra që korrespondon me /dev/random dhe tjetra me /dev/urandom, siç përshkruhet në këtë 2015. Pishina bllokuese është grupi për /dev/random; leximet për atë pajisje do të bllokojë (që do të thotë emrin e saj) derisa të mblidhet "mjaftueshëm" entropia nga sistemi për të përmbushur kërkesën. Leximet e mëtejshme nga ky skedar gjithashtu bllokohen nëse nuk ka entropi të mjaftueshme në grup.
Heqja e grupit të kyçjes do të thotë që leximi nga /dev/random sillet si getrandom() me flamuj të vendosur në zero (dhe e kthen flamurin GRND_RANDOM në një noop). Pasi të inicializohet gjeneratori i numrave të rastësishëm kriptografikë (CRNG), leximi nga /dev/random dhe thirrjet në getrandom(...,0) nuk do të bllokohen dhe do të kthejnë sasinë e kërkuar të të dhënave të rastësishme.
Lutomirsky thotë: “Unë besoj se grupi i bllokimit të Linux është bërë i vjetëruar. CRNG Linux gjeneron dalje që është mjaft e mirë për t'u përdorur edhe për gjenerimin e çelësave. Pishina bllokuese nuk është më e fortë në asnjë kuptim material dhe kërkon shumë infrastrukturë me vlerë të dyshimtë për ta mbështetur atë.”
Ndryshimet u bënë me qëllimin për të siguruar që programet ekzistuese nuk do të prekeshin realisht dhe në fakt, do të kishte më pak probleme me pritjet e gjata për gjëra të tilla si gjenerimi i çelësave GnuPG.
“Këto episode nuk duhet të prishin asnjë program ekzistues. /dev/urandom mbetet i pandryshuar. /dev/random ende bllokon menjëherë pas nisjes, por bllokon më pak se më parë. getentropy() me flamujt ekzistues do të kthejë një rezultat që është po aq i përshtatshëm për qëllime praktike sa më parë."
Lutomirsky vuri në dukje se është ende një pyetje e hapur nëse kerneli duhet të sigurojë të ashtuquajturat "numra të vërtetë të rastësishëm", gjë që është ajo që kerneli bllokues supozohej të bënte në një masë të caktuar. Ai sheh vetëm një arsye për këtë: "përputhshmërinë me standardet e qeverisë". Lutomirsky sugjeroi që nëse kerneli do ta siguronte këtë, duhet të bëhej përmes një ndërfaqeje krejtësisht të ndryshme, ose duhet të zhvendosej në hapësirën e përdoruesit, duke e lejuar përdoruesin të marrë mostrat e ngjarjeve të papërpunuara që mund të përdoren për të krijuar një grup të tillë bllokimi.
Stephan Müller sugjeroi që grupi i tij për Linux Random Number Generator (LRNG) (aktualisht versioni 26 i lëshuar) mund të jetë një mënyrë për të siguruar numra të vërtetë të rastësishëm për aplikacionet që kanë nevojë për të. LRNG është "plotësisht në përputhje me Udhëzimet SP800-90B mbi burimet e entropisë që përdoren për të gjeneruar bit të rastësishëm", duke e bërë atë një zgjidhje për problemin e standardeve të qeverisë.
Matthew Garrett kundërshtoi termin "të dhëna të vërteta të rastësishme", duke vënë në dukje se pajisjet e marra në mostër mund të modelohen në parim mjaftueshëm për t'i bërë ato të parashikueshme: "ne nuk po marrim kampionime të ngjarjeve kuantike këtu".
Müller u përgjigj se termi vjen nga standardi gjerman AIS 31 për të përshkruar një gjenerues të numrave të rastësishëm që prodhon vetëm një rezultat "në të njëjtin ritëm që burimi themelor i zhurmës prodhon entropi".
Duke lënë mënjanë dallimet në terminologji, të kesh një pishinë bllokimi siç sugjerohet nga arnimet LRNG thjesht do të çojë në probleme të ndryshme, të paktën nëse aksesohet pa privilegje.
Siç tha Lutomirsky: “Kjo nuk e zgjidh problemin. Nëse dy përdorues të ndryshëm drejtojnë programe budallaqe si gnupg, ata thjesht do të kullojnë njëri-tjetrin. Unë shoh që aktualisht ka dy probleme kryesore me /dev/random: është i prirur për DoS (d.m.th. shterimi i burimeve, ndikimi keqdashës ose diçka e ngjashme), dhe duke qenë se nuk kërkohen privilegje për ta përdorur atë, ai gjithashtu është i prirur për abuzim. Gnupg është gabim, është një kolaps i plotë. Nëse shtojmë një ndërfaqe të re të paprivilegjuar që do të përdorin gnupg dhe programe të ngjashme, do të humbasim përsëri."
Mueller vuri në dukje se shtimi i getrandom() do të lejojë tani GnuPG të përdorë këtë ndërfaqe, pasi do të sigurojë garancinë e nevojshme që grupi është inicializuar. Bazuar në diskutimet me zhvilluesin e GnuPG, Werner Koch, Mueller beson se garancia është e vetmja arsye që GnuPG aktualisht lexon drejtpërdrejt nga /dev/random. Por nëse ka një ndërfaqe të paprivilegjuar që është e ndjeshme ndaj mohimit të shërbimit (siç është sot /dev/random), Lutomirsky argumenton se do të keqpërdoret nga disa aplikacione.
Theodore Yue Tak Ts'o, zhvilluesi i nënsistemit të numrave të rastësishëm të Linux-it, duket se ka ndryshuar mendje për nevojën për një grup bllokues. Ai tha se heqja e këtij grupi do të shpëtonte efektivisht nga ideja se Linux ka një gjenerues të vërtetë të numrave të rastësishëm (TRNG): "Kjo nuk është marrëzi, pasi kjo është pikërisht ajo që *BSD ka bërë gjithmonë."
Ai është gjithashtu i shqetësuar se ofrimi i një mekanizmi TRNG do të shërbejë thjesht si karrem për zhvilluesit e aplikacioneve dhe beson se në fakt, duke pasur parasysh llojet e ndryshme të harduerit të mbështetur nga Linux, është e pamundur të garantohet TRNG në kernel. Edhe aftësia për të punuar me pajisje vetëm me privilegje rrënjësore nuk do ta zgjidhë problemin: "Zhvilluesit e aplikacioneve specifikojnë që aplikacioni i tyre të instalohet si rrënjë për qëllime sigurie, në mënyrë që kjo të jetë e vetmja mënyrë për të hyrë në numrat e rastësishëm "vërtetë të mirë".
Mueller pyeti nëse Cao kishte braktisur zbatimin e grupit bllokues që ai vetë kishte propozuar prej kohësh. Cao u përgjigj se ai planifikon të marrë arnimet e Lutomirsky dhe kundërshton në mënyrë aktive shtimin e një ndërfaqe bllokuese përsëri në kernel.
“Bërthama nuk mund të japë asnjë garanci nëse burimi i zhurmës është karakterizuar siç duhet. E vetmja gjë që mund të marrë një zhvillues GPG ose OpenSSL është një ndjenjë e paqartë se TRUERANDOM është "më mirë", dhe duke qenë se ata duan më shumë siguri, padyshim që do të përpiqen ta përdorin atë. Në një moment ai do të bllokohet dhe kur një përdorues tjetër i zgjuar (ndoshta një specialist i shpërndarjes) e fut atë në skriptin init dhe sistemet ndalojnë së punuari, përdoruesit do të duhet vetëm të ankohen te vetë Linus Torvalds.
Cao gjithashtu mbron dhënien e kriptografëve dhe atyre që në të vërtetë kanë nevojë për TRNG një mënyrë për të mbledhur entropinë e tyre në hapësirën e përdoruesit për ta përdorur siç e shohin të arsyeshme. Ai thotë se mbledhja e entropisë nuk është një proces që mund të kryhet nga kerneli në të gjithë harduerin e ndryshëm që ai mbështet, dhe as vetë kerneli nuk mund të vlerësojë sasinë e entropisë të ofruar nga burime të ndryshme.
"Bërthama nuk duhet të përziejë burime të ndryshme zhurme së bashku dhe sigurisht nuk duhet të përpiqet të pretendojë të dijë se sa copa entropie po merr kur po përpiqet të luajë një lloj "lojë entropie twitchy" në një CPU jashtëzakonisht të thjeshtë. arkitekturë për përdoruesit e konsumatorit. IOT/Rastet e ngulitura ku gjithçka është jashtë sinkronizimit me një oshilator të vetëm, ku nuk ka asnjë udhëzim të CPU-së për të rirenditur ose riemërtuar një regjistër, etj."
“Ju mund të flisni për ofrimin e mjeteve që përpiqen të bëjnë këto llogaritje, por gjëra të tilla duhet të bëhen në harduerin e secilit përdorues, gjë që thjesht nuk është praktike për shumicën e përdoruesve të shpërndarjes. Nëse kjo është menduar 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 thjeshtojmë GPG, OpenSSL, etj., në mënyrë që të gjithë të thonë "ne duam "rastësinë e vërtetë" dhe nuk do të kënaqemi me më pak." Ne mund të flasim për mënyrën se si u ofrojmë ndërfaqe kriptografëve në mënyrë që ata të marrin informacionin që u nevojitet duke hyrë në burimet kryesore të zhurmës, të ndara dhe të emërtuara, dhe ndoshta disi burimi i zhurmës mund të vërtetohet në një bibliotekë ose aplikacion të hapësirës së përdoruesit."
Pati disa diskutime se si mund të duket një ndërfaqe e tillë, pasi për shembull mund të ketë implikime sigurie për disa ngjarje. Cao vuri në dukje se kodet e skanimit të tastierës (d.m.th. goditjet e tastierës) përzihen në një grup si pjesë e mbledhjes së entropisë: "Sjellja e kësaj në hapësirën e përdoruesit, qoftë edhe përmes një thirrjeje të privilegjuar të sistemit, do të ishte aspak e mençur." Është shumë e mundur që oraret e tjera të ngjarjeve mund të krijojnë një lloj rrjedhje informacioni përmes kanaleve anësore.
Pra, duket sikur një problem i kahershëm me nënsistemin e numrave të rastësishëm të Linux-it është në rrugën e zgjidhjes. Ndryshimet që ka pësuar kohët e fundit nënsistemi i numrave të rastësishëm, në fakt kanë rezultuar vetëm në probleme DoS gjatë përdorimit të tij. Tani ka mënyra efikase për të marrë numrat më të mirë të rastësishëm që mund të sigurojë kerneli. Nëse TRNG është ende i dëshirueshëm në Linux, atëherë kjo e metë do të duhet të adresohet në të ardhmen, por me shumë mundësi kjo nuk do të bëhet brenda vetë kernelit.
Disa reklama 🙂
Faleminderit që qëndruat me ne. A ju pëlqejnë artikujt tanë? Dëshironi të shihni përmbajtje më interesante? Na mbështesni duke bërë një porosi ose duke rekomanduar miqve, , një analog unik i serverëve të nivelit të hyrjes, i cili u shpik nga ne për ju: (e disponueshme me RAID1 dhe RAID10, deri në 24 bërthama dhe deri në 40 GB DDR4).
Dell R730xd 2 herë më 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 dollarë! Lexoni rreth
Burimi: www.habr.com