.png)
FIPS 140 Evaluation
Introduction
This document provides information on how Microsoft products and libraries comply with the U.S. Federal government standard, Federal Information Processing Standard (FIPS) 140 – Security Requirements for Cryptographic Modules [FIPS 140].
Audience
This document is primarily focused on providing information for three parties:
Procurement Officer – Responsible for verifying that Microsoft products (or even third-party applications) are either FIPS 140 validated or utilize a Microsoft FIPS 140 validated library.
System Integrator – Responsible for ensuring that Microsoft Products are configured properly to use only FIPS 140 validated cryptographic modules.
Software Developer – Responsible for building software products that utilize Microsoft FIPS 140 validated cryptographic libraries.
Document Map
This document is broken into six major sections:
FIPS 140 Overview – Provides an overview of the FIPS 140 standard as well as provides some useful historical information and future developments of the standard.
Microsoft Product Compliance (Information for Procurement Officers) – Provides information on how Microsoft products are FIPS 140 compliant.
Deploying FIPS Compliant Systems (Information for System Integrators) – Describes how to configure and verify that Microsoft Products are being used in a FIPS compliant manner.
Developing FIPS Compliant Software (Information for Software Developers) – Identifies how developers can leverage the Microsoft validated cryptographic libraries to build FIPS compliant software.
Microsoft FIPS 140 Validated Components – Explains Microsoft cryptographic architecture and identifies specific components that are validated.
FAQ – Frequently Asked Questions.
FIPS 140 Overview
FIPS 140 Standard
FIPS 140 is a US 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 National Institute of Standards (NIST) and the Communications Security Establishment of Canada (CSEC).
The current standard defines four-levels of increasing security, 1 thru 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 May 25, 2002. Though many changes exist between these two revisions of the standard, FIPS 140-1 validated products are still valid and federal agencies may purchase or retain FIPS 140-1 validated modules to protect their data.
FIPS 140-2
FIPS 140-2 is currently the active version of the standard.
Development of FIPS 140-3
At this time, the CMVP is developing the next generation of the FIPS standard, 140-3. The first public draft of the standard was released on July 13, 2007 and was subjected to a 90-day public comment period. The second public draft of FIPS 140-3 – the Revised Draft – was released December 11, 2009 and comments were due by March 11, 2010. As of February 2012, NIST has not announced a release date for the FIPS 140-3 standard. Federal agencies requiring the use of FIPS validated cryptographic modules may continue to use and purchase both FIPS 140-1 and 140-2 validated products.
Microsoft FIPS Support Policy
Microsoft actively maintains validation compliance for its cryptographic libraries for each public and/or Service Pack release. Microsoft also continually monitors the development of the FIPS 140-3 standard.
Microsoft Product Compliance (Information for Procurement Officers)
This section provides information for Procurement Officers and Auditors who are responsible for ensuring that Microsoft products with FIPS 140 validated modules are used in their organization. The goal of this section is to provide an overview of the Microsoft developed products and components and explain how the validated cryptographic libraries are used.
Microsoft Product Relationship with CAPI/CNG libraries
Rather than validate individual components and products, Microsoft chooses to validate only the underlying cryptographic components. Subsequently, many Windows components and Microsoft products are built to rely on the Cryptographic API (CAPI) and Cryptographic API: Next Generation (CNG) FIPS 140 validated cryptographic libraries. Windows components and Microsoft products use the documented application programming interfaces (API) for each of the libraries to access various cryptographic services.
The following list contains some of the Windows components and Microsoft products that rely on FIPS 140 validated cryptographic libraries:
- Schannel Security Package
- Remote Desktop Protocol (RDP) Client
- Encrypting File System (EFS)
- Microsoft .NET Framework Applications
- BitLocker® Drive Full-volume Encryption (Windows Vista, Windows Server 2008, or later)
- IPsec Settings of Windows Firewall (Windows Vista SP1, Windows Server 2008, or later)
Deploying FIPS Compliant Systems (Information for System Integrators)
This section provides information for System Integrators and Auditors who are responsible for deploying Microsoft products in a FIPS compliant manner.
There are two primary steps to ensure that Microsoft products operate in a FIPS compliant configuration:
1. Selecting/Installing FIPS 140 Validated Cryptographic Modules
2a. Setting FIPS Local Policy Flag
- OR -
2b. Follow FIPS Library Security Policy
Step 1 – Selecting/Installing FIPS 140 Validated Cryptographic Modules
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 library with the list of validated binaries. The list of validated CAPI binaries is identified in the CAPI Validated Modules section below and the list of validated CNG binaries is identified in the CNG Validated Modules section. There are similar sections for all other validated modules.
The version number of the installed binary is found by right-clicking the library file and clicking on the Version or Details tab. User space libraries are stored in the "windows\system32" directory while the kernel level libraries are stored in the "windows\system32\drivers" directory.
Step 2a – Setting FIPS Local Policy Flag
The Windows operating system provides a Local Policy Setting (System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing), which is used by many Microsoft products to determine if FIPS mode should be enforced. Upon setting this flag, the Microsoft product will enforce the Security Policy of the validated cryptographic library (ensuring that it is used in a FIPS compliant manner).
Note – There is no enforcement of the FIPS policy by the operating system or the validated cryptographic libraries (CAPI or CNG). Instead, each individual application must check this flag and enforce the Security Policy of the validated cryptographic libraries.
Instructions on Setting the FIPS Local Policy Flag
While there are alternative methods for setting the FIPS local policy flag, the following method is included as a guide to users with Administrative access:
- Open the 'Run' menu by clicking Start -> Run or pressing the combination 'Windows Key + R'. On Windows Vista and later systems using the Start Menu, you can use the search box at the bottom of the menu.
- 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.
- Close the properties window by clicking 'Ok' and close the Local Security Policy management console window by clicking the 'X' in the upper right corner, by going to the menu File -> Exit or by pressing 'Alt + F4'.
Microsoft Components and Products That Utilizes FIPS Registry Key
The following list details some of the Microsoft components that use the cryptographic functionality implemented by either CAPI or CNG. When the FIPS Local 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)
- Microsoft .NET Framework Applications
- BitLocker® Drive Full-volume Encryption (Windows Vista, Windows Server 2008, or later)
- IPsec Settings of Windows Firewall (Windows Vista SP1, Windows Server 2008 or later)
Effects of Setting FIPS Local Policy Flag
When setting the FIPS local 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
- If Terminal Services is configured to use TLS for Server Authentication, then only TLS 1.0 will be able to be used.
- If Terminal Services is not configured with TLS, then the Remote Desktop Protocol (RDP) will switch from using RC4 to Three-key Triple-DES encryption with Cipher-Block Chaining. Additionally, the SHA-1 protocol will be used to create message digests and only RDP Client 5.2 or later can connect to the server.
- Windows XP clients using RDP Client 5.2 or later versions can connect to Windows Server 2003, Windows Vista, or Windows Server 2008; however, remote desktop connections to Windows XP or Windows 2000 computers fail.
- In Windows XP pre-SP1, the Encrypting File System (EFS) switches from a non-approved DESX algorithm to Three-key Triple-DES.
- In Windows XP SP1 and Windows Server 2003, the EFS switches from a non-validated kernel AES implementation to a validated Three-Key Triple-DES implementation.
- 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.
- In Windows Vista SP1 and later or Windows Server 2008 and later, only members of the Cryptographic Operators group can edit the crypto settings in the IPsec policy of the Windows Firewall.
Please be aware that selection of FIPS mode can limit product functionality (See http://support.microsoft.com/kb/811833).
Step 2b – Follow FIPS Library Security Policy
Some Microsoft components/products do not check or use the FIPS Local Policy Flag. For these products, one must individually configure each application to ensure that the FIPS 140 validated cryptographic library is used in a compliant manner.
In order to configure the application correctly, one must follow the Security Rules identified in the Security Policy document for the FIPS validated cryptographic library that is installed. Links to each of the Security Policy documents is provided in the Microsoft Validated Components section below. Simply click on the version number of the validated cryptographic library to access the Security Policy.
Developing FIPS Compliant Software (Information for Software Developers)
This section is targeted at developers who wish to build their own applications using the FIPS validated cryptographic libraries.
FIPS Mode of Operation
Each of the validated cryptographic libraries defines a series of rules that must be followed in order to consider the use of the modules to be FIPS compliant. The Security Rules for each validated cryptographic library are specified in the Security Policy document. Links to each of the Security Policy documents is provided in the Microsoft Validated Components section below. Simply click on the version number of the validated cryptographic library to access the Security Policy.
Generally, the key restriction in Microsoft validated cryptographic libraries is limiting use of cryptography to only FIPS Approved cryptographic algorithms, modes, and key sizes.
Using Microsoft Cryptographic Libraries in a FIPS mode of operation
No matter if developing with native languages or using .NET it is important to first check whether or not the CAPI and CNG components for the target system are FIPS validated. The list of validated CAPI binaries is identified in the CAPI Validated Modules section below and the list of validated CNG binaries is identified in the CNG Validated Modules section.
When developing using CAPI or 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 Microsoft Validated Components section below. Simply click on the version number of the validated cryptographic library to access the Security Policy. It is important to remember that setting the FIPS local policy Flag (discussed above) does not affect the behavior of the libraries 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 enforce the use of only validated crypto implementations by generating 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 "CryptoServiceProvider", which use the CAPI binaries, or "Cng", which use the CNG binaries.
This enforcement is “best effort”. Just because .NET doesn’t generate an exception, this doesn’t mean that the algorithm is still approved by NIST.
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.
Microsoft FIPS 140 Validated Components
Overview of CAPI and CNG
Microsoft Cryptography API (CAPI) supports a series of Cryptographic Service Providers (CSP) that can be accessed using a common Cryptographic API (CryptoAPI - see Figure 1). This common API is implemented in a combination of ADVAPI (advapi32.dll) and CRYPT32 (crypt32.dll) before Windows 7. In Windows 7, the CAPI1 router was moved from advapi32.dll to cryptsp.dll. These DLLs act at the System Layer to convert the CryptoAPI calls into CryptoSPI calls. The CryptoSPI is used to interface directly with one of the user mode CSPs, including the validated DSSENH (dssenh.dll) and RSAENH (rsaenh.dll) libraries.
Prior to Windows Vista, there was an additional kernel mode driver (FIPS.sys), which provided cryptographic functionality for applications and drivers at the kernel layer. This kernel mode driver has a separate API and is directly accessed instead of using ADVAPI or CRYPT32. This driver is no longer supported in Windows Vista. However, its APIs are included within the Windows Vista kernel mode driver, KSECDD (ksecdd.sys), to support backward compatibility. These old APIs are deprecated and developers should use the newer Cryptographic API: Next Generation (CNG) in new code.
Figure 1 - MS CAPI Architecture
With Windows Vista came the introduction of Cryptographic API: Next Generation (CNG), which provides a new API to use both kernel and user space (see Figure 2) cryptography. In addition, the need for intermediary DLLs (advapi32.dll and crypt32.dll) is no longer necessary. 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 modules.
Figure 2 - CNG Architecture in Windows Vista and Windows Server 2008
In Windows 7 and Windows Server 2008 R2, the list of FIPS 140-2 validated modules was changed again. 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.
Figure 3 – CNG Architecture in Windows 7 and Windows Server 2008 R2
While only one cryptographic API was available for versions of Windows before Windows Vista and Windows Server 2008, components and applications may use either CAPI or CNG for their cryptographic services. Microsoft strongly recommends using CNG components for new applications as CAPI components are primarily provided for backward compatibility.
CAPI Validated Modules
Microsoft actively maintains FIPS 140 validation for three CAPI CSPs:
- Enhanced Cryptographic Provider (rsaenh.dll)
- Enhanced DSS and Diffie-Hellman Cryptographic Provider (dssenh.dll)
- 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 library is provided in Appendix A – CAPI Supported Algorithms.
Table 1 – RSA Enhanced Validated Modules
|
RSAENH Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
FIPS Version Validated |
|---|---|---|---|
|
Windows NT 4.0 SP6 |
140-1 | ||
|
Windows 95 |
140-1 | ||
|
Windows 98 |
140-1 | ||
|
Windows 2000 |
140-1 | ||
|
Windows 2000 SP1 |
140-1 | ||
|
Windows 2000 SP2 |
140-1 | ||
|
Windows 2000 SP3 |
140-1 | ||
|
Windows XP |
140-1 | ||
|
Windows XP SP1 |
140-1 | ||
|
Windows XP SP2 |
140-1 | ||
|
Windows XP Professional SP3 |
140-2 | ||
|
Windows CE 5.00 and 5.01 |
140-2 | ||
|
Windows Mobile 6.0, 6.1, and 6.5 |
140-2 | ||
|
Windows CE 6.0 and 6.0 R2 |
140-2 | ||
|
Windows Server 2003 |
140-2 | ||
|
Windows Server 2003 SP1 |
140-2 | ||
|
Windows Server 2003 SP2 |
140-2 | ||
|
Windows Server 2003 SP2 |
140-2 | ||
|
Windows Vista Ultimate Edition |
140-2 | ||
|
Windows Vista Ultimate Edition SP1 |
140-2 | ||
|
Windows Server 2008 |
140-2 | ||
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 |
6.1.7600.16385 |
140-2 | |
|
Windows 7 and Windows 7 SP1 |
6.1.7600.16385 |
140-2 |
Table 2 – DSS Enhanced Validated Modules
|
DSSENH Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
FIPS Version Validated |
|---|---|---|---|
|
Microsoft Windows NT 4.0 SP4 |
140-1 | ||
|
Windows NT 4.0 SP6 |
140-1 | ||
|
Windows 95 |
140-1 | ||
|
Windows 98 |
140-1 | ||
|
Windows 2000 |
140-1 | ||
|
Windows 2000 SP1 |
140-1 | ||
|
Windows 2000 SP2 |
140-1 | ||
|
Windows 2000 SP3 |
140-1 | ||
|
Windows XP |
140-1 | ||
|
Windows XP SP2 |
140-1 | ||
|
Windows XP Professional SP3 |
140-2 | ||
|
Windows Server 2003 |
140-2 | ||
|
Windows Server 2003 SP1 |
140-2 | ||
|
Windows Server 2003 SP2 |
140-2 | ||
|
Windows Vista Ultimate Edition |
140-2 | ||
|
Windows Vista Ultimate Edition SP1 |
140-2 | ||
|
Windows Server 2008 |
140-2 | ||
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 |
6.1.7600.16385 |
140-2 | |
|
Windows 7 and Windows 7 SP1 |
6.1.7600.16385 |
140-2 |
Table 3 – FIPS.sys Validated Modules
|
FIPS.sys Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
FIPS Version Validated |
|---|---|---|---|
|
Windows 2000 SP2 or higher |
140-1 | ||
|
Windows XP |
140-1 | ||
|
Windows XP Professional SP3 |
140-2 | ||
|
Windows Server 2003 |
140-2 | ||
|
Windows Server 2003 SP1 |
140-2 | ||
|
Windows Server 2003 SP2 |
140-2 |
CNG Validated Modules
Microsoft actively maintains FIPS 140-2 validation for two CNG libraries in Windows Vista and Windows Server 2008
- Cryptographic Primitives Library (bcrypt.dll)
- Kernel Mode Security Support Provider Interface (ksecdd.sys)
Microsoft actively maintains FIPS 140-2 validation for two CNG libraries in Windows 7 and Windows Server 2008 R2:
- Cryptographic Primitives Library (bcryptprimitives.dll)
- Kernel Mode Cryptographic Primitives Library (cng.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 library is provided in Appendix A – CNG Supported Algorithms.
Table 4 – Bcrypt Validated Modules
|
Bcrypt Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 | ||
|
Windows Server 2008 |
Table 5 – Ksecdd Validated Modules
|
Ksecdd Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 | 6.0.6002.22742 | |
|
Windows Server 2008 | 6.0.6002.22742 |
Table 6 – BCRYPTPRIMITIVES Validated Modules
|
BCRYPTPRIMITIVES Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows 7 and Windows 7 SP1 | ||
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 |
Table 7 – CNG Validated Modules
|
CNG Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows 7 and Windows 7 SP1 | ||
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 |
Foundational Validated Modules
For Windows Vista and Windows Server 2008 and later, Microsoft has also validated three additional components: Code Integrity, Winload OS Loader, and Boot Manager. The validated versions of these components must be installed in order to use the validated cryptographic libraries, in an approved mode of operation.
Table 8 – Code Integrity Validations
|
Code Integrity Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 | ||
|
Windows Server 2008 | ||
|
Windows 7 and Windows 7 SP1 | ||
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 |
Table 9 – Winload OS Loader Validations
|
Winload OS Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 | 6.0.6002.22596 | |
|
Windows Server 2008 | 6.0.6002.22596 | |
|
Windows 7 and Windows 7 SP1 | 6.1.7601.21675 | |
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 | 6.1.7601.21675 |
Table 10 – Boot Manager Validations
|
Boot Manager Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 | ||
|
Windows Server 2008 | ||
|
Windows 7 and Windows 7 SP1 | 6.1.7601.17514 | |
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 | 6.1.7601.17514 |
BitLocker Validated Modules
Microsoft also actively maintains FIPS 140-2 validation for the BitLocker product. 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.
Table 11 – BitLocker Validations
|
BitLocker Validated Operating Systems |
Validated Versions (Links to Security Policy) |
FIPS Certificate # |
|---|---|---|
|
Windows Vista Ultimate Edition | ||
|
Windows Vista Ultimate Edition SP1 |
6.0.6002.22596
| |
|
Windows Server 2008 |
6.0.6002.22596
| |
|
Windows 7 and Windows 7 SP1 |
6.1.7601.21675
| |
|
Windows Server 2008 R2 and Windows Server 2008 R2 SP1 | 6.1.7601.21675 |
FIPS 140 FAQ
The following provides answers to commonly asked questions as it relates to 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 products and/or components that support cryptographic functionality. On the other hand, Common Criteria is designed to help evaluate security functionality of 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 libraries. Each library provides a different set of cryptographic algorithms. If you are required to use only FIPS validated cryptographic libraries, you simply need to verify that the version being used appears on the validation list.
Please see the Microsoft Validated Components section for a complete list of Microsoft validated libraries.
-
My app links against crypt32.dll, cryptsp.dll, advapi32.dll, bcrypt.dll, bcryptprimitives.dll, or ncrypt.dll. What do I need to do to be FIPS compliant?
Answer: crypt32.dll, cryptsp.dll, advapi32.dll, and ncrypt.dll are intermediary libraries that will offload all cryptographic operations to the FIPS validated cryptographic libraries. Bcrypt.dll itself is a validated cryptographic library. 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.
In order to be FIPS compliant, you must first verify that the underlying CAPI or CNG cryptographic library is validated. Once verified, you'll need to confirm that you're using the library correctly in FIPS mode (See Developing FIPS Compliant Software section for details).
The list of CAPI Validated Libraries is identified in this article.
The list of CNG Validated Libraries is also identified in this article.
-
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 library in a FIPS compliant manner. The security rules are defined in the Security Policy for the library 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 library (See Microsoft Validated Components section for links to each policy).
Appendix A
Algorithms Supported by CAPI
The following tables identify the cryptographic algorithms supported by each CSP and the operating system that it runs on. Furthermore, links have been provided to the Cryptographic Algorithm Validation Program (CAVP) issued certificates.
Table 12 – RSAENH Supported Algorithms
|
RSAENH Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197) – ECB, CBC – 128, 192, 256–bit keys | |
|
ECB ( e/d; 128 , 192 , 256 ) CBC ( e/d; 128 , 192 , 256 ) CFB8 ( e/d; 128 , 192 , 256 ) | |
|
HMAC (FIPS 198) – HMAC SHA1, HMAC SHA–256, HMAC SHA384, HMAC SHA 512 – KS < BS, KS=BS, KS > BS | |
|
– HMAC SHA1 – KS < BS, KS=BS, KS > BS |
|
|
Triple–DES (FIPS 46–3) – ECB, CBC – Key Option 1 and 2 | |
|
– ECB, CBC, CFB8 – Key Option 1 and 2 | |
|
SHS (FIPS 180–3) – SHA–1 | |
|
– SHA1, SHA–256, SHA384, SHA–512 | |
|
RNG (FIPS 186–2) | |
|
DRBG (SP 800–90) |
|
|
DRBG [ (No_df): AES–256 ( AES Val#1168 ) ] | |
|
RSA (FIPS 186–2) – PKCS#1 v1.5, signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 | |
|
– ANSI X9.31 signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1 And – PKCS#1 v1.5, signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 | |
|
– ANSI X9.31 key generation – Mod sizes: 1024, 1536, 2048, 3072, 4096 – Public Key Values: 65537 | |
|
ALG[RSASSA–PKCS1_V1_5] SIG(gen); SIG(ver) 1024 , 1536 , 2048 , 3072 , 4096 SHS: SHA–1 Val#1081 , SHA–256 Val#1081 , SHA–384 Val#1081 , SHA–512 Val#1081
|
Table 13 – DSS ENH Supported Algorithms
|
DSSENH Algorithms |
Operating System and Certificate # |
|---|---|
|
DSA (FIPS 186-2) |
|
|
RNG (FIPS 186-2) | |
|
SHS (FIPS 180-3) - SHA-1 | |
|
Triple-DES (FIPS 46-3) - ECB, CBC - Key Option 1 and 2 | |
|
- ECB, CBC, CFB8 - Key Option 1 and 2 | |
|
Triple-DES MAC |
Table 14 – FIPS.sys Supported Algorithms
|
FIPS.sys Algorithms |
Operating System and Certificate # |
|---|---|
|
HMAC (FIPS 198) - HMAC SHA1 - KS<BS, KS=BS, KS>BS | |
|
RNG (FIPS 186-2) | |
|
SHS (FIPS 180-3) - SHA-1 | |
|
Triple-DES (FIPS 46-3) - ECB, CBC - Key Option 1 and 2 |
Algorithms Supported by CNG
Microsoft actively follows US government standards development in the field of cryptography. As new US government approved algorithms are developed and added, Microsoft will update the existing CNG components to support these new algorithms.
The following tables identify the cryptographic algorithms supported by each CNG component and the operating system that it runs on. Furthermore, links have been provided to the Cryptographic Algorithm Validation Program (CAVP) issued certificates.
Table 15 – Bcrypt Supported Algorithms
|
Bcrypt Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197) – ECB, CBC, CFB8 – 128,192,256–bit keys | |
|
– CCM (KS: 128, 192, 256) (Assoc. Data Len Range: 0 – 0, 2^16) (Payload Length Range: 1 – 32) (Nonce Length(s): 7 8 9 10 11 12 13) (Tag Length(s): 4 6 8 10 12 14 16) | |
|
DSA (FIPS 186–2) | |
|
ECDSA(FIPS 186–2) – Curves P–256, P–384, and P–521 | |
|
HMAC (FIPS 198) – HMAC SHA1, HMAC SHA–256, HMAC SHA384, HMAC SHA 512 – KS<BS, KS=BS, KS>BS | |
|
RNG (FIPS 186–2) | |
|
RNG (SP800–90) – AES–CTR |
|
|
RSA (FIPS 186–2) – PKCS#1 v1.5, signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 And – Probabilistic Signature Scheme (PSS), signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 | |
|
SHS (FIPS 180–3) – SHA–1, SHA–256, SHA–384, and SHA–512 | |
|
Triple–DES (FIPS 46–3) – ECB, CBC, CFB8 – Key Option 1 and 2 |
Table 16 –Supported Algorithms Implemented in KSecDD
|
KSecDD Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197) – ECB, CBC, CFB8 – 128,192,256–bit keys | |
|
– CCM (KS: 128, 192, 256) (Assoc. Data Len Range: 0 – 0, 2^16) (Payload Length Range: 1 – 32) (Nonce Length(s): 7 8 9 10 11 12 13) (Tag Length(s): 4 6 8 10 12 14 16) | |
|
ECDSA (FIPS 186–2) – Curves P–256, P–384, and P–521 | |
|
HMAC (FIPS 198) – HMAC SHA1, HMAC SHA–256, HMAC SHA384, HMAC SHA 512 – KS<BS, KS=BS, KS>BS | |
|
RNG (FIPS 186–2) | |
|
RNG (SP800–90) – AES–CTR |
|
|
RSA (FIPS 186–2) – PKCS#1 v1.5, signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 And – Probabilistic Signature Scheme (PSS), signature generation and verification – Mod sizes: 1024, 1536, 2048, 3072, 4096 – SHS: SHA–1/256/384/512 | |
|
SHS (FIPS 180–3) – SHA–1, SHA–256, SHA–384, and SHA–512 | |
|
Triple–DES (FIPS 46–3) – ECB, CBC, CFB8 – Key Option 1 and 2 |
Table 17 –Supported Algorithms in BCRYPTPRIMITIVES
|
BCRYPTPRIMITIVES Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197)
– ECB, CBC, CFB8 – 128,192,256–bit keys | |
|
– CCM (KS: 128, 192, 256) (Assoc. Data Len Range: 0 – 0, 2^16) (Payload Length Range: 0 – 32) (Nonce Length(s): 7 8 9 10 11 12 13) (Tag Length(s): 4 6 8 10 12 14 16) | |
|
AES GCM | |
|
AES GMAC | |
|
DRBG [ (No_df): AES–256 ( AES Val#1168 ) ] | |
|
Dual_EC_DRBG ( SHS Val#1081 ) [ P–256: SHA–256] |
|
|
Dual_EC_DRBG ( ECDSA Val#142 ) ( SHS Val#1081 ) [ P–256: SHA–256] |
|
|
DSA (FIPS 186–2) | |
|
ECDSA(FIPS 186–2) – Curves P–256, P–384, and P–521 | |
|
HMAC (FIPS 198) – HMAC SHA1, HMAC SHA–256, HMAC SHA384, HMAC SHA 512 – KS<BS, KS=BS, KS>BS | |
|
KAS (SP 800–56A) key agreement key establishment methodology provides 80 to 256 bits of encryption strength |
|
|
RNG (FIPS 186–2) | |
|
RSA ALG[ANSIX9.31] Key(gen) (MOD: 1024 , 1536 , 2048 , 3072 , 4096 PubKey Values: 65537 ) DRBG: Val# 23
| |
|
RSA ALG[RSASSA–PKCS1_V1_5] SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 SHS: SHA–1 Val#1081 , SHA–256 Val#1081, SHA–384 Val#1081 , SHA–512 Val#1081
ALG[RSASSA–PSS] SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 SHS: SHA–1 Val#1081 , SHA–256 Val#1081, SHA–384 Val#1081 , SHA–512 Val#1081 | |
|
SHS (FIPS 180–3) – SHA–1, SHA–256, SHA–384, and SHA–512 | |
|
Triple–DES (FIPS 46–3) – ECB, CBC, CFB8 – Key Option 1 and 2 |
Table 18 –Supported Algorithms in BitLocker
|
BitLocker Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197)
ECB ( e/d; 128 , 192 , 256 ) CBC ( e/d; 128 , 192 , 256 ) CFB8 ( e/d; 128 , 192 , 256 ) | |
|
CCM (KS: 128, 256) (Assoc. Data Len Range: 0 – 8) (Payload Length Range: 4 – 32) (Nonce Length(s): 7 8 12 13) (Tag Length(s): 4 6 8 14 16) | |
|
CBC ( e/d; 128 , 256 ) CCM (KS: 128 , 256 ) (Assoc. Data Len Range: 0 – 8 ) (Payload Length Range: 4 – 32 ) (Nonce Length(s): 7 8 12 13 ) (Tag Length(s): 4 6 8 14 16 ) |
|
|
HMAC–SHA1 (Key Sizes Ranges Tested: KS<BS ) SHS Val#1081 HMAC–SHA256 ( Key Size Ranges Tested: KS<BS ) SHS Val#1081 | |
|
HMAC–SHA1 (Key Sizes Ranges Tested: KS<BS ) SHS Val#753 HMAC–SHA256 ( Key Size Ranges Tested: KS<BS ) SHS Val#753 | |
|
SHA–1 (BYTE–only) SHA–256 (BYTE–only) SHA–384 (BYTE–only) SHA–512 (BYTE–only) | |
|
SHA–1 (BYTE–only) SHA–256 (BYTE–only) |
|
Table 19 –Supported Algorithms in CNG.sys
|
CNG Algorithms |
Operating System and Certificate # |
|---|---|
|
AES (FIPS 197) ECB ( e/d; 128 , 192 , 256 ) CBC ( e/d; 128 , 192 , 256 ) CFB8 ( e/d; 128 , 192 , 256 ) | |
|
CCM (KS: 128 , 192 , 256 ) (Assoc. Data Len Range: 0 – 0 , 2^16 ) (Payload Length Range: 0 – 32 ) ( Nonce Length(s): 7 8 9 10 11 12 13 ) (Tag Length(s): 4 6 8 10 12 14 16 ) | |
|
AES GCM | |
|
AES GMAC | |
|
DRBG Dual_EC_DRBG ( ECDSA Val#142 ) ( SHS Val#1081 ) [ P–256: SHA–256] |
|
|
DRBG Dual_EC_DRBG ( SHS Val#1081 ) [ P–256: SHA–256] |
|
|
DRBG [ (No_df): AES–256 ( AES Val#1168 ) ] | |
|
ECDSA PKG: CURVES( P–256 P–384 P–521 ) SIG(gen): CURVES( P–256 P–384 P–521 ) SIG(ver): CURVES( P–256 P–384 P–521 ) SHS: Val#1081 DRBG: Val# 23 | |
|
HMAC–SHA1 (Key Sizes Ranges Tested: KS<BS KS=BS KS>BS ) SHS Val#1081 HMAC–SHA256 ( Key Size Ranges Tested: KS<BS KS=BS KS>BS ) SHS Val#1081 HMAC–SHA384 ( Key Size Ranges Tested: KS<BS KS=BS KS>BS ) SHS Val#1081 HMAC–SHA512 ( Key Size Ranges Tested: KS<BS KS=BS KS>BS ) SHS Val#1081 | |
|
KAS (SP 800–56A) key agreement key establishment methodology provides between 80 and 256 bits of encryption strength |
|
|
RNG FIPS 186–2 [ (x–Change Notice); (SHA–1) ] FIPS 186–2 General Purpose [ (x–Change Notice); (SHA–1) ] | |
|
RSA ALG[ANSIX9.31] Key(gen)(MOD: 1024 , 1536 , 2048 , 3072 , 4096 PubKey Values: 65537 ) DRBG: Val# 23 | |
|
ALG[RSASSA–PKCS1_V1_5]; SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 SHS: SHA–1 Val#1081 , SHA–256 Val#1081 , SHA–384 Val#1081 , SHA–512 Val#1081 ALG[RSASSA–PSS]; SIG(gen); SIG(ver); 1024 , 1536 , 2048 , 3072 , 4096 SHS: SHA–1 Val#1081 , SHA–256 Val#1081 , SHA–384 Val#1081 , SHA–512 Val#1081 | |
|
SHS SHA–1 (BYTE–only) SHA–256 (BYTE–only) SHA–384 (BYTE–only) SHA–512 (BYTE–only) | |
|
Triple–DES TECB(e/d; KO 1,2) TCBC(e/d; KO 1,2) TCFB8(e/d; KO 1,2) |
References
[FIPS 140] - FIPS 140-2, Security Requirements for Cryptographic Modules
[FIPS FAQ] - Cryptographic Module Validation Program (CMVP) FAQ
[SP 800-57] - Recommendation for Key Management – Part 1: General (Revised)
[SP 800-131A] - Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths
Additional Microsoft References
Enabling FIPS mode - http://support.microsoft.com/kb/811833
Cipher Suites in Schannel - http://msdn.microsoft.com/en-us/library/aa374757(VS.85).aspx
