/dev/random, kryptografisesti suojattu näennäissatunnaislukugeneraattori (CSPRNG), jolla tiedetään olevan yksi ärsyttävä ongelma: esto. Tässä artikkelissa kerrotaan, kuinka voit ratkaista sen.
Muutaman viime kuukauden aikana ytimen satunnaislukujen luontitoimintoja on hieman muokattu, mutta tämän alijärjestelmän ongelmat on ratkaistu laajemman . Eniten tehtiin estämään getrandom()-järjestelmäkutsua estymästä pitkäksi aikaa järjestelmän käynnistyessä, mutta taustalla oleva syy tähän oli satunnaisen poolin estokäyttäytyminen. Äskettäinen korjaustiedosto olisi poistanut tämän poolin ja sen olisi odotettu suuntaavan kohti pääydintä.
Andy Lutomirski julkaisi korjaustiedoston kolmannen version joulukuun lopussa. Hän osallistuu "kaksi suurta semanttista muutosta satunnaisiin Linux-sovellusliittymiin". Korjaus lisää uuden GRND_INSECURE-lipun getrandom()-järjestelmäkutsuun (vaikka Lutomirsky viittaa siihen nimellä getentropy(), joka on toteutettu glibc:ssä käyttämällä getrandom():ta kiinteillä lipuilla); tämä lippu saa puhelun aina palauttamaan pyydetyn datamäärän, mutta takaamatta tietojen satunnaisuutta. Ydin yksinkertaisesti tekee parhaansa tuottaakseen parhaan satunnaisen datan, joka sillä on kulloinkin. "Todennäköisesti parasta on kutsua sitä "VARMOTTOmaksi" (epäturvallinen), jotta tätä APIa ei käytetä turvallisuutta vaativiin asioihin."
Laastarit poistavat myös estävän altaan. Ydin ylläpitää tällä hetkellä kahta satunnaista tietopankkia, joista toinen vastaa /dev/random ja toinen /dev/urandom, kuten tässä kuvataan. 2015. Estopooli on /dev/random; Laitteen lukemat estävät (eli sen nimen), kunnes järjestelmästä on kerätty "tarpeeksi" entropiaa pyynnön täyttämiseksi. Myös tämän tiedoston lisälukeminen estetään, jos poolissa ei ole tarpeeksi entropiaa.
Lukitusvarannon poistaminen tarkoittaa, että lukeminen tiedostosta /dev/random toimii kuten getrandom() lippujen ollessa nolla (ja muuttaa GRND_RANDOM-lipun noopiksi). Kun kryptografinen satunnaislukugeneraattori (CRNG) on alustettu, lukeminen tiedostosta /dev/random ja kutsut osoitteeseen getrandom(...,0) eivät estä ja palauttaa pyydetyn määrän satunnaista dataa.
Lutomirsky sanoo: ”Uskon, että Linuxin estoallas on vanhentunut. CRNG Linux tuottaa tulosteen, joka on tarpeeksi hyvä käytettäväksi jopa avainten luomiseen. Estopooli ei ole vahvempi missään aineellisessa mielessä, ja sen tukemiseen tarvitaan paljon arveluttavaa infrastruktuuria.
Muutokset tehtiin tarkoituksena varmistaa, että olemassa oleviin ohjelmiin ei todellakaan kohdistuisi vaikutusta, ja itse asiassa GnuPG-avainten luomisen kaltaisten asioiden pitkien odotusten vuoksi olisi vähemmän ongelmia.
"Nämä jaksot eivät saa häiritä olemassa olevia ohjelmia. /dev/urandom pysyy ennallaan. /dev/random estää edelleen heti käynnistyksen yhteydessä, mutta se estää vähemmän kuin ennen. getentropy() olemassa olevilla lipuilla palauttaa tuloksen, joka on yhtä sopiva käytännön tarkoituksiin kuin ennenkin."
Lutomirsky huomautti, että on vielä avoin kysymys, pitäisikö ytimen tarjota niin sanottuja "todellisia satunnaislukuja", mitä estävän ytimen oli jossain määrin tehtävä. Hän näkee tähän vain yhden syyn: "hallituksen standardien noudattaminen". Lutomirsky ehdotti, että jos ydin tarjoaisi tämän, se tulisi tehdä täysin erilaisen käyttöliittymän kautta tai se tulisi siirtää käyttäjätilaan, jolloin käyttäjä voi hakea käsittelemättömiä tapahtumanäytteitä, joita voitaisiin käyttää tällaisen lukituspoolin luomiseen.
Stephan Müller ehdotti, että hänen settinsä Linux Random Number Generator (LRNG) (tällä hetkellä julkaistu versio 26) voisi olla tapa tarjota todellisia satunnaislukuja sitä tarvitseville sovelluksille. LRNG on "täysin yhteensopiva SP800-90B:n ohjeiden kanssa satunnaisten bittien luomiseen käytetyistä entropialähteistä", mikä tekee siitä ratkaisun hallituksen standardien ongelmaan.
Matthew Garrett vastusti termiä "todellista satunnaista dataa" ja huomautti, että näytteitetyt laitteet voidaan periaatteessa mallintaa tarpeeksi tarkasti, jotta ne olisivat ennustettavissa: "Emme ota tässä näytteitä kvanttitapahtumista."
Müller vastasi, että termi tulee saksalaisesta standardista AIS 31 kuvaamaan satunnaislukugeneraattoria, joka tuottaa vain tuloksen "samalla nopeudella kuin taustalla oleva kohinalähde tuottaa entropiaa".
Terminologiset erot syrjään, LRNG-korjausten ehdottama lukkopooli johtaa yksinkertaisesti erilaisiin ongelmiin, ainakin jos sitä käytetään ilman oikeuksia.
Kuten Lutomirsky sanoi: "Tämä ei ratkaise ongelmaa. Jos kaksi eri käyttäjää ajaa typeriä ohjelmia, kuten gnupg, he vain tyhjentävät toisiaan. Näen, että /dev/randomissa on tällä hetkellä kaksi pääongelmaa: se on alttiina DoS:lle (eli resurssien ehtymiselle, haitallisille vaikutuksille tai muulle vastaavalle), ja koska sen käyttöön ei vaadita oikeuksia, se on myös altis väärinkäytölle. Gnupg on väärässä, se on täydellinen romahdus. Jos lisäämme uuden käyttöliittymän, jota gnupg ja vastaavat ohjelmat käyttävät, menetämme jälleen."
Mueller huomautti, että getrandom():n lisääminen sallii nyt GnuPG:n käyttää tätä käyttöliittymää, koska se takaa tarvittavan takuun, että pooli on alustettu. GnuPG-kehittäjä Werner Kochin kanssa käytyjen keskustelujen perusteella Mueller uskoo, että takuu on ainoa syy, miksi GnuPG lukee tällä hetkellä suoraan tiedostosta /dev/random. Mutta jos on etuoikeutettu käyttöliittymä, joka on alttiina palvelunestolle (kuten /dev/random on nykyään), Lutomirsky väittää, että jotkut sovellukset käyttävät sitä väärin.
Theodore Yue Tak Ts'o, Linuxin satunnaislukualijärjestelmän kehittäjä, näyttää muuttaneen mieltään estopoolin tarpeesta. Hän sanoi, että tämän poolin poistaminen pääsisi tehokkaasti eroon ajatuksesta, että Linuxissa on todellinen satunnaislukugeneraattori (TRNG): "Tämä ei ole hölynpölyä, koska tämä on juuri sitä, mitä *BSD on aina tehnyt."
Hän on myös huolissaan siitä, että TRNG-mekanismin tarjoaminen toimii vain syöttinä sovelluskehittäjille, ja uskoo, että Linuxin tukemien erityyppisten laitteistojen vuoksi on mahdotonta taata TRNG:tä ytimessä. Jopa kyky työskennellä laitteiden kanssa vain pääkäyttäjän oikeuksilla ei ratkaise ongelmaa: "Sovelluskehittäjät määrittävät, että heidän sovelluksensa asennetaan pääkäyttäjänä turvallisuussyistä, joten vain tällä tavalla pääset käsiksi "todella hyviin" satunnaislukuihin."
Mueller kysyi, oliko Cao hylännyt estopoolin toteutuksen, jota hän itse oli pitkään ehdottanut. Cao vastasi, että hän aikoo ottaa Lutomirskyn korjaustiedostot ja vastustaa aktiivisesti estävän käyttöliittymän lisäämistä takaisin ytimeen.
"Ydin ei voi antaa takeita siitä, onko melulähde kuvattu oikein. Ainoa asia, jonka GPG- tai OpenSSL-kehittäjä voi saada, on epämääräinen tunne, että TRUERANDOM on "parempi", ja koska he haluavat lisää turvallisuutta, he epäilemättä yrittävät käyttää sitä. Jossain vaiheessa se estetään, ja kun joku muu älykäs käyttäjä (ehkä jakeluasiantuntija) lisää sen aloitusskriptiin ja järjestelmät lakkaavat toimimasta, käyttäjien tarvitsee vain valittaa Linus Torvaldsille itselleen."
Cao kannattaa myös sitä, että kryptografeille ja niille, jotka todella tarvitsevat TRNG:tä, annetaan mahdollisuus kerätä omaa entropiaan käyttäjätilassa käytettäväksi parhaaksi katsomallaan tavalla. Hän sanoo, että entropian kerääminen ei ole prosessi, jota ydin voi suorittaa kaikilla tukemillaan laitteilla, eikä ydin voi itse arvioida eri lähteiden tarjoaman entropian määrää.
"Ytimen ei pitäisi sekoittaa eri kohinalähteitä keskenään, eikä sen pitäisi varmastikaan yrittää väittää tietävänsä kuinka monta bittiä entropiaa se saa, kun se yrittää pelata jonkinlaista "nykivää entropiapeliä" järjettömän yksinkertaisella prosessorilla. arkkitehtuuri kuluttajakäyttäjille. IOT/sulautetut tapaukset, joissa kaikki ei ole synkronoitu yhden pääoskillaattorin kanssa, joissa ei ole CPU-käskyä järjestellä tai nimetä uudelleen rekisteri jne.
”Voit puhua työkalujen tarjoamisesta, jotka yrittävät tehdä näitä laskelmia, mutta tällaiset asiat on tehtävä jokaisen käyttäjän laitteistolla, mikä ei yksinkertaisesti ole käytännöllistä useimmille jakelukäyttäjille. Jos tämä on tarkoitettu vain kryptografeille, niin tehkää se heidän käyttäjätilassaan. Ja älkäämme yksinkertaistako GPG:tä, OpenSSL:ää jne. niin, että kaikki sanovat "haluamme "todellisen satunnaisuuden" emmekä tyydy vähempään. Voimme puhua siitä, kuinka tarjoamme salaustyöntekijöille rajapintoja, jotta he voivat saada tarvitsemansa tiedot käsiksi ensisijaisesti eroteltuihin ja nimettyihin melulähteisiin, ja ehkä jotenkin melulähde voi todentaa itsensä kirjastoon tai käyttäjätilasovellukseen."
Keskusteltiin jonkin verran siitä, miltä tällainen käyttöliittymä saattaisi näyttää, koska sillä saattaa olla esimerkiksi turvallisuusvaikutuksia joissakin tapahtumissa. Cao huomautti, että näppäimistön skannauskoodit (eli näppäinpainallukset) sekoitetaan pooliin osana entropian keräämistä: "Tämän tuominen käyttäjäavaruuteen, jopa etuoikeutetun järjestelmäkutsun kautta, olisi vähintäänkin viisasta." On täysin mahdollista, että muut tapahtuma-ajoitukset voivat aiheuttaa jonkinlaista tietovuotoa sivukanavien kautta.
Joten näyttää siltä, että Linuxin satunnaislukualijärjestelmän pitkäaikainen ongelma on matkalla ratkaisuun. Muutokset, jotka satunnaislukualijärjestelmä on viime aikoina käynyt läpi, ovat itse asiassa johtaneet vain DoS-ongelmiin sen käytön aikana. Nyt on olemassa tehokkaita tapoja saada parhaat ytimen tarjoamat satunnaisluvut. Jos TRNG on edelleen toivottava Linuxissa, tämä virhe on korjattava tulevaisuudessa, mutta todennäköisesti tätä ei tehdä itse ytimessä.
Muutamia mainoksia 🙂
Kiitos, että pysyt kanssamme. Pidätkö artikkeleistamme? Haluatko nähdä mielenkiintoisempaa sisältöä? Tue meitä tekemällä tilauksen tai suosittelemalla ystäville, , ainutlaatuinen lähtötason palvelimien analogi, jonka me keksimme sinulle: (saatavana RAID1:n ja RAID10:n kanssa, jopa 24 ydintä ja jopa 40 Gt DDR4-muistia).
Dell R730xd 2 kertaa halvempi Equinix Tier IV -palvelinkeskuksessa Amsterdamissa? Vain täällä Alankomaissa! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - alkaen 99 dollaria! Lukea
Lähde: will.com