Summit Linux FIPS Core Crypto Module

Certificate

Approved Algorithms (70)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Summit Linux FIPS Core Crypto Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Error State</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Kernel AES-ECB<br/>Kernel AES-CTR<br/>Kernel AES-CBC</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Summit Linux FIPS Core Crypto Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Error State</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Kernel AES-ECB<br/>Kernel AES-CTR<br/>Kernel AES-CBC</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

Ezurio Summit Linux FIPS Core Crypto Module Document Version: 1.1 Last Modified: 04/04/2025 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com © 2025 Ezurio/atsec information security.

© 2025 Ezurio/atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for the Summit Linux FIPS Core Crypto Module, firmware version 11.0. It contains the security rules under which the module must be operated and describes how this module meets the requirements as specified in FIPS 140-3 (Federal Information Processing Standards Publication 140-3) for a This Security Policy contains non-proprietary information. All other documentation submitted for FIPS 140-3 conformance testing and validation is proprietary and is releasable only under appropriate non-disclosure agreements.

which was further consolidated into this document by atsec information security together with other vendor-supplied documentation. In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would then edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing.

Table 1: Security Levels N/A © 2025 Ezurio/atsec information security.

Purpose and Use: The Summit Linux FIPS Core Crypto Module (hereafter referred to as the “module”) is a firmware module supporting FIPS 140-3 Approved cryptographic algorithms. The module is composed by firmware components comprised of a kernel and OpenSSL library. These firmware components provide a C language application program interface (API) for use by other processes that require cryptographic functionality. The module offers approved cryptographic functions in the approved mode for, among other uses:

• Algorithms for use in the Wi-Fi protocols CCMP and GCMP.
• Algorithms for use in the TLS protocol.
• Encryption and decryption for data at rest. Module Type: Firmware Module Embodiment: MultiChipStand Cryptographic Boundary: The Summit Linux FIPS Core Crypto Module is defined as a firmware, Multi-Chip Standalone module per the requirements within FIPS 140-3. The cryptographic boundary of the module consists of the firmware component files (kernel, FIPS Provider, and the fipscheck integrity test tool) and the integrity test HMAC files. For easier readability in the rest of the document “OpenSSL FIPS provider” has been shortened to “FIPS provider”. Tested Operational Environment’s Physical Perimeter (TOEPP): Figure 1 below depicts the physical representations of the tested platforms as the top and bottom view of the circuit board. The tested environments are further described in Section 6. © 2025 Ezurio/atsec information security.

Figure 1: Physical configurations of the tested platform (top and bottom in order). Figure 2 below shows the block diagram of the module. The cryptographic boundary is indicated with yellow blocks, distributed among firmware components. Blocks of another color do not belong to the cryptographic boundary. Users of the module interact through the API that are the logical interfaces data input, data output, control input, status output. A dotted line encompasses the module’s components that interface through the API. In Figure 2, users of the module are exemplified by applications. These applications may reside within the NAND Flash memory or may reside outside (but still within the physical perimeter), always interacting with the module’s API. The physical perimeter of the module is defined as the perimeter of the circuit board on which the module is installed. The filesystem and operating system reside on NAND Flash memory within the physical perimeter. © 2025 Ezurio/atsec information security.

Tested Module Identification

• Software, Firmware, Hybrid (Executable Code Sets): N/A Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Operational Environments - Software, Firmware, Hybrid: N/A © 2025 Ezurio/atsec information security.

Table 3: Tested Operational Environments - Software, Firmware, Hybrid CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements.

Modes List and Description: NonAutomatically entered Table 4: Modes List and Description NonApproved After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode. Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of

Approved Algorithms: © 2025 Ezurio/atsec information security.

© 2025 Ezurio/atsec information security.

HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2512 HMAC-SHA3224 HMAC-SHA3256 HMAC-SHA3384 HMAC-SHA3512 © 2025 Ezurio/atsec information security.

© 2025 Ezurio/atsec information security.

KDF SP800108 © 2025 Ezurio/atsec information security.

SHA2512/224 SHA2512/256 Table 5: Approved Algorithms Vendor-Affirmed Algorithms: © 2025 Ezurio/atsec information security.

Table 6: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: Table 7: Non-Approved, Not Allowed Algorithms

HMACSHA2-256: HMACSHA2-384: © 2025 Ezurio/atsec information security.

KAS-ECCSSC AES-CBCCS3 HMACSHA2-512: HMACSHA2-256: HMACSHA2-384: HMACSHA2-512: KAS-ECCSSC Sp80056Ar3: AES-CBCCS3: © 2025 Ezurio/atsec information security.

HMACSHA2-224: HMACSHA2-256: HMACSHA2-384: HMACSHA2-512: HMACSHA3-224: HMACSHA3-256: HMACSHA3-384: © 2025 Ezurio/atsec information security.

KAS-IFCSSC KAS-IFCSSC: © 2025 Ezurio/atsec information security.

AsymKeyPairKeyVer KAS-FFCSSC KAS-ECCSSC KAS-FFCSSC Sp80056Ar3: KAS-ECCSSC Sp80056Ar3: © 2025 Ezurio/atsec information security.

AES-CBCCS1 AES-CBCCS2 AES-CBCCS3 AESCFB128 AES-CBCCS1: AES-CBCCS2: AES-CBCCS3: AESCFB128: © 2025 Ezurio/atsec information security.

AsymKeyPairKeyVer DigSigSigGen DigSigSigGen © 2025 Ezurio/atsec information security.

DigSigSigGen HMACSHA2-224: HMACSHA2-256: HMACSHA2-384: HMACSHA2-512: HMACSHA2512/224: HMACSHA2512/256: HMACSHA3-224: HMACSHA3-256: © 2025 Ezurio/atsec information security.

HMACSHA3-384: HMACSHA3-512: SHA2512/224: SHA2512/256: © 2025 Ezurio/atsec information security.

Passwordbased Key Sp80056Cr1: SP80056Cr2: SP80056Cr2: © 2025 Ezurio/atsec information security.

Table 8: Security Function Implementations Sp800108r1: KDF SP800108:

AES-GCM encryption and decryption are used in the context of the TLS protocol version 1.2 and 1.3 using the FIPS provider component (corresponding to Scenario 1 and 5 of IG C.H), and in the context of IEEE 802.11 GCMP using the kernel/hardware components (corresponding to Scenario 5 of IG C.H). For IPsec, the module offers the AES GCM implementation and uses the context of Scenario 1 of FIPS 140-3 IG C.H. The mechanism for IV generation is compliant with RFC 4106. IVs generated using this mechanism may only be used in the context of AES GCM encryption within the IPsec protocol. Alternatively, the Crypto Officer can use the module’s API to perform AES GCM encryption using internal IV generation. These IVs are always 96 bits and generated using the approved DRBG internal to the module’s boundary, compliant with Scenario 2 of FIPS 140-3 IG C.H. The module also provides a non-approved AES GCM encryption service which accepts arbitrary external IVs from the operator. This service can be requested by invoking the EVP_EncryptInit_ex2 API function with a non-NULL iv value. When this is the case, the API will set a non-approved service indicator.

For TLS v1.2, the module uses the context of Scenario 1 of IG C.H. The module is compliant with SP 800-52 section 3.3.1 and the mechanism for IV generation is compliant with RFC5288. For this compliance, the module’s implementation of the AES-GCM shall be used together with an application that negotiates the protocol session’s keys and the 32-bit nonce value of the IV. The setting of the counter portion of the IV is performed within the cryptographic boundary. The nonce explicit part of the IV does not exhaust the maximum number of possible values for a given session key. This condition is implicitly ensured by the design of the TLS protocol, in which the nonce_explicit is denied exhaustion by the control exerted by the protocol’s management logic (wherein the nonce_explicit is incremented per each TLS record). This management logic also implies that the probability of an exhaustion of all 264

• 1 values of the nonce_explicit for the same TLS session in a realistic time frame is not significant. © 2025 Ezurio/atsec information security.

In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established.

For TLS 1.3, the AES GCM implementation uses the context of Scenario 5 of FIPS 140-3 IG C.H. The protocol that provides this compliance is TLS 1.3, defined in RFC8446 of August 2018, using the cipher-suites that explicitly select AES GCM as the encryption/decryption cipher (Appendix B.4 of RFC8446). The module supports acceptable AES GCM cipher suites from Section 3.3.1 of SP800-52r2. TLS 1.3 employs separate 64-bit sequence numbers, one for protocol records that are received, and one for protocol records that are sent to a peer. These sequence numbers are set at zero at the beginning of a TLS 1.3 connection and each time when the AES-GCM key is changed. After reading or writing a record, the respective sequence number is incremented by one. The protocol specification determines that the sequence number should not wrap, and if this condition is observed, then the protocol implementation must either trigger a re-key of the session (i.e., a new key for AES-GCM), or terminate the connection. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established.

