Criptografia Multiplataforma no .NET

As operações criptográficas no .NET são realizadas pelas bibliotecas do sistema operacional (SO). Essa dependência tem vantagens:

• Os aplicativos .NET se beneficiam da confiabilidade do sistema operacional. Manter bibliotecas de criptografia seguras contra vulnerabilidades é uma alta prioridade para os fornecedores de SO. Para fazer isso, eles fornecem atualizações que os administradores do sistema devem aplicar.
• Os aplicativos .NET terão acesso a algoritmos validados por FIPS se as bibliotecas do SO forem validadas pelo FIPS.

A dependência de bibliotecas do sistema operacional também significa que os aplicativos .NET só podem usar recursos criptográficos compatíveis com o sistema operacional. Embora todas as plataformas deem suporte a determinados recursos principais, alguns recursos com suporte no .NET não podem ser usados em algumas plataformas. Este artigo identifica os recursos com suporte em cada plataforma.

Este artigo pressupõe que você tenha uma familiaridade funcional com criptografia no .NET. Para mais informações, confira Modelo de Criptografia do .NET e Serviços de Criptografia do .NET.

Algoritmos de autenticação de hash e mensagem

Todas as classes de algoritmo de hash e autenticação de mensagens baseada em hash (HMAC), incluindo as classes *Managed, dependem das bibliotecas do SO, com exceção do .NET no WASM do Navegador. No navegador WASM, SHA-1, SHA-2-256, SHA-2-384, SHA-2-512 e os equivalentes HMAC são implementados usando código gerenciado.

1 Disponível a partir do .NET 9.

2 A função de saída extensível (XOF) de streaming está disponível a partir do .NET 9. No Linux, isso requer o OpenSSL 3.3.

Criptografia simétrica

As criptografias subjacentes e o encadeamento são feitos pelas bibliotecas do sistema.

Criptografia autenticada

O suporte à criptografia autenticada (AE) é fornecido para AES-CCM, AES-GCM e ChaCha20Poly1305 por meio das classes System.Security.Cryptography.AesCcm, System.Security.Cryptography.AesGcm e System.Security.Cryptography.ChaCha20Poly1305, respectivamente.

Como a criptografia de autenticação requer APIs de plataforma mais recentes para dar suporte ao algoritmo, o suporte pode não estar presente em todas as plataformas. A propriedade estática IsSupported nas classes do algoritmo pode ser utilizada para detectar, em runtime, se a plataforma atual dá suporte ao algoritmo ou não.

AES-CCM no macOS

Antes do .NET 10, AES-CCM funcionava se uma versão com suporte do OpenSSL estivesse presente e o carregador de biblioteca dinâmica pudesse localizá-la. O suporte ao OpenSSL no macOS foi removido no .NET 10.

AES-GCM e ChaCha20Poly1305 no iOS, tvOS e MacCatalyst

O suporte para AES-GCM e ChaCha20Poly1305 está disponível a partir do .NET 9 no iOS e tvOS 13.0 e posterior, e em todas as versões do MacCatalyst.

Chaves, nonces e marcas do AES-CCM

• Tamanhos de chave

  O AES-CCM funciona com chaves de 128, 192 e 256 bits.

• Tamanhos de Nonce

  A classe AesCcm dá suporte a nós de 56, 64, 72, 80, 88, 96 e 104 bits (7, 8, 9, 10, 11, 12 e 13 bytes).

• Tamanhos de marca

  A classe AesCcm dá suporte à criação ou processamento de marcas de 32, 48, 64, 80, 96, 112 e 128 bits (4, 8, 10, 12, 14 e 16 bytes).

Chaves, nonces e marcas do AES-GCM

• Tamanhos de chave

  O AES-GCM funciona com chaves de 128, 192 e 256 bits.

• Tamanhos de Nonce

  A classe AesGcm dá suporte apenas a nós de 96 bits (12 bytes).

• Tamanhos de marca No Windows e no Linux, a classe AesGcm dá suporte à criação ou ao processamento de marcas de 96, 104, 112, 120 e 128 bits (12, 13, 14, 15 e 16 bytes). Nas plataformas Apple, o tamanho da marca é limitado a 128 bits (16 bytes) devido a limitações da estrutura do CryptoKit.

Chaves, nonces e marcas ChaCha20Poly1305.

O ChaCha20Poly1305 tem um tamanho fixo para a chave, o nonce e a marca de autenticação. O ChaCha20Poly1305 sempre usa uma chave de 256 bits, um nonce de 96 bits (12 bytes) e uma marca de 128 bits (16 bytes).

Criptografia assimétrica

Esta seção inclui as seguintes subseções:

• RSA
• ECDSA
• ECDH
• DSA

RSA

A geração de chaves RSA (Rivest-Shamir-Adleman) é executada pelas bibliotecas do sistema operacional e está sujeita às suas limitações de tamanho e características de desempenho.

As operações de chave RSA são executadas pelas bibliotecas do SO e os tipos de chave que podem ser carregadas estão sujeitos aos requisitos do sistema operacional.

O .NET não expõe operações RSA "brutas" (não preenchidas).

O suporte ao preenchimento e resumo da mensagem variam de acordo com a plataforma:

¹ O Windows CryptoAPI (CAPI) tem capacidade para a assinatura PKCS1 com um algoritmo SHA-2. Porém, o objeto RSA individual pode ser carregado em um CSP (provedor de serviços de criptografia) que não dá suporte a ele.

RSA no Windows

• O CAPI (Windows CryptoAPI) é usado sempre que new RSACryptoServiceProvider() é usado.
• A CNG (API de Criptografia do Windows) é usada sempre que new RSACng() é usada.
• O objeto retornado por RSA.Create é alimentado internamente pela CNG do Windows. Esse uso do CNG do Windows é um detalhe de implementação e está sujeito a alterações.
• O método GetRSAPublicKey de extensão para X509Certificate2 retorna uma instância RSACng. Esse uso de RSACng é um detalhe de implementação e está sujeito a alterações.
• O método de extensão GetRSAPrivateKey para X509Certificate2 atualmente prefere uma instância RSACng, mas se RSACng não puder abrir a chave, RSACryptoServiceProvider será tentado. O provedor preferencial é um detalhe de implementação e está sujeito a alterações.

Interoperabilidade nativa de RSA

O .NET expõe tipos para permitir que programas interoperem com as bibliotecas do sistema operacional que o código de criptografia .NET usa. Os tipos envolvidos não são convertidos entre plataformas e só devem ser usados diretamente quando necessário.

¹ Em sistemas não Windows, RSACryptoServiceProvider pode ser utilizado para compatibilidade com programas existentes. Nesse caso, qualquer método que exija interoperabilidade do SO, como abrir uma chave nomeada, gera um PlatformNotSupportedException.

² No macOS, antes do .NET 10, RSAOpenSsl funcionava se o OpenSSL estava instalado e um dylib libcrypto apropriado poderia ser encontrado por meio do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

ECDSA

A geração de chaves ECDSA (Algoritmo de Assinatura Digital da Curva Elíptica) é feita pelas bibliotecas do SO e está sujeita às suas limitações de tamanho e características de desempenho.

As curvas de chave ECDSA são definidas pelas bibliotecas do SO e estão sujeitas às respectivas limitações.

¹ Nem todas as distribuições Linux têm suporte para as mesmas curvas nomeadas.

² O suporte para curvas nomeadas foi adicionado ao CNG do Windows no Windows 10. Para mais informações, confira Curvas elípticas nomeadas do CNG. As curvas nomeadas não estão disponíveis em versões anteriores do Windows, exceto por três curvas no Windows 7.

³ A exportação com parâmetros de curva explícitos exige suporte da biblioteca do SO, que não está disponível nas plataformas com suporte da Apple ou em versões anteriores do Windows.

⁴ O suporte do Android para algumas curvas depende da versão do Android. Os distribuidores do Android também podem optar por adicionar ou remover as curvas da sua build do Android.

Interoperabilidade nativa ECDSA

O .NET expõe tipos para permitir que programas interoperem com as bibliotecas do sistema operacional que o código de criptografia .NET usa. Os tipos envolvidos não se traduzem entre plataformas e só devem ser usados diretamente quando necessário.

* No macOS, antes do .NET 10, ECDsaOpenSsl funcionava se o OpenSSL estava instalado e um dylib libcrypto apropriado poderia ser encontrado por meio do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

ECDH

A geração de chave ECDH (Diffie-Hellman de curva elíptica) é feita pelas bibliotecas do SO e está sujeita às respectivas limitações de tamanho e características de desempenho.

A classe ECDiffieHellman dá suporte ao valor "bruto" da computação ECDH, bem como por meio das seguintes funções de derivação de chave:

• HASH(Z)
• HASH(prepend || Z || acréscimo)
• HMAC(key, Z)
• HMAC(key, prepend || Z || acréscimo)
• HMAC(Z, Z)
• HMAC(Z, prepend || Z || acréscimo)
• Tls11Prf(label, seed)

As curvas de chave ECDH são definidas pelas bibliotecas do sistema operacional e estão sujeitas às respectivas limitações.

¹ Nem todas as distribuições Linux têm suporte para as mesmas curvas nomeadas.

² O suporte para curvas nomeadas foi adicionado ao CNG do Windows no Windows 10. Para mais informações, confira Curvas elípticas nomeadas do CNG. As curvas nomeadas não estão disponíveis em versões anteriores do Windows, exceto por três curvas no Windows 7.

³ A exportação com parâmetros de curva explícitos exige suporte da biblioteca do SO, que não está disponível nas plataformas com suporte da Apple ou em versões anteriores do Windows.

⁴ O suporte do Android para algumas curvas depende da versão do Android. Os distribuidores do Android também podem optar por adicionar ou remover as curvas da sua build do Android.

Interoperabilidade nativa de ECDH

O .NET expõe tipos para permitir que programas interoperem com as bibliotecas do SO que o .NET usa. Os tipos envolvidos não se traduzem entre plataformas e só devem ser usados diretamente quando necessário.

* No macOS, antes do .NET 10, ECDiffieHellmanOpenSsl funcionava se o OpenSSL estava instalado e um dylib libcrypto apropriado poderia ser encontrado por meio do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

DSA

A geração de chaves DSA (Algoritmo de Assinatura Digital) é executada pelas bibliotecas do sistema e está sujeita às suas limitações de tamanho e características de desempenho.

* O macOS carrega chaves DSA maiores que 1024 bits, mas o comportamento dessas chaves é indefinido. Elas não se comportam de acordo com o FIPS 186-3.

DSA no Windows

• O CAPI (Windows CryptoAPI) é usado sempre que new DSACryptoServiceProvider() é usado.
• A CNG (API de Criptografia do Windows) é usada sempre que new DSACng() é usada.
• O objeto retornado por DSA.Create é alimentado internamente pela CNG do Windows. Esse uso do CNG do Windows é um detalhe de implementação e está sujeito a alterações.
• O método GetDSAPublicKey de extensão para X509Certificate2 retorna uma instância DSACng. Esse uso de DSACng é um detalhe de implementação e está sujeito a alterações.
• O método de extensão GetDSAPrivateKey para X509Certificate2 prefere uma instância DSACng, mas se DSACng não puder abrir a chave, DSACryptoServiceProvider será tentado. O provedor preferencial é um detalhe de implementação e está sujeito a alterações.

Interoperabilidade nativa de DSA

O .NET expõe tipos para permitir que programas interoperem com as bibliotecas do sistema operacional que o código de criptografia .NET usa. Os tipos envolvidos não se traduzem entre plataformas e só devem ser usados diretamente quando necessário.

¹ Em sistemas não Windows, DSACryptoServiceProvider pode ser utilizado para compatibilidade com programas existentes. Nesse caso, qualquer método que exija interoperabilidade do sistema, como abrir uma chave nomeada, gerará um PlatformNotSupportedException.

² No macOS, antes do .NET 10, DSAOpenSsl funcionava se o OpenSSL estava instalado e um dylib libcrypto apropriado poderia ser encontrado por meio do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

Criptografia pós-quântica

Algoritmos pós-quânticos estão disponíveis a partir do .NET 10. Eles também estão disponíveis para o .NET Framework usando o pacote NuGet Microsoft.Bcl.Cryptography. A tabela de suporte a seguir indica o suporte da plataforma para os componentes criptográficos internos do sistema operacional, como aqueles criados de Generate ou ImportFromPem. Implementações que derivam da classe base podem ter comportamentos de suporte diferentes.

Para os algoritmos internos, uma IsSupported propriedade estática está disponível para determinar se a plataforma dá suporte a qualquer um dos conjuntos de parâmetros.

Os tipos de interoperabilidade nativos para algoritmos pós-quânticos não dão suporte à geração ou importação de chaves. Eles existem especificamente para cenários de interoperabilidade com os tipos de plataforma nativos, como um EVP_PKEY no OpenSSL ou CngKey no Windows.

ML-KEM

Interoperabilidade nativa ML-KEM

• MLKemOpenSsl: OpenSSL 3.5.0+
• MLKemCng: Windows 11 Insiders (mais recente)

ML-DSA

ML-DSA tem uma variante pura e pré-hash (HashML-DSA). A tabela a seguir reflete tanto as variantes puras quanto as de pré-hash.

¹ O suporte externo a Mu é somente para assinatura e verificação de Mu. Não há suporte para a computação do Mu.

ML-DSA de interoperabilidade nativa

• MLDsaOpenSsl: OpenSSL 3.5.0+
• MLDsaCng: Windows 11 Insiders (mais recente)

SLH-DSA

SLH-DSA tem uma variante pura e uma variante de pré-hash (HashSLH-DSA). A tabela a seguir reflete as variantes pura e de pré-hash.

Interoperabilidade nativa SLH-DSA

• SlhDsaOpenSsl: OpenSSL 3.5.0+
• SlhDsaCng: sem suporte

ML-DSA de composição

Composição de interoperabilidade nativa ML-DSA

