Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 (Anniversary Update) Microsoft Windows Server 2016

6.FAU_GEN.1.1

The evaluator shall check the administrative guide and ensure that it lists all of the auditable events. The evaluator shall check to make sure that every audit event type selected in the ST is included.

The evaluator shall test the OS's ability to correctly generate audit records by having the TOE generate audit records for the events listed in the ST. This should include all instance types of an event specified. When verifying the test results, the evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record have the proper entries.

7.FAU_GEN.1.2

The evaluator shall check the administrative guide and ensure that it provides a format for audit records. Each audit record format type must be covered, along with a brief description of each field. The evaluator shall ensure that the fields contains the information required.

The evaluator shall test the OS's ability to correctly generate audit records by having the TOE generate audit records for the events listed in the ST. The evaluator shall ensure the audit records generated during testing match the format specified in the administrative guide, and that the fields in each audit record provide the required information.

7.1.1.1Cryptographic Support (FCS)

7.1.1.1.1Cryptographic Key Generation (FCS_CKM.1(1))

The evaluator will ensure that the TSS identifies the key sizes supported by the OS. If the ST specifies more than one scheme, the evaluator will examine the TSS to verify that it identifies the usage for each scheme.

The evaluator will verify that the AGD guidance instructs the administrator how to configure the OS to use the selected key generation scheme(s) and key size(s) for all uses defined in this PP.

Assurance Activity Note: The following tests may require the vendor to furnish a developer environment and developer tools that are typically not available to end­users of the OS.

Key Generation for FIPS PUB 186­4 RSA Schemes

The evaluator will verify the implementation of RSA Key Generation by the OS using the Key Generation test. This test verifies the ability of the TSF to correctly produce values for the key components including the public verification exponent e, the private prime factors p and q, the public modulus n and the calculation of the private signature exponent d. Key Pair generation specifies 5 ways (or methods) to generate the primes p and q. These include:

1. 
   Random Primes:
   

• 
  Provable primes
  
• 
  Probable primes
  

2. 
   Primes with Conditions:
   

• 
  Primes p1, p2, q1,q2, p and q shall all be provable primes
  
• 
  Primes p1, p2, q1, and q2 shall be provable primes and p and q shall be probable primes
  
• 
  Primes p1, p2, q1,q2, p and q shall all be probable primes
  

To test the key generation method for the Random Provable primes method and for all the Primes with Conditions methods, the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair. This includes the random seed(s), the public exponent of the RSA key, and the desired key length. For each key length supported, the evaluator shall have the TSF generate 25 key pairs. The evaluator will verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated from a known good implementation.

If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator will have the TSF generate 10 keys pairs for each supported key length nlen and verify:

• 
  n = p ⋅ q,
  
• 
  p and q are probably prime according to Miller­Rabin tests,
  
• 
  GCD(p­1,e) = 1,
  
• 
  GCD(q­1,e) = 1,
  
• 
  2¹⁶ ≤ e ≤ 2²⁵⁶ and e is an odd integer,
  
• 
  p­q| > 2^{nlen/2 - 100},
  
• 
  p ≥ 2^{nlen/2 – 1/2},
  
• 
  q ≥ 2^{nlen/2 – 1/2},
  
• 
  2^(nlen/2) < d < LCM(p­1,q­1),
  
• 
  e ⋅ d = 1 mod LCM(p­1,q­1).
  

Key Generation for ANSI X9.31­1998 RSA Schemes

If the TSF implements the ANSI X9.31­1998 scheme, the evaluator will check to ensure that the TSS describes how the key­pairs are generated. In order to show that the TSF implementation complies with ANSI X9.31­1998, the evaluator will ensure that the TSS contains the following information:

• 
  The TSS shall list all sections of the standard to which the OS complies;
  
• 
  For each applicable section listed in the TSS, for all statements that are not "shall" (that is, "shall not", "should", and "should not") , if the OS implements such options it shall be described in the TSS. If the included functionality is indicated as "shall not" or "should not" in the standard, the TSS shall provide a rationale for why this will not adversely affect the security policy implemented by the OS;
  
• 
  For each applicable section of Appendix B, any omission of functionality related to "shall" or “should” statements shall be described.
  

Key Generation for Elliptic Curve Cryptography (ECC)

FIPS 186­4 ECC Key Generation Test

For each supported NIST curve, i.e., P­256, P­384 and P­521, the evaluator will require the implementation under test (IUT) to generate 10 private/public key pairs. The private key shall be generated using an approved random bit generator (RBG). To determine correctness, the evaluator will submit the generated key pairs to the public key verification (PKV) function of a known good implementation.

FIPS 186­4 Public Key Verification (PKV) Test

For each supported NIST curve, i.e., P­256, P­384 and P­521, the evaluator will generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator will obtain in response a set of 10 PASS/FAIL values.

7.1.1.1.2Cryptographic Key Establishment (FCS_CKM.2(1))

The evaluator will ensure that the supported key establishment schemes correspond to the key generation schemes identified in FCS_CKM.1.1. If the ST specifies more than one scheme, the evaluator will examine the TSS to verify that it identifies the usage for each scheme.

The evaluator will verify that the AGD guidance instructs the administrator how to configure the OS to use the selected key establishment scheme(s).

Assurance Activity Note: The following tests require the developer to provide access to a test platform that provides the evaluator with tools that are typically not found on factory products.

Key Establishment Schemes

The evaluator will verify the implementation of the key establishment schemes supported by the OS using the applicable tests below.

SP800­56A Key Establishment Schemes

The evaluator will verify the OS's implementation of SP800-56A key agreement schemes using the following Function and Validity tests. These validation tests for each key agreement scheme verify that the OS has implemented the components of the key agreement scheme according to the specifications in the Recommendation. These components include the calculation of the discrete logarithm cryptography (DLC) primitives (the shared secret value Z) and the calculation of the derived keying material (DKM) via the Key Derivation Function (KDF). If key confirmation is supported, the evaluator will also verify that the components of key confirmation have been implemented correctly, using the test procedures described below. This includes the parsing of the DKM, the generation of MAC data and the calculation of MAC tag.

Function Test

The Function test verifies the ability of the OS to implement the key agreement schemes correctly. To conduct this test the evaluator shall generate or obtain test vectors from a known good implementation of the OS's supported schemes. For each supported key agreement scheme­key agreement role combination, KDF type, and, if supported, key confirmation role­ key confirmation type combination, the tester shall generate 10 sets of test vectors. The data set consists of the NIST approved curve (ECC) per 10 sets of public keys. These keys are static, ephemeral or both depending on the scheme being tested.

The evaluator will obtain the DKM, the corresponding OS's public keys (static and/or ephemeral), the MAC tag(s), and any inputs used in the KDF, such as the

Other Information field OI and OS id fields.

If the OS does not use a KDF defined in SP 800­56A, the evaluator will obtain only the public keys and the hashed value of the shared secret.

The evaluator will verify the correctness of the TSF’s implementation of a given scheme by using a known good implementation to calculate the shared secret value, derive the keying material DKM, and compare hashes or MAC tags generated from these values.

If key confirmation is supported, the OS shall perform the above for each implemented approved MAC algorithm.

Validity Test

The Validity test verifies the ability of the OS to recognize another party’s valid and invalid key agreement results with or without key confirmation. To conduct this test, the evaluator will obtain a list of the supporting cryptographic functions included in the SP800­56A key agreement implementation to determine which errors the OS should be able to recognize. The evaluator generates a set of 30 test vectors consisting of data sets including domain parameter values or NIST approved curves, the evaluator’s public keys, the OS’s public/private key pairs, MAC tag, and any inputs used in the KDF, such as the other info and OS id fields.

The evaluator will inject an error in some of the test vectors to test that the OS recognizes invalid key agreement results caused by the following fields being incorrect: the shared secret value Z, the DKM, the other information field OI, the data to be MAC'd, or the generated MAC tag. If the OS contains the full or partial (only ECC) public key validation, the evaluator will also individually inject errors in both parties’ static public keys, both parties’ ephemeral public keys and the OS’s static private key to assure the OS detects errors in the public key validation function and/or the partial key validation function (in ECC only). At least two of the test vectors shall remain unmodified and therefore should result in valid key agreement results (they should pass).

The OS shall use these modified test vectors to emulate the key agreement scheme using the corresponding parameters. The evaluator will compare the OS’s results with the results using a known good implementation verifying that the OS detects these errors.

SP800­56B Key Establishment Schemes

The evaluator will verify that the TSS describes whether the OS acts as a sender, a recipient, or both for RSA­based key establishment schemes.

If the OS acts as a sender, the following assurance activity shall be performed to ensure the proper operation of every OS supported combination of RSA­based key establishment scheme:

To conduct this test the evaluator will generate or obtain test vectors from a known good implementation of the OS's supported schemes. For each combination of supported key establishment scheme and its options (with or without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS­OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA public key, the plaintext keying material, any additional input parameters if applicable, the MAC key and MAC tag if key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator shall perform a key establishment encryption operation on the OS with the same inputs (in cases where key confirmation is incorporated, the test shall use the MAC key from the test vector instead of the randomly generated MAC key used in normal operation) and ensure that the outputted ciphertext is equivalent to the ciphertext in the test vector.

If the OS acts as a receiver, the following assurance activities shall be performed to ensure the proper operation of every OS supported combination of RSA­based key establishment scheme:

To conduct this test the evaluator will generate or obtain test vectors from a known good implementation of the OS's supported schemes. For each combination of supported key establishment scheme and its options (with our without key confirmation if supported, for each supported key confirmation MAC function if key confirmation is supported, and for each supported mask generation function if KTS­OAEP is supported), the tester shall generate 10 sets of test vectors. Each test vector shall include the RSA private key, the plaintext keying material, any additional input parameters if applicable, the MAC tag in cases where key confirmation is incorporated, and the outputted ciphertext. For each test vector, the evaluator will perform the key establishment decryption operation on the OS and ensure that the outputted plaintext keying material is equivalent to the plaintext keying material in the test vector. In cases where key confirmation is incorporated, the evaluator will perform the key confirmation steps and ensure that the outputted MAC tag is equivalent to the MAC tag in the test vector.

The evaluator will ensure that the TSS describes how the OS handles decryption errors. In accordance with NIST Special Publication 800­56B, the OS must not reveal the particular error that occurred, either through the contents of any outputted or logged error message or through timing variations. If KTS­OAEP is supported, the evaluator will create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800­56B section 7.2.2.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each. If KTS­KEM­KWS is supported, the evaluator will create separate contrived ciphertext values that trigger each of the three decryption error checks described in NIST Special Publication 800­56B section 7.2.3.3, ensure that each decryption attempt results in an error, and ensure that any outputted or logged error message is identical for each.

7.1.1.1.3Cryptographic Key Destruction (FCS_CKM_EXT.3)

The evaluator will check to ensure the TSS lists each type of key material and its origin and storage location. The evaluator will verify that the TSS describes when each type of key material is cleared. For each software key clearing situation the evaluator will repeat the following test.

• 
  Test 1: The evaluator will utilize appropriate combinations of specialized operational environment and development tools (debuggers, simulators, etc.) for the TOE and instrumented TOE builds to test that keys are cleared correctly, including all intermediate copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key. Cryptographic TOE implementations in software shall be loaded and exercised under a debugger to perform such tests. The evaluator will perform the following steps for each key subject to clearing, including intermediate copies of keys that are persisted encrypted by the TOE:
  

1. 
   Load the instrumented TOE build in a debugger.
   
2. 
   Record the value of the key in the TOE subject to clearing.
   
3. 
   Cause the TOE to perform a normal cryptographic processing with the key from #1.
   
4. 
   Cause the TOE to clear the key.
   
5. 
   Cause the TOE to stop the execution but not exit.
   
6. 
   Cause the TOE to dump the entire memory footprint of the TOE into a binary file.
   
7. 
   Search the content of the binary file created in #4 for instances of the known key value from #1. The test succeeds if no copies of the key from #1 are found in step #7 above and fails otherwise.
   

The evaluator will perform this test on all keys, including those persisted in encrypted form, to ensure intermediate copies are cleared.

7.1.1.1.4Cryptographic Operation for Encryption / Decryption (FCS_COP.1(SYM))

The evaluator will verify that the AGD documents contains instructions required to configure the OS to use the required modes and key sizes. The evaluator will execute all instructions as specified to configure the OS to the appropriate state. The evaluator will perform all of the following tests for each algorithm implemented by the OS and used to satisfy the requirements of this PP:

AES­CBC Known Answer Tests

There are four Known Answer Tests (KATs), described below. In all KATs, the plaintext, ciphertext, and IV values shall be 128­bit blocks. The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator will compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

• 
  KAT­1. To test the encrypt functionality of AES­CBC, the evaluator will supply a set of 10 plaintext values and obtain the ciphertext value that results from AESCBC encryption of the given plaintext using a key value of all zeros and an IV of all zeros. Five plaintext values shall be encrypted with a 128­bit all­zeros key, and the other five shall be encrypted with a 256­bit all­ zeros key. To test the decrypt functionality of AES­CBC, the evaluator will perform the same test as for encrypt, using 10 ciphertext values as input and AES­CBC decryption.
  
• 
  KAT­2. To test the encrypt functionality of AES­CBC, the evaluator will supply a set of 10 key values and obtain the ciphertext value that results from AES­CBC encryption of an all­zeros plaintext using the given key value and an IV of all zeros. Five of the keys shall be 128­bit keys, and the other five shall be 256­bit keys. To test the decrypt functionality of AES­CBC, the evaluator will perform the same test as for encrypt, using an all­zero ciphertext value as input and AESCBC decryption.
  
• 
  KAT­3. To test the encrypt functionality of AES­CBC, the evaluator will supply the two sets of key values described below and obtain the ciphertext value that results from AES encryption of an all­zeros plaintext using the given key value and an IV of all zeros. The first set of keys shall have 128 128­bit keys, and the second set shall have 256 256­bit keys. Key i in each set shall have the leftmost i bits be ones and the rightmost N­i bits be zeros, for i in [1,N]. To test the decrypt functionality of AES­CBC, the evaluator will supply the two sets of key and ciphertext value pairs described below and obtain the plaintext value that results from AES­CBC decryption of the given ciphertext using the given key and an IV of all zeros. The first set of key/ciphertext pairs shall have 128 128­bit key/ciphertext pairs, and the second set of key/ciphertext pairs shall have 256 256­bit key/ciphertext pairs. Key i in each set shall have the leftmost i bits be ones and the rightmost N­i bits be zeros, for i in [1,N]. The ciphertext value in each pair shall be the value that results in an all­zeros plaintext when decrypted with its corresponding key.
  
• 
  KAT­4. To test the encrypt functionality of AES­CBC, the evaluator will supply the set of 128 plaintext values described below and obtain the two ciphertext values that result from AES­CBC encryption of the given plaintext using a 128­bit key value of all zeros with an IV of all zeros and using a 256­bit key value of all zeros with an IV of all zeros, respectively. Plaintext value i in each set shall have the leftmost i bits be ones and the rightmost 128­i bits be zeros, for i in [1,128].
  

To test the decrypt functionality of AES­CBC, the evaluator will perform the same test as for encrypt, using ciphertext values of the same form as the plaintext in the encrypt test as input and AES­CBC decryption.

AES­CBC Multi­Block Message Test

The evaluator will test the encrypt functionality by encrypting an i­block message where 1 < i ≤ 10. The evaluator will choose a key, an IV and plaintext message of length i blocks and encrypt the message, using the mode to be tested, with the chosen key and IV. The ciphertext shall be compared to the result of encrypting the same plaintext message with the same key and IV using a known good implementation. The evaluator will also test the decrypt functionality for each mode by decrypting an i­block message where 1 < i ≤10. The evaluator will choose a key, an IV and a ciphertext message of length i blocks and decrypt the message, using the mode to be tested, with the chosen key and IV. The plaintext shall be compared to the result of decrypting the same ciphertext message with the same key and IV using a known good implementation.

AES­CBC Monte Carlo Tests

The evaluator will test the encrypt functionality using a set of 200 plaintext, IV, and key 3­ tuples. 100 of these shall use 128 bit keys, and 100 shall use 256 bit keys. The plaintext and IV values shall be 128­bit blocks. For each 3­tuple, 1000 iterations shall be run as follows:

# Input: PT, IV, Key

for i = 1 to 1000:

if i == 1:

CT[1] = AES-CBC-Encrypt(Key, IV, PT)

PT = IV

else:

CT[i] = AES-CBC-Encrypt(Key, PT)

PT = CT[i-1]

The ciphertext computed in the 1000th iteration (i.e., CT[1000]) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.

The evaluator will test the decrypt functionality using the same test as for encrypt, exchanging CT and PT and replacing AES­CBC­Encrypt with AES­CBC­Decrypt.

AES­GCM Monte Carlo Tests

The evaluator will test the authenticated encrypt functionality of AES­GCM for each combination of the following input parameter lengths:

• 
  128 bit and 256 bit keys
  
• 
  Two plaintext lengths. One of the plaintext lengths shall be a non­zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.
  
• 
  Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non­zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.
  
• 
  Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested.
  

The evaluator will test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES­GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.

The evaluator will test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5­tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator will compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

AES­CCM Tests

The evaluator will test the generation­encryption and decryption­verification functionality of AES­CCM for the following input parameter and tag lengths:

• 
  128 bit and 256 bit keys
  
• 
  Two payload lengths. One payload length shall be the shortest supported payload length, greater than or equal to zero bytes. The other payload length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits).
  
• 
  Two or three associated data lengths. One associated data length shall be 0, if supported. One associated data length shall be the shortest supported payload length, greater than or equal to zero bytes. One associated data length shall be the longest supported payload length, less than or equal to 32 bytes (256 bits). If the implementation supports an associated data length of 2 16 bytes, an associated data length of 216 bytes shall be tested.
  
• 
  Nonce lengths. All supported nonce lengths between 7 and 13 bytes, inclusive, shall be tested.
  
• 
  Tag lengths. All supported tag lengths of 4, 6, 8, 10, 12, 14 and 16 bytes shall be tested.
  

To test the generation­encryption functionality of AES­CCM, the evaluator will perform the following four tests:

• 
  Test 1: For EACH supported key and associated data length and ANY supported payload, nonce and tag length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.
  
• 
  Test 2: For EACH supported key and payload length and ANY supported associated data, nonce and tag length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext.
  
• 
  Test 3: For EACH supported key and nonce length and ANY supported associated data, payload and tag length, the evaluator will supply one key value and 10 associated data, payload and nonce value 3­tuples and obtain the resulting ciphertext.
  
• 
  Test 4: For EACH supported key and tag length and ANY supported associated data, payload and nonce length, the evaluator will supply one key value, one nonce value and 10 pairs of associated data and payload values and obtain the resulting ciphertext. To determine correctness in each of the above tests, the evaluator will compare the ciphertext with the result of generation­encryption of the same inputs with a known good implementation.
  

To test the decryption­verification functionality of AES­CCM, for EACH combination of supported associated data length, payload length, nonce length and tag length, the evaluator shall supply a key value and 15 nonce, associated data and ciphertext 3­tuples and obtain either a FAIL result or a PASS result with the decrypted payload. The evaluator will supply 10 tuples that should FAIL and 5 that should PASS per set of 15.

Additionally, the evaluator will use tests from the IEEE 802.11­02/362r6 document “Proposed Test vectors for IEEE 802.11 TGi”, dated September 10, 2002, Section 2.1 AESCCMP Encapsulation Example and Section 2.2 Additional AES CCMP Test Vectors to further verify the IEEE 802.11­2007 implementation of AES­CCMP.

AES­GCM Test

The evaluator will test the authenticated encrypt functionality of AES­GCM for each combination of the following input parameter lengths:

• 
  128 bit and 256 bit keys
  
• 
  Two plaintext lengths. One of the plaintext lengths shall be a non­zero integer multiple of 128 bits, if supported. The other plaintext length shall not be an integer multiple of 128 bits, if supported.
  
• 
  Three AAD lengths. One AAD length shall be 0, if supported. One AAD length shall be a non­zero integer multiple of 128 bits, if supported. One AAD length shall not be an integer multiple of 128 bits, if supported.
  
• 
  Two IV lengths. If 96 bit IV is supported, 96 bits shall be one of the two IV lengths tested.
  

The evaluator will test the encrypt functionality using a set of 10 key, plaintext, AAD, and IV tuples for each combination of parameter lengths above and obtain the ciphertext value and tag that results from AES­GCM authenticated encrypt. Each supported tag length shall be tested at least once per set of 10. The IV value may be supplied by the evaluator or the implementation being tested, as long as it is known.

The evaluator will test the decrypt functionality using a set of 10 key, ciphertext, tag, AAD, and IV 5­tuples for each combination of parameter lengths above and obtain a Pass/Fail result on authentication and the decrypted plaintext if Pass. The set shall include five tuples that Pass and five that Fail.

The results from each test may either be obtained by the evaluator directly or by supplying the inputs to the implementer and receiving the results in response. To determine correctness, the evaluator will compare the resulting values to those obtained by submitting the same inputs to a known good implementation.

XTS­AES Test

The evaluator will test the encrypt functionality of XTS­AES for each combination of the following input parameter lengths:

• 
  256 bit (for AES­128) and 512 bit (for AES­256) keys
  
• 
  Three data unit (i.e., plaintext) lengths. One of the data unit lengths shall be a nonzero integer multiple of 128 bits, if supported. One of the data unit lengths shall be an integer multiple of 128 bits, if supported. The third data unit length shall be either the longest supported data unit length or 216 bits, whichever is smaller.
  

using a set of 100 (key, plaintext and 128­bit random tweak value) 3­tuples and obtain the ciphertext that results from XTS­AES encrypt.

The evaluator may supply a data unit sequence number instead of the tweak value if the implementation supports it. The data unit sequence number is a base­10 number ranging between 0 and 255 that implementations convert to a tweak value internally.

The evaluator will test the decrypt functionality of XTS­AES using the same test as for encrypt, replacing plaintext values with ciphertext values and XTS­AES encrypt with XTSAES decrypt.

AES Key Wrap (AES­KW) and Key Wrap with Padding (AES­KWP) Test

The evaluator will test the authenticated encryption functionality of AES­KW for EACH combination of the following input parameter lengths:

• 
  128 and 256 bit key encryption keys (KEKs)
  
• 
  Three plaintext lengths. One of the plaintext lengths shall be two semi­blocks (128 bits). One of the plaintext lengths shall be three semi­blocks (192 bits). The third data unit length shall be the longest supported plaintext length less than or equal to 64 semi­blocks (4096 bits).
  

using a set of 100 key and plaintext pairs and obtain the ciphertext that results from AES­KW authenticated encryption. To determine correctness, the evaluator will use the AES­KW authenticated­encryption function of a known good implementation.

The evaluator will test the authenticated­decryption functionality of AES­KW using the same test as for authenticated­encryption, replacing plaintext values with ciphertext values and AES­KW authenticated­encryption with AES­KW authenticated­decryption.

The evaluator will test the authenticated­encryption functionality of AES­KWP using the same test as for AES­KW authenticated­encryption with the following change in the three plaintext lengths:

• 
  One plaintext length shall be one octet. One plaintext length shall be 20 octets (160 bits).
  
• 
  One plaintext length shall be the longest supported plaintext length less than or equal to 512 octets (4096 bits).
  

The evaluator will test the authenticated­decryption functionality of AES­KWP using the same test as for AESKWP authenticated­encryption, replacing plaintext values with ciphertext values and AES­KWP authenticatedencryption with AES­KWP authenticated­decryption.

7.1.1.1.5Cryptographic Operation for Hashing (FCS_COP.1(HASH))

The evaluator will check that the association of the hash function with other application cryptographic functions (for example, the digital signature verification function) is documented in the TSS.

The TSF hashing functions can be implemented in one of two modes. The first mode is the byte­oriented mode. In this mode the TSF only hashes messages that are an integral number of bytes in length; i.e., the length (in bits) of the message to be hashed is divisible by 8. The second mode is the bit­oriented mode. In this mode the TSF hashes messages of arbitrary length. As there are different tests for each mode, an indication is given in the following sections for the bit-oriented vs. the byte­oriented testmacs. The evaluator will perform all of the following tests for each hash algorithm implemented by the TSF and used to satisfy the requirements of this PP.

The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.

• 
  Test 1: Short Messages Test (Bit oriented Mode) ­ The evaluator will generate an input set consisting of m+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m bits. The message text shall be pseudorandomly generated. The evaluator will compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
  
• 
  Test 2: Short Messages Test (Byte oriented Mode) ­ The evaluator will generate an input set consisting of m/8+1 messages, where m is the block length of the hash algorithm. The length of the messages range sequentially from 0 to m/8 bytes, with each message being an integral number of bytes. The message text shall be pseudorandomly generated. The evaluator will compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
  
• 
  Test 3: Selected Long Messages Test (Bit oriented Mode) ­ The evaluator will generate an input set consisting of m messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 99 ⋅ i, where 1 ≤ i ≤ m. The message text shall be pseudorandomly generated. The evaluator will compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
  
• 
  Test 4: Selected Long Messages Test (Byte oriented Mode) ­ The evaluator will generate an input set consisting of m/8 messages, where m is the block length of the hash algorithm. The length of the ith message is 512 + 8 ⋅ 99 ⋅ i, where 1 ≤ i ≤ m/8. The message text shall be pseudorandomly generated. The evaluator will compute the message digest for each of the messages and ensure that the correct result is produced when the messages are provided to the TSF.
  
• 
  Test 5: Pseudorandomly Generated Messages Test This test is for byte­oriented implementations only. The evaluator will randomly generate a seed that is n bits long, where n is the length of the message digest produced by the hash function to be tested. The evaluator will then formulate a set of 100 messages and associated digests by following the algorithm provided in Figure 1 of [SHAVS]. The evaluator will then ensure that the correct result is produced when the messages are provided to the TSF.
  

7.1.1.1.6Cryptographic Operation for Signing (FCS_COP.1(SIGN))

The evaluator will perform the following activities based on the selections in the ST.

The following tests require the developer to provide access to a test application that provides the evaluator with tools that are typically not found in the production application.

ECDSA Algorithm Tests

• 
  Test 1: ECDSA FIPS 186­4 Signature Generation Test. For each supported NIST curve (i.e., P­256, P­384 and P­521) and SHA function pair, the evaluator will generate 10 1024­bit long messages and obtain for each message a public key and the resulting signature values R and S. To determine correctness, the evaluator will use the signature verification function of a known good implementation.
  
• 
  Test 2: ECDSA FIPS 186­4 Signature Verification Test. For each supported NIST curve (i.e., P­256, P­384 and P­521) and SHA function pair, the evaluator will generate a set of 10 1024­bit message, public key and signature tuples and modify one of the values (message, public key or signature) in five of the 10 tuples. The evaluator will verify that 5 responses indicate success and 5 responses indicate failure.
  

RSA Signature Algorithm Tests

• 
  Test 1: Signature Generation Test. The evaluator will verify the implementation of RSA Signature Generation by the OS using the Signature Generation Test. To conduct this test the evaluator must generate or obtain 10 messages from a trusted reference implementation for each modulus size/SHA combination supported by the TSF. The evaluator will have the OS use its private key and modulus value to sign these messages. The evaluator will verify the correctness of the TSF’s signature using a known good implementation and the associated public keys to verify the signatures.
  
• 
  Test 2: Signature Verification Test. The evaluator will perform the Signature Verification test to verify the ability of the OS to recognize another party’s valid and invalid signatures. The evaluator will inject errors into the test vectors produced during the Signature Verification Test by introducing errors in some of the public keys, e, messages, IR format, and/or signatures. The evaluator will verify that the OS returns failure when validating each signature.
  

7.1.1.1.7Cryptographic Operation for Keyed Hash Algorithms (FCS_COP.1(HMAC))

The evaluator will perform the following activities based on the selections in the ST.

For each of the supported parameter sets, the evaluator will compose 15 sets of test data. Each set shall consist of a key and message data. The evaluator will have the OS generate HMAC tags for these sets of test data. The resulting MAC tags shall be compared against the result of generating HMAC tags with the same key and IV using a known­good implementation.

7.1.1.1.8Random Bit Generation (FCS_RBG_EXT.1)