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["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</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["Possible only, trusted<br/>code is reachable through<br/>update and 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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    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,C5,C6 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Ezurio Summit Linux FIPS Core Crypto Module Document Version: 1.1 Last Modified: 08/19/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.1, hardware version ATSAMA5D31, ATSAMA5D36. 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 Security Level 1 module. 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.

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-Hybrid module supporting FIPS 140-3 Approved cryptographic algorithms. The module is composed by a hardware component, the ARM-based Microchip/Atmel microprocessor, and firmware components comprised of a kernel and OpenSSL library, and fipscheck binary. The 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-hybrid Module Embodiment: MultiChipStand Cryptographic Boundary: The Summit Linux FIPS Core Crypto Module is defined as a Firmware-Hybrid, Multi-chip Standalone module per the requirements within FIPS 140-3. The cryptographic boundary of the module consists of the embedded hardware AES cryptographic engine within the Microchip/Atmel microprocessor, the firmware component files (Kernel, OpenSSL 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 shows the physical representations of the tested platforms as the top view of the circuit boards. The tested environments are further described in Section 6. © 2025 Ezurio / atsec information security.

(a) WB50NBT with Microchip/Atmel (b) SU60-SOMC 60 Series SOM (System on Module) ATSAMA5D31. with Microchip/Atmel ATSAMA5D36 Figure 1: Tested Operational Environment Physical Perimeter Figure 2 below shows the block diagram of the module. The cryptographic boundary is indicated with yellow blocks, distributed among hardware and 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 Module Identification
• Hybrid Disjoint Hardware: N/A N/A N/A N/A N/A N/A Table 3: Tested Module Identification
• Hybrid Disjoint Hardware © 2025 Ezurio / atsec information security.

Tested Operational Environments - Software, Firmware, Hybrid: N/A N/A Table 4: Tested Operational Environments - Software, Firmware, Hybrid

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

Modes List and Description: Nonapproved NonApproved Table 5: Modes List and Description After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes depending on the services service that was requested.

Approved Algorithms: © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

HMAC-SHA2224 HMAC-SHA2224 HMAC-SHA2224 HMAC-SHA2224 HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2256 HMAC-SHA2384 HMAC-SHA2384 HMAC-SHA2384 © 2025 Ezurio / atsec information security.

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

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

Table 6: Approved Algorithms Vendor-Affirmed Algorithms: N/A Table 7: 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: © 2025 Ezurio / atsec information security.

Table 8: Non-Approved, Not Allowed Algorithms

Kernel AESCCM (KTSWrap) Kernel AESGCM (KTSWrap) © 2025 Ezurio / atsec information security.

Kernel AESCFB8 Kernel AESCFB128 Kernel AESCMAC © 2025 Ezurio / atsec information security.

Kernel AESGMAC © 2025 Ezurio / atsec information security.

AsymKeyPairKeyVer © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

AsymKeyPairKeyVer © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

Table 9: Security Function Implementations

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 80052rev2 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. 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 © 2025 Ezurio / atsec information security.

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 AESGCM) or terminate the connection. The module implements, within its boundary, an IV generation unit for TLS 1.3 that keeps control of the 64-bit counter value within the AES-GCM IV. The module explicitly ensures that the 64-bit counter is monotonically increasing at each invocation of the AES-GCM for the same encryption key, and that this counter does not exhaust all its possible values. If this exhaustion condition is observed, the module will return an error indication to the calling application who will then need to either trigger a re-key of the session (i.e., a new key for AES-GCM) or terminate the connection. The module will refuse a new AES-GCM encryption for the same key and IV under this scenario. 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. 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 2 20 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: © 2025 Ezurio / atsec information security.

• 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. 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 80090Ar1 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 80056ARev3. 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. 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. 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. 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 © 2025 Ezurio / atsec information security.

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: 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 and SHAKE hash functions compliant with IG C.C. Every implementation of each SHA-3 and SHAKE functions were tested and validated on all of the module’s operating environments. SHA-3 hash functions are also used as part of a higher-level algorithm for HMAC. SHAKE functions are only used a standalone algorithms.

© 2025 Ezurio / atsec information security.

SHA-1 from FIPS provider Message Digest service is only approved for non-digital-signature uses. SHA-1 used within Digital Signature Verification is considered Legacy (approved) per IG C.M. Algorithms designated as “Legacy” can only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M. Table 10: Entropy Certificates NonPhysical Table 11: Entropy Sources The module implements multiple DRBGs compliant with SP800-90A for random number generation and the creation of key components of asymmetric keys. The kernel component of the module implements a CTR_DRBG while the FIPS provider component of the module implements a CTR_DRBG, Hash_DRBG and HMAC_DRBG. Each of these DRBG is seeded with full entropy using an entropy source listed in the above table. For internal usage, module uses an SP800-90Ar1 CTR_DRBG with AES-256 as the default DRBG in both the Kernel and the FIPS Provider components. Note: Per FIPS 140-3 IG C.L please make sure to select the appropriate hash function when instantiating HMAC or Hash DRBG based on the minimum-security strength required for the generated random bits.

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 800133r2:

• HKDF compliant with SP 800-56Cr1: derivation of secret keys in the context of SP 800-56Ar3 and SP 800-56Br2 key agreement schemes. © 2025 Ezurio / atsec information security.

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

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 - key transport for KTS-IFC and KTS-Wrap

Only the Key Derivation Functions have been validated by the CAVP No other part of the SSH, IKE or TLS protocols are implemented or have been tested by the CAVP and CMVP. 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. 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 12: 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 13: 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.

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

n n t n n t n n t AESECB AESCTR AESCBC AESCBCCS3 AESCFB8 AESCFB128 AESXTS AESOFB AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (BCAuth) AESGCM W,E W,E W,E © 2025 Ezurio / atsec information security.

g (BCAuth) AESCCM (KTSWrap) AESGCM (KTSWrap) AESCCM (KTSWrap) AESGCM (KTSWrap) W,E W,E © 2025 Ezurio / atsec information security.

AESCMAC AESGMAC KASECCSSC n W,E W,E W,E W,E G,W,E G,R G,R © 2025 Ezurio / atsec information security.

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

n t t AESCFB128 AESXTS AESOFB AESCTR AESCBC AESECB AESCBCCS1 AESCBCCS2 AESCBCCS3 W,E © 2025 Ezurio / atsec information security.

n t n t t AESCFB8 AESCFB128 AESXTS AESOFB AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (BCAuth) AESGCM (BCAuth) W,E W,E © 2025 Ezurio / atsec information security.

AESCMAC AESGMAC KASFFCSSC KASECCSSC KASIFC-SSC W,E W,E W,E W,E © 2025 Ezurio / atsec information security.

keyderivation © 2025 Ezurio / atsec information security.

TLS premaster W,E W,E W,E W,E TLS premaster © 2025 Ezurio / atsec information security.

Passwordbased key a W,E © 2025 Ezurio / atsec information security.

DHGroup © 2025 Ezurio / atsec information security.

n n AESCCM (KTSWrap) W W W,E © 2025 Ezurio / atsec information security.

g n m AESGCM (KTSWrap) AESCCM (KTSWrap) AESGCM (KTSWrap) e W,E © 2025 Ezurio / atsec information security.

n m n m n m e e e e e e W,E W,E © 2025 Ezurio / atsec information security.

m n KTSIFC KTSIFC N/A N/A G,W,E G,W,E © 2025 Ezurio / atsec information security.

N/A N/A n Z Z Z © 2025 Ezurio / atsec information security.

Z Z Z © 2025 Ezurio / atsec information security.

keyderivation Table 14: Approved Services 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 © 2025 Ezurio / atsec information security.

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 indicator.

• _SUMMIT_FIPS_INDICATOR_APPROVED
• _SUMMIT_FIPS_INDICATOR_NOT_APPROVED 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.

Table 15: Non-Approved Services © 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 an HMAC-SHA2-256 implemented by the FIPS provider. 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, for the FIPS provider binary and the fipscheck application and library, and then compared against the stored value in the file. If the comparison succeeds, then the remaining Known Answer Tests (KATs) for FIPS provider are performed. Then the kernel component executes its algorithm-specific Known Answer Tests. If the integrity test fails the module will enter the error state. Please see section 10.4 for details

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. The Self-Tests service can also be used to invoke the integrity test on-demand. © 2025 Ezurio / atsec information security.

Type of Operational Environment: Limited How Requirements are Satisfied: The firmware components of this module are executed in the Microchip/Atmel ATSAMA5D31 (Microprocessor Unit) and Microchip/Atmel ATSAMA5D36 (Microprocessor Unit), ARM Cortex A5-based (ARMv7) operational environments.

The module shall be installed as stated in Section 11.1. There are no security rules, settings or restrictions to the configuration of the operational environment. © 2025 Ezurio / atsec information security.

N/A for this module. The module is a firmware-hardware hybrid module. The module contains standard integrated circuits with a uniform exterior material and standard connectors. 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. The physical security requirements do not apply to the firmware components of the module. © 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 16: Storage Areas plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls.

Table 17: SSP Input-Output Methods

© 2025 Ezurio / atsec information security.

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

AESGCM (KTSWrap) AESCBC-CS3 AESCFB8 AESCFB128 AESCCM (BCAuth) AESGCM (BCAuth) © 2025 Ezurio / atsec information security.

KASECC-SSC AESGMAC n KASECC-SSC KASECC-SSC KASECC-SSC © 2025 Ezurio / atsec information security.

C) AESCCM (KTSWrap) AESGCM (KTSWrap) © 2025 Ezurio / atsec information security.

AESCBC-CS1 AESCBC-CS2 AESCBC-CS3 AESCFB1 AESCFB8 AESCCM (BCAuth) AESGCM (BCAuth) © 2025 Ezurio / atsec information security.

AESCMAC AESGMAC n KASFFC-SSC KASECC-SSC © 2025 Ezurio / atsec information security.

TLS premaster KASFFC-SSC KASECC-SSC n n n n © 2025 Ezurio / atsec information security.

KASFFC-SSC KASFFC-SSC KASECC-SSC © 2025 Ezurio / atsec information security.

KASECC-SSC n n KASFFC-SSC KASFFC-SSC © 2025 Ezurio / atsec information security.

KASECC-SSC KASECC-SSC n n © 2025 Ezurio / atsec information security.

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

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

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

n n © 2025 Ezurio / atsec information security.

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

AESCBC AESCCM (BCAuth) AESGCM (BCAuth) AESCBC AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (BCAuth) AESGCM (BCAuth) AESCCM (BCAuth) AESGCM (BCAuth) Table 19: SSP Table 1 © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

(V, C) © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

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

HMACSHA2-256 Table 21: 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., HMACSHA2-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.

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

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

AESCFB128 © 2025 Ezurio / atsec information security.

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

SP80056Cr2 Sp80056Cr1 N/A © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

KAS-FFCSSC Sp80056Ar3 KAS-ECCSSC Sp80056Ar3 HMACSHA2-224 © 2025 Ezurio / atsec information security.

HMACSHA2-224 HMACSHA2-224 HMACSHA2-224 HMACSHA2-256 HMACSHA2-384 HMACSHA3-224 HMACSHA3-384 HMACSHA3-512 HMACSHA3-256 AES-CBCCS3 AES-CBCCS3 AES-CBCCS3 AES-CBCCS3 SHAKE128 © 2025 Ezurio / atsec information security.

SHAKE256 Sp800108r1 SP80056Cr2 KAS-IFCSSC Table 22: 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 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.

Table 23: Pre-Operational Periodic Information © 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

© 2025 Ezurio / atsec information security.

Table 24: Conditional Periodic Information © 2025 Ezurio / atsec information security.

Table 25: 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 health tests, can be invoked on demand by unloading and subsequently re-initializing the module. The entropy health tests are run during DRBG seeding and reseeding. Similarly, a Pair-wise Consistency Test (PCT) it is run for keygen operations. © 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.1 The hardware component of the module for both OE’s can be identified by executing the “cat /proc/cpuinfo” command which outputs: processor : 0 model name : ARMv7 Processor rev 1 (v7l) BogoMIPS : 33.00 Features : half thumb fastmult vfp edsp thumbee vfpv3 vfpv3d16 tls vfpv4 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xc05 CPU revision : 1 Hardware Revision Serial : Atmel SAMA5 : 0000 : 0000000000000000 The following are the HMAC values for each of the components for each platform:

• WB50NBT MPU /usr/lib/fipscheck/Image.gz.hmac: a1eb02e51646193b56a0391677293df724cf5a75a424812a1872842049b830fa © 2025 Ezurio / atsec information security.

• WB50NBT MPU /usr/lib/fipscheck/fips.so.hmac: c246bfcce5880bebd46dae090270fff4f06d3ba3482e5b1ac4c7000d73b2372d WB50NBT MPU /usr/lib/fipscheck/fipscheck.hmac: 5c986e37c11276eb300df8ee113f28b3129276f90b2b8099aa08c2c74fc89616 WB50NBT MPU /usr/lib/fipscheck/libfipscheck.so.1.hmac: baae25b3d5faaedf74376e8e4ce729ec7009f1038d4f8851bcf3095491dded00 SU60-SOMC 60 Series SOM /usr/lib/fipscheck/Image.gz.hmac: 013763a8e1ddd8395cf3e1f8d5d6e171a1486a350c66124fea88aaaf8f105c5d SU60-SOMC 60 Series SOM /usr/lib/fipscheck/fips.so.hmac: c246bfcce5880bebd46dae090270fff4f06d3ba3482e5b1ac4c7000d73b2372d SU60-SOMC 60 Series SOM /usr/lib/fipscheck/fipscheck.hmac: 5c986e37c11276eb300df8ee113f28b3129276f90b2b8099aa08c2c74fc89616 SU60-SOMC 60 Series SOM /usr/lib/fipscheck/libfipscheck.so.1.hmac: baae25b3d5faaedf74376e8e4ce729ec7009f1038d4f8851bcf3095491dded00

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 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.42-2001 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.63-2001 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/fips-140-3-igannouncements 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 © 2025 Ezurio / atsec information security.

RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://www.ietf.org/rfc/rfc5288.txt 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-38a-add.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/nistspecialpublication800-38c.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 © 2025 Ezurio / atsec information security.

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 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 800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.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/nistspecialpublication800-135r1.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-140-3-ig-
• 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-add.pdf
• https://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
• https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
• 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-131Ar2.pdf
• 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/Legacy/SP/nistspecialpublication800-135r1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf