The evaluator shall examine the TSS to verify that it describes any mechanisms the TSF uses to generate audit data for security-relevant audit events. If multiple separate mechanisms are used, the evaluator shall verify that the TSS identifies the events that are logged via each mechanism.

The evaluator shall examine the operational guidance to verify that it includes information on how security-relevant audit events are logged and what the format for the audit records are. The evaluator shall also verify that the operational guidance includes sample audit records for each security-relevant event so that it is clear to the reader how the TSF identifies those events in the audit data.

The evaluator shall check the administrative guide and ensure that it provides a format for audit data. Each audit data 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 data by having the TOE generate audit data 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 data generated during testing match the format specified in the administrative guide, and that the audit data provides the required information.

The evaluator shall examine the TSS to verify that it describes how the TOE generates a key based on output from a random bit generator as specified in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked. If support for P-256 is claimed, the evaluator shall examine the TSS to verify that it is only used for Bluetooth functions.

The evaluator shall examine the TSS to verify that it identifies the usage and key lifecycle for keys generated using each selected algorithm.

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed in accordance with the relevant standards.

If the TOE uses the generated key in a key chain or hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain or hierarchy.

The evaluator shall verify that the guidance instructs the administrator how to configure the TOE to generate keys for the selected key generation algorithms for all key types and uses identified in the TSS.

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
RSA	RSA	Modulus of size [selection: 3072, 4096, 6144, 8192] bits	NIST FIPS PUB 186-5 (Section A.1.1)

FIPS PUB 186-5 Key Pair generation specifies five methods for generating the primes p and q.

These are:

1. Random provable primes
2. Random probable primes
3. Provable primes with conditions based on auxiliary provable primes
4. Probable primes with conditions based on auxiliary provable primes
5. Probable primes with conditions based on auxiliary probable primes

In addition to the key generation method, the input parameters are:

• Modulus [3072, 4096, 6144, 8192]
• Hash algorithm [SHA-384, SHA-512] (methods 1, 3, 4 only)
• Rabin-Miller prime test [2¹⁰⁰, 2^{Security String}] (methods 2, 4, 5 only)
• p mod 8 value [0,1,3,5,7]
• q mod 8 value [0,1,3,5,7]
• Private key format [standard, Chinese Remainder Theorem]
• Public exponent [fixed value, random]

The evaluator shall verify the ability of the TSF to correctly produce values for the RSA 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.

Testing for Random Provable Primes and Conditional Methods

To test the key generation method for the random provable primes method and for all the primes with conditions methods (methods 1, 3-5), the evaluator must seed the TSF key generation routine with sufficient data to deterministically generate the RSA key pair.

For each supported combination of the above input parameters, the evaluator shall have the TSF generate 25 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Testing for Random Probable Primes Method

If the TOE generates random probable primes (method 2) then, if possible, the random probable primes method should also be verified against a known good implementation as described above. If verification against a known good implementation is not possible, the evaluator shall have the TSF generate 25 key pairs for each supported key length nlen and verify that all of the following are true.

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

Elliptic Curve Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ECC-ERB	ECC – Extra Random Bits	Elliptic Curve [selection: P-256, P-384, P-521]	NIST FIPS PUB 186-5 (Section A.2.1) NIST SP 800-186 (Section 3) [NIST Curves]
ECC-RS	ECC – Rejection Sampling	Elliptic Curve [selection: P-256, P-384, P-521]	NIST FIPS PUB 186-5 (Section A.2.2) NIST SP 800-186 (Section 3) [NIST Curves]

To test the TOE’s ability to generate asymmetric cryptographic keys using elliptic curves, the evaluator shall perform the ECC Key Generation Test and the ECC Key Validation Test using the following input parameters.

• Elliptic curve [P-256, P-384, P-521]
• Key pair generation method [extra random bits, rejection sampling]

ECC Key Generation Test
For each supported combination of the above input parameters the evaluator shall require the implementation under test to generate 10 private and public key pairs (d, Q). The private key, d, shall be generated using a random bit generator as specified in FCS_RBG.1. The private key, d, is used to compute the public key, Q'. The evaluator shall confirm that 0<d<n (where n is the order of the group), and the computed value Q' is then compared to the generated public and private key pairs’ public key, Q, to confirm that Q is equal to Q'.

ECC Key Validation Test
For each supported combination of the above parameters the evaluator shall generate 12 private and public key pairs using the key generation function of a known good implementation. For each set of 12 public keys, the evaluator shall modify four public key values by shifting x or y out of range by adding the order of the field and modify four other public key values by shifting x or y so that they are still in bounds, but not on the curve. The remaining public key values are left unchanged (i.e., correct). To determine correctness, the evaluator shall submit the public keys to the public key validation (PKV) function of the TOE and confirm that the results correspond as expected for the modified and unmodified values.

Finite Field Cryptography Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
FFC-ERB	FFC – Extra Random Bits	Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.3) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]
FFC-RS	FFC – Rejection Sampling	Static domain parameters approved for [selection: IKE groups [selection: MODP-3072, MODP-4096, MODP-6144, MODP-8192], TLS groups [selection: ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]]]	NIST SP 800-56A Revision 3 (Section 5.6.1.1.4) [key pair generation] [selection: RFC 3526 [IKE groups], RFC 7919 [TLS groups]]

To test the TOE’s ability to generate asymmetric cryptographic keys using finite fields, the evaluator shall perform the Safe Primes Generation Test and the Safe Primes Validation Test using the following input parameter:

• Fields/Groups [MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192]

Safe Primes Generation Test
For each supported safe primes group, generate 10 key pairs. The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Safe Primes Verification Test
For each supported safe primes group, use a known good implementation to generate 10 key pairs. For each set of 10, the evaluator shall modify three so they are incorrect. The remaining values are left unmodified (i.e. correct). To determine correctness, the evaluator shall submit the key pairs to the public key validation (PKV) function of the TOE and shall confirm that the results correspond as expected for the modified and unmodified values.

ML-KEM Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ML-KEM	ML-KEM Key Generation	Parameter set = [ML-KEM-1024]	NIST FIPS PUB 203 (Section 7.1)

To test the TOE’s ability to generate asymmetric cryptographic keys using ML-KEM, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Parameter set [ML-KEM-1024]
• Random seed d [32 bytes]
• Random seed z [32 bytes]

Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated pairs of 32-byte seed values (d, z). To determine correctness, the evaluator shall compare the resulting key pairs (ek, dk) with those generated using a known good implementation using the same inputs.

ML-DSA Key Generation

Identifier	Cryptographic Key Generation Algorithm	Cryptographic Algorithm Parameters	List of Standards
ML-DSA	ML-DSA Key Generation	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.1)

To test the TOE’s ability to generate asymmetric cryptographic keys using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Parameter set [ML-DSA-87]
• Random seed [32 bytes]

Algorithm Functional Test
For each supported parameter set the evaluator shall require the implementation under test to generate 25 key pairs using 25 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs.

The evaluator shall examine the TSS to verify that it describes how the TOE obtains a symmetric cryptographic key through direct generation from a random bit generator as specified in FCS_RBG.1. The evaluator shall review the TSS to verify that it describes how the functionality described by FCS_RBG.1 is invoked.

The evaluator shall examine the TSS to verify that it identifies the usage, and key lifecycle for keys generated using each selected algorithm.

If the TOE uses the generated key in a key chain/hierarchy then the evaluator shall verify that the TSS describes how the key is used as part of the key chain/hierarchy.

The evaluator shall verify that the AGD instructs the administrator how to configure the TOE to use the RBG to generate symmetric keys for all uses identified in the ST.

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

To test the TOE’s ability to generate symmetric cryptographic keys using a random bit generator, the evaluator shall configure the symmetric cryptographic key generation capability for each claimed key size. The evaluator shall use the description of the RBG interface to verify that the TOE requests and receives an amount of RBG output greater than or equal to the requested key size.

The evaluator shall verify that the TSS identifies all plaintext keying material and CSPs stored by the TOE, the type of memory in which it is stored, and when and how the keying material is erased. If the TOE uses one or more KEKs to protect stored keying material, the evaluator shall verify that the TSS describes the destruction of that keying material, either directly or by destruction of the KEK used to encrypt it.

If different types of memory are used to store the materials to be protected, the evaluator shall check to ensure that the TSS describes the clearing procedure in terms of the memory in which the data are stored (for example, "secret keys stored on flash are cleared by overwriting once with zeros, while secret keys stored on the internal persistent storage device are cleared by overwriting one time with a random pattern that is changed before each write"). For block erases, the evaluator shall also ensure that the TSS identifies the block erase command that is used and shall verify that the command used also addresses any copies of the plaintext key material that may be created, e.g. in order to optimize the use of Flash memory.

There are a variety of concerns that may prevent or delay key destruction in some cases. The evaluator shall check that the guidance documentation identifies configurations or circumstances that may not strictly conform to the key destruction requirement, and that this description is consistent with the relevant parts of the TSS and any other relevant Required Supplementary Information. The evaluator shall check that the guidance documentation provides guidance on situations where key destruction may be delayed at the physical layer and how such situations can be avoided or mitigated if possible.

Some examples of what is expected to be in the documentation are provided here.

When the TOE does not have full access to the physical memory, it is possible that the storage may be implementing wear-leveling and garbage collection. This may create additional copies of the key that are logically inaccessible but persist physically. In this case, to mitigate this the drive should support the TRIM command and implements garbage collection to destroy these persistent copies when not actively engaged in other tasks.

Drive vendors implement garbage collection in a variety of different ways, as such there is a variable amount of time until data is truly removed from these solutions. There is a risk that data may persist for a longer amount of time if it is contained in a block with other data not ready for erasure. To reduce this risk, the operating system and file system of the OE should support TRIM, instructing the non-volatile memory to erase copies via garbage collection upon their deletion. If a RAID array is being used, only set-ups that support TRIM are utilized. If the drive is connected via PCI-Express, the operating system supports TRIM over that channel.

The drive should be healthy and contains minimal corrupted data and should be end-of-lifed before a significant amount of damage to drive health occurs, this minimizes the risk that small amounts of potentially recoverable data may remain in damaged areas of the drive.

Evaluation Activity Note: The following tests likely require the TOE developer to provide access to a test platform that provides the evaluator with tools that are typically not found on the end consumer version of the TOE.

The evaluator shall perform the following tests for all keys and key material subject to destruction by the TOE. For these tests, the evaluator shall utilize an appropriate development environment (e.g., a virtual machine) and development tools (debuggers, simulators, etc.) to test that keys are cleared, including all copies of the key that may have been created internally by the TOE during normal cryptographic processing with that key.

• Test FCS_CKM.6:1: Applied to each key held as plaintext in volatile memory and subject to destruction by overwrite by the TOE (whether or not the plaintext value is subsequently encrypted for storage in volatile or non-volatile memory). In the case where the only selection made for the destruction method key was removal of power, then this test is unnecessary. The evaluator shall:
  
  1. Record the value of the key in the TOE subject to clearing.
  2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
  3. Cause the TOE to clear the key.
  4. Cause the TOE to stop the execution but not exit.
  5. Cause the TOE to dump the entire memory of the TOE into a binary file.
  6. Search the content of the binary file created in Step #5 for instances of the known key value from Step #1.
  7. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece.
  
  Steps 1-6 ensure that the complete key does not exist anywhere in volatile memory. If a copy is found, then the test fails.
  
  Step 7 ensures that partial key fragments do not remain in memory. If a fragment is found, there is a minuscule chance that it is not within the context of a key (e.g., some random bits that happen to match). If this is the case the test should be repeated with a different key in Step #1. If a fragment is found the test fails.
  
  
• Test FCS_CKM.6:2: Applied to each key held in non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:
  
  1. Record the value of the key in the TOE subject to clearing.
  2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
  3. Cause the TOE to clear the key.
  4. Search the non-volatile memory the key was stored in for instances of the known key value from Step #1. If a copy is found, then the test fails.
  5. Break the key value from Step #1 into 3 similar sized pieces and perform a search using each piece. If a fragment is found then the test is repeated (as described for test 1 above), and if a fragment is found in the repeated test then the test fails.
  
  
  
• Test FCS_CKM.6:3: Applied to each key held as non-volatile memory and subject to destruction by overwrite by the TOE. The evaluator shall use special tools (as needed), provided by the TOE developer if necessary, to view the key storage location:
  
  1. Record the storage location of the key in the TOE subject to clearing.
  2. Cause the TOE to perform a normal cryptographic processing with the key from Step #1.
  3. Cause the TOE to clear the key.
  4. Read the storage location in Step #1 of non-volatile memory to ensure the appropriate pattern is utilized.
  
  The test succeeds if correct pattern is used to overwrite the key in the memory location. If the pattern is not found the test fails.

The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, nonces, and tags in conformance with the relevant specifications.

If a CCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the nonce is generated and that the same nonce is never reused to encrypt different plaintext pairs under the same key. If the use of 128-bit keys is selected in conjunction with AES-CCM, the evaluator shall verify that the TSS describes the use of 128-bit AES-CCM as being solely for Bluetooth.

If a GCM mode algorithm is selected, then the evaluator shall examine the TOE summary specification to confirm that it describes how the IV is generated and that the same IV is never reused to encrypt different plaintext pairs under the same key. The evaluator shall also confirm that for each invocation of GCM, the length of the plaintext is at most (2³²)-2 blocks.

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

The following tests are conditional based upon the selections made in the SFR. The evaluator shall perform the following test or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

AES-CCM

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CCM	AES in CCM mode with non-repeating nonce, minimum size of 64 bits	[selection:128 bits, 256 bits]	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 7), NIST SP 800-38C] [CCM]

To test the TOE’s implementation of AES-CCM authenticated encryption functionality the evaluator shall perform the Algorithm Functional Tests described below using the following input parameters:

• Key Size [128,256] bits
• Associated data size [0-65536] bits in increments of 8
• Payload size [0-256] bits in increments of 8
• IV/Nonce size [64-104] bits in increments of 8
• Tag size [32-128] bits in increments of 16

Algorithm Functional Tests

Unless otherwise specified, the following tests should use random data, a tag size of 128 bits, IV/Nonce size of 104 bits, payload size of 256 bits, and associated data size of 256 bits. If any of these values are not supported, any supported value may be used. The evaluator shall compare the output from each test case against results generated by a known-good implementation with the same input parameters.

Variable Associated Data Test

For each claimed key size, and for each supported associated data size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data. In addition, for each key size, the TOE must be tested by encrypting 10 cases with associated data lengths of 65536 bits, if supported.

Variable Payload Test

For each claimed key size, and for each supported payload size from 0 through 256 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Variable Nonce Test

For each claimed key size, and for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Variable Tag Test

For each claimed key size, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by encrypting 10 test cases using all random data.

Decryption Verification Test

For each claimed key size, for each supported associated data size from 0 through 256 bits in increments of 8 bits, for each supported payload size from 0 through 256 bits in increments of 8 bits, for each supported IV/Nonce size from 64 through 104 bits in increments of 8 bits, and for each supported tag size from 32 through 128 bits in increments of 16 bits, the TOE must be tested by decrypting 10 test cases using all random data.

AES-GCM

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-GCM	AES in GCM mode with non-repeating IVs using [selection: deterministic, RBG-based] IV construction; the tag must be of length [selection: 96, 104, 112, 120, or 128] bits.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 19772:2020 (Clause 10), NIST SP 800-38D] [GCM]

To test the TOE’s implementation of AES-GCM authenticated encryption functionality the evaluator shall perform the Encryption Algorithm Functional Tests and Decryption Algorithm Functional Tests as described below using the following input parameters:

• Key Size [256] bits
• Associated data size [0-65536] bits
• Payload size [0-65536] bits
• IV size [96] bits
• Tag size [96, 104, 112, 120, 128] bits

Encryption Algorithm Functional Tests

The evaluator shall generate 15 test cases using random data for each combination of the above parameters as follows:

• Each claimed key size,
• Each supported tag size,
• Four supported non-zero payload sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits,
• Four supported non-zero associated data sizes, such that two are multiples of 128 bits and two are not multiples of 128 bits, and
• An associated data size of zero, if supported.

Note that the IV size is always 96 bits.

The evaluator shall compare the output from each test case against results generated by a known- good implementation with the same input parameters.

Decryption Algorithm Functional Tests

