Recomendações criptográficas do Microsoft SDL

Introdução

Este documento contém recomendações e melhores práticas para uso de criptografia em plataformas Microsoft. Grande parte do conteúdo aqui é parafraseada ou agregada dos próprios padrões de segurança internos da Microsoft usados para criar o ciclo de vida do desenvolvimento de segurança. Ele deve ser usado 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.

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 SSL/TLS:

  • O TSL 1.2 deve estar habilitado

  • O TLS 1.1 e o TLS 1.0 devem estar habilitados somente para compatibilidade com versões anteriores

  • O SSL 3 e o SSL 2 devem estar desabilitados por padrão

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 para novos códigos.

  • O padrão de criptografia 3DES (Triple Data Encryption Standard) com três chaves é permitido em códigos existentes e para garantir a compatibilidade com versões anteriores.

  • Todas as outras codificações de bloco, incluindo RC2, DES, 3DES com duas chaves, DESX e Skipjack, só deverão ser usadas para descriptografar os dados antigos e deverão ser substituídas se utilizadas para criptografia.

Para algoritmos de criptografia de bloco simétrica, recomenda-se um comprimento mínimo de chave de 128 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). O 3DES com três chaves é atualmente aceitável se já estiver em uso no código existente. É recomendável mudar para AES. Os algoritmos DESX, DES, RC2 e Skipjack não são mais considerados seguros. Eles só devem ser usados para descriptografar os dados existentes por conta de sua compatibilidade com versões anteriores. Depois disso, os dados devem ser criptografados novamente com uma codificação de bloco recomendada.

Modos de criptografia

Os algoritmos simétricos podem operar em uma variedade de 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 incluídos 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)

  • CCM (contador com CBC-MAC)

  • GCM (Galois/modo de 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. 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, pois isso 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 CTR (Counter).

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

RSA

  • O RSA deve 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.

  • Chaves >= 2.048 bits são recomendadas

ECDSA

  • ECDSA com >= 256 bits é recomendado

  • As assinaturas baseadas em ECDSA devem usar uma das três curvas NIST aprovadas (P-256, P-384 ou P521).

ECDH

  • ECDH com >= chaves de 256 bits é recomendado

  • As trocas de chaves baseadas em ECDH devem usar uma das três curvas NIST aprovadas (P-256, P-384 ou P521).

Inteiro Diffie-Hellman

  • Comprimento de chave >= 2.048 bits é recomendado

  • 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

  • Todas as chaves assimétricas devem ter um tempo de vida máximo de cinco anos, sendo recomendado um ano.

  • Todas as chaves simétricas devem ter um tempo de vida máximo de três anos; sendo recomendado um ano.

  • 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

CAPI

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, mas pode ser usado para testes internos.

  • A função SystemPrng é recomendada para o código de modo kernel.

.NET

Aplicativos da Windows Store

Não recomendado

  • As funções não seguras relacionadas à geração de números aleatórios incluem rand,System.Random (.NET), GetTickCount e GetTickCount64

  • Não recomendamos o uso do algoritmo do geração aleatória de números de curva elíptica dupla ("DUAL_EC_DRBG").

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 serã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:

  1. A biblioteca deve ser uma versão atual com suporte, livre de vulnerabilidades conhecidas de segurança

  2. Os protocolos de segurança, os algoritmos e os comprimentos de chave mais recentes devem ter suporte

  3. (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 ou Windows Phone, use a CNG, se possível. Caso contrário, use a CryptoAPI (também chamada de CAPI, que tem suporte como um componente herdado do Windows Vista em diante).

  • SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 ou IXMLHTTPRequest3.

    • Os aplicativos WinHTTP devem ser criados com WinHttpSetOptionpara dar suporte a TLS 1.2
  • 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

  • Primitivos de criptografia: use a API definida no namespace System.Security.Cryptography – as classes CNG são preferenciais.

  • Use a versão mais recente disponível do .Net Framework. No mínimo, deve ser a versão 4.6 do .Net Framework. Se uma versão mais antiga for necessária, verifique se a regkey "SchUseStrongCrypto" está definida para habilitar o TLS 1.2 para o aplicativo em questão.

  • Validação de certificado: use as APIs definidas no namespace System.Security.Cryptography.X509Certificates.

  • SSL/TLS/DTLS: use as APIs definidas no namespace System.Net (por exemplo, HttpWebRequest).

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: 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 2): recomendação para esquemas de estabelecimento de chave em pares usando criptografia de logaritmo discreto. Em particular, recomenda-se a "Função de derivação de chave de etapa única" na seção 5.8.1.

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 SSL, TLS ou DTLS deverão verificar completamente os certificados X.509 das entidades a que se conectarem. Isso inclui a verificação para os seguintes aspectos dos certificados:

  • 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.

Os clientes que confiam em certificados "autoassinados" (por exemplo, um cliente de email que se conecta a um servidor Exchange em uma configuração padrão) podem ignorar as verificações de certificado. No entanto, 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. Você só deverá confiar em certificados autoassinados se os tiver obtido de outra fonte confiável (por exemplo, uma entidade confiável que fornece o certificado sobre um transporte autenticado e protegido por integridade).

Funções de hash criptográfico

Os produtos devem usar a família SHA-2 de algoritmos de hash (SHA256, SHA384 e SHA512). Por motivos de segurança, não é recomendado truncar hashes criptográficos para menos de 128 bits.

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).

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. Isso deve incluir o algoritmo usado, tamanhos de chave, vetores de inicialização e modos de preenchimento.

  • Quando disponível, os produtos devem usar protocolos de criptografia estabelecidos e fornecidos pela plataforma em vez de reimplementá-los. Isso inclui formatos de assinatura (por exemplo, usar um formato padrão existente).

  • Criptografias de stream simétricas, como RC4, não devem ser usadas. Em vez de codificações de stream simétricas, os produtos devem usar uma codificação de bloco, especificamente a AES com uma chave de pelo menos 128 bits.

  • 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 o seguinte:

    • 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?

  • Os certificados autoassinados não são recomendados para ambientes de produção. 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 no caso de uma falha de segurança.

Criptografia de dados confidenciais antes do armazenamento

DPAPI/DPAPI-NG

Para dados que precisam ser persistidos entre reinicializações do sistema:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (CNG DPAPI do Windows 8)

Para dados que não precisam ser persistidos entre reinicializações do sistema:

  • CryptProtectMemory

  • CryptUnprotectMemory

Para dados que precisam ser persistidos e acessados por vários computadores e contas de domínio:

TDE do SQL Server

Você pode usar o SQL Server TDE (Transparent Data Encryption) para proteger dados confidenciais.

Você deve usar uma DEK (chave de criptografia de banco de dados) TDE que atenda aos requisitos de restrição de chave e algoritmo de criptografia do SDL. Atualmente, apenas AES_128, AES_192 e AES_256 são recomendados; TRIPLE_DES_3KEY não é recomendado.

Há algumas considerações importantes para usar o SQL TDE que você deve ter em mente:

Gerenciamento de credenciais

Use a API do Windows Credential Manager ou Microsoft Azure KeyVault para proteger os dados de senhas e credenciais.

Aplicativos da Windows Store

Use as classes nos namespaces Windows.Security.Cryptography e Windows.Security.Cryptography.DataProtection para proteger segredos e dados confidenciais.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

Use as classes no namespace Windows.Security.Credentials para proteger dados de senha e credenciais.

.NET

Para dados que precisam ser persistidos entre reinicializações do sistema:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

Para dados que não precisam ser persistidos entre reinicializações do sistema:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

Para arquivos de configuração, use

RsaProtectedConfigurationProvider ou DPAPIProtectedConfigurationProvider para proteger sua configuração, usando a criptografia RSA ou DPAPI, respectivamente.

O RSAProtectedConfigurationProvider pode ser usado em vários computadores em um cluster. Saiba mais em Criptografia de informações de configuração usando configuração protegida.