Se sap que /dev/random, un generador de números pseudoaleatoris criptogràficament segur (CSPRNG), té un problema molest: el bloqueig. Aquest article explica com podeu resoldre'l.
Durant els darrers mesos, les instal·lacions de generació de nombres aleatoris al nucli s'han reelaborat lleugerament, però els problemes en aquest subsistema s'han resolt al llarg del procés més ampli. . El més es van fer per evitar que la trucada al sistema getrandom() es bloquegés durant molt de temps quan el sistema arrenca, però la raó subjacent d'això va ser el comportament de bloqueig del grup aleatori. Un pedaç recent hauria eliminat aquest grup i s'hauria esperat que es dirigiria cap al nucli principal.
Andy Lutomirski va publicar la tercera versió del pegat a finals de desembre. Ell contribueix "dos canvis semàntics importants a les API de Linux aleatòries". El pedaç afegeix un nou senyalador GRND_INSECURE a la crida al sistema getrandom() (encara que Lutomirsky s'hi refereix com getentropy(), que s'implementa a la glibc utilitzant getrandom() amb senyaladors fixos); aquest senyalador fa que la trucada torni sempre la quantitat de dades sol·licitades, però sense garantir que les dades siguin aleatòries. El nucli simplement farà tot el possible per produir les millors dades aleatòries que tingui en el moment donat. "Probablement el millor que cal fer és anomenar-lo 'INSEGUR' (insegur) per evitar que aquesta API s'utilitzi per a coses que necessiten seguretat".
Els pedaços també eliminen el grup de bloqueig. Actualment, el nucli manté dos grups de dades aleatòries, un corresponent a /dev/random i l'altre a /dev/urandom, tal com es descriu en aquest 2015. El grup de bloqueig és el grup per a /dev/random; les lectures d'aquest dispositiu es bloquejaran (és a dir, el seu nom) fins que s'hagi recollit "prou" entropia del sistema per satisfer la sol·licitud. Les lectures addicionals d'aquest fitxer també es bloquegen si no hi ha prou entropia al grup.
L'eliminació del grup de bloqueig significa que la lectura de /dev/random es comporta com getrandom() amb els indicadors posats a zero (i converteix el senyalador GRND_RANDOM en un noop). Un cop inicialitzat el generador de números aleatoris criptogràfics (CRNG), la lectura de /dev/random i les trucades a getrandom(...,0) no es bloquejarà i retornarà la quantitat de dades aleatòries sol·licitada.
Lutomirsky diu: "Crec que el grup de bloqueig de Linux ha quedat obsolet. CRNG Linux genera una sortida prou bona fins i tot per utilitzar-la per a la generació de claus. El grup de bloqueig no és més fort en cap sentit material i requereix molta infraestructura de dubtós valor per donar-hi suport".
Els canvis es van fer amb l'objectiu d'assegurar que els programes existents no es veurien realment afectats i, de fet, hi hauria menys problemes amb les llargues esperes per a coses com la generació de claus GnuPG.
"Aquests episodis no han d'interrompre cap programa existent. /dev/urandom roman sense canvis. /dev/random encara bloqueja immediatament després de l'arrencada, però bloqueja menys que abans. getentropy() amb els indicadors existents retornarà un resultat tan adequat per a finalitats pràctiques com abans."
Lutomirsky va assenyalar que encara és una qüestió oberta si el nucli hauria de proporcionar els anomenats "nombres aleatoris veritables", que és el que se suposava que havia de fer el nucli de bloqueig fins a cert punt. Només veu una raó per a això: "compliment dels estàndards governamentals". Lutomirsky va suggerir que si el nucli hagués de proporcionar això, s'hauria de fer a través d'una interfície completament diferent, o s'hauria de moure a l'espai d'usuari, permetent a l'usuari recuperar mostres d'esdeveniments en brut que es podrien utilitzar per crear aquest grup de bloqueig.
Stephan Müller va suggerir que el seu conjunt per Linux Random Number Generator (LRNG) (actualment la versió 26 publicada) podria ser una manera de proporcionar números aleatoris reals per a les aplicacions que ho necessitin. LLRNG compleix "totalment amb les directrius SP800-90B sobre fonts d'entropia utilitzades per generar bits aleatoris", cosa que la converteix en una solució al problema dels estàndards governamentals.
Matthew Garrett es va oposar al terme "dades aleatòries veritables", assenyalant que els dispositius mostrejats es podrien modelar en principi amb prou precisió com per fer-los previsibles: "no estem mostrant esdeveniments quàntics aquí".
Müller va respondre que el terme prové de l'estàndard alemany AIS 31 per descriure un generador de números aleatoris que només produeix un resultat "a la mateixa velocitat que la font de soroll subjacent produeix entropia".
Deixant de banda les diferències de terminologia, tenir un grup de bloqueig tal com suggereixen els pedaços de LRNG simplement comportarà diversos problemes, almenys si s'hi accedeix sense privilegis.
Com va dir Lutomirsky: "Això no resol el problema. Si dos usuaris diferents executen programes estúpids com gnupg, només s'esgotaran mútuament. Veig que actualment hi ha dos problemes principals amb /dev/random: és propens a DoS (és a dir, esgotament de recursos, influència maliciosa o alguna cosa semblant) i com que no es requereixen privilegis per utilitzar-lo, també és propens a abusar. Gnupg està equivocat, és un col·lapse total. Si afegim una nova interfície sense privilegis que utilitzaran gnupg i programes similars, tornarem a perdre".
Mueller va assenyalar que l'addició de getrandom() ara permetrà a GnuPG utilitzar aquesta interfície, ja que proporcionarà la garantia necessària que el grup s'ha inicialitzat. Basant-se en les discussions amb el desenvolupador de GnuPG Werner Koch, Mueller creu que la garantia és l'única raó per la qual actualment GnuPG llegeix directament des de /dev/random. Però si hi ha una interfície sense privilegis susceptible de denegació de servei (com és /dev/random avui), Lutomirsky argumenta que algunes aplicacions faran un mal ús.
Theodore Yue Tak Ts'o, desenvolupador del subsistema de nombres aleatoris de Linux, sembla haver canviat d'opinió sobre la necessitat d'un grup de bloqueig. Va dir que eliminar aquest grup de manera efectiva eliminaria la idea que Linux té un veritable generador de números aleatoris (TRNG): "Això no és una tonteria, ja que això és exactament el que *BSD ha fet sempre".
També li preocupa que proporcionar un mecanisme TRNG simplement serveixi d'esquer per als desenvolupadors d'aplicacions i creu que, de fet, atesos els diferents tipus de maquinari suportats per Linux, és impossible garantir TRNG al nucli. Fins i tot la capacitat de treballar amb equips només amb privilegis root no solucionarà el problema: "Els desenvolupadors d'aplicacions especifiquen que la seva aplicació s'instal·la com a root per motius de seguretat, de manera que aquesta és l'única manera d'accedir als números aleatoris "molt bons"".
Mueller va preguntar si Cao havia abandonat la implementació del grup de bloqueig que ell mateix havia proposat durant molt de temps. Cao va respondre que planeja agafar els pegats de Lutomirsky i s'oposa activament a afegir una interfície de bloqueig al nucli.
"El nucli no pot donar cap garantia sobre si la font de soroll s'ha caracteritzat correctament. L'únic que pot tenir un desenvolupador de GPG o OpenSSL és una vaga sensació que TRUERANDOM és "millor", i com que volen més seguretat, sens dubte intentaran utilitzar-lo. En algun moment es bloquejarà, i quan un altre usuari intel·ligent (potser un especialista en distribució) l'insereixi a l'script d'inici i els sistemes deixin de funcionar, els usuaris només hauran de queixar-se al mateix Linus Torvalds".
Cao també defensa que els criptògrafs i aquells que realment necessiten TRNG una manera de recollir la seva pròpia entropia a l'espai d'usuari per utilitzar-los com creguin convenient. Diu que la recollida d'entropia no és un procés que el nucli pugui dur a terme en tots els diferents maquinari que admet, ni el propi nucli pot estimar la quantitat d'entropia proporcionada per diferents fonts.
"El nucli no hauria de barrejar diferents fonts de soroll junts i, certament, no hauria d'intentar afirmar saber quants bits d'entropia obté quan intenta jugar a algun tipus de "joc d'entropia convulsa" en una CPU escandalosament senzilla. arquitectura per a usuaris consumidors IOT/Incrustats en què tot està fora de sincronització amb un sol oscil·lador mestre, on no hi ha instruccions de CPU per reordenar o canviar el nom d'un registre, etc.
“Es pot parlar de proporcionar eines que intentin fer aquests càlculs, però aquestes coses s'han de fer al maquinari de cada usuari, cosa que simplement no és pràctica per a la majoria dels usuaris de distribució. Si això només està pensat per a criptògrafs, deixeu-ho fer al seu espai d'usuari. I no simplifiquem GPG, OpenSSL, etc. perquè tothom digui "volem "autèntica aleatorietat" i no ens conformarem amb menys". Podem parlar de com proporcionem interfícies als criptògrafs perquè puguin obtenir la informació que necessiten accedint a les fonts de soroll primàries, separades i anomenades, i potser d'alguna manera la font de soroll es pot autenticar en una biblioteca o aplicació d'espai d'usuari".
Hi va haver una discussió sobre com podria ser una interfície d'aquest tipus, ja que, per exemple, hi podria haver implicacions de seguretat per a alguns esdeveniments. Cao va assenyalar que els codis d'exploració del teclat (és a dir, les pulsacions de tecles) es barregen en un grup com a part de la recollida d'entropia: "Portar-ho a l'espai de l'usuari, fins i tot mitjançant una trucada al sistema privilegiada, seria imprudent per dir-ho com a mínim". És molt possible que altres horaris d'esdeveniments puguin generar algun tipus de fuga d'informació a través de canals secundaris.
Per tant, sembla que un problema de llarga data amb el subsistema de nombres aleatoris de Linux està en camí cap a una solució. Els canvis que ha sofert recentment el subsistema de nombres aleatoris només han donat lloc a problemes de DoS mentre l'utilitzaven. Ara hi ha maneres eficients d'obtenir els millors números aleatoris que el nucli pot proporcionar. Si TRNG encara és desitjable a Linux, llavors aquest defecte s'haurà d'abordar en el futur, però el més probable és que això no es faci dins del propi nucli.
Alguns anuncis 🙂
Gràcies per quedar-te amb nosaltres. T'agraden els nostres articles? Vols veure més contingut interessant? Doneu-nos suport fent una comanda o recomanant als amics, , un anàleg únic dels servidors d'entrada, que vam inventar per a vosaltres: (disponible amb RAID1 i RAID10, fins a 24 nuclis i fins a 40 GB DDR4).
Dell R730xd 2 vegades més barat al centre de dades Equinix Tier IV a Amsterdam? Només aquí als Països Baixos! Dell R420 - 2x E5-2430 2.2 Ghz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gbps 100 TB - a partir de 99 $! Llegeix sobre
Font: www.habr.com
