Criptografia entre plataformas no .NET

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

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

A dependência das bibliotecas do sistema operacional também significa que os aplicativos .NET só podem usar recursos criptográficos suportados pelo sistema operacional. Embora todas as plataformas ofereçam suporte a determinados recursos principais, alguns recursos suportados pelo .NET não podem ser usados em algumas plataformas. Este artigo identifica os recursos suportados em cada plataforma.

Este artigo pressupõe que você tenha uma familiaridade de trabalho com criptografia no .NET. Para obter mais informações, consulte .NET Cryptography Model e .NET Cryptographic Services.

Algoritmos de autenticação de hash e mensagem

Todos os algoritmos de hash e classes de autenticação de mensagem baseada em hash (HMAC), incluindo as *Managed classes, adiam para as bibliotecas do sistema operacional, com exceção do .NET no Browser WASM. 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 de streaming (XOF) está disponível a partir do .NET 9. No Linux, isso requer OpenSSL 3.3.

Encriptação simétrica

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

Encriptação autenticada

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

Como a criptografia autenticada requer APIs de plataforma mais recentes para suportar o algoritmo, o suporte pode não estar presente em todas as plataformas. A IsSupported propriedade static nas classes para o algoritmo pode ser usada para detetar em tempo de execução se a plataforma atual suporta o algoritmo ou não.

AES-CCM no macOS

Antes do .NET 10, AES-CCM funcionava se uma versão suportada do OpenSSL estivesse presente e o carregador de biblioteca dinâmica pudesse localizá-lo. O suporte a 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 tags AES-CCM

• Tamanhos das chaves

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

• Tamanhos Nonce

  A AesCcm classe suporta nonces de 56, 64, 72, 80, 88, 96 e 104 bits (7, 8, 9, 10, 11, 12 e 13 bytes).

• Tamanhos de tags

  A AesCcm classe suporta a criação ou processamento de tags de 32, 48, 64, 80, 96, 112 e 128 bits (4, 8, 10, 12, 14 e 16 bytes).

Chaves, nonces e tags AES-GCM

• Tamanhos das chaves

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

• Tamanhos Nonce

  A AesGcm classe suporta apenas nonces de 96 bits (12 bytes).

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

ChaCha20Poly1305 chaves, nonces e tags.

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

Criptografia assimétrica

Esta secção inclui as seguintes subsecções:

• ASR
• ECDSA
• ECDH
• DSA

RSA

A geração de chaves RSA (Rivest–Shamir–Adleman) é realizada 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 realizadas pelas bibliotecas do sistema operacional, e os tipos de chave que podem ser carregados estão sujeitos aos requisitos do sistema operacional.

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

O suporte a preenchimento e resumo varia de acordo com a plataforma:

1 Windows CryptoAPI (CAPI) é capaz de assinatura PKCS1 com um algoritmo SHA-2. Mas o objeto RSA individual pode ser carregado em um provedor de serviços de criptografia (CSP) que não oferece suporte a ele.

RSA no Windows

• Windows CryptoAPI (CAPI) é usado sempre que new RSACryptoServiceProvider() é usado.
• A API de Criptografia do Windows Next Generation (CNG) é usada sempre que new RSACng() é usada.
• O objeto retornado por RSA.Create é alimentado internamente pelo Windows CNG. Este uso do Windows CNG é um detalhe de implementação e está sujeito a alterações.
• O GetRSAPublicKey método de extensão para X509Certificate2 retorna uma RSACng instância. Este uso de é um detalhe de RSACng implementação e está sujeito a alterações.
• O GetRSAPrivateKey método de extensão para X509Certificate2 atualmente prefere uma RSACng instância, 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 RSA

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

1 Em não-Windows, RSACryptoServiceProvider pode ser usado para compatibilidade com programas existentes. Nesse caso, qualquer método que exija interoperabilidade do sistema operacional, como abrir uma chave nomeada, lança um PlatformNotSupportedExceptionarquivo .