The evaluator shall test the authenticated decrypt functionality of AES-GCM by supplying 15 test cases for the supported combinations of the parameters as described above. For each parameter combination the evaluator shall introduce an error into either the Ciphertext or the Tag such that approximately half of the cases are correct and half the cases contain errors.

The evaluator shall examine the TSS to verify that if SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function or as part of LMS, and not as a hash algorithm.

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

The following tests are conditional, based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

SHA-256, SHA-384, SHA-512

To test the TOE’s ability to generate hash digests using SHA2, the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Test for each claimed SHA2 algorithm.

Algorithm Functional Test

The evaluator shall generate a number of test cases equal to the block size of the hash (512 for SHA2-256; 1024 for the other SHA2 algorithms).

Each test case is to consist of random data of a random length between 0 and 65536 bits, or the largest size supported.

Monte Carlo Test

Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.

There are two versions of the Monte Carlo Test for SHA-1 and SHA-2. Either one is acceptable. For the standard Monte Carlo test the message hashed is always three times the length of the initial seed.

                  For j = 0 to 99
                  A = B = C = SEED
                  For i = 0 to 999
                  MSG = A || B || C
                  MD = SHA(MSG)
                  A = B
                  B = C
                  C = MD
                  Output MD
                  SEED = MD
                

For the alternate version of the Monte Carlo Test, the hashed message is always the same length as the seed.

                  INITIAL_SEED_LENGTH = LEN(SEED)
                  For j = 0 to 99
                  A = B = C = SEED
                  For i = 0 to 999
                  MSG = A || B || C
                  if LEN(MSG) >= INITIAL_SEED_LENGTH:
                  MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
                  else:
                  MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
                  MD = SHA(MSG)
                  A = B
                  B = C
                  C = MD
                  Output MD
                  SEED = MD	
                

The evaluator shall compare the output against results generated by a known good implementation with the same input.

Large Data Test

The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits.

The evaluator shall compare the output against results generated by a known good implementation with the same input.

SHA3-384, SHA3-512

To test the TOE’s ability to generate hash digests using SHA3 the evaluator shall perform the Algorithm Functional Test, Monte Carlo Test, and Large Data Tests for each claimed SHA3 algorithm.

Algorithm Functional Test

Generate a test case consisting of random data for every message length from 0 bits (or the smallest supported message size) to rate bits, where rate equals

• 832 for SHA3-384 and
• 576 for SHA3-512.

Additionally, generate tests cases of random data for messages of every multiple of (rate+1) bits starting at length rate, and continuing until 65535 is exceeded.

The evaluator shall compare the output against results generated by a known good implementation with the same input.

Monte Carlo Test

Monte Carlo tests begin with a single seed and run 100 iterations of the chained computation.

For this Monte Carlo Test, the hashed message is always the same length as the seed.

                  MD[0] = SEED
                  INITIAL_SEED_LENGTH = LEN(SEED)
                  For 100 iterations
                  For i = 1 to 1000
                  MSG = MD[i-1];
                  if LEN(MSG) >= INITIAL_SEED_LENGTH:
                  MSG = leftmost INITIAL_SEED_LENGTH bits of MSG
                  else:
                  MSG = MSG || INITIAL_SEED_LENGTH - LEN(MSG) 0 bits
                  MD[i] = SHA3(MSG)
                  MD[0] = MD[1000]
                  Output MD[0]
                

The evaluator shall compare the output against results generated by a known good implementation with the same input.

Large Data Test

The implementation must be tested against one test case each on large data messages of 1GB, 2GB, 4GB, and 8GB of data as supported. The data need not be random. It may, for example, consist of a repeated pattern of 64 bits.

The evaluator shall compare the output against results generated by a known good implementation with the same input.

The evaluator shall examine the TSS to ensure that the size of the key is sufficient for the desired security strength of the output.

The evaluator shall examine the TSS to verify that if HMAC-SHA-256 is selected, that it is being used only as a PRF or MAC step in a key derivation function.

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

HMAC

Keyed Hash Algorithm	Cryptographic Key Sizes	List of Standards
HMAC-SHA-256	256 bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
HMAC-SHA-384	[selection: (ISO, FIPS) 384, (FIPS) 256] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]
HMAC-SHA-512	[selection: (ISO, FIPS) 512, (FIPS) 384, 256] bits	[selection: ISO/IEC 9797-2:2021 (Section 7 “MAC Algorithm 2”), FIPS PUB 198-1]

To test the TOE’s ability to generate keyed hashes using HMAC the evaluator shall perform the Algorithm Functional Test for each combination of claimed HMAC algorithm the following parameters:

• Hash function [SHA-256, SHA-384, SHA-512]
• Key length [8-65536] bits by 8s
• MAC length [32-[digest size of hash function (256, 384, 512)]] bits

Algorithm Functional Test

For each supported Hash function the evaluator shall generate 150 test cases using random input messages of 128 bits, random supported key lengths, random keys, and random supported MAC lengths such that across the 150 test cases:

• The key length includes the minimum, the maximum, a key length equal to the block size, and key lengths that are both larger and smaller than the block size.
• The MAC size includes the minimum, the maximum, and two other random values.

The evaluator shall compare the output against results generated by a known good implementation with the same input.

The evaluator shall examine the TSS and verify that any hash function is the appropriate security strength for the signing algorithm.

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards.

The evaluator shall examine the TSS to verify that the TOE has appropriate measures in place to ensure that hash-based signature algorithms do not reuse private keys.

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA-PKCS Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]

To test the TOE’s ability to perform RSA Digital Signature Generation using PKCS1-v1,5 signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

• Modulus size [3072, 4096, 6144, 8192] bits
• Hash algorithm [SHA-384, SHA-512]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation.

RSA-PSS Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512], Salt Length (sLen) such that [assignment: 0 ≤ sLen ≤ hLen (Hash Output Length)] and Mask Generation Function = MGF1	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]

To test the TOE’s ability to perform RSA Digital Signature Generation using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

• Modulus size [3072, 4096, 6144, 8192] bits
• Hash algorithm [SHA-384, SHA-512]
• Salt length [Fixed based on implementation]
• Mask function [MGF1]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate three test cases using random data. The evaluator shall compare the results against those from a known good implementation.

ECDSA Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521], per-message secret number generation [selection: extra random bits, rejection sampling, deterministic] and hash function using [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]

To test the TOE’s ability to perform ECDSA Digital Signature Generation using extra random bits or rejection sampling for secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Elliptic Curve [P-384, P-521]
• Hash algorithm [SHA-384, SHA-512]

To test the TOE’s ability to perform ECDSA Digital Signature Generation using deterministic secret number generation, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Elliptic Curve [P-384, P-521]
• Hash algorithm [SHA-384, SHA-512]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate 10 test cases using random data. The evaluator shall compare the results against those from a known good implementation.

ML-DSA Signature Generation

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ML-DSA	ML-DSA SigGen	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.2)

To test the TOE’s ability to generate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Parameter set [ML-DSA-87]
• Seed [32 random bytes] (for non-deterministic signature testing), or
• Seed [32 zero bytes] (for deterministic signature testing)
• Message to sign [8-65535] bytes
• Mu value (if generated externally)
• Previously generated private key (sk)
• Context (for external interface testing)

Algorithm Functional Test

For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to generate 15 signatures pairs using 15 different randomly generated 32-byte seed values. To determine correctness, the evaluator shall compare the resulting key pairs with those generated using a known good implementation using the same inputs.

Known Answer Test for Rejection Cases

For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row for each corresponding test case below.

The test values are defined as follows:

• Seed is the seed to generate the key pair (pk, sk)
• Hash of keys is computed by SHA-256(pk||sk)
• Message is the message to be signed
• Hash of sig is computed by SHA-256(sig)

