Partilhar via

Recomendações criptográficas do Microsoft SDL

  • Artigo

Use essas informações como referência ao projetar 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 internos de segurança da Microsoft usados para criar o Ciclo de Vida de Desenvolvimento de Segurança.

Os programadores em plataformas que não sejam Windows podem beneficiar destas recomendações. Embora os nomes da API e da 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 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 ativado para melhorar a compatibilidade com clientes mais antigos.
  • TLS 1.1, TLS 1.0, SSL 3 e SSL 2 devem ser desativados

Cifras de bloco simétrico, modos de codificação e vetores de inicialização

Cifras de bloco

Para produtos que utilizam cifras de bloco simétrico:

  • Recomenda-se AES (Advanced Encryption Standard).
  • Todas as outras cifras de bloco, incluindo 3DES (Triple DES/TDEA) e RC4 devem ser substituídas se usadas para criptografia.

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

Modos de codificação

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

As cifras de bloco simétrico devem ser usadas com um dos seguintes modos de codificação:

Alguns outros modos de cifra, como os que se seguem, têm armadilhas de implementação que os tornam mais propensos a serem usados incorretamente. Em especial, deve ser evitado o modo de funcionamento do Livro Eletrónico de Códigos (Electronic Code Book – ECB). Reutilizar o mesmo vetor de inicialização (IV) com cifras de bloco em "modos de codificação de streaming", como CTR, pode fazer com que dados criptografados sejam revelados. Recomenda-se uma revisão de segurança extra se qualquer um dos modos abaixo for usado:

  • Feedback de saída (OFB)
  • Feedback de cifra (CFB)
  • Contador (CTR)
  • Qualquer outra coisa que não esteja na lista "recomendada" anterior

Vetores de inicialização (IV)

Todas as cifras 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 predicável. Consulte Geradores de números aleatórios 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, particularmente ao usar modos de codificação de streaming, como Feedback de Saída (OFB) ou Contador (CTR).

Recomendações AES-GCM & AES-CCM

AES-GCM (Galois/Counter Mode) e AES-CCM (Counter with CBC-MAC) são modos de encriptação autenticados amplamente utilizados. Combinam confidencialidade e proteção da integridade, tornando-os úteis para uma comunicação segura. No entanto, a sua fragilidade reside na reutilização do nonce. Quando o mesmo nonce (vetor de inicialização) é usado duas vezes, pode levar a consequências catastróficas.

Recomendamos seguir as diretrizes do nonce conforme descrito no NIST SP 800-38D, Recomendação para Modos de Operação de Cifra de Bloco: Modo Galois/Contador (GCM) e GMAC, tendo especial atenção à seção 8.3 em relação ao número máximo de invocações.

Outra opção seria gerar chaves AES-GCM/CCM exclusivas para cada mensagem sendo criptografada, efetivamente limitando o número máximo de invocações a 1. Essa abordagem é recomendada para criptografar dados em repouso, onde usar um contador ou certificar-se de que você pode rastrear 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 uma alternativa usando um esquema Encrypt-then-MAC, certificando-se de usar chaves separadas para criptografia e para o MAC.

Verificação da integridade

É um equívoco comum pensar que a criptografia por padrão fornece garantia de confidencialidade e integridade. Muitos algoritmos de encriptação não fornecem qualquer verificação de integridade e podem estar vulneráveis a ataques de adulteração. Devem ser tomadas medidas adicionais para garantir a integridade dos dados antes do envio e após a receção.

Se você não pode usar um algoritmo de criptografia autenticado com dados associados (AEAD), como AES-GCM, uma alternativa seria validar a integridade com um código de autenticação de mensagem (MAC) 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 função de derivação de chave adequada (KDF), 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 pseudoaleatórias | CSRC (nist.gov).

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

RSA

  • O RSA pode ser usado para criptografia, troca de chaves e assinaturas.
  • A encriptação RSA deve utilizar os modos de preenchimento OAEP ou RSA-PSS.
  • O código existente deve usar o modo de preenchimento PKCS #1 v1.5 apenas para compatibilidade.
  • O uso de preenchimento nulo não é recomendado.
  • Recomenda-se um comprimento mínimo de chave de 2048 bits, mas recomendamos o 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 o suporte para P-384.

Inteiro Diffie-Hellman

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

Tempos de vida das chaves

  • Defina um criptoperíodo para todas as chaves.
    • Por exemplo: uma chave simétrica para criptografia de dados, muitas vezes referida 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 período de uso do originador. Pode definir que tem um período de utilização válido para desencriptação por mais três anos, também conhecido como período de utilização do destinatário.
  • Você deve fornecer um mecanismo ou ter um processo para substituir chaves para alcançar o tempo de vida ativo limitado. Após o fim de sua vida útil, 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 devem usar geradores de números aleatórios criptograficamente seguros quando a aleatoriedade é necessária.

GNV

Win32/64

  • O código herdado pode usar RtlGenRandom no modo kernel.
  • Novo código deve usar BCryptGenRandom ou CryptGenRandom.
  • A função C Rand_s() também é recomendada (que no Windows, chama CryptGenRandom).
  • Rand_s() é um substituto seguro e eficiente para Rand().
  • Rand() não deve ser usado para quaisquer aplicações criptográficas.

.NET

PowerShell

Aplicações da Loja Windows

Linux/macOS

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

Bibliotecas de criptografia suportadas pela plataforma Windows

Na plataforma Windows, a Microsoft recomenda o uso das APIs de criptografia incorporadas ao sistema operacional. Em outras plataformas, os desenvolvedores podem optar por avaliar bibliotecas de criptografia não relacionadas à plataforma para uso. Em geral, as bibliotecas de criptografia da plataforma são atualizadas com mais frequência, pois são fornecidas como parte de um sistema operacional, em vez de serem empacotadas com um aplicativo.

Qualquer decisão de uso em relação à criptomoeda plataforma vs não plataforma deve ser guiada pelos seguintes requisitos:

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

Código nativo

  • Crypto Primitives: Se a sua versão estiver no Windows, use CNG, se possível.
  • Verificação de assinatura de código: WinVerifyTrust é a API suportada 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)

Principais funções de derivação

A derivação de chave é o processo de derivar 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. A derivação de chaves a partir de palavras-passe escolhidas pelo utilizador ou palavras-passe de hashing para armazenamento num sistema de autenticação é um caso especial não abrangido por esta orientação; os programadores devem consultar um especialista.

As seguintes normas especificam as funções KDF recomendadas para utilização:

  • NIST SP 800-108 (Revisão 1): Recomendação para derivação de chave usando funções pseudoaleatórias. Em particular, o KDF em modo contador, com HMAC como uma função pseudoaleatória
  • NIST SP 800-56A (Revisão 3): Recomendação para esquemas de estabelecimento de chaves 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 contrato 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 devem verificar completamente os certificados X.509 das entidades às quais se conectam. Este processo inclui a verificação das seguintes partes do certificado:

  • Nome de domínio.
  • Datas de validade (datas de início e de validade).
  • Estado 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 ser encadeados a uma autoridade de certificação (CA) raiz confiável pela plataforma ou explicitamente configurada pelo administrador.

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

Não use certificados "autoassinados". A assinatura própria não transmite inerentemente confiança, revogação de suporte ou renovação de chave de suporte.

Funções hash criptográficas

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

Algoritmos hash codificados/HMAC/MAC

Um código de autenticação de mensagem (MAC) é uma informação anexada a uma mensagem que permite ao seu 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 MAC baseado em cifra de bloco é recomendado, desde que todos os algoritmos de criptografia simétrica ou hash 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 do HMAC-SHA256 seja o mínimo, recomendamos o suporte ao HMAC-SHA384.

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

Considerações operacionais e de design

  • Você deve fornecer um mecanismo para substituir chaves criptográficas conforme necessário. As chaves devem ser substituídas assim que chegarem ao fim do seu tempo de vida ativo ou a chave criptográfica estiver comprometida.
    • Sempre que renovar um certificado, deve renová-lo com uma nova chave.
  • Os produtos que utilizam algoritmos criptográficos para proteger os dados devem incluir metadados suficientes, juntamente com esse conteúdo, para suportar a migração para algoritmos diferentes no futuro. Esses metadados devem incluir o algoritmo usado, tamanhos de chave e modos de preenchimento.
  • Quando disponíveis, os produtos devem utilizar protocolos criptográficos estabelecidos e fornecidos pela plataforma, em vez de os reimplementarem, incluindo formatos de assinatura (por exemplo, utilizar um formato normalizado existente).
  • Não reporte falhas de operação criptográfica aos 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 relatar diretamente erros de comprimento fora do intervalo ou inválidos. Registre erros detalhados somente no servidor e somente se o log detalhado estiver habilitado.
  • A revisão de segurança extra é altamente recomendada para qualquer projeto que incorpore os seguintes itens:
    • Um novo protocolo focado principalmente na segurança (como um protocolo de autenticação ou autorização)
    • Um novo protocolo que usa criptografia de forma nova ou fora do padrão. Exemplos de considerações incluem:
      • Um produto que implementa o protocolo chamará quaisquer APIs ou métodos 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 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 enraizado em uma autoridade de certificação confiável deixa clara a base para confiar na chave privada associada e permite a revogação e as atualizações se houver uma falha de segurança.