Criptografía multiplataforma en .NET

Las operaciones criptográficas de .NET se realizan mediante bibliotecas de sistema operativo (SO). Esta dependencia tiene ventajas:

• Las aplicaciones .NET se benefician de la confiabilidad del sistema operativo. Mantener las bibliotecas de criptografía seguras frente a vulnerabilidades es una prioridad importante para los proveedores del sistema operativo. Para ello, proporcionan actualizaciones que los administradores del sistema deben aplicar.
• Las aplicaciones .NET tendrán acceso a algoritmos validados por FIPS si las bibliotecas del sistema operativo están validadas por FIPS.

La dependencia sobre las bibliotecas del sistema operativo también significa que las aplicaciones .NET solo podrán usar las características criptográficas que admita el sistema operativo. Aunque todas las plataformas admiten determinadas características principales, algunas características que admite .NET no se pueden usar en algunas plataformas. En este artículo se identifican las características que se admiten en cada plataforma.

En este artículo se supone que está familiarizado con la criptografía en .NET. Para más información, consulte Modelo de criptografía de .NET y Servicios criptográficos de .NET.

Algoritmos de autenticación de mensajes y hash

Todos los algoritmos hash y las clases de autenticación de mensajes basadas en hash (HMAC), incluidas las clases *Managed, hacen referencia a las bibliotecas del sistema operativo, con la excepción de .NET en el WASM del explorador. En el explorador WASM, SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 y los equivalentes de HMAC se implementan mediante código administrado.

¹Disponible a partir de .NET 9.

²La función de salida extensible de streaming (XOF) está disponible a partir de .NET 9. En Linux, esto requiere OpenSSL 3.3.

Cifrado simétrico

Las bibliotecas del sistema realizan los cifrados y el encadenamiento subyacentes.

Cifrado autenticado

La compatibilidad con el cifrado autenticado (AE) se proporciona para AES-CCM, AES-GCM y ChaCha20Poly1305 a través de las clases System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm y System.Security.Cryptography.ChaCha20Poly1305, respectivamente.

Dado que el cifrado autenticado requiere las API de plataforma más recientes para admitir el algoritmo, es posible que no haya compatibilidad en todas las plataformas. La propiedad estática IsSupported de las clases del algoritmo se puede usar para detectar en tiempo de ejecución si la plataforma actual admite o no el algoritmo.

AES-CCM en macOS

En macOS, las bibliotecas del sistema no admiten AES-CCM para código de terceros, por lo que las clase AesCcm usa OpenSSL para ser compatible. Los usuarios de macOS deben obtener una copia adecuada de OpenSSL (libcrypto) para que este tipo funcione y debe estar en una ruta de acceso desde la que el sistema cargaría una biblioteca de forma predeterminada. Se recomienda que instale OpenSSL desde un administrador de paquetes como Homebrew.

Las bibliotecas libcrypto.0.9.7.dylib y libcrypto.0.9.8.dylib incluidas en macOS proceden de versiones anteriores de OpenSSL y no se usarán. Las bibliotecas libcrypto.35.dylib, libcrypto.41.dylib y libcrypto.42.dylib son de LibreSSL y no se usarán.

AES-GCM y ChaCha20Poly1305 en iOS, tvOS y MacCatalyst

La compatibilidad con AES-GCM y ChaCha20Poly1305 está disponible a partir de .NET 9 en iOS y tvOS 13.0 y versiones posteriores, y en todas las versiones de MacCatalyst.

Claves, nonces y etiquetas de AES-CCM

• Tamaños de clave

  AES-CCM funciona con claves de 128, 192 y 256 bits.

• Tamaños de nonce

  La clase AesCcm admite nonces de 56, 64, 72, 80, 88, 96 y 104 bits (7, 8, 9, 10, 11, 12 y 13 bytes).

• Tamaños de etiqueta

  La clase AesCcm admite la creación o procesamiento de etiquetas de 32, 48, 64, 80, 96, 112 y 128 bits (4, 8, 10, 12, 14 y 16 bytes).

Claves, nonces y etiquetas de AES-GCM

• Tamaños de clave

  AES-GCM funciona con claves de 128, 192 y 256 bits.

• Tamaños de nonce

  La clase AesGcm solo admite nonces de 96 bits (12 bytes).