The kernel component is in compliance with FIPS 140-3 IG C.H scenario 5 for the WPA2 protocol. Specifically, GCMP is defined in IEEE 802.11ac-2013. For IEEE 802.11 GCMP, the module implements an internal production unit logic that constructs the IV deterministically upon the initialization of a GCMP connection, and therefore the initialization of a GCM encryption context." and "In case the module's power is lost and then restored, the key used for AES GCM encryption or decryption shall be re-distributed.

The length of a single data unit encrypted or decrypted with AES XTS shall not exceed 220 AES blocks, that is 16MB, of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, such as the encryption of data in transit.

The module provides password-based key derivation (PBKDF2), compliant with SP 800-132. The module supports option 1a from Section 5.4 of SP 800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance to SP 800-132 and FIPS 140-3 IG D.N, the following requirements shall be met:

• Derived keys shall only be used in storage applications. The MK shall not be used for other purposes. The length of the MK or DPK shall be of 112 bits or more.
• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic keys. © 2025 Ezurio/atsec information security.

• The length of the password or passphrase shall be at least 8 characters. The probability of guessing the value, assuming a worst-case scenario of all digits, is estimated to be at most 10-8. Combined with the minimum iteration count as described below, this provides an acceptable trade-off between user experience and security against brute-force attacks. A portion of the salt, with a length of at least 128 bits, shall be generated randomly using the SP 800-90Ar1 DRBG provided by the module. The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The minimum value is 1000.

Kernel Component: The module offers ECDH shared secret computation services compliant to the SP 800-56ARev3. In order to meet the required assurances listed in section

5.6 of SP 800-56ARev3, the module shall be used together with an application that

implements the "IPsec protocol" and the following steps shall be performed.

1. The entity using the module, must use the module's "key pair generation" service for generating ECDH ephemeral keys. The key generation service performs full public key validation. This meets the assurances required by key pair owner defined in the section 5.6.2.1 of SP 800-56ARev3.
2. The consumer using the module doesn't need to obtain assurance of the peer's possession of private key as the module only makes use of ephemeral keys.
3. As part of the module’s shared secret computation service, the module internally performs the public key validation on the peer's public key passed in as input to the SSC function. This meets the public key validity assurance required by the sections 5.6.2.2.1/5.6.2.2.2 of SP 800-56ARev3. FIPS provider Component: The module offers DH and ECDH shared secret computation services compliant to the SP 800-56ARev3. To comply with the assurances found in Section

5.6.2 of SP 800-56Ar3, the operator must use the module together with an application that

implements the TLS protocol. Additionally, the module’s approved key pair generation service must be used to generate ephemeral Diffie-Hellman or EC Diffie-Hellman key pairs, or the key pairs must be obtained from another FIPS-validated module. As part of this service, the module will internally perform the full public key validation of the generated public key. The module’s shared secret computation service will internally perform the full public key validation of the peer public key, complying with Sections 5.6.2.2.1 and 5.6.2.2.2 of SP 800-56Ar3.

To comply with SP800-56Br2 assurances found in its Section 6 (specifically SP800-56Br2 Section 6.4 Required Assurances) the entity using the module must obtain required assurances listed in section 6.4 of SP 800-56Br2 by performing the following steps:

1. The entity requesting the RSA key un-encapsulation service from the module, shall only use an RSA private key that was generated by an active FIPS validated module that implements FIPS 186-5 compliant RSA key generation service and performs the key pair validity and the pairwise consistency as stated in section 6.4.1.1 of the SP 800-56Br2. Additionally, the entity shall renew these assurances over time by using any method described in section 6.4.1.5 of the SP 800-56Br2.
2. For use of an RSA key encapsulation service in the context of key transport per IG D.G the entity using the module shall: © 2025 Ezurio/atsec information security.

a. verify the validity of the peer’s public key using the public key validation service of the module (EVP_PKEY_check() API). b. confirm the peer’s possession of private key by using any method specified in section 6.4.2.3 of the SP 800-56Br2. Only after the above assurances are successfully met, shall the entity use the peer’s public key to perform the RSA key encapsulation service of the module.

