Recomendaciones criptográficas del ciclo de vida de desarrollo de seguridad de Microsoft
Introducción
El documento contiene recomendaciones y procedimientos recomendados para usar el cifrado en plataformas de Microsoft. Gran parte del contenido de este documento se encuentra en los propios estándares de seguridad internos de Microsoft que se usan para crear el ciclo de vida de desarrollo de seguridad. Está concebido para usarse como referencia al diseñar productos a fin de usar las mismas API, algoritmos, protocolos y longitudes de claves que Microsoft requiere en sus propios productos y servicios.
Los desarrolladores de plataformas que no son de Windows también pueden aprovechar estas recomendaciones. Aunque los nombres de las API y de las bibliotecas pueden ser diferentes, los procedimientos recomendados relacionados con la elección de algoritmos, la longitud de claves y la protección de datos son similares entre las diversas plataformas.
Recomendaciones de protocolo de seguridad, algoritmo y longitud de claves
Versiones de SSL/TLS
Los productos y servicios deben usar versiones criptográficamente seguras de SSL/TLS:
TLS 1.2 debe estar habilitado.
TLS 1.1 y TLS 1.0 deben estar habilitados solo para compatibilidad con versiones anteriores.
SSL 3 y SSL 2 deben estar habilitados de forma predeterminada.
Cifrados de bloques, modos de cifrado y vectores de inicialización simétricos
Cifrados de bloques
Para los productos con cifrados de bloques simétricos:
Se recomienda el estándar de cifrado avanzado (AES) para el nuevo código.
El estándar de cifrado de datos triple (3DES) con tres claves está permitido en el código existente para proporcionar la compatibilidad con versiones anteriores.
Todos los demás cifrados de bloques, como RC2, DES, 3DES de dos claves, DESX y Skipjack, solo deben usarse para descifrar datos antiguos y deben reemplazarse si se usan para el cifrado.
Para los algoritmos de cifrado de bloques simétrico, se recomienda una longitud de clave mínima de 128 bits. El único algoritmo de cifrado de bloques recomendado para código nuevo es AES (AES-128, AES-192 y AES-256 son aceptables, si bien AES-192 carece de optimización en algunos procesadores). El algoritmo 3DES de tres claves se acepta actualmente si ya está en uso en el código existente; se recomienda la transición al algoritmo AES. DES, DESX, RC2 y Skipjack ya no se consideran seguros. Estos algoritmos solo deben utilizarse para descifrar datos existentes por motivos de compatibilidad con versiones anteriores, y los datos se deben volver a cifrar mediante uno de los cifrados de bloques recomendados.
Modos de cifrado
Los algoritmos simétricos pueden funcionar en diversos modos, la mayoría de los cuales vinculan las operaciones de cifrado en bloques sucesivos de texto no cifrado y texto cifrado.
Los cifrados de bloques simétricos deben usarse con uno de los siguientes modos de cifrado:
Robo de texto cifrado (CTS)
Libro de códigos modificado basado en XEX con modo de robo de texto cifrado (XTS)
Algunos otros modos de cifrado, como los que se incluyen a continuación, presentan dificultades de implementación que hacen que sea más probable utilizarlos incorrectamente. En concreto, se debe evitar el modo de funcionamiento del libro de código electrónico (ECB). La reutilización del mismo vector de inicialización (IV) con cifrados de bloques en "modos de cifrados de flujo" como CTR puede provocar que se revelen los datos cifrados. Se recomienda una revisión de seguridad adicional si se usa cualquiera de los modos siguientes:
Comentarios de salida (OFB)
Comentarios de cifrado (CFB)
Contador (CTR)
Contador con CBC-MAC (CCM)
Modo Galois/Contador (GCM)
Cualquier otro modo no se encuentra en la lista "recomendada" anterior.
Vectores de inicialización (IV)
Todos los cifrados de bloques simétricos también se deben usar con un número aleatorio de alta seguridad criptográfica como vector de inicialización. Los vectores de inicialización nunca deben ser un valor constante. Consulte Generadores de números aleatorios para ver recomendaciones sobre la generación de números aleatorios de alta seguridad criptográfica.
Los vectores de inicialización nunca deben reutilizarse al realizar varias operaciones de cifrado, ya que esto puede revelar información sobre los datos que se cifran, especialmente cuando se usan modos de cifrado de flujo, como los modos de comentarios de salida (OFB) o de contador (CTR).
Algoritmos asimétricos, longitudes de clave y modos de relleno
RSA
RSA se debe utilizar para el cifrado, el intercambio de claves y las firmas.
El cifrado RSA debe usar los modos de relleno OAEP o RSA-PSS. El código existente debe utilizar el modo de relleno PKCS #1 v1.5 solo si es necesario para garantizar la compatibilidad.
No se recomienda el uso de relleno nulo.
Se recomiendan claves >= 2048 bits.
ECDSA
Se recomienda ECDSA con claves >= 256 bits.
Las firmas basadas en ECDSA deben utilizar una de las tres curvas NIST aprobadas (P-256, P-384 o P-521).
ECDH
Se recomienda ECDH con claves >= 256 bits.
El intercambio de claves de ECDH debe utilizar una de las tres curvas NIST aprobadas (P-256, P-384 o P-521).
Entero Diffie-Hellman
Se recomienda una longitud de clave >= 2048 bits.
Los parámetros de grupo deben ser un grupo con nombre conocido (por ejemplo, RFC 7919) o generado por una entidad de confianza y autenticado antes de su uso.
Vigencia de la clave
Todas las claves asimétricas deben tener una duración máxima de cinco años, con una vigencia recomendada de un año.
Todas las claves simétricas deben tener una duración máxima de tres años, con una vigencia recomendada de un año.
Debe proporcionar un mecanismo o disponer de un proceso para reemplazar claves para lograr la vigencia activa limitada. Después del final de su vigencia activa, no se debe usar una clave para generar nuevos datos (por ejemplo, para cifrado o firma), pero se puede seguir utilizando para leer datos (por ejemplo, para descifrado o comprobación).
Generadores de números aleatorios
Todos los productos y servicios deben usar generadores de números aleatorios criptográficamente seguros cuando se requiera aleatoriedad.
CNG
- Use BCryptGenRandom con la marca BCRYPT_USE_SYSTEM_PREFERRED_RNG.
CAPI
- Use CryptGenRandom para generar valores aleatorios.
Win32/64
El código heredado puede usar RtlGenRandom en modo kernel.
El código nuevo debe usar BCryptGenRandom o CryptGenRandom.
También se recomienda la función de C Rand_s() (que, en Windows, llama a CryptGenRandom).
Rand_s() es un reemplazo seguro y eficaz de Rand(). Rand() no debe usarse para ninguna aplicación criptográfica, pero es adecuado para pruebas internas únicamente.
La función SystemPrng se recomienda para el código en modo kernel.
.NET
- Uso de RNGCryptoServiceProvider
Aplicaciones de la Tienda Windows
- Las aplicaciones de la Tienda pueden usar CryptographicBuffer.GenerateRandom o CryptographicBuffer.GenerateRandomNumber.
No recomendado
Entre las funciones no seguras relacionadas con la generación de números aleatorios se incluyen rand,System.Random (.NET), GetTickCount y GetTickCount64.
No se recomienda usar el algoritmo ("DUAL_EC_DRBG") del generador de números aleatorios de curva elíptica dual.
Bibliotecas criptográficas compatibles con la plataforma Windows
En la plataforma Windows, Microsoft recomienda usar las API de cifrado integradas en el sistema operativo. En otras plataformas, los desarrolladores pueden optar por evaluar bibliotecas criptográficas que no son de la plataforma para su uso. En general, las bibliotecas criptográficas de la plataforma se actualizarán con más frecuencia, ya que se incluyen como parte de un sistema operativo en lugar de empaquetarse con una aplicación.
A la hora de decidir si usar criptografía de la plataforma o ajena a esta, deben considerarse los siguientes requisitos:
La biblioteca debe ser una versión actual compatible sin vulnerabilidades de seguridad conocidas.
Deben admitirse los protocolos de seguridad, los algoritmos y las longitudes de clave más recientes.
(Opcional) La biblioteca debe ser capaz de admitir algoritmos o protocolos de seguridad más antiguos solo para la compatibilidad con versiones anteriores.
Código nativo
Primitivas criptográficas: si su versión está en Windows o Windows Phone, use CNG si es posible. De lo contrario, use CryptoAPI (también llamada CAPI, que se admite como componente heredado en Windows a partir de Windows Vista).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 o IXMLHTTPRequest3.
- Las aplicaciones WinHTTP deben compilarse con WinHttpSetOptionpara admitir TLS 1.2.
Comprobación de firma de código: WinVerifyTrust es la API admitida para comprobar las firmas de código en plataformas Windows.
Validación de certificados (tal y como se usa en la validación de certificados restringida para la firma de código o SSL/TLS/DTLS): API CAPI2; por ejemplo, CertGetCertificateChain y CertVerifyCertificateChainPolicy.
Código administrado
Primitivas criptográficas: use la API definida en el espacio de nombres System.Security.Cryptography (se prefieren las clases CNG).
Use la versión más reciente de .NET Framework disponible. Como mínimo, debe ser .NET Framework 4.6. Si se requiere una versión anterior, asegúrese de que la clave de registro “SchUseStrongCrypto” está establecida para habilitar TLS 1.2 para la aplicación en cuestión.
Validación de certificados: use las API definidas en el espacio de nombres System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS: use las API definidas en el espacio de nombres System.Net (por ejemplo, HttpWebRequest).
Funciones de derivación de claves
La derivación de claves es el proceso de derivar material de clave criptográfica de un secreto compartido o una clave criptográfica existente. Los productos deben usar funciones de derivación de claves recomendadas. La derivación de claves a partir de contraseñas elegidas por el usuario o la aplicación de un algoritmo hash a contraseñas para su almacenamiento en un sistema de autenticación es un caso especial que no se trata en esta guía. Los desarrolladores deben consultar a un experto.
Los siguientes estándares especifican funciones de derivación de claves recomendadas:
NIST SP 800-108: Recomendación para la derivación de claves mediante funciones pseudoaleatorias. En concreto, la función de derivación de claves en modo de contador, con HMAC como función pseudoaleatoria.
NIST SP 800-56A (revisión 2): Recomendación de esquemas de establecimiento de claves por pares mediante criptografía de logaritmos discretos. En concreto, se recomienda la "Función de derivación de claves de un solo paso" de la sección 5.8.1.
Para derivar claves a partir de claves existentes, use la API BCryptKeyDerivation con uno de estos algoritmos:
BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM
Para derivar claves a partir de un secreto compartido (la salida de un acuerdo de claves), use la API BCryptDeriveKey con uno de los algoritmos siguientes:
BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC
Validación de certificados
Los productos que utilizan SSL, TLS y DTLS deben comprobar completamente los certificados X.509 de las entidades a las que se conectan. Esto incluye la comprobación de los siguientes aspectos de los certificados:
Nombre de dominio.
Fechas de validez (fechas de inicio y caducidad).
Estado de revocación
Uso (por ejemplo, “autenticación de servidor” para servidores, “autenticación de cliente” para clientes).
Cadena de confianza: los certificados deben estar encadenados a una entidad de certificación raíz (CA) que sea de confianza para la plataforma o que haya configurado explícitamente el administrador.
Si se produce un error en cualquiera de estas pruebas de comprobación, el producto debe finalizar la conexión con la entidad.
Los clientes que confían en certificados “autofirmados” (por ejemplo, un cliente de correo que se conecta a un servidor Exchange en una configuración predeterminada) pueden omitir las pruebas de comprobación de certificados. Sin embargo, los certificados autofirmados no proporcionan confianza, admiten la revocación ni admiten la renovación de claves de forma inherente. Solo debe confiar en los certificados autofirmados si los ha obtenido de otro origen de confianza (por ejemplo, una entidad de confianza que proporciona el certificado a través de un transporte autenticado y protegido en su integridad).
Funciones hash criptográficas
Los productos deben utilizar la familia SHA-2 de algoritmos hash (SHA256, SHA384 y SHA512). No se recomienda el truncamiento de los algoritmos hash criptográficos por debajo de los 128 bits por motivos de seguridad.
Algoritmos hash con clave, MAC o HMAC
Un código de autenticación de mensajes (MAC) es un fragmento de información que se adjunta a un mensaje, y que le permite a su destinatario comprobar la autenticidad del remitente y la integridad del mensaje mediante una clave secreta.
Se recomienda el uso de MAC basado en hash (HMAC) o MAC basado en el cifrado de bloques siempre que también se recomiende el uso de todos los algoritmos hash subyacentes o de cifrado simétrico; actualmente esto incluye las funciones de HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 y HMAC-SHA512).
No se recomienda el truncamiento de los HMAC por debajo de los 128 bits.
Consideraciones operativas y de diseño
Debe proporcionar un mecanismo para reemplazar las claves criptográficas según sea necesario. Las claves se deben reemplazar una vez que han llegado al final de su vigencia activa o si la clave criptográfica está en riesgo. Cada vez que renueve un certificado, debe renovarlo con una nueva clave.
Los productos que usan algoritmos criptográficos para proteger los datos deben incluir suficientes metadatos junto con ese contenido para admitir la migración a diferentes algoritmos en el futuro. Esto debe incluir el algoritmo utilizado, los tamaños de clave, los vectores de inicialización y los modos de relleno.
- Para más información sobre la agilidad criptográfica, consulte Agilidad criptográfica en MSDN.
Cuando estén disponibles, los productos deben usar protocolos criptográficos establecidos y proporcionados por la plataforma en lugar de volver a implementarlos. Esto incluye formatos de firma (por ejemplo, el uso de un formato estándar existente).
No deben usarse cifrados de flujos simétricos, como RC4. En lugar de cifrados de flujos simétricos, los productos deberían utilizar un cifrado por bloques, específicamente AES con una longitud de clave de 128 bits como mínimo.
No notifique errores de operación criptográfica a los usuarios finales. Al devolver un error a un llamador remoto (por ejemplo, un cliente web o un cliente en un escenario cliente-servidor), use solo un mensaje de error genérico.
- Evite proporcionar información innecesaria, como notificar directamente errores de longitud no válida o fuera del intervalo. Registre los errores detallados solo en el servidor y únicamente si está habilitado el registro detallado.
Se recomienda encarecidamente una revisión de la seguridad adicional para cualquier diseño que incorpore lo siguiente:
Un nuevo protocolo que se centre principalmente en la seguridad (por ejemplo, un protocolo de autenticación o autorización).
Un nuevo protocolo que use criptografía de una manera nueva o no estándar. Por ejemplo, pueden tenerse en cuenta las consideraciones siguientes:
¿Un producto que implemente el protocolo llamará a cualquier API o método criptográfico como parte de la implementación del protocolo?
¿Depende el protocolo de cualquier otro protocolo usado para la autenticación o autorización?
¿Definirá el protocolo formatos de almacenamiento para elementos criptográficos, como claves?
No se recomiendan los certificados autofirmados para entornos de producción. El uso de un certificado autofirmado, como el uso de una clave criptográfica sin procesar, no proporciona de forma inherente a los usuarios o administradores ninguna base para tomar una decisión de confianza.
- Por su parte, el uso de un certificado basado en una entidad de certificación de confianza establece claramente la base para confiar en la clave privada asociada y permite la revocación y las actualizaciones en caso de que se produzca un error de seguridad.
Cifrado de datos confidenciales antes de almacenarse
DPAPI/DPAPI-NG
Para los datos que deben conservarse entre reinicios del sistema:
CryptProtectData
CryptUnprotectData
NCryptProtectSecret (CNG DPAPI en Windows 8)
Para los datos que no es necesario conservar entre reinicios del sistema:
CryptProtectMemory
CryptUnprotectMemory
Para los datos que deben conservarse y ser accesibles para varias cuentas de dominio y equipos:
NCryptProtectSecret (en CNG DPAPI, disponible a partir de Windows 8)
SQL Server TDE
Puede usar el cifrado de datos transparente (TDE) de SQL Server para proteger datos confidenciales.
Debe usar una clave de cifrado de base de datos (DEK) de cifrado de datos transparente que cumpla los requisitos de nivel de clave y algoritmo criptográfico del ciclo de vida de desarrollo de seguridad de Microsoft. Actualmente, solo se recomiendan AES_128, AES_192 y AES_256; no se recomienda TRIPLE_DES_3KEY.
Para el uso de TDE de SQL se deben tener en cuenta algunas consideraciones importantes:
SQL Server no admite el cifrado de datos FILESTREAM, incluso si TDE está habilitado.
TDE no proporciona automáticamente el cifrado de datos en tránsito hacia o desde la base de datos; también debe habilitar las conexiones cifradas a la base de datos de SQL Server. Consulte Habilitaciónde conexiones cifradas en el motor de base de datos (Administrador de configuración de SQL Server) para obtener instrucciones sobre cómo habilitar las conexiones cifradas.
Si mueve una base de datos protegida por TDE a otra instancia de SQL Server, también debe mover el certificado que protege la clave de cifrado de datos (DEK) de TDE e instalarlo en la base de datos maestra de la instancia de SQL Server de destino. Consulte el artículo de TechNet Trasladode una base de datos protegida TDE a otra de SQL Server para más información.
Administración de credenciales
Use la API del administrador de credenciales de Windows o Microsoft Azure KeyVault para proteger datos de contraseñas y credenciales.
Aplicaciones de la Tienda Windows
Use las clases de los espacios de nombres Windows.Security.Cryptography y Windows.Security.Cryptography.DataProtection para proteger secretos y datos confidenciales.
ProtectAsync
ProtectStreamAsync
UnprotectAsync
UnprotectStreamAsync
Use las clases del espacio de nombres Windows.Security.Credentials para proteger datos de contraseñas y credenciales.
.NET
Para los datos que deben conservarse entre reinicios del sistema:
ProtectedData.Protect
ProtectedData.Unprotect
Para los datos que no es necesario conservar entre reinicios del sistema:
ProtectedMemory.Protect
ProtectedMemory.Unprotect
Para archivos de configuración, use
RSAProtectedConfigurationProvider o DPAPIProtectedConfigurationProvider para proteger la configuración, mediante cifrado RSA o DPAPI respectivamente.
RSAProtectedConfigurationProvider se puede usar en varias máquinas de un clúster. Consulte Cifrado de la información de configuración mediante la configuración protegida para más información.