Entropia su macchine virtuali

Come forse saprai, non è facile generare entropia su una macchina virtuale come su un PC "normale". La generazione di una chiave gpg su una macchina virtuale può richiedere del tempo, anche con gli strumenti corretti.

Esistono molte più funzioni di crittografia là fuori che non sono così consapevoli dell'entropia come lo è gpg.

Quindi si può dire che la crittografia è meno sicura su una macchina virtuale?

Prima di tutto, lasciami dire che non sono affatto un esperto di sicurezza.

Poiché la creazione della chiave gpg sta usando /dev/randomcome generatore di numeri casuali, è sicura su una macchina virtuale, come su una macchina reale.
/dev/randomè un dispositivo di blocco e smetterà di fornire qualsiasi casualità oltre la quantità disponibile. Puoi controllare la casualità disponibile entro
cat /proc/sys/kernel/random/entropy_avail(dovrebbe essere intorno al 2000 )

Su una macchina virtuale la casualità disponibile è effettivamente inferiore rispetto a una macchina reale, a causa della mancanza di accesso all'hardware.
È possibile aumentare l'entropia applicando, ad esempio, le chiavi di entropia e / o passando a una macchina non virtualizzata.

C'è un bell'articolo disponibile sull'entropia nelle macchine virtuali. Purtroppo entrambe le parti dell'articolo sono disponibili solo nella cache di Google in questo momento.

L'entropia ha ulteriori effetti sulla crittografia ssl / tls. Pertanto, l'utilizzo /dev/urandomo qualsiasi altra fonte non casuale ha effettivamente un impatto sulla sicurezza delle tue applicazioni.

In termini di affidabilità /dev/urandomrispetto alla vera casualità;
non sono in grado di darti una risposta decente, scusa.

Per ulteriori informazioni su questo argomento, visitare il sito Web http://security.stackexchange.com e / o leggere ad es. questo post

Sì, nella maggior parte dei casi la crittografia è meno sicura su una macchina virtuale che su un server "reale".

Quest'ultimo può almeno raccogliere entropia da qualche hardware reale. In effetti, il funzionamento di un pezzo di HW è - nella maggior parte dei casi - legato a qualche fenomeno fisico, che è sempre soggetto a piccole variazioni, casuali da tutti i conti. Poiché i server in genere funzionano per un tempo molto lungo senza un ripristino, il pool di entropia risultante alla fine sarà di qualità sufficiente.

Le macchine virtuali soffrono di tre problemi.

1. L'hardware che vedono non è reale e quindi non è influenzato da alcun fenomeno fisico. Saranno in grado di raccogliere l'entropia in un modo molto più lento.
2. Le macchine virtuali vengono ripristinate molto più spesso dei server reali e potrebbero non avere nemmeno il tempo di raccogliere abbastanza entropia (motivo per cui è utile salvare lo stato di entropia corrente al momento dello spegnimento e utilizzarlo per alimentare il pool di entropia al riavvio).
3. Mentre un vero server potrebbe avere qualche possibilità di determinare quando si sta occupando un pool di entropia difettoso, la macchina virtuale funzionerà più facilmente con l'impressione che il pool di entropia sia buono (perché è stato raccolto da HW, ma senza sapere che l'HW è non reale), mentre in realtà è male.

La soluzione migliore è avere la VM che si arrende e si rende conto che l'HW che vede è una cattiva fonte di entropia. Quindi, organizzare un servizio di rete locale per la distribuzione di entropia di alta qualità (consultare Entropy Broker ). Il "server entropia" può estrarre casualità da HW generico (nel qual caso deve funzionare per un tempo sufficiente e deve avere un sistema operativo decente) o da HW crittografico specifico (un chip TPM, un chip VIA Padlock, ecc.).

Una VM che utilizza tale servizio può persino essere più sicura (dal punto di vista crittografico) di un server "reale" che si è appena avviato.