Dove entra in contatto un ospite Hyper-V durante la generazione di una coppia di chiavi dell'autorità di certificazione?

Question

Dove entra in contatto un ospite Hyper-V durante la generazione di una coppia di chiavi dell'autorità di certificazione?

#1 da (2 voti)

10

Secondo i risultati dell'osservatorio SSL del FEP , ci sono "decine di migliaia di chiavi che offrono in modo efficace nessuna sicurezza dovuta al debole algoritmo di generazione di numeri casuali. " La mia comprensione di questo problema è questa: durante la generazione dei grandi fattori primi utilizzati dall'algoritmo RSA, un numero significativo di dispositivi ha finito per scegliere gli stessi fattori primi. Presumibilmente ciò è avvenuto perché l'entropia insufficiente è stata utilizzata dai dispositivi per selezionare i fattori primi.

Quando installi Servizi certificati Active Directory, ti viene presentata la seguente schermata:

Ostensibilmente,ilcompletamentodell'installazionecausalagenerazionedeifattoriprimichecomprendonolacoppiadichiavi.

Hosentitospessolaraccomandazione( qui è una ) per creare l'autorità di certificazione radice come macchina virtuale per facilitare l'assunzione è offline e lo protegge fisicamente. In un ambiente Windows, sembra naturale ospitare la CA principale utilizzando Hyper-V.

Questo solleva quindi le seguenti domande:

Dove viene immessa l'entropia di un'istanza ospitata da HyperV in Windows Server durante la generazione dei fattori principali durante l'installazione di Servizi certificati di Active Directory?
In che modo "buono" è la fonte di entropia?

windows virtualization certificate-authority entropy

posta alx9r 14.02.2014 - 18:38

fonte

1 risposta

Leggi altre domande sui tag windows virtualization certificate-authority entropy

Come rendere Firefox ignora l'intestazione di risposta X-XSS-Protection? La tabella arcobaleno non richiede decompressione?

score 2 · Answer 1

Un guest Hyper-V ottiene la sua entropia proprio come farebbe se non fosse un ospite. Per Windows, un'applicazione che utilizza i provider di servizi di crittografia di Microsoft ottiene la sua entropia da tre / quattro fonti principali:

Eventi esterni come attività di rete.
Dettagli sui chiamanti alle funzioni CSP (ID processo, ID thread, vari timer associati a tali thread e processi, ecc.).
Qualsiasi entropia che lo sviluppatore dell'applicazione vorrebbe fornire (tempistiche per la pressione di tasti, movimenti del mouse, ecc.).
Qualsiasi dispositivo entropico hardware supportato, come RdRand nei processori Intel.

Tutti e quattro i suddetti sono disponibili per un ospite come lo sarebbero se fosse un server fisico.

Come descritto in msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx:

With Microsoft CSPs, CryptGenRandom uses the same random number generator used by other security components. This allows numerous processes to contribute to a system-wide seed. CryptoAPI stores an intermediate random seed with every user. To form the seed for the random number generator, a calling application supplies bits it might have—for instance, mouse or keyboard timing input—that are then combined with both the stored seed and various system data and user data such as the process ID and thread ID, the system clock, the system time, the system counter, memory status, free disk clusters, the hashed user environment block. This result is used to seed the pseudorandom number generator (PRNG). In Windows Vista with Service Pack 1 (SP1) and later, an implementation of the AES counter-mode based PRNG specified in NIST Special Publication 800-90 is used. In Windows Vista, Windows Storage Server 2003, and Windows XP, the PRNG specified in Federal Information Processing Standard (FIPS) 186-2 is used. If an application has access to a good random source, it can fill the pbBuffer buffer with some random data before calling CryptGenRandom. The CSP then uses this data to further randomize its internal seed. It is acceptable to omit the step of initializing the pbBuffer buffer before calling CryptGenRandom.