Microsoft SDL Cryptographic Recomendaciones

Artículo
11/28/2021
13 minutos para leer

Introducción

Este documento contiene recomendaciones y procedimientos recomendados para usar el cifrado en plataformas de Microsoft. Gran parte del contenido aquí está parafrasado o agregado a partir de los propios estándares de seguridad interna de Microsoft usados para crear el ciclo de vida de desarrollo de seguridad. Está pensado para usarse como referencia al diseñar productos para usar las mismas API, algoritmos, protocolos y longitudes clave que Microsoft requiere de sus propios productos y servicios.

Los desarrolladores que no Windows plataformas también pueden beneficiarse de estas recomendaciones. Aunque los nombres de la API y la biblioteca pueden ser diferentes, los procedimientos recomendados relacionados con la elección del algoritmo, la longitud de las claves y la protección de datos son similares en todas las plataformas.

Protocolo de seguridad, algoritmo y longitud de clave Recomendaciones

Versiones 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 deshabilitados de forma predeterminada

Cifrados de bloque simétricos, modos de cifrado y vectores de inicialización

Bloquear cifrados

Para productos que usan cifrados de bloque simétricos:

Se recomienda el estándar de cifrado avanzado (AES) para código nuevo.
El triple estándar de cifrado de datos (3DES) de tres teclas es permisible en el código existente para la compatibilidad con versiones anteriores.
Todos los demás cifrados de bloques, incluidos RC2, DES, 3DES de 2 teclas, 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 bloque simétricos, se recomienda una longitud mínima de clave 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, y hay que tener en cuenta que AES-192 carece de optimización en algunos procesadores). 3DES de tres teclas es aceptable actualmente si ya está en uso en código existente; se recomienda la transición a AES. DES, DESX, RC2 y Skipjack ya no se consideran seguros. Estos algoritmos solo deben usarse para descifrar datos existentes en aras de la compatibilidad con versiones anteriores y los datos deben volverse a cifrar con un cifrado de bloque recomendado.

Modos de cifrado

Los algoritmos simétricos pueden funcionar en una variedad de modos, la mayoría de los cuales vinculan las operaciones de cifrado en bloques sucesivos de texto sin formato y texto cifrado.

Los cifrados de bloque simétricos deben usarse con uno de los siguientes modos de cifrado:

Encadenamiento de bloques de cifrado (CBC)
Robo de texto cifrado (CTS)
Datos basados en XEX Tweaked-Codebook robo de texto cifrado (XTS)

Algunos otros modos de cifrado como los que se incluyen a continuación tienen dificultades de implementación que hacen que sean más probables que se utilicen incorrectamente. En particular, debe evitarse el modo de funcionamiento del Libro de códigos electrónico (BCE). Volver a usar el mismo vector de inicialización (IV) con cifrados de bloques en "modos de cifrado de streaming" como CTR puede hacer que se revelen datos cifrados. Se recomienda una revisión de seguridad adicional si se usa alguno de los modos siguientes:

Comentarios de salida (OFB)
Comentarios de cifrado (CFB)
Contador (CTR)
Contador con CBC-MAC (CCM)
Modo Galois/Counter (GCM)
Cualquier otra cosa que no se encuentra en la lista "recomendada" anterior

Vectores de inicialización (IV)

Todos los cifrados de bloque simétricos también deben usarse con un número aleatorio cifrado fuerte como vector de inicialización. Los vectores de inicialización nunca deben ser un valor constante. Vea Generadores de números aleatorios para obtener recomendaciones sobre la generación de números aleatorios cifrados.

Los vectores de inicialización nunca se deben volver a usar al realizar varias operaciones de cifrado, ya que esto puede revelar información sobre los datos cifrados, especialmente cuando se usan modos de cifrado de streaming como Comentarios de salida (OFB) o Contador (CTR).

Algoritmos asimétricos, longitudes de teclas y modos de relleno

RSA

RSA debe usarse 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 usar el modo de relleno PKCS #1 v1.5 solo para la compatibilidad.
No se recomienda usar relleno nulo.
Teclas > = se recomiendan 2048 bits

ECDSA

Se recomienda ECDSA con > teclas = 256 bits
Las firmas basadas en ECDSA deben usar una de las tres curvas aprobadas por NIST (P-256, P-384 o P521).

ECDH

Se recomienda ECDH con > = teclas de 256 bits
El intercambio de claves basado en ECDH debe usar una de las tres curvas aprobadas por NIST (P-256, P-384 o P521).

Integer Diffie-Hellman

Longitud de > la clave = se recomiendan 2048 bits
Los parámetros de grupo deben ser un grupo con nombre conocido (por ejemplo, RFC 7919) o generado por una parte de confianza y autenticado antes de su uso

Duración de las claves

Todas las claves asimétricas deben tener una duración máxima de cinco años, una duración recomendada de un año.
Todas las claves simétricas deben tener una duración máxima de tres años; una duración recomendada de un año.
Debe proporcionar un mecanismo o tener un proceso para reemplazar claves para lograr la duración activa limitada. Después del final de su vida activa, no se debe usar una clave para generar nuevos datos (por ejemplo, para cifrado o firma), pero puede seguir usársela para leer datos (por ejemplo, para el descifrado o la verificación).

Generadores de números aleatorios

Todos los productos y servicios deben usar generadores de números aleatorios seguros criptográficamente cuando se requiera aleatoriedad.

CNG

Usar BCryptGenRandom con la BCRYPT_USE_SYSTEM_PREFERRED_RNG de datos

CAPI

Use CryptGenRandom para generar valores aleatorios.

Win32/64

El código heredado puede usar RtlGenRandom en modo kernel
El nuevo código debe usar BCryptGenRandom o CryptGenRandom.
También se recomienda la función C Rand_s() (que, en Windows, llama a CryptGenRandom)
Rand_s() es un reemplazo seguro y performant para Rand(). Rand() no se debe usar para ninguna aplicación criptográfica, pero solo está disponible para pruebas internas.
Se recomienda la función SystemPrng para código de modo kernel.

.NET

Use RNGCryptoServiceProvider o RNGCng.

Windows aplicaciones de la Tienda

Las aplicaciones de store pueden usar CryptographicBuffer.GenerateRandom o CryptographicBuffer.GenerateRandomNumber.

No recomendado

Las funciones inseguras relacionadas con la generación de números aleatorios incluyen rand,System.Random (.NET), GetTickCount y GetTickCount64
No se recomienda usar el algoritmo de doble curva elíptica de número aleatorio ("DUAL_EC_DRBG").

Windows bibliotecas de cifrado compatibles con la plataforma

En la Windows, Microsoft recomienda usar las API de cifrado integradas en el sistema operativo. En otras plataformas, los desarrolladores pueden optar por evaluar bibliotecas de cifrado que no son de plataforma para su uso. En general, las bibliotecas de cifrado de plataformas se actualizarán con más frecuencia, ya que se envían como parte de un sistema operativo en lugar de empaquetarse con una aplicación.

Cualquier decisión de uso con respecto a la plataforma frente a la criptografía que no sea de plataforma debe guiarse por los siguientes requisitos:

La biblioteca debe ser una versión actual en soporte técnico libre de vulnerabilidades de seguridad conocidas
Los protocolos de seguridad, algoritmos y longitudes de clave más recientes deben ser compatibles
(Opcional) La biblioteca debe ser capaz de admitir protocolos de seguridad o algoritmos antiguos solo para la compatibilidad con versiones anteriores

Código nativo

Crypto Primitives: Si la versión está en Windows o Windows Phone, use CNG si es posible. En caso contrario, use la CryptoAPI (también denominada CAPI, que se admite como un componente heredado en Windows desde Windows Vista en adelante).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 o IXMLHTTPRequest3.
- Las aplicaciones de WinHTTP deben crearse con WinHttpSetOption paraadmitir TLS 1.2
Verificación de firma de código: WinVerifyTrust es la API compatible para comprobar las firmas de código en Windows plataformas.
Validación de certificado (como se usa en la validación de certificados restringidos para la firma de código o SSL/TLS/DTLS): API CAPI2; por ejemplo, CertGetCertificateChain y CertVerifyCertificateChainPolicy

Código administrado

Crypto Primitives: Use la API definida en el espacio de nombres System.Security.Cryptography---las clases de CNG son preferidas.
Use la versión más reciente de .Net Framework disponible. Como mínimo, debería ser .Net Framework versión 4.6. Si se requiere una versión anterior, asegúrese de que la tecla de registro "SchUseStrongCrypto" está configurada para habilitar TLS 1.2 para la aplicación en cuestión.
Validación de certificado: Use API definidas en el espacio de nombres System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS: Use API definidas en el espacio de nombres System.Net (por ejemplo, HttpWebRequest).

Funciones de derivación de teclas

La derivación de claves es el proceso de derivación de material de clave criptográfica a partir 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 de contraseñas elegidas por el usuario o el hash de contraseñas para almacenamiento en un sistema de autenticación es un caso especial no cubierto por estas instrucciones; los desarrolladores deben consultar a un experto.

Los siguientes estándares especifican las funciones KDF recomendadas para su uso:

NIST SP 800-108: Recomendación para la derivación de claves mediante funciones de pseudoaleatorio. En particular, el KDF en modo de contador, con HMAC como función de pseudoaleativo
NIST SP 800-56A (revisión 2): Recomendación para los Pair-Wise de establecimiento de claves con criptografía logaritmo discreta. En particular, se recomienda la "Función de derivación de clave de un solo paso" en la sección 5.8.1.

Para derivar claves de claves existentes, use la API BCryptKeyDerivation con uno de los algoritmos:

BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM

Para derivar claves de un secreto compartido (el resultado de un contrato de clave) use la API BCryptDeriveKey con uno de los siguientes algoritmos:

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

Validación de certificados

Los productos que usan SSL, TLS o DTLS deben comprobar por completo los certificados X.509 de las entidades a las que se conectan. Esto incluye la verificación de los certificados:This includes verification of the certificates':

Nombre de dominio.
Fechas de validez (fechas de inicio y expiración).
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 encadenarse a una entidad de certificación raíz (CA) de confianza de la plataforma o configurada explícitamente por el administrador.

Si alguna de estas pruebas de verificación falla, 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 comprobaciones de verificación de certificados. Sin embargo, los certificados autofirmados no transmiten intrínsecamente confianza, admiten la revocación o admiten la renovación de claves. 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 sobre un transporte autenticado y protegido por la integridad).

Funciones hash criptográficas

Los productos deben usar la familia SHA-2 de algoritmos hash (SHA256, SHA384 y SHA512). No se recomienda truncar los hashes criptográficos con fines de seguridad a menos de 128 bits.

Algoritmos de hash con teclas MAC/HMAC

Un código de autenticación de mensajes (MAC) es un fragmento de información adjunto a un mensaje que permite a su destinatario comprobar la autenticidad del remitente y la integridad del mensaje con una clave secreta.

Se recomienda usar un MAC basado en hash(HMAC) o un MAC basado en cifrado de bloques siempre y cuando también se recomienda usar todos los algoritmos de cifrado simétricos o hash subyacentes; actualmente se incluyen las funciones HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 y HMAC-SHA512).

No se recomienda truncar los MMACS a menos de 128 bits.

Consideraciones operativas y de diseño

Debe proporcionar un mecanismo para reemplazar las claves criptográficas según sea necesario. Las claves deben reemplazarse una vez que han alcanzado el final de su vida activa o si la clave criptográfica está en peligro. Siempre que renueve un certificado, debe renovarlo con una nueva clave.
Los productos que usan algoritmos criptográficos para proteger datos deben incluir metadatos suficientes junto con ese contenido para admitir la migración a diferentes algoritmos en el futuro. Esto debe incluir el algoritmo usado, los tamaños de clave, los vectores de inicialización y los modos de relleno.
- Para obtener más información sobre agilidad criptográfica, vea 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, usar un formato estándar existente).
No se deben usar cifrados de transmisión simétrica como RC4. En lugar de cifrados de transmisión simétrica, los productos deben usar un cifrado de bloques, específicamente AES con una longitud de clave de al menos 128 bits.
No informe de errores de operación criptográfica a los usuarios finales. Al devolver un error a un autor de llamada remoto (por ejemplo, cliente web o cliente en un escenario de cliente-servidor), use un mensaje de error genérico solo.
- Evite proporcionar información innecesaria, como, por ejemplo, informar directamente de errores fuera del rango o de longitud no válida. Registre errores detallados solo en el servidor y solo si el registro detallado está habilitado.
La revisión de seguridad adicional es muy recomendable para cualquier diseño que incorpore lo siguiente:
- Un nuevo protocolo que se centra principalmente en la seguridad (como un protocolo de autenticación o autorización)
- Un nuevo protocolo que usa la criptografía de una forma nueva o no estándar o Consideraciones de ejemplo incluyen:
  - ¿Llamará un producto que implementa el protocolo a las API o métodos criptográficos 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 las claves?
Los certificados autofirmados no se recomiendan para entornos de producción. El uso de un certificado autofirmado, como el uso de una clave criptográfica sin procesar, no proporciona intrínsecamente a los usuarios o administradores ninguna base para tomar una decisión de confianza.
- Por el contrario, el uso de un certificado basado en una entidad de certificación de confianza deja clara la base para confiar en la clave privada asociada y permite la revocación y las actualizaciones en caso de un error de seguridad.

Cifrar datos confidenciales antes de Storage

DPAPI/DPAPI-NG

Para los datos que deben conservarse en los reinicios del sistema:

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (Windows 8 DPAPI CNG)

Para los datos que no es necesario conservar en los reinicios del sistema:

CryptProtectMemory
CryptUnprotectMemory

Para los datos a los que deben conservarse y tener acceso varias cuentas de dominio y equipos:

NCryptProtectSecret (en DPAPI de CNG, disponible a Windows 8)
Microsoft Azure KeyVault

SQL Server TDE

Puede usar SQL Server Cifrado de datos transparente (TDE) para proteger datos confidenciales.

Debe usar una clave de cifrado de base de datos TDE (DEK) que cumpla los requisitos de resistencia y algoritmo criptográfico SDL. Actualmente, solo AES_128, AES_192 y AES_256 se recomiendan; TRIPLE_DES_3KEY no se recomienda.

Hay algunas consideraciones importantes para usar SQL TDE que debe tener en cuenta:

SQL Server no admite el cifrado de datos FILESTREAM, incluso cuando TDE está habilitado.
TDE no proporciona automáticamente cifrado para los datos en tránsito hacia o desde la base de datos; también debe habilitar las conexiones cifradas a la base SQL Server datos. Consulte Habilitar conexionescifradas a la 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 instalarla en la base de datos maestra de la instancia SQL Server destino. Vea el artículo de TechNet Mover una base de datos protegida por TDE aotro SQL Server para obtener más información.

Administración de credenciales

Use la API Windows Credential Manager o Microsoft Azure KeyVault para proteger los datos de contraseña y credenciales.

Windows aplicaciones de la Tienda

Use las clases de la Windows. Security.Cryptography y Windows. Espacios de nombres Security.Cryptography.DataProtection para proteger secretos y datos confidenciales.

ProtectAsync
ProtectStreamAsync
DesprotegerAsync
DesprotegerStreamAsync

Use las clases de la Windows. Espacio de nombres Security.Credentials para proteger los datos de contraseña y credenciales.

.NET