Quais são os três algoritmos de assinatura digital aprovados pelo NIST escolha três escolha uma ou mais?

• Utilize apenas cifras de bloco simétrico aprovadas e comprimentos de chave
• Utilizar modos de cifra de blocos aprovados e vetores de inicialização para cifras simétricas
• Utilize algoritmos assimétricos aprovados, comprimentos de chave e estofamento
• Utilize geradores de números aleatórios aprovados
• Não utilize cifras de fluxo simétrico
• Utilizar algoritmos hash codificados/HMAC/MAC aprovados
• Utilizar apenas funções hash criptográficas aprovadas

• Use algoritmos de encriptação fortes para encriptar dados na base de dados
• Os pacotes SSIS devem ser encriptados e assinados digitalmente
• Adicionar assinatura digital a bases de dados críticas
• Use SQL servidor EKM para proteger chaves de encriptação
• Utilize funcionalidade AlwaysEncrypted se as chaves de encriptação não deverão ser reveladas ao motor da Base de Dados

• Guarde as chaves criptográficas de forma segura no dispositivo IoT

• Gere uma chave simétrica aleatória de comprimento suficiente para a autenticação Hub IoT

• Certifique-se de que existe uma política de gestão de dispositivos que requer um PIN de utilização e permite a limpeza remota

• Certifique-se de que existe uma política de gestão de dispositivos que requer um PIN/password/bloqueio automático e encripta todos os dados (por exemplo, BitLocker)

• Certifique-se de que as teclas de assinatura são enroladas ao utilizar o Servidor de Identidade
• Certifique-se de que o ID do cliente criptograficamente forte, o segredo do cliente são usados no Servidor de Identidade

Os produtos devem utilizar apenas as cifras de bloco simétrico e os comprimentos de chave associados que tenham sido explicitamente aprovados pelo Crypto Advisor na sua organização. Os algoritmos simétricos aprovados na Microsoft incluem as seguintes cifras de bloco:

• Para novo código AES-128, AES-192 e AES-256 são aceitáveis
• Para compatibilidade retrógrada com o código existente, 3DES de três chaves é aceitável
• Para os produtos que utilizam cifras de bloco simétrico:
  • O Padrão avançado de encriptação (AES) é necessário para novo código
  • A norma de encriptação de dados tripla de três chaves (3DES) é permitida em código existente para retrocompatibilidade
  • Todas as outras cifras de blocos, incluindo RC2, DES, 2 Key 3DES, DESX e Skipjack, só podem ser usadas 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 128 bits. O único algoritmo de encriptação de bloco recomendado para novo código é AES (AES-128, AES-192 e AES-256 são todos aceitáveis)
• Atualmente, o 3DES de três chaves é aceitável se já estiver em uso no código existente; recomenda-se 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 os dados existentes por uma questão de retrocompatibilidade, e os dados devem ser reencrim encriptados usando uma cifra de bloco recomendada

Por favor, note que todas as cifras de bloco simétrico devem ser utilizadas com um modo de cifra aprovado, que requer a utilização de um vetor de inicialização apropriado (IV). Um IV apropriado, é tipicamente um número aleatório e nunca um valor constante

A utilização de algoritmos criptos ou não aprovados e comprimentos-chave menores para a leitura dos dados existentes (em oposição à escrita de novos dados) pode ser permitida após a revisão do Crypto Board da sua organização. No entanto, deve solicitar uma exceção contra este requisito. Além disso, nas implementações das empresas, os produtos devem considerar administradores de aviso quando o cripto fraco é usado para ler dados. Tais advertências devem ser explicativas e exequíveis. Em alguns casos, pode ser apropriado ter Política de Grupo controlar o uso de cripto fraco

Algoritmos .NET permitidos para cripto-agilidade gerida (por ordem de preferência)

• AesCng (em conformidade com o FIPS)
• AutenticadoAesCng (em conformidade com o FIPS)
• AESCryptoServiceProvider (compatível com FIPS)
• AESManaged (não conforme com o FIPS)

Por favor, note que nenhum destes algoritmos pode ser especificado através do SymmetricAlgorithm.Create ou CryptoConfig.CreateFromName métodos sem fazer alterações no ficheiro machine.config. Além disso, note que a AES em versões de .NET antes de .NET 3.5 é nomeada RijndaelManaged, e estão AesCngAuthenticatedAesCng>disponíveis através do CodePlex e requerem CNG no SISTEMA subjacente

A utilização de algoritmos criptográficos proibidos introduz riscos significativos para a segurança do produto e deve ser evitada. Os produtos devem utilizar apenas os algoritmos criptográficos e os comprimentos e estofos de chaves associados que tenham sido explicitamente aprovados pela Crypto Board da sua organização.

• RSA- pode ser usado para encriptação, troca de chaves e assinatura. A encriptação RSA deve utilizar apenas os modos de enchimento OAEP ou RSA-KEM. O código existente pode utilizar o modo de enchimento PKCS #1 v1.5 apenas para compatibilidade. O uso de enchimento nulo é explicitamente proibido. Chaves >= 2048 bits são necessários para novo código. O código existente pode suportar as teclas < 2048 bits apenas para retrocompatibilidade após uma revisão pelo Crypto Board da sua organização. As teclas < 1024 bits só podem ser utilizadas para desencriptar/verificar dados antigos, e devem ser substituídas se forem utilizadas para operações de encriptação ou assinatura
• ECDSA- pode ser usado apenas para assinatura. ECDSA com >teclas =256 bits é necessário para novo código. As assinaturas baseadas no ECDSA devem utilizar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram analisadas minuciosamente só podem ser utilizadas após uma revisão com o Crypto Board da sua organização.
• ECDH- pode ser usado apenas para troca de chaves. ECDH com >teclas =256 bits é necessário para novo código. O intercâmbio-chave baseado no ECDH deve utilizar uma das três curvas aprovadas pelo NIST (P-256, P-384 ou P521). As curvas que foram analisadas minuciosamente só podem ser utilizadas após uma revisão com o Crypto Board da sua organização.
• A DSA- pode ser aceitável após revisão e aprovação do Crypto Board da sua organização. Contacte o seu conselheiro de segurança para agendar a revisão do Crypto Board da sua organização. Se a sua utilização da DSA for aprovada, note que terá de proibir a utilização de chaves com menos de 2048 bits de comprimento. O CNG suporta comprimentos-chave de 2048 e maiores a partir de Windows 8.
• Diffie-Hellman- pode ser usado apenas para gestão de chaves de sessão. O comprimento da chave >= 2048 bits é necessário para novo código. O código existente pode suportar os comprimentos < das chaves de 2048 apenas para retrocompatibilidade após uma revisão pelo Crypto Board da sua organização. As teclas < 1024 bits não podem ser utilizadas.

Os produtos devem utilizar geradores de números aleatórios aprovados. Funções pseudorandom tais como o rand de função de execução C, o sistema de classe .NET Framework.Random, ou funções do sistema como GetTickCount devem, portanto, nunca ser usadas em tal código. É proibida a utilização do algoritmo do gerador de números aleatórios de curva dupla elíptica (DUAL_EC_DRBG)

• CNG- BCryptGenRandom (utilização da bandeira de BCRYPT_USE_SYSTEM_PREFERRED_RNG recomendada, a menos que o chamador possa funcionar em qualquer IRQL superior a 0 [isto é, PASSIVE_LEVEL])
• CAPI- criptGenRandom
• Win32/64... RtlGenRandom (novas implementações devem utilizar BCryptGenRandom ou CryptGenRandom) * rand_s * SystemPrng (para o modo kernel)
• . NET- RNGCryptoServiceProvider ou RNGCng
• Windows Store Apps-Windows. Security.Cryptography.CryptographicBuffer.GenerateRandom ou . Gerar ORandomNumber
• Apple OS X (10.7+)/iOS (2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes)
• Apple OS X (<10.7)- Utilização /dev/random para recuperar números aleatórios
• Java (incluindo o código Java Do Google Android)- java.security.SecureRandom. Note que para o Android 4.3 (Jelly Bean), os desenvolvedores devem seguir o Android recomendado solução e atualizar suas aplicações para explicitamente inicializar o PRNG com entropia de /dev/urandom ou /dev/random

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 mensagem (MAC) é uma informação anexada a uma mensagem que permite ao destinatário verificar tanto a autenticidade do remetente como a integridade da mensagem utilizando 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 de HMAC-SHA1 pode ser permitida para a compatibilidade da plataforma, mas você será obrigado a preencher uma exceção a este procedimento e submeter-se à revisão Crypto da sua organização. Não é permitida a truncação de HMACs a 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.

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). Note 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 (em conformidade com o FIPS)
• SHA384Cng (em conformidade com o FIPS)
• SHA256Cng (compatível com o 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)

Certifique-se de que o ID do cliente criptograficamente forte, o segredo do cliente são usados no Servidor de Identidade. As seguintes diretrizes devem ser utilizadas enquanto gera uma ID do cliente e secreta:

• Gere um GUID aleatório como iD do cliente
• Gere uma chave criptograficamente aleatória de 256 bits como o segredo