• Tamaños de etiqueta en Windows y Linux: la clase AesGcm admite la creación o procesamiento de etiquetas de 96, 104, 112, 120 y 128 bits (12, 13, 14, 15 y 16 bytes). En las plataformas de Apple, el tamaño de la etiqueta está limitado a 128 bits (16 bytes) debido a las limitaciones del marco CryptoKit.

Claves, noces y etiquetas ChaCha20Poly1305.

ChaCha20Poly1305 tiene un tamaño fijo para la clave, nonce y etiqueta de autenticación. ChaCha20Poly1305 siempre usa una clave de 256 bits, un nonce de 96 bits (12 bytes) y una etiqueta de 128 bits (16 bytes).

Criptografía asimétrica

Esta sección contiene las siguientes subsecciones:

• RSA
• ECDSA
• ECDH
• DSA

RSA

La generación de claves RSA (Rivest–Shamir–Adleman) se realiza mediante las bibliotecas del sistema operativo y está sujeta a sus limitaciones de tamaño y características de rendimiento.

Las bibliotecas del sistema operativo realizan operaciones de clave RSA y los tipos de clave que se pueden cargar están sujetos a los requisitos del sistema operativo.

.NET no expone operaciones RSA "sin procesar" (sin rellenar).

La compatibilidad con relleno y síntesis del mensaje varía según la plataforma:

¹ Windows CryptoAPI (CAPI) admite la firma PKCS1 con un algoritmo SHA-2. Pero el objeto RSA individual se puede cargar en un proveedor de servicios criptográficos (CSP) que no lo admita.

RSA en Windows

• Windows CryptoAPI (CAPI) se utiliza cada vez que se usa new RSACryptoServiceProvider().
• Windows Cryptography API Next Generation (CNG) se utiliza cada vez que se usa new RSACng().
• El objeto que devuelve RSA.Create viene internamente con tecnología de Windows CNG. Este uso de Windows CNG es un detalle de implementación y está sujeto a cambios.
• El método de extensión GetRSAPublicKey de X509Certificate2 devuelve una instancia de RSACng. Este uso de RSACng es un detalle de implementación y está sujeto a cambios.
• El método de extensión GetRSAPrivateKey de X509Certificate2 prefiere actualmente una instancia de RSACng, pero si RSACng no puede abrir la clave, se intentará con RSACryptoServiceProvider. El proveedor preferido es un detalle de implementación y está sujeto a cambios.

Interoperabilidad nativa de RSA

.NET expone tipos para permitir que los programas interoperen con las bibliotecas del sistema operativo que usa el código de criptografía de .NET. Los tipos implicados no se trasladan entre plataformas y solo se deben usar directamente si es necesario.

¹ cuando no se trate de Windows, se puede usar RSACryptoServiceProvider para la compatibilidad con los programas existentes. En ese caso, cualquier método que requiera la interoperabilidad del sistema operativo, como abrir una clave con nombre, producirá una PlatformNotSupportedException.

² En macOS, RSAOpenSsl funciona si OpenSSL está instalado y se puede encontrar un libcrypto dylib adecuado a través de la carga dinámica de la biblioteca. Si no se encuentra una biblioteca adecuada, se producirán excepciones.

ECDSA

La generación de claves ECDSA (Elliptic Curve Digital Signature Algorithm) se realiza mediante las bibliotecas del sistema operativo y está sujeta a sus limitaciones de tamaño y características de rendimiento.

Las curvas de la clave ECDSA se definen mediante las bibliotecas del sistema operativo y están sujetas a sus limitaciones.

¹ Las distribuciones de Linux no todas admiten las mismas curvas con nombre.

² Se ha agregado compatibilidad con las curvas con nombre a Windows CNG en Windows 10. Para más información, consulte Curvas elípticas con nombre de CNG. Las curvas con nombre no están disponibles en versiones anteriores de Windows, excepto en tres curvas de Windows 7.

³ la exportación con parámetros de curva explícitos requiere compatibilidad con la biblioteca del sistema operativo, lo cual no está disponible en plataformas Apple ni en versiones anteriores de Windows.

⁴ la compatibilidad con Android para algunas curvas depende de la versión de Android. Los distribuidores de Android también podrían optar por agregar o quitar curvas de su compilación de Android.

Interoperabilidad nativa de ECDSA

.NET expone tipos para permitir que los programas interoperen con las bibliotecas del sistema operativo que usa el código de criptografía de .NET. Los tipos implicados no se trasladan entre plataformas y solo se deben usar directamente si es necesario.

* En macOS, ECDsaOpenSsl funciona si OpenSSL está instalado en el sistema y se puede encontrar un libcrypto dylib adecuado a través de la carga dinámica de la biblioteca. Si no se encuentra una biblioteca adecuada, se producirán excepciones.

ECDH

La generación de claves ECDH (Elliptic Curve Diffie-Hellman) se realiza mediante las bibliotecas del sistema operativo y está sujeta a sus limitaciones de tamaño y características de rendimiento.

La clase ECDiffieHellman admite el valor "sin procesar" del cálculo ECDH, así como a través de las siguientes funciones de derivación de claves:

• HASH(Z)
• HASH(prepend || Z || append)
• HMAC(key, Z)
• HMAC(key, prepend || Z || append)
• HMAC(Z, Z)
• HMAC(Z, prepend || Z || append)
• Tls11Prf(label, seed)

Las curvas de la clave ECDH se definen mediante las bibliotecas del sistema operativo y están sujetas a sus limitaciones.

¹ Las distribuciones de Linux no todas admiten las mismas curvas con nombre.

² Se ha agregado compatibilidad con las curvas con nombre a Windows CNG en Windows 10. Para más información, consulte Curvas elípticas con nombre de CNG. Las curvas con nombre no están disponibles en versiones anteriores de Windows, excepto en tres curvas de Windows 7.

³ la exportación con parámetros de curva explícitos requiere compatibilidad con la biblioteca del sistema operativo, lo cual no está disponible en plataformas Apple ni en versiones anteriores de Windows.

⁴ la compatibilidad con Android para algunas curvas depende de la versión de Android. Los distribuidores de Android también podrían optar por agregar o quitar curvas de su compilación de Android.

Interoperabilidad nativa de ECDH

.NET expone tipos para permitir que los programas interoperen con las bibliotecas del sistema operativo que usa .NET. Los tipos implicados no se trasladan entre plataformas y solo se deben usar directamente si es necesario.

* En macOS, ECDiffieHellmanOpenSsl funciona si OpenSSL está instalado y se puede encontrar un libcrypto dylib adecuado a través de la carga dinámica de la biblioteca. Si no se encuentra una biblioteca adecuada, se producirán excepciones.

DSA

La generación de claves DSA (Digital Signature Algorithm) se realiza mediante las bibliotecas del sistema y está sujeta a sus limitaciones de tamaño y características de rendimiento.

* macOS carga claves DSA con un tamaño superior a 1024 bits, pero el comportamiento de esas claves no está definido. No se comportan según FIPS 186-3.

DSA en Windows

• Windows CryptoAPI (CAPI) se utiliza cada vez que se usa new DSACryptoServiceProvider().
• Windows Cryptography API Next Generation (CNG) se utiliza cada vez que se usa new DSACng().
• El objeto que devuelve DSA.Create viene internamente con tecnología de Windows CNG. Este uso de Windows CNG es un detalle de implementación y está sujeto a cambios.
• El método de extensión GetDSAPublicKey de X509Certificate2 devuelve una instancia de DSACng. Este uso de DSACng es un detalle de implementación y está sujeto a cambios.
• El método de extensión GetDSAPrivateKey de X509Certificate2 prefiere una instancia de DSACng, pero si DSACng no puede abrir la clave, se intentará con DSACryptoServiceProvider. El proveedor preferido es un detalle de implementación y está sujeto a cambios.

Interoperabilidad nativa de DSA

.NET expone tipos para permitir que los programas interoperen con las bibliotecas del sistema operativo que usa el código de criptografía de .NET. Los tipos implicados no se trasladan entre plataformas y solo se deben usar directamente si es necesario.

¹ cuando no se trate de Windows, se puede usar DSACryptoServiceProvider para la compatibilidad con los programas existentes. En ese caso, cualquier método que requiera la interoperabilidad del sistema, como abrir una clave con nombre, producirá una PlatformNotSupportedException.

² En macOS, DSAOpenSsl funciona si OpenSSL está instalado y se puede encontrar un libcrypto dylib adecuado a través de la carga dinámica de la biblioteca. Si no se encuentra una biblioteca adecuada, se producirán excepciones.

Certificados X.509

La mayoría de la compatibilidad con los certificados X.509 en .NET procede de las bibliotecas del sistema operativo. Para cargar un certificado en una instancia de X509Certificate2 o X509Certificate en .NET, la biblioteca del sistema operativo subyacente debe cargar el certificado.

