Recomendaciones criptográficas del ciclo de vida de desarrollo de seguridad de Microsoft

  • Artículo

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:

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

CAPI

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

Aplicaciones de la Tienda Windows

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:

  1. La biblioteca debe ser una versión actual compatible sin vulnerabilidades de seguridad conocidas.

  2. Deben admitirse los protocolos de seguridad, los algoritmos y las longitudes de clave más recientes.

  3. (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.

  • 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:

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:

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.