To comply with the assurances found in Section 6.4 of SP 800-56Br2, the module’s approved RSA key pair generation service must be used to generate the RSA key pairs, or the key pairs must be obtained from another FIPS-validated module. As part of this service, the module will internally perform the key pair validity and the pairwise consistency according to section 6.4.1.1 of SP 800-56Br2. Additionally, the entity requesting the shared secret computation service shall verify the validity of the peer’s public key using the public key validation service of the module (EVP_PKEY_check() API). This service will perform the full public key validation of the peer’s public key, complying with Section 6.4.2.1 of SP 800-56Br2.

The module provides RSA signature generation and signature verification compliant with IG C.F. The module supports RSA modulus lengths of 2048, 3072, and 4096 bits for signature generation and 1024, 2048, 3072, and 4096 for signature verification. The RSA signature generation and signature verification implementations have been tested for all implemented RSA modulus lengths. The number of Miller-Rabin tests is consistent with the bit sizes of p and q from Table B.1 of FIPS 186-4.

The module provides SHA-3 hash functions compliant with IG C.C. Every implementation of each SHA-3 function was tested and validated on all of the module’s operating environments. SHAKE functions are not implemented. SHA-3 hash functions are also used as part of a higher-level algorithm for HMAC.

Table 9: Entropy Certificates © 2025 Ezurio/atsec information security.

Table 10: Entropy Sources A4713 (SHA3256) The module provides DRBG’s compliant with SP800-90A for random number generation and the creation of key components of asymmetric keys. The kernel component DRBG implements a CTR_DRBG mechanism with AES-128, AES-192 or AES-256, with selectable enabling of derivation function and prediction resistance. The FIPS provider component DRBG’s implements a CTR_DRBG mechanism with AES-128, AES-192 or AES-256 with selectable enabling of derivation function and prediction resistance. Additionally, a Hash_DRBG and HMAC_DRBG mechanism with SHA-1, SHA-256 or SHA-512 with selectable enabling of derivation function and prediction resistance is implemented. Lastly the kernel and FIPS Provider DRBG’s are seeded with 320 bits and assessed to be full entropy in the ESV certificate #E119 at 1 bit/bit or 256 bits of entropy.

For generating RSA, ECDSA, Diffie-Hellman, EC Diffie-Hellman keys for the FIPS Provider component and ECDSA keys for Kernel component, the module implements asymmetric key generation services compliant with FIPS186-5 or SP800-56Arev3 as applicable and using a DRBG compliant with SP800-90A. The random value used in asymmetric key generation is obtained from the DRBG. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per Section 4 of SP800-133rev2 (vendor affirmed). Additionally, the module implements the following key derivation methods according to section 6.2 of SP 800-133r2:

• HKDF compliant with SP 800-56Cr1: derivation of secret keys in the context of an SP 800-56Ar3 and SP 800-56Br2 key agreement schemes. TLS KDF compliant with SP 800-135r1: derivation of secret keys in the context of the TLS 1.0/1.1, TLS 1.2 and TLS 1.3 protocols. PBKDF2: compliant with option 1a of SP 800-132: derivation of keys for use in storage applications. ANS 9.42 KDF compliant with SP 800-135r1: derivation of secret keys in the context of ANS X9.42-2001 key agreement schemes. ANS 9.63 KDF compliant with SP 800-135r1: derivation of secret keys in the context ANS X9.63-2001 key agreement schemes. KBKDF compliant with Sp800-108r1: derivation of secret keys. KDA OneStep and KDA TwoStep compliant with SP800-56Cr2: derivation of secret keys in the context of SP 800-56Ar3 and SP 800-56Br2 key agreement schemes.

The module implements following key establishments methods that are listed in the Security Function Implementations table: - shared secret computation for KAS-IFC-SSC, KAS-FFC-SSC KAS-ECC-SSC © 2025 Ezurio/atsec information security.

- key transport for KTS-IFC and KTS-Wrap

For DH, the module supports the use of the safe primes defined in RFC 3526 (IKE) and RFC

7919 (TLS) as listed in Approved Services table. Note that the module only implements key

