F5OS-A Cryptographic Module

Certificate

Approved Algorithms (44)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for F5OS-A Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C1["[high] Firmware / bootloader<br/>versions disclosed<br/>(identity, not provenance)<br/><i>1.5.1</i>"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Update own password<br/>Update others password<br/>Configure SSH user configurati on</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Show status</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/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I1["Component identity is<br/>disclosed, but provenance<br/>and patch lineage are not."]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R1["Do the vendor version<br/>strings obscure the<br/>upstream baseline, fork<br/>lineage, or known-CVE<br/>exposure?"]
    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"]
    E1["SBOM / component baselines<br/>· patch and backport<br/>manifest · CVE disposition"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C1 --> I1 --> R1 --> E1
  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 C1,C2,C3,C5,C6 clue;
  class I1,I2,I3,I5,I6 infer;
  class R1,R2,R3,R5,R6 risk;
  class E1,E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for F5OS-A Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C1["[high] Firmware / bootloader versions disclosed (identity, not provenance)<br/><i>1.5.1</i><br/>src: certificate.firmwareVersions"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Update own password<br/>Update others password<br/>Configure SSH user configurati on</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Show status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</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 C1,C2,C3 clueHigh;
  class C5,C6 clueLow;

Security Policy, page by page

F5, Inc. F5OS-A Cryptographic Module Module Version: 1.5.1 FIPS Security Level 2 Document Version 1.2 Last update: November 2024 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com

F5OS-A Cryptographic Module Table of Contents 2.1 2.2 2.3 2.4 2.5 4.1 4.2 4.3 5.1 5.2 5.3 6.1 7.1 9.1 9.2 9.3 9.4 9.5 9.6 10.1.1 10.2.1 10.2.2 10.2.3 11.2.1 11.2.2 11.2.3 © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module 11.3.1 11.3.2 11.3.3 © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module F5®, BIG-IP® are registered trademarks of F5, Inc. Intel®, Atom® and Xeon® are registered trademarks of Intel Corporation. © 2024 F5, Inc. / atsec information security.

This document is the non-proprietary FIPS 140-3 Security Policy for the F5OS-A Cryptographic Module with firmware version 1.5.1. The document 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 This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. N/A N/A N/A Table 1 - Security Levels © 2024 F5, Inc. / atsec information security.

Purpose and Use: The F5OS-A Cryptographic Module (hereafter referred to as “the module”) is a microservices-based, proprietary platform layer that provides an interface between the BIG-IP ADC and the rSeries hardware. Module Type: Firmware Module Embodiment: Multi Chip Standalone

Table 2 - Tested Operational Environments

The module supports two modes of operation:

• In Approved mode of operation only approved or vendor affirmed security functions can be used.
• In non-Approved mode of operation only non-approved security functions can be used. The module enters the approved mode after pre-operational self-tests and CASTs succeed. The module automatically switches between the approved and non-approved modes depending on the services requested by the operator. The status indicator of the mode of operation is equivalent to the indicator of the service that was requested. SSPs used or stored in the Approved mode are not used in the non-Approved mode, and vice versa. In the Approved Mode, the cryptographic module provides the following cryptographic algorithms whose CAVP certificates are in Table 3 below. Not all the ACVP tested capabilities are used by the module in approved mode of operation. © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Table 3 - Approved Algorithms The module does not implement any non-approved algorithms allowed in the approved mode of operation with or without security claimed. The following table lists the non-approved algorithms not allowed in approved mode along with their usage.

1 No parts of the TLS / SSH protocols except the KDF has been reviewed or tested by the CAVP and

CMVP © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module n Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

Figures below show the various platforms on which the module was tested. © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Figure 1 - r4800 isometric view Figure 2 - r5900 front view Figure 3 - r5920-DF front view © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Figure 4

• r10900, r10920-DF front view (same chassis for the test platforms)

The module cryptographic boundary is defined by the red dotted line in Figure

5. The TOEPP is defined by the tested platforms listed in Table 2 and delineated by the black rectangle in Figure
6. Figure 5 also depicts the flow of status output (SO), control input (CI), data input (DI) and data output (DO) interfaces. Figure 5 - Block Diagram © 2024 F5, Inc. / atsec information security.

The logical interfaces are the commands through which users of the module request services. There are no external input or output devices to the module can be used for For the purpose of the FIPS 140-3 validation, the physical ports are interpreted to be the physical ports of the hardware platform on which it runs. N/A N/A N/A N/A Table 5 - Ports and Interfaces

© 2024 F5, Inc. / atsec information security.

The module supports one CO role and one User role. Maintenance role is not supported. The FIPS 140-3 roles are defined below and corresponding service with input and output are described in Table 6.

• Crypto Officer (CO) role: The Crypto Officer is represented by the administrator/root of the module. This entity performs module installation and initialization. This role has full access to the system and can create, delete, and manage other User roles on the system. At initialization, the CO is the only available role and only the CO can create the user roles.
• The FIPS140-3 User role is mapped to multiple module roles: Operator, Resource Admin and, Tenant-console. The list of services available to the CO and user roles are defined in Table 8 and Table 9. N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module N/A N/A N/A N/A Table 6 - Roles, Service Commands, Input and Output

The module supports role-based authentication. The module supports concurrent operators belonging to different roles (one CO role and one User role) which create different authenticated sessions, while achieving the separation between the concurrent operators. Two interfaces are used to access the module: © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module

• CLI: The module offers a CLI which is accessed remotely using the SSHv2 secured session over the Ethernet connection.
• Web Utility Interface (WebUI): The Web interface consists of HTTPS over TLS-enabled web browser which provides a graphical interface for system management tools. The CO role and User role can access the module through Command Line Interface (CLI) or Web Interface. However, the CO can restrict User role access to have the User accessing through Web Interface only. The module does not maintain authenticated sessions upon power cycling. Power-cycling the system requires the authentication credentials to be re-entered. When entering password authentication data through the WebUI, any character entered will be obfuscated (i.e. replace the character entered with a dot on the entry box). When entering password authentication data through the CLI, the module does not display any character entered by the operator in stdin (e.g. keyboard). The CO and User roles are selected via the authentication credentials that are entered. the User role depending upon which interface is being used. Table 7 - Roles and Authentication

Table 8 lists the Approved services, the service name, description, the Approved security function being used by the service, the keys and SSPs accessed by the service, the roles used by the service, access rights to keys and SSPs and the FIPS 140-3 service indicator returned by the service. The environment variable SECURITY_FIPS140_CIPHER_STRICT is exported with the cipher restriction status. If the cipher_restricted status is enabled, the status output from the © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module service indicator is returned in the /var/log/audit.log file. Using an approved service will provide an indicator which shows which approved algorithms were used. If the cipher_restricted status is disabled, there is no service indicator output. For SSH service the service indicator is implicit: when the SSH connection is established the service with the cipher selected is approved.

• G = Generate: The module generates or derives the SSP.
• R = Read: The SSP is read from the module (e.g. the SSP is output).
• W = Write: The SSP is updated, imported, or written to the module.
• E = Execute: The module uses the SSP in performing a cryptographic operation.
• Z = Zeroise: The module zeroises the SSP. N/A N/A N/A N/A W N/A N/A N/A N/A N/A N/A N/A N/A N/A W N/A W N/A N/A E G E W, E © 2024 F5, Inc. / atsec information security.

N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A W Z Z W W N/A N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module G E W, E E W E G G E E N/A Z W G E W, E W E G E G, E G © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module N/A E Z N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Table 9 - Non-Approved Services © 2024 F5, Inc. / atsec information security.

The integrity of the module is verified using the approved integrity technique HMAC-SHA384, as listed in the section 10.1.1 by comparing the HMAC-SHA-384 checksum values of the installed binaries calculated at run time with the stored values computed at build time. If the values do not match, the module enters the Error state. Integrity tests are performed as part of the Pre-Operational Self-Tests.

The on demand pre-operational self-tests, including the integrity test on demand, are performed by rebooting the module.

The executable code is defined by the firmware version 1.5.1. All code belonging to this firmware version is the executable code of the module. © 2024 F5, Inc. / atsec information security.

The module operates in a non-modifiable operational environment provided by F5 with firmware version 1.5.1. Once the module is operational, it does not allow the loading of any additional firmware. The module is a firmware validated at a Security Level 2 in Physical Security then the security area is N/A. © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module The module tested in the platforms listed in Table 2 is enclosed in a hard-metallic production grade enclosure that provides opacity and prevents visual inspection of the internals. Each test platform is fitted with tamper evident labels to provide physical evidence of attempts to gain access inside the enclosure. The tamper evident labels shall be installed on the module's platform to operate in approved mode of operation N/A N/A N/A N/A Table 10 - Physical Security Inspection Guidelines The pictures below show the location of all tamper-evident labels for each platform. Label application instructions are provided in Section 11.2.1 of the Crypto-Officer guidance below. The tamper label placements are delineated with red circles. © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Figure 6 - Tamper labels on r4800 (5 of 5 tamper labels) Figure 7

• Tamper labels on r5900 (4 of 4 tamper labels) © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Figure 8 - Tamper labels on r5920-DF (5 of 5 tamper labels). Labels are located on the lateral sides of the platform -labels 1,2,3 and

4. The tamper label 5 on the chassis lid is covering the ventilation fan tray that allows access to SSD. Figure 9 – Tamper labels on r10900, r10920-DF (4 +1 tamper labels shown). Labels are located on the lateral sides of the platform -labels 1,2,3 and
5. The tamper label 5 on the chassis lid is covering the ventilation fan tray that allows access to SSD. © 2024 F5, Inc. / atsec information security.

This section is N/A until non-invasive security is defined. © 2024 F5, Inc. / atsec information security.

112bits 150bits 112bits 150bits 128bits 192bits 128bits n N/A N/A N/A N/A N/A N/A

3 "CST Establishment" column defines the distribution and entry options from IG 9.5.A e.g.

Automated Distribution / Electronic Entry = AD/EE © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module 192bits DiffieHellma n 128bits 192bits DiffieHellma n N/A EC DiffieHellman TLS preprimary DiffieHellma n 128bits 192bits DiffieHellma n N/A N/A EC DiffieHellman preprimar y DiffieHellm 128bits 192bits N/A N/A SP80056Ar3 DiffieHellma n n © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module n y 256bits N/A N/A d 256bits 256bits ) 192bits N/A N/A N/A N/A 192bits N/A N/A N/A DiffieHellma n 192bits KASECCSSC N/A DiffieHellma n 192bits KASECCSSC N/A N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module n 256bits N/A N/A SP80056Ar3 KASECCSSC d 256bits 256bits ) 7) N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module n Table 12 - SSPs The module employs a Deterministic Random Bit Generator (DRBG) based on [SP80090Ar1] for the generation of random value used in asymmetric keys. The Approved DRBG provided by the module is the CTR_DRBG with AES-256. The module uses the SP800-90B compliant entropy source specified in Table 13 to seed the DRBG. In accordance with FIPS 140-3 IG D.L, the 'Entropy input string', 'seed', 'DRBG internal state (V and key values)' are considered CSPs by the module. No non-DRBG functions or instances are able to access the DRBG internal state. The operator does not have the ability to modify the F5 entropy source (ES) configuration settings (see details in Public Use Document referenced in section 11.2). The F5 ES is tested in the OEs listed in Table 2. Table 13 - Non-Deterministic Random Number Generation Specification The module implements RSA, ECDSA and EC Diffie-Hellman asymmetric key generation services compliant with [FIPS186-4], and using an [SP800-90Ar1] DRBG. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 4 example 1 [SP800-133r2] (vendor affirmed). The RSA and ECDSA key pairs used for Digital Signature Schemes are generated in accordance with section 5.1 of [SP800-133r2] and maps specifically to [FIPS 186-4]. The ECDH key pair used for Key Establishment are generated in accordance with section

5.2 of [SP800-133r2] i.e. key generation method specified in [SP 800-56Ar3]. For this

module applicable method from [SP800-56Ar3] is 5.6.1.2 ECC Key Pair Generation which maps to [FIPS 186-4]. The module does not implement symmetric key generation as an explicit service. The HMAC and AES symmetric keys are derived from shared secrets by applying [SP 800-135] © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module as part of the TLS/ SSH protocols. The scenario maps to the [SP 800-133r2] section 6.2.1 Symmetric keys generated using Key Agreement Scheme.

The module provides the following key establishment services:

• EC Diffie-Hellman key agreement scheme compliant with SP800-56Ar3 and FIPS 140-3 IG D.F scenario 2 (path 2) is used as part of the TLS and SSH Protocols. The full EC DiffieHellman KAS implements a shared secret computation with the key derivation implemented by [SP 800-135] TLS KDFs and [SP 800-135] SSH KDFs. EC Diffie-Hellman key agreement provides 128 or 192-bits of encryption strength. [SP 800-38F], IG D.G, key wrapping in the context of TLS protocol using an approved authenticated encryption mode (i.e. AES-GCM) provides 128 or 256 bits of encryption strength (AES Cert. #A3896, 5260)
• [SP 800-38F], IG D.G, key wrapping in the context of TLS protocol using a combination of approved AES encryption and HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Certs. #A3896, #A5260).
• [SP 800-38F], IG D.G, key wrapping in the context of SSH protocol using a combination of approved AES-CBC or AES-CTR encryption mode and HMAC authentication method provides

During the TLS handshake, the keys that are entered or output to the module over the network includes RSA/ECDSA public keys. For TLS with EC Diffie-Hellman key exchange, the TLS pre-primary secret is established during key agreement and is not output from the module. Once the TLS session is established, any key or data transfer performed thereafter is protected by authenticated encryption mode using AES-GCM or by AES encryption and HMAC authentication through a mutually agreed AES and HMAC session keys derived by applying SP 800-135 TLS KDF. For SSH with EC Diffie-Hellman key exchange, the SSH shared secret is established during key agreement and is not output from the module. SSH ECDSA public keys can be imported into the module by the CO using the "Configure SSH user configuration" service. Once the SSH session is established, any key or data transfer performed thereafter is protected by AES encryption and HMAC authentication through a mutually agreed AES and HMAC session keys derived by applying SP 800-135 SSH KDF. There are no encrypted SSPs that are directly entered.

As shown in Table 12 the keys are stored in the volatile memory (RAM) in plaintext form and are destroyed when released by the appropriate zeroization calls or when the system is rebooted. The static SSPs are persistently stored in plaintext in the module's non-volatile memory solid-state drive (SSD). The static SSPs remain on the system across power cycle. SSPs are only accessible to the authenticated operator, to which the SSPs are associated. © 2024 F5, Inc. / atsec information security.

The zeroization methods listed in Table 12, overwrites the memory occupied by keys with “zeros” or pre-defined values. The zeroization of temporary values are performed when they are no longer needed. The zeroization can be enforced by the crypto officer with the following services:

• Calling Reboot System service will clear the SSPs present in volatile memory RAM memory.
• For keys present in non-volatile memory, using Secure Erase service (which can only be triggered during reboot of the test platform) will perform a single pass zeroization erasing the entire module. © 2024 F5, Inc. / atsec information security.

The pre-operational self-test are performed automatically when the module is powered on. At initialization the module performed pre-operational self-test (integrity test) and the conditional cryptographic algorithm tests (CASTs). Services are not available during the pre-operational self-test and the data output interface is inhibited. On successful completion of the pre-operational self-tests and CASTs, the module enters the approved mode and cryptographic services are available. If the module fails any of the tests, the module returns an error code, and transitions to an the error state where any cryptographic operations are prohibited. Both the pre-operational tests and conditional tests are performed without operator intervention, without any external controls, externally provided test vectors, output results and the determination of pass of fail is done by the module. 10.1.1 Pre-operational Software/Firmware Integrity Test The integrity of the module is verified by comparing the HMAC-SHA-384 checksum values of the installed binaries calculated at run time with the stored values computed at build time. If the values do not match the module enters the error state (see Table 15). The HMAC-SHA-384 algorithm is self-tested prior to the integrity test being run.

10.2.1 Conditional Cryptographic Algorithm Tests The module performs cryptographic algorithm self-tests (CASTs) on all Approved cryptographic algorithms. The module performs the CASTs shown in Table 14 during power-up. The CASTs consist of Known Answer Tests for all the approved cryptographic © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Table 14

• Conditional Cryptographic Algorithm Self-Tests Conditional Pairwise Consistency Test A pairwise consistency test is run whenever asymmetric keys (RSA, EC Diffie-Hellman or ECDSA) are generated. PCT for ECDSA and RSA Key Pair Generation used for digital signatures is tested by the calculation and verification of a digital signature. PCT for Key Pair Generation EC Diffie-Hellman is covered by EC Diffie-Hellman PCT tested by the On demand self-tests are performed by rebooting the module. This service performs the available, and no data output or input is possible. The PCTs are executed on demand during the key generation functions invocation. In the error state, any data output or cryptographic operations are prohibited. The module must reboot or be re-loaded with a fresh image to clear the error condition. All data output and cryptographic operations are inhibited when the module is in an Error Table 15 - Error States © 2024 F5, Inc. / atsec information security.

The hardware platforms are shipped directly from the hardware manufacturer/authorized subcontractor via trusted carrier and tracked by that carrier. The hardware is shipped in a sealed box that includes a packing slip with a list of components inside, and with labels outside printed with the product nomenclature, sales order number, and product serial number. Upon receipt of the hardware, the customer is required to perform the following verifications:

• Ensure that the shipping label exactly identifies the correct customer’s name and address as well as the hardware model.
• Inspect the packaging for tampering or other issues.
• Ensure that the external labels match the expected delivery and the shipped product.
• Ensure that the components in the box match those on the documentation shipped with the product.
• Verify the hardware platform with the model number given on the shipping label and marked on the hardware platform itself.

The Crypto Officer should verify that the following specific configuration rules are followed in order to operate the module in the approved mode validated configuration. The ESV Public Use Document (PUD) reference for non-physical entropy source is as follows: https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropyvalidations/certificate/85. 11.2.1 Installing Tamper Evident Labels Before the hardware platform is installed in the production environment, tamper-evident labels must be installed in the location identified for each module in Section 7.1. The following steps should be taken when installing or replacing the tamper evident labels on the test platforms on which the module runs. The instructions are also included in F5 Platforms: FIPS Kit Installation provided with each hardware platform.

• Use the provided alcohol wipes to clean the chassis cover and components of dirt, grease, or oil before you apply the tamper evidence seals. After applying the seal, run your finger over the seal multiple times using extra high pressure. The seals completely cure within 48 hours. 11.2.2 Installing F5OS Follow the instructions in the "Initial Configuration" guide for the initial setup and configuration of the firmware module.
• Install the FIPS validated F5OS iso onto the device. Guidance on installing or upgrading the ISO can be found here: https://techdocs.f5.com/en-us/f5os-a-1-0-0/f5-rseries-systemsinstallation-upgrade/title-install-upgrade-software.html#install-upgrade-options). © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module

• Run the Setup wizard "appliance-setup-wizard" using the CLI with the CO account and default credentials. The system will prompt you to change the password.
• License the system from the WebUI. Guidance on Licensing the F5OS system can be found in https://techdocs.f5.com/en-us/hardware/f5-rseries-systems-getting-started/gs-systeminitial-config.html#run-setup-wizard) and summarized as followed: Before you can activate the license for the F5OS system, you must obtain a base registration key. The base registration key is pre-installed on new F5OS systems. When you power up the product and connect through the WebUI, you can open the SYSTEM SETTINGS > Licensing page to display the registration key. Select "Automatic" for the license Activation Method to communicate with the F5 License Server. The F5 product generates a dossier which is an encrypted list of key characteristics used to identify the platform and activates the license.
• After rebooting the F5OS system, it will then be in the approved mode of operation and is now ready for additional system configuration.
• Once the module is installed, licensed and configured, the Crypto Officer should confirm that the system is installed and licensed correctly. 11.2.2.1 Version Confirmation The Crypto Officer should call the show version service (with command "show system security fips-module" and "show system image"), then confirm that the provided version matches the validated module name and version (F5OS-A Cryptographic Module and Version 1.5.1). Any firmware loaded into the module other than version 1.5.1 is out of the scope of this validation and will mean that the module is not operating as a FIPS validated module. 11.2.2.2 License Confirmation The FIPS validated module activation requires installation of the license referred as ‘FIPS license’. The Crypto Officer should call the show license service (with command "show system licensing"), then verify that the list of license flags includes "FIPS 140 License”. 11.2.3 Additional Guidance The Crypto Officer should verify that the following specific configuration rules are followed to operate the module in the FIPS validated configuration.
• The integrity check must not be disabled. The CO can verify whether this is enabled by using the command "show system security integrity-check".
• Management of the module via the platform's LCD display is not allowed.
• Serial port console and USB port of the test platform on which the module executes should be disabled after the initial power on and communications setup of the hardware.

The approved and non-approved security functions available to users are listed in section 2, the physical ports, and logical interfaces available to users are specified in section 3. The Approved and non-Approved modes of operation are specified in section 2.3. The algorithm-specific information is listed in sub-section below. 11.3.1 AES GCM IV AES-GCM IV is constructed in accordance with SP800-38D in compliance with IG C.H scenario 1a. The implementation of the nonce_explicit management logic inside the module ensures that when the IV exhausts the maximum number of possible values for a © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module given session key, the module triggers a new handshake request to establish a new key. In case the module’s power is lost and then restored, the key used for the AES GCM encryption or decryption shall be re-distributed. The AES GCM IV generation follows [RFC 5288] and shall only be used for the TLS protocol version 1.2 to be compliant with [FIPS140-3_IG] IG C.H scenario 1a; thus, the module is compliant with [SP800-52r2] section 3.3.1. 11.3.2 RSA SigGen/SigVer All the modulus sizes supported by the module have been ACVP tested (per IG C.F). 11.3.3 Legacy Algorithms The use of SHA-1 within Digital Signature Verification is allowed for legacy use per SP800131Ar2 section 9. This may only be used on data that was generated prior to the Legacy Date specified in FIPS 140-3 IG C.M. © 2024 F5, Inc. / atsec information security.

The module does not implement security mechanisms to mitigate other attacks. © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Appendix A. Glossary and Abbreviations ADC AES API ACVP CAVP CBC CCM CFB CKG CLI CMAC CMVP CSP CTR DES DSA DRBG ECB ECC ECDSA ESV FIPS GCM GMAC HMAC IKE KAS KAT KDF KTS KW MAC NIST OFB PAA PUD PSS RNG RSA SHA SHS SNMP SSC SSD SSH SSP Application Delivery Controller Advanced Encryption Standard Application Programming Interface Automated Cryptographic Validation Protocol Cryptographic Algorithm Validation Program Cipher Block Chaining Counter with Cipher Block Chaining-Message Authentication Code Cipher Feedback Cryptographic Key Generation Command Line Interface Cipher-based Message Authentication Code Cryptographic Module Validation Program Critical Security Parameter Counter Mode Data Encryption Standard Digital Signature Algorithm Deterministic Random Bit Generator Electronic Code Book Elliptic Curve Cryptography Elliptic Curve Digital Signature Algorithm Entropy Source Validation Federal Information Processing Standards Publication Galois Counter Mode Galois Message Authentication Code Hash Message Authentication Code Internet Key Exchange Key Agreement Schema Known Answer Test Key Derivation Function Key Transport Scheme AES Key Wrap Message Authentication Code National Institute of Science and Technology Output Feedback Processor Algorithm Accelerators Public Use Document Probabilistic Signature Scheme Random Number Generator Rivest, Shamir, Adleman Secure Hash Algorithm Secure Hash Standard Simple Network Mail Protocol Shared-Secret Computation Solid State Drive Secure Shell Sensitive Security Parameter © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module TLS Triple-DES XTS Transport Layer Security Triple Data Encryption Standard XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-igannouncements FIPS180-4 Secure Hash Standard (SHS) March 2012 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf RFC 2313 PKCS #1: RSA Encryption Version 1.5 March 1998 https://datatracker.ietf.org/doc/html/rfc2313 RFC 5288 AES Galois Counter Mode (GCM) Cipher Suites for TLS August 2008 https://www.ietf.org/rfc/rfc5288.txt RFC 7627 Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension September 2015 https://www.ietf.org/rfc/rfc7627.txt SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf SP800-38B NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication May 2005 http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP800-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf © 2024 F5, Inc. / atsec information security.

F5OS-A Cryptographic Module SP800-38F NIST Special Publication 800-38F - Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping December 2012 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf SP800-52r2 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations August 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf SP800-56Ar3 NIST Special Publication 800-56A Revision 3 - Recommendation for Pair Wise Key Establishment Schemes Using Discrete Logarithm Cryptography April 2018 https://doi.org/10.6028/NIST.SP.800-56Ar3 SP800-90Ar1 NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 https://doi.org/10.6028/NIST.SP.800-90Ar1 SP800-90B NIST Special Publication 800-90B - Recommendation for the Entropy Sources Used for Random Bit Generation January 2018 https://doi.org/10.6028/NIST.SP.800-90B SP800-131Ar2 Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP800-133r2 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://doi.org/10.6028/NIST.SP.800-133r2 SP800-135r1 NIST Special Publication 800-135 Revision 1 - Recommendation for Existing Application-Specific Key Derivation Functions December 2011 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2024 F5, Inc. / atsec information security.

Referenced URLs

• www.atsec.com
• https://csrc.nist.gov/projects/cryptographic-module-validation-program/entropy-
• https://techdocs.f5.com/en-us/f5os-a-1-0-0/f5-rseries-systems-
• https://techdocs.f5.com/en-us/hardware/f5-rseries-systems-getting-started/gs-system-
• https://doi.org/10.6028/NIST.FIPS.140-3
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-3-ig-
• http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf
• http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
• http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
• https://datatracker.ietf.org/doc/html/rfc2313
• https://www.ietf.org/rfc/rfc5288.txt
• https://www.ietf.org/rfc/rfc7627.txt
• http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
• http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
• http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf
• https://doi.org/10.6028/NIST.SP.800-56Ar3
• https://doi.org/10.6028/NIST.SP.800-90Ar1
• https://doi.org/10.6028/NIST.SP.800-90B
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf
• https://doi.org/10.6028/NIST.SP.800-133r2
• http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-135r1.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf