In che modo un sistema operativo crea entropia per semi casuali?


19

Su Linux, i file /dev/randome i/dev/urandom file sono le fonti bloccanti e non bloccanti (rispettivamente) di byte pseudo-casuali.

Possono essere letti come file normali:

$ hexdump /dev/random
0000000 28eb d9e7 44bb 1ac9 d06f b943 f904 8ffa
0000010 5652 1f08 ccb8 9ee2 d85c 7c6b ddb2 bcbe
0000020 f841 bd90 9e7c 5be2 eecc e395 5971 ab7f
0000030 864f d402 74dd 1aa8 925d 8a80 de75 a0e3
0000040 cb64 4422 02f7 0c50 6174 f725 0653 2444
...

Molte altre varianti di unix forniscono /dev/randome /dev/urandompure, senza la distinzione blocco / non blocco.

L'equivalente di Windows è la CryptGenRandom()funzione .

In che modo il sistema operativo genera pseudo-casualità?


Che ricerca hai fatto? Hai cercato su siti standard, come Wikipedia, o su Security.SE o Crypto.SE? Wikipedia ha un articolo su questo: en.wikipedia.org/wiki//dev/random . Quando Wikipedia ha un articolo che risponde alla tua domanda, è praticamente la definizione di non aver fatto abbastanza ricerche. (Ci aspettiamo che tu faccia una notevole quantità di ricerche prima di fare una domanda qui, e che ci mostri nella domanda di ricerca che hai fatto.)
DW

Risposte:


31

Il titolo e il corpo della tua domanda pongono due domande diverse: come il sistema operativo crea l'entropia (questo dovrebbe davvero ottenere l' entropia) e come genera pseudo-casualità da questa entropia. Inizierò spiegando la differenza.

Da dove viene la casualità?

I generatori di numeri casuali (RNG) sono disponibili in due tipi:

Alcune applicazioni, come le simulazioni di fenomeni fisici, possono essere contenti di numeri casuali che superano test statistici. Altre applicazioni, come la generazione di chiavi crittografiche, richiedono una proprietà più forte: l' imprevedibilità . L'imprevedibilità è una proprietà di sicurezza, non (solo) una proprietà statistica: significa che un avversario non può indovinare l'output del generatore di numeri casuali. (Più precisamente, è possibile misurare la qualità dell'RNG misurando la probabilità per un avversario di indovinare ogni bit di output dell'RNG. Se la probabilità è misurabilmente diversa da 1/2, l'RNG è scadente.)

Esistono fenomeni fisici che producono dati casuali con buone proprietà statistiche, ad esempio il decadimento radioattivo o alcune osservazioni astronomiche del rumore di fondo o delle fluttuazioni del mercato azionario. Tali misurazioni fisiche richiedono un condizionamento ( sbiancamento ), per trasformare le distribuzioni di probabilità distorte in una distribuzione di probabilità uniforme. Una misurazione fisica nota a tutti non fa bene alla crittografia: le fluttuazioni del mercato azionario potrebbero essere utili per il geohashing , ma non è possibile utilizzarle per generare chiavi segrete .

La crittografia richiede segretezza : un avversario non deve essere in grado di scoprire i dati che sono stati condizionati. Esistono generatori di numeri pseudo-casuali (CSPRNG) crittograficamente sicuri : algoritmi PRNG il cui output è adatto per l'uso in applicazioni crittografiche, oltre ad avere buone proprietà statistiche . Una delle proprietà che rendono un CSPRNG crittograficamente sicuro è che il suo output non consente a un avversario di ricostruire lo stato interno (conoscere tutti i bit tranne uno prodotto da un CSPRNG non aiuta a trovare il bit mancante). Non entrerò nel modo di creare un CSPRNG perché è un po 'semplice: puoi seguire le ricette fornite dai crittografi professionisti (usa uno standardalgoritmo, come Hash_DRBG, HMAC_DRBG o CTR_DRBG da NIST SP 800-90A ) o ANSI X9.31 PRNG . Il CSPRNG richiede due proprietà del suo stato per essere sicuro:

  • Lo stato deve essere tenuto segreto dall'inizio e in ogni momento (anche se l'esposizione dello stato non rivelerà le uscite passate).
  • Lo stato deve essere lineare: l'RNG non deve mai essere avviato due volte dallo stesso stato.

