FIPS 140 Overview

FIPS 140 Standard

FIPS 140 is a US government and Canadian government standard that defines a minimum set of the security requirements for products that implement cryptography. This standard is designed for cryptographic modules that are used to secure sensitive but unclassified information. Testing against the FIPS 140 standard is maintained by the Cryptographic Module Validation Program (CMVP), a joint effort between the US National Institute of Standards and Technology (NIST) and the Communications Security Establishment of Canada (CSEC).

The current standard defines four-levels of increasing security, 1 through 4. Most software products (including all Microsoft products) are tested against the Level 1 security requirements.

Applicability of the FIPS standard

Within the US Federal government, the FIPS 140 standard applies to any security system (whether hardware, firmware, software, or a combination thereof) to be used by agencies for protecting sensitive but unclassified information. Some agencies have expanded its use by requiring that the modules to be procured for secret systems also meet the FIPS 140 requirements.

The FIPS 140 standard has also been used by different standards bodies, specification groups, nations, and private institutions as a requirement or guideline for those products (e.g. – Digital Cinema Systems Specification).

History of 140-1

FIPS 140-1 is the original working version of the standard made official on January 11, 1994. The standard remained in effect until FIPS 140-2 became mandatory for new products on May 25, 2002.

FIPS 140-2

FIPS 140-2 is currently the active version of the standard.

Microsoft FIPS Support Policy

FIPS Mode of Operation

The common term “FIPS mode” is used in this document and Security Policy documents. When a cryptographic module contains both FIPS-approved and non-FIPS approved security methods, it must have a "FIPS mode of operation" to ensure only FIPS-approved security methods may be used. When a module is in "FIPS mode", a non-FIPS approved method cannot be used instead of a FIPS-approved method.

This section provides information for Procurement Officers and Auditors who are responsible for ensuring that Microsoft products with FIPS 140 validated cryptographic modules are used in their organization. The goal of this section is to provide an overview of the Microsoft developed products and modules and explain how the validated cryptographic modules are used.

Microsoft Product Relationship with CNG and CAPI libraries

Rather than validate individual components and products, Microsoft chooses to validate only the underlying cryptographic modules. Subsequently, many Windows components and Microsoft products are built to rely on the Cryptographic API: Next Generation (CNG) and legacy Cryptographic API (CAPI) FIPS 140 validated cryptographic modules. Windows components and Microsoft products use the documented application programming interfaces (APIs) for each of the modules to access various cryptographic services.

The following list contains some of the Windows components and Microsoft products that rely on FIPS 140 validated cryptographic modules:

Schannel Security Package

Remote Desktop Protocol (RDP) Client

Encrypting File System (EFS)

Some Microsoft .NET Framework Applications (.NET also provides cryptographic algorithm implementations that have not been FIPS 140 validated.)

Systems Integrators must ensure that all cryptographic modules installed are, in fact, FIPS 140 validated. This can be accomplished by cross-checking the version number of the installed module with the list of validated binaries. The list of validated CAPI binaries is identified in the CAPI Validated Cryptographic Modules section below and the list of validated CNG binaries is identified in the CNG Validated Cryptographic Modules section below. There are similar sections for all other validated cryptographic modules.

The version number of the installed binary is found by right-clicking the module file and clicking on the Version or Details tab. Cryptographic modules are stored in the "windows\system32" or "windows\system32\drivers" directory.

Step 2 – Setting FIPS Local/Group Security Policy Flag

The Windows operating system provides a group (or local) security policy setting, “System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing”, which is used by many Microsoft products to determine whether to operate in a FIPS-approved mode. When this policy is set, the validated cryptographic modules in Windows will also operate in a FIPS-approved mode.

Note – There is no enforcement of the FIPS policy by the operating system or the validated cryptographic modules. Instead, each individual application must check this flag and enforce the Security Policy of the validated cryptographic modules.

Instructions on Setting the FIPS Local/Group Security Policy Flag

While there are alternative methods for setting the FIPS local/group security policy flag, the following method is included as a guide to users with Administrative privileges. This description is for the Local Security Policy, but the Group Security Policy may be set in a similar manner.

