/dev/random, kriptografie sekura pseŭdo-hazarda nombro-generatoro (CSPRNG), povas havi unu ĝenan problemon: blokado. Ĉi tiu artikolo klarigas kiel vi povas solvi ĝin.
Dum la lastaj monatoj, la hazardaj nombrogeneraciaj instalaĵoj en la kerno estis iomete reverkitaj, sed problemoj en ĉi tiu subsistemo estis solvitaj dum la pli larĝa. . La plej estis faritaj por malhelpi la getrandom() sistemvokon de blokado dum longa tempo kiam la sistemo ekfunkciigas, sed la subesta kialo por tio estis la blokadkonduto de la hazarda naĝejo. Lastatempa flikaĵo forigintus ĉi tiun naĝejon kaj ĝi estus atendita direktiĝi al la ĉefa kerno.
Andy Lutomirski publikigis la trian version de la flikaĵo fine de decembro. Li kontribuas "du gravaj semantikaj ŝanĝoj al hazardaj Linukso-APIoj". La flikilo aldonas novan GRND_INSECURE flagon al la getrandom() sistemvoko (kvankam Lutomirsky nomas ĝin getentropy(), kiu estas efektivigita en glibc uzante getrandom() kun fiksaj flagoj); ĉi tiu flago igas la alvokon ĉiam resendi la kvanton de datumoj petitaj, sed sen garantii ke la datumoj estas hazardaj. La kerno simple faros sian eblon por produkti la plej bonajn hazardajn datumojn, kiujn ĝi havas en la donita tempo. "Verŝajne la plej bona afero por fari estas nomi ĝin 'NESEKURA' (nesekura) por malhelpi ĉi tiun API esti uzata por aferoj kiuj bezonas sekurecon."
La pecetoj ankaŭ forigas la blokantan naĝejon. La kerno nuntempe konservas du hazardajn datumgrupojn, unu respondante al /dev/random kaj la alia al /dev/urandom, kiel priskribite en ĉi tiu 2015. La blokado estas la pool por /dev/random; legas por tiu aparato blokos (kun la signifo ĝia nomo) ĝis "sufiĉe" entropio estis kolektita de la sistemo por kontentigi la peton. Pliaj legaĵoj de ĉi tiu dosiero ankaŭ estas blokitaj se ne estas sufiĉe da entropio en la naĝejo.
Forigi la ŝlosilon signifas ke legado de /dev/random kondutas kiel getrandom() kun flagoj agordita al nulo (kaj igas la GRND_RANDOM flagon en noop). Post kiam la kriptiga hazarda nombrogeneratoro (CRNG) estas pravigita, legado de /dev/random kaj vokoj al getrandom(...,0) ne blokos kaj resendos la petitan kvanton da hazardaj datumoj.
Lutomirsky diras: “Mi kredas, ke la Linukso-bloka grupo malnoviĝis. CRNG Linukso generas produktaĵon sufiĉe bonan por eĉ esti uzata por ŝlosilgenerado. La blokada naĝejo ne estas pli forta en iu ajn materia signifo kaj postulas multan infrastrukturon de dubinda valoro por subteni ĝin."
La ŝanĝoj estis faritaj kun la celo certigi ke ekzistantaj programoj ne estus vere tuŝitaj, kaj fakte, estus malpli da problemoj kun longaj atendoj por aferoj kiel GnuPG-ŝlosilgenerado.
"Ĉi tiuj epizodoj ne devas interrompi iujn ajn ekzistantajn programojn. /dev/urandom restas senŝanĝa. /dev/random ankoraŭ blokas tuj post lanĉo, sed ĝi blokas malpli ol antaŭe. getentropy() kun la ekzistantaj flagoj redonos rezulton same taŭgan por praktikaj celoj kiel antaŭe."
Lutomirsky rimarkis, ke estas ankoraŭ malferma demando, ĉu la kerno devus provizi tiel nomatajn "verajn hazardajn nombrojn", kio estas tio, kion la blokanta kerno laŭsupoze faris certagrade. Li vidas nur unu kialon por tio: "konformeco al registaraj normoj." Lutomirsky sugestis ke se la kerno disponigus tion, ĝi devus esti farita tra tute malsama interfaco, aŭ ĝi devus esti proponita en uzantspacon, permesante al la uzanto preni krudajn okazaĵprovaĵojn kiuj povus esti uzitaj por krei tian kluzgrupon.
Stephan Müller sugestis ke lia aro por Linukso Random Number Generator (LRNG) (nuntempe versio 26 publikigita) povus esti maniero disponigi verajn hazardajn nombrojn por aplikoj kiuj bezonas ĝin. LRNG estas "plene konforma al SP800-90B Gvidlinioj pri Entropio-Fontoj Uzitaj por Generar Hazardajn Bitojn", farante ĝin solvo al la registara normproblemo.
Matthew Garrett protestis kontraŭ la esprimo "veraj hazardaj datumoj", rimarkante, ke la aparatoj provitaj principe povus esti modeligitaj sufiĉe precize por igi ilin antaŭvideblaj: "ni ne provas kvantumajn eventojn ĉi tie."
Müller respondis ke la esprimo venas de la germana normo AIS 31 por priskribi hazardan nombrogeneratoron kiu nur produktas rezulton "kun la sama rapideco kiam la subesta brufonto produktas entropion."
Terminologiaj diferencoj flankenmetite, havi ŝlosilon kiel sugestite de la LRNG-flakoj simple kondukos al diversaj problemoj, almenaŭ se ĝi estas alirita sen privilegioj.
Kiel Lutomirsky diris: “Ĉi tio ne solvas la problemon. Se du malsamaj uzantoj ruligas stultajn programojn kiel gnupg, ili simple malplenigos unu la alian. Mi vidas, ke nuntempe ekzistas du ĉefaj problemoj kun /dev/random: ĝi estas inklina al DoS (t.e. rimedo-malplenigo, malica influo aŭ io simila), kaj ĉar neniuj privilegioj estas bezonataj por uzi ĝin, ĝi ankaŭ inklinas al misuzo. Gnupg eraras, ĝi estas kompleta kolapso. Se ni aldonas novan senprivilegian interfacon kiun uzos gnupg kaj similaj programoj, ni denove perdos."
Mueller rimarkis, ke la aldono de getrandom() nun permesos al GnuPG uzi ĉi tiun interfacon, ĉar ĝi provizos la necesan garantion, ke la aro estas pravalorigita. Surbaze de diskutoj kun GnuPG-programisto Werner Koch, Mueller opinias, ke la garantio estas la sola kialo, ke GnuPG nuntempe legas rekte de /dev/random. Sed se ekzistas senprivilegia interfaco kiu estas susceptible al neo de servo (kiel /dev/random estas hodiaŭ), Lutomirsky argumentas ke ĝi estos misuzata de iuj aplikoj.
Theodore Yue Tak Ts'o, ellaboranto de la hazarda nombro-subsistemo de Linukso, ŝajnas esti ŝanĝinta opinion pri la bezono de blokada naĝejo. Li diris, ke forigi ĉi tiun naĝejon efike forigus la ideon, ke Linukso havas veran hazardan nombrogeneratoron (TRNG): "ĉi tio ne estas sensencaĵo, ĉar ĝuste ĉi tion *BSD ĉiam faris."
Li ankaŭ zorgas pri tio, ke provizi TRNG-mekanismon simple servos kiel logilo por programistoj de aplikaĵoj kaj kredas ke fakte, konsiderante la malsamajn specojn de aparataro subtenataj de Linukso, estas neeble garantii TRNG en la kerno. Eĉ la kapablo labori kun ekipaĵo nur kun radikaj privilegioj ne solvos la problemon: "Programistoj de aplikaĵoj precizigas, ke ilia aplikaĵo estu instalita kiel radiko por sekurecaj celoj, tiel ke ĉi tio estas la nura maniero kiel vi povas aliri la "vere bonajn" hazardajn nombrojn."
Mueller demandis ĉu Cao prirezignis la blokan naĝejon efektivigon kiun li mem longe proponis. Cao respondis ke li planas preni la pecetojn de Lutomirsky kaj aktive kontraŭas aldoni blokantan interfacon reen al la kerno.
"La kerno ne povas fari ajnajn garantiojn ĉu la brufonto estis konvene karakterizita. La nura afero, kiun GPG aŭ OpenSSL-programisto povas akiri, estas neklara sento, ke TRUERANDOM estas "pli bona", kaj ĉar ili volas pli da sekureco, ili sendube provos uzi ĝin. Iam ĝi estos blokita, kaj kiam iu alia inteligenta uzanto (eble distribua specialisto) enŝovos ĝin en la init-skripton kaj la sistemoj ĉesos funkcii, uzantoj devos nur plendi al Linus Torvalds mem."
Cao ankaŭ rekomendas doni al kriptografoj kaj tiuj kiuj fakte bezonas TRNG manieron rikolti sian propran entropion en uzantspaco por uzi kiel ili opinias konvene. Li diras ke kolekti entropion ne estas procezo kiu povas esti farita per la kerno sur la tuta malsama hardvaro kiun ĝi apogas, nek la kerno mem povas taksi la kvanton de entropio disponigita per malsamaj fontoj.
"La kerno ne devus miksi malsamajn bruajn fontojn kune, kaj ĝi certe ne devus aserti scii kiom da entropioj ĝi ricevas kiam ĝi provas ludi ian "konvulsian entropian ludon" sur skandale simpla CPU. arkitekturo por konsumantoj. IOT/Embedded kazoj kie ĉio estas malsinkronigita kun ununura majstra oscilatoro, kie ekzistas neniu CPU-instrukcio por reordigi aŭ renomi registron, ktp."
“Vi povas paroli pri disponigado de iloj kiuj provas fari ĉi tiujn kalkulojn, sed tiaj aferoj devas esti faritaj sur la aparataro de ĉiu uzanto, kio simple ne estas praktika por la plej multaj distribuuzantoj. Se ĉi tio estas nur destinita por kriptografoj, tiam ĝi estu farita en ilia uzantspaco. Kaj ni ne simpligu GPG, OpenSSL, ktp, por ke ĉiuj diru "ni volas "veran hazardon" kaj ne kontentiĝos je malpli." Ni povas paroli pri kiel ni disponigas interfacojn al kriptografistoj tiel ke ili povas ricevi la informojn kiujn ili bezonas alirante la primarajn brufontojn, apartigitajn kaj nomitajn, kaj eble iel la brufonto povas aŭtentikigi sin al biblioteko aŭ uzantspacapliko."
Estis iom da diskuto pri kia tia interfaco povus aspekti, ĉar ekzemple povus esti sekurecaj implicoj por iuj eventoj. Cao notis ke klavaraj skankodoj (t.e. klavopremoj) estas miksitaj en naĝejon kiel parto de entropiokolekto: "Alporti tion en uzantspacon, eĉ tra privilegia sistemvoko, estus malprudenta diri la malplej." Estas tute eble, ke aliaj okazaĵaj tempoj povas krei ian informan elfluon tra flankaj kanaloj.
Do ŝajnas, ke longdaŭra problemo pri la hazarda nombro-subsistemo de Linukso estas survoje al solvo. La ŝanĝoj, kiujn la hazarda nombro-subsistemo spertis lastatempe, fakte nur rezultigis DoS-problemojn dum ĝi uzis. Nun ekzistas efikaj manieroj akiri la plej bonajn hazardajn nombrojn, kiujn la kerno povas provizi. Se TRNG ankoraŭ estas dezirinda en Linukso, tiam ĉi tiu difekto devos esti traktita estonte, sed plej verŝajne tio ne estos farita ene de la kerno mem.
Kelkaj reklamoj 🙂
Dankon pro restado ĉe ni. Ĉu vi ŝatas niajn artikolojn? Ĉu vi volas vidi pli interesan enhavon? Subtenu nin farante mendon aŭ rekomendante al amikoj, , unika analogo de enirnivelaj serviloj, kiu estis inventita de ni por vi: (havebla kun RAID1 kaj RAID10, ĝis 24 kernoj kaj ĝis 40GB DDR4).
Dell R730xd 2 fojojn pli malmultekosta en Equinix Tier IV datumcentro en Amsterdamo? Nur ĉi tie en Nederlando! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ekde $99! Legu pri
fonto: www.habr.com