Architettura di un generatore di numeri casuali

In pratica, quasi tutti i buoni generatori di numeri casuali combinano un CSPRNG con una o più fonti di entropia . Per dirla in modo succinto, l'entropia è una misura dell'imprevedibilità di una fonte di dati. Basare un generatore di numeri casuali esclusivamente su un RNG hardware è difficile:

  • È probabile che i dati fisici grezzi debbano comunque essere condizionati, per trasformare i dati probabilistici in una distribuzione uniforme.
  • L'output dalla fonte di casualità deve essere tenuto segreto.
  • Le fonti di entropia sono spesso lente rispetto alla domanda.

Quindi l'RNG in un sistema operativo funziona quasi sempre così :

  1. Accumula entropia sufficiente per costruire uno stato interno imprevedibile.
  2. Esegui un CSPRNG , usando l'entropia accumulata come seme, ovvero come valore iniziale dello stato interno.
  3. Facoltativamente, mescolare periodicamente entropia aggiuntiva nello stato interno. (Ciò non è strettamente necessario, dal momento che l' entropia non viene "consumata" in alcun modo misurabile . Aiuta contro alcune minacce che perdono lo stato di RNG senza compromettere l'intero sistema.)

Un servizio di generazione di numeri casuali fa parte del lavoro di un sistema operativo, poiché la raccolta di entropia richiede l'accesso all'hardware e le fonti di entropia costituiscono una risorsa condivisa: il sistema operativo deve assemblarli e ricavarne l'output adatto alle applicazioni. Il condizionamento pseudo-casuale delle fonti entropiche è richiesto nel sistema operativo; potrebbe anche essere crittograficamente sicuro, perché questo non è fondamentalmente più difficile (ed è richiesto sui sistemi operativi in ​​cui le applicazioni non si fidano l'una dell'altra; su sistemi pienamente cooperativi, ogni applicazione dovrebbe eseguire il proprio CSPRNG internamente se il sistema operativo non ne ho fornito uno comunque).

La maggior parte dei sistemi con archiviazione persistente caricherà un seed RNG dal disco (userò "disk" come abbreviazione per qualsiasi tipo di archiviazione persistente) quando si avvia e sovrascriverà il seed con alcuni nuovi dati pseudo-casuali generati da quel seed, o se disponibile con dati casuali generati da quel seme più un'altra fonte di entropia. In questo modo, anche se l'entropia non è disponibile dopo un riavvio, l'entropia di una sessione precedente viene riutilizzata.

È necessario prestare attenzione allo stato salvato. Ricordi come ho detto che lo stato deve essere lineare? Se si avvia due volte dallo stesso stato del disco, si otterranno gli stessi output RNG. Se questa è una possibilità nel tuo ambiente, hai bisogno di un'altra fonte di entropia. Prestare attenzione durante il ripristino da backup o durante la clonazione di una macchina virtuale . Una tecnica per la clonazione è quella di mescolare l'entropia memorizzata con alcuni dati ambientali prevedibili ma unici (ad es. Tempo e indirizzo MAC); attenzione che se i dati ambientali sono prevedibili, chiunque sia in possesso dello stato di VM memorizzato può ricostruire il seed di un'istanza di VM biforcuta.

Fonti di entropia

Trovare (e usare correttamente) le fonti entropiche è la parte più difficile della generazione di numeri casuali in un sistema operativo. Le fonti di entropia disponibili dipenderanno necessariamente dall'hardware e dall'ambiente in cui l'hardware è in esecuzione.

Se sei fortunato, il tuo hardware fornisce una periferica che può essere utilizzata come fonte di entropia: un generatore di numeri casuali hardware , sia dedicato che finalizzato. Per esempio:

NIST SP800-90B fornisce le linee guida di progettazione per l'RNG hardware. La valutazione di un RNG hardware è difficile . L'hardware RNG è in genere un animale delicato, che deve essere usato con cura: molti tipi richiedono un po 'di tempo dopo l'avvio e un po' di tempo tra le letture per destabilizzarsi, sono spesso sensibili a condizioni ambientali come la temperatura, ecc.

I processori Intel x86-64 basati sull'architettura Ivy Bridge forniscono le RdRandistruzioni che forniscono l'output di un CSPRNG generato dal rumore termico . La maggior parte dei processori per smartphone include una sorgente di entropia hardware, sebbene Android non la usi sempre.

I sistemi che non hanno una forte fonte di entropia devono accontentarsi di combinare fonti di entropia deboli e sperare ( assicurarsi che sarebbe una parola troppo forte) che basteranno. I movimenti casuali del mouse sono popolari per le macchine client e potresti aver visto lo spettacolo di sicurezza da alcuni programmi di crittografia che ti chiedono di spostare il mouse (anche se su qualsiasi sistema operativo per PC del 21 ° secolo il sistema operativo avrà accumulato entropia senza che l'applicazione debba preoccuparsi ).

Se vuoi guardare un esempio, puoi guardare Linux, ma fai attenzione che non sia perfetto . In particolare, si /dev/randomblocca troppo spesso (perché blocca fino a quando non è disponibile abbastanza entropia, con una nozione eccessivamente conservativa di entropia), mentre /dev/urandomè quasi sempre buono tranne che al primo avvio ma non dà indicazioni quando non ha abbastanza entropia. Linux ha i driver per molti dispositivi HRNG e accumula entropia da vari dispositivi (inclusi i dispositivi di input ) e temporizzazioni del disco .

Se si dispone di spazio di archiviazione (riservato) persistente, è possibile utilizzarlo per salvare l'entropia da un avvio all'altro, come indicato sopra. Il primo avvio è un momento delicato: il sistema potrebbe essere in uno stato abbastanza prevedibile a quel punto, specialmente su dispositivi prodotti in serie che essenzialmente funzionano fuori dalla fabbrica allo stesso modo. Ad alcuni dispositivi incorporati con memoria persistente viene eseguito il provisioning con un seed iniziale in fabbrica (prodotto da un RNG in esecuzione su un computer in fabbrica). In ambienti server virtualizzati, è possibile eseguire il provisioning dell'entropia iniziale quando si crea un'istanza di una macchina virtuale dall'host o da un server entropia.

I dispositivi con seeding errato sono in pratica un problema molto diffuso: uno studio sulle chiavi pubbliche RSA ha rilevato che molti server e dispositivi avevano chiavi generate con un RNG scadente, molto probabilmente un buon PRNG che non era stato seminato in modo sufficiente. Come progettista di sistemi operativi, non è possibile risolvere questo problema da soli: è compito dell'entità controllare la catena di distribuzione per garantire che l'RNG venga correttamente seminato al primo avvio. Il tuo compito come progettista di sistemi operativi è di fornire un RNG adeguato, inclusa un'interfaccia per fornire quel primo seed, e di garantire una corretta segnalazione degli errori se l'RNG viene utilizzato prima che venga correttamente eseguito il seeding.


5
Freaking risposta stellare.
Adam Maras,

Questo == fantastico.

"Non ci sono fonti di informazione che sono conosciute per essere veramente casuali" Non sono d'accordo. L'interpretazione prevalente (di Copenaghen) della meccanica quantistica afferma che il risultato della misurazione di un sistema che si trova in una sovrapposizione di possibili esiti è veramente casuale, nel senso che non possiamo mai prevederne l'esito ma possiamo semplicemente fornire una distribuzione di probabilità (nella migliore delle ipotesi) . Fonte: studente laureato in fisica qui
balu,

3

Oltre alla risposta di Gilles, gli interrupt possono anche essere usati per stabilire l'entropia. In Linux, ad esempio, quando si aggiunge un gestore di interrupt è possibile definire se ricorrere a questo interrupt come contributo al pool di entropia del kernel.

Naturalmente questo non dovrebbe mai essere il caso di interruzioni che un attaccante potrebbe essere in grado di determinare. Ad esempio, a prima vista il traffico di rete (ovvero le interruzioni che ne risultano) sembra essere una buona fonte di casualità. Tuttavia, un utente malintenzionato potrebbe essere in grado di manipolare il traffico in modo tale da poter prevedere la casualità necessaria per alcune operazioni.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.