² No macOS, antes do .NET 10, RSAOpenSsl funcionava se o OpenSSL estivesse instalado e um dylib libcrypto apropriado pudesse ser encontrado através do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

ECDSA

A geração de chaves ECDSA (Elliptic Curve Digital Signature Algorithm) é feita pelas bibliotecas do sistema operacional e está sujeita às suas limitações de tamanho e características de desempenho.

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

1 As distribuições Linux não têm suporte para as mesmas curvas nomeadas.

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

3 A exportação com parâmetros de curva explícitos requer suporte à biblioteca do sistema operacional, que não está disponível em plataformas Apple ou versões anteriores do Windows.

4 O suporte Android para algumas curvas depende da versão Android. Os distribuidores Android também podem optar por adicionar ou remover curvas da sua compilação Android.

Interoperabilidade Nativa ECDSA

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

* No macOS, antes do .NET 10, ECDsaOpenSsl funcionava se o OpenSSL estivesse instalado e um dylib libcrypto apropriado pudesse ser encontrado através do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

ECDH

A geração de chaves ECDH (Elliptic Curve Diffie-Hellman) é feita pelas bibliotecas do sistema operacional e está sujeita às suas limitações de tamanho e características de desempenho.

A ECDiffieHellman classe suporta o valor "bruto" da computação ECDH, bem como através das seguintes funções de derivação chave:

• HASH(Z)
• HASH(prepend || Z || Anexar)
• HMAC (chave, Z)
• HMAC(chave, prepend || Z || Anexar)
• HMAC (Z, Z)
• HMAC(Z, pendente || Z || Anexar)
• Tls11Prf (rótulo, semente)

As curvas de teclas ECDH são definidas pelas bibliotecas do SO e estão sujeitas às suas limitações.

1 As distribuições Linux não têm suporte para as mesmas curvas nomeadas.

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

3 A exportação com parâmetros de curva explícitos requer suporte à biblioteca do sistema operacional, que não está disponível em plataformas Apple ou versões anteriores do Windows.

4 O suporte Android para algumas curvas depende da versão Android. Os distribuidores Android também podem optar por adicionar ou remover curvas da sua compilação Android.

Interoperabilidade nativa do ECDH

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

* No macOS, antes do .NET 10, ECDiffieHellmanOpenSsl funcionava se o OpenSSL estivesse instalado e um dylib libcrypto apropriado pudesse ser encontrado através do carregamento dinâmico da biblioteca. Esse suporte foi removido no .NET 10.

DSA

A geração de chaves DSA (Digital Signature Algorithm) é realizada 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. Eles não se comportam de acordo com o FIPS 186-3.

DSA no Windows

• Windows CryptoAPI (CAPI) é usado sempre que new DSACryptoServiceProvider() é usado.
• A API de Criptografia do Windows Next Generation (CNG) é usada sempre que new DSACng() é usada.
• O objeto retornado por DSA.Create é alimentado internamente pelo Windows CNG. Este uso do Windows CNG é um detalhe de implementação e está sujeito a alterações.
• O GetDSAPublicKey método de extensão para X509Certificate2 retorna uma DSACng instância. Este uso de é um detalhe de DSACng implementação e está sujeito a alterações.
• O GetDSAPrivateKey método de extensão para X509Certificate2 prefere uma DSACng instância, 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 do DSA

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

1 Em não-Windows, DSACryptoServiceProvider pode ser usado para compatibilidade com programas existentes. Nesse caso, qualquer método que exija interoperabilidade do sistema, como abrir uma chave nomeada, lança um PlatformNotSupportedExceptionarquivo .

² No macOS, antes do .NET 10, DSAOpenSsl funcionava se o OpenSSL estivesse instalado e um dylib libcrypto apropriado pudesse ser encontrado através 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 a partir de Generate ou ImportFromPem. As 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 suporta qualquer um dos conjuntos de parâmetros.

Os tipos de interoperabilidade nativos para algoritmos pós-quânticos não suportam geração ou importação de chaves. Eles existem especificamente para cenários de interoperabilidade com os tipos de plataforma nativa, 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é-hashizada (HashML-DSA). A tabela a seguir reflete ambas as variantes pura e pré-hash.

¹ O suporte externo de Mu destina-se apenas a assinar e verificar Mu. A computação de Mu não é suportada.

Interoperabilidade nativa ML-DSA

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

SLH-DSA

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

Interoperabilidade nativa SLH-DSA

• SlhDsaOpenSsl: OpenSSL 3.5.0+
• SlhDsaCng: Não suportado

Composto ML-DSA

Composto de interoperabilidade nativa ML-DSA

• CompositeMLDsaCng: Não suportado

Certificados X.509

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

Ler uma PKCS12/PFX

Escrever um PKCS12/PFX

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

Escrever uma coleção de certificados PKCS7

Windows e Linux emitem blobs PKCS7 codificados por DER. O macOS emite blobs PKCS7 codificados em CER de comprimento indefinido.

Loja X509

No Windows, a X509Store classe é 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 não-Windows, a X509Store classe é uma projeção de decisões de confiança do sistema (somente leitura), decisões de confiança do usuário (leitura-gravação) e armazenamento de chave do usuário (leitura-gravação).

As tabelas a seguir mostram quais cenários são suportados em cada plataforma. Para cenários sem suporte (❌ nas tabelas), um CryptographicException é lançado.

A minha loja

No Linux, as lojas são criadas na primeira gravação e não existem repositórios de usuários por padrão, portanto, abrir CurrentUser\My com ExistingOnly pode falhar.

No macOS, a CurrentUser\My loja é o porta-chaves padrão do usuário, que é login.keychain por padrão. A LocalMachine\My loja é System.keychain.

O repositório raiz

No Linux, a LocalMachine\Root loja é uma interpretação do pacote CA no caminho padrão para OpenSSL.

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

A loja intermediária

No Linux, a CurrentUser\Intermediate loja é usada como um cache ao baixar CAs intermediárias por seus registros de acesso a informações de autoridade em compilações X509Chain bem-sucedidas. O LocalMachine\Intermediate repositório é uma interpretação do pacote CA no caminho padrão para OpenSSL.

No macOS, a CurrentUser\Intermediate loja é tratada como uma loja personalizada. Os certificados adicionados a este repositório não afetam a construção da cadeia X.509.

A loja não permitida

No Linux, a Disallowed loja não é usada na construção de cadeias, e tentar adicionar conteúdo a ela resulta em um CryptographicExceptionarquivo . A CryptographicException é lançado ao abrir a Disallowed loja se já tiver adquirido conteúdos.

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

Loja inexistente

No macOS, a criação de lojas personalizadas com a API X509Store é suportada apenas para CurrentUser localização. Ele criará um novo porta-chaves sem senha no diretório de chaves do usuário (~/Library/Keychains). Para criar um porta-chaves com senha, um P/Invoke para SecKeychainCreate pode ser usado. Da mesma forma, SecKeychainOpen poderia ser usado para abrir chaveiros em diferentes locais. O resultado IntPtr pode ser passado para new X509Store(IntPtr) obter um armazenamento com capacidade de leitura/gravação, sujeito às permissões do usuário atual.

X509Cadeia

O macOS não suporta a utilização de CRL offline, por isso X509RevocationMode.Offline é tratado como X509RevocationMode.Online.

O macOS não suporta um tempo limite iniciado pelo usuário no download de CRL (Lista de Revogação de Certificados) / OCSP (Online Certificate Status Protocol) / AIA (Authority Information Access), portanto X509ChainPolicy.UrlRetrievalTimeout , é ignorado.

Certificados de criptografia pós-quântica e PKCS12/PFX

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

Recursos adicionais

• Modelo de criptografia .NET
• Serviços de criptografia .NET
• Vulnerabilidades de temporização com desencriptação simétrica no modo CBC usando preenchimento
• ASP.NET Proteção de dados principais