Domanda:
Cosa rende i generatori di numeri casuali così fragili?
john doe
2018-07-29 06:10:18 UTC
view on stackexchange narkive permalink

Mi sembra che un componente hardware che genera numeri casuali sia estremamente semplice: basta misurare piccole vibrazioni nell'hardware con un sensore, giusto? Forse mi sbaglio ma sembra che se misurassi le vibrazioni con una precisione molto elevata, potresti facilmente generare numeri casuali indovinabili.

Tuttavia, sono un noob della crittografia e ne so poco. Quindi sto leggendo e un articolo dice:

e non è necessario essere così sofisticati per indebolire un generatore di numeri casuali. Questi generatori sono già sorprendentemente fragili ed è terribilmente difficile rilevare quando uno è rotto. I manutentori di Debian hanno sottolineato questo punto in modo meraviglioso nel 2008, quando un'errata pulizia del codice ha ridotto l'entropia effettiva di OpenSSL a soli 16 bit. In effetti, gli RNG sono così vulnerabili che la sfida qui non è indebolire l'RNG - qualsiasi idiota con una tastiera può farlo - lo fa senza rendere l'implementazione banalmente vulnerabile a tutti gli altri.

Sicuramente mi mancano alcuni dettagli critici su come la generazione di numeri casuali sia "fragile". Qualcuno può spiegare?

La vibrazione sarebbe probabilmente in realtà più coerente dal punto di vista matematico di quanto potresti pensare.Un modo che ho visto fare per un semplice generatore hardware è stato invertire il bias di un transistor, che produce casualità a livello quantistico.Questo era solo un semplice circuito Arduino ... Sono sicuro che i pacchetti casuali dell'hardware reale siano più sofisticati.Ma non tutti i sistemi hanno hardware a loro disposizione ... specialmente nei sistemi virtualizzati.
Va anche notato che la sezione dell'articolo che stai citando parla di un punto debole scoperto in un generatore di numeri casuali * software *.
@HarryJohnston Capisco ... Per qualche ragione ho pensato che i numeri casuali importanti sarebbero sempre stati generati lato server con hardware appropriato.Sto cercando di entrare nella crittografia ed è un argomento enorme da imparare.Probabilmente dovresti leggere un libro
@johndoe Quando il mio telefono apre un sito Web HTTPS, sia il mio telefono che il server devono generare numeri casuali segreti.Benvenuto nella crittografia!È un campo grande, ma inizia con un angolo che capisci e costruisci le tue conoscenze da lì.Ho trovato la lettura e le risposte alle domande su questo sito incredibilmente utili per il mio apprendimento.
Ho letto quella citazione come qualcuno che non è un esperto di crittografia che dà l'avvertimento generale "A MENO CHE NON SAPETE COSA STAI FACENDO, NON MODIFICARE IL CODICE CRYPTO, e anche in questo caso, fallo con molta attenzione."Non credo che gli RNG siano speciali in questo senso;qualsiasi codice crittografico sarebbe fragile se le persone iniziassero ad apportare modifiche al codice che non comprendono.
@MikeOunsworth È particolarmente vero dato che molti CSPRNG sono basati su altre primitive crittografiche come AES, ChaCha20 o SHA-1.Cambia una singola riga in SHA-1 e perdi la non linearità, interrompendo completamente un PRNG basato su di essa.Il codice Crypto dovrebbe essere considerato sacro!
Va notato che il fiasco RNG di Debian aveva ben poco a che fare con la fragilità della crittografia di per sé - era principalmente una conseguenza di quanto sia facile introdurre errori silenziosi (come invocare comportamenti indefiniti) in certi linguaggi.
Fragile qui significa "matematica così complessa che è facile romperla senza essere ovvia e siamo stati troppo pigri per creare anche suite di test di base per verificare le prestazioni dei nostri codici"
@MikeOunsworth Per essere onesti, era un codice crittografico completamente orribile e stupido che non avrebbe dovuto essere scritto in primo luogo.
`Forse mi sbaglio ma sembra che se avessi misurato le vibrazioni con una precisione molto alta` Supponendo che la parte vibrante abbia un raggio di movimento massimo, posso effettivamente" de-randomizzare "la mia funzione casuale posizionando il computer in un ambiente conperturbazioni (garantendo così una vibrazione costante da limite a limite).Ignorando questa scappatoia, stai ancora assicurando solo dati _imprevedibili_ ma non necessariamente dati ** imparziali **.Non ci sono aspettative di uguale distribuzione nel tuo oscillatore.
Cinque risposte:
#1
+75
forest
2018-07-29 08:11:50 UTC
view on stackexchange narkive permalink

RNG hardware e software

La prima cosa che dici è una fonte di rumore hardware. La misurazione ad alta precisione di alcuni fenomeni metastabili è sufficiente per generare dati imprevedibili. Questo può essere fatto con un diodo zener a polarizzazione inversa, con oscillatori ad anello, con un ADC o anche con un contatore Geiger. Si può anche misurare i ritardi a livello di nanosecondi nei tempi tra le sequenze di tasti. Queste sorgenti di rumore possono non funzionare se l'hardware stesso inizia a guastarsi. Ad esempio, un transistor può rompersi se non è specificamente progettato per funzionare al contrario ad alte tensioni. Sebbene queste tecniche abbiano diversi livelli di fragilità, non è ciò che viene discusso nel testo che hai citato.

Il secondo tipo di RNG che hai menzionato è un software RNG chiamato generatore di numeri pseudocasuali (PRNG * ). Questo è un algoritmo che prende un seed , che è come una chiave di crittografia, e lo espande in un flusso infinito di dati. Tenta di garantire che i dati non possano essere previsti o separati dalla pura casualità, senza la conoscenza del seme casuale segreto con cui l'algoritmo è iniziato. In questo caso, il PRNG è implementato in software puro, quindi per romperlo è sufficiente introdurre un bug nel codice, che è ciò di cui parla il testo che hai citato. È semplicemente codice che è fragile , rischiando il completo fallimento se vengono apportate modifiche al codice che deviano dal comportamento previsto dall'algoritmo.

Un PRNG può essere considerato come un algoritmo di crittografia proposto. In effetti, puoi creare un PRNG crittograficamente sicuro utilizzando un codice come AES per crittografare un contatore. Finché la chiave di crittografia (seed) è segreta, l'output non può essere previsto e il seed non può essere scoperto. Quando ci si pensa in questo modo, diventa più facile capire come un piccolo, insignificante cambiamento nel codice possa rompere completamente la sicurezza dell'algoritmo.

Raccolta della casualità

Quindi, in che modo i dispositivi moderni raccolgono effettivamente la casualità? Prendiamo un server in esecuzione silenziosamente in un datacenter da qualche parte. Per supportare cose come TLS, ha bisogno di una grande quantità di dati completamente imprevedibili che non possono essere distinti da un flusso veramente casuale. Senza una sorgente di rumore hardware dedicata, la casualità deve provenire dall'interno. I computer si sforzano di essere completamente deterministici, ma ricevono molti input da dispositivi non deterministici. Inserisci ... interrupt!

Nell'hardware moderno, un interrupt è un segnale emesso dall'hardware per avvisare la CPU di un cambiamento di stato. Consente alla CPU di evitare di eseguire rapidamente il polling di ogni dispositivo hardware per gli aggiornamenti e invece di fidarsi che il dispositivo lo avviserà in modo asincrono quando sarà il momento. Quando si verifica un interrupt, viene chiamato un gestore di interrupt per elaborare il segnale. Si scopre che questo gestore è il posto perfetto per ottenere casualità! Quando misuri la temporizzazione a livello di nanosecondi degli interrupt, puoi ottenere rapidamente un bel po 'di casualità. Questo perché gli interrupt vengono attivati ​​per ogni genere di cose, dai pacchetti in arrivo sulla scheda NIC ai dati letti da un disco rigido. Alcune di queste sorgenti di interrupt sono altamente non deterministiche, come un disco rigido che si basa sul movimento fisico di un attuatore.

Una volta che sufficienti bit casuali sono stati raccolti dal sistema operativo, un piccolo seme di almeno 128 bit possono essere inseriti in un PRNG crittograficamente sicuro per generare un flusso illimitato di dati pseudocasuali. A meno che qualcuno non sia in grado di prevedere esattamente quando si è verificato ogni interruzione passata, con una precisione al nanosecondo, non sarà in grado di derivare il seme e non sarà in grado di prevedere la futura produzione di PRNG. Questo rende l'output completamente adatto per le chiavi TLS.

* Un PRNG orientato alla sicurezza è chiamato PRNG crittograficamente sicuro o CSPRNG. L'utilizzo di un normale PRNG quando un'applicazione richiede un CSPRNG può causare vulnerabilità di sicurezza.

i diodi zenner non sono progettati specificamente per funzionare al contrario?
È diodo Zener, non zenner - prende il nome da [Clarence Zener] (https://en.wikipedia.org/wiki/Clarence_Zener).
@hytromo Non alla tensione di rottura per lunghi periodi.Hai bisogno di un diodo a valanga per gestirlo per un tempo molto lungo.Ho riformulato quella frase per essere più specifico (non mi ero reso conto di quanto suonasse sciocco!)
Penso che dovresti rimuovere la frase "non specificamente progettato per funzionare al contrario ad alte tensioni".I cosiddetti "diodi Zener" possono utilizzare effetti Zener o valanga o entrambi e, naturalmente, sono progettati per funzionare indefinitamente in caso di guasto inverso.Forse hai avuto l'idea perché le giunzioni E-B dei transistor vengono talvolta utilizzate nella ripartizione inversa e non sono progettate per essere utilizzate in questo modo.
Mi piace questa risposta, tranne per il fatto che non menziona nemmeno PRNG vs CSPRNG.Solo uno fa effettivamente un tentativo di essere _ imprevedibile_;l'altro cerca solo di farti ottenere un sacco di numeri che sembrano, a uno sguardo non istruito, non correlati.(Non in quest'ordine.) Questa è una distinzione importante da fare, specialmente su questo sito.L'utilizzo di un PRNG dove si intendeva utilizzare un CSPRNG può causare seri problemi e il contrario può perdere molte prestazioni (il che può anche causare problemi)
@NicHartley Ho aggiunto una nota a piè di pagina per spiegare la differenza.Grazie!
#2
+17
Harry Johnston
2018-07-29 07:15:35 UTC
view on stackexchange narkive permalink

Storicamente, gli RNG hardware adatti per la crittografia non erano comunemente disponibili su PC: ad esempio, secondo questa domanda AMD ha aggiunto il supporto solo pochi anni fa, quindi anche oggi un fornitore di software può " t semplicemente presumere che sarà disponibile. Questo è presumibilmente il motivo per cui OpenSSL (come discusso nella tua citazione) utilizzava un software RNG, rendendolo vulnerabile al bug trovato nel codice.

(Come ampiamente discusso nei commenti, un PC standard contiene una serie di "fonti di entropia" che un software RNG può utilizzare - e credo che OpenSSL lo faccia, anche se non sono molto familiare con esso - ma ovviamente in quello scenario un bug nel software può portare a numeri casuali errati, come in effetti è successo.)

Ci sono anche preoccupazioni che gli RNG hardware potrebbero essere stati backdoor , portando le persone a combinare RNG hardware con altre fonti di entropia piuttosto che utilizzarli così come sono. (L'hardware con backdoor è menzionato anche nel tuo articolo collegato, a pochi paragrafi dal bit che hai citato.)

Va ​​anche detto che gli RNG hardware non sono così semplici da implementare come la tua domanda suggerisce ... per prima cosa, le implementazioni ingenue potrebbero essere vulnerabili a vari attacchi fisici, ad esempio, se stai generando bit casuali basati su vibrazioni, cosa succede se qualcuno punta un'ecografia su di esso? Anche in condizioni ideali, è probabile che ci sia una sorta di bias nei risultati che potrebbe rendere i bit generati non sicuri per l'uso crittografico.

Ecco perché le implementazioni del mondo reale usano il rumore hardware ma anche lo elaborano crittograficamente. Ma a quel punto sei tornato alla domanda se l'algoritmo (o la sua implementazione) è stato deliberatamente sabotato, o forse semplicemente non è robusto come si credeva.

Un disclaimer: non sono un esperto qui.Se desideri ulteriori dettagli, potresti seguire il sito Stack Exchange Cryptography.
In realtà gli RNG hardware erano disponibili da molto tempo.Stai confondendo le istruzioni di casualità della CPU per un RNG hardware di qualsiasi tipo.Anche le console video di prima generazione utilizzavano quello che potrebbe essere chiamato un RNG hardware.
@forest, ma non erano standard nei PC.
@HarryJohnston: la maggior parte dei PC ha eccellenti fonti di casualità.Regola il guadagno analogico di una scheda audio al massimo e ottieni il rumore termico.Regola il guadagno analogico di una webcam al massimo e ottieni il rumore termico.Misura le variazioni nell'input dell'utente e ottieni rumore.Misura le fluttuazioni nella velocità di rotazione di un HDD dovute alla turbolenza e ottieni rumore.Misura le fluttuazioni di tensione sulla scheda madre e ottieni rumore.Ad esempio, potresti cercare su Google / bing per LavaRand.Quello che non avevi fino a poco tempo fa era un RNG hardware integrato nella CPU, con corrispondenti istruzioni standardizzate.
@JörgWMittag, la maggior parte dei sistemi non dispone di quell'hardware.Nessun server in un rack ha una scheda audio, una web cam o dispositivi di input utente e la maggior parte di quelli più recenti ha SSD invece di HDD.E non hanno dispositivi di misurazione ad alta precisione.Una soluzione deve essere applicata a tutti i tipi di macchine, non solo a un desktop o laptop tradizionale.
@JörgWMittag, l'OP non ha chiesto informazioni sulle "fonti di casualità".
@JohnDeters Bene, un'altra opzione ovvia per dove ottenere un po 'di casualità è misurare la tempistica dei pacchetti in arrivo sulle interfacce di rete.(Questo probabilmente funziona meglio su un server occupato che su un PC di casa.) I server hanno tipicamente alcuni sensori di temperatura;piccole variazioni possono fornire un po 'di casualità.Lo stesso con i sensori di tensione.Gli SSD potrebbero non subire variazioni indotte dalla turbolenza, ma la temporizzazione di I / O non è comunque completamente deterministica a livello di nanosecondi.Anche essere in grado di raccogliere solo un bit al secondo di buona casualità ti dà un solido seme casuale in due minuti.
@JohnDeters: Qualsiasi computer con almeno due cristalli di clock ha una vera fonte di entropia estremamente buona: il tasso di uno rispetto all'altro.I cristalli dell'orologio sono soggetti a una risposta in frequenza non lineare a piccoli cambiamenti di temperatura e altre condizioni ambientali, e queste risposte sono soggette a isteresi.(Corollario: non esiste un'emulazione perfetta per il ciclo di qualsiasi computer con più di una sorgente di clock)
Vorrei sottolineare che la mia risposta deliberatamente non discute la questione dell'ottenimento dell'entropia per i generatori di numeri casuali del software, perché non lo considero direttamente pertinente alla domanda originale.Il dibattito su questo punto può essere portato altrove?
-1
@R .. Corollario del corollario: non è necessaria l'emulazione del ciclo perfetto perché il computer stesso non era perfetto per il ciclo.
Un attacco ecografico è davvero fattibile rispetto ad altri attacchi noti?Nel corso degli anni sono state scoperte dozzine di vulnerabilità negli RNG e nessuna di alto profilo che ricordo richiedesse vicinanza fisica.
@CodyP, contro gli RNG del mondo reale?Spero di no, ma potrebbe funzionare contro un ingenuo RNG hardware del tipo richiesto dall'OP.(Ho scelto gli ultrasuoni in particolare perché l'OP ha suggerito di misurare le vibrazioni.) Se un RNG ingenuo conta il numero di volte in cui un rilevatore di vibrazioni si spegne in un periodo di N microsecondi, e ne genera uno se è maggiore di X o zero altrimenti - equindi il software mette letteralmente insieme quei bit per generare una chiave di crittografia, quindi presumibilmente un'ecografia potrebbe facilmente farli generare tutti.
... ma questo tipo di approccio non è mai stato un attacco di alto profilo, perché nessuno costruisce RNG che funzionino in questo modo.Non per uso crittografico, comunque.
#3
+12
paj28
2018-07-30 21:49:45 UTC
view on stackexchange narkive permalink

Perché sono difficili da testare

Sebbene sia facile verificare che un generatore di numeri casuali produca output con il formato corretto, determinare se è statisticamente casuale è molto più complicato e improbabile che venga incluso in una suite di test automatizzata. Un sacco di altro codice sarà molto più ovvio se lo si rompe.

Crypto deve essere corretto

In generale, assicurarsi che il codice sia corretto è difficile. Una grazia salvifica per molto codice è che solo una piccola percentuale di errori di correttezza provoca vulnerabilità di sicurezza. Ma con il codice crittografico, inclusi i generatori di numeri casuali, molti errori di correttezza si tradurranno in vulnerabilità. Il codice crittografico deve essere corretto, per essere sicuro e assicurarsi che sia corretto è difficile.

Il manutentore Debian ha commesso un grave errore

Il codice non lo è in realtà così fragile. Affinché fosse reso insicuro, sono stati necessari gravi errori da parte del manutentore. tagliare righe che producono avvisi con solo controlli superficiali che non sia rotto nulla, è piuttosto scadente.

Modifica: non era solo il colpa del manutentore, vedi il commento di Angel

Bene, il manutentore Debian [ha chiesto sulla mailing list di openssl] (https://marc.info/?t=114651088900003&r=1&w=2), notando che "il pool potrebbe ricevere meno entropia", e fondamentalmente gli è stato detto di "rimuoverli"
@ Ángel - Grazie per avermelo informato, sposta notevolmente la responsabilità.
#4
+4
supercat
2018-08-01 02:16:43 UTC
view on stackexchange narkive permalink

Uno degli aspetti più importanti di qualsiasi generatore casuale è che il valore di ogni bit casuale non solo deve essere completamente indipendente dai valori di tutti gli altri bit che genera, ma deve anche essere completamente indipendente da tutto il resto nell'universo un avversario potrebbe osservare o influenzare . Sfortunatamente, quella proprietà è spesso una delle più difficili da garantire. Il meglio che si può fare in genere è generare bit in un modo che è improbabile che abbia una relazione sfruttabile con qualsiasi altra cosa nell'universo.

A titolo di semplice esempio, se un avversario con un trasmettitore RF altamente focalizzato avesse una capacità di influenzare il tuo generatore di numeri casuali in modo che alcuni campioni di sua scelta abbiano una probabilità del 95% di produrne uno, mentre il resto avrebbe solo una probabilità del 5% di farlo. Se si dovessero semplicemente leggere 128 bit da un tale generatore e incorporarli in una chiave a 128 bit, un attaccante che ha concentrato un attacco di forza bruta su schemi di bit vicini a quello usato per influenzare il generatore avrebbe una probabilità molto maggiore di successo rapido che se il generatore fosse stato imparziale. Supponiamo, tuttavia, che invece di selezionare i bit uno alla volta, si selezionino gruppi di 7 bit e li xo insieme. Ciò aumenterebbe di sette volte il tempo per generare una chiave a 128 bit, ma l'influenza di un utente malintenzionato verrebbe ridotta da 95/5 a 74/26, riducendo notevolmente la probabilità che la chiave finisca per essere vicina al modello di bit dell'aggressore cercando di forzare.

In alternativa, si supponga di generare 128 bit casuali, di eseguirne l'hashing in qualche modo e quindi di xorarli con altri 128 bit casuali. Ciò richiederebbe solo la generazione di 256 bit anziché 896, ma renderebbe molto difficile per un attaccante sfruttare qualsiasi bias nel generatore. Anche se enumerare i pattern più probabili a 95.000.000.000 di bit a 128 bit avrebbe circa il 50% di possibilità di abbinare un gruppo di 128 bit utilizzato prima dell'hash, o quello con cui il valore di hash è stato xor'ed, la distribuzione finale dopo xor sarebbe improbabile che abbiano pregiudizi o fughe di informazioni sfruttabili .

#5
+1
Cody P
2018-08-02 04:51:26 UTC
view on stackexchange narkive permalink

Gli RNG sicuri comunemente usati come / dev / random di Linux, ChaCha20 o RdRand funzionano bene per molti casi convenzionali. Tuttavia, sono tutt'altro che a prova di idiota. Supponiamo che tu faccia qualcosa di divertente come non impostare il tuo orologio in tempo reale quando generi numeri casuali all'avvio. Se non capisci come questo influenzerà il tuo RNG, qualcuno che lo fa potrebbe andarsene con la tua chiave privata. C'è poco spazio per errori qui perché una piccola quantità di non casualità può compromettere un intero protocollo crittografico come la generazione di chiavi.

Sebbene i problemi con implementazioni personalizzate di generatori di numeri casuali o interferenze fisiche nel tuo hardware ingenui siano fonte di buone discussioni, la maggior parte delle vulnerabilità nelle notizie con generatori di numeri casuali, come il problema Debian che hai citato, non è dovuto a questi problemi. I problemi più grandi che ho riscontrato ripetutamente sono gli sviluppatori che pensano di avere una buona fonte di entropia per seminare il generatore di numeri casuali quando in realtà non lo fanno, consentendo erroneamente di scoprire e sfruttare lo stato del generatore casuale, o la mancanza di test rigorosi del generatore di numeri casuali stesso. L'NSA non ha bisogno di backdoor per la generazione delle chiavi se sei uno dello 0,75% dei client TLS che utilizza chiavi a bassa entropia. In sintesi, gli sviluppatori ignorano i pochi avvertimenti e presumono che il loro RNG funzionerà in qualsiasi applicazione.

Cos'è l'entropia e dove la trovo?

Poiché tutti i programmi per computer producono gli stessi output dati gli stessi input, devono essere letti da una fonte di entropia (o dati imprevedibili) nel sistema operativo o hardware. Oggigiorno abbiamo cose come il comando RdRand che può generare decine o centinaia di MB di entropia ogni secondo. Tuttavia, i dispositivi con generatori di numeri casuali hardware come Ferranti Mark 1 nel 1951 o Intel 82802 Firmware Hub nel 1999 rappresentavano l'eccezione piuttosto che la regola fino al 2010.

Quindi, i generatori di numeri storicamente casuali si basano su fonti di entropia relativamente lente come l'input umano o i tempi del computer, ei sistemi legacy potrebbero non avere quasi nessuna funzione incorporata con buone fonti di entropia disponibili. / Dev / random di Linux, ad esempio, può utilizzare l'ora di avvio, la temporizzazione dei dispositivi di input umani, le temporizzazioni del disco, le temporizzazioni IRQ e persino la modifica del pool di entropia da parte di altri thread

In molti modi generatori di numeri casuali sono fragili perché questi metodi standard per ottenere l'entropia non sono infallibili. Tutto ciò che rende queste fonti di entropia prevedibili o limitate comprometterà il tuo RNG, ad esempio:

  • Il bug Debian che hai notato utilizzava solo l'ID del processo per l'entropia.
  • Se si utilizza un sistema operativo headless e preconfigurato che genera chiavi all'avvio, molte delle fonti di entropia di Linux potrebbero essere prevedibili. fonte
  • Java Cryptography Architecture di Android è risultato richiedere un'inizializzazione esplicita da una buona fonte di entropia su alcuni dispositivi.
  • La generazione di numeri casuali troppo rapidamente in Linux esaurirà il pool di entropia più velocemente di quanto possa essere reintegrato, portando a numeri meno casuali.

Capire lo stato e la mancanza di reseeding

Spesso gli RNG non ottengono nuova entropia con ogni chiamata di funzione come fa / dev / random. A volte non puoi ottenere abbastanza entropia abbastanza velocemente, o non ti fidi completamente della fonte di entropia. Quindi, invece, l'RNG viene seminato con una fonte nota di entropia, quindi produce valori indipendenti da quel seme. Tuttavia, quando qualcuno capisce lo stato interno del generatore le cose vanno male, portando a tutto, dalla clonazione delle smart card al imbroglio di una slot machine a Las Vegas.

Un attacco di overflow del buffer o un attacco simile può rivelare lo stato del generatore di numeri casuali. L'apprendimento dello stato può anche essere possibile con un attacco di forza bruta, soprattutto se l'algoritmo è noto ed è reversibile, può essere calcolato rapidamente o è noto un testo in chiaro. Questo era il caso dei problemi con Windows XP, libreria SSH Dropbear, XorShift128 + in Chrome e algoritmo di messerne twister, tra molti altri.

La richiesta di mitigazione avanzata per questi attacchi a stati noti rende fragile l'RNG. Il modo migliore per mitigare gli attacchi a stati noti è non utilizzare un algoritmo vulnerabile (come la maggior parte dei CSRNG). Questa domanda spiega anche in modo più dettagliato esattamente cosa rende sicuro un buon RNG. Tuttavia, anche i CSRNG a volte hanno anche dei punti deboli (per esempio, la vulnerabilità RNG nel kernel Linux 2.6.10). Quindi la difesa in profondità richiede attenuazioni come l'utilizzo di stati separati per generatori di numeri casuali (forse uno per utente), l'aggiornamento frequente del seed e attraverso protezioni da attacchi di canale laterale e buffer overflow.

Passare la colpa tra sviluppatori e utenti

Spesso questi RNG sono fragili a causa della comunicazione errata delle limitazioni tra sviluppatori di librerie o creatori di sistemi operativi che non possono progettare un sistema infallibile e utenti che si aspettano uno. Linux, ad esempio, costringe gli utenti a scegliere tra alta latenza / dev / random e potenzialmente bassa entropia / dev / urandom. Come altro esempio, PHP prima della 5.3 non supportava i PRNG potenti in Windows tramite interfacce come mcrypt_create_iv () e prima della 7.0 non aveva un buon CSPRNG integrato.

Difficoltà nel rilevamento

C'è un punto di discussione popolare quando si discute di numeri casuali che, per un numero veramente casuale, ogni possibilità è ugualmente probabile e ci sono un numero infinito di schemi potenziali. Allora come puoi veramente guardare una sequenza e dire che non è casuale? (pertinente Dilbert)

In realtà, la rilevazione di pattern in numeri casuali è un campo maturo, sebbene imperfetto, e la questione se possa essere rilevata la non casualità è stata affrontata da quando M.G. L'articolo del 1938 di Kendall e B. Babington-Smith. puoi dimostrare che non è molto più probabile che appaiano tipi specifici di modelli rispetto al caso casuale. Ad esempio, posso verificare se la cifra 1 è più comune di altre cifre, con soglie determinate da un test del chi quadrato. Finché questi modelli testati sono almeno remotamente probabili e controlli un insieme sufficientemente lungo di numeri generati, le probabilità di un falso positivo sono basse. Sebbene alcuni problemi nascosti con alcuni generatori di numeri casuali possano passare inosservati per anni, se hai eseguito una crittoanalisi di base e poi applicato test di livello industriale come spiegato in questa domanda, allora non si può sbagliare.

Tuttavia, i progettisti potrebbero anche sottovalutare i loro aggressori (come si poteva prevedere che le persone effettuerebbero il reverse engineering e il tempo della tua slot machine?). Peggio ancora, a volte il generatore di numeri casuali o la generazione di entropia non vengono mai ispezionati da un esperto e viene esaminato solo il risultato dell'utilizzo dell'RNG, come quando le firme del firmware PS3 erano firmate con un output "casuale" costante.

Alla fine della giornata, il problema qui è simile a quello in gran parte della sicurezza informatica: hai un insieme molto complesso di protocolli, requisiti e dispositivi per numeri casuali. Come sempre, se non capisci la complessità, sei vulnerabile a un aggressore che lo fa.

Perché l'impostazione dell'RTC non influisce in alcun modo sulla casualità?
@forest RTC viene utilizzato per il pool di entropia di Linux, quindi se l'RNG viene utilizzato in un momento prevedibile (ad esempio, la generazione di chiavi all'avvio) può portare a chiavi più prevedibili.Modificherò la mia risposta per chiarire.Vedere questo documento per ulteriori informazioni: https://factorable.net/weakkeys12.extended.pdf
Questo non è l'RTC, è il TSC (contatore del ciclo di riferimento tramite l'istruzione RDTSC, sebbene alcuni sistemi MIPS32 utilizzino un contatore diverso, credo).L'RTC ha solo un secondo di granularità e una latenza significativa e _molti sistemi_ non ne hanno uno, ma non ha alcun effetto sul driver di casualità.E non puoi disabilitare il TSC nel kernel senza patchare intenzionalmente per impostare forzatamente CR4.TSD, anche se penso che potrebbe non avere comunque alcun effetto sul codice dell'anello 0.C'è davvero molto poco che puoi fare in Kconfig per compromettere in modo significativo la raccolta di entropia.Anche uccidere HPET è innocuo.
Quello che voglio dire è che probabilmente intendi il contatore del timestamp (TSC), non l'orologio in tempo reale (RTC).
Ricaricando l'articolo sembra che si riferisca all'inizializzazione del pool di entropia, che influenza le chiavi generate con / dev / urandom al primo avvio, prima che il pool di entropia si sia "riempito".Questa inizializzazione del pool viene eseguita con il tempo di avvio.Forse cambiarlo in "come generare chiavi entro un minuto dal primo avvio" sarebbe più chiaro e meno ambiguo.


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...