pair generation, key pair verification, and shared secret computation. No other part of the IKE or TLS protocols is implemented (with the exception of the TLS 1.2 and 1.3 KDFs). SSH KDF, TLS 1.0/1.1 KDF, TLS 1.2 KDF (RFC 7627), TLS 1.3 KDF implementations shall only be used to generate secret keys in the context of the SSH, TLS 1.0/1.1, TLS 1.2, or TLS 1.3 protocols, respectively. Note that TLS 1.2 KDF must be compliant with RFC 7627 to be considered approved. ANS X9.42 KDF and ANS X9.63 KDF implementations shall only be used to generate secret keys in the context of an ANS X9.42-2001 resp. ANS X9.63-2001 key agreement scheme. © 2025 Ezurio/atsec information security.

N/A N/A N/A N/A N/A Table 11: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design. © 2025 Ezurio/atsec information security.

Table 12: Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators.

s n t AESECB AESCTR AESCBC AESCBCCS3 AESXTS AESECB AESCTR AESCBC AESCBCCS3 AESXTS W,E W,E © 2025 Ezurio/atsec information security.

s n t d AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (KTSWrap) AESGCM (KTSWrap) AESCCM (KTSWrap) AESGCM (KTSWrap) W,E W,E W,E W,E © 2025 Ezurio/atsec information security.

s e e ea ea e KASECCSSC e AESCMAC AESGMAC W,E W,E C): W,E © 2025 Ezurio/atsec information security.

s n ea t e t er AESCTR er AESCBC er AESECB er AESCBCCS1 er AESCBCCS2 er AESCBCCS3 er AESCFB1 G,E,Z W,E © 2025 Ezurio/atsec information security.

s er AESCFB8 er AESCFB12 er AESXTS er AESOFB er AESCTR er AESCBC er AESECB er AESCBCCS1 er AESCBCCS2 er AESCBCCS3 er AESCFB1 er AESCFB8 W,E © 2025 Ezurio/atsec information security.

s n t t e e er AESCFB12 er AESXTS er AESOFB er AESCCM (BCAuth) er AESGCM (BCAuth) er AESCCM (BCAuth) er AESGCM (BCAuth) er AESCMAC er AESGMAC W,E W,E W,E © 2025 Ezurio/atsec information security.

s er KASFFCSSC ea ea er KASECCSSC ea er KASIFCSSC n W,E W,E W,E © 2025 Ezurio/atsec information security.

s 1.0 1.1 1.2 1.3 keyderivation Preshared W,E W,E © 2025 Ezurio/atsec information security.

s n d d DHGroup ordbased W,E W,E W,E © 2025 Ezurio/atsec information security.

s G,E,Z G,E,Z G,E,Z © 2025 Ezurio/atsec information security.

s d er AESCCM (KTSWrap) er AESGCM (KTSWrap) er AESCCM (KTSWrap) er AESGCM (KTSWrap) W,E W,E © 2025 Ezurio/atsec information security.

s e e e e m m e e m e e e m e © 2025 Ezurio/atsec information security.

s e er KTSIFC key unencapsul er KTSIFC N/A N/A N/A SelfTests G,W,E C): G,W,E © 2025 Ezurio/atsec information security.

s N/A Z C): Z © 2025 Ezurio/atsec information security.

s © 2025 Ezurio/atsec information security.

s keyderivation Z Z © 2025 Ezurio/atsec information security.

Table 13: Approved Services s Z The table above lists the approved services. The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation.
• Zeroize (Z): The module zeroizes the SSP. To interact with the FIPS provider component of the module, a calling application must use the EVP API layer provided by OpenSSL. This layer will delegate the request to the FIPS provider, which will in turn perform the requested service. The EVP_KDF_CTX_get_params() function can be used to determine whether an EVP API function is approved. After a cryptographic service was performed by the module, the API context associated with this request can contain a parameter (listed below) which represents the approved service
• _SUMMIT_FIPS_INDICATOR_APPROVED (approved services)
• _SUMMIT_FIPS_INDICATOR_NOT_APPROVED (non-approved services) The security function implementation “FIPS provider KBKDF Key Derivation” listed for the “FIPS provider Key Derivation” approved service in the table above is intended to derive keys for use of 802.11 protocols. The Kernel does not provide any non-approved services. The API for the Kernel services listed in the Indicator column, return the specified values that indicate that the services are approved. © 2025 Ezurio/atsec information security.

