Los administradores de seguridad y los auditores que implementan controles basados en normativas NIST suelen preguntarse si el identificador de sesión que asigna Windows Server (el Locally Unique Identifier o LUID) ofrece un nivel de aleatoriedad certificado. En este artículo examinamos cómo se construye el LUID, qué papel juegan sus 32 bits finales y por qué, a falta de documentación oficial de Microsoft, no puede considerarse conforme a NIST SP 800‑90A.

Definición y propósito del LUID

Un LUID es un valor de 64 bits que Windows genera cada vez que se crea un token de inicio de sesión interactivo, por lotes, por red o por servicio. Su misión principal es permitir que el sistema operativo distinga de manera inequívoca una sesión de otra sin necesidad de un repositorio centralizado. Esa unicidad facilita—entre otras cosas—la auditoría de eventos, la enumeración de sesiones a través de API como WTSQuerySessionInformation y la creación de SID de logon (S-1-5-5-X-Y). A diferencia de un GUID o de un nonce criptográfico, el LUID jamás abandona el sistema y rara vez se expone en protocolos de red.

Estructura interna: lo que se sabe

Microsoft no ha publicado el algoritmo ni la semántica exacta de cada bit dentro del LUID. Sin embargo, mediante ingeniería inversa y análisis de debug symbols se han observado patrones constantes:

• Los 32 bits superiores (Luid.HighPart) suelen permanecer en 0x00000000 en versiones modernas del kernel.
• Los 32 bits inferiores (Luid.LowPart) se incrementan de forma monotónica global conforme se crean sesiones.
• Cuando la cuenta supera el margen de seguridad (normalmente tras reinicios muy prolongados o cargas de trabajo con millones de sesiones), el sistema vuelve a cero sin colisiones, ya que los valores antiguos han caducado.

Este diseño demuestra que el foco está en garantizar unicidad temporal, no en proporcionar entropía criptográfica.

Aleatoriedad frente a unicidad

La Confianza de los controles NIST SP 800‑90A recae en que los bits de salida de un Deterministic Random Bit Generator (DRBG) validado sean indistinguibles de ruido uniforme. Dicho requisito nace de usos en criptografía simétrica (claves, IV, nonce, etc.). Un identificador local cuyo único fin es evitar colisiones no necesita aleatoriedad perfecta; basta con que su órbita (el espacio de valores posibles) no se recicle dentro de la ventana de vida de una máquina. De ahí que el LUID:

• No combine factores de hardware, reloj o ruido térmico.
• No apunte a pools de entropía como CNG o BCrypt.
• Se genere en modo kernel antes de que los servicios de criptografía estén completamente inicializados.

NIST SP 800‑90A en pocas palabras

La publicación NIST SP 800‑90A—hoy en versión Rev.1—define tres familias de DRBG:

1. Hash_DRBG, basado en SHA‑2.
2. HMAC_DRBG, basado en HMAC‑SHA‑2.
3. CTR_DRBG, basado en AES‑CTR.

Un módulo que reclame conformidad debe:

1. Pasar las validaciones de algoritmo (Algorithm Validation Tests) del NIST.
2. Aparecer en el certificado FIPS 140‑2/3 del proveedor.
3. Cumplir con requisitos de inicialización, resembrado y protección contra prediction resistance.

La ausencia de cualquiera de estos puntos implica que el RNG no está formalmente cubierto por la guía.

¿Incluye Windows Server un DRBG validado para el LUID?

En los certificados FIPS de Microsoft, los subsistemas evaluados son típicamente:

• bcryptprimitives.dll (CNG PRNG y primitivas AES, SHA, RSA, ECC).
• ncryptsslp.dll (TLS Provider).
• Componentes de BitLocker y TLS de Schannel.

Hasta la fecha de este artículo (julio 2025) ningún certificado FIPS menciona un módulo para “LUID Generation” o similar. Tampoco existe evidencia pública de que SeSinglePrivilegeCheck, SepCreateToken o funciones derivadas llamen a las API de CNG cuando crean el LUID. En pruebas de laboratorio se ha confirmado que los 32 bits altos permanecen estáticos tras reiniciar máquinas limpias, lo cual sería incompatible con la entropía garantizada por un DRBG.

Análisis de los 32 bits finales

Diversos investigadores han capturado millones de LUID en máquinas de prueba bajo cargas de autenticación automáticas. Los resultados apuntan a:

• Distribución uniforme: La parte baja se incrementa secuencialmente, por lo que cada valor es único dentro de la vida del host.
• Ausencia de ciclo corto: A una velocidad hipotética de 100 LUID/seg, harían falta más de 13 meses de uptime para recorrer los 4.294.967.296 valores disponibles.
• No se aprecia ruido: No se observa ningún bit que cambie de forma no determinista entre saltos consecutivos.

Estos hallazgos avalan la tesis de que Windows confía en un contador global protegido por spinlock o variable atómica, en lugar de un RNG criptográfico.

Implicaciones de seguridad

Que el LUID carezca de entropía robusta rara vez representa un problema operativo porque:

• No se intercambia por la red—se consulta mediante llamadas locales.
• No sirve como clave ni semilla de cifrado.
• Los privilegios se autorizan por SID y privilegios del token, no por LUID.

Los riesgos surgen cuando terceras aplicaciones confunden al LUID con un token impredecible y lo reutilizan en protocolos, nombres de archivo, correos de restablecimiento o cualquier contexto donde un atacante pueda adivinarlo. En ese escenario, un actor podría intentar enumerar sesiones o suplantar referencias si queda un canal expuesto.

Recomendaciones para cumplir NIST

Escenario	¿Aceptar LUID?	Alternativa recomendada
Registros de auditoría locales	Sí	No necesaria
Identificadores de correlación entre sistemas	No	GUID aleatorio (CoCreateGuid o UuidCreate)
Semillas criptográficas	No	BCryptGenRandom (modo FIPS)
Tokens de restablecimiento	No	CNG PRNG validado

Cómo obtener aleatoriedad certificada en Windows Server

Para generar datos realmente aleatorios bajo los requisitos de NIST SP 800‑90A:

1. Active el modo FIPS (System Cryptography – Use FIPS compliant algorithms) en la directiva de seguridad local si su política lo exige.
2. Llame a BCryptGenRandom con el flag BCRYPTUSESYSTEMPREFERREDRNG. Este PRNG está validado bajo FIPS 140‑2/3 y usa implementation certificates asociados a AES‑CTR_DRBG.
3. Para aplicaciones .NET, inicialice RandomNumberGenerator.Create(), que se enlaza a CNG bajo el capó.
4. Mantenga el sistema actualizado: los parches de seguridad de Windows incluyen mejoras en gestión de entropía y correcciones en el motor CNG.

Buenas prácticas de desarrollo y auditoría

• Documente los orígenes de entropía usados en cada módulo y el mapeo a requisitos NIST.
• Evite exponer identificadores internos (SID, LUID, PID) fuera del límite de confianza.
• Incluya pruebas de entropía (por ejemplo, SP 800‑90B Entropy Assessment) cuando diseñe servicios que dependan de RNG.
• En auditorías, solicite los certificados CMVP del proveedor de software; verifique que la versión del sistema operativo coincida con la listada.
• Aplique defense‑in‑depth: aunque un RNG falle, las credenciales se deben validar con firma o cifrado autenticado.

Preguntas frecuentes

¿Puedo pedir a Microsoft detalles del algoritmo del LUID?

Sí. Los contratos empresariales Premier Support y Unified Support permiten abrir consultas de “nivel 3” donde el equipo de producto puede compartir documentación bajo NDA. No obstante, históricamente Microsoft no ha publicado código ni diagramas de flujo para el generador de LUID.

¿Existe riesgo de colisión de LUID entre reinicios?

Mínimo. El contador se reinicia a cero, pero los LUID de la instancia previa ya no son válidos porque los tokens no sobreviven al apagado.

¿Debo activar FIPS mode en el servidor?

Sólo si una auditoría lo exige. Activar FIPS deshabilita algoritmos considerados “no aprobados”, lo que puede romper compatibilidad con software antiguo (por ejemplo, SSL 3.0 o firmas MD5).

¿Cómo verifico que BCryptGenRandom usa un DRBG certificado?

Ejecute certutil -v -store "Trusted People" o revise los certificados FIPS de Microsoft; busque el identificador de implementación del módulo CNG correspondiente a su versión de Windows.

Conclusión

Los 32 bits finales del LUID en Windows Server 2016/2019 ofrecen unicidad fiable, pero no provienen de un DRBG validado conforme a NIST SP 800‑90A. Si su caso de uso exige estricta conformidad, genere identificadores con las API criptográficas de CNG o bibliotecas equivalentes certificadas. El LUID debe verse como una marca interna de sesión, no como un número aleatorio con garantías criptográficas.