Canonical Ltd. Ubuntu 22.04 GnuTLS Cryptographic Module

Certificate

Approved Algorithms (90)

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

flowchart LR
  %% Deterministic review-risk graph for Canonical Ltd. Ubuntu 22.04 GnuTLS 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 22.04 GnuTLS 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 22.04 GnuTLS Cryptographic Module Version 3.7.3-4ubuntu1.2+Fips1.1 Version 1.3 Last updated: 10-22-2024 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.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.7.3-4ubuntu1.2+Fips1.1 of the Canonical Ltd. Ubuntu 22.04 GnuTLS Cryptographic Module. It has a one-to-one mapping to SP 800140B starting with section B.2.1 named “General” that maps to section 1 in this document and ending with section B.2.12 named “Mitigation of other attacks” that maps to section 12 in this document.

N/A © 2024 Canonical Ltd. / atsec information security.

Purpose and Use: The Canonical Ltd. Ubuntu 22.04 GnuTLS Cryptographic Module (hereafter referred to as “the module”) provides cryptographic services to applications running in the user space of the underlying operating system through a C language Application Program Interface (API). Module Type: Software Module Embodiment: MultiChipStand Module Characteristics: Cryptographic Boundary: The software block diagram below shows the cryptographic boundary of the module, and its interfaces with the operational environment. Figure 1: Block Diagram Tested Operational Environment’s Physical Perimeter (TOEPP): © 2024 Canonical Ltd. / atsec information security.

The TOEPP (tested operational environment’s physical perimeter) of the module is defined as the general-purpose computer on which the module is installed.

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 The module makes use of hardware acceleration provided by the hardware platform. Namely, AES-NI from the Intel based platform, NEON and Cryptography Extension for the Graviton2 based platform and CPACF for the z15 based platforms, listed in the Tested Operational Environments - Software, Firmware, Hybrid table. Out of these, only CPACF is considered as PAI and other two are considered as 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.

Modes List and Description: Table 4: Modes List and Description When the module starts up successfully, after passing all the pre-operational and conditional cryptographic algorithms self-tests (CASTs), the module is operating in the approved mode of operation by default. Please see section 4 for the details on service indicator provided by the module that identifies Mode Change Instructions and Status: If the module is in the approved mode, it can be transitioned to the non-approved mode by calling one of the non-approved services listed in section 4. If the module is in the non-approved mode, the module can be transitioned to the approved mode by calling one of the approved services listed in section 4. © 2024 Canonical Ltd. / atsec information security.

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.

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: Table 7: Non-Approved, Allowed Algorithms with No Security Claimed Non-Approved, Not Allowed Algorithms: © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Table 8: Non-Approved, Not Allowed 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.

Table 9: Security Function Implementations

Hash Algorithms In compliance with IG C.B, every approved hash algorithm implementation was CAVP tested and validated on all the module’s operational environments. Section 2.5 of this security policy contains a table of the CAVP certificates of the approved hash functions. For the higher-level algorithms that use the approved hash functions - Counter DRBG, ECDSA SigGen, RSA SigGen, RSA SigVer – every implemented combination for which CAVP testing exists was CAVP © 2024 Canonical Ltd. / atsec information security.

tested and validated on all the module’s operational environments. Section 2.5 of this security policy contains a table of the CAVP certificates of these higher-level algorithms. SHA-3 The module provides SHA-3 hash functions compliant with IG C.C. Every implementation of each SHA-3 function was tested and validated on all the module’s operating environments. SHAKE functions are not implemented. SHA-3 hash functions are not used as part of a higher-level algorithm. RSA Key Generation In compliance with IG C.E, the module generates RSA signature keys using an approved method of FIPS 186-4: generation of random primes that are provably prime. The CAVP certificate #A3667 indicates that the RSA key generating algorithm has been tested and validated for conformance to the methods in FIPS 186-4. RSA Signature Generation and Signature Verification 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 both signature generation and 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. AES-GCM The module implements AES GCM for being used in the TLS v1.2 and v1.3 protocols. AES GCM IV generation is compliant with [FIPS140-3_IG] IG C.H for both protocols as follows:

• For TLS v1.2, IV generation is compliant with scenario 1.a of IG C.H and [RFC5288]. The module supports acceptable AES-GCM cipher suites from section 3.3.1 of [SP800-52rev2].
• For TLS v1.3, IV generation is compliant with scenario 5 of IG C.H and [RFC8446]. The module supports acceptable AES-GCM cipher suites from section 3.3.1 of [SP800-52rev2]. The IV generated in both scenarios is only used within the context of the TLS protocol implementation. The nonce_explicit part of the IV does not exhaust the maximum number of possible values for a given session key. The design of the TLS protocol in this module implicitly ensures that the nonce_explicit, or counter portion of the IV will not exhaust all its possible values. In case the module's power is lost and then restored, the key used for the AES GCM encryption or decryption shall be redistributed. AES-XTS The AES algorithm in XTS mode can only be used for the cryptographic protection of data on storage devices, as specified in SP800-38E. The length of a single data unit encrypted with the AES-XTS shall not exceed 2²⁰ AES blocks, that is 16MB of data. To meet the requirement stated in 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. Key Agreement Methods 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 © 2024 Canonical Ltd. / atsec information security.

“Asymmetric key generation” service must be used to generate ephemeral Diffie-Hellman or EC DiffieHellman 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. Key Transport Methods Please refer to section 2.10 of this security policy. Cryptographic Key Generation In compliance with IG D.H, the module generates symmetric keys and seeds for asymmetric keys using the method described in section 4 example 1 of SP 800-133r2 without the use of V (direct DRBG output as described in additional comment 2 of IG D.H). Please refer to section 2.9 for more information on the key generation methods employed by the module. DRBGs In compliance with IG D.L, the entropy input, DRBG seed, DRBG internal state (values of V and Key) are considered CSPs. The DRBG internal state is contained within the DRBG mechanism boundary and is not accessible by other mechanisms. PBKDF2 The module provides password-based key derivation (PBKDF), compliant with SP800-132 and IG D.N. The module supports option 1a from section 5.4 of SP800-132, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In accordance with SP800-132, the following requirements shall be met.

• Derived keys shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The length of the MK or DPK shall be 112 bits or more (this is verified by the module to determine the service is approved).
• 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 SP800-90Arev1 DRBG.
• 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 shall be 1000 (this is verified by the module to determine the service is approved).
• Passwords or passphrases, used as an input for the PBKDF, shall not be used as cryptographic keys.
• The length of the password or passphrase shall be of at least 8 characters (this is verified by the module to determine the service is approved), and shall consist of lower-case, upper-case, and numeric characters. The probability of guessing the value is estimated to be 1/62^{8} = 10^{-14}, which is less than 2^{-112}. If the password consists of only digits (worst case), the probability of guessing the value is estimated to be 10^{-8} which is less than 2^{-112}. © 2024 Canonical Ltd. / atsec information security.

The requirements of input parameters (derived key length, salt length, iteration count and password length) are verified by the module when providing the service indicator. The calling application shall also observe the rest of the requirements and recommendations specified in SP800-132. TLS v1.2 KDF In compliance with IG D.Q, the module supports the TLS 1.2 KDF with the extended master secret: TLS v1.2 KDF RFC7627 (CVL).

Table 10: Entropy Certificates Table 11: Entropy Sources The module implements CTR_DRBG with AES-256, according to SP800-90Arev1, without a derivation function and without prediction resistance. The module uses an SP800-90B-compliant entropy source as specified above. This entropy source is located within the physical perimeter, but outside of the cryptographic boundary of the module. The public use document of the entropy source is found at: https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/entropy/E60_PublicUse.pdf The module obtains 384 bits from the entropy source to seed the DRBG, and 256 bits to reseed it, sufficient to provide a DRBG with 256 bits of security strength. The largest key strength generated by the module is 256 bits.

The module generates symmetric keys and seeds for asymmetric keys using the method described in section 4 example 1 of SP 800-133r2 without the use of V (direct output of DRBG as described in additional comment 2 of IG D.H). The module generates the following keys:

• RSA (asymmetric): 2048, 3072, 4096-bit keys with 112-149 bits of key strength
• ECDSA (asymmetric): P-256, P-384, P-521 elliptic curves with 128-256 bits of key strength © 2024 Canonical Ltd. / atsec information security.

• ECDH (asymmetric): P-256, P-384, P-521 elliptic curves with 128-256 bits of key strength
• Safe Primes (asymmetric): 2048, 3072, 4096, 6144, 8192-bit keys with 112-200 bits of key strength
• AES (symmetric): 128, 192, 256-bit keys with 128-256 bits of key strength
• HMAC (symmetric): 112-524288 bit keys with 112-256 bits of key strength The generation of RSA keys is compliant with section B.3.2 of FIPS 186-4 (provable primes). The generation of ECDSA keys is compliant with section B.4.2 of FIPS186-4 (testing candidates). The generation of EC Diffie-Hellman keys is performed using the ECDSA key generation method, which is compliant with FIPS 186-4 and SP 800-56Ar3. The generation of Diffie-Hellman keys is compliant with SP 800-56Ar3 (testing candidates). The module generates keys using safe primes defined in RFC7919 and RFC3526. Additionally, the module implements the following key derivation methods:
• KDF TLS (CVL), compliant with SP800-135r1: derivation of secret keys in the context of TLS 1.0/1.1
• TLS v1.2 KDF RFC7627 (CVL), compliant with SP800-135r1: derivation of secret keys in the context of TLS 1.2
• KDA HKDF Sp800-56Cr1, compliant with SP800-56Cr1: derivation of secret keys in the context of SP800-56Ar3 key agreement schemes
• PBKDF2, compliant with option 1a of SP800-132: derivation of keys for use in storage applications

Key Agreement The module provides Diffie-Hellman and EC Diffie-Hellman shared secret computation compliant with SP800-56Arev3, in accordance with scenario 2 (1) of IG D.F and used as part of the TLS protocol key exchange in accordance with scenario 2 (2) of IG D.F; that is, the shared secret computation (KAS-FFCSSC and KAS-ECC-SSC) followed by the derivation of the keying material using KDF TLS (CVL), TLS v1.2 KDF RFC7627 (CVL), or KDA HKDF Sp800-56Cr1. The Diffie-Hellman shared secret computation, EC DiffieHellman shared secret computation, KDF TLS (CVL), TLS v1.2 KDF RFC7627 (CVL), and KDA HKDF Sp80056Cr1 have been CAVP tested. The EC Diffie-Hellman shared secret computation uses the Ephemeral Unified Model. The module supports EC Diffie-Hellman shared secret computation with P-256, P-384, and P-521 curves which have a security strength of 128-256 bits. The Diffie-Hellman shared secret computation uses the DH Ephemeral scheme. The module supports Diffie-Hellman shared secret computation with the MODP-2048, MODP-3072, MODP-4096, MODP-6144, MODP-8192, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, and ffdhe8192 groups which have a security strength of 112-200 bits. Key Transport The module provides key wrapping (KTS), compliant with IG D.G, using AES-CCM, AES-GCM, and AES-CBC with HMAC, used in the context of the TLS protocol cipher suites with 128-bit or 256-bit keys, with strengths of 128 bits and 256 bits respectively. When using AES-CBC with HMAC, the entire wrapped message is authenticated. AES-CCM, AES-GCM, AES-GCM, and HMAC have been tested and validated by the CAVP and the algorithms’ certificate numbers are in section 2.5 of the security policy. © 2024 Canonical Ltd. / atsec information security.

The TLS protocol implementation provides both server and client sides. To operate in the approved mode, digital certificates used for server and client authentication shall comply with the restrictions of key size and message digest algorithms imposed by SP800-131Arev2. No parts of the TLS protocol, other than the approved cryptographic algorithms and the KDFs, have been tested by the CAVP and CMVP.

N/A © 2024 Canonical Ltd. / atsec information security.

Table 12: Ports and Interfaces The module does not have a control output interface.

N/A © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

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

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

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

© 2024 Canonical Ltd. / atsec information security.

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

G,R G,R Table 14: Approved Services The “Indicator” column shows the service indicator API functions that must be used to verify the service indicator for each of the services. The function gnutls_fips140_get_operation_state() indicates GNUTLS_FIPS140_OP_NOT_APPROVED or GNUTLS_FIPS140_OP_APPROVED depending on whether the API invoked corresponds to an approved or non-approved algorithm. © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Table 15: Non-Approved Services

The module does not support the loading of external software/firmware.

N/A © 2024 Canonical Ltd. / atsec information security.

The integrity of the module is verified by comparing an HMAC-SHA2-256 value calculated at run time with the HMAC value stored in the .hmac file that was computed at build time for each software component of the module listed in section 2. If the HMAC values do not match, the test fails, and the module enters the error state.

The pre-operational integrity self-test can be initiated on demand by calling the Self-Test service (via the gnutls_fips140_run_self_tests() function) or by powering-off and reloading the module. During the execution of the on-demand integrity self-test, services are not available, and no data output is possible.

N/A © 2024 Canonical Ltd. / atsec information security.

Type of Operational Environment: Modifiable How Requirements are Satisfied: N/A

The module shall be installed as stated in section 11. 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.

N/A © 2024 Canonical Ltd. / atsec information security.

Temp/Voltage Type LowTemperature HighTemperature LowVoltage HighVoltage

Temperature or Voltage

EFP or EFT

Result

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

Number: Placement: Surface Preparation: Operator Responsible for Securing Unused Seals: Part Numbers: N/A

N/A Table 16: EFP/EFT Information

© 2024 Canonical Ltd. / atsec information security.

Table 17: Hardness Testing Temperatures

N/A © 2024 Canonical Ltd. / atsec information security.

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

N/A © 2024 Canonical Ltd. / atsec information security.

Table 18: Storage Areas Table 19: SSP Input-Output Methods © 2024 Canonical Ltd. / atsec information security.

Table 20: SSP Zeroization Methods All data output is inhibited when the module is performing zeroization. © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

6, n 4, n © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

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

© 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

N/A © 2024 Canonical Ltd. / atsec information security.

The module performs the pre-operational self-test and cryptographic algorithm self-tests (CASTs) automatically when the module is loaded into memory. The module’s services are not available for use and data input and output are inhibited until the pre-operational tests and CASTs are completed successfully. If any of the pre-operational integrity self-tests or CASTs fail, an error message is returned and the module transitions to the error state.

Table 23: Pre-Operational Self-Tests

© 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 24: Conditional Self-Tests © 2024 Canonical Ltd. / atsec information security.

Algorithm or Test

Test Method

Test Type

Period

Periodic Method gnutls_fips140_run_self_tests() function

Table 25: Pre-Operational Periodic Information © 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 26: Conditional Periodic Information

© 2024 Canonical Ltd. / atsec information security.

Name

Description

Conditions KAT fails; When a newly generated RSA, ECDSA, Diffie- Hellman or EC Diffie-Hellman key pair fails the PCT; When the module is in error state and caller requests cryptographic operations;

Recovery Method

Indicator

Table 27: Error States The calling application can obtain the module state by calling the gnutls_fips140_get_operation_state() API function. The function returns GNUTLS_FIPS140_OP_ERROR if the module is in the Error state.

The operator can initiate the pre-operational integrity self-test and cryptographic algorithm self-tests by calling the Self-Test service (via the gnutls_fips140_run_self_tests() function) or by powering-off and reloading the module. The operator can initiate a pairwise consistency self-test by calling the “Asymmetric key generation” service. During the execution of the pre-operational integrity self-test and cryptographic algorithm self-tests, services are not available, and no data output is possible.

N/A © 2024 Canonical Ltd. / atsec information security.

The module needs to be set to run in the FIPS validated operational environment. 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 the FIPS validated operational environment run: $ sudo pro enable fips (4) To verify that the FIPS validated operational environment is enabled run: $ sudo pro status The pro client will install the necessary packages that are part of the FIPS validated operational environment, including the kernel and the bootloader. After this step you MUST reboot to enter the FIPS validated operational environment. The reboot will boot into the kernel of the FIPS validated operational environment and create the /proc/sys/crypto/fips_enabled entry which tells the FIPS certified modules to run in the approved mode of operation. If you do not reboot after installing and configuring the bootloader, you will not be in the FIPS validated operational environment. To verify that the FIPS validated operational environment 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 the approved mode of operation. If the file is missing, the correct kernel (which is part of the FIPS validated operational environment) is not installed. You can verify that the FIPS validated operational environment has been properly enabled with the pro status command. Instrumentation tools like the ptrace system call, gdb and strace utilities, 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-tested operational environment. If the module is not installed, initialized, and configured according to this section, the module is in a noncompliant state. If the module is in a non-compliant state, it can be placed into the compliant state by un-initializing and uninstalling the module and then installing, initializing, and configuring the module according to this section.

On the Supermicro SYS-1019P-WTR hardware platform with the Intel Xeon Gold 6226 processor, the module is delivered through the following Ubuntu packages: © 2024 Canonical Ltd. / atsec information security.

libgnutls30_3.7.3-4ubuntu1.2+Fips1.1_amd64.deb libnettle8_3.7.3-1ubuntu0.1~Fips1_amd64.deb libhogweed6_3.7.3-1ubuntu0.1~Fips1_amd64.deb libgmp10_6.2.1+dfsg-3ubuntu1+Fips1_amd64.deb On the Amazon Web Services (AWS) c6g.metal hardware platform with the AWS Graviton2 processor, the module is delivered through the following Ubuntu packages: libgnutls30_3.7.3-4ubuntu1.2+Fips1.1_arm64.deb libnettle8_3.7.3-1ubuntu0.1~Fips1_arm64.deb libhogweed6_3.7.3-1ubuntu0.1~Fips1_arm64.deb libgmp10_6.2.1+dfsg-3ubuntu1+Fips1_arm64.deb On the IBM z15 hardware platform with the z15 processor, the module is delivered through the following Ubuntu packages: libgnutls30_3.7.3-4ubuntu1.2+Fips1.1_s390x.deb libnettle8_3.7.3-1ubuntu0.1~Fips1_s390x.deb libhogweed6_3.7.3-1ubuntu0.1~Fips1_s390x.deb libgmp10_6.2.1+dfsg-3ubuntu1+Fips1_s390x.deb

After the operating environment has been configured according to the instructions of section 11.1.1, the Crypto Officer can install the Ubuntu packages containing the module using the Advanced Package Tool (APT) with the following commands: $ sudo apt-get install libgnutls30=3.7.3-4ubuntu1.2+Fips1.1 $ sudo apt-get install libgmp10=2:6.2.1+dfsg-3ubuntu1+Fips1 $ sudo apt-get install libhogweed6=3.7.3-1ubuntu0.1~Fips1 $ sudo apt-get install libnettle8=3.7.3-1ubuntu0.1~Fips1 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. The module cannot use the following environment variables: GNUTLS_NO_EXPLICIT_INIT GNUTLS_SKIP_FIPS_INTEGRITY_CHECKS The module can only be used with the cryptographic algorithms provided. Therefore, the following API functions are forbidden in the approved mode of operation: gnutls_crypto_register_cipher gnutls_crypto_register_aead_cipher gnutls_crypto_register_mac gnutls_crypto_register_digest gnutls_privkey_import_ext4

© 2024 Canonical Ltd. / atsec information security.

The Crypto Officer shall follow this Security Policy to configure the operational environment and install the module to be operated in the approved mode. The output of the “Show module name and version” service is: “Canonical Ltd. Ubuntu 22.04 GnuTLS Cryptographic Module” and "3.7.3-4ubuntu1.2+Fips1.1".

The approved security functions are listed in section 2.6 of this security policy. The logical interfaces available to the users of the cryptographic module are listed in section 3.1. For the secure operation of the module, the operator must follow the instructions in section 11.1 of this security policy.

For secure sanitization of the cryptographic module, the module needs first to be powered off, which will zeroize all keys and CSPs in volatile memory. The module does not possess persistent storage of SSPs, so further sanitization steps are not needed.

N/A © 2024 Canonical Ltd. / atsec information security.

The module does not mitigate other attacks.

N/A © 2024 Canonical Ltd. / atsec information security.

Appendix A: TLS Cipher Suites The module supports the following cipher suites for the TLS protocol version 1.0, 1.1, 1.2 and 1.3, compliant with section 3.3.1 of SP800-52rev2. Each cipher suite defines the key exchange algorithm, the bulk encryption algorithm (including the symmetric key size) and the MAC algorithm. © 2024 Canonical Ltd. / atsec information security.

© 2024 Canonical Ltd. / atsec information security.

Appendix B. Glossary and Abbreviations AES                   Advanced Encryption Standard AES-NI                Advanced Encryption Standard New Instructions CAVP                  Cryptographic Algorithm Validation Program CBC                   Cipher Block Chaining CCM                   Counter with Cipher Block Chaining-Message Authentication Code CFB                   Cipher Feedback CMAC                  Cipher-based Message Authentication Code CMVP                  Cryptographic Module Validation Program CPACF                 Central Processor Assist for Cryptographic Function CSP                   Critical Security Parameter CTR                   Counter Mode DF                    Derivation Function DRBG                  Deterministic Random Bit Generator ECB                   Electronic Code Book ECC                   Elliptic Curve Cryptography FFC                   Finite Field Cryptography FIPS                  Federal Information Processing Standards Publication FSM                   Finite State Model GCM                   Galois Counter Mode HMAC                  Hash Message Authentication Code KAS                   Key Agreement Schema KAT                   Known Answer Test MAC                   Message Authentication Code NIST                  National Institute of Science and Technology OFB                    Output Feedback OS                    Operating System PAA                   Processor Algorithm Acceleration PAI                   Processor Algorithm Implementation PR                    Prediction Resistance PSS                   Probabilistic Signature Scheme RNG                   Random Number Generator RSA                   Rivest, Shamir, Addleman SHA                   Secure Hash Algorithm SHS                   Secure Hash Standard © 2024 Canonical Ltd. / atsec information security.

SSH Secure Shell SSP Sensitive Security Parameter XTS XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 Canonical Ltd. / atsec information security.