ML-DSA-87 Test Cases for Rejection Cases

		Test case 87-RC-01
		Seed: 			E4F5AFCF697E0EC3C1BDEB66FAA903221E803902F9C3F716E1056A63D77DC250
		Hash of Keys: 	61618E8DDA6998072C8EB36974E03880D741CAF0BD523356DFC161E7C9E63934
		Message: 		F4F1C05004D5B946F69EAFE104C4020519086ADDB9582A20FDE887D13DFC36B1
		Hash of sig: 	B584E38FA442FC3C81A147D4BDBF058D73C822CAF5CA4C06B0110867F60A8001
						
		Test case 87-RC-02
		Seed: 			8B828D871254D6C57384A8E7025AA3F7160CAD1D2C754499DF3844426062C3DD
		Hash of Keys: 	BB64481317D6C0DBAD20C0C7EF11078AD54E5D574F4A07652115A95F77C655FA
		Message: 		0F9409C5A4930C25B83FC5B77FDB5BB49C75372DE724D9C1A77DB700CF0CF154
		Hash of sig: 	F86B49BE9DEB2B209BDEB4E922E5939E92D38E562C44BB09AFBD67323C345192
						
		Test case 87-RC-03
		Seed: 			E693D282CACB8CE65FD4D108DA7A373F097F0AA9713550BE242AAD5BD3E2E452
		Hash of Keys: 	B0BEAF56713A69BD4AB2CBEE006FA5001E7B41F3AE541E05F088933AA0CC78DF
		Message: 		24DABB9D57ADEBD560ED65D9451C5106D437061708F849BA53F3543CDF9AAAE0
		Hash of sig: 	DBF65CEFF9F96A74AAF6F3AB27B043231BE6AA04FBA2EEC987A24A00BDD6A08E
						
		Test case 87-RC-04
		Seed: 			4002163EB8EED01A8E0919BA8C07D291341EDCAE25B02B9779A2CFFE50561AF0
		Hash of Keys: 	FED1BE685C20ECB322FC40D41DEE7E0E98D0409FBF989CAE71B8AD2D58AD645E
		Message: 		EE316BB5EBED53325B4A55571C60657B53E353B51B831F4A0BBB28107EBA4BA8
		Hash of sig: 	3BE9B5545FDCED92547B3409C83B3312CCB5792A8EC3A4DA63BA692C79BEF17C
						
		Test case 87-RC-05
		Seed: 			9C7AD524F65854C27E565BCEDF8E86D650F13A40D0448F9AE10C05F10F777120
		Hash of Keys: 	0EA872CA5A4BEA94F4E8EF7ED31800727899A51059FDEE111E5CB15F0233B534
		Message: 		CE09831294AA96CAF684B9E667947B021C57B24C138EC7D4DA270694C82F2E08
		Hash of sig: 	3B9526CEE6587F2418BFE603ADB0F7DF0D69EBA31C9F9F005C60C993945EBD33
						
		Test case 87-RC-06
		Seed: 			2EB7676D4A28700DA7772A7A035EB495CAA6F842352A74824EF5FD891BC38B2A
		Hash of Keys: 	D5B73703A1DDC5BCB0D14AE39B193A25D6ADA6535827973181ADB0BE70435A5B
		Message: 		C2B3A0AC483A5517682285C205974B2A506946448A8F7D3E1934C155EFDFE922
		Hash of sig: 	375D598704B722C8A1FEF1626FD7738A532C06329AA4217357460E3B729660F8
						
		Test case 87-RC-07
		Seed: 			E4E80CCE8B26DF1B02B99949851EE2F907FE4F0CC34790352C76D5D91634D073
		Hash of Keys: 	84B7E61684A12698400B09EA332EA3C4FBCFA47FE37FD6AE725CBC5FA8A99D3F
		Message: 		89E6AB43C9CB1CC59C3986D53217A558357E62102A26F666F2B64CD1DBB7A536
		Hash of sig: 	7C4AABD163CAEF8F6EBFDA3E3EEBC0A9604675B0E991ABAFD284F1AE8BA07B2A
						
		Test case 87-RC-08
		Seed: 			5787262B803499223D4E5A8C1EE572E89F7A69B359B3F8505355B0BDEAB95E5C
		Hash of Keys: 	85AE1DE605A7B479C02730BF4B7DD6D0FD8FFE5C980893CA6DAD00BD8BD1CE68
		Message: 		D3230C4E061964BBFB17702432D5D36FC1EB3D1068F8CCAA84044776E3B5CC55
		Hash of sig: 	D3ABE460EE2DD9595F413CFE2780A319E4E4DFD6592995298A7AB0B82A5E2815
						
		Test case 87-RC-09
		Seed: 			CE099B99330537DD153052243FC32ACAD509A126AB982410258858567D410D79
		Hash of Keys: 	E04A9F15EDF8F078EB336CE624249EF2A8EDF2CDBF6A8276E9F5E92ED9B0BAE8
		Message: 		0035931762665F561A1B22176567E3B10FDE2441521F77030733A8E39312EEEE
		Hash of sig: 	3EEF413CB5EB179896ECA172D0DBFB9B251545DC561D61580BD5BBC8B6D734E1

		Test case 87-RC-10
		Seed: 			FC8F2929878CBD81E1CCC23913F290380120C043A4A8A251AEEBF09705B8E590
		Hash of Keys: 	7E2ECCA86F532E8E8092FEBB6E0007F92E7909AD2BCBE2E02AB375DAC9969E5E
		Message: 		D3C28875D2671C0EF23BFDC8869E8ECF8868D3F0561C3134D254F7479D0CE0E5
		Hash of sig: 	EB69A908EDCC04320A0B61AD57E21B044465F2037698636B64229CF2DB259789
						

Known Answer Test for Large Number of Rejection Cases (Total Rejection Count)

For each supported parameter set, the evaluator shall cause the TOE to generate signatures using the data below and a deterministic seed of all 0’s. Correctness is determined by comparing the hash of the resulting signature with the hash in the fourth row of the corresponding test case below.

ML-DSA-87 Test Cases for Total Rejection Count

		Test case 87-LN-01
		Seed: 			98B6298051D92BF37293C93C97370747BF527B87B71F6C4264182F45155ADE4C
		Hash of Keys: 	04A135B5C9B7020332C7B16E7108E8FF7FC1EAE1C23C5FA0B5D5CED0FEEE7424
		Message: 		D7B0341269259083ABF3C8DC47559A19D57669B4486E0224F376DC43E577A3D8
		Hash of sig: 	58D72D76EC0FB65BFB9893C4479366B79DD7B8B7577E4291D13514FCC76C26DD

		Test case 87-LN-02
		Seed: 			DFB5BDD90F58571DCA962426C623F13D046BBE814D183886AC90D143EAD725A7
		Hash of Keys: 	2B6AB8CFCCCC41F759CAF01932E9413F5DC6D949BC827F739866929683FB155E
		Message: 		21005DB2B583CC826A9684BFFD0EE00AB97E0479FE4A1D266699337540145778
		Hash of sig: 	C93EA34E00FFFFC3ECEA072D5FB038A83B5539CAF7B831AEDCFA785E50B3CA5E

		Test case 87-LN-03
		Seed: 			5AD414E0DD0EF2FE685F342871875FDF06F503717A86C3B3466565ADD2096417
		Hash of Keys: 	BD9C2D52F3FC78DB17E682DA2E78947ECFC0898333838D60C892700B2B0DDA9F
		Message: 		29139C279816B25F2D6BB52C8247D163544F7BA332C3CF63359B9E23FBC56515
		Hash of sig:	DB4BE2DE19FB40437BDB7E9B6578D665DB05B4E88C16907DF4546EBA9BE03AEA

		Test case 87-LN-04
		Seed: 			484DD2F406A4D15F49A91AD5FC3BDC1D0FF253622EB68F83D6E1C870D0E89E29
		Hash of Keys: 	A719DC9A77C91C46295555C2353BA0CBEA513DA9A92A5C34D2E949EFF46A12D8
		Message: 		6AD6E959F0EA60126364FB7C95FA71133F246A9265A11B4965EE78AB0CB5AF0E
		Hash of sig: 	5050D7A665074EC63D9F3966C1F01A1BFB18F9E83AE0B09F838BC1E2342ED6F4

		Test case 87-LN-05
		Seed: 			B25C1816F82D59940D5CB829BAC364AAD013C4C16415CE1CF6DCC2F15199B391
		Hash of Keys: 	ADBB2CD43F222640BD9FF4E61C80E63853E8DC1F759C581B7447C9C166EAA38E
		Message: 		824E47322895BFFE37B6B4AFC41CF6115C07EEC0C24EB81076C87A1B01AE8617
		Hash of sig: 	667ADA46073BC69D64DC47BB9A76DD0D78302E7415D87D5E816B05FB95F9E84D

		Test case 87-LN-06
		Seed: 			B2CE72B3560AF07E06465881F56ADA00262BA708D87B73F39E04E310F3B8A3E9
		Hash of Keys: 	FD9C4AC53AE803242A62DF933B8E8BAD6CE5207AC4A73683B6D9383B5E70B17A
		Message: 		A1501CC84C917E0D2D7C27C2AC382220BD8FFFE807DB38E37A9E429EC2781911
		Hash of sig: 	779553B195E11558EE59EF3942F5F6B446A2144600D1F4F50B300C6C56504760

		Test case 87-LN-07
		Seed: 			AB01D0E591B7DDCD3C03395AED808FA2763C0A486D44119D621BE0FD0B022B25
		Hash of Keys: 	93B6ADE34F78A4ADB36B2F6D2C51DB793E659E1243E80488AE1C03B65125D6D7
		Message: 		8DE8122D89D15FE84A4C34F6B59B2C4B11F33B6A053154D199B634F557FDF5F6
		Hash of sig: 	0483045999A79B583F403DB96A736F0F0B24E2DFBC4E5CFA9B50E3D910786F07

		Test case 87-LN-08
		Seed: 			15D60D3693762F82C9AC1DCB0576936651AC81D863842EDB91109C8EE83AE705
		Hash of Keys: 	2DF544E2E939AA717741C2437288FAEB308DEB8FF37A2652FAE34BAE8B84D779
		Message: 		F05946A6113905C34163AEF2246FD69016CE24A7BA40F8E7E42EDAC2D0A44605
		Hash of sig: 	F8383917AF79C8E540D2356AB05F08B465BF32DFEC444B787CE31BF48CC6C3DD

		Test case 87-LN-09
		Seed: 			21212285BED53B3411705DAF5F3BDDB6F0618EB571B36EE11A74053407A269F5
		Hash of Keys: 	737061155A9A03F11F9FEBBB940BED4DD54542C4A6212F89A5EB4EC2BE542782
		Message: 		FFE38246BF3DEFD9CAD15CC17CEA511C067D582E04227B479E32F9197CF91482
		Hash of sig: 	C4C12C58032052FB2D21F0C6A7388A63154FB85B74287D2859DE6C1C6F7F277B

		Test case 87-LN-10
		Seed: 			A2744470587C71BA43EC26DC390CE3531978F315993C653E5D3EFD2849D5D9F1
		Hash of Keys: 	B1BF37BFFB11531B6ADD697870D7DB2E2462D0A97A63F09C1D0038457C6D795A
		Message: 		9831A830231A160B9847203341A5F30BF3E87A2A482AEEA6886315C92B5C4E4C
		Hash of sig: 	46C669D2FEB643A38E54FF87B790CC33F44043A1B6B31DB9474D301328CA2A7F
						

The evaluator shall examine the TSS to verify that any one-time values such as nonces or masks are constructed and used in accordance with the relevant standards.

If "2048 (for secure boot only)" is selected for RSA, the evaluator shall check that the TSS documents that 2048-bit RSA is used only for secure boot and that a larger key size is used for any other function.

If "2048 (for secure boot only)" is selected for RSA, the evaluator shall check that the guidance includes an configuration needed to ensure that 2048-bit RSA is used only for secure boot and that a larger key size is used for any other function.

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.

RSA-PKCS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PKCS	RSASSA-PKCS1-v1_5	Modulus of size [selection: 2048 (for secure boot only), 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PKCS1-v1_5]

To test the TOE’s ability to perform RSA Digital Signature Verification using PKCS1-v1,5 signature type, the evaluator shall perform Generated Data Test using the following input parameters:

• Modulus size [2048, 3072, 4096, 6144, 8192] bits
• Hash algorithm [SHA-384, SHA-512]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using a random message and its signature such that the test cases are modified as follows:

• One test case is left unmodified
• For one test case the Message is modified
• For one test case the Signature is modified
• For one test case the exponent (e) is modified
• For one test case the IR is moved
• For one test case the Trailer is moved

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

RSA-PSS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
RSA-PSS	RSASSA-PSS	Modulus of size [selection: 2048 (for secure boot only), 3072, 4096, 6144, 8192] bits, hash [selection: SHA-384, SHA-512]	RFC 8017 (Section 8.2) [PKCS #1 v2.2] NIST FIPS PUB 186-5 (Section 5.4) [RSASSA-PSS]

To test the TOE’s ability to perform RSA Digital Signature Verification using PSS signature type, the evaluator shall perform the Generated Data Test using the following input parameters:

• Modulus size [2048, 3072, 4096, 6144, 8192] bits
• Hash algorithm [SHA-384, SHA-512]
• Salt length [0-hash length]
• Mask function [MGF1]

Generated Data Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate six test cases using random data such that the test cases are modified as follows:

• One test case is left unmodified
• For one test case the Message is modified
• For one test case the Signature is modified
• For one test case the exponent (e) is modified
• For one test case the IR is moved
• For one test case the Trailer is moved

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

ECDSA Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ECDSA	ECDSA	Elliptic Curve [selection: P-384, P-521] and hash function using [selection: SHA-384, SHA-512]	[selection: ISO/IEC 14888-3:2018 (Subclause 6.6), NIST FIPS PUB 186-5 (Sections 6.3.1, 6.4.1] [ECDSA] NIST SP-800 186 (Section 4) [NIST Curves]

To test the TOE’s ability to perform ECDSA Digital Signature Verification, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Elliptic Curve [P-384, P-521]
• Hash algorithm [SHA-384, SHA-512]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall cause the TOE to generate test cases consisting of messages and signatures such that the 21 test cases are modified as follows:

• Three test cases are left unmodified
• For three test cases the Message is modified
• For three test cases the key is modified
• For three test cases the r value is modified
• For three test cases the s value is modified
• For three test cases the value r is zeroed
• For three test cases the value s is zeroed

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

LMS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
LMS	LMS	Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], Winternitz parameter = [selection: 1, 2, 4, 8], and tree height = [selection: 5, 10, 15, 20, 25]	RFC 8554 [LMS] NIST SP 800-208 [parameters]

To test the TOE’s ability to verify cryptographic digital signature using LMS, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
• Winternitz [1, 2, 4, 8]
• Tree height [5, 10, 15, 20, 25]

Algorithm Functional Test

For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that

• One test case is unmodified (i.e. correct)
• For one test case modify the message, i.e. the message is different
• For one test case modify the signature, i.e. signature is different
• For one test case modify the signature header so that it is a valid header for a different LMS parameter set.

The TOE must correctly verify the unmodified test case and fail to verify the modified test cases.

XMSS Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
XMSS	XMSS	Private key size = [selection: 192 bits with [selection: SHA256/192, SHAKE256/192], 256 bits with [selection: SHA-256, SHAKE256]], and tree height = [selection: 10, 16, 20]	RFC 8391 [XMSS] NIST SP 800-208 [parameters]

To test the TOE’s ability to verify digital signatures using XMSS or XMSS MT, the evaluator shall perform the XMSS digital signature verification test using the following input parameters:

• Hash algorithm [SHA-256/192, SHAKE256/192, SHA-256, SHAKE256]
• Tree height [10, 16, 20]

XMSS Digital Signature Verification Test

For each supported combination of the above parameters, the evaluator shall generate four test cases consisting of signed messages and keys, such that

• One test case is unmodified (i.e. correct)
• For one test case modify the message, i.e. the message is different
• For one test case modify the signature, i.e. signature is different
• For one test case modify the signature header so that it is a valid header for a different XMSS parameter set

The evaluator shall verify the correctness of the implementation by verifying that the TOE correctly verifies the unmodified test case and fails to verify the modified test cases.

ML-DSA Signature Verification

Identifier	Cryptographic Algorithm Parameters	Cryptographic Key Sizes	List of Standards
ML-DSA	ML-DSA SigVer	Parameter set = ML-DSA-87	NIST FIPS PUB 204 (Section 5.2)

To test the TOE’s ability to validate digital signatures using ML-DSA, the evaluator shall perform the Algorithm Functional Test using the following input parameters:

• Parameter set [ML-DSA-87]
• Previously generated signed Message [8-65535] bytes
• Mu value (if generated externally)
• Context (for external interface testing)
• Previously generated public key (pk)
• Previously generated Signature

Algorithm Functional Test

For each combination of supported parameter set and capabilities, the evaluator shall require the implementation under test to validate 15 signatures. Each group of 15 test cases is modified as follows:

• Three test cases are left unmodified
• For three test cases the Signed message is modified
• For three test cases the component of the signature that commits the signer to the message is modified
• For three test cases the component of the signature that allows the verifier to construct the vector z is modified
• For three test cases the component of the signature that allows the verifier to construct the hint array is modified

The TOE must correctly verify the unmodified signatures and fail to verify the modified signatures.

The evaluator shall examine the TSS to ensure that it describes the construction of any IVs, tweak values, and counters in conformance with the relevant specifications.

If XTS-AES is claimed then the evaluator shall examine the TSS to verify that the TOE creates full-length keys by methods that ensure that the two key halves are different and independent.

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.

The following tests are conditional based on the selections made in the SFR. The evaluator shall perform the following tests or witness respective tests executed by the developer. The tests must be executed on a platform that is as close as practically possible to the operational platform (but which may be instrumented in terms of, for example, use of a debug mode). Where the test is not carried out on the TOE itself, the test platform shall be identified and the differences between test environment and TOE execution environment shall be described.
AES-CBC

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CBC	AES in CBC mode with non-repeating and unpredictable IVs	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 7), NIST SP 800-38A] [CBC]

To test the TOE’s ability to encrypt and decrypt data using AES in CBC mode, the evaluator shall perform Algorithm Functional Tests and Monte Carlo Tests using the following input parameters:

• Key size [256] bits
• Direction [encryption, decryption]

Algorithm Functional Tests

Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CBC, there are two types of AFTs:

Known-Answer Tests

For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.

Multi-Block Message Tests

For each combination of direction and claimed key size, the TOE must be tested against 10 test cases consisting of a random IV, random key, and random plaintext or ciphertext. The plaintext or ciphertext starts with a length of 16 bytes and increases by 16 bytes for each test case until reaching 160 bytes.

Monte Carlo Tests

Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size:

                  Key[0] = Key
                  IV[0] = IV
                  PT[0] = PT
                  for i = 0 to 99 {
                  Output Key[i], IV[i], PT[0]
                  for j = 0 to 999 {
                  if (j == 0) {
                  CT[j] = AES-CBC-Encrypt(Key[i], IV[i], PT[j])
                  PT[j+1] = IV[i]
                  } else {
                  CT[j] = AES-CBC-Encrypt(Key[i], PT[j])
                  PT[j+1] = CT[j-1]
                  }
                  }
                  Output CT[j]
                  AES_KEY_SHUFFLE(Key, CT)
                  IV[i+1] = CT[j]
                  PT[0] = CT[j-1]
                  }
                

where

AES_KEY_SHUFFLE

is defined as:

                  If ( keylen = 128 )
                  Key[i+1] = Key[i] xor MSB(CT[j], 128)
                  If ( keylen = 192 )
                  Key[i+1] = Key[i] xor (LSB(CT[j-1], 64) || MSB(CT[j], 128))
                  If ( keylen = 256 )
                  Key[i+1] = Key[i] xor (MSB(CT[j-1], 128) || MSB(CT[j], 128))
                

The above pseudocode is for encryption. For decryption, swap all instances of CT and PT.

The initial IV, key, and plaintext or ciphertext should be random.

The evaluator shall test the decrypt functionality using the same test as above, exchanging CT and PT, and replacing AES-CBC-Encrypt with AES-CBC-Decrypt.

XTS-AES

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
XTS-AES	AES in XTS mode with unique tweak values that are consecutive non-negative integers starting at an arbitrary non-negative integer	512 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: IEEE Std. 1619-2018, NIST SP 800-38E] [XTS]

To test the TOE’s ability to encrypt and decrypt data using AES in XTS mode, the evaluator shall perform the Single Data Unit Test and the Multiple Data Unit Test using the following input parameters:

• Direction [encryption, decryption]
• Key size [512] bits
• Tweak value format [128-bit hex string, data unit sequence number]

Single Data Unit Test

For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. The payload size and data unit size must be equal.

Multiple Data Unit Test

For each combination of claimed key size, direction, and supported tweak value format, the evaluator shall generate 50 test cases consisting of random payload data. The payload data size is determined randomly for each test case from supported values within the range [128-65536] bits. Likewise, the data unit size is determined randomly for each test case from supported values within the range [128-65535] bits. The payload size and data unit size must not be equal.

The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

AES-CTR

Identifier	Cryptographic Algorithm	Cryptographic Key Sizes	List of Standards
AES-CTR	AES in Counter Mode with a non-repeating initial counter and with no repeated use of counter values across multiple messages with the same secret key.	256 bits	[selection: ISO/IEC 18033-3:2010 (Subclause 5.2), FIPS PUB 197] [AES] [selection: ISO/IEC 10116:2017 (Clause 10), NIST SP 800-38A] [CTR]

To test the TOE’s ability to encrypt and decrypt data using AES in CTR mode, the evaluator shall perform the Algorithm Functional Test and the Counter Test using the following input parameters:

• Direction [encryption, decryption]
• Key size [256] bits

Algorithm Functional Tests

Algorithm Functional Tests are designed to verify the correct operation of the logical components of the algorithm implementation under normal operation using different block sizes. For AES-CTR, there are three types of AFTs:

Known-Answer Tests

For each combination of direction and claimed key size, the TOE must be tested using the GFSBox, KeySbox, VarTxt, and VarKey test cases listed in Appendixes B through E of The Advanced Encryption Standard Algorithm Validation Suite (AESAVS), NIST, 15 November 2002.

Single Block Message Tests

For each combination of direction and claimed key, the evaluator shall generate 10 test cases with a data size of 128 bits.

Partial Block Message Tests

Monte Carlo tests are intended to test the implementation under strenuous conditions. The TOE must process the test cases according to the following algorithm once for each combination of direction and key size:

For each combination of direction and claimed key, the evaluator shall generate five test cases such that the data size is not a multiple of 128 bits.

The evaluator shall verify the correctness of the TSF’s implementation by comparing values generated by the TSF with those generated by a known good implementation using the same input parameters.

Counter Test

The evaluator shall generate a single message of 1000 blocks (128000 bits) and either encrypt or decrypt it. Back-compute the IVs used and verify that they are unique and increasing (encryption) or decreasing (decryption).

The evaluator shall check the TSS to ensure that it lists all persistent sensitive data for which the OS provides a storage capability. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it can be used, and how it is stored. The evaluator shall confirm that cryptographic operations used to protect the data occur as specified in FCS_COP.1/SKC.

The evaluator shall consult the developer documentation to verify that instructions exists on applications should securely store credentials.

The evaluator shall confirm that the TSS comprehensively describes the access control policy enforced by the OS. The description must include the rules by which accesses to particular files and directories are determined for particular users. The evaluator shall inspect the TSS to ensure that it describes the access control rules in such detail that given any possible scenario between a user and a file governed by the OS the access control decision is unambiguous.

The evaluator shall create two new standard user accounts on the TOE and conduct the tests below. If the TSF enforces access controls on user home directories that prevents the evaluator from exercising the permissions directly (i.e., because the home directory itself or its contents are restricted by permissions), the evaluator shall temporarily relax the permissions on the parent directory/directories in order to perform the tests.

• Test FDP_ACF_EXT.1:1: The evaluator shall authenticate to the system as the first user and create a file within that user's home directory. The evaluator shall then log off the system and log in as the second user. The evaluator shall then attempt to read the file created in the first user's home directory. The evaluator shall ensure that the read attempt is denied.
• Test FDP_ACF_EXT.1:2: The evaluator shall authenticate to the system as the first user and create a file within that user's home directory. The evaluator shall then log off the system and log in as the second user. The evaluator shall then attempt to modify the file created in the first user's home directory. The evaluator shall ensure that the modification is denied.
• Test FDP_ACF_EXT.1:3: The evaluator shall authenticate to the system as the first user and create a file within that user's user directory. The evaluator shall then log off the system and log in as the second user. The evaluator shall then attempt to delete the file created in the first user's home directory. The evaluator shall ensure that the deletion is denied.
• Test FDP_ACF_EXT.1:4: The evaluator shall authenticate to the system as the first user. The evaluator shall attempt to create a file in the second user's home directory. The evaluator shall ensure that the creation of the file is denied.
• Test FDP_ACF_EXT.1:5: The evaluator shall authenticate to the system as the first user and attempt to modify the file created in the first user's home directory. The evaluator shall ensure that the modification of the file is accepted.
• Test FDP_ACF_EXT.1:6: The evaluator shall authenticate to the system as the first user and attempt to delete the file created in the first user's directory. The evaluator shall ensure that the deletion of the file is accepted.

The evaluator shall examine the TSS to verify that it defines the mechanism by which excessive authentication failures are checked (i.e, whether it is a fixed or configurable value) and the actions that are taken against that account when the failure threshold has been reached.

The evaluator shall examine the operational guidance to verify that it identifies either the fixed number of successive authentication failures that triggers a response to occur, or if this is a configurable value, the mechanism by which the value is configured. The evaluator shall also examine the operational guidance to verify that it describes the behavior that occurs when the failure threshold is met. If this behavior is configurable, the evaluator shall verify that the operational guidance provides instructions for how to set each response as claimed in FIA_AFL.1.2.

If configurable, the evaluator shall set an administrator-configurable threshold for failed authentication attempts, or note the ST-specified assignment. The evaluator will then (per selection) repeatedly attempt to authenticate with an incorrect password, PIN, certificate, or biometric until the number of attempts reaches the threshold and observe that the behavior claimed in FIA_AFL.1.2 occurs. If the behavior in FIA_AFL.1.2 is configurable, the evaluator shall repeat this test as necessary for each configured behavior and verify that the configured behavior occurs in all cases. Note that the authentication attempts and lockouts must also be logged as specified in FAU_GEN.1.

• Test FIA_AFL.1:1: [conditional, to be performed if "authentication based on user name and password" is selected in FIA_AFL.1 and FIA_UAU.5]: The evaluator shall attempt to authenticate repeatedly to the system with a known bad password. Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.
• Test FIA_AFL.1:2: [conditional, to be performed if "authentication based on user name and a PIN that releases an asymmetric key stored in OE-protected storage" is selected in FIA_AFL.1 and FIA_UAU.5]: The evaluator shall attempt to authenticate repeatedly to the system with a known bad PIN. Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.
• Test FIA_AFL.1:3: [conditional, to be performed if "authentication based on X.509 certificates" is selected in FIA_AFL.1 and FIA_UAU.5]:The evaluator shall attempt to authenticate repeatedly to the system using a known bad certificate. Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.
• Test FIA_AFL.1:4: [conditional, to be performed if "authentication based on biometric in accordance with the Biometric Enrollment and Verification, version 1.1" or "hybrid" is selected in FIA_AFL.1 and FIA_UAU.5]:The evaluator shall attempt to authenticate repeatedly to the system using a known bad biometric authentication factor. Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.
• Test FIA_AFL.1:5: [conditional, to be performed if "hybrid" is selected in FIA_AFL.1 and FIA_UAU.5]:

  The evaluator shall attempt to authenticate repeatedly to the system using a known bad primary authentication factor (PIN, Password, certificate). Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.

  The evaluator shall then attempt to authenticate repeatedly to the system using a known good primary authentication factor (PIN, Password, certificate) but a known bad biometric authentication factor. Once the defined number of failed authentication attempts has been reached the evaluator shall ensure that the account that was being used for testing has had the actions detailed in the assignment list above applied to it. The evaluator shall ensure that an event has been logged to the security event log detailing that the account has had these actions applied.

The evaluator shall ensure that the TSS describes the rules as to how each authentication mechanism specified in FIA_UAU.5.1 is implemented and used. Example rules are how the authentication mechanism authenticates the user (i.e. how does the TSF verify that the correct password or authentication factor is used), the result of a successful authentication (i.e. is the user input used to derive or unlock a key) and which authentication mechanism can be used at which authentication factor interfaces (i.e. if there are times, for example, after a reboot, that only specific authentication mechanisms can be used). Rules regarding how the authentication factors interact in terms of unsuccessful authentication are covered in FIA_AFL.1. If multiple Biometric Authentication Factors are claimed in FIA_MBV_EXT.1.1 in the Biometric Enrollment and Verification, version 1.1, the interaction between the BAFs must be described. For example, whether the multiple BAFs can be enabled at the same time.

The evaluator shall verify that configuration guidance for each authentication mechanism is addressed in the AGD guidance.

Authentication mechanisms related to authentication based on X.509 certificates are tested under FIA_X509_EXT.1 as defined in the Functional Package for X.509, version 1.0 and SSH public key-based authentication are tested in the Functional Package for Secure Shell (SSH), version 2.0. Biometric authentication mechanisms are tested in the Biometric Enrollment and Verification, version 1.1.

For each authentication mechanism rule, the evaluator shall ensure that the authentication mechanism(s) behave as documented in the TSS.

The evaluator shall verify that the TSS describes those management functions that are restricted to Administrators, including how the user is prevented from performing those functions, or not able to use any interfaces that allow access to that function.

The evaluator shall examine the operational guidance to verify that for the functions claimed in FMT_SMF_EXT.1 as being restricted to the administrator (i.e., the user cannot perform them), the guidance identifies how that restriction is enforced (i.e., what role or permission permits the ability to perform the function).

The evaluator shall also perform the following test.

• Test FMT_MOF_EXT.1:1: For each function that is indicated as restricted to the administrator, the evaluation will perform the function as an administrator, as specified in the Operational Guidance, and determine that it has the expected effect as outlined by the Operational Guidance and the SFR. The evaluator shall then perform the function (or otherwise attempt to access the function) as a non-administrator and observe that they are unable to invoke that functionality.

The evaluator shall examine the TSS to verify that identifies the management functions claimed by the TOE and whether they can be performed by an administrator, a user, or both.

The evaluator shall examine the operational guidance verify that every management function captured in the ST is described in the operational guidance and that the description contains the information required to perform the management duties associated with the management function.

The evaluator shall test the OS's ability to provide the management functions by configuring the operating system and testing each option selected from above. The evaluator is expected to test these functions in all the ways in which the ST and guidance documentation state the configuration can be managed.

The evaluator shall confirm that the TSS specifies the locations of kernel drivers/modules, security audit logs, shared libraries, system executables, and system configuration files. Every file does not need to be individually identified, but the system's conventions for storing and protecting such files must be specified.

The evaluator shall create an unprivileged user account. Using this account, the evaluator shall ensure that the following tests result in a negative outcome (i.e., the action results in the OS denying the evaluator permission to complete the action):

• Test FPT_ACF_EXT.1:1: The evaluator shall attempt to modify all kernel drivers and modules.
• Test FPT_ACF_EXT.1:2: The evaluator shall attempt to modify all security audit logs generated by the logging subsystem.
• Test FPT_ACF_EXT.1:3: The evaluator shall attempt to modify all shared libraries that are used throughout the system.
• Test FPT_ACF_EXT.1:4: The evaluator shall attempt to modify all system executables.
• Test FPT_ACF_EXT.1:5: The evaluator shall attempt to modify all system configuration files.
• Test FPT_ACF_EXT.1:6: The evaluator shall attempt to modify any additional components selected.

The evaluator shall create an unprivileged user account. Using this account, the evaluator shall ensure that the following tests result in a negative outcome (i.e., the action results in the OS denying the evaluator permission to complete the action):

• Test FPT_ACF_EXT.1:7: The evaluator shall attempt to read security audit logs generated by the auditing subsystem
• Test FPT_ACF_EXT.1:8: The evaluator shall attempt to read system-wide credential repositories
• Test FPT_ACF_EXT.1:9: The evaluator shall attempt to read any other object specified in the assignment

The evaluator shall examine the TSS to verify that it identifies the number of entropy bits used for ASLR and what exceptions there are to this, if any.

The evaluator shall select 3 executables included with the TSF. If the TSF includes a web browser it must be selected. If the TSF includes a mail client it must be selected. For each of these apps, the evaluator shall launch the same executables on two separate instances of the OS on identical hardware and compare all memory mapping locations. The evaluator shall ensure that no memory mappings are placed in the same location. If the rare chance occurs that two mappings are the same for a single executable and not the same for the other two, the evaluator shall repeat the test with that executable to verify that in the second test the mappings are different. This test can also be completed on the same hardware and rebooting between application launches.

The evaluator shall verify that the TSF describes how the TOE enters an error state in the event of a DRBG self-test failure.

The evaluator shall verify that the guidance documentation describes the error state that results from a DRBG self-test failure and the actions that a user or administrator should take in response to attempt to resolve the error state.

The evaluator shall examine the TSS to verify that it describes how stack-based buffer overflow protection is implemented, or how the TOE is designed in such a way that these protections are not explicitly needed.

For stack-based OSes, the evaluator shall determine that the TSS contains a description of stack-based buffer overflow protections used by the OS. These are referred to by a variety of terms. These include, but are not limited to, tagging, stack cookie, stack guard, and stack canaries. The TSS must include a rationale for any binaries that are not protected in this manner. The evaluator shall also preform the following test:

• Test FPT_SBOP_EXT.1:1: [Conditional: if stack-based overflow detection can be determined by inventorying]: The evaluator shall inventory the kernel, libraries, and application binaries to determine those that do not implement stack-based buffer overflow protections. This list should match up with the list provided in the TSS.

For OSes that store parameters/variables separately from control flow values, the evaluator shall verify that the TSS describes what data structures control values, parameters, and variables are stored. The evaluator shall also ensure that the TSS includes a description of the safeguards that ensure parameters and variables do not intermix with control flow values.

The evaluator shall examine the TSS to ensure that it details the self-tests that are run by the TSF along with how they are run. This description should include an outline of what the tests are actually doing. The evaluator shall ensure that the TSS makes an argument that the tests are sufficient to demonstrate that the DRBG is operating correctly.

Note that this information may also be placed in the entropy documentation specified by Appendix E - Entropy Documentation and Assessment.

If a self-test can be executed at the request of an authorized user, the evaluator shall verify that the operational guidance provides instructions on how to execute that self-test.

For each self-test, the evaluator shall verify that evidence is produced that the self-test is executed when specified by FPT_TST.1.1.

If a self-test can be executed at the request of an authorized user, the evaluator shall verify that following the steps documented in the operational guidance to perform the self-test will result in execution of the self-test.

The evaluator shall examine the TSS to ensure that it lists each security function that makes use of time, and that it identifies the primary time source that can be considered to be reliable. The evaluator shall examine the TSS to verify that it describes the TOE's ability to obtain time data from an NTP server, a cellular carrier network, or a hypercall to the TOE's hardware platform if running on a virtualization system.

If this functionality is configurable, the evaluator shall examines the operational guidance to ensure it describes how to set the time directly or how to configure the TOE's primary time source.

• Test FPT_STM.1:1: If the time is configurable, the evaluator shall follow the operational guidance to set the time. The evaluator shall then use an available interface to observe that the time was set correctly. If the primary time source is configurable, the evaluator shall deliberately set the time to an incorrect value, verify the incorrect time setting is applied, configure the TOE to connect to the primary time source, and verify that the time is subsequently synchronized to the expected time.

The evaluator shall verify that the TSS section of the ST includes a comprehensive description of the boot procedures, including a description of the entire bootchain, for the TSF. The evaluator shall ensure that the OS cryptographically verifies each piece of software it loads in the bootchain to include bootloaders and the kernel. Software loaded for execution directly by the platform (e.g. first-stage bootloaders) is out of scope. For each additional category of executable code verified before execution, the evaluator shall verify that the description in the TSS describes how that software is cryptographically verified.

The evaluator shall verify that the TSS contains a description of the protection afforded to the mechanism performing the cryptographic verification.

The evaluator shall also perform the following tests:

• Test FPT_TST_EXT.1:1: The evaluator shall perform actions to cause TSF software to load and observe that the integrity mechanism does not flag any executables as containing integrity errors and that the OS properly boots.
• Test FPT_TST_EXT.1:2: The evaluator shall modify a TSF executable that is part of the bootchain verified by the TSF (i.e. Not the first-stage bootloader) and attempt to boot. The evaluator shall ensure that an integrity violation is triggered and the OS does not boot (Care must be taken so that the integrity violation is determined to be the cause of the failure to load the module, and not the fact that in such a way to invalidate the structure of the module.).
The following content should be included if:
• a digital signature using an X.509 certificate with hardware-based protection is selected from FPT_TST_EXT.1.1
If the ST author indicates that the integrity verification is performed using public key in an X509 certificate, the evaluator shall verify that the boot integrity mechanism includes a certificate validation according to in accordance with FIA_X509_EXT.1 as defined in the Functional Package for X.509, version 1.0 for all certificates in the chain from the certificate used for boot integrity to a certificate in the trust store that are not themselves in the trust store. This means that, for each X.509 certificate in this chain that is not a trust store element, the evaluator must ensure that revocation information is available to the TOE during the bootstrap mechanism (before the TOE becomes fully operational).

The evaluator shall examine the TSS to verify that it describes how the TSF checks for updates and how it verifies those updates are genuine.

The evaluator shall examine the operational guidance to verify that it describes how to use the TOE to check for and initiate updates to itself and how to determine that an integrity check of the update has failed.

The evaluator shall check for an update using procedures described in the documentation and verify that the OS provides a list of available updates. Testing this capability may require installing and temporarily placing the system into a configuration in conflict with secure configuration guidance which specifies automatic update.

The evaluator is also to ensure that the response to this query is authentic by using a digital signature scheme specified in FCS_COP.1/SigVer. The digital signature verification may be performed as part of a network protocol that uses a trusted channel as described in FTP_ITC_EXT.1. If the signature verification is not performed as part of a trusted channel, the evaluator shall send a query response with a bad signature and verify that the signature verification fails. The evaluator shall then send a query response with a good signature and verify that the signature verification is successful.

For the following tests, the evaluator shall initiate the download of an update and capture the update prior to installation. The download could originate from the vendor's website, an enterprise-hosted update repository, or another system (e.g. network peer). All update mechanisms supported by the TOE must be evaluated. However, this only includes those mechanisms for which the TSF is providing a trusted installation and update functionality. It does not include user or administrator-driven download and installation of arbitrary files.

• Test FPT_TUD_EXT.1:1: The evaluator shall ensure that the update has a digital signature belonging to the vendor prior to its installation. The evaluator shall modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator will then attempt to install the modified update. The evaluator shall ensure that the OS does not install the modified update.
• Test FPT_TUD_EXT.1:2: The evaluator shall ensure that the update has a digital signature belonging to the vendor. The evaluator shall then attempt to install the update (or permit installation to continue). The evaluator shall ensure that the OS successfully installs the update.

The evaluator shall examine the TSS to verify that it describes the TOE's ability to check for updates to application software and how the authenticity and integrity of these updates are verified.

The evaluator shall examine the operational guidance to verify that it provides instructions for how to use the TOE to check for updates to application software, and how to determine if the check for authenticity or integrity of the update failed.

The evaluator shall check for updates to application software using procedures described in the documentation and verify that the OS provides a list of available updates. Testing this capability may require temporarily placing the system into a configuration in conflict with secure configuration guidance which specifies automatic update.

The evaluator shall also ensure that the response to this query is authentic by using a digital signature scheme specified in FCS_COP.1/SigVer. The digital signature verification may be performed as part of a network protocol that uses a trusted channel as described in FTP_ITC_EXT.1. If the signature verification is not performed as part of a trusted channel, the evaluator shall send a query response with a bad signature and verify that the signature verification fails. The evaluator shall then send a query response with a good signature and verify that the signature verification is successful.

The evaluator shall initiate an update to an application. This may vary depending on the application, but it could be through the application vendor's website, a commercial app store, or another system. All update mechanisms supported by the TOE must be evaluated. However, this only includes those mechanisms for which the TSF is providing a trusted installation and update functionality. It does not include user or administrator-driven download and installation of arbitrary files.

• Test FPT_TUD_EXT.2:1: The evaluator shall ensure that the update has a digital signature which chains to the OS vendor or another trusted root managed through the OS. The evaluator shall modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator shall then attempt to install the modified update. The evaluator shall ensure that the OS does not install the modified update.
• Test FPT_TUD_EXT.2:2: The evaluator shall ensure that the update has a digital signature belonging to the OS vendor or another trusted root managed through the OS. The evaluator shall then attempt to install the update. The evaluator shall ensure that the OS successfully installs the update.