Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module

Certificate

Approved Algorithms (518)

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

flowchart LR
  %% Deterministic review-risk graph for Canonical Ltd. Ubuntu 22.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</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 22.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</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 22.04 OpenSSL Cryptographic Module Document Version: 1.1 Last Updated: 2024-08-28 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

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for version 3.0.50ubuntu0.1+Fips2.1 of the Canonical Ltd. Ubuntu 22.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 module. whole and intact and including this notice. Other documentation is proprietary to their authors.

1 1

2 1

3 1

4 1

5 1

6 1

7 N/A

8 N/A

9 1

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

Purpose and Use: The Canonical Ltd. Ubuntu 22.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 components painted in orange blocks, which consists only of the shared library implementing the FIPS provider (fips.so). Green lines indicate the flow of data between the cryptographic module and its operator application, through the logical interfaces defined in Section 3. © 2024 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. Tested Operational Environments - Software, Firmware, Hybrid: © 2024 Canonical Ltd. / atsec information security.

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

There are no components excluded from the module.

Modes List and Description: 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 Approved Services table and (2) the non-approved mode of operation, in which 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 © 2024 Canonical Ltd. / atsec information security.

The module does not implement a degraded mode of operation.

Approved Algorithms: © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Table 5: Approved Algorithms The table above 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). 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: © 2024 Canonical Ltd. / atsec information security.

Table 7: Non-Approved, Not Allowed Algorithms The table above lists all the non-approved cryptographic algorithms of the module employed by the non-approved services in the Non-Approved Services table.

© 2024 Canonical Ltd. / atsec information security.

Name

Type

Description

Properties

Algorithms AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Name

Type

Description

Properties

Algorithms AES-CFB1 AES-CFB1 AES-CFB1 AES-CFB1 AES-CFB1 AES-CFB1 AES-CFB1 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB128 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CFB8 AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-CTR AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-ECB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-OFB AES-XTS Testing Revision 2.0 AES-XTS Testing Revision 2.0 AES-XTS Testing

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Name

Type

Description

Properties 256 bits) HMAC-SHA3- 224:112-524288 bits (112-256 bits) HMAC-SHA3- 256:112-524288 bits (112-256 bits) HMAC-SHA3- 384:112-524288 bits (112-256 bits) HMAC-SHA3- 512:112-524288 bits (112-256 bits) KMAC-128:128- 1024 bits (128-256 bits) KMAC-256:128- 1024 bits (128-256 bits)

Algorithms HMAC-SHA-1 HMAC-SHA-1 HMAC-SHA-1 HMAC-SHA-1 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-224 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-256 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-384 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2-512 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/224 HMAC-SHA2- 512/256 HMAC-SHA2- 512/256 HMAC-SHA2- 512/256

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Name

Type

Description

Properties

Algorithms SHA2-256 SHA2-256 SHA2-256 SHA2-256 SHA2-256 SHA2-256 SHA2-256 SHA2-256 SHA2-384 SHA2-384 SHA2-384 SHA2-384 SHA2-384 SHA2-384 SHA2-384 SHA2-512 SHA2-512 SHA2-512 SHA2-512 SHA2-512 SHA2-512 SHA2-512 SHA2-512/224 SHA2-512/224 SHA2-512/224 SHA2-512/224 SHA2-512/224 SHA2-512/224 SHA2-512/224 SHA2-512/256 SHA2-512/256 SHA2-512/256 SHA2-512/256 SHA2-512/256 SHA2-512/256 SHA2-512/256 SHA3-224 SHA3-224 SHA3-224 SHA3-256 SHA3-256 SHA3-256 SHA3-384 SHA3-384 SHA3-384 SHA3-512 SHA3-512 SHA3-512 SHAKE-128 SHAKE-128 SHAKE-128 SHAKE-256

© 2024 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. 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 © 2024 Canonical Ltd. / atsec information security.

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. 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 module offers DH and ECDH shared secret computation services compliant to the SP 800-56ARev3 and meeting IG D.F scenario 2 path (1). The key agreement schemes provided by the module are dhEphem and Unified Model, pertaining to the C(2e, 0s) schemes in section 6.1.2 . 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 utilizes the following legacy algorithms as defined in SP 800-131Arev2:

Table 9: Entropy Certificates Table 10: Entropy Sources © 2024 Canonical Ltd. / atsec information security.

The module employs two Deterministic Random Bit Generator (DRBG) implementations based on SP 800-90Ar1. These DRBGs are used internally by the module (e.g. to generate seeds for asymmetric key pairs and random numbers for security functions). They can also be accessed using the specified API functions. The following parameters are used:

4. Private DRBG: AES-256 CTR_DRBG with derivation function. This DRBG is used to generate secret random values (e.g. during asymmetric key pair generation). It can be accessed using RAND_priv_bytes.
5. Public DRBG: AES-256 CTR_DRBG with derivation function. This DRBG is used to generate general purpose random values that do not need to remain secret (e.g. initialization vectors). It can be accessed using RAND_bytes. The public and private DRBGs are seeded with 384 bits of entropy and 256 bits of entropy are used to reseed each of the private and public DRBGs. The highest SSP security strength generated by the module is 256 bits. These DRBGs will always employ prediction resistance. More information regarding the configuration and design of these DRBGs can be found in the module’s manual pages.

The module implements Cryptographic Key Generation (CKG, vendor affirmed), compliant with SP 800-133r2. When random values are required, they are obtained from the SP 800-90Ar1 approved DRBG, compliant with Section 4 of SP 800-133r2. This method does not use the value V as described in Additional Comment 2 of FIPS 140-3 IG D.H. The following methods are implemented:

Intermediate key generation values are not output from the module and are explicitly zeroized after processing the service. Additionally, the module implements the following key derivation methods: • KBKDF: compliant with SP 800-108r1. This implementation can be used to derive secret keys from a pre-existing key-derivation-key. © 2024 Canonical Ltd. / atsec information security.

The module implements SSP agreement and SSP transport methods as listed in the SFI table. The module provides Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH) shared secret computation compliant with SP800-56Ar3, in accordance with scenario 2 (1) of FIPS 140-3 IG D.F. According to FIPS 140-3 IG D.B, for shared secret computation, the key sizes of DH provide 112-200 bits of security strength, while the key sizes of ECDH provide 112-

The module also supports the AES KW and AES KWP key wrapping mechanisms compliant with IG D.G and SP 800-38F. These algorithms can be used to wrap SSPs with a security strength of 128, 192, or 256 bits, depending on the wrapping key size.

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) © 2024 Canonical Ltd. / atsec information security.

• 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. © 2024 Canonical Ltd. / atsec information security.

Table 11: Ports and Interfaces The logical interfaces are the APIs through which the applications request services. These logical interfaces are logically separated from each other by the API design. The table above summarizes the logical interfaces.

Not applicable. Not applicable.

Not applicable. © 2024 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.

g d © 2024 Canonical Ltd. / atsec information security.

n n n n n n © 2024 Canonical Ltd. / atsec information security.

W,E W,E W,E W,E W,E W,E © 2024 Canonical Ltd. / atsec information security.

W,E d d: W,E,Z W,E G,W,E C): G,W,E G,W,E G,R © 2024 Canonical Ltd. / atsec information security.

G,R m m m m © 2024 Canonical Ltd. / atsec information security.

G,E,Z G,E,Z G,E,Z © 2024 Canonical Ltd. / atsec information security.

d: Z © 2024 Canonical Ltd. / atsec information security.

Name

Descript ion

Indicator

Inputs

Output s

Security Functions

SSP Access OneStep KDA Derived key: Z - TLS Derived key: Z - Entropy input: Z - DRBG Internal state (V, Key): Z - DRBG Internal state (V, C): Z - DRBG seed: 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 - Intermed iate key generati on value: Z

C): 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. © 2024 Canonical Ltd. / atsec information security.

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 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 The table above lists the non-approved services in this module, the algorithms involved, the roles that can request the service. In this table, CO specifies the Crypto Officer role.

The module does not have the capability of loading software or firmware from an external source.

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

Not applicable. © 2024 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. © 2024 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. © 2024 Canonical Ltd. / atsec information security.

Temp/Voltage Type LowTemperature HighTemperature LowVoltage HighVoltage

Temperature or Voltage

EFP or EFT

Result

Temperature Type LowTemperature HighTemperature

Temperature

The module is comprised of software only, and therefore this section is not applicable.

Number: Not applicable. Placement: Not applicable. Surface Preparation: Not applicable. Operator Responsible for Securing Unused Seals: Not applicable. Part Numbers: Not applicable.

Not applicable. Table 15: EFP/EFT Information Not applicable.

Table 16: Hardness Testing Temperatures Not applicable. © 2024 Canonical Ltd. / atsec information security.

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

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

Not applicable. © 2024 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 17: Storage Areas Table 18: 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 (see Section 9.2). © 2024 Canonical Ltd. / atsec information security.

Name AES key HMAC key KMAC key Key- derivation key Shared secret Password PBKDF Derived key

Description Used for encryption, decryption, and message authentication Used for hash- based message authentication Used for message authentication Used for key derivation Generated by shared secret computation and used for key derivation Used for password- based key derivation Generated from password-

Size - Strength 128, 192, 256 bits - 128, 192, 256 bits 112-524288 bits - 112-256 bits 128-1024 bits - 128-256 bits 112-4096 bits - 112-256 bits 224-8192 bits - 112-256 bits At least 8 characters - N/A 112-256 bits - 112-256 bits

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

Generated By Key derivation

Established By Shared secret computation

Used By Symmetric encryption Symmetric decryption Message authentication Message authentication Message authentication Key derivation Key derivation Password- based key derivation Key derivation

Table 19: 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. © 2024 Canonical Ltd. / atsec information security.

Name KBKDF Derived key ANS X9.42 Derived key ANS X9.63 Derived key HKDF Derived key OneStep KDA Derived key TLS Derived key Entropy input DRBG Internal state (V, Key) DRBG Internal state (V, C) DRBG seed

Description based key derivation Generated from key-based key derivation Generated from ANS X9.42 key derivation Generated from ANS X9.63 key derivation Generated from HKDF key derivation Generated from OneStep KDA key derivation Generated by TLS-based 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

Size - Strength 112-256 bits - 112-256 bits 112-256 bits - 112-256 bits 112-256 bits - 112-256 bits 112-256 bits - 112-256 bits 112-256 bits - 112-256 bits 112-256 bits - 112-256 bits 128-384 bits - 128-256 bits CTR_DRBG: 256, 320, 348 bits; HMAC_DRBG: 320, 512, 1024 bits - CTR_DRBG: 128, 192, 256 bits; HMAC_DRBG: 128, 256 bits 880, 1776 bits - 128, 256 bits 128-256 bits - 128-256 bits

Type - Category Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Symmetric key - CSP Entropy Input - CSP Internal state - CSP Internal state - CSP Seed - CSP

Generated By Key derivation Key derivation Key derivation Key derivation Key derivation Key derivation Random number generation Random number generation Random number generation

Established By

Used By Key derivation Key derivation Key derivation Key derivation Key derivation Key derivation Random number generation Random number generation Random number generation Random number generation

© 2024 Canonical Ltd. / atsec information security.

Name DH private key DH public key EC private key EC public key RSA private key RSA public key Intermediate key generation value SSH KDF Derived key

Description (compliant with IG D.L) Used for shared secret computation and key pair verification 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 Used for key pair generation Generated from SSH KDF key derivation

Size - Strength 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, 128, 192, 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 - 96, 112, 128, 192, 256 bits 2048-16384 bits - 112-256 bits 1024-16384 bits - 80-256 bits 112-16384 bits - 112-256 bits 112-256 bits - 112-256 bits

Type - Category Private key - CSP Public key - PSP Private key - CSP Public key - PSP Private key - CSP Public key - PSP intermediate key generation value - CSP Symmetric key - CSP

Generated By Key pair generation Key pair generation Key pair generation Key pair generation Key pair generation Key pair generation Key pair generation Key derivation

Established By

Used By Shared secret computation Key pair verification Shared secret computation Key pair verification Digital signature generation Shared secret computation Key pair verification Digital signature verification Shared secret computation Key pair verification Digital signature generation Digital signature verification Key pair generation

Table 20: SSP Table 1 © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Table 21: 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. © 2024 Canonical Ltd. / atsec information security.

The SHA-1 algorithm, as implemented by the module, will be non-approved for all purposes starting January 1, 2030. The RSA algorithm as implemented by the module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. FIPS 186-4 has been withdrawn since February 3, 2024.

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

Table 22: 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. © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.