Table 14: Non-Approved Services

The module does not load external software or firmware. © 2025 Ezurio/atsec information security.

The integrity of the module’s firmware components (the kernel, the FIPS Provider components and fipscheck application and library) is individually verified by the fipscheck integrity test tool using HMAC-SHA2-256 implemented in the FIPS Provider. The FIPS Provider component executes its CASTs (which include the KAT for the integrity technique using HMAC-SHA2-256) before the fipscheck integrity test tool executes to verify the integrity of the module. The HMAC value of each firmware component is computed at build time and stored in the .hmac file for each component. The value is recalculated at runtime for the image of the kernel, FIPS Provider binary and fipscheck application and library, and then compared against the stored value in the file. If the comparison succeeds, then the remaining CASTs (consisting of the Known Answer Tests) for the kernel are performed.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity tests can be invoked on demand by unloading and subsequently re-initializing the module, which will perform (among others) the firmware integrity tests. © 2025 Ezurio/atsec information security.

Type of Operational Environment: Limited How Requirements are Satisfied: The operating system provides process isolation and memory protection mechanisms that ensure appropriate separation for memory access among the processes on the system. Each process has control over its own data and uncontrolled access to the data of other processes is prevented.

The module shall be installed as stated in Section 11.1. Instrumentation tools like the ptrace system call, gdb and strace, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environments. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment. © 2025 Ezurio/atsec information security.

N/A for this module. The module is enclosed within a production-grade enclosure with components that include standard passivation techniques (e.g., a conformal coating applied over the module's circuitry to protect against environmental or other physical damage) conformant to the Level 1 requirements for physical security. © 2025 Ezurio/atsec information security.

This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2025 Ezurio/atsec information security.

Table 15: Storage Areas the RAM in plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls. t c t c t c t c Table 16: SSP Input-Output Methods m © 2025 Ezurio/atsec information security.

Table 17: SSP Zeroization Methods h (KTSWrap) © 2025 Ezurio/atsec information security.

h AESGCM (KTSWrap) AESCBC-CS3 (BCAuth) AESGCM (BCAuth) AESCMAC AESGMAC © 2025 Ezurio/atsec information security.

h KAS-ECCSSC KASECC-SSC KASECC-SSC © 2025 Ezurio/atsec information security.

C) h (KTSWrap) AESGCM (KTSWrap) AESCBC-CS1 AESCBC-CS2 AESCBC-CS3 AESCFB1 AESCFB8 © 2025 Ezurio/atsec information security.

h 2248192 (BCAuth) AESGCM (BCAuth) AESCMAC AESGMAC n KAS-FFCSSC KAS-ECCSSC © 2025 Ezurio/atsec information security.

h n n n n © 2025 Ezurio/atsec information security.

h 9, 9, KAS-FFCSSC KAS-FFCSSC KASECC-SSC e e KASECC-SSC e © 2025 Ezurio/atsec information security.

h 9, 9, e KAS-IFCSSC © 2025 Ezurio/atsec information security.

h 2244096 e KAS-IFCSSC e © 2025 Ezurio/atsec information security.

h 1124096 n n © 2025 Ezurio/atsec information security.

h keyderivation 1124096 n n n n n n n n © 2025 Ezurio/atsec information security.

h Preshared n n n © 2025 Ezurio/atsec information security.

h N/A N/A n n n n (BCAuth) AESGCM (BCAuth) n (BCAuth) AESGCM (BCAuth) (BCAuth) AESGCM (BCAuth) © 2025 Ezurio/atsec information security.

Table 18: SSP Table 1 h t t t t t t n © 2025 Ezurio/atsec information security.

n t t t t t © 2025 Ezurio/atsec information security.

t t t t n © 2025 Ezurio/atsec information security.

n t t t t t t © 2025 Ezurio/atsec information security.

n t t t t t s s © 2025 Ezurio/atsec information security.

t n © 2025 Ezurio/atsec information security.

n keyderivation t t t t t t © 2025 Ezurio/atsec information security.

t t t t t t n © 2025 Ezurio/atsec information security.

The SHA-1 algorithm as implemented by the module will be non-approved for all purposes, starting January 1, 2030. © 2025 Ezurio/atsec information security.

HMACSHA2-256 Table 20: Pre-Operational Self-Tests The pre-operational firmware integrity tests are performed automatically when the module is powered on, before the module transitions into the operational state. The algorithm used for the integrity test (i.e., HMAC-SHA2-256) is self-tested before the firmware integrity test is performed. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module transitions to the operational state only after the pre-operational self-tests are passed successfully.

(FIPS1865) s N/A d e s SP 80056Ar3 5.6.2.1.4 T T T T T T n n n n n n © 2025 Ezurio/atsec information security.

s d e T s T P-256, P384 T T T T T T T n n n n n n n n n n n T n N/A AESCMAC KAS-ECCSSC Sp80056Ar3 (FIPS1865) (FIPS1865) © 2025 Ezurio/atsec information security.

s d e T SP800108 SP80056Cr2 Sp80056Cr1 s 5.6.2.1.4) T T keys, 128bit HMACSHA2-256, T T n T n T n T n T n n n n n © 2025 Ezurio/atsec information security.

s 24character d e s T n T n T n T n T n T n T T n n © 2025 Ezurio/atsec information security.

KAS-FFCSSC Sp80056Ar3 KAS-ECCSSC Sp80056Ar3 (FIPS1865) (FIPS1865) (FIPS1865) (FIPS1865) s d e T s n T n P-256, P384, and P521 P-256, P384, and P521 T n T n T n T n T T T n n n Table 21: Conditional Self-Tests The module performs self-tests on all approved cryptographic algorithms as part of the approved services supported in the approved mode of operation, using the tests shown in in the table above. Services are not available, and data output (via the data output interface) is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state.

© 2025 Ezurio/atsec information security.

HMAC-SHA2Message Table 22: Pre-Operational Periodic Information © 2025 Ezurio/atsec information security.

© 2025 Ezurio/atsec information security.

Table 23: Conditional Periodic Information

Table 24: Error States In the error state, the output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running).

All self-tests, with the exception of the continuous health tests, can be invoked on demand by unloading and subsequently re-initializing the module. © 2025 Ezurio/atsec information security.

Before deploying the module for usage, the Crypto Officer shall employ the following steps:

1. Verify the HMAC values of each component of the module as listed in section 2.2.
2. Verify that the kernel component command line is configured to run fipsInit.sh before any user mode application or init system.
3. Verify that ‘fips=1’ parameter is present on the kernel command line for approved mode operation.

The Crypto Officer must execute the “cat /proc/sys/crypto/fips_name” command. The Crypto Officer must ensure that the proper name is listed in the output as follows: Summit Linux This output maps to the module name “Summit Linux FIPS Core Crypto Module”. Next the Crypto Officer must execute “cat /proc/sys/crypto/fips_version”. This command must output the following: 11.0 The following are the HMAC values for each of the module components:

• wb45n/Image.lzma.hmac:3df472065e70a8c176c976c0588170e89b816d3ca1caee5f7 34ea0b187696e13 wb45n/libfipscheck.so.1.hmac:d193a7627cb9f9b7bae33a1bba2c57fdb52a42710a914 ec57122590a5e63a65c wb45n/fipscheck.hmac:1e5bfd65b7a5d351e6cd1445df5cff7dddd62e8d9097ec065bc b877188a5271f wb45n/fips.so.hmac:f2eae64d2d5ae6b84995e671d25aba0672408f7b1b247c45a89cb 817276c30f9

There is no non-administrator guidance.

As the module does not persistently store SSPs, secure sanitization of the module consists of unloading the module. This will zeroize all SSPs in volatile memory. © 2025 Ezurio/atsec information security.

For the FIPS Provider component, certain cryptographic subroutines and algorithms are vulnerable to timing analysis. The FIPS Provider component mitigates this vulnerability by using constant-time implementations. This includes, but is not limited to:

• Big number operations: computing GCDs, modular inversion, multiplication, division, and modular exponentiation (using Montgomery multiplication). Elliptic curve point arithmetic: addition and multiplication (using the Montgomery ladder). Vector-based AES implementations. In addition, RSA, ECDSA, ECDH, and DH employ blinding techniques to further impede timing and power analysis. No configuration is needed to enable the aforementioned countermeasures. © 2025 Ezurio/atsec information security.

