C RYPTOGRAPHIC P ROTECTION

Cryptography API: Next Generation (CNG) API is the long-term replacement for the CryptoAPI. CNG is designed to be extensible at many levels and cryptography agnostic in behavior. An important feature of CNG is its support for the Suite B algorithms. CNG includes support for Suite B that extends to all

required algorithms: AES (all key sizes), the SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, elliptic curve Diffie Hellman (ECDH), and elliptical curve DSA (ECDSA) over the NIST-standard prime curves P-256, P-384, and P-521.

Protocols such as the Internet Key Exchange (IKE, mainly used in IPsec), and Transport Layer Security (TLS), make use of elliptic curve Diffie-Hellman (ECDH) included in Suite B.

Random number generation (RNG) is provided in Suite B and is implemented in accordance with NIST Special Publication 800-90. Note that while the TOE can generate random numbers using only software-based noise sources, it will also utilize the hardware-software-based noise source available from a TPM chip when one is present. The random number generator is seeded by independent software-based entropy sources, and independent hardware-based entropy sources when a TPM chip is present. CNG

components such as Asymmetric Key Generation, Signing, and the Schannel Protocol Provider use this RNG. The TSF defends against tampering of the random number generation (RNG)/ pseudorandom number generation (PRNG) sources by encapsulating its use of Suite B in Kernel Security Device Driver.

The encryption and decryption operations are performed by independent modules, known as

Cryptographic Service Providers (CSPs). The CSPs, specifically the Cryptographic Primitives Library and kernel security device driver, are FIPS 140-2 Level 1 compliant. The TSF applies validation techniques to generate symmetric keys in accordance with NIST Special Publication 800-57, “Recommendation for Key Management.”

In addition to encryption and decryption services, the TSF provides other cryptographic operations such as hashing, key agreement, and digital signatures. The TSF also provides pseudo random number generation capabilities. These cryptographic capabilities are designed to conform to published standard and compliance with these cryptographic standards has been demonstrated as follows:

Table 6-3 Cryptographic Standards and Evaluation Methods Cryptographic Operation Standard Evaluation Method Encryption/Decryption FIPS 46-3 - 3DES (aka

TDEA) –CBC, ECB, and CFB

NIST CAVP #846 for TECB(e/d; KO 1,2), TCBC(e/d; KO 1,2), TCFB8(e/d; KO 1,2) Encryption/Decryption FIPS 197 - AES – ECB,

CBC, CFB8, CCM, and GCM

NIST CAVP #1168 for ECB(e/d;

128,192,256), CBC(e/d; 128,192,256), CFB8(e/d; 128,192,256); #1178 and

Cryptographic Operation Standard Evaluation Method

#1187 for CCM (KS: 128 , 192 , 256); and

#1177 for CCM (KS: 128, 256)

Digital signature FIPS 186-2 DSA NIST CAVP #385, #386, #390, and #391 for KEYGEN(Y) MOD(1024), SIG(gen) MOD(1024), SIG(ver) MOD(1024)

Digital signature rDSA NIST CAVP #557 and #568 for

ALG[RSASSA-PKCS1_V1_5] SIG(gen), SIG(ver), 1024 , 1536, 2048, 3072, 4096;

#560 and #567 for ALG[RSASSA-PKCS1_V1_5] SIG(gen), SIG(ver), 1024 , 1536, 2048, 3072, 4096 and

ALG[RSASSA-PSS] SIG(gen), SIG(ver), 1024 , 1536, 2048, 3072, 4096 Digital signature ECDSA NIST CAVP #141 and #142 for PKG:

CURVES(P-256, P-384, P-521); SIG(gen):

CURVES(P-256, P-384, P-521); and SIG(ver): CURVES(P-256, P-384, P-521)

Hashing SHA-256, SHA-384,

and SHA-512

NIST CAVP #1081 for SHA-256 (BYTE-only); SHA-384 (BYTE-(BYTE-only); and SHA-512 (BYTE-only)

Keyed-Hash Message Authentication Code

HMAC NIST CAVP #673, #677, #686, and #687 for SHA1; SHA256; HMAC-SHA384; HMAC-SHA512; and #675 for HMAC-SHA1; HMAC-SHA256

Random number generation

NIST SP 800-90 NIST CAVP #27 and #24 for

Dual_EC_DRBG and #23 for (No_df):

AES-256 Random number

generation

FIPS 186-2 NIST CAVP #649 for FIPS 186-2 [ (x-Change Notice); (SHA-1) ] FIPS 186-2 General Purpose [ (x-Change Notice);

(SHA-1) ] Key agreement ECDSA (ANSI

X9.62-1998)

Vendor Affirmed Key agreement ECDH (eliptic curve

Diffie-Hellman) – NIST SP 800-56A

Vendor Affirmed

Key Generation RNG (3DES and AES) The random number was generated using NIST approved random number generators, in particular a NIST SP 800-90 DRNG (certificate #23)

Key Generation RNG (DSA, rDSA, ECDSA, ECDH)

NIST CAVP #385, #386, #390, and #391 for KEYGEN(Y) MOD(1024); #559 for ALG[ANSIX9.31] Key(gen)(MOD: 1024, 1536, 2048, 3072, 4096; PubKey Values:

Cryptographic Operation Standard Evaluation Method

65537); and #141 and #142 for PKG:

CURVES(P-256, P-384, P-521)

Key Zeroization FIPS 140-2 FIPS 140-2 certificates #1319, #1321,

#1326, #1327, #1328, #1329, #1330,

#1331, #1332, #1333, #1334, #1335,

#1336, #1337, #1338, and #1339

The TSF includes a key isolation service designed specifically to host secret and private keys in a

protected process to mitigate tampering or access to sensitive key materials. The TSF performs key entry and output in accordance with FIPS 140-2. The TSF performs a key error detection check on each

transfer of key (internal, intermediate transfers). The TSF prevents archiving of expired (private) signature keys. The TSF destroys non-persistent cryptographic keys – note that all keys subject to destruction are stored within the cryptomodule that was subject to FIPS 140-2 certification - after a cryptographic administrator-defined period of time of inactivity. The TSF overwrites each intermediate storage area for plaintext key/critical cryptographic security parameter (i.e., any storage, such as memory buffers, that is included in the path of such data). This overwriting is performed as follows:

 For non-volatile memories other than EEPROM and Flash, the overwrite is executed three or more times using a different alternating data pattern each time upon the transfer of the key/critical cryptographic security parameter to another location.

 For volatile memory and non-volatile EEPROM and Flash memories, the overwrite is a single direct overwrite consisting of a pseudo random pattern, followed by a read-verify upon the transfer of the key/critical cryptographic security parameter to another location.

SFR Mapping:

The Cryptographic Protection function satisfies the following SFRs:

 FCS_BCM_EXT.1: See Table 6-3 Cryptographic Standards and Evaluation Methods.

 FCS_COP.1a, FCS_COP.1d: The TSF uses the 3DES or AES (128-bit and higher key sizes) algorithm to encrypt user data and only allows the user who encrypted the data to decrypt the data by ensuring that the SID of the subject requesting decryption is the same as the SID of the subject that requested encryption of the data.

 FCS_COP.1a-g: See Table 6-3 Cryptographic Standards and Evaluation Methods.

 FCS_CKM.1a-b: See Table 6-3 Cryptographic Standards and Evaluation Methods.

 FCS_CKM.4: See Table 6-3 Cryptographic Standards and Evaluation Methods.

 FCS_COA_EXT.1: See Table 6-3 Cryptographic Standards and Evaluation Methods.

 FCS_RBG_EXT.1: See Table 6-3 Cryptographic Standards and Evaluation Methods.