Compartilhar via

Recomendações criptográficas do Microsoft SDL

Use essas informações como referência ao criar produtos para usar as mesmas APIs, algoritmos, protocolos e comprimentos de chave que a Microsoft exige de seus próprios produtos e serviços. Grande parte do conteúdo se baseia nos próprios padrões de segurança interna da Microsoft usados para criar o Ciclo de Vida de Desenvolvimento de Segurança.

Os desenvolvedores em plataformas que não são do Windows podem se beneficiar dessas recomendações. Embora os nomes de API e biblioteca possam ser diferentes, as práticas recomendadas que envolvem a escolha do algoritmo, o comprimento da chave e a proteção de dados são semelhantes entre plataformas.

Recomendações de protocolo de segurança, algoritmo e comprimento de chave

Versões do TLS/SSL

Produtos e serviços devem usar versões criptograficamente seguras do TLS/SSL:

  • O TLS 1.3 deve estar habilitado.
  • O TLS 1.2 pode ser habilitado para melhorar a compatibilidade com clientes mais antigos.
  • TLS 1.1, TLS 1.0, SSL 3 e SSL 2 devem estar desabilitados

Criptografias de bloco simétrico, modos de criptografia e vetores de inicialização

Bloquear criptografias

Para produtos que usam criptografias de bloco simétrico:

  • A AES (Advanced Encryption Standard) é recomendada.
  • Todas as outras criptografias de bloco, incluindo 3DES (Triplo DES/TDEA), e RC4 devem ser substituídas se usadas para criptografia.

Para algoritmos de criptografia de bloco simétrico, é necessário um comprimento mínimo de chave de 128 bits, mas recomendamos dar suporte a chaves de 256 bits. O único algoritmo de criptografia de bloco recomendado para o novo código é AES (AES-128, AES-192 e AES-256 são todos aceitáveis, observando que o AES-192 não tem otimização em alguns processadores).

Modos de criptografia

Algoritmos simétricos podem operar em vários modos, a maioria dos quais vinculam as operações de criptografia em blocos sucessivos de texto sem formatação e texto criptografado.

As criptografias de bloco simétrico devem ser usadas com um dos seguintes modos de criptografia:

Alguns outros modos de criptografia, como aqueles a seguir, têm armadilhas de implementação que os tornam mais propensos a serem usados incorretamente. Em particular, o modo de operação do ECB (Electronic Code Book) deve ser evitado. Reutilizar o mesmo vetor de inicialização (IV) com criptografias de bloco em "modos de criptografia de streaming", como CTR, pode fazer com que os dados criptografados sejam revelados. Uma revisão de segurança extra será recomendada se algum dos modos abaixo for usado:

  • OFB (comentário de saída)
  • CFB (comentário de criptografia)
  • CTR (contador)
  • Qualquer outra coisa que não está na lista "recomendada" anterior

Vetores de inicialização (IV)

Todas as criptografias de bloco simétrico também devem ser usadas com um número aleatório criptograficamente forte como um vetor de inicialização. Os vetores de inicialização nunca devem ser um valor constante ou predefinido. Consulte Geradores de Número Aleatório para obter recomendações sobre como gerar números aleatórios criptograficamente fortes.

Os vetores de inicialização nunca devem ser reutilizados ao executar várias operações de criptografia. A reutilização pode revelar informações sobre os dados que estão sendo criptografados, especialmente ao usar modos de criptografia de streaming, como OFB (Comentários de Saída) ou Contador (CTR).

Recomendações do AES-GCM & AES-CCM

AES-GCM (Modo Galois/Contador) e AES-CCM (Contador com CBC-MAC) são modos de criptografia autenticados amplamente usados. Eles combinam confidencialidade e proteção de integridade, tornando-os úteis para uma comunicação segura. No entanto, sua fragilidade está na reutilização do nonce. Quando o mesmo nonce (vetor de inicialização) é usado duas vezes, ele pode levar a consequências catastróficas.

É recomendável seguir as diretrizes de nonce, conforme descrito em NIST SP 800-38D, Recomendação para modos de criptografia de bloco de operação: GCM (Modo de Galois/Contador) e GMAC, com atenção especial para a seção 8.3 sobre o número máximo de invocações.

Outra opção seria gerar chaves AES-GCM/CCM exclusivas para cada mensagem que está sendo criptografada, limitando efetivamente o número máximo de invocações a 1. Essa abordagem é recomendada para criptografar dados em repouso, em que usar um contador ou verificar se você pode controlar o número máximo de invocações para uma determinada chave seria impraticável.

Para criptografar dados em repouso, você também pode considerar o uso de AES-CBC com um código de autenticação de mensagem (MAC) como alternativa, utilizando um esquema Encrypt-then-MAC, e certificando-se de usar chaves separadas para a criptografia e para o MAC.

Verificação de integridade

É um equívoco comum que a criptografia, por padrão, forneça confidencialidade e garantia de integridade. Muitos algoritmos de criptografia não fornecem nenhuma verificação de integridade e podem estar vulneráveis a ataques de adulteração. Etapas extras devem ser tomadas para garantir a integridade dos dados antes de enviar e depois de receber.

