Security Frame: Cryptography | Mitigation

• Use only approved symmetric block ciphers and key lengths
• Use approved block cipher modes and initialization vectors for symmetric ciphers
• Use approved asymmetric algorithms, key lengths, and padding
• Use approved random number generators
• Do not use symmetric stream ciphers
• Use approved MAC/HMAC/keyed hash algorithms
• Use only approved cryptographic hash functions

• Use strong encryption algorithms to encrypt data in the database
• SSIS packages should be encrypted and digitally signed
• Add digital signature to critical database securables
• Use SQL server EKM to protect encryption keys
• Use AlwaysEncrypted feature if encryption keys should not be revealed to Database engine

• Store Cryptographic Keys securely on IoT Device

• Generate a random symmetric key of sufficient length for authentication to IoT Hub

• Ensure a device management policy is in place that requires a use PIN and allows remote wiping

• Ensure a device management policy is in place that requires a PIN/password/auto lock and encrypts all data (e.g. BitLocker)

• Ensure that signing keys are rolled over when using Identity Server
• Ensure that cryptographically strong client ID, client secret are used in Identity Server

Products must use only those symmetric block ciphers and associated key lengths which have been explicitly approved by the Crypto Advisor in your organization. Approved symmetric algorithms at Microsoft include the following block ciphers:

• For new code AES-128, AES-192, and AES-256 are acceptable
• For backward compatibility with existing code, three-key 3DES is acceptable
• For products using symmetric block ciphers:
  • Advanced Encryption Standard (AES) is required for new code
  • Three-key triple Data Encryption Standard (3DES) is permissible in existing code for backward compatibility
  • All other block ciphers, including RC2, DES, 2 Key 3DES, DESX, and Skipjack, may only be used for decrypting old data, and must be replaced if used for encryption
• For symmetric block encryption algorithms, a minimum key length of 128 bits is required. The only block encryption algorithm recommended for new code is AES (AES-128, AES-192 and AES-256 are all acceptable)
• Three-key 3DES is currently acceptable if already in use in existing code; transition to AES is recommended. DES, DESX, RC2, and Skipjack are no longer considered secure. These algorithms may only be used for decrypting existing data for the sake of backward-compatibility, and data should be re-encrypted using a recommended block cipher

Please note that all symmetric block ciphers must be used with an approved cipher mode, which requires use of an appropriate initialization vector (IV). An appropriate IV, is typically a random number and never a constant value

The use of legacy or otherwise unapproved crypto algorithms and smaller key lengths for reading existing data (as opposed to writing new data) may be permitted after your organization's Crypto Board review. However, you must file for an exception against this requirement. Additionally, in enterprise deployments, products should consider warning administrators when weak crypto is used to read data. Such warnings should be explanatory and actionable. In some cases, it may be appropriate to have Group Policy control the use of weak crypto

Allowed .NET algorithms for managed crypto agility (in order of preference)

• AesCng (FIPS compliant)
• AuthenticatedAesCng (FIPS compliant)
• AESCryptoServiceProvider (FIPS compliant)
• AESManaged (non-FIPS-compliant)

Please note that none of these algorithms can be specified via the SymmetricAlgorithm.Create or CryptoConfig.CreateFromName methods without making changes to the machine.config file. Also, note that AES in versions of .NET prior to .NET 3.5 is named RijndaelManaged, and AesCng and AuthenticatedAesCng are >available through CodePlex and require CNG in the underlying OS

The use of banned cryptographic algorithms introduces significant risk to product security and must be avoided. Products must use only those cryptographic algorithms and associated key lengths and padding that have been explicitly approved by your organization's Crypto Board.

