Recomendações criptográficas do Microsoft SDL

  • Artigo

Use essas informações como referência durante o desenvolvimento de 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 é baseado nos próprios padrões de segurança internos da Microsoft usados para criar o ciclo de vida do desenvolvimento de segurança.

Os desenvolvedores de outras plataformas que não Windows também podem se beneficiar dessas recomendações. Por mais que os nomes de API e das bibliotecas possam ser diferentes, as melhores práticas que envolvem a escolha de algoritmo, o comprimento da chave e a proteção de dados são semelhantes entre as plataformas.

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

Versões do TLS/SSL

Os 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

Codificações de bloco simétricas, modos de criptografia e vetores de inicialização

Codificações de bloco

Para os produtos que usam codificações de bloco simétricas:

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

Para algoritmos de criptografia de bloco simétrica, é preciso ter 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, com a ressalva de que o AES-192 não tem otimização em alguns processadores).

Modos de criptografia

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

As codificações de bloco simétrico devem ser usadas com um dos seguintes modos de criptografia:

Alguns outros modos de criptografia, como os indicados abaixo, têm armadilhas de implementação que aumentam a probabilidade de que sejam usados incorretamente. Deve ser evitado, em especial, o modo de ECB (livro de código eletrônico) da operação. Reutilizar o mesmo IV (vetor de inicialização) com codificações de bloco em "modos de criptografia de streaming" como CTR pode fazer com que dados criptografados sejam revelados. Recomenda-se uma revisão de segurança adicional caso qualquer um dos modos abaixo seja usado:

  • OFB (comentário de saída)
  • CFB (comentário de criptografia)
  • CTR (contador)
  • Qualquer outro ponto que não conste na lista "recomendada" acima

IV (vetores de inicialização)

Todas as codificações de bloco simétrico também devem ser usadas com um número aleatório criptograficamente forte como vetor de inicialização. Os vetores de inicialização nunca devem ser um valor constante ou previsível. Confira Geradores de números aleatórios para obter recomendações de 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 gerar 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 inativos, 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 inativos, você também pode considerar o uso do AES-CBC com um MAC (código de autenticação de mensagem) como alternativa usando um esquema “Criptografar depois MAC”, certificando-se de usar chaves separadas para 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. Medidas adicionais devem ser tomadas para garantir a integridade dos dados antes do envio e após o recebimento.

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 “Criptografar depois MAC”, certificando-se de usar chaves separadas para criptografia e para MAC.

O uso de uma chave separada para criptografia e para o MAC é essencial. Se não for possível armazenar as duas chaves, uma alternativa válida é a derivação de duas chaves da chave principal usando uma 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

  • O RSA pode ser usado para assinaturas, troca de chaves e criptografia.
  • 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

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

Inteiro Diffie-Hellman

  • Comprimento de chave >= 2.048 bits é recommended0
  • 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 da chave

  • 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 de substituição de chaves para atingir o tempo de vida ativo limitado. Após o término 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úmeros aleatórios

Todos os produtos e serviços deverão usar geradores de números aleatórios 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-se CryptGenRandom).
  • Rand_s() é uma substituição segura e de alto desempenho para Rand().
  • Rand() não deve ser usado para aplicativos criptográficos.

.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 com suporte na plataforma Windows

Na plataforma Windows, a Microsoft recomenda usar as APIs de criptografia internas do sistema operacional. Em outras plataformas, os desenvolvedores podem optar por avaliar o uso de bibliotecas de criptografia não pertencentes à plataforma. Em geral, as bibliotecas de criptografia de plataforma são atualizadas com mais frequência, uma vez que são fornecidas como parte de um sistema operacional, em vez de serem agrupadas com um aplicativo.

Qualquer decisão de uso relacionada à criptografia de plataforma vs. não plataforma deve ser guiada pelos seguintes requisitos:

  • A biblioteca deve ser uma versão atual com suporte, livre de vulnerabilidades conhecidas de segurança.
  • Os protocolos de segurança, os algoritmos e os comprimentos de chave mais recentes devem ter suporte.
  • (Opcional) A biblioteca deve ser capaz de dar suporte a protocolos/algoritmos de segurança mais antigos apenas 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 (conforme usada 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)

  • Primitivos de criptografia: use a API definida no namespace System.Security.Cryptography.
  • Usar a versão mais recente do .NET disponível.

Funções de derivação de chave

A derivação de chave é o processo de derivar material de chave de criptografia de um segredo compartilhado ou de uma chave de criptografia 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 padrões a seguir especificam as funções KDF recomendadas para uso:

  • NIST SP 800-108 (Revisão 1): recomendação para derivação de chave usando funções pseudoaleatórias. 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 do certificado

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

  • Nome de domínio.
  • Datas de validade (datas de início e de validade).
  • 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 qualquer um desses testes de verificação falhar, o produto deverá encerrar a conexão com a entidade.

Não use certificados "autoassinados". Os certificados autoassinados não transmitem inerentemente a confiança e não dão suporte a revogação nem a renovação de chave.

Funções de hash criptográfico

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

Algoritmos de hash com chave/MAC/HMAC

Um código de autenticação de mensagem (MAC) é um trecho de informação anexado 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 criptografia de bloco é recomendado, desde que todos os hashes subjacentes ou algoritmos de criptografia simétrica 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 mínimo, recomendamos dar suporte ao HMAC-SHA384.

Não recomendamos truncar HMACs para menos de 128 bits.

Considerações sobre design e operações

  • Você deve fornecer um mecanismo para substituir as chaves de criptografia conforme necessário. As chaves deverão ser substituídas depois que atingirem o término do tempo de vida ativo ou se a chave de criptografia for comprometida.
    • Sempre que você renovar um certificado, faça isso com uma nova chave.
  • Os produtos que usam algoritmos de criptografia para proteger os dados devem incluir metadados suficientes juntamente com esse conteúdo a fim de dar suporte à migração para diferentes algoritmos no futuro. Estes metadados devem incluir o algoritmo usado, tamanhos de chave e modos de preenchimento.
  • Quando disponível, os produtos devem usar protocolos de criptografia estabelecidos e 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 para os usuários finais. Ao retornar um erro para 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.
  • Uma revisão de segurança adicional é altamente recomendável 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 a criptografia em uma forma nova ou não padrão. As considerações de exemplo incluem:
      • Um produto que implementa o protocolo chamará alguma API ou método de criptografia como parte da implementação do protocolo?
      • O protocolo depende de algum 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 de criptografia bruta, não fornece inerentemente aos usuários ou administradores nenhuma 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 esclarece a base para depender da chave privada associada e permite a revogação e atualizações se houver uma falha de segurança.