Thursday, November 27, 2014

Whether to enable "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"

Use of "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing"is the standard recommendation in order to align with many security compliance standards. The United States Federal Information Processing Standard (FIPS) standard defines cryptographic algorithms approved for use by US Federal government computer systems for the protection of sensitive data. The requirement to use approved and validated algorithms applies only to the protection of sensitive data. Systems and applications are free to use weak or non-validated cryptographic implementations for non-security purposes based on its security context.

Enabling FIPS mode makes Windows and its subsystems use only FIPS-validated cryptographic algorithms. For example if this is enabled, it does not allow to use SSL 2.0 or 3.0 and enforce to use TLS instead. Further with .Net framework, if FIPS mode is enabled, the .NET Framework disallows the use of all non-validated cryptographic classes. The problem here is that the Framework offers multiple implementations of most algorithms, and not all of them have been submitted for validation, even though they are similar or identical to implementations that have been approved. Another significant problem with FIPS mode is that until very recently there was no NIST-approved way to derive an encryption key from a password. That blocked use of the Bitlocker Drive Encryption feature that stored a computer’s 48-character recovery password to Active Directory.

Even through the security best practise is to enable "System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing", it is up to the individuals to decide their way of implementation based on their security context of applicability.

Reference:
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx