Compartir a través de

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

  • Artículo

Use esta información como referencia al diseñar productos para usar las mismas API, algoritmos, protocolos y longitudes de claves que Microsoft requiere en sus propios productos y servicios. Gran parte del contenido se basa en los propios estándares de seguridad internos de Microsoft que se usan para crear el ciclo de vida de desarrollo de seguridad.

Los desarrolladores de plataformas que no son de Windows 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 TLS/SSL

Los productos y servicios deben usar versiones criptográficamente seguras de TLS/SSL:

  • TLS 1.3 debe estar habilitado.
  • TLS 1.2 se puede habilitar para mejorar la compatibilidad con clientes anteriores.
  • TLS 1.1, TLS 1.0, SSL 3 y SSL 2 deben estar deshabilitados

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).
  • Todos los demás cifrados de bloques, incluidos 3DES (Triple DES/TDEA) y RC4, deben reemplazarse si se usan para el cifrado.

En el caso de los algoritmos de cifrado de bloques simétricos, se requiere una longitud mínima de clave de 128 bits, pero se recomienda admitir claves de 256 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).

Modos de cifrado

Los algoritmos simétricos pueden funcionar en varios 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 están 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)
  • Cualquier otra cosa que no esté 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 o predicable. 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 se deben reutilizar al realizar varias operaciones de cifrado. La reutilización puede revelar información sobre los datos que se cifran, especialmente cuando se usan modos de cifrado de streaming, como Output Feedback (OFB) o Counter (CTR).

Recomendaciones de AES-GCM y AES-CCM

AES-GCM (modo Galois/Counter) y AES-CCM (Counter con CBC-MAC) son modos de cifrado autenticados ampliamente usados. Combinan la confidencialidad y la protección de la integridad, por lo que son útiles para una comunicación segura. Sin embargo, su fragilidad radica en la reutilización de nonce. Cuando se usa el mismo nonce (vector de inicialización) dos veces, esto puede provocar consecuencias catastróficas.

Se recomienda seguir las directrices de nonce tal como se describe en NIST SP 800-38D, recomendación para los modos de cifrado de bloques de operación: modo Galois/Counter (GCM) y GMAC. Se toma especial atención a la sección 8.3 con respecto al número máximo de invocaciones.

Otra opción sería generar claves AES-GCM/CCM únicas para cada mensaje encriptado, limitando así el número máximo de invocaciones a 1. Este enfoque se recomienda para el cifrado de datos en reposo, donde el uso de un contador o asegurarse de que se puede realizar un seguimiento del número máximo de invocaciones para una clave dada sería poco práctico.

Para cifrar datos en reposo, también puedes considerar el uso de AES-CBC con un código de autenticación de mensajes (MAC) como alternativa utilizando un esquema de cifrado y luego MAC, asegurándote de utilizar claves separadas para el cifrado y para el MAC.

Comprobación de integridad

Es un error común pensar que el cifrado proporciona por defecto tanto confidencialidad como garantía de integridad. Muchos algoritmos de cifrado no proporcionan ninguna comprobación de integridad y pueden ser vulnerables a ataques de manipulación. Se deben tomar medidas adicionales para garantizar la integridad de los datos antes de enviarlos y después de recibirlos.

Si no puede utilizar un algoritmo de cifrado autenticado con datos asociados (AEAD) como AES-GCM, una alternativa sería validar la integridad con un código de autenticación de mensaje (MAC) utilizando un esquema de cifrado y luego MAC, asegurándose de utilizar claves separadas para el cifrado y para el MAC.

Es esencial utilizar una clave distinta para el cifrado y para la MAC. Si no es posible almacenar las dos claves, una alternativa válida es derivar dos claves a partir de la clave principal utilizando una función de derivación de claves (KDF) adecuada, una para fines de cifrado y otra para MAC. Para más información, consulte SP 800-108 (Rev. 1): Recomendación para la derivación de claves mediante funciones pseudoaleatorias | CSRC (nist.gov).

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

RSA

  • RSA se puede utilizar para el cifrado, el intercambio de claves y la firma.
  • 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 recomienda un mínimo de longitud de clave de 2048 bits, pero se recomienda admitir una longitud de clave de 3072 bits.

ECDSA y ECDH

  • El intercambio de claves basado en ECDH y las firmas basadas en ECDSA deben usar una de las tres curvas aprobadas por NIST (P-256, P-384 o P521).
  • La compatibilidad con P-256 debe considerarse como mínimo, pero se recomienda admitir P-384.

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 clave

  • Defina un criptoperíodo para todas las claves.
    • Por ejemplo: una clave simétrica para el cifrado de datos, a menudo, denominada clave de cifrado de datos o DEK, podría tener un período de uso de hasta dos años para cifrar datos, también conocido como período de uso del originador. Puede definir que tiene un período de uso válido para el descifrado durante tres años más, también conocido como período de uso del destinatario.
  • 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

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.

.NET

PowerShell

Aplicaciones de la Tienda Windows

Linux/macOS

  • El dispositivo /dev/urandom proporciona un origen criptográficamente seguro de datos aleatorios, al igual que la llamada del sistema getrandom(2).

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 actualizan 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 la versión está en Windows, use CNG si es posible.
  • 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 (.NET)

  • Primitivas criptográficas: use la API definida en el espacio de nombres System.Security.Cryptography.
  • Use la versión más reciente de .NET disponible.

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 (Revisión 1): 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 3): Recomendación de esquemas de establecimiento de claves por pares mediante criptografía de logaritmos discretos.

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 TLS y DTLS deben comprobar completamente los certificados X.509 de las entidades a las que se conectan. Este proceso incluye la comprobación de las siguientes partes del certificado:

  • 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) 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.

No use certificados "autofirmados". Estos no transmiten confianza de forma inherente, la revocación ni la renovación de claves.

Funciones hash criptográficas

Los productos deben usar la familia SHA-2 de algoritmos hash (SHA-256, SHA-384 y SHA-512). No se permite el truncamiento de los algoritmos hash criptográficos por debajo de los 128 bits por motivos de seguridad. Aunque el uso de SHA-256 es el mínimo, se recomienda admitir SHA-384.

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). Aunque el uso de HMAC-SHA256 es el mínimo, se recomienda admitir HMAC-SHA384.

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 después de llegar 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. Estos metadatos deben incluir el algoritmo usado, los tamaños de clave 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, incluidos los formatos de firma (por ejemplo, use un formato estándar y existente).
  • 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 los siguientes elementos:
    • Un nuevo protocolo que se centre principalmente en la seguridad (por ejemplo, un protocolo de autenticación o autorización).
    • Nuevo protocolo que usa criptografía de una manera nueva o no estándar. Entre los ejemplos de consideraciones, se incluyen:
      • ¿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. 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 si hay un error de seguridad.