Open the 'Run' menu by pressing the combination 'Windows Key + R'.

Type 'secpol.msc' and press 'Enter' or click the 'Ok' button.

In the Local Security Policy management console window that opens, use the left tab to navigate to the Local Policies -> Security Options.

Scroll down the right pane and double-click 'System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing'.

In the properties window, select the 'Enabled' option and click the 'Apply' button.

The following list details some of the Microsoft components that use the cryptographic functionality implemented by either CNG or legacy CAPI. When the FIPS Local/Group Security Policy is set, the following components will enforce the validated module Security Policy.

Schannel Security Package

Remote Desktop Protocol (RDP) Client

Encrypting File System (EFS)

Some Microsoft .NET Framework Applications (.NET also provides cryptographic algorithm implementations that have not been FIPS 140 validated.)

Effects of Setting FIPS Local/Group Security Policy Flag

When setting the FIPS local/group security policy flag, the behavior of several Microsoft components and products are affected. The most noticeable difference will be that the components enforcing this setting will only use those algorithms approved or allowed in FIPS mode. The specific changes to the products listed above are:

Schannel Security Package forced to negotiate sessions using TLS1.0. The following supported Cipher Suites are disabled:

TLS_RSA_WITH_RC4_128_SHA

TLS_RSA_WITH_RC4_128_MD5

SSL_CK_RC4_128_WITH_MD5

SSL_CK_DES_192_EDE3_CBC_WITH_MD5

TLS_RSA_WITH_NULL_MD5

TLS_RSA_WITH_NULL_SHA

The set of cryptographic algorithms that a Remote Desktop Protocol (RDP) server will use is scoped to:

CALG_RSA_KEYX - RSA public key exchange algorithm

CALG_3DES - Triple DES encryption algorithm

CALG_AES_128 - 128 bit AES

CALG_AES_256 - 256 bit AES

CALG_SHA1 - SHA hashing algorithm

CALG_SHA_256 - 256 bit SHA hashing algorithm

CALG_SHA_384 - 384 bit SHA hashing algorithm

CALG_SHA_512 - 512 bit SHA hashing algorithm

Any Microsoft .NET Framework applications, such as Microsoft ASP.NET or Windows Communication Foundation (WCF), only allow algorithm implementations that are validated to FIPS 140, meaning only classes that end in "CryptoServiceProvider" or "Cng" can be used. Any attempt to create an instance of other cryptographic algorithm classes or create instances that use non-allowed algorithms will cause an InvalidOperationException exception.

Verification of ClickOnce applications fails unless the client computer has .NET Framework 2.0 SP1 or later service pack installed or .NET Framework 3.5 or later installed.

On Windows Vista and Windows Server 2008 and later, BitLocker Drive Encryption will switch from AES-128 using the elephant diffuser to using the approved AES-256 encryption. Recovery passwords are not created or backed up. Instead, backup a recovery key on a local drive or on a network share. To use the recovery key, put the key on a USB device and plug the device into the computer.

Information for Software Developers

This section is targeted at developers who wish to build their own applications using the FIPS 140 validated cryptographic modules.

Each of the validated cryptographic modules defines a series of rules that must be followed. The security rules for each validated cryptographic module are specified in the Security Policy document. Links to each of the Security Policy documents is provided in the Microsoft FIPS 140 Validated Cryptographic Modules section below. Generally, the restriction in Microsoft validated cryptographic modules is limiting the use of cryptography to only FIPS Approved cryptographic algorithms, modes, and key sizes.

Using Microsoft Cryptographic Modules in a FIPS mode of operation

No matter whether developing with native languages or using .NET, it is important to first check whether the CNG modules for the target system are FIPS validated. The list of validated CNG binaries is identified in the CNG Validated Cryptographic Modules section.

When developing using CNG directly, it is the responsibility of the developer to follow the security rules outlined in the FIPS 140 Security Policy for each module. The security policy for each module is provided on the CMVP website. Links to each of the Security Policy documents is provided in the tables below. It is important to remember that setting the FIPS local/group security policy Flag (discussed above) does not affect the behavior of the modules when used for developing custom applications.

