Nagu teada, /dev/random, krüptograafiliselt turvaline valejuhuslike numbrite generaator (CSPRNG), omab ühte ebameeldivat probleemi – lukustusi. Käesolevas artiklis käsitletakse, kuidas seda probleemi lahendada.
Viimase paari kuu jooksul on juhuslike numbrite genereerimise vahendeid tuumas veidi ringi tehtud, kuid selle alla kuuluvaid probleeme lahendati laiemas Viimased tehti selleks, et vältida süsteemikõne getrandom() pikaajalist lukustamist süsteemi käivitamisel, kuid aluseks olev põhjus oli blokkeeriva juhusliku basseini käitumine. Hiljutine puhastus eemaldas selle basseini ja oodati, et see suundub põhituuma.
Andy Lutomirski avaldas detsembri lõpus kolmanda versiooni patšist. See toob kaasa "kaks peamist semantilist muutust Linuxi juhuslikes API-des".Patš lisab uue lipu GRND_INSECURE süsteemikõntele getrandom() (kuigi Lutomirski viitab sellele kui getentropy(), mis on glibc-s rakendatud getrandom() abil fikseeritud lippudega); see lipp sunnib kõnet alati tagastama nõutud andmete arvu, kuid ilma garantiita, et need andmed on juhuslikud. Tuum püüab lihtsalt anda parimaid juhuslikke andmeid, mis tal sel hetkel on. "Tõenäoliselt on parim, mida teha saab, nimetada seda 'INSECURE' (ebaturvaliseks), et takistada selle API kasutamist asjade jaoks, mis vajavad turvalisust." Patšid eemaldavad samuti blokkeeriva basseini. Praegu toetab tuum kahte juhuslike andmete basseini, millest üks vastab /dev/random ja teine /dev/urandom, nagu on kirjeldatud selle
2015. aasta. Blokkeeriv bassein on /dev/random jaoks; lugemine sellest seadmest blokeeritakse (millele viitab selle nimi), kuni süsteemist kogutakse "piisavalt" entropiat, et rahuldada taotlust. Edasised lugemised sellest failist blokeeritakse samuti, kui basseinis ei ole piisavalt entropiat. 2015 года. Блокирующий пул — это пул для /dev/random; чтение для этого устройства будет блокироваться (имеется в виду его имя) до тех пор, пока из системы не будет собрана «достаточная» энтропия для удовлетворения запроса. Дальнейшие чтения из этого файла также блокируются, если в пуле недостаточно энтропии.
Lukkuploki eemaldamine tähendab, et lugemine /dev/random käitub nagu getrandom() nulli väärtusega ja muudab GRND_RANDOM lipu noop'iks. Pärast krüptograafilise juhusnumbergeneraatori (CRNG) algatamist ei põhjusta lugemine /dev/random ja getrandom(…,0) kutse lukustumist ning tagastavad soovitud hulga juhuslikke andmeid.
Lutumirski ütleb: „Mina arvan, et Linuxi lukkuplokk on oma aja ära elanud. Linuxi CRNG genereerib väljundeid, mis on piisavalt head nende kasutamiseks isegi võtmete genereerimisel. Lukustav plokk ei ole enam mingil praktilisel viisil tugevam ja selle säilitamiseks on vaja palju kahtlase väärtusega infrastruktuuri.“
Muudatused on tehtud silmas pidades, et olemasolevad programmused ei saaks kahjustada, ja tegelikult on probleemide arv, nagu näiteks GnuPG võtmete genereerimise pika ootamisega, vähenemas.
„Need seerjad ei tohiks rikkuda ühtegi olemasolevat programmi. /dev/urandom jääb muutumatuks. /dev/random on endiselt lukustatud kohe pärast süsteemi käivitamist, kuid lukustamine toimub vähem kui varem. getentropy() olemasolevate lippudega tagastab tulemuse, mis on praktiliste eesmärkide jaoks sama sobiv kui varem.“
Lutumirski märkis, et endiselt jääb lahtiseks küsimus, kas kernel peaks pakkuma nn „tõelisi juhuslikke numbreid“, mida teatud määral pidi pakkuma lukustav kernel. Ta näeb sellega seoses vaid ühte põhjust: „riiklike standardite järgimine“. Lutumirski esitas hüpoteesi, et kui kernel peab seda tagama, peaks see olema tehtud täiesti erineva liidese kaudu või peaks see olema viidud kasutajaruumi, andes sellele võimaluse hankida toore sündmuste proovide andmeid, mida saab kasutada sellise lukkuploki loomiseks.
Stephan Müller väitis, et tema komplekt Linuxi juhuslike numbrite generaator (LRNG) (praegu on välja antud 26. versioon) võib olla viis tõestuslike juhuslike arvude esitlemiseks rakendustele, mis seda vajavad. LRNG "vastab täielikult nõuetele „Ettepanekud entropiaallikate kohta, mida kasutatakse juhuslike bittide genereerimiseks“ SP800-90B", mis teeb sellest lahenduse riiklikele standarditele.
Matthew Garrett esitas vastuväite termini „tõelised juhuslikud andmed” suhtes, märkides, et valitud seadmeid on põhimõtteliselt võimalik piisavalt täpselt mudeldada, et muudab need ettearvatavaks: „me ei vali siin kvantüritusi.”
Müller vastas, et see termin pärineb Saksamaa standardist AIS 31, et kirjeldada juhuslike numbrite generaatorit, mis toob tulemuse „sama kiirus kui aluseks olev müraallikas genereerib entropiat.”
Lisaks terminoloogia erinevustele toob blokeerimise olemasolu, nagu seda pakuvad LRNG-i plaastrid, lihtsalt kaasa mitmesuguseid probleeme, eriti kui see on saadaval privileegideta.
Nagu ütles Lutomirski: „See ei lahenda probleemi. Kui kaks erinevat kasutajat käivitavad rumalaid programme, nagu gnupg, siis nad lihtsalt välistavad üksteist. Ma näen, et praegusel hetkel on kaks peamist probleemi \/dev\/random: see on altid DoS-ile (st ressursside ärakasutamisele, pahatahtlikule mõjule või millelegi sarnasele), ja kuna selle kasutamiseks ei ole vaja privileege, on see ka kuritarvitamisele kalduv. Gnupg on vale, see on täielik kokkuvarisemine. Kui me lisame uue privileegideta liidese, mida gnupg ja sarnased programmid kasutavad, kaotame me jälle.”
Müller märkis, et getrandom() lisamine võimaldab GnuPG-l nüüd seda liidest kasutada, kuna see tagab vajaliku garantii, et bassein on initsialiseeritud. Pärast arutelu GnuPG arendaja Werner Kocha kanssa usub Müller, et garantii on ainus põhjus, miks GnuPG hetkel loeb otse \/dev\/random. Kuid kui on olemas privileegideta liides, mis on teenuse keelamise all (nagu praegu \/dev\/random), siis Lutomirski sõnul kasutatakse seda ebatäpselt mõnede rakenduste poolt.
Theodor Tsao (Theodore Yue Tak Ts’o), a developer of the Linux random number subsystem, seemingly changed his mind about the necessity of a blocking pool. He stated that removing this pool would effectively eliminate the misconception that Linux has a true random number generator (TRNG): “this is not nonsense, as this is exactly what *BSD has always done.”
He is also concerned that providing a TRNG mechanism will merely serve as bait for application developers and believes that, given the various types of hardware supported by Linux, it is impossible to guarantee TRNG in the kernel. The issue will not be resolved even by the possibility of working with hardware based solely on root privileges: “Application developers indicate that for their application to be secure, it must be installed as root, because only then can you access 'really good' random numbers.”
Mueller asked if Tsao has abandoned the implementation of the blocking pool that he himself proposed long ago. Tsao replied that he plans to adopt Lutomirski's patches and is actively opposed to reintroducing the blocking interface back into the kernel.
“The kernel cannot provide any guarantees regarding whether the noise source has been characterized properly. The only thing that a GPG or OpenSSL developer can get is a vague sense that TRUERANDOM is 'better', and since they want greater security, they will undoubtedly try to use it. At some point, it will be blocked, and when some other clever user (perhaps a distribution release engineer) includes it in the init script and the systems stop working, users will only be left to complain to Linus Torvalds himself.”
Tsao also advocates for providing cryptographers and those who truly need TRNG with a way to collect their own entropy in user space to use it at their discretion. He states that collecting entropy is not a process that can be performed by the kernel across all the hardware it supports; moreover, the kernel itself cannot evaluate the amount of entropy provided by different sources.
„Ydin ei saa sekoittaa erilaisia häiriölähteitä keskenään, eikä sen tietenkään pitäisi väittää tietävänsä, kuinka paljon entropiabittejä se saa, kun se yrittää pelata jotain 'kikattelevan entropian peliä' yksinkertaisella CPU-arkkitehtuurilla IoT/Embedded-käyttötapaukseen, kun kaikki on synkronoituna yhdestä päägeneraattorista, eikä ole mitään CPU-ohjekoodia rekisterin uudelleenjärjestämiseen tai uudelleennimeämiseen jne.“.
„Voidaan puhua työkalujen tarjoamisesta, jotka yrittävät tehdä nämä laskelmat, mutta tällaisia asioita tulisi suorittaa jokaisen käyttäjän laitteistolla, mikä on suurimmalle osalle jakeluversioiden käyttäjistä käytännössä mahdotonta. Jos se on tarkoitettu vain kryptograafeille, niin se tehdään heidän käyttäjätilassaan. Ja älkäämme yksinkertaistako GPG:tä, OpenSSL:tä jne., jotta kaikki sanovat: 'haluamme 'todellista satunnaisuutta' emmekä hyväksy vähempää'. Voidaan keskustella siitä, kuinka tarjoamme rajapintoja kryptograafeille, jotta he voivat saada tarvittavat tiedot pääsyllä ensisijaisiin häiriölähteisiin, jotka ovat eristettyjä ja nimettyjä, ja ehkä jollain tavalla häiriölähde voi todentaa itsensä kirjastossa tai sovelluksessa käyttäjätilassa.“.
Käytiin pieni keskustelu siitä, miltä tällainen rajapinta voisi näyttää, sillä esimerkiksi joidenkin tapahtumien voi olla turvallisuuteen vaikuttavia seurauksia. Cao huomautti, että näppäinpainallusten (eli näppäinten painallusten) skannauskoodit sekoittuvat altaaseen osana entropian keruuta: „Tämän siirtäminen käyttäjätilaan, jopa privilegioidun järjestelmäkutsun kautta, olisi vähintäänkin vahingollista“. On täysin mahdollista, että muut tapahtuma-aikahaastattelut voivat luoda jotakin tietovuotoa sivukanavilla.
Seega tekib tunne, et Linuxi juhuslike arvude alamprogrammi pikaajaline probleem on lahenduse teel. Hiljutised muudatused juhuslike arvude alamprogrammis on tegelikult kaasa toonud ainult DoS probleeme selle kasutamisel. Nüüd on aga välja töötatud tõhusad viisid, kuidas saada parimaid juhuslikke arve, mida tuum suudab pakkuda. Kui TRNG on Linuxis endiselt soovitav, siis tuleb see puudus tulevikus kõrvaldada, kuid tõenäoliselt ei toimu see tuuma sees.
Veidi reklaami 🙂
Aitäh, et olete meiega. Kas teile meeldivad meie artiklid? Kas soovite näha rohkem huvitavat sisu? Toetage meid, tellides teenuse või soovitades meid tuttavatele. , ainulaadne entry-level serverite analoog, mille oleme teie jaoks välja mõelnud: (saadaval RAID1 ja RAID10 variandid, kuni 24 tuuma ja kuni 40GB DDR4).
Dell R730xd on Equinixi Tier IV andmekeskuses Amsterdamis kaks korda odavam? Ainult meie juures Hollandis! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — alates $99! Lugege sellest
Allikas: habr.com