Lectura de un PKCS12/PFX

Escritura de un PKCS12/PFX

macOS no puede cargar claves privadas de certificado sin un objeto de cadena de claves, lo cual requiere escribir en el disco. Las cadenas de claves se crean automáticamente para la carga PFX y se eliminan cuando no se usan. Puesto que la opción X509KeyStorageFlags.EphemeralKeySet significa que la clave privada no debe escribirse en el disco, emplear esa marca en macOS da como resultado la excepción PlatformNotSupportedException.

Escritura de una colección de certificados PKCS7

Windows y Linux emiten blobs PKCS7 codificados con DER. macOS emite blobs PKCS7 con codificación CER de longitud indefinida.

X509Store

En Windows, la clase X509Store es una representación de las API del almacén de certificados de Windows. Esas API funcionan igual en .NET Core y .NET 5 que en .NET Framework.

Cuando no se trate de Windows, la clase X509Store es una proyección de decisiones de confianza del sistema (solo lectura), decisiones de confianza del usuario (lectura y escritura) y almacenamiento de claves de usuario (lectura y escritura).

En las tablas siguientes se muestran los escenarios que se admiten en cada plataforma. En el caso de los escenarios no admitidos (❌ en las tablas), se produce la excepción CryptographicException.

El almacén My

En Linux, los almacenes se crean en la primera escritura y no existen almacenes de usuario de forma predeterminada, por lo que es posible que se produzca un error al abrir CurrentUser\My con ExistingOnly.

En macOS, el almacén CurrentUser\My es la cadena de claves predeterminada del usuario, la cual es login.keychain de forma predeterminada. El almacén LocalMachine\My es System.keychain.

El almacén Root

En Linux, el almacén LocalMachine\Root es una interpretación de la agrupación de CA en la ruta de acceso predeterminada de OpenSSL.

En macOS, el almacén CurrentUser\Root es una interpretación de los resultados SecTrustSettings del dominio de confianza del usuario. El almacén LocalMachine\Root es una interpretación de los resultados SecTrustSettings de los dominios de confianza del administrador y del sistema.

El almacén Intermediate

En Linux, el almacén CurrentUser\Intermediate se usa como caché al descargar CA intermedias según sus registros de acceso a la información de entidad en compilaciones X509Chain correctas. En Linux, el almacén LocalMachine\Intermediate es una interpretación de la agrupación de CA de la ruta de acceso predeterminada de OpenSSL.

En macOS, el almacén CurrentUser\Intermediate se trata como un almacén personalizado. Los certificados agregados a este almacén no afectan a la compilación de cadenas X.509.

El almacén Disallowed

En Linux, el almacén Disallowed no se usa en la creación de cadenas e intentar agregar contenido a él da como resultado la excepción CryptographicException. Se produce la excepción CryptographicException al abrir el almacén Disallowed si ya ha adquirido contenido.

En macOS, los almacenes CurrentUser\Disallowed y LocalMachine\Disallowed son interpretaciones de los resultados de SecTrustSettings adecuados para los certificados cuya confianza se ha establecido en Always Deny.

Almacén Nonexistent

En macOS, la creación de almacenes personalizados con la API X509Store solo se admite para la ubicación CurrentUser. Se creará una nueva cadena de claves sin contraseña en el directorio de cadenas de claves del usuario (~/Library/Keychains). Para crear una cadena de claves con contraseña, se podría usar P/Invoke para SecKeychainCreate. Del mismo modo, se podría usar SecKeychainOpen para abrir las cadenas de claves en diferentes ubicaciones. El resultado IntPtr se puede pasar a new X509Store(IntPtr) para obtener un almacén compatible con lectura y escritura, sujeto a los permisos del usuario actual.

X509Chain

macOS no admite el uso de CRL sin conexión, por lo que X509RevocationMode.Offline se trata como X509RevocationMode.Online.

macOS no admite un tiempo de espera iniciado por el usuario en la descarga de CRL (lista de revocación de certificados) / OCSP (protocolo de estado de certificados en línea) / AIA (acceso a la información de entidad), por lo que X509ChainPolicy.UrlRetrievalTimeout se omite.

Recursos adicionales

• Modelo de criptografía de .NET
• Servicios criptográficos de .NET
• Vulnerabilidades de temporalización con descifrado simétrico en modo CBC al usar el relleno
• Protección de datos de ASP.NET Core