Utilizar apenas cifras de bloco simétrico aprovados e comprimentos de chave
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Os produtos têm de utilizar apenas as cifras de bloco simétrico e os comprimentos de chave associados que tenham sido explicitamente aprovados pelo Assistente de Criptografia na sua organização. Os algoritmos simétricos aprovados na Microsoft incluem as seguintes cifras de bloco:
Para o novo código AES-128, AES-192 e AES-256 são aceitáveis
Para retrocompatibilidade com o código existente, o 3DES de três chaves é aceitável
Para produtos que utilizam cifras de bloco simétrico:
A Norma de Encriptação Avançada (AES) é necessária para o novo código
A Norma de Encriptação de Dados Tripla (3DES) de três chaves é permitida no código existente para retrocompatibilidade
Todas as outras cifras de blocos, incluindo RC2, DES, 2 Key 3DES, DESX e Skipjack, só podem ser utilizadas para desencriptar dados antigos e devem ser substituídas se forem utilizadas para encriptação
Para algoritmos de encriptação de bloco simétrico, é necessário um comprimento mínimo de chave de 128 bits. O único algoritmo de encriptação de blocos recomendado para o novo código é AES (AES-128, AES-192 e AES-256 são aceitáveis)
O 3DES de três chaves é atualmente aceitável se já estiver a ser utilizado no código existente; é recomendada a transição para a AES. DES, DESX, RC2 e Skipjack já não são considerados seguros. Estes algoritmos só podem ser utilizados para desencriptar dados existentes por uma questão de retrocompatibilidade e os dados devem ser encriptados novamente com uma cifra de bloco recomendada
Tenha em atenção que todas as cifras de bloco simétrico têm de ser utilizadas com um modo de cifra aprovado, o que requer a utilização de um vetor de inicialização adequado (IV). Um IV adequado, é normalmente um número aleatório e nunca um valor constante
A utilização de algoritmos criptográficos legados ou não aprovados e comprimentos de chave mais pequenos para ler dados existentes (por oposição à escrita de novos dados) pode ser permitida após a revisão do Crypto Board da sua organização. No entanto, tem de pedir uma exceção contra este requisito. Além disso, nas implementações empresariais, os produtos devem considerar os administradores de aviso quando a criptográfica fraca é utilizada para ler dados. Tais avisos devem ser explicativos e acionáveis. Em alguns casos, pode ser apropriado ter Política de Grupo controlar a utilização de criptográfica fraca
Algoritmos .NET permitidos para agilidade criptográfica gerida (por ordem de preferência)
AesCng (compatível com FIPS)
AuthenticatedAesCng (compatível com FIPS)
AESCryptoServiceProvider (compatível com FIPS)
AESManaged (não compatível com FIPS)
Tenha em atenção que nenhum destes algoritmos pode ser especificado através dos SymmetricAlgorithm.Create métodos ou CryptoConfig.CreateFromName sem fazer alterações ao ficheiro machine.config. Além disso, tenha em atenção que o AES nas versões do .NET anteriores ao .NET 3.5 tem o nome RijndaelManagede AesCngAuthenticatedAesCng está >disponível através do CodePlex e requer o CNG no SO subjacente
Utilizar modos de cifra de bloco aprovados e vetores de inicialização para cifras simétricas
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Todas as cifras de bloco simétrico têm de ser utilizadas com um modo de cifra simétrica aprovado. Os únicos modos aprovados são CBC e CTS. Em particular, o modo de funcionamento do livro de código electrónico (BCE) deve ser evitado; A utilização do BCE requer a revisão criptográfica da sua organização. Toda a utilização de OFB, CFB, CTR, CCM e GCM ou qualquer outro modo de encriptação tem de ser revista pelo Crypto Board da sua organização. Reutilizar o mesmo vetor de inicialização (IV) com cifras de bloco em "modos de cifras de transmissão em fluxo", como CTR, pode fazer com que os dados encriptados sejam revelados. Todas as cifras de bloco simétrico também têm de ser utilizadas com um vetor de inicialização apropriado (IV). Um IV adequado é um número criptograficamente forte, aleatório e nunca um valor constante.
Utilizar algoritmos assimétricos aprovados, comprimentos de chave e preenchimento
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
A utilização de algoritmos criptográficos proibidos apresenta um risco significativo para a segurança do produto e tem de ser evitada. Os produtos devem utilizar apenas esses algoritmos criptográficos e comprimentos de chave associados e preenchimentos que foram explicitamente aprovados pelo Crypto Board da sua organização.
RSA – pode ser utilizado para encriptação, troca de chaves e assinatura. A encriptação RSA tem de utilizar apenas os modos de preenchimento OAEP ou RSA-KEM. O código existente pode utilizar o modo de preenchimento PKCS #1 v1.5 apenas para compatibilidade. A utilização de preenchimento nulo é explicitamente proibida. As chaves >= 2048 bits são necessárias para o novo código. O código existente pode suportar chaves < de 2048 bits apenas para retrocompatibilidade após uma revisão do Crypto Board da sua organização. As chaves < de 1024 bits só podem ser utilizadas para desencriptar/verificar dados antigos e têm de ser substituídas se forem utilizadas para operações de encriptação ou assinatura
ECDSA– pode ser utilizado apenas para assinatura. A ECDSA com >chaves =256 bits é necessária para o novo código. As assinaturas baseadas em ECDSA têm de utilizar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram analisadas exaustivamente só podem ser utilizadas após uma revisão com o Crypto Board da sua organização.
ECDH – pode ser utilizado apenas para troca de chaves. O ECDH com >=chaves de 256 bits é necessário para o novo código. A troca de chaves baseada em ECDH tem de utilizar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram analisadas exaustivamente só podem ser utilizadas após uma revisão com o Crypto Board da sua organização.
DSA– pode ser aceitável após revisão e aprovação do Crypto Board da sua organização. Contacte o seu assistente de segurança para agendar a revisão do Crypto Board da sua organização. Se a utilização da DSA for aprovada, tenha em atenção que terá de proibir a utilização de chaves com menos de 2048 bits de comprimento. O CNG suporta comprimentos de chave de 2048 bits e maiores a partir de Windows 8.
Diffie-Hellman- pode ser utilizado apenas para gestão de chaves de sessão. O comprimento da >chave = 2048 bits é necessário para o novo código. O código existente pode suportar comprimentos < de chave de 2048 bits apenas para retrocompatibilidade após uma revisão do Crypto Board da sua organização. As teclas < 1024 bits podem não ser utilizadas.
Utilizar geradores de números aleatórios aprovados
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Os produtos têm de utilizar geradores de números aleatórios aprovados. As funções pseudorandom, como a função de runtime C rand, a classe .NET Framework System.Random ou funções do sistema, como GetTickCount, nunca devem ser utilizadas nesse código. É proibida a utilização do algoritmo gerador de números aleatórios de curva elíptica dupla (DUAL_EC_DRBG)
CNG- BCryptGenRandom(utilização do sinalizador de BCRYPT_USE_SYSTEM_PREFERRED_RNG recomendado, a menos que o autor da chamada possa ser executado em qualquer IRQL superior a 0 [ou seja, PASSIVE_LEVEL])
CAPI - cryptGenRandom
Win32/64- RtlGenRandom (as novas implementações devem utilizar BCryptGenRandom ou CryptGenRandom) * rand_s * SystemPrng (para o modo kernel)
. NET- RNGCryptoServiceProvider ou RNGCng
Aplicações da Loja Windows - Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom ou . GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
Apple OS X (<10.7)- Utilize /dev/random para obter números aleatórios
Java(incluindo o código Java do Google Android)- java.security.SecureRandom class. Tenha em atenção que para o Android 4.3 (Jelly Bean), os programadores têm de seguir a solução recomendada para Android e atualizar as suas aplicações para inicializar explicitamente o PRNG com entropia de /dev/urandom ou /dev/random
Não utilizar cifras de fluxo simétricas
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
As cifras de fluxo simétricas, como a RC4, não podem ser utilizadas. Em vez de cifras de fluxo simétricas, os produtos devem utilizar uma cifra de bloco, especificamente a AES com um comprimento de chave de, pelo menos, 128 bits.
Os produtos devem utilizar apenas algoritmos MAC (Message Authentication Code) ou HMAC (Hash-based Message Authentication Code) aprovados.
Um código de autenticação de mensagens (MAC) é uma informação anexada a uma mensagem que permite ao destinatário verificar a autenticidade do remetente e a integridade da mensagem através de uma chave secreta. A utilização de um MAC baseado em hash (HMAC) ou MAC baseado em cifras em bloco é admissível desde que todos os algoritmos de encriptação simétricos ou hash subjacentes também sejam aprovados para utilização; atualmente, inclui as funções HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 e HMAC-SHA512) e os MACs baseados em cifras em bloco CMAC/OMAC1 e OMAC2 (estes são baseados no AES).
A utilização do HMAC-SHA1 pode ser permitida para compatibilidade da plataforma, mas terá de apresentar uma exceção a este procedimento e submeter-se à revisão criptográfica da sua organização. Não é permitida a truncagem de HMACs para menos de 128 bits. A utilização de métodos do cliente para realizar o hash a uma chave e a dados não está aprovada e deve ser submetida à análise pelo Conselho Criptográfico da organização antes da utilização.
Utilizar apenas funções hash criptográficas aprovadas
Título
Detalhes
Componente
Aplicação Web
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Os produtos devem utilizar a família de algoritmos hash SHA-2 (SHA256, SHA384 e SHA512). Se for necessário um hash mais curto, como um comprimento de saída de 128 bits para se adaptar a uma estrutura de dados concebida com um hash MD5 mais curto, as equipas de produto poderão truncar um dos hashes SHA2 (normalmente,o SHA256). Tenha em atenção que SHA384 é uma versão truncada de SHA512. Não é permitida a truncagem de hashes criptográficos para fins de segurança inferiores a 128 bits. O novo código não deve utilizar os algoritmos hash MD2, MD4, MD5, SHA-0, SHA-1 ou RIPEMD. As colisões de hash são computacionalmente viáveis para estes algoritmos, o que, efetivamente, os interrompe.
Algoritmos hash .NET permitidos para agilidade criptográfica gerida (por ordem de preferência):
SHA512Cng (compatível com FIPS)
SHA384Cng (compatível com FIPS)
SHA256Cng (compatível com FIPS)
SHA512Managed (não compatível com o FIPS) (utilizar SHA512 como nome de algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA384Managed (não compatível com o FIPS) (utilizar SHA384 como nome de algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA256Managed (não compatível com o FIPS) (utilizar SHA256 como nome de algoritmo em chamadas para HashAlgorithm.Create ou CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (compatível com FIPS)
SHA256CryptoServiceProvider (compatível com FIPS)
SHA384CryptoServiceProvider (compatível com FIPS)
Utilizar algoritmos de encriptação fortes para encriptar dados na base de dados
Os algoritmos de encriptação definem transformações de dados que não podem ser facilmente revertidas por utilizadores não autorizados. SQL Server permite que administradores e programadores escolham entre vários algoritmos, incluindo DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128 bits RC4, DESX, AES de 128 bits, AES de 192 bits e AES de 256 bits
Os pacotes SSIS devem ser encriptados e assinados digitalmente
A origem de um pacote é a pessoa ou organização que criou o pacote. Executar um pacote a partir de uma origem desconhecida ou não fidedigna pode ser arriscado. Para impedir a adulteração não autorizada de pacotes SSIS, devem ser utilizadas assinaturas digitais. Além disso, para garantir a confidencialidade dos pacotes durante o armazenamento/trânsito, os pacotes SSIS têm de ser encriptados
Adicionar assinatura digital a securables de bases de dados críticas
Nos casos em que a integridade de uma base de dados crítica com segurança tem de ser verificada, devem ser utilizadas assinaturas digitais. Os dispositivos de segurança da base de dados, como um procedimento armazenado, função, assemblagem ou acionador, podem ser assinados digitalmente. Segue-se um exemplo de quando isto pode ser útil: digamos que um ISV (Fornecedor Independente de Software) forneceu suporte a um software entregue a um dos seus clientes. Antes de fornecer suporte, o ISV gostaria de garantir que uma base de dados com segurança no software não foi adulterada por engano ou por uma tentativa maliciosa. Se o titular estiver assinado digitalmente, o ISV pode verificar a assinatura digital e validar a sua integridade.
Utilizar o EKM do SQL Server para proteger chaves de encriptação
SQL Server Gestão de Chaves Extensíveis permite que as chaves de encriptação que protegem os ficheiros de base de dados sejam armazenadas num dispositivo off-box, como um smartcard, um dispositivo USB ou um módulo EKM/HSM. Isto também permite a proteção de dados de administradores de bases de dados (exceto membros do grupo sysadmin). Os dados podem ser encriptados através de chaves de encriptação às quais apenas o utilizador da base de dados tem acesso no módulo EKM/HSM externo.
Utilizar a funcionalidade AlwaysEncrypted se as chaves de encriptação não forem reveladas ao Motor de base de dados
Always Encrypted é uma funcionalidade concebida para proteger dados confidenciais, como números de cartão de crédito ou números de identificação nacionais/regionais (por exemplo, números de segurança social dos EUA), armazenados na Base de Dados do SQL do Azure ou em bases de dados SQL Server. Always Encrypted permite que os clientes encriptem dados confidenciais dentro de aplicações cliente e nunca revelem as chaves de encriptação para o Motor de Base de Dados (Base de Dados SQL ou SQL Server). Como resultado, Always Encrypted fornece uma separação entre aqueles que possuem os dados (e podem vê-los) e aqueles que gerem os dados (mas não devem ter acesso)
Armazenar Chaves Criptográficas de forma segura no Dispositivo IoT
Título
Detalhes
Componente
Dispositivo IoT
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
SO do Dispositivo – Windows IoT Core, Conectividade do Dispositivo – SDKs de dispositivos do Azure IoT
Chaves simétricas ou privadas de certificados de forma segura num armazenamento protegido por hardware, como chips TPM ou Smart Card. Windows 10 IoT Core suporta o utilizador de um TPM e existem vários TPMs compatíveis que podem ser utilizados: TPM Discreto (dTPM). Recomenda-se a utilização de um Firmware ou TPM Discreto. Um TPM de Software só deve ser utilizado para fins de desenvolvimento e teste. Assim que um TPM estiver disponível e as chaves forem aprovisionadas no mesmo, o código que gera o token deve ser escrito sem codificar informações confidenciais no mesmo.
Exemplo
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Como se pode ver, a chave primária do dispositivo não está presente no código. Em vez disso, é armazenado no TPM no bloco 0. O dispositivo TPM gera um token de SAS de curta duração que, em seguida, é utilizado para ligar ao Hub IoT.
Gerar uma chave simétrica aleatória de comprimento suficiente para a autenticação Hub IoT
Título
Detalhes
Componente
IoT Cloud Gateway
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
Escolha do gateway - Hub IoT do Azure
Referências
N/D
Passos
Hub IoT contém um Registo de Identidade do dispositivo e, ao aprovisionar um dispositivo, gera automaticamente uma chave simétrica aleatória. Recomenda-se utilizar esta funcionalidade do registo de identidade do Hub IoT do Azure para gerar a chave utilizada para autenticação. Hub IoT também permite que uma chave seja especificada ao criar o dispositivo. Se uma chave for gerada fora do Hub IoT durante o aprovisionamento do dispositivo, é recomendado criar uma chave simétrica aleatória ou, pelo menos, 256 bits.
Certifique-se de que está implementada uma política de gestão de dispositivos que requer um PIN de utilização e permite a limpeza remota
Título
Detalhes
Componente
Dynamics CRM Mobile Client
Fase SDL
Implementação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Certifique-se de que está implementada uma política de gestão de dispositivos que requer um PIN de utilização e permite a limpeza remota
Certifique-se de que está implementada uma política de gestão de dispositivos que requer um PIN/palavra-passe/bloqueio automático e encripta todos os dados (por exemplo, BitLocker)
Título
Detalhes
Componente
Cliente Outlook do Dynamics CRM
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Certifique-se de que está implementada uma política de gestão de dispositivos que requer um PIN/palavra-passe/bloqueio automático e encripta todos os dados (por exemplo, BitLocker)
Confirme que as chaves de assinatura são revertidas ao utilizar o Identity Server
Certifique-se de que as chaves de assinatura são revertidas ao utilizar o Identity Server. A ligação na secção de referências explica como isto deve ser planeado sem causar interrupções nas aplicações que dependem do Identity Server.
Confirme que o ID de cliente criptograficamente forte e o segredo do cliente são utilizados no Identity Server
Título
Detalhes
Componente
Servidor de Identidade
Fase SDL
Compilação
Tecnologias Aplicáveis
Genérica
Atributos
N/D
Referências
N/D
Passos
Certifique-se de que o ID de cliente criptograficamente forte e o segredo do cliente são utilizados no Identity Server. As seguintes diretrizes devem ser utilizadas ao gerar um ID de cliente e um segredo:
Gerar um GUID aleatório como o ID de cliente
Gerar uma chave criptograficamente aleatória de 256 bits como o segredo