Appendix A. Glossary and Abbreviations AES API CAST CAVP CBC CCM CFB CMAC CMVP CSP CTR CTS DH DRBG ECB ECC ECDH ECDSA EMS ENT (NP) FFC FIPS GCM GMAC HKDF HMAC IPsec KAT KBKDF MAC NIST PAA PBKDF2 PKCS RSA SFI SHA SSC SSP TOEPP XTS Advanced Encryption Standard Application Programming Interface Cryptographic Algorithm Self-Test Cryptographic Algorithm Validation Program Cipher Block Chaining Counter with Cipher Block Chaining-Message Authentication Code Cipher Feedback Cipher-based Message Authentication Code Cryptographic Module Validation Program Critical Security Parameter Counter Ciphertext Stealing Diffie-Hellman Deterministic Random Bit Generator Electronic Code Book Elliptic Curve Cryptography Elliptic Curve Diffie-Hellman Elliptic Curve Digital Signature Algorithm Extended Master Secret Non-physical Entropy Source Finite Field Cryptography Federal Information Processing Standards Galois Counter Mode Galois Counter Mode Message Authentication Code HMAC-based Key Derivation Function Keyed-Hash Message Authentication Code Internet Protocol Security Known Answer Test Key-based Key Derivation Function Message Authentication Code National Institute of Science and Technology Processor Algorithm Acceleration Password-based Key Derivation Function v2 Public-Key Cryptography Standards Rivest, Shamir, Addleman Security Function Implementation Secure Hash Algorithm Shared Secret Computation Sensitive Security Parameter Test Operational Environment’s Physical Perimeter XEX-based Tweaked-codebook mode with cipher text Stealing © 2025 Ezurio/atsec information security.

Appendix B. References ANS X9.422001 Public Key Cryptography for the Financial Services Industry: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography 2001 https://webstore.ansi.org/standards/ascx9/ansix9422001 ANS X9.632001 Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography 2001 https://webstore.ansi.org/standards/ascx9/ansix9632001 FIPS 140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf FIPS 140-3 IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips140-3-ig-announcements FIPS 180-4 Secure Hash Standard (SHS) March 2012 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS 186-5 Digital Signature Standard (DSS) February 3, 2023 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf FIPS 197 Advanced Encryption Standard November 2001 https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS 198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf FIPS 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions August 2015 https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 https://www.ietf.org/rfc/rfc3447.txt RFC 3526 More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE) May 2003 https://www.ietf.org/rfc/rfc3526.txt RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://www.ietf.org/rfc/rfc5288.txt © 2025 Ezurio/atsec information security.

RFC 7919 Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport Layer Security (TLS) August 2016 https://www.ietf.org/rfc/rfc7919.txt RFC 8446 The Transport Layer Security (TLS) Protocol Version 1.3 August 2018 https://www.ietf.org/rfc/rfc8446.txt SP 800-38A Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP 800-38A Addendum Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode October 2010 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38aadd.pdf SP 800-38B Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP 800-38C Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication80038c.pdf SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf SP 800-38E Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf SP 800-38F Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP 800-52r2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf SP 800-56Ar3 Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf SP 800-56Cr2 Recommendation for Key-Derivation Methods in Key-Establishment Schemes August 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf © 2025 Ezurio/atsec information security.

SP 800-90Ar1 Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP 800-90B Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf SP 800-108r1 NIST Special Publication 800-108 - Recommendation for Key Derivation Using Pseudorandom Functions August 2022 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf SP 800131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800131Ar2.pdf SP 800-132 Recommendation for Password-Based Key Derivation - Part 1: Storage Applications December 2010 https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf SP 800-133r2 Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf SP 800-135r1 Recommendation for Existing Application-Specific Key Derivation Functions December 2011 https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800135r1.pdf SP 800-140B CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2025 Ezurio/atsec information security.

Referenced URLs

• www.atsec.com
• https://webstore.ansi.org/standards/ascx9/ansix9422001
• https://webstore.ansi.org/standards/ascx9/ansix9632001
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf
• https://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
• https://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
• https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
• https://www.ietf.org/rfc/rfc3447.txt
• https://www.ietf.org/rfc/rfc3526.txt
• https://www.ietf.org/rfc/rfc5288.txt
• https://www.ietf.org/rfc/rfc7919.txt
• https://www.ietf.org/rfc/rfc8446.txt
• https://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a-
• https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-
• https://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
• https://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Cr2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90B.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-108r1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-
• https://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf