Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module

Certificate

Approved Algorithms (217)

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

flowchart LR
  %% Deterministic review-risk graph for Canonical Ltd. Ubuntu 22.04 Strongswan 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>Update<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>selftest<br/>self-test<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/>IKEV</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 Strongswan 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>Update<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>selftest<br/>self-test<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/>IKEV</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. Ubuntu 22.04 Strongswan Cryptographic Module Version: 5.9.5-2ubuntu2.1+Fips1 Document Version: 1.1 Last Update: 2024-11-27 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.

3 of 40

1. General Information 1.1. Overview This document is the non-proprietary FIPS 140-3 Security Policy for version 5.9.5-2ubuntu2.1+Fips1 of the Canonical Ltd. Ubuntu 22.04 Strongswan 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 distributed, but only whole and intact and including this notice. Other documentation is proprietary to their authors. 1.2. How this Security Policy was Prepared 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. 1.3. Security Levels Table 1 describes the individual security areas of FIPS 140-3, as well as the security levels of those individual areas. Table 1 - Security Levels © 2024 Canonical Ltd./ atsec information security.

5 of 40

2. Cryptographic Module Specification 2.1. Description Purpose and Use: The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module (hereafter referred to as “the module”) provides cryptographic services for the Internet Key Exchange (IKE) protocol in the Ubuntu Operating System user space. The module uses the Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module as a bound module (also referred to as “the bound OpenSSL module”), which provides the underlying cryptographic algorithms necessary for establishing and maintaining IKE sessions. The Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module is a FIPS-validated module with certificate #4794. The module also uses the Canonical Ltd. Ubuntu 22.04 Kernel Crypto API Cryptographic Module as a bound module (also referred to as “the bound Kernel Crypto API module”) for performing integrity tests. The Canonical Ltd. Ubuntu 22.04 Kernel Crypto API Cryptographic Module is a FIPS-validated module with certificate #4894. Module Type: Software Module Embodiment: Multi-chip standalone Module Characteristics: N/A Cryptographic Boundary: The cryptographic boundary of the module is defined as the IKEv2 daemon, the libraries and plugins, and the ipsec command. In addition, the cryptographic boundary contains the .hmac files which store the expected integrity values for each of the software components. Tested Operational Environment's Physical Perimeter (TOEPP) The TOEPP of the module is defined as the general-purpose computer on which the module is installed. Picture or Block Diagram © 2024 Canonical Ltd./ atsec information security.

6 of 40

Figure 1 - Block Diagram 2.2. Version Information Hardware Versions: N/A Software Versions: 5.9.5-2ubuntu2.1+Fips1 Firmware Versions: N/A 2.3. Operating Environments Software, Firmware, Hybrid Tested Operating Environments: © 2024 Canonical Ltd./ atsec information security.

7 of 40

Table 2 - Software, Firmware, Hybrid Tested Operating Environments Executable Code Sets: © 2024 Canonical Ltd./ atsec information security.

8 of 40

Table 3 - Executable Code Sets Vendor Affirmed Operating Environments: N/A 2.4. Excluded Components There are no components within the cryptographic boundary excluded from the FIPS 140-3 requirements. 2.5. Modes of Operation Modes List and Description: Table 4 - Modes List and Description The module enters Approved mode after passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up. The approved mode of operation is assumed once the Mode change instructions and status indicators: The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module implements the approved service indicator relying on a global service indicator (In compliance with IG 2.4.C - Table) which is the successful establishment of the IKE connection. Degraded Mode Description: The module does not implement a degraded mode of operation. © 2024 Canonical Ltd./ atsec information security.

9 of 40

2.6. Algorithms Approved Algorithms: Although HMAC and SHA are implemented by the bound OpenSSL module, the CAVP certificate still contains HMAC and SHA as prerequisite algorithms. © 2024 Canonical Ltd./ atsec information security.

10 of 40

© 2024 Canonical Ltd./ atsec information security.

11 of 40

Table 5 - Approved Algorithms Vendor Affirmed Algorithms: N/A Non-Approved, Allowed Algorithms: The module does not implement non-approved algorithms allowed in the approved mode of operation. Non-Approved, Allowed Algorithms with No Security Claimed: The module does not implement non-approved algorithms allowed in the approved mode of operation with no security claimed. Non-Approved, Not Allowed Algorithms: The module does not implement non-approved algorithms not allowed in the approved mode of operation. Entropy Information: RNG Information: The module does not implement any random number generator. Instead, it uses the Random Number Generation (RNG) service provided by the bound Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module, which implements a Deterministic Random Bit Generator (DRBG) based on [SP800-90Ar1]. The DRBG is seeded with 384 bits of entropy and 256 bits of entropy are used to reseed the DRBG. The highest SSP security strength generated by the module is 256 bits. © 2024 Canonical Ltd./ atsec information security.

12 of 40

2.8. SSP Generation The module implements the key derivation portion of the DH and ECDH key agreement, using the NIST SP 800-135 IKEv2 (CVL) in compliance with Section 6.2 of SP 800-132r2. The DH and ECDH key pairs to be used in the IKEv2 protocol are generated by the bound OpenSSL module. Below are listed the SSP generation methods provided by the bound OpenSSL module: Table 7 - SSP Generation 2.9. SSP Establishment The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module and the bound OpenSSL module together provide the Diffie Hellman and EC Diffie Hellman key agreement. The Canonical Ltd. Ubuntu

22.04 Strongswan Cryptographic Module only implements the NIST SP 800-135 IKEv2 KDF (CVL) part

of the key agreement using the HMAC portion of the SSP agreement and the bound OpenSSL module provides the shared secret computation. Below are listed the SSP agreement methods provided by the bound OpenSSL module: Table 8 - SSP Agreement The module does not implement any key transport method. 2.10. Design and Rules The module performs pre-operational self-test and cryptographic algorithm self-tests when it is loaded into memory without operator intervention. Pre-operational self-tests ensure that the © 2024 Canonical Ltd./ atsec information security.

13 of 40

module is not corrupted and that the cryptographic algorithms work as expected. While the module is executing the self-tests, services are not available, and input and output are inhibited. The module is not available for use until the self-tests complete successfully. If any pre-operational self-test fails, the module will return the error message listed in Table 19, enter the error state and terminate. Therefore, no cryptographic operations or data output are possible. Note: The bound Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module and the Canonical Ltd. Ubuntu 22.04 Kernel Crypto API Cryptographic Module perform their own pre-operational and cryptographic algorithm self-tests automatically when they are loaded into memory. The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module ensures that both bound modules complete their pre-operational self-tests successfully. 2.11. Initialisation There are no specific initialization requirements. © 2024 Canonical Ltd./ atsec information security.

14 of 40

3. Cryptographic Module Interfaces 3.1. Description Table 9 - 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. 3.2. Trusted Channel Specification The module does not implement a trusted channel. © 2024 Canonical Ltd./ atsec information security.

15 of 40

4. Roles, Services, and Authentication The module does not implement operator authentication. 4.2. Roles Table 10 - Roles The module supports the Crypto Officer role only. This sole role is implicitly and always assumed by the operator of the module. No support is provided for multiple concurrent operators. 4.3. Approved Services © 2024 Canonical Ltd./ atsec information security.

16 of 40

© 2024 Canonical Ltd./ atsec information security.

17 of 40

© 2024 Canonical Ltd./ atsec information security.

18 of 40

Table 11 - Approved Services Table 11 lists the approved services. The following convention is used to specify access rights to SSPs:

• Generate (G): The module generates or derives the SSP.
• Read (R): The SSP is read from the module (e.g. the SSP is output).
• Write (W): The SSP is updated, imported, or written to the module.
• Execute (E): The module uses the SSP in performing a cryptographic operation. 4.4. Non-Approved Services The module does not implement any non-approved services. 4.5. External Software/Firmware Loaded The module does not load external software or firmware. 4.6. Bypass Actions and Status The module does not implement a bypass capability. 4.7. Cryptographic Output Actions and Status The module does not implement a self-initiated cryptographic output capability. © 2024 Canonical Ltd./ atsec information security.

19 of 40

5. Software/Firmware Security 5.1. Integrity Techniques The integrity of the module is verified by comparing an HMAC-SHA-256 value calculated at run time with the HMAC value stored in the .hmac file that was computed at build time, for each of the components that comprise the module. The HMAC-SHA-256 algorithm for integrity test is provided by the bound Canonical Ltd. Ubuntu 22.04 Kernel Crypto API Cryptographic Module. If the HMAC values do not match, the test fails and the module enters the error state. 5.2. Initiate on Demand Integrity test is performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity test can be invoked on demand by unloading and subsequently reinitializing the module, which will perform (among others) the software integrity tests. © 2024 Canonical Ltd./ atsec information security.

20 of 40

6. Operational Environment 6.1. Operational Environment Type and Requirements Type of Operating Environment: modifiable; the module executes as part of a general-purpose operating system (Canonical Ubuntu 22.04), which allows modification, loading, and execution of software that is not part of the validated module. How Requirements are Satisfied: 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. Processes that are spawned by the cryptographic module are owned by the module and are not owned by external processes/operators. 6.2. Configuration Settings and Restrictions The module shall be installed as stated in Section 11.1. Instrumentation tools like the ptrace system call, gdb and strace, as well as other tracing mechanisms offered by the Linux environment such as ftrace or systemtap, shall not be used in the operational environment. The use of any of these tools implies that the cryptographic module is running in a nonvalidated operational environment. © 2024 Canonical Ltd./ atsec information security.

21 of 40

7. Physical Security The module is comprised of software only and therefore this section is not applicable. © 2024 Canonical Ltd./ atsec information security.

22 of 40

8. Non-Invasive Security This module does not implement any non-invasive security mechanism and therefore this section is not applicable. © 2024 Canonical Ltd./ atsec information security.

23 of 40

9. Sensitive Security Parameters Management 9.1. Storage Areas Table 12 - Storage Areas The module does not perform persistent storage of SSPs. The SSPs are temporarily stored in the RAM in plaintext form. SSPs are provided to the module by the calling process and are destroyed when released by the appropriate zeroization function calls. Public and private keys for IKEv2 authentication are stored in the /etc/ipsec.d/certs and /etc/ipsec.d/private directories, which are within the module’s physical perimeter, but outside its cryptographic boundary. The module does not support manual key entry or intermediate key generation key output. The keys are entered from or output to the module electronically. © 2024 Canonical Ltd./ atsec information security.

24 of 40

Table 14 - SSP Zeroization Methods The memory occupied by SSPs is allocated by regular memory allocation operating system calls. The module calls appropriate key zeroization functions provided by the bound OpenSSL module and calls its own appropriate key zeroization functions. In both cases, these functions overwrite the memory with zeroes and deallocate the memory with the regular memory deallocation operating system call. All data output is inhibited during zeroization. 9.4. SSPs © 2024 Canonical Ltd./ atsec information security.

25 of 40

© 2024 Canonical Ltd./ atsec information security.

26 of 40

Table 15 - SSP Information First © 2024 Canonical Ltd./ atsec information security.

27 of 40

© 2024 Canonical Ltd./ atsec information security.

28 of 40

Table 16 - SSP Information Second 9.5. Transitions The SHA-1 algorithm as implemented by the bound OpenSSL module will be non-approved for all purposes, starting January 1, 2030. The RSA algorithm as implemented by the bound OpenSSL module conforms to FIPS 186-4, which has been superseded by FIPS 186-5. FIPS 186-4 will be withdrawn on February 3, 2024. © 2024 Canonical Ltd./ atsec information security.

29 of 40

10. Self-Tests 10.1. Pre-Operational Self-Tests Table 17 - Pre-Operational Self-Tests powered on, before the module transitions into the operational state. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module transitions to the operational state only after the pre-operational self-tests are passed successfully. 10.2. Conditional Self-Tests The module performs the self-test on the following Approved cryptographic algorithm supported in Approved mode using the Known Answer Test (KAT) shown below: © 2024 Canonical Ltd./ atsec information security.

30 of 40

5.6.2.1.4 Table 18 - Conditional Self-Tests For the KAT, the module calculates the result and compares it with the known answer. If the calculated value does not match the known answer, the KAT fails and the module enters the error state. 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 Table 18. Services are not available, and data output (via the data output interface) is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state. 10.3. Periodic Self-Tests The module does not implement any periodic self-tests. 10.4. Error States If the module fails any of the self-tests, it will return an error message to indicate the error and then enter the error state. In the error state, the module immediately stops functioning and ends the © 2024 Canonical Ltd./ atsec information security.

31 of 40

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). The following table shows the list of error messages when the module fails any self-test. Table 19 - Error States To recover from the error state, the module must be restarted and perform self-tests again. If the failure persists, the module must be reinstalled. 10.5. Operator Initiation The software integrity tests, cryptographic algorithm self-tests, and entropy source start-up tests can be invoked on demand by unloading and subsequently re-initializing the module. On-demand selftests can be invoked by powering off and reloading the module, which cause the module to run the self-tests again. During the execution of the on-demand self-tests, services are not available and no data output or input is possible. © 2024 Canonical Ltd./ atsec information security.

32 of 40

11. Life-Cycle Assurance 11.1. Startup Procedures The module is distributed as a part of Ubuntu 22.04 in the form of the following deb packages:

• strongswan=5.9.5-2ubuntu2.1+Fips1
• strongswan-charon=5.9.5-2ubuntu2.1+Fips1
• strongswan-hmac=5.9.5-2ubuntu2.1+Fips1
• strongswan-libcharon=5.9.5-2ubuntu2.1+Fips1
• strongswan-starter=5.9.5-2ubuntu2.1+Fips1
• libstrongswan=5.9.5-2ubuntu2.1+Fips1
• libstrongswan-standard-plugins=5.9.5-2ubuntu2.1+Fips1
• libcharon-extauth-plugins_5.9.5-2ubuntu2.1+Fips1 In order to configure the operating environment, the following bound modules must be installed:
• Canonical Ltd. Ubuntu 22.04 Kernel Crypto API Cryptographic Module
• Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module Please follow the instructions provided in the respective security policies to install and configure both modules in the Approved mode of operation. Once these modules are installed and configured properly, the operating environment is configured to support Approved operation. The Crypto Officer should check the existence of the file /proc/sys/crypto/fips_enabled, which content should be the character “1”. If the file does not exist or does not contain “1”, the operating environment is not configured to support Approved mode and the module will not operate in the Approved mode properly. 11.1.1. Operating Environment Configurations The module needs to be set to run in the Approved mode configuration. This can be enabled automatically via the Ubuntu Advantage tool after attaching your subscription.
• To install the tool type the following commands: $ sudo apt update $ sudo apt install ubuntu-advantage-tools
• To activate the Ubuntu Pro subscription run: $ sudo pro attach 'your_pro_token'
• To enable Approved mode run: $ sudo pro enable fips
• 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 © 2024 Canonical Ltd./ atsec information security.

33 of 40

boot into the 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 Approved mode 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 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 module can only operate in Approved mode as stated in section 3.2. With the operational environment setup as stated in the above section, the following restrictions are applicable. No more cipher addition is possible by configuration or command line options. Configure Charon as specified in ipsec.conf(5), and ipsec.secrets(5) man pages

• To start and stop the module, use the ipsec command.
• IKEv2 must be used In order to run the module in Approved mode of operation, the following setting must be included in the ipsec.conf file: keyexchange = ikev2
• ikelifetime should not be larger than 1 hour: ikelifetime = 1h
• salifetime should not be larger than 1 hour: salifetime = 1h
• Galois Counter Mode (GCM) should be used with their full tag lengths.
• Aggressive mode should not be used.
• Stopping the module will zeroize the SSP (e.g., ephemeral key).
• To check module status, read the Charon debug data using the ipsec statusall command line and the logs in /var/log/charon.log. NOTE: Encryption and decryption of data is done implicitly when the kernel triggers Charon to set up a new Security Association. 11.1.2. Module Installation Once the operating environment is configured following the instructions provided in Section 11.1.1, and configuration to access the PPA is complete, the Crypto Officer can install the Ubuntu packages containing the module using the Advanced Package Tool (APT), for example with the following command line: $ sudo apt-get install strongswan strongswan-charon strongswan-hmac strongswan-libcharon strongswan-starter libstrongswan libstrongswan-standard-plugins 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 packages are installed, the Crypto Officer must execute the ipsec version command. The Crypto Officer must ensure that the proper name and version are listed in the output as follows: Linux strongSwan U5.9.5/K5.15.0-70-fips © 2024 Canonical Ltd./ atsec information security.

34 of 40

University of Applied Sciences Rapperswil, Switzerland FIPS module name: Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module FIPS module version: 5.9.5-2ubuntu2.1+Fips1 11.2. Administrator Guidance 11.2.1. Managing the IKEv2 Daemon To start the IKEv2 daemon, use the following command: # ipsec start To stop the IKEv2 daemon, use the following command: # ipsec stop To start the IKEv2 daemon automatically at the system boot time, use the following command: # systemctl enable strongswan To prevent the IKEv2 daemon from automatically starting, use the following command: # systemctl disable strongswan See the ipsec(8), ipsec.conf(5) and ipsec.secrets(5) man pages for more information about how to operate the module. 11.2.2. AES GCM IV The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module is bound to the Canonical Ltd. Ubuntu 22.04 OpenSSL Cryptographic Module which implements AES-GCM. This module, Strongswan, generates the IV for AES-GCM in OpenSSL through the IKEv2 key establishment protocol which is compliant with IG C.H provision 1) (b), "IPSec protocol IV generation". The AES-GCM IV generation is in compliance with [RFC5282]. The module uses the [RFC7296] compliant IKEv2 protocol to establish the shared secret SKEYSEED from which the AES-GCM encryption keys are derived. By the virtue of the lifetime limit (see above Section 11.1.1), the IV is renegotiated before reaching 2^64. The IV does not get stored permanently. In case or normal or abnormal termination of the IKE connection, the SA has to be renegotiated by the module. In the event the module’s power is lost and restored, the operator must ensure that a new key for use with the AES GCM key encryption or decryption under this scenario shall be established. 11.2.3. RSA Signatures To meet the requirement stated in IG C.F, the bound OpenSSL module implements only the FIPS 186-

4 approved modulus sizes of 2048, 3072, and 4096 bits for signature generation. For signature

verification, the bound OpenSSL module implements only the FIPS 186-4 approved modulus sizes of 1024, 2048, 3072, and 4096 bits. Each modulus size was tested, and corresponding certificates can be found detailed in Section 2 for the bound OpenSSL module. © 2024 Canonical Ltd./ atsec information security.

35 of 40

11.2.4. Compliance to SP 800-56ARev3 Assurances The bound OpenSSL module offers DH and ECDH shared secret computation services compliant to the SP 800-56ARev3. The Canonical Ltd. Ubuntu 22.04 Strongswan Cryptographic Module implements the NIST SP 800-135 IKEv2 KDF (CVL) part of the key agreement using the HMAC portion of the SSP agreement, while the bound OpenSSL module provides the SP 800-56Arev3-compliant DH and ECDH shared secret computation. Therefore, the module meets the requirements of IG D.F scenario 2 (2). In order to meet the required assurances listed in section 5.6 of SP 800-56ARev3, the following steps are performed.

1. The entity using the bound OpenSSL module, must use the bound OpenSSL 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 bound OpenSSL module's shared secret computation (SSC) service, the bound OpenSSL module internally performs the public key validation on the peer's public key passed in as input to the SSC function. This meets the public key validity assurance required by the sections 5.6.2.2.1/5.6.2.2.2 of SP 800-56ARev3.
3. The bound OpenSSL module does not support static keys therefore the "assurance of peer's possession of private key" is not applicable. 11.2.5. Legacy Algorithms The module utilizes the following legacy algorithms from the bound OpenSSL module, as defined in SP 800-131Arev2: • SHA-1 for RSA Signature Verification and ECDSA Signature Verification purposes. 11.3. Non-Administrator Guidance There is no non-administrator guidance. 11.4. Maintenance Requirements There are no maintenance requirements. 11.5. End of Life 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, the Ubuntu packages can be uninstalled from the Ubuntu 22.04 system. © 2024 Canonical Ltd./ atsec information security.

36 of 40

12. Mitigation of Other Attacks The module does not implement security mechanisms to mitigate other attacks. © 2024 Canonical Ltd./ atsec information security.

37 of 40

Appendix A. Glossary and Abbreviations AES          Advanced Encryption Standard API          Application Programming Interface CAST         Cryptographic Algorithm Self-Test CAVP         Cryptographic Algorithm Validation Program CBC          Cipher Block Chaining CCM          Counter with Cipher Block Chaining-Message Authentication Code CKG          Cryptographic Key Generation CMVP         Cryptographic Module Validation Program CSP          Critical Security Parameter CTR          Counter DH           Diffie-Hellman DRBG         Deterministic Random Bit Generator ECC          Elliptic Curve Cryptography ECDH         Elliptic Curve Diffie-Hellman ECDSA        Elliptic Curve Digital Signature Algorithm ENT (NP)     Non-physical Entropy Source FFC          Finite Field Cryptography FIPS         Federal Information Processing Standards GCM          Galois Counter Mode GMAC         Galois Counter Mode Message Authentication Code HMAC         Keyed-Hash Message Authentication Code IG           Implementation Guidance IKE          Internet Key Exchange IPSEC        Internet Protocol Security KAS          Key Agreement Scheme KAT          Known Answer Test NIST         National Institute of Science and Technology PAA          Processor Algorithm Acceleration PCT          Pair-wise Consistency Test PKCS         Public-Key Cryptography Standards PSS          Probabilistic Signature Scheme RAM          Random Access Memory RNG          Random Number Generator RSA          Rivest, Shamir, Addleman SHA          Secure Hash Algorithm SSC          Shared Secret Computation SSH          Secure Shell SSP          Sensitive Security Parameter TLS          Transport Layer Security TOEPP        Tested Operational Environment's Physical Perimeter © 2024 Canonical Ltd./ atsec information security.

38 of 40