/dev/random
Nei sistemi operativi Unix e Unix-like, /dev/random (random device, dispositivo casuale) è un file speciale (ossia non fisicamente presente su memoria di massa) con la caratteristica di restituire un valore numerico casuale o pseudo-casuale ogni volta che vi si accede. Consente di accedere al rumore ambientale raccolto dai dispositivi collegati e da altre sorgenti. /dev/random viene utilizzato per esempio per il test di applicazioni che operano su numeri casuali, o come sistema per individuare errori di programmazione (bug) su input casuali. Può essere impiegato anche per simulare il "rumore" (vale a dire la presenza di dati non corretti) nelle sequenze di input verso i driver di periferica. Un diverso utilizzo si ha nel campo della crittografiadove /dev/random può essere utilizzato per generare chiavi crittografiche casuali sia ad uso del sistema operativo che delle applicazioni.
Non tutti i sistemi operativi implementano la stessa semantica per /dev/random. Linux è stato il primo sistema Unix-like a implementare /dev/random come generatore di numeri casuali. Implementazioni simili si trovano in FreeBSD, Solaris, Mac OS X, NetBSD, OpenBSD, Tru64 UNIX 5.1B, AIX 5.2, e HP-UX 11i v2. Nei sistemiWindows della famiglia NT funzioni simili vengono svolte dal file ksecdd.sys.
Linux
La generazione di numeri casuali dal kernel è stata implementata per la prima volta in Linux[1] nel 1994 da Theodore Ts'o.[2]. L'implementazione usa hash sicuri al posto di un cifrario per evitare problemi legali che erano presenti al momento del progetto. L'implementazione tiene anche conto del fatto che un certo hash o cifrario potrebbe essere scoperto essere debole, e quindi il progetto è durabile contro ogni tale debolezza.
In questa implementazione, il generatore mantiene una stima del numero di bits di rumore nella entropy pool. Da questa entropy pool i numeri casuali sono creati. Quando viene letto, /dev/random ritorna solo byte casuali ll'interno della stima del numero di bit di rumore nell'entropy pool. /dev/random può essere adatto per gli utenti che necessitano di una casualità di ottima qualità come per la creazione di one time pad o chiavi pubbliche. Quando l'entropy pool è vuota, la lettura di /dev/random si interrompe fino a quando non viene accumulato nuovo rumore ambientale.[3] Il motivo è di fornire un generatore di numeri pseudocasuale crittograficamente sicuro, fornendo un output con un'entropia il più grande possibile.
Una controparte di /dev/random è /dev/urandom (sorgente causale non bloccata "unlocked" [4]) che riusa il pool interno per produrre bits pseudocasuali aggiuntivi. Questo significa che la richiesta non si blocca, ma il risultato potrebbe contenere meno entropia rispetto a /dev/random. Nonostante sia un generatore di numeri pseudocasuali adatto per la maggior parte delle applicazioni crittografiche, non è raccomandato per la generazione di chiavi crittografiche a lunga scadenza.
È inoltre possibile scrivere su /dev/random. Questo consente ad ogni utente di mischiare i dati casuali all'interno del pool. L'attuale ammontare dell'entropia e la dimensione dell'entropy pool del kernel Linux è disponibile attraverso /proc/sys/kernel/random/.
Nel Marzo 2006 Gutterman, Pinkas, & Reinman hanno pubblicato un'analisi dettagliata del generatore di numeri casuali di Linux[5] nel quale descrivono alcune debolezze. Probabilmente il problema più importante riportato è quello che si verifica con sistemi embedded o con i Live CD nel quale lo stato di bootup è prevedibile e l'entropia disponibile dall'ambiente potrebbe essere limitata. Per i sistemi con memoria non volatile, è raccomandato salvare qualche stato del generatore allo spegnimento in modo da poterlo usare come stato al successivo avvio. Nel caso dei router nei quali il traffico di rete rappresenta la sorgente primaria di entropia, gli autori notano che salvare lo stato tra riavvii "dovrebbe far richiere a un potenziale attaccante di spiare su tutto il traffico di rete" che passa per il router, e ottenere un accesso diretto allo stato interno del router. Questo problema è particolarmente critico nel caso di router wireless il cui traffico di rete può essere catturato a distanza, il quale può essere utilizzato per generare chiavi crittografiche.
FreeBSD
The FreeBSD operating system implements a 256-bit variant of the Yarrow algorithm, intended to provide a cryptographically secure pseudorandom stream—this replaced a previous Linux style random device. Unlike the Linux /dev/random, the FreeBSD /dev/random device never blocks. Its behavior is similar to the Linux /dev/urandom, and /dev/urandom on FreeBSD is linked to /dev/random.
Yarrow is based on the assumptions that modern PRNGs are very secure if their internal state is unknown to an attacker, and that they are better understood than the estimation of entropy. Whilst entropy pool based methods are completely secure if implemented correctly, if they overestimate their entropy they may become less secure than well-seeded PRNGs. In some cases an attacker may have a considerable amount of control over the entropy, for example a diskless server may get almost all of it from the network—rendering it potentially vulnerable to man-in-the-middle attacks. Yarrow places a lot of emphasis on avoiding any pool compromise and on recovering from it as quickly as possible. It is regularly reseeded; on a system with small amount of network and disk activity, this is done after a fraction of a second.
In 2004, Landon Curt Noll tested the FreeBSD 5.2.1 version of /dev/random and suggested that it was not cryptographically secure because its output had multiple uniformity flaws.[6] Similar flaws were found in the Linux 2.4.21-20, Solaris 8 patch 108528-18, and Mac OS X 10.3.5 implementations of /dev/random.
FreeBSD also provides support for hardware random number generators, which will replace Yarrow when present.
Other operating systems
/dev/random and /dev/urandom are also available on Solaris, Mac OS X, NetBSD, OpenBSD,
Tru64 UNIX 5.1B,
AIX 5.2,
and
HP-UX 11i v2. As with FreeBSD, AIX implements its own Yarrow-based design, however AIX uses considerably fewer entropy sources than the standard /dev/random implementation and stops refilling the pool when it thinks it contains enough entropy.[7]
In Windows NT, similar functionality is delivered by ksecdd.sys, but reading the special file \Device\KsecDD does not work as in UNIX. The documented methods to generate cryptographically random bytes are
CryptGenRandom and RtlGenRandom.
While DOS doesn't naturally provide such functionality there is an open source third-party driver called Noise.sys which functions similarly in that it creates 2 devices, RANDOM$ and URANDOM$, which are also accessible as /DEV/RANDOM$ and /DEV/URANDOM$, that programs can access for random data.
EGD as an alternative
A software program called EGD (entropy gathering daemon) is a common alternative for Unix systems which do not support the /dev/random device. It is a user space daemon which provides high quality cryptographic random data. Some cryptographic software such as OpenSSL, GNU Privacy Guard, and the Apache HTTP Server support using EGD when a /dev/random device is not available.
EGD, or a compatible alternative such as prngd, gather pseudo-random entropy from various sources, process it to remove bias and improve cryptographic quality, and then make it available over a Unix ___domain socket (with /dev/egd-pool being a common choice), or over a TCP socket. The entropy gathering usually entails periodically forking subprocesses to query attributes of the system that are likely to be frequently changing and unpredictable, such as monitoring CPU, I/O, and network usage as well as the contents of various log files and temporary directories.
EGD communicates with other programs which need random data using a simple protocol. The client connects to an EGD socket and sends a command, identified by the value of the first octet:
- command 0: query the amount of entropy currently available. The EGD daemon returns a 4-byte number in big endian format representing the number of random bytes that can currently be satisfied without delay.
- command 1: get random bytes, no blocking. The second byte in the request tells EGD how many random bytes of output it should return, from 1 to 255. If EGD does not have enough entropy to immediately satisfy the request, fewer bytes, or perhaps no bytes may be returned. The first octet of the reply indicates how many additional bytes, those containing the random data, immediately follow in the reply.
- command 2: get random bytes, blocking. The second byte tells EGD how many random bytes of output it should return. If EGD does not have enough entropy, it will wait until it has gathered enough before responding. Unlike command 1, the reply starts immediately with the random bytes rather than a length octet, as the total length of returned data will not vary from the amount requested.
- command 3: update entropy. This command allows the client to provide additional entropy to be added to EGD's internal pool. The next two bytes, interpreted as a 16-bit big endian integer indicate how many bits of randomness the caller is claiming to be supplying. The fourth byte indicates how many additional bytes of source data follow in the request. The EGD daemon may mix in the received entropy and will return nothing back.
See also
Notes
- ^ Jack Lloyd, On Syllable's /dev/random, su randombit.net, December 9, 2008. URL consultato il 27 aprile 2009 (archiviato il 29 aprile 2009).
- ^ /dev/random, su everything2.com, June 8, 2003. URL consultato il 27 aprile 2009 (archiviato il 29 aprile 2009).
- ^
- ^ http://www.kernel.org/doc/man-pages/online/pages/man4/random.4.html
- ^ Zvi Gutterman, Benny Pinkas, Tzachy Reinman, Analysis of the Linux Random Number Generator (PDF), su pinkas.net, March 6, 2006. URL consultato il 18 settembre 2008.
- ^ [[#CITEREF{{{1}}}|{{{1}}}]]
- ^ Iain Roberts, AIX 5.2 /dev/random and /dev/urandom devices, su lists.gnupg.org, April 25, 2003. URL consultato il 18 settembre 2008.
