¿Dónde obtiene un entropía un huésped de Hyper-V cuando genera un par de claves de autoridad de certificación?

10

De acuerdo con los hallazgos del observatorio de SSL de la EFF , hay "decenas de miles de claves que no ofrecen ninguna garantía. a débil algoritmo de generación de números aleatorios ". Mi comprensión de ese problema es la siguiente: durante la generación de los grandes factores primos utilizados por el algoritmo RSA, un número significativo de dispositivos terminó eligiendo los mismos factores primos. Presumiblemente, esto ocurrió porque los dispositivos no utilizaron la entropía suficiente para seleccionar los factores primos.

Cuando instala los Servicios de certificados de Active Directory, aparece la siguiente pantalla:

Aparentemente,alcompletarlainstalaciónsegeneranlosfactoresprimosqueformanelpardeclaves.

Amenudoheescuchadolarecomendación( aquí hay una ) para crear su autoridad de certificado raíz como una máquina virtual para facilitar la toma. Desconectado y asegurándolo físicamente. En un entorno de Windows, parece natural alojar su CA raíz utilizando Hyper-V.

Esto plantea las siguientes preguntas:

  1. ¿Dónde obtiene una entropía una instancia de Windows Server alojada en HyperV cuando genera los factores principales durante la instalación de AD Certificate Services?

  2. ¿Qué tan 'buena' es la fuente de entropía?

pregunta alx9r 14.02.2014 - 18:38
fuente

1 respuesta

2

Un invitado Hyper-V obtiene su entropía como si no fuera un invitado. Para Windows, una aplicación que utiliza los proveedores de servicios criptográficos de Microsoft obtiene su entropía de tres / cuatro fuentes principales:

  1. Eventos externos como la actividad de la red.
  2. Detalles sobre las personas que llaman a las funciones de CSP (ID de proceso, ID de hilo, varios temporizadores asociados con esos hilos y procesos, etc.).
  3. Cualquier entropía que el desarrollador de la aplicación desee proporcionar (tiempos de pulsación de teclas, movimiento del mouse, etc.).
  4. Cualquier dispositivo de entropía de hardware compatible, como RdRand en procesadores Intel.

Los cuatro anteriores están tan disponibles para un invitado como lo serían si fuera un servidor físico.

Como se describe en msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx:

  

Con los CSP de Microsoft, CryptGenRandom utiliza el mismo generador de números aleatorios que utilizan otros componentes de seguridad. Esto permite que numerosos procesos contribuyan a una semilla de todo el sistema. CryptoAPI almacena una semilla aleatoria intermedia con cada usuario. Para formar la semilla para el generador de números aleatorios, una aplicación de llamada suministra bits que pueden tener, por ejemplo, entrada de temporización del mouse o teclado, que luego se combinan con la semilla almacenada y varios datos del sistema y datos del usuario, como la identificación del proceso y ID de hilo, el reloj del sistema, la hora del sistema, el contador del sistema, el estado de la memoria, los grupos de discos libres, el bloque de entorno de usuario hash. Este resultado se utiliza para inicializar el generador de números pseudoaleatorios (PRNG). En Windows Vista con Service Pack 1 (SP1) y posterior, se usa una implementación del PRNG basado en modo contador AES especificado en la Publicación Especial 800-90 de NIST. En Windows Vista, Windows Storage Server 2003 y Windows XP, se usa el PRNG especificado en el Estándar de procesamiento de información federal (FIPS) 186-2. Si una aplicación tiene acceso a una buena fuente aleatoria, puede llenar el búfer pbBuffer con algunos datos aleatorios antes de llamar a CryptGenRandom. El CSP luego usa estos datos para aleatorizar aún más su semilla interna. Es aceptable omitir el paso de inicializar el búfer pbBuffer antes de llamar a CryptGenRandom.

    
respondido por el longneck 10.03.2014 - 19:55
fuente

Lea otras preguntas en las etiquetas