Žinoma, kad /dev/random, kriptografiškai saugus pseudoatsitiktinių skaičių generatorius (CSPRNG), turi vieną erzinančią problemą: blokavimą. Šiame straipsnyje paaiškinama, kaip galite ją išspręsti.
Per pastaruosius kelis mėnesius atsitiktinių skaičių generavimo įranga branduolyje buvo šiek tiek pakeista, tačiau šios posistemės problemos buvo išspręstos per platesnį . Labiausiai buvo sukurtos siekiant neleisti getrandom() sistemos iškvietimo blokuoti ilgą laiką, kai sistema paleidžiama, tačiau pagrindinė to priežastis buvo atsitiktinio telkinio blokavimo elgsena. Neseniai įdiegtas pleistras būtų pašalinęs šį baseiną ir būtų tikimasi, kad jis pateks į pagrindinį branduolį.
Andy Lutomirski gruodžio pabaigoje paskelbė trečiąją pleistro versiją. Jis prisideda "du pagrindiniai semantiniai atsitiktinių Linux API pakeitimai". Pleistras prideda naują GRND_INSECURE vėliavėlę prie getrandom() sistemos iškvietimo (nors Lutomirsky vadina ją getentropy(), kuri yra įdiegta glibc naudojant getrandom() su fiksuotomis vėliavėlėmis); dėl šios žymos skambutis visada grąžina prašomą duomenų kiekį, tačiau negarantuoja, kad duomenys yra atsitiktiniai. Branduolys tiesiog padarys viską, kad gautų geriausius atsitiktinius duomenis, kuriuos turi tuo metu. „Turbūt geriausia tai pavadinti „NESAUGU“ (nesaugus), kad ši API nebūtų naudojama dalykams, kuriems reikia saugumo.
Pleistrai taip pat pašalina blokuojantį baseiną. Šiuo metu branduolys turi du atsitiktinius duomenų telkinius, vieną atitinkantį /dev/random, o kitą - /dev/urandom, kaip aprašyta šiame straipsnyje. 2015 m. Blokavimo telkinys yra /dev/random; to įrenginio skaitymai bus blokuojami (tai reiškia jo pavadinimą), kol iš sistemos bus surinkta „pakankamai“ entropijos užklausai patenkinti. Tolesnis šio failo skaitymas taip pat blokuojamas, jei telkinyje nėra pakankamai entropijos.
Užrakinimo telkinio pašalinimas reiškia, kad skaitymas iš /dev/random elgiasi kaip getrandom(), kai vėliavėlės yra nustatytos į nulį (ir GRND_RANDOM vėliavėlė paverčiama „noop“). Kai kriptografinis atsitiktinių skaičių generatorius (CRNG) inicijuojamas, skaitymas iš /dev/random ir iškvietimai į getrandom(...,0) nebus blokuojami ir grąžins prašomą atsitiktinių duomenų kiekį.
Lutomirskis sako: „Manau, kad „Linux“ blokavimo baseinas paseno. CRNG Linux generuoja išvestį, kuri yra pakankamai gera, kad ją būtų galima naudoti net raktų generavimui. Blokuojantis baseinas nėra stipresnis jokia materialine prasme ir jam palaikyti reikia daug abejotinos vertės infrastruktūros.
Pakeitimai buvo atlikti siekiant užtikrinti, kad esamos programos tikrai nebūtų paveiktos, o iš tikrųjų būtų mažiau problemų dėl ilgo laukimo, pavyzdžiui, GnuPG raktų generavimo.
„Šie epizodai neturi trikdyti esamų programų. /dev/urandom lieka nepakitęs. /dev/random vis tiek blokuoja iškart po paleidimo, bet blokuoja mažiau nei anksčiau. getentropy() su esamomis vėliavėlėmis duos rezultatą, kuris yra toks pat tinkamas praktiniams tikslams kaip ir anksčiau.
Lutomirsky pažymėjo, kad vis dar atviras klausimas, ar branduolys turėtų pateikti vadinamuosius „tikruosius atsitiktinius skaičius“, ką blokuojantis branduolys tam tikru mastu ir turėjo padaryti. Jis mato tik vieną to priežastį: „vyriausybinių standartų laikymasis“. Lutomirsky pasiūlė, kad jei branduolys turėtų tai suteikti, tai turėtų būti padaryta per visiškai kitą sąsają arba jis turėtų būti perkeltas į vartotojo erdvę, kad vartotojas galėtų gauti neapdorotus įvykių pavyzdžius, kuriuos būtų galima panaudoti tokiam užrakinimo telkiniui sukurti.
Stephanas Mülleris pasiūlė, kad jo rinkinys Linux Random Number Generator (LRNG) (šiuo metu išleista 26 versija) galėtų būti būdas pateikti tikrus atsitiktinius skaičius programoms, kurioms to reikia. LRNG „visiškai atitinka SP800-90B gaires dėl entropijos šaltinių, naudojamų atsitiktiniams bitams generuoti“, todėl tai yra vyriausybės standartų problemos sprendimas.
Matthew Garrettas prieštaravo terminui „tikrieji atsitiktiniai duomenys“, pažymėdamas, kad atrinktus įrenginius iš principo galima pakankamai tiksliai sumodeliuoti, kad būtų galima juos nuspėti: „čia nerenkame kvantinių įvykių“.
Mülleris atsakė, kad terminas kilęs iš Vokietijos standarto AIS 31, apibūdinantis atsitiktinių skaičių generatorių, kuris tik sukuria rezultatą „tokiu pat greičiu, kaip pagrindinis triukšmo šaltinis sukuria entropiją“.
Neskaitant terminų skirtumų, LRNG pataisose siūlomas užraktų baseinas tiesiog sukels įvairių problemų, bent jau tuo atveju, jei jis pasiekiamas be privilegijų.
Kaip sakė Lutomirskis: „Tai neišsprendžia problemos. Jei du skirtingi vartotojai paleidžia tokias kvailas programas kaip gnupg, jie tiesiog nusausins vienas kitą. Matau, kad šiuo metu yra dvi pagrindinės problemos, susijusios su /dev/random: jis linkęs į DoS (ty išeikvoti išteklius, kenksminga įtaka ar kažkas panašaus), o kadangi juo naudotis nereikia jokių privilegijų, jis taip pat linkęs piktnaudžiauti. Gnupg klysta, tai visiškas žlugimas. Jei pridėsime naują neprivilegijuotą sąsają, kurią naudos gnupg ir panašios programos, vėl pralaimėsime.
Muelleris pažymėjo, kad getrandom() pridėjimas dabar leis GnuPG naudoti šią sąsają, nes tai suteiks reikiamą garantiją, kad baseinas buvo inicijuotas. Remdamasis diskusijomis su GnuPG kūrėju Werneriu Kochu, Muelleris mano, kad garantija yra vienintelė priežastis, dėl kurios GnuPG šiuo metu skaito tiesiai iš /dev/random. Tačiau jei yra neprivilegijuota sąsaja, kuriai gali būti atsisakyta teikti paslaugą (kaip šiandien yra /dev/random), Lutomirsky teigia, kad kai kurios programos ja naudosis netinkamai.
Panašu, kad Theodore Yue Tak Ts'o, „Linux“ atsitiktinių skaičių posistemio kūrėjas, pakeitė savo nuomonę dėl blokavimo telkinio poreikio. Jis teigė, kad pašalinus šį telkinį būtų veiksmingai pašalinta mintis, kad Linux turi tikrą atsitiktinių skaičių generatorių (TRNG): "Tai nėra nesąmonė, nes būtent tai *BSD visada darė."
Jis taip pat yra susirūpinęs, kad TRNG mechanizmas bus tiesiog masalas programų kūrėjams, ir mano, kad iš tikrųjų, atsižvelgiant į skirtingus Linux palaikomos aparatinės įrangos tipus, neįmanoma užtikrinti TRNG branduolyje. Net galimybė dirbti su įranga tik su root teisėmis neišspręs problemos: „Programų kūrėjai nurodo, kad jų programa saugumo sumetimais būtų įdiegta kaip root, kad tik taip galėtumėte pasiekti „tikrai gerus“ atsitiktinius skaičius.
Muelleris paklausė, ar Cao atsisakė blokuojančio baseino įgyvendinimo, kurį jis pats jau seniai siūlė. Cao atsakė, kad planuoja naudoti Lutomirsky pataisas ir aktyviai prieštarauja blokuojančios sąsajos pridėjimui atgal į branduolį.
„Branduolys negali suteikti jokių garantijų, ar triukšmo šaltinis buvo tinkamai apibūdintas. Vienintelis dalykas, kurį gali gauti GPG arba OpenSSL kūrėjas, yra miglotas jausmas, kad TRUERANDOM yra „geresnis“, ir kadangi jie nori didesnio saugumo, jie neabejotinai bandys juo pasinaudoti. Kažkuriuo momentu jis bus užblokuotas, o kai koks nors kitas protingas vartotojas (galbūt platinimo specialistas) įterps jį į init scenarijų ir sistemos nustos veikti, vartotojams teks skųstis pačiam Linui Torvaldsui.
Cao taip pat pasisako už tai, kad kriptografams ir tiems, kuriems iš tikrųjų reikia TRNG, būtų suteiktas būdas surinkti savo entropiją vartotojo erdvėje ir naudoti taip, kaip jiems atrodo tinkama. Jis sako, kad entropijos rinkimas nėra procesas, kurį branduolys gali atlikti visoje įvairioje palaikomoje aparatinėje įrangoje, taip pat pats branduolys negali įvertinti skirtingų šaltinių teikiamos entropijos kiekio.
„Branduolys neturėtų maišyti skirtingų triukšmo šaltinių ir tikrai neturėtų bandyti teigti, kiek entropijos bitų jis gauna, kai bando žaisti kokį nors „trūkčiojantį entropijos žaidimą“ nepaprastai paprastu CPU. architektūra vartotojų vartotojams. IOT / įterptieji atvejai, kai viskas nesinchronizuojama su vienu pagrindiniu generatoriumi, kai nėra CPU nurodymų pertvarkyti ar pervardyti registrą ir pan.
„Galima kalbėti apie įrankių, kurie bando atlikti šiuos skaičiavimus, pateikimą, tačiau tokius dalykus reikia atlikti kiekvieno vartotojo aparatinėje įrangoje, o tai daugeliui platinimo vartotojų tiesiog nėra praktiška. Jei tai skirta tik kriptografams, tegul tai daroma jų vartotojo erdvėje. Ir nesupaprastinkime GPG, OpenSSL ir t.t., kad visi sakytų „mes norime „tikro atsitiktinumo“ ir nepasitenkinsime mažiau“. Galime kalbėti apie tai, kaip teikiame sąsajas kriptografams, kad jie gautų reikiamą informaciją, prieidami prie pirminių atskirtų ir pavadintų triukšmo šaltinių, o galbūt kaip nors triukšmo šaltinis gali autentifikuoti save bibliotekoje ar vartotojo erdvėje.
Buvo diskutuojama, kaip tokia sąsaja galėtų atrodyti, nes, pavyzdžiui, kai kurie įvykiai gali turėti įtakos saugumui. Cao pažymėjo, kad klaviatūros nuskaitymo kodai (t. y. klavišų paspaudimai) sumaišomi į telkinį kaip entropijos rinkimo dalis: „Įnešti tai į vartotojo erdvę, net naudojant privilegijuotąjį sistemos skambutį, būtų švelniai tariant, neprotinga“. Visai įmanoma, kad kiti įvykių laikai gali sukelti tam tikrą informacijos nutekėjimą šoniniais kanalais.
Taigi panašu, kad jau seniai susiklosčiusi „Linux“ atsitiktinių skaičių posistemės problema jau artėja prie sprendimo. Pakeitimai, kuriuos neseniai patyrė atsitiktinių skaičių posistemė, iš tikrųjų sukėlė tik DoS problemų ją naudojant. Dabar yra veiksmingų būdų gauti geriausius atsitiktinius skaičius, kuriuos gali pateikti branduolys. Jei TRNG vis dar pageidautina Linux sistemoje, šią trūkumą reikės pašalinti ateityje, tačiau greičiausiai tai nebus padaryta pačiame branduolyje.
Kai kurie skelbimai 🙂
Dėkojame, kad likote su mumis. Ar jums patinka mūsų straipsniai? Norite pamatyti įdomesnio turinio? Palaikykite mus pateikdami užsakymą ar rekomenduodami draugams, , unikalus pradinio lygio serverių analogas, kurį mes sugalvojome jums: (galima su RAID1 ir RAID10, iki 24 branduolių ir iki 40 GB DDR4).
„Dell R730xd“ 2 kartus pigiau „Equinix Tier IV“ duomenų centre Amsterdame? Tik čia Olandijoje! „Dell R420“ – 2 x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB – nuo 99 USD! Skaityti apie
Šaltinis: www.habr.com