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
- Use BCryptGenRandom com o sinalizador BCRYPT_USE_SYSTEM_PREFERRED_RNG
CAPI
- Use CryptGenRandom para gerar valores aleatórios.
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
- Os aplicativos da loja podem usar CryptographicBuffer.GenerateRandom ou CryptographicBuffer.GenerateRandomNumber.
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:
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 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.
- Confira mais informações sobre Agilidade de Criptografia em Agilidade de Criptografia no MSDN.
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:
NCryptProtectSecret (em CNG DPAPI, disponível a partir do Windows 8)
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:
O SQL Server não dá suporte à criptografia para dados FILESTREAM, mesmo quando o TDE está habilitado.
O TDE não fornece automaticamente a criptografia para dados em trânsito para ou do banco de dados; você também deve habilitar conexões criptografadas para o banco de dados SQL Server. Confira HabilitarConexões criptografadas para o Mecanismo de Banco de Dados (SQL Server Configuration Manager) para obter orientação sobre como habilitar conexões criptografadas.
Se você mover um banco de dados protegido por TDE para uma instância diferente do SQL Server, também deverá mover o certificado que protege a DEK (chave de criptografia de dados) do TDE e instalá-lo no banco de dados mestre da instância do SQL Server de destino. Confira o artigo do TechNet Mover um banco de dados protegido por TDEpara outro SQL Server a fim de obter mais detalhes.
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.