• RSA- may be used for encryption, key exchange and signature. RSA encryption must use only the OAEP or RSA-KEM padding modes. Existing code may use PKCS #1 v1.5 padding mode for compatibility only. Use of null padding is explicitly banned. Keys >= 2048 bits is required for new code. Existing code may support keys < 2048 bits only for backwards compatibility after a review by your organization's Crypto Board. Keys < 1024 bits may only be used for decrypting/verifying old data, and must be replaced if used for encryption or signing operations
• ECDSA- may be used for signature only. ECDSA with >=256-bit keys is required for new code. ECDSA-based signatures must use one of the three NIST approved curves (P-256, P-384, or P521). Curves that have been thoroughly analyzed may be used only after a review with your organization's Crypto Board.
• ECDH- may be used for key exchange only. ECDH with >=256-bit keys is required for new code. ECDH-based key exchange must use one of the three NIST approved curves (P-256, P-384, or P521). Curves that have been thoroughly analyzed may be used only after a review with your organization's Crypto Board.
• DSA- may be acceptable after review and approval from your organization's Crypto Board. Contact your security advisor to schedule your organization's Crypto Board review. If your use of DSA is approved, note that you will need to prohibit use of keys less than 2048 bits in length. CNG supports 2048-bit and greater key lengths as of Windows 8.
• Diffie-Hellman- may be used for session key management only. Key length >= 2048 bits is required for new code. Existing code may support key lengths < 2048 bits only for backwards compatibility after a review by your organization's Crypto Board. Keys < 1024 bits may not be used.

Products must use approved random number generators. Pseudorandom functions such as the C runtime function rand, the .NET Framework class System.Random, or system functions such as GetTickCount must, therefore, never be used in such code. Use of the dual elliptic curve random number generator (DUAL_EC_DRBG) algorithm is prohibited

• CNG- BCryptGenRandom(use of the BCRYPT_USE_SYSTEM_PREFERRED_RNG flag recommended unless the caller might run at any IRQL greater than 0 [that is, PASSIVE_LEVEL])
• CAPI- cryptGenRandom
• Win32/64- RtlGenRandom (new implementations should use BCryptGenRandom or CryptGenRandom) * rand_s * SystemPrng (for kernel mode)
• .NET- RNGCryptoServiceProvider or RNGCng
• Windows Store Apps- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom or .GenerateRandomNumber
• Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
• Apple OS X (<10.7)- Use /dev/random to retrieve random numbers
• Java(including Google Android Java code)- java.security.SecureRandom class. Note that for Android 4.3 (Jelly Bean), developers must follow the Android recommended workaround and update their applications to explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random

Products must use only approved message authentication code (MAC) or hash-based message authentication code (HMAC) algorithms.

A message authentication code (MAC) is a piece of information attached to a message that allows its recipient to verify both the authenticity of the sender and the integrity of the message using a secret key. The use of either a hash-based MAC (HMAC) or block-cipher-based MAC is permissible as long as all underlying hash or symmetric encryption algorithms are also approved for use; currently this includes the HMAC-SHA2 functions (HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) and the CMAC/OMAC1 and OMAC2 block cipher-based MACs (these are based on AES).

Use of HMAC-SHA1 may be permissible for platform compatibility, but you will be required to file an exception to this procedure and undergo your organization's Crypto review. Truncation of HMACs to less than 128 bits is not permitted. Using customer methods to hash a key and data is not approved, and must undergo your organization's Crypto Board review prior to use.

Products must use the SHA-2 family of hash algorithms (SHA256, SHA384, and SHA512). If a shorter hash is needed, such as a 128-bit output length in order to fit a data structure designed with the shorter MD5 hash in mind, product teams may truncate one of the SHA2 hashes (typically SHA256). Note that SHA384 is a truncated version of SHA512. Truncation of cryptographic hashes for security purposes to less than 128 bits is not permitted. New code must not use the MD2, MD4, MD5, SHA-0, SHA-1, or RIPEMD hash algorithms. Hash collisions are computationally feasible for these algorithms, which effectively breaks them.

Allowed .NET hash algorithms for managed crypto agility (in order of preference):

• SHA512Cng (FIPS compliant)
• SHA384Cng (FIPS compliant)
• SHA256Cng (FIPS compliant)
• SHA512Managed (non-FIPS-compliant) (use SHA512 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
• SHA384Managed (non-FIPS-compliant) (use SHA384 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
• SHA256Managed (non-FIPS-compliant) (use SHA256 as algorithm name in calls to HashAlgorithm.Create or CryptoConfig.CreateFromName)
• SHA512CryptoServiceProvider (FIPS compliant)
• SHA256CryptoServiceProvider (FIPS compliant)
• SHA384CryptoServiceProvider (FIPS compliant)

Ensure that cryptographically strong client ID, client secret are used in Identity Server. The following guidelines should be used while generating a client ID and secret:

• Generate a random GUID as the client ID
• Generate a cryptographically random 256-bit key as the secret