Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic Module

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic 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<br/>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</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["Possible only, some<br/>services may process input<br/>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["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>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 Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic 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<br/>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>Status Output</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</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,C5,C6 clueLow;

Security Policy, page by page

Canonical Ltd. Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic Module Version 3.0.13-0ubuntu3+Fips1 Document Version: 1.2 Last Updated: 2025-12-16 Prepared by: Prepared for: atsec information security corporation Canonical Ltd.

4516 Seton Center Parkway, Suite 250 110 Southwark Street, Blue Fin Building, 5th Floor

Austin, TX 78759 London, SE1 0SU www.atsec.com www.canonical.com

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.0.130ubuntu3+Fips1 of the Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic Module. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 1 whole and intact and including this notice. Other documentation is proprietary to their authors.

In preparing the Security Policy document, the laboratory formatted the vendorsupplied 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. © 2025 Canonical Ltd. / atsec information security.

Purpose and Use: The Canonical Ltd. Ubuntu 24.04 OpenSSL Cryptographic Module (hereafter referred to as “the module”) is defined as a software module in a multi-chip standalone embodiment. It provides a C language application program interface (API) for use by other applications that require cryptographic functionality. The module consists of one software component, the “FIPS provider” i.e., fips.so, which implements the FIPS requirements, and the cryptographic functionality provided to the operator. Module Type: Software Module Embodiment: MultiChipStand Module Characteristics Cryptographic Boundary: Components in white are only included in the diagram for informational purposes. They are not included in the cryptographic boundary (and therefore not part of the module’s validation). For example, the kernel is responsible for managing system calls issued by the module itself, as well as other applications using the module for cryptographic services. Tested Operational Environment’s Physical Perimeter (TOEPP): Figure 1 shows a block diagram that represents the design of the module when the module is operational and providing services to other user space applications. In this diagram, the physical perimeter of the operational environment (a general-purpose computer on which the module is installed) is indicated by a purple dashed line. The cryptographic boundary is represented by the component in the orange block, that is, the shared library implementing the FIPS provider (fips.so). The connecting lines indicate the flow of data between the cryptographic module and its operator application, through the logical interfaces defined in Section 3. © 2025 Canonical Ltd. / atsec information security.

Identification Tested Module Identification

• Hardware: N/A for this module. Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): Table 2: Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. © 2025 Canonical Ltd. / atsec information security.

Tested Operational Environments - Software, Firmware, Hybrid: Table 3: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module.

There are no components excluded from the module.

Modes List and Description: 4.3 4.4 Table 4: Modes List and Description The module supports two modes of operation: (1) the approved mode of operation, in which the approved or vendor affirmed services are available as specified in the non-approved services are available as specified in the Non-Approved Services table. Mode Change Instructions and Status: The module automatically switches between the approved and non-approved modes © 2025 Canonical Ltd. / atsec information security.

Degraded Mode Description: The module does not implement a degraded mode of operation.

Approved Algorithms: The table below lists all implemented modes or methods of operation for the approved cryptographic algorithms of the module that are employed for approved services (Approved Services table). © 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

Table 5: Approved Algorithms Vendor-Affirmed Algorithms: 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: © 2025 Canonical Ltd. / atsec information security.

Name Encryption with AES

Type BC-UnAuth

Description SP 800-38A and SP 800-38E. Encryption

Properties

Algorithms AES-CBC: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS1: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS2: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS3: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CFB1: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CFB128: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CFB8: (A5747,

Table 7: Non-Approved, Not Allowed Algorithms

© 2025 Canonical Ltd. / atsec information security.

Name Decryption with AES

Type BC-UnAuth

Description SP 800-38A and SP 800-38E. Decryption

Properties

Algorithms A5748, A5749, A5774, A5775, A5776, A5927) AES-CTR: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-ECB: (A5747, A5748, A5749, A5751, A5752, A5753, A5754, A5755, A5774, A5775, A5776, A5927, A5932) AES-OFB: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-XTS Testing Revision 2.0: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS1: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS2: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CBC-CS3: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CFB1: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CFB128: (A5747, A5748, A5749, A5774, A5775, A5776, A5927)

© 2025 Canonical Ltd. / atsec information security.

Name Authenticated Encryption with AES Authenticated Decryption with AES

Type BC-Auth BC-Auth

Description SP 800-38D. Authenticated encryption SP 800-38D. Authenticated decryption

Properties

Algorithms AES-CFB8: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CTR: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-ECB: (A5747, A5748, A5749, A5751, A5752, A5753, A5754, A5755, A5774, A5775, A5776, A5927, A5932) AES-OFB: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-XTS Testing Revision 2.0: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CCM: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-GCM: (A5759, A5760, A5761, A5762, A5763, A5764, A5765, A5766, A5767, A5777, A5781, A5782, A5783, A5928, A5929, A5930) AES-KW: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-KWP: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CCM: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-GCM: (A5759, A5760, A5761,

© 2025 Canonical Ltd. / atsec information security.

Name Message Authentication Generation with AES Message Authentication Generation with HMAC

Type MAC MAC

Description SP 800-38B and SP 800-38D Message authentication generation FIPS 198-1. Message authentication generation

Properties

Algorithms A5762, A5763, A5764, A5765, A5766, A5767, A5777, A5781, A5782, A5783, A5928, A5929, A5930) AES-KW: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-KWP: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-CMAC: (A5747, A5748, A5749, A5774, A5775, A5776, A5927) AES-GMAC: (A5759, A5760, A5761, A5762, A5763, A5764, A5765, A5766, A5767, A5777, A5781, A5782, A5783, A5928, A5929, A5930) HMAC-SHA-1: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) HMAC-SHA2-224: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) HMAC-SHA2-256: (A5750, A5768, A5769, A5770, A5771, A5778, A5779, A5931) HMAC-SHA2-384: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) HMAC-SHA2-512: (A5750, A5768, A5769, A5770, A5771, A5778,

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

Name Key Pair Verification with Safe Primes Key Derivation with KBKDF Key Derivation with KDA OneStep Key Derivation with KDA TwoStep Key Derivation with KDA HKDF Key Derivation with ANS X9.42 KDF Key Derivation with X9.63 KDF Key Derivation with SSH KDF Key Derivation with TLS 1.2 KDF Key Derivation with TLS 1.3 KDF Key Derivation with PBKDF2

Type AsymKeyPair- KeyVer KBKDF KAS-56CKDF KAS-56CKDF KAS-56CKDF KAS-135KDF KAS-135KDF KAS-135KDF KAS-135KDF KAS-135KDF PBKDF

Description SP 800-56Ar3. Key pair verification SP 800-108r1. Key derivation SP 800-56Cr2. Key derivation SP 800-56Cr2. Key derivation SP 800-56Cr2. Key derivation SP 800-135r1. Key derivation SP 800-135r1. Key derivation SP 800-135r1. Key derivation SP 800-135r1. Key derivation RFC 8446. Key derivation SP 800-132. Key derivation

Properties

Algorithms A5778, A5931) ECDSA KeyVer (FIPS186-5): (A5745, A5750, A5768, A5769, A5770, A5771, A5778, A5931) Safe Primes Key Verification: (A5773) KDF SP800-108: (A5772) KDA OneStep SP800-56Cr2: (A5744) KDA TwoStep SP800-56Cr2: (A5744) KDA HKDF SP800- 56Cr2: (A5758) KDF ANS 9.42: (A5750, A5756, A5768, A5769, A5770, A5771, A5778, A5780, A5931, A5933) KDF ANS 9.63: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) KDF SSH: (A5751, A5752, A5753, A5754, A5755, A5932) TLS v1.2 KDF RFC7627: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) TLS v1.3 KDF: (A5758) PBKDF: (A5750, A5756, A5768, A5769, A5770, A5771, A5778, A5780, A5931, A5933)

© 2025 Canonical Ltd. / atsec information security.

Name Shared Secret Computation Message Digest with SHA Message Digest with SHAKE

Type KAS-SSC SHA XOF

Description SP 800-56Ar3. Shared secret computation FIPS 180-4 and FIPS 202. Message digest FIPS 202. Message digest

Properties

Algorithms KAS-ECC-SSC Sp800-56Ar3: (A5750, A5768, A5770, A5771, A5778, A5931, A5769) KAS-FFC-SSC Sp800-56Ar3: (A5773) SHA-1: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) SHA2-224: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) SHA2-256: (A5750, A5768, A5769, A5770, A5771, A5778, A5779, A5931) SHA2-384: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) SHA2-512: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) SHA2-512/224: (A5750, A5768, A5769, A5770, A5771, A5778, A5931) SHA2-512/256: (A5750, A5771, A5778, A5931, A5768, A5769, A5770) SHA3-224: (A5756, A5780, A5933) SHA3-256: (A5756, A5780, A5933) SHA3-384: (A5756, A5780, A5933) SHA3-512: (A5756, A5780, A5933) SHAKE-128: (A5756, A5780, A5933) SHAKE-256: (A5756, A5780, A5933)

© 2025 Canonical Ltd. / atsec information security.

Table 8: Security Function Implementations

For TLS 1.2, the module offers the AES GCM implementation and uses the context of Scenario 1 of FIPS 140-3 IG C.H. The module is compliant with SP 800-52r2 Section

3.3.1 and the mechanism for IV generation is compliant with RFC 5288 and 8446.

The module does not implement the TLS protocol. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. 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. 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 in compliance with Scenario 2 of IG C.H. © 2025 Canonical Ltd. / atsec information security.

The module also provides a non-approved AES GCM encryption service which accepts arbitrary external IVs from the operator. The 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 as described in Section 4.3. Finally, 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. The module’s implementation of AES GCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key

In accordance to FIPS 140-3 IG C.I, the module implements a check that ensures, before performing any cryptographic operation, that the two AES keys used in AES XTS mode are not identical. As the module does not generate symmetric keys, the check is performed when keys are input the service APIs. Key_1 and Key_2 shall be generated and/or established independently according to the rules for component symmetric keys from NIST SP 800-133rev2, Sec. 6.3. In addition, Section 4 of SP 800-38E states that the length of a single data unit encrypted or decrypted with AES XTS shall not exceed 2²⁰ AES blocks, that is 16MB, of data per XTS instance. 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:

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 (this is verified by the module to determine the service is approved), 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 module enforces the iteration count to be equal to or greater than 1000.

The module offers DH and ECDH shared secret computation services compliant to the SP 800-56ARev3 and meeting IG D.F scenario 2 path (1). 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 “TLS 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 DH/ECDH ephemeral keys. This meets the assurances required by key pair owner defined in the section 5.6.2.1 of SP 800-56ARev3.
2. As part of the module's shared secret computation (SSC) 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.2 of SP 800-56ARev3.
3. The module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable.

The module does not establish SSPs using an approved key transport scheme (KTS). However, it does offer approved authenticated algorithms that can be used by an external operator/application as part of an approved KTS.

The module does not establish SSPs using an approved key agreement scheme (KAS). However, it does offer some or all of the underlying KAS cryptographic functionality to be used by an external operator/application as part of an approved KAS.

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

Table 10: Entropy Sources The module implements a primary DRBG (AES-256-CTR-DRBG (5746)) which acts as the conditioning component for the entropy source mentioned in the above table. It is only used internally by the module to seed the secondary DRBGs which can be of type (CTR, Hash, HMAC). The module complies with the Public Use Document for ESV certificate E218 by reading entropy data from the EVP_RAND_generate() function of the primary DRBG, which corresponds to the GetEntropy() conceptual interface. The operational environment on the ESV certificate is identical to the operating system described in this document. There are no maintenance requirements for the entropy source. As per the Public Use document of entropy certificate E218, the entropy source provides full entropy of 256 bits. When the module needs random data for internal purposes it uses two separate instances of AES-256 CTR_DRBG DRBG based on use case. i.e., it uses the “private DRBG” accessed via RAND_priv_bytes () for asymmetric key generation, signature generation, or other SSP use cases and it uses the “public DRBG” accessed via RAND_bytes() when it needs to generate IV or other non-SSP use cases. When an external caller needs the random data, they can access it via “Random Number Generation” service of the module and they have a choice between Hash, HMAC or CTR_DRBG listed in the Approved Algorithms table.

The module implements asymmetric key pair generation compliant with SP 800-133 Rev. 2 as listed in the Security Function Implementations table. When random values are required, they are obtained from the SP 800-90A Rev. 1 approved DRBG, compliant with Section 4 of SP 800-133 Rev. 2 (without XOR). Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service. The key derivation methods implemented by the module are specified in the Security Function Implementations table. © 2025 Canonical Ltd. / atsec information security.

Key Establishment methods are specified in the Security Function Implementations table.

The module implements the SSH KDF (CVL) for use in the SSH protocol (RFC 4253 and RFC 6668). GCM with internal IV generation in the approved mode is compliant with versions 1.2 and 1.3 of the TLS protocol (RFC 5288 and 8446) and shall only be used in conjunction with the TLS protocol. Additionally, the module implements the TLS 1.2 and TLS 1.3 key derivation functions for use in the TLS protocol. For Diffie-Hellman, the module supports the use of the safe primes defined in RFC

3526 (IKE) and RFC 7919 (TLS). 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 KDF (CVL) and

• IKE (RFC 3526): MODP-2048 (ID = 14), MODP-3072 (ID = 15), MODP-4096 (ID = 16), MODP-6144 (ID = 17), MODP-8192 (ID = 18)
• TLS (RFC 7919): ffdhe2048 (ID = 256), ffdhe3072 (ID = 257), ffdhe4096 (ID = 258), ffdhe6144 (ID = 259), ffdhe8192 (ID = 260) For Elliptic Curve Diffie-Hellman, the module supports the NIST-defined P-224, P-256, P-384, and P-521 curves. No parts of the SSH, TLS, or IKE protocols, other than those mentioned above, have been tested by the CAVP or CMVP.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Table 11: Ports and Interfaces As a software-only module, the module does not have physical ports. Physical Ports are interpreted to be the physical ports of the hardware platform on which it runs. The module does not implement a control output interface.

Not applicable. © 2025 Canonical Ltd. / 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 a maintenance role.

© 2025 Canonical Ltd. / atsec information security.

G,R G,R G,R G,R G,R G,R © 2025 Canonical Ltd. / atsec information security.

G,R G,R G,E (V, C): G,E © 2025 Canonical Ltd. / atsec information security.

G,R G,R © 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

Name

Description

Indicator

Inputs

Outputs

Security Functions

SSP Access Z - DH Private Key: Z - DH Public Key: Z - EC Private Key: Z - EC Public Key: Z - RSA Private Key: Z - RSA Public Key: Z - Module Generated DH Private Key: Z - Module Generated DH Public Key: Z - Module Generated EC Private Key: Z - Module Generated EC Public Key: - Module Generated RSA Private Key: Z - Module Generated RSA Public Key: Z

Z Table 13: Approved Services The module provides services to operators that assume the available role. All services are described in detail in the API documentation (manual pages). The Approved Services table and the Non-Approved Services table define the services that utilize approved and non-approved security functions in this module. For the respective tables, the convention below applies when specifying the access permissions (types) that the service has for each SSP.

To interact with 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 © 2025 Canonical Ltd. / atsec information security.

turn perform the requested service. Additionally, this EVP API layer can be used to retrieve the approved service indicator for the module. The cryptographic module provides an approved service indicator in the form of an OpenSSL provider gettable parameter called UBUNTU_OSSL_PROV_FIPS_PARAM_UNAPPROVED_USAGE. This parameter will be equal to 0 if the requested service is an approved security service, otherwise it will be set to 1. The operator is responsible to query the value of such gettable parameter after calling the requested service.

Table 14: Non-Approved Services In the table above, CO specifies the Crypto Officer role.

The module does not have the capability of loading software or firmware from an external source. © 2025 Canonical Ltd. / atsec information security.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

The integrity of the module is verified by comparing a HMAC-SHA2-256 value calculated at run time with the HMAC-SHA2-256 value embedded in the fips.so file that was computed at build time.

Integrity tests are performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity test may be invoked on-demand by unloading and subsequently re-initializing the module, or by calling the OSSL_PROVIDER_self_test function. This will perform (among others) the software integrity test.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module shall be installed as stated in Section 11. If properly installed, 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.

Instrumentation tools like the ptrace system call, gdb and strace, userspace live patching, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a non-validated operational environment.

There are no concurrent operators. © 2025 Canonical Ltd. / atsec information security.

The module is comprised of software only, and therefore this section is not applicable. © 2025 Canonical Ltd. / atsec information security.

This module does not implement any non-invasive security mechanism, and therefore this section is not applicable.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Name API input parameters API output parameters

From Operator calling application (TOEPP) Cryptographic module

To Cryptographic module Operator calling application (TOEPP)

Format Type Plaintext Plaintext

Distribution Type Manual Manual

Entry Type Electronic Electronic

SFI or Algorithm

Table 15: Storage Areas Table 16: SSP Input-Output Methods running on the same operational environment. This corresponds to manual distribution, electronic entry/output (“CM Software to/from App via TOEPP Path”) per FIPS 140-3 IG 9.5.A Table 1. There is no entry or output of cryptographically protected SSPs can be entered into the module via API input parameters, when required by a immediately after generation of the SSP. © 2025 Canonical Ltd. / atsec information security.

Name AES Key HMAC Key KMAC Key Key- Derivation Key

Description Used for encryption, decryption, and message authentication Used for hash- based message authentication Used for message authentication Used for key derivation

Size - Strength 128, 192, 256 bits - 128, 192, 256 bits 112-524288 bits - 112- 256 bits 128-1024 bits - 112- 256 bits 112-4096 bits - 112- 256 bits

Type - Category Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP

Generated By

Established By

Used By Encryption with AES Decryption with AES Authenticated Encryption with AES Authenticated Decryption with AES Message Authentication Generation with AES Message Authentication Generation with HMAC Message Authentication Generation with KMAC Key Derivation with KBKDF

Table 17: SSP Zeroization Methods system calls. The operator is responsible for calling the appropriate destruction functions provided in the module's API. The destruction functions, listed above, the regular memory de-allocation operating system call. All data output is inhibited during zeroization. © 2025 Canonical Ltd. / atsec information security.

Name Shared Secret Password PBKDF Derived Key KBKDF Derived Key ANS X9.42 Derived Key ANS X9.63 Derived Key HKDF Derived Key KDA OneStep Derived Key

Description Generated by shared secret computation and used for key derivation Used for password-based key derivation Generated by password-based key derivation Generated by key-based key derivation Generated by ANS X9.42 key derivation Generated by ANS X9.63 key derivation Generated by HKDF key derivation Generated by OneStep KDA key derivation

Size - Strength 224-8192 bits - 112- 256 bits At least 8 characters - N/A 112-4096 bits - 112- 256 bits 112-4096 bits - 112- 256 bits 128-4096 bits - 112- 256 bits 128-4096 bits - 112- 256 bits 224-8192 bits - 112- 256 bits 2048 bits - 112-256 bits

Type - Category Shared secret - CSP Password - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP

Generated By Key Derivation with PBKDF2 Key Derivation with KBKDF Key Derivation with ANS X9.42 KDF Key Derivation with X9.63 KDF Key Derivation with KDA HKDF Key Derivation with KDA OneStep

Established By Shared Secret Computation

Used By Key Derivation with KDA OneStep Key Derivation with KDA TwoStep Key Derivation with KDA HKDF Key Derivation with ANS X9.42 KDF Key Derivation with X9.63 KDF Key Derivation with SSH KDF Key Derivation with TLS 1.2 KDF Key Derivation with TLS 1.3 KDF Key Derivation with PBKDF2

© 2025 Canonical Ltd. / atsec information security.

Name KDA TwoStep Derived Key TLS Derived Key SSH KDF Derived Key Entropy Input DRBG Internal State (V, Key) DRBG Internal State (V, C) DRBG Seed DH Private Key

Description Generated by TwoStep KDA key derivation Generated by TLS KDF key derivation Generated by SSH KDF key derivation Used for random number generation and seeding a DRBG (compliant with IG D.L) Used for random number generation (compliant with IG D.L) Used for random number generation (compliant with IG D.L) Used for random number generation (compliant with IG D.L) Used for shared secret computation and key pair verification

Size - Strength 2048 bits - 112-256 bits 112-1024 bits - 112- 256 bits 112-256 bits - 112-256 bits 128-384 bits - 128-256 bits Counter DRBG: 256, 320, 348 bits; HMAC DRBG: 320, 512, 1024 bits - Counter DRBG: 128, 192, 256 bits; HMAC DRBG: 128, 256 bits 880, 1776 bits - 128, 256 bits 128-256 bits - 128-256 bits 2048-8192 bits - 112- 200 bits

Type - Category Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Entropy input - CSP Internal state - CSP Internal state - CSP Seed - CSP Private key - CSP

Generated By Key Derivation with KDA TwoStep Key Derivation with TLS 1.2 KDF Key Derivation with TLS 1.3 KDF Key Derivation with SSH KDF Random Number Generation with DRBG Random Number Generation with DRBG Random Number Generation with DRBG

Established By

Used By Random Number Generation with DRBG Random Number Generation with DRBG Random Number Generation with DRBG Random Number Generation with DRBG Key Pair Verification with Safe Primes Shared Secret Computation

© 2025 Canonical Ltd. / atsec information security.

Name DH Public Key EC Private Key EC Public Key RSA Private Key RSA Public Key Module Generated DH Private Key Module Generated DH Public Key Module Generated EC Private Key Module Generated EC Public Key

Description Used for shared secret computation and key pair verification Used for shared secret computation, digital signature generation, and key pair verification Used for shared secret computation, signature verification, and key pair verification Used for signature generation Used for signature verification DH private key generated by the module DH public key generated by the module EC private key generated by the module EC public key generated by the module

Size - Strength 2048-8192 bits - 112- 200 bits P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B-233, B-283, B-409, B-571 bits - 112- 256 bits P-192, P-224, P-256, P-384, P-521, K-163, K-233, K-283, K-409, K-571, B-163, B-233, B-283, B-409, B-571 bits - 80-256 bits 2048-16384 bits - 112- 256 bits 1024-16384 bits - 80-256 bits 2048-8192 bits - 112- 200 bits 2048-8192 bits - 112- 200 bits P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B-233, B-283, B-409, B-571 bits - 112- 256 bits P-224, P-256, P-384, P-521, K-163, K-233, K-283, K-409,

Type - Category Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP

Generated By Key Pair Generation with Safe Primes Key Pair Generation with Safe Primes Key Pair Generation with ECDSA Key Pair Generation with ECDSA

Established By

Used By Key Pair Verification with Safe Primes Shared Secret Computation Signature Generation with ECDSA Key Pair Verification with ECDSA Shared Secret Computation Signature Verification with ECDSA Key Pair Verification with ECDSA Shared Secret Computation Signature Generation with RSA Signature Verification with RSA

© 2025 Canonical Ltd. / atsec information security.

Name Module Generated RSA Private Key Module Generated RSA Public Key Intermediate Key Generation Value

Description RSA private key generated by the module RSA public key generated by the module Used for key pair generation

Size - Strength K-571, B-163, B-233, B-283, B-409, B-571 bits - 112- 256 bits 2048-16384 bits - 112- 256 bits 2048-16384 bits - 112- 256 bits 224-16384 bits - 112- 256 bits

Type - Category Private key - CSP Public key - PSP Intermediate value - CSP

Generated By Key Pair Generation with RSA Key Pair Generation with RSA Key Pair Generation with ECDSA Key Pair Generation with RSA Key Pair Generation with Safe Primes

Established By

Used By Key Pair Generation with ECDSA Key Pair Generation with RSA Key Pair Generation with Safe Primes

Table 18: SSP Table 1 © 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

Table 19: SSP Table 2 The tables above summarize the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module in the approved services (Approved Services table). SSPs, including CSPs, are directly imported as input parameters and exported as output parameters from the module. Because these SSPs are only transiently used for a specific service, they are, by definition, exclusive between approved and nonapproved services. © 2025 Canonical Ltd. / atsec information security.

The SHA-1 algorithm, as implemented by the module, will be non-approved for all purposes starting January 1, 2031.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Table 20: Pre-Operational Self-Tests The module performs pre-operational tests automatically when the module is powered on. The pre-operational self-tests ensure that the module is not corrupted. The module transitions to the operational state only after the pre-operational selftests are passed successfully. The integrity of the shared library component of the module is verified by comparing an HMAC-SHA2-256 value calculated at run time with the corresponding HMAC value embedded in the fips.so file that was computed at build time. If the software integrity test fails, the module transitions to the error state (Section 10.3). The HMAC and SHA2-256 algorithms go through their respective CASTs before the software integrity test is performed. © 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

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 the table above. The CASTs can be performed on demand by unloading and re-initializing the module. Data output through the data output interface is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state. © 2025 Canonical Ltd. / atsec information security.

Table 22: Pre-Operational Periodic Information © 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

© 2025 Canonical Ltd. / atsec information security.

Table 23: Conditional Periodic Information The module does not implement periodic self-tests.

Table 24: Error States If the module fails any of the self-tests, the module enters the error state. In the error state, the module immediately stops functioning and ends the application process. Consequently, the data output interface is inhibited, and the module accepts no more inputs or requests (as the module is no longer running). © 2025 Canonical Ltd. / atsec information security.

Regarding the PCT failure, an OSSL_PROV_PARAM_STATUS parameter can be queried from the FIPS provider to check the status of the cryptographic module. The table above lists the error states and the status indicator values that explain the error that has occurred.

The software integrity tests and cryptographic algorithm self-tests can be invoked on demand by resetting the module or by invoking the OSSL_PROVIDER_self_test method. The pair-wise consistency tests can be invoked on demand by requesting the key pair generation service.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

The binaries of the FIPS validated module are contained in the following Ubuntu packages for delivery:

Once the operating environment is configured following the instructions provided, the Crypto Officer can install the Ubuntu packages containing the module listed below - Ubuntu packages using the Advanced Package Tool (APT) with the following command: $ sudo apt-get install openssl-fips-module-3 All the Ubuntu packages are associated with hashes for integrity check. The integrity of the Ubuntu package is automatically verified by the packing tool during the installation of the module. The Crypto Officer shall not install the package if the integrity fails. After the openssl-fips-module-3 package is installed, the Crypto Officer must execute the openssl list -providers command. The Crypto Officer must ensure that the FIPS provider is listed in the output as follows: fips name: Ubuntu 24.04 OpenSSL Cryptographic Module version: 3.0.13-0ubuntu3+Fips1 status: active The cryptographic boundary consists only of the FIPS provider as listed. If any other OpenSSL or third-party provider is invoked, the user is not interacting with the module specified in this Security Policy. After, the module needs to be set to run in the FIPS validated configuration. This can be enabled automatically via the Ubuntu Advantage tool after attaching your subscription. (1) To install the tool type the following commands: $ sudo apt update $ sudo apt install ubuntu-advantage-tools (2) To activate the Ubuntu Pro subscription run: $ sudo pro attach <your_pro_token> (3) To enable Approved mode run: © 2025 Canonical Ltd. / atsec information security.

$ sudo pro enable fips (4) To verify that Approved mode is enabled run: $ sudo pro status The pro client will install the necessary packages for the Approved mode, including the kernel and the bootloader. After this step you MUST reboot to put the system into Approved mode. The reboot will boot into FIPS supported kernel and create the /proc/sys/crypto/fips_enabled entry which tells the FIPS certified modules to run in Approved mode. If you do not reboot after installing and configuring the bootloader, Approved mode is not yet enabled. To verify that FIPS is enabled after the reboot check the /proc/sys/crypto/fips_enabled file and ensure it is set to 1. If it is set to 0, the FIPS modules will not run in Approved mode. If the file is missing, the FIPS kernel is not installed, you can verify that FIPS has been properly enabled with the pro status command.

The Approved and non-Approved modes of operation are specified in section 2.4. The administrative functions are specified in the Approved Services table. All the logical interfaces are specified in section 3.1. The requirements and restrictions that shall be considered when operating the module in approved mode are specified in section 2.7 and section 6. The installation, initialization, and startup procedures specified in section 11.1 shall be followed.

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. Then, if desired, the Ubuntu packages can be uninstalled from the Ubuntu 24.04 system. © 2025 Canonical Ltd. / atsec information security.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Certain cryptographic subroutines and algorithms are vulnerable to timing analysis. The module mitigates this vulnerability by using constant-time implementations. This includes, but is not limited to:

RSA, ECDSA, ECDH, and DH employ blinding techniques to further impede timing and power analysis.

No configuration is needed to enable the aforementioned countermeasures.

Not applicable. © 2025 Canonical Ltd. / atsec information security.

Appendix A. Glossary and Abbreviations