Updated : June 17, 2009
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 Approved cryptographic services
Software Developer – Responsible for building software products that utilize
Microsoft validated cryptographic libraries
Document Map
This document is broken into five 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 Validated Components – Explains Microsoft cryptographic
architecture and identifies specific components that are validated.
Microsoft Product Compliance (Procurement Officers) – Provides information
on how Microsoft products are FIPS 140 compliant
Deploying FIPS Compliant Systems (System Integrators) – Describes how to
configure and verify that Microsoft Products are being used in a FIPS compliant
manner.
Developing FIPS Compliant Software (Software Developers) – Identifies how
developers can leverage the Microsoft validated cryptographic libraries to build
FIPS compliant software.
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 used to 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 draft of the standard is currently projected by the
CMVP for a release in the Q2 of 2009.
If the current projected schedule issued
by the CMVP were to hold, testing for FIPS 140-3 will not become mandatory until
late 2010. As before, passing of FIPS 140-3 will not invalidate 140-2 validated
modules. 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 and will be ready to validate its cryptographic modules against this
new version when it is released.
Microsoft 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). 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 Vista kernel mode driver, KSECDD (ksecdd.sys), to
support backward compatibility.
.png)
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.
.png)
Figure 2 - CNG Architecture
While only one option was available for
versions of Windows before Vista and 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
Table 2 – DSS Enhanced Validated Modules
Table 3 – FIPS.sys Validated Modules
CNG Validated Modules
Microsoft actively maintains FIPS 140-2
validation for two CNG libraries:
-
Cryptographic Primitives Library (bcrypt.dll)
-
Kernel Mode Security Support Provider Interface
(ksecdd.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
Table 5 – Ksecdd Validated Modules
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 6 – BitLocker Validations
Microsoft Product Compliance (Procurement Officers)
This section provides information for
Procurement Officers and Auditors who are responsible for ensuring that
Microsoft products utilize FIPS Approved modules. 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 choses to validate only the underlying
cryptographic components. Subsequently, many Windows components and Microsoft
products are built to rely on the CAPI and CNG FIPS-validated cryptographic
libraries. Microsoft components and products use the documented application
programming interfaces (API) for each of the libraries to access various
cryptographic services.
| Exception – BitLocker is an exception to the above. This product, as a whole, is independently FIPS 140 validated |
The following list
of Microsoft components and Products rely on FIPS validated cryptographic
libraries:
-
Schannel Security Package
-
Remote Desktop Protocol (RDP)
Client
-
Encrypting File System (EFS)
-
Microsoft .NET Framework
Applications
-
BitLocker Drive Full-volume
Encryption (Vista and Server 2008 only)
-
IPsec Settings of Windows Firewall
(Vista SP1 or later and Server 2008 only)
Deploying FIPS Compliant Systems (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 Approved Binaries
2a. Setting FIPS Local Policy Flag
- OR -
2b. Follow FIPS Library Security Policy
Step 1 – Selecting/Installing Approved Binaries
Systems Integrators must ensure that all
CAPI and/or CNG libraries installed are in fact 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 above in the
CAPI Validated Modules section above and the list of validated CNG binaries
is identified in the
CNG Validated Modules section.
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.
Important Note (Vista and Server 2008 only) – Additionally, the Systems Integrators must further verify that the following Microsoft components are also FIPS 140 validated: Code Integrity (/windows/system32/ci.dll), Winload OS Loader (/windows/system32/winload.exe), and Boot Manager (/windows/boot/PCAT/bootmgr).
Please see Appendix B for the list of validated versions. |
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 the cryptographic APIs provided by
CAPI and CNG do not require any special flags to be used in FIPS mode, it is
necessary to set this flag to ensure that some Microsoft applications are using
the modules in a FIPS compliant manner.
Important Note: Not all Microsoft components and products check this flag. Some Microsoft products, such as Outlook must be individually configured to user only Approved cryptographic algorithms.
See Step 2b – Follow FIPS Library Security Policy section below for details on these products. |
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 Vista
and later systems using the new-style 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 Settings,
use the left tab to navigate to the Local Policies -> Security Options.
-
Scroll down the right pane and
double-click the ‘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 Settings 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 (Vista and Server 2008 only)
-
IPsec Settings of Windows Firewall
(Vista SP1 or later and Server 2008 only)
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 or later and
Server 2003, the EFS switches from an non-Approved kernel AES implementation
to an approved Three-Key Triple-DES implementation.
-
In Windows Vista and Server 2008,
the EFS implementation continues to use the default AES 256-bit
implementation, which is approved.
-
Microsoft .NET Framework
applications (i.e. Microsoft ASP.NET) only allow algorithm implementations
that are allowewd by 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 Vista and Server 2008, 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, 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 approved
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 above. Simply click on the version
number of the validated cryptographic library to access the Security Policy.
Developing FIPS Compliant Software (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 above. 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 are limiting use of cryptography to only FIPS approved cryptographic algorithms.
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 above in the
CAPI Validated Modules section above 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 above. 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 approved security functions by
generating an exception when an improper .NET class is used for cryptography
(i.e. the cryptographic classes whose names end in “Managed”). These allowed
classes end with “CryptoServiceProvider”, which use the CAPI binaries, or “Cng”,
which use the CNG binaries.
Key Strengths and Validity Periods
NIST Special Publication 800-57 –
Recommendation for Key Management – Part 1: General provides general guidance
and best practices for the management of cryptographic keys. One of the most
important topics discussed in this publication 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. The following table (taken from SP 800-57) identifies the recommended
algorithms and minimum key sizes and their expiration periods.
Table 4: Recommended algorithms
and minimum key sizes
|
Algorithm security lifetimes
|
Symmetric Key Algorithms (Encryption & MAC)
|
FFC
(e.g., DSA, DH)
|
IFC
(e.g., RSA)
|
ECC
(e.g., ECDSA)
|
|
Through 2010 (min. of 80 bits of strength)
|
2TDEA
3TDEA
AES-128
AES-192
AES-256
|
Min.:
L = 1024;
N = 160
|
Min.:
k = 1024
|
Min.:
f = 160
|
|
Through 2030 (min. of 112 bits of strength)
|
3TDEA
AES-128
AES-192
AES-256
|
Min.:
L = 2048;
N = 224
|
Min.:
k = 2048
|
Min.:
f = 224
|
|
Beyond 2030 (min. of 128 bits of strength)
|
AES-128
AES-192
AES-256
|
Min.:
L = 3072;
N = 256
|
Min.:
k = 3072
|
Min.:
f = 256
|
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
:
In short, they are not related. These are two separate security standards with
different 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 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
verified 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, bcrypt.dll or ncrypt.dll. What do I need to do to be FIPS compliant?
Answer: crypt32.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.
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 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).
Additionally,
proper configuration of the underlying operating system is also required.
Please see the NIST Federal Desktop Core Configuration (FDCC) website
(http://nvd.nist.gov/fdcc/index.cfm) for details on how each operating system
must be configured.
Appendix A
CAPI Algorithms Supported
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
CAPI CSPs to support these new algorithms.
|
Note – Currently, no FIPS standard exists for RSA key transport and thus algorithm testing is not available. Until such a standard is developed, NIST only allows the use of RSA encryption for transporting cryptographic keys. |
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 7 – RSAENH Supported Algorithms
|
RSAENH Algorithms
|
Operating System and Certificate #
|
|---|
|
AES (FIPS 197)
-
ECB, CBC
-
128, 192, 256-bit keys
|
-
Windows XP, SP1, and SP2 –
#33
-
Windows XP Professional SP3 –
#781
-
Windows Server 2003 –
#80
-
Windows Server 2003 SP1 –
#290
-
Windows Server 2003 SP2 –
#548
-
Windows Server 2003 SP2 –
#818
|
|
-
ECB, CBC, CFB8
-
128, 192, 256-bit keys
|
-
Windows Vista –
#553
-
Windows Vista Ultimate SP1 –
#739
-
Windows Server 2008 –
#739
|
|
HMAC (FIPS 198)
-
HMAC SHA1, HMAC SHA-256, HMAC SHA384, HMAC SHA 512
-
KS < BS, KS=BS, KS > BS
|
-
Windows XP Professional SP3 –
#428
-
Windows Server 2003 SP2 –
#289
-
Windows Server 2003 SP2 –
#452
-
Windows Vista –
#297
-
Windows Vista Ultimate SP1 –
#407
-
Windows Server 2008 –
#408
|
|
-
HMAC SHA1
-
KS < BS, KS=BS, KS > BS
| -
Windows XP – Vendor affirmed
-
Windows Server 2003 SP1 –
#99
|
|
Triple-DES (FIPS 46-3)
-
ECB, CBC
-
Key Option 1 and 2
| -
Windows 2000 Professional –
#192
-
Windows XP –
#81
-
Windows XP Professional SP3 –
#675
-
Windows Server 2003 SP1 –
#365
-
Windows Server 2003 SP2 –
#544
-
Windows Server 2003 SP2 –
#691
|
|
-
ECB, CBC, CFB8
-
Key Option 1 and 2
|
-
Windows Vista –
#549
-
Windows Vista Ultimate SP1 –
#656
-
Windows Server 2008 –
#656
|
|
SHS (FIPS 180-3)
-
SHA-1
|
-
Windows XP –
#83
-
Windows Server 2003 –
#176
|
|
-
SHA1, SHA-256, SHA384, SHA-512
| -
Windows Server 2003 SP1 –
#364
-
Windows XP Professional SP3 –
#783
-
Windows Server 2003 SP2 –
#613
-
Windows Server 2003 SP2 –
#816
-
Windows Vista –
#618
-
Windows Vista Ultimate SP1 –
#753
-
Windows Server 2008 –
#753
|
|
RNG (FIPS 186-2)
| -
Windows XP Professional SP3 –
#447
-
Windows Server 2003 SP2 –
#316
-
Windows Server 2003 SP2 –
#470
-
Windows Vista –
#321
|
|
DRBG (SP 800-90)
|
-
Windows Vista Ultimate SP1 – Vendor
Affirmed
|
|
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
| -
Windows 2000 – Vendor Affirmed
-
Windows XP – Vendor Affirmed
-
Windows Server 2003 SP1 –
#81
-
Windows Vista Ultimate Edition –
#255
|
|
-
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
| -
Windows XP Professional SP3 –
#371
-
Windows Server 2003 SP2 –
#245
-
Windows Server 2003 SP2 –
#395
-
Windows Vista Ultimate SP1 –
#354
-
Windows Server 2008 –
#355
|
|
-
ANSI X9.31 key generation
-
Mod sizes: 1024, 1536, 2048, 3072, 4096
-
Public Key Values: 65537
|
-
Windows Vista –
#258
-
Windows Vista Ultimate SP1 –
#353
-
Windows Server 2008 –
#353
|
Table 8 – DSS ENH Supported Algorithms
|
DSSENH Algorithms
|
Operating System and Certificate #
|
|---|
|
DSA (FIPS 186-2)
| -
Windows NT 4 SP6 –
#26
-
Windows 2000 –
#29
-
Windows XP, SP1, and SP2 –
#29
-
Windows XP Professional SP3 –
#292
-
Windows Server 2003 –
#95
-
Windows Server 2003 SP1 –
#146
-
Windows Server 2003 SP2 –
#221
-
Windows Vista –
#226
-
Windows Vista Ultimate SP1 –
#281
-
Windows Server 2008 –
#282
|
|
RNG (FIPS 186-2)
| -
Windows Server 2003 SP2 –
#314
-
Windows XP Professional SP3 –
#448
-
Windows Vista –
#321
-
Windows Vista Ultimate SP1 –
#435
|
|
SHS (FIPS 180-3)
-
SHA-1
| -
Windows NT 4 SP6 –
#26
-
Windows 2003 –
#181
-
Windows Server 2003 SP1 –
#385
-
Windows Server 2003 SP2 –
#611
-
Windows XP Professional SP3 –
#784
|
|
-
SHA-1, SHA-256, SHA-384, SHA-512
| -
Windows Vista –
#618
-
Windows Vista Ultimate SP1 –
#753
|
|
Triple-DES (FIPS 46-3)
-
ECB, CBC
-
Key Option 1 and 2
| -
Windows 2000 –
#16
-
Windows XP Professional SP3 –
#676
-
Windows Server 2003 –
#199
-
Windows Server 2003 SP1 –
#381
-
Windows Server 2003 SP2 –
#543
|
|
-
ECB, CBC, CFB8
-
Key Option 1 and 2
| -
Windows Vista –
#549
-
Windows Vista Ultimate SP1 –
#656
-
Windows Server 2008 –
#656
|
Table 9 – FIPS.sys Supported Algorithms
|
FIPS.sys Algorithms
|
Operating System and Certificate #
|
|---|
|
HMAC (FIPS 198)
-
HMAC SHA1
-
KS<BS, KS=BS, KS>BS
| -
Windows XP – Vendor Affirmed
-
Windows XP Professional SP3 –
#429
-
Windows Server 2003 SP2 –
#287
|
|
RNG (FIPS 186-2)
| -
Windows XP Professional SP3 –
#449
-
Windows Server 2003 SP2 –
#313
|
|
SHS (FIPS 180-3)
-
SHA-1
| -
Windows 2000 –
#35
-
Windows XP Professional SP3 –
#785
-
Windows 2003 .Net Windows Server –
#177
-
Windows Server 2003 SP1 –
#371
-
Windows Server 2003 SP2 –
#610
|
Triple-DES (FIPS 46-3)
-
ECB, CBC
-
Key Option 1 and 2
| -
Windows 2000 –
#16
-
Windows XP Professional SP3 –
#677
-
Windows 2003 .Net Windows Server –
#201
-
Windows Server 2003 SP1 –
#370
-
Windows Server 2003 SP2 –
#542
|
CNG Algorithms Supported
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.
| Note – Currently, no FIPS standard exists for RSA key transport and thus algorithm testing is not available. Until such a standard is developed, NIST only allows the use of RSA encryption for transporting cryptographic keys. |
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 10 – Bcrypt Supported Algorithms
|
Bcrypt Algorithms
|
Operating System and Certificate #
|
|---|
|
AES (FIPS 197)
-
ECB, CBC, CFB8
-
128,192,256-bit keys
| -
Windows Vista –
#553
-
Windows Vista Ultimate SP1 –
#739
-
Windows Server 2008 –
#739
|
-
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)
| -
Windows Vista Ultimate SP1 –
#756
-
Windows Server 2008 –
#757
|
|
DSA
(FIPS 186-2)
| -
Windows Vista –
#227
-
Windows Vista Ultimate SP1 –
#283
-
Windows Server 2008 –
#284
|
|
ECDSA(FIPS 186-2)
-
Curves P-256, P-384, and P-521
| -
Windows Vista –
#60
-
Windows Vista Ultimate SP1 –
#82
-
Windows Server 2008 –
#83
|
|
HMAC (FIPS 198)
-
HMAC SHA1, HMAC SHA-256, HMAC SHA384, HMAC SHA 512
-
KS<BS, KS=BS, KS>BS
| -
Windows Vista –
#298
-
Windows Vista Ultimate SP1 –
#412
-
Windows Server 2008 –
#413
|
|
RNG
(FIPS 186-2)
| -
Windows Vista –
#321
-
Windows Vista Ultimate SP1 –
#435
-
Windows Server 2008 –
#435
|
|
RNG (SP800-90)
-
AES-CTR
|
-
Windows Vista Ultimate SP1 – Vendor Affirmed
|
|
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
| -
Windows Vista –
#257
-
Windows Vista Ultimate SP1 –
#357
-
Windows Server 2008 –
#358
|
|
SHS (FIPS 180-3)
-
SHA-1, SHA-256, SHA-384, and SHA-512
| -
Windows Vista –
#618
-
Windows Vista Ultimate SP1 –
#753
-
Windows Server 2008 –
#753
|
|
Triple-DES (FIPS 46-3)
-
ECB, CBC, CFB8
-
Key Option 1 and 2
| -
Windows Vista –
#549
-
Windows Vista Ultimate SP1 –
#656
-
Windows Server 2008 –
#656
|
Table 11 – Kseccdd Supported Algorithms
|
Ksecdd Algorithms
|
Operating System and Certificate #
|
|---|
|
AES (FIPS 197)
-
ECB, CBC, CFB8
-
128,192,256-bit keys
| -
Windows Vista –
#553
-
Windows Vista Ultimate SP1 –
#739
-
Windows Server 2008 –
#739
|
-
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)
| -
Windows Vista Ultimate SP1 –
#756
-
Windows Server 2008 –
#757
|
|
ECDSA (FIPS 186-2)
- Curves P-256, P-384, and P-521
| -
Windows Vista –
#60
-
Windows Vista Ultimate SP1 –
#82
-
Windows Server 2008 –
#83
|
|
HMAC (FIPS 198)
-
HMAC SHA1, HMAC SHA-256, HMAC SHA384, HMAC SHA 512
-
KS<BS, KS=BS, KS>BS
| -
Windows Vista –
#298
-
Windows Vista Ultimate SP1 –
#412
-
Windows Server 2008 –
#413
|
|
RNG (FIPS
186-2)
| -
Windows Vista –
#321
-
Windows Vista Ultimate SP1 –
#435
-
Windows Server 2008 –
#435
|
|
RNG (SP800-90)
- AES-CTR
|
-
Windows Vista Ultimate SP1 – Vendor
Affirmed
|
|
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
| -
Windows Vista –
#257
-
Windows Vista Ultimate SP1 –
#357
-
Windows Server 2008 –
#358
|
|
SHS (FIPS 180-3)
-
SHA-1, SHA-256, SHA-384, and SHA-512
| -
Windows Vista –
#618
-
Windows Vista Ultimate SP1 –
#753
-
Windows Server 2008 –
#753
|
|
Triple-DES (FIPS 46-3)
-
ECB, CBC, CFB8
-
Key Option 1 and 2
| -
Windows Vista –
#549
-
Windows Vista Ultimate SP1 –
#656
-
Windows Server 2008 –
#656
|
Appendix B – Additional Validated Components
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 12 – Code Integrity Validations
Table 13 – Winload OS Loader Validations
Table 14 – Boot Manager Validations
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)
Additional Microsoft References