Se você não puder usar um algoritmo de criptografia autenticado com dados associados (AEAD), como a AES-GCM, uma alternativa seria validar a integridade com um MAC (código de autenticação de mensagem) usando um esquema Encrypt-then-MAC, certificando-se de usar chaves separadas para criptografia e para o MAC.

Usar uma chave separada para criptografia e para o MAC é essencial. Se não for possível armazenar as duas chaves, uma alternativa válida é derivar duas chaves da chave principal usando uma KDF (função de derivação de chave) adequada, uma para fins de criptografia e outra para MAC. Para obter mais informações, consulte SP 800-108 Rev. 1, Recomendação para derivação de chave usando funções pseudorandom | CSRC (nist.gov).

Algoritmos assimétricos, comprimentos de chave e modos de preenchimento

RSA

  • A RSA pode ser usada para criptografia, troca de chaves e assinaturas.
  • A criptografia RSA deve usar os modos de preenchimento OAEP ou RSA-PSS.
  • O código existente deve usar o modo de preenchimento PKCS #1 v1.5 somente para fins de compatibilidade.
  • O uso de preenchimento nulo não é recomendado.
  • É recomendável um comprimento mínimo de chave de 2048 bits, mas recomendamos dar suporte a um comprimento de chave de 3072 bits.

ECDSA e ECDH

  • A troca de chaves baseada em ECDH e as assinaturas baseadas em ECDSA devem usar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521).
  • O suporte para P-256 deve ser considerado o mínimo, mas recomendamos dar suporte a P-384.

Inteiro Diffie-Hellman

  • O comprimento da chave >= 2048 bits é recomendado0
  • Os parâmetros de grupo devem ser um grupo nomeado conhecido (por exemplo, RFC 7919) ou gerados por uma parte confiável e autenticados antes do uso.

Tempos de vida principais

  • Defina um período criptográfico para todas as chaves.
    • Por exemplo: uma chave simétrica para criptografia de dados, geralmente conhecida como chave de criptografia de dados ou DEK, pode ter um período de uso de até dois anos para criptografar dados, também conhecido como o período de uso do originador. Você pode definir que ele tem um período de uso válido para descriptografia por mais três anos, também conhecido como o período de uso do destinatário.
  • Você deve fornecer um mecanismo ou ter um processo para substituir chaves para atingir a vida útil limitada. Após o fim de seu tempo de vida ativo, uma chave não deve ser usada para produzir novos dados (por exemplo, para criptografia ou assinatura), mas ainda pode ser usada para ler dados (por exemplo, para descriptografia ou verificação).

Geradores de número aleatório

Todos os produtos e serviços devem usar geradores de número aleatório criptograficamente seguros quando a aleatoriedade for necessária.

CNG

Win32/64

  • O código herdado pode usar RtlGenRandom no modo kernel.
  • O novo código deve usar BCryptGenRandom ou CryptGenRandom.
  • A função C Rand_s() também é recomendada (que, no Windows, chama CryptGenRandom).
  • Rand_s() é uma substituição segura e com desempenho para Rand().
  • Rand() não deve ser usado para nenhum aplicativo criptográfico.

.NET

PowerShell

Aplicativos da Windows Store

Linux/macOS

  • O dispositivo /dev/urandom fornece uma fonte criptograficamente forte de dados aleatórios, assim como a chamada do sistema getrandom(2).

Bibliotecas de criptografia compatíveis com a plataforma Windows

Na plataforma Windows, a Microsoft recomenda usar as APIs de criptografia internas no sistema operacional. Em outras plataformas, os desenvolvedores podem escolher avaliar bibliotecas de criptografia fora da plataforma para uso. Em geral, as bibliotecas de criptografia de plataforma são atualizadas com mais frequência, pois são enviadas como parte de um sistema operacional em vez de serem agrupadas com um aplicativo.

Qualquer decisão de uso em relação à plataforma versus a criptografia nãoplataforma deve ser orientada pelos seguintes requisitos:

  • A biblioteca deve ser uma versão atual em suporte livre de vulnerabilidades de segurança conhecidas.
  • Os protocolos de segurança, algoritmos e comprimentos de chave mais recentes devem ter suporte.
  • (Opcional) A biblioteca deve ser capaz de dar suporte apenas a protocolos/algoritmos de segurança mais antigos para compatibilidade com versões anteriores.

Código nativo

  • Primitivos de criptografia: se a versão estiver no Windows, use a CNG, se possível.
  • Verificação de assinatura de código: WinVerifyTrust é a API com suporte para verificar assinaturas de código em plataformas Windows.
  • Validação de certificado (como usado na validação de certificado restrito para assinatura de código ou SSL/TLS/DTLS): API CAPI2; por exemplo, CertGetCertificateChain e CertVerifyCertificateChainPolicy.

Código gerenciado (.NET)

Funções de derivação de chave

Derivação de chave é o processo de derivação de material de chave criptográfica de um segredo compartilhado ou de uma chave criptográfica existente. Os produtos devem usar funções de derivação de chave recomendadas. Derivar chaves de senhas escolhidas pelo usuário ou senhas de hash para armazenamento em um sistema de autenticação é um caso especial não coberto por essas diretrizes; os desenvolvedores devem consultar um especialista.

Os seguintes padrões especificam funções KDF recomendadas para uso:

  • NIST SP 800-108 (Revisão 1): Recomendação para derivação de chave usando funções pseudorandom. Em particular, o KDF no modo de contador, com HMAC como função pseudoaleatória
  • NIST SP 800-56A (revisão 3): recomendação para esquemas de estabelecimento de chave em pares usando criptografia de logaritmo discreto.

Para derivar chaves de chaves existentes, use a API BCryptKeyDerivation com um dos algoritmos:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM
  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Para derivar chaves de um segredo compartilhado (a saída de um acordo de chave), use a API BCryptDeriveKey com um dos seguintes algoritmos:

  • BCRYPT_KDF_SP80056A_CONCAT
  • BCRYPT_KDF_HMAC

Validação de certificado

Os produtos que usam TLS ou DTLS devem verificar completamente os certificados X.509 das entidades às quais se conectam. Esse processo inclui a verificação das seguintes partes do certificado:

  • Nome de domínio.
  • Datas de validade (datas de início e de término).
  • Status de revogação.
  • Uso (por exemplo, "Autenticação de Servidor" para servidores, "Autenticação de Cliente" para clientes).
  • Cadeia de confiança. Os certificados devem estar vinculados a uma AC (autoridade de certificação) raiz de confiança da plataforma ou ser configurados explicitamente pelo administrador.

Se algum desses testes de verificação falhar, o produto deverá encerrar a conexão com a entidade.

Não use certificados "autoassinados". Certificados autoassinados não transmitem inerentemente confiança, nem suportam a revogação, nem a renovação de chave.

Funções de hash criptográficas

Os produtos devem usar a família SHA-2 de algoritmos de hash (SHA-256, SHA-384 e SHA-512). O truncamento de hashes criptográficos para fins de segurança com menos de 128 bits não é permitido. Embora o uso do SHA-256 seja o mínimo, recomendamos dar suporte ao SHA-384.

Algoritmos de hash com chave/MAC/HMAC

Um MAC (código de autenticação de mensagem) é uma parte das informações anexadas a uma mensagem que permite ao destinatário verificar a autenticidade do remetente e a integridade da mensagem usando uma chave secreta.

O uso de um MAC baseado em hash (HMAC) ou de um MAC baseado em cifra de bloco é recomendado, desde que todos os algoritmos de hash ou criptografia simétrica subjacentes também sejam recomendados para uso. Atualmente, isso inclui as funções HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512). Embora o uso de HMAC-SHA256 seja o mínimo, recomendamos dar suporte ao HMAC-SHA384.

O truncamento de HMACs para menos de 128 bits não é recomendado.

Considerações de design e operacionais

  • Você deve fornecer um mecanismo para substituir chaves criptográficas conforme necessário. As chaves devem ser substituídas quando chegarem ao final do tempo de vida ativo ou a chave criptográfica estiver comprometida.
    • Sempre que você renovar um certificado, deverá renová-lo com uma nova chave.
  • Os produtos que usam algoritmos criptográficos para proteger dados devem incluir metadados suficientes junto com esse conteúdo para dar suporte à migração para algoritmos diferentes no futuro. Estes metadados devem incluir o algoritmo usado, tamanhos de chave e modos de preenchimento.
    • Para obter mais informações sobre agilidade criptográfica, consulte o artigo de Agilidade Criptográfica.
  • Quando disponíveis, os produtos devem usar protocolos criptográficos estabelecidos fornecidos pela plataforma em vez de reimplementá-los, incluindo formatos de assinatura (por exemplo, usar um formato padrão e existente).
  • Não relate falhas de operação criptográfica aos usuários finais. Ao retornar um erro a um chamador remoto (por exemplo, cliente Web ou cliente em um cenário cliente-servidor), use apenas uma mensagem de erro genérica.
    • Evite fornecer informações desnecessárias, como informar diretamente erros de comprimento inválido ou fora do intervalo. Registre os erros detalhados somente no servidor e somente se o log detalhado estiver habilitado.
  • A revisão de segurança extra é altamente recomendada para qualquer design que incorpore os seguintes itens:
    • Um novo protocolo que se concentra principalmente na segurança (como um protocolo de autenticação ou autorização)
    • Um novo protocolo que usa criptografia de forma nova ou não padrão. As considerações de exemplo incluem:
      • Um produto que implementa o protocolo chamará as APIs ou métodos de criptografia como parte da implementação do protocolo?
      • O protocolo depende de qualquer outro protocolo usado para autenticação ou autorização?
      • O protocolo definirá formatos de armazenamento para elementos criptográficos, como chaves?
  • Certificados autoassinados não são recomendados. O uso de um certificado autoassinado, como o uso de uma chave criptográfica bruta, não fornece inerentemente aos usuários ou administradores qualquer base para tomar uma decisão de confiança.
    • Por outro lado, o uso de um certificado com raiz em uma autoridade de certificação confiável deixa clara a base para depender da chave privada associada e habilita a revogação e atualizações se houver uma falha de segurança.