If you are developing your application using .NET instead of using the native libraries, then setting the FIPS local policy flag will generate an exception when an improper .NET class is used for cryptography (i.e. the cryptographic classes whose names end in "Managed"). The names of these allowed classes end with "Cng", which use the CNG binaries or "CryptoServiceProvider", which use the legacy CAPI binaries.

Key Strengths and Validity Periods

NIST Special Publication 800-131A, Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths, dated January 2011, [SP 800-131A], offers guidance for moving to stronger cryptographic keys and algorithms. This does not replace NIST SP 800-57, Recommendation for Key Management Part 1: General, [SP 800-57], but gives more specific guidance. One of the most important topics discussed in these publications deals with the key strengths of FIPS Approved algorithms and their validity periods. When developing applications that use FIPS Approved algorithms, it is also extremely important to select appropriate key sizes based on the security lifetimes recommended by NIST.

FIPS 140 FAQ

The following are answers to commonly asked questions for the FIPS 140-2 validation of Microsoft products.

How does FIPS 140 relate to the Common Criteria?Answer: These are two separate security standards with different, but complementary, purposes. FIPS 140 is a standard designed specifically for validating product modules that implement cryptography. On the other hand, Common Criteria is designed to help evaluate security functions in IT products.In many cases, Common Criteria evaluations will rely on FIPS 140 validations to provide assurance that cryptographic functionality is implemented properly.

How does FIPS 140 relate to Suite B?Answer: Suite B is simply a set of cryptographic algorithms defined by the U.S. National Security Agency (NSA) as part of its Cryptographic Modernization Program. The set of Suite B cryptographic algorithms are to be used for both unclassified information and most classified information.The Suite B cryptographic algorithms are a subset of the FIPS Approved cryptographic algorithms as allowed by the FIPS 140 standard.

There are so many modules listed on the NIST website for each release, how are they related and how do I tell which one applies to me?Answer: Microsoft strives to validate all releases of its cryptographic modules. Each module provides a different set of cryptographic algorithms. If you are required to use only FIPS validated cryptographic modules, you simply need to verify that the version being used appears on the validation list.Please see the Microsoft FIPS 140 Validated Cryptographic Modulessection for a complete list of Microsoft validated modules.

My application links against crypt32.dll, cryptsp.dll, advapi32.dll, bcrypt.dll, bcryptprimitives.dll, or ncrypt.dll. What do I need to do to assure I’m using FIPS 140 validated cryptographic modules?Answer: crypt32.dll, cryptsp.dll, advapi32.dll, and ncrypt.dll are intermediary libraries that will offload all cryptographic operations to the FIPS validated cryptographic modules. Bcrypt.dll itself is a validated cryptographic module for Windows Vista and Windows Server 2008. For Windows 7 and Windows Server 2008 R2 and later, bcryptprimitives.dll is the validated module, but bcrypt.dll remains as one of the libraries to link against.You must first verify that the underlying CNG cryptographic module is validated. Once verified, you'll need to confirm that you're using the module correctly in FIPS mode (See Information for Software Developers section for details).

What does "When operated in FIPS mode" mean on certificates?Answer: This caveat identifies that a required configuration and security rules must be followed in order to use the cryptographic module in a manner consistent with its FIPS 140 Security Policy. The security rules are defined in the Security Policy for the module and usually revolve around using only FIPS Approved cryptographic algorithms and key sizes. Please see the Security Policy for the specific security rules for each cryptographic module (See Microsoft FIPS 140 Validated Cryptographic Modules section for links to each policy).

Which FIPS validated module is called when Windows 7 or Windows 8 is configured to use the FIPS setting in the wireless configuration?Answer: CNG is used. This setting tells the wireless driver to call FIPS 140-2 validated cryptographic modules instead of using the driver’s own cryptography, if any.

Is BitLocker to Go FIPS 140-2 validated?Answer: There are two separate parts for BitLocker to Go. One part is simply a native feature of BitLocker and as such, it uses FIPS 140-2 validated cryptographic modules. The other part is the BitLocker to Go Reader application for down-level support of older operating systems such as Windows XP and Windows Vista. The Reader application does not use FIPS 140-2 validated cryptographic modules.

Are applications FIPS 140-2 validated?Answer: Microsoft only has low-level cryptographic modules in Windows FIPS 140-2 validated, not high-level applications. A better question is whether a certain application calls a FIPS 140-2 validated cryptographic module in the underlying Windows OS. That question needs to be directed to the company/product group that created the application of interest.

Microsoft FIPS 140 Validated Cryptographic Modules

Overview of CNG

With Windows Vista came the introduction of Cryptographic API: Next Generation (CNG), which provides a new API to use both kernel and user space cryptography. It replaced the legacy Microsoft Cryptography API (CAPI), which has been deprecated. Developers should use the new CNG APIs. In Windows Vista and Windows Server 2008, user mode applications directly interface with BCRYPT (bcrypt.dll), while kernel mode applications directly interface through the API with KSECDD. Both of these underlying libraries are validated cryptographic modules in the Windows Vista and Windows Server 2008 releases

In Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012, the list of FIPS 140-2 validated cryptographic modules is different. Now, the kernel mode cryptographic functionality is contained in a separate driver, cng.sys, which supports both the CNG and the legacy FIPS.sys APIs. The user mode CNG algorithm implementations are now in bcryptprimitives.dll, which is loaded by bcrypt.dll; applications must still interface with bcrypt.dll.

Microsoft strongly recommends using CNG modules for new applications. The legacy CAPI modules should not be used because their APIs have been deprecated.

The following tables identify the specific versions that are validated as well as the operating systems for which testing is valid. Hyperlinks are also provided to the CMVP issued certificate as well as the Security Policy for each. A full listing of cryptographic algorithms supported by each module is provided in the Cryptographic Algorithms section below.

Kernel Mode Cryptographic Module (FIPS.sys)

The following tables identify the specific versions that are validated as well as the operating systems for which testing is valid. Hyperlinks are also provided to the CMVP issued certificate as well as the Security Policy for each. A full listing of cryptographic algorithms supported by each module is provided in the Cryptographic Algorithms section below.

BitLocker® Validated Cryptographic Modules

Microsoft also maintains FIPS 140-2 validation for the BitLocker cryptographic modules. The following tables identify the specific versions that are validated as well as the operating systems for which testing is valid. Hyperlinks are also provided to the CMVP issued certificate as well as the Security Policy for each.

Cryptographic Algorithms

The following tables are organized by cryptographic algorithms with their modes, states, and key sizes. For each algorithm implementation (operating system / platform), there is a link to the Cryptographic Algorithm Validation Program (CAVP) issued certificate.

FIPS186-2:PQG(ver) MOD(1024); SIG(ver) MOD(1024); SHS: Val# 1902DRBG: Val# 258Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical DSA List Val#686.

FIPS186-2:SIG(ver) MOD(1024); SHS: Val# 1773DRBG: Val# 193Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical DSA List Val#645.

FIPS186-2: SIG(ver) MOD(1024); SHS: Val# 784RNG: Val# 448Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical DSA List Val#292.

FIPS186-2: SIG(ver) MOD(1024); SHS: Val# 783RNG: Val# 447Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical DSA List Val#291.

FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 2048 , 3072 , 4096 PubKey Values: 65537 DRBG: Val# 23Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical RSA List Val#559.

FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 2048 , 3072 , 4096 PubKey Values: 65537 Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical RSA List Val#353.

FIPS186-2: ALG[ANSIX9.31]: Key(gen)(MOD: 2048 , 3072 , 4096 PubKey Values: 65537 RNG: Val# 321Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical RSA List Val#258.

FIPS186-2: ALG[RSASSA-PKCS1_V1_5]:SIG(ver): 1024 , 1536 , 2048 , 3072 , 4096 , SHS: SHA-1Val#364Some of the previously validated components for this validation have been removed because they are now non-compliant per the SP800-131A transition. See Historical RSA List Val#81.