Come puoi generare in modo sicuro le chiavi su AWS?

Questo mantra "bassa entropia" è un vero disastro. Vedi questa risposta per i dettagli. Il sommario esecutivo è: alcuni software, in particolare /dev/random , possono riportare una "bassa entropia" e un blocco per ragioni che non hanno alcun senso pratico. L'idea che l'entropia sia "esaurita" deriva da un modello matematico che ha solo legami tenui con la realtà e può (teoricamente) fornire alcun guadagno di sicurezza solo quando la casualità viene utilizzata per gli algoritmi di "informazione teoricamente sicura". Algoritmi usuali come RSA o AES non sono di queste classi.

Quindi quello che devi fare è il seguente:

• OpenSSL normalmente dovrebbe usare /dev/urandom , evitando il problema. Se il problema si verifica, si manifesterà come un comportamento di "blocco" (la generazione della chiave richiede una quantità di tempo anormale, senza CPU utilizzata).
• Se si verifica il problema, "ricarica" /dev/random con nuova pseudo-casualità, che è abbastanza buono . Qualcosa come: dd if=/dev/urandom of=/dev/random bs=1024 count=64

Tuttavia, c'è un altro problema che non è così facile da gestire. I sistemi cloud sono macchine virtuali, che possono essere eseguite in concomitanza con altre macchine virtuali sullo stesso hardware. Quando due thread di esecuzione vengono eseguiti su due core della stessa CPU, anche se si riferiscono a macchine virtuali distinte, condividono la cache di livello 1 e potrebbero potenzialmente spiare l'uno sull'altro. La tecnica prevede l'esecuzione di accessi alla memoria in un array che utilizza le stesse linee cache del codice di destinazione e ricostruisce i segreti obiettivo notando quando alcuni elementi dell'array sono stati sfrattati dalla cache.

I prototipi di lavoro sono stati dimostrati in condizioni di laboratorio. Se possono essere applicati in una configurazione pratica dipende da molti parametri ed è attualmente sconosciuto. Tuttavia, è plausibile . La conclusione è che se fai qualcosa di serio con le chiavi, allora dovresti sforzarti di eseguire il tuo hardware, o almeno ottenere qualche garanzia dal provider di cloud che le tue macchine virtuali non condivideranno lo stesso hardware server come macchine virtuali di altri clienti.

Thread precedente, ma la buona domanda e le poche risposte qui non sono sempre specifiche per le macchine AWS o anche per le macchine virtuali cloud, come menzionato nella domanda, quindi suggerirò di dare un'occhiata a una raccomandazione del Lemur squadra, che si applica a scenari più ampi: "La quantità di sforzi che desideri spendere per garantire che Lemur ha una buona entropia da cui attingere dipende dalla tua specifica tolleranza al rischio e da come è configurato Lemure. Se desideri generare più entropia per il tuo sistema ti suggeriamo di dare un'occhiata alle seguenti risorse: "e procedono a raccomandare < a href="https://www.digitalocean.com/community/tutorials/how-to-setup-additional-entropy-for-cloud-servers-using-haveged"> haveged .

Per chi è interessato a leggere di più sui problemi con bassa entropia, il seguente documento, Un'analisi del generatore di numeri casuali di OpenSSL , e riferimenti, vale la pena leggere.

The ability to generate high entropy random numbers is crucial to the generation of secret keys, initialization vectors, and other values that the security of cryptographic operations depends on.

Questo articolo, Miglioramento di semi casuali in Ubuntu 14.04 LTS Cloud Le istanze , sugli sforzi di Ubuntu per migliorare l'entropia nel cloud, descrivono i problemi e le possibili soluzioni ( pollen ) in modo molto più dettagliato:

Q: So my OS generates an initial seed at first boot? A: Yep, but computers are predictable, especially VMs. Computers are inherently deterministic And thus, bad at generating randomness Real hardware can provide quality entropy But virtual machines are basically clones of one another

La soluzione Ubuntu potrebbe non soddisfare i requisiti dell'OP in quanto è una soluzione "entropy-as-a-service", tuttavia (secondo lo sviluppatore) è "veloce, efficiente e scalabile".

Per passare dalla teoria alla pratica, controlla Prangster se sei interessato a valutare quanto è buono il tuo PRNG:

Now our goal is to determine the seed that produced a given sample of pseudorandom output, and in doing so, conclude with certainty the use of an insecure PRNG and prepare to attack the application that uses it. This is the primary function of the Prangster tool; all it needs is the output and the right PRNG and alphabet

.

Ci sono molti pregiudizi e miti su /dev/random o /dev/urandom . In generale non è vero che usare /dev/urandom sia sempre abbastanza buono e che /dev/random sia solo per paranoico.

La chiave qui è la quantità totale di entropia raccolta durante la vita dell'istanza prima di iniziare a generare numeri. Questo è ciò che conta di più. Dopo l'istanza di spawn (da AMI) il generatore casuale deve accumulare abbastanza entropia per iniziare a produrre numeri indeterminabili.

Una volta che c'è abbastanza entropia, puoi generare praticamente una "qualsiasi" quantità di dati che è cripto-strong da /dev/urandom . Tuttavia, se l'entropia raccolta non è sufficiente, non c'è altra soluzione che prenderla prima.

Quella /dev/random riduce il contatore di entropia è un po 'paranoica. È un must-have di un buon generatore rnd che non puoi indovinare il prossimo numero generato anche se pubblicizzi qualsiasi quantità di numeri precedentemente generati . Per ottenere ciò, i generatori usano fedelmente gli stessi costrutti che si trovano negli algoritmi di crittografia (AES, SHA, ecc.). Pertanto, se non credi nel tuo generatore rnd non puoi credere nella crittografia in quanto tale.