• CompositeMLDsaCng: sem suporte

Certificados X.509

A maioria do suporte para certificados X.509 no .NET vem de bibliotecas do SO. Para carregar um certificado em uma instância X509Certificate2 ou X509Certificate no .NET, o certificado deve ser carregado pela biblioteca do sistema operacional subjacente.

Ler um PKCS12/PFX

Gravar um PKCS12/PFX

O macOS não pode carregar chaves privadas de certificado sem um objeto de conjunto de chaves, o que requer gravação em disco. Os keychains são criados automaticamente para carregamento PFX e são excluídos quando não estão mais em uso. Como a opção X509KeyStorageFlags.EphemeralKeySet significa que a chave privada não deve ser gravada no disco, afirmar que o sinalizador no macOS resulta em um PlatformNotSupportedException.

Gravar uma coleção de certificados PKCS7

O Windows e o Linux emitem blobs PKCS7 codificados em DER. O macOS emite blobs PKCS7 codificados por CER indefinidos.

X509Store

No Windows, a classe X509Store é uma representação das APIs do Repositório de Certificados do Windows. Essas APIs funcionam da mesma forma no .NET Core e no .NET 5 que no .NET Framework.

Em sistemas não Windows, a classe X509Store é uma projeção das decisões de confiança do sistema (somente leitura), das decisões de confiança do usuário (leitura/gravação) e do armazenamento de chaves do usuário (leitura/gravação).

As tabelas a seguir mostram quais cenários têm suporte em cada plataforma. Para cenários sem suporte (❌ nas tabelas), um CryptographicException é gerado.

A minha loja

No Linux, as lojas são criadas na primeira gravação e nenhum armazenamento de usuário existe por padrão, portanto, abrir CurrentUser\My com ExistingOnly pode falhar.

No macOS, o repositório CurrentUser\My é o conjunto de chaves padrão do usuário, que é login.keychain por padrão. O repositório LocalMachine\My é System.keychain.

O repositório Raiz

No Linux, o repositório LocalMachine\Root é uma interpretação do pacote de AC no caminho padrão para OpenSSL.

No macOS, o repositório CurrentUser\Root é uma interpretação dos resultados SecTrustSettings do domínio de confiança do usuário. O repositório LocalMachine\Root é uma interpretação dos resultados SecTrustSettings para os domínios de confiança do administrador e do sistema.

O repositório intermediário

No Linux, o repositório CurrentUser\Intermediate é usado como um cache ao baixar CAs intermediárias por seus registros de acesso às informações da autoridade em builds X509Chain bem-sucedidos. O repositório LocalMachine\Intermediate é uma interpretação do pacote de AC no caminho padrão para OpenSSL.

No macOS, o repositório CurrentUser\Intermediate é tratado como um repositório personalizado. Os certificados adicionados a esse repositório não afetam a compilação de cadeias X.509.

O repositório não permitido

No Linux, o repositório Disallowed não é usado na criação de cadeias e tentar adicionar conteúdo a ele resulta em um CryptographicException. Um CryptographicException será gerado ao abrir o repositório Disallowed se ele já tiver adquirido conteúdo.

No macOS, os repositórios CurrentUser\Disallowed e LocalMachine\Disallowed são interpretações dos resultados apropriados do SecTrustSettings para certificados cuja confiança está definida como Always Deny.

Repositório inexistente

No macOS, há suporte para a criação de repositório personalizado com a API X509Store apenas para o local CurrentUser. Ele criará um conjunto de chaves sem senha no diretório do conjunto de chaves do usuário (~/Library/Keychains). Para criar um conjunto de chaves com senha, um P/Invoke a SecKeychainCreate pode ser usado. Da mesma forma, SecKeychainOpen pode ser usado para abrir conjuntos de chaves em locais diferentes. O resultado IntPtr pode ser passado para new X509Store(IntPtr) para obter um repositório com capacidade de leitura/gravação, sujeito às permissões do usuário atual.

X509Chain

O macOS não dá suporte à utilização de CRL offline, portanto, X509RevocationMode.Offline é tratado como X509RevocationMode.Online.

O macOS não dá suporte a um tempo limite iniciado pelo usuário na CRL (Lista de Certificados Revogados)/OCSP (Protocolo de Status de Certificado Online)/AIA (acesso às informações da autoridade) baixando, portanto, X509ChainPolicy.UrlRetrievalTimeout é ignorado.

Certificados de criptografia pós-quantum e PKCS12/PFX

O suporte a certificado pós-quântico também requer suporte do algoritmo primitivo.

Recursos adicionais

• Modelo de criptografia .NET
• Serviços criptográficos do .NET
• Vulnerabilidades de temporização com descriptografia simétrica no modo CBC usando preenchimento
• Proteção de dados ASP.NET Core