Device Cryptographic Module

Certificate

Approved Algorithms (52)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Device 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>16.1.3.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 Device 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>16.1.3.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. Device Cryptographic Module Hardware Versions: BIG-IP i4600, BIG-IP i4800, BIG-IP i5600, BIG-IP i5800, BIG-IP i5820-DF, BIG-IP i7600, BIG-IP i7800, BIG-IP i7820-DF, BIG-IP i10600, BIG-IP i10800, BIG-IP i11600-DS, BIG-IP i11800-DS, BIG-IP i15600, BIG-IP i15800, BIG-IP i15820-DF, VIPRION B2250, VIPRION B4450 with FIPS Kit P/N: F5-ADD-BIG-FIPS140 Firmware Version: 16.1.3.1 FIPS Security Level 2 Last update: July 2024 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com

Device Cryptographic Module Table of Contents

2.4.2 Non-Approved, Allowed Algorithms and Non-Approved, Allowed Algorithms with No

© 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Appendix A. Appendix B. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Figure 12

• Tamper labels on BIG-IP i10800, BIG-IP i10600, BIG-IP i11600-DS, BIG-IP i11800-DS .. 32 © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module F5®, BIG-IP®, TMOS®, are registered trademarks of F5, Inc. Intel® 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 Device Cryptographic Module with firmware version 16.1.3.1 and hardware versions listed in Table 2 below. 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 Publication 140-3) for a Security Level 2 module. This document provides all tables and diagrams (when applicable) required by NIST SP 800-140B. The following describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. N/A N/A N/A Table 1 - Security Levels © 2024 F5, Inc. / atsec information security.

The Device Cryptographic Module (hereafter referred to as “the module”) is a Hardware cryptographic module with multiple-chip standalone embodiment. The module is a smart evolution of Application Delivery Controller (ADC) technology. Solutions built on this platform are load balancers. They are full proxies that give visibility into, and the power to control—inspect and encrypt or decrypt—all the traffic that passes through your network. Underlying all BIG-IP hardware and software is F5’s proprietary operating system, TMOS, which provides unified intelligence, flexibility, and programmability. With its application control plane architecture, TMOS gives you control over the acceleration, security, and availability services your applications require. TMOS establishes a virtual, unified pool of highly scalable, resilient, and reusable services that can dynamically adapt to the changing conditions in data centers and virtual and cloud infrastructures.

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

Device Cryptographic Module # i11600DS i11800DS i15820DF Table 2 - Cryptographic Module Tested Configuration © 2024 F5, Inc. / atsec information security.

The module supports two modes of operation:

• Approved mode of operation: Only approved or vendor affirmed security functions can be used. Non-Approved mode of operation: Only non-approved security functions can be used. The module enters operational mode after pre-operational self-tests 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. The Control (or Management) Plane refers to the connection from an administrator to the BIG-IP for system management. The Data Plane refers to the traffic passed between external entities and internal servers. Not all the ACVP tested capabilities are used by the module in approved mode of operation.

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

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

Device Cryptographic Module N/A Table 3 - Approved Algorithms

2.4.2 Non-Approved, Allowed Algorithms and Non-Approved, Allowed Algorithms with No

Security Claimed The module does not implement any non-approved algorithms allowed in the approved mode of operation with or without security claimed.

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.

The following table lists the non-FIPS Approved algorithms along with their usage.

2 The AES-XTS mode shall only be used for the cryptographic protection of data on storage devices

and shall not be used for other purposes such as the encryption of data in transit. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

Figure 1 - BIG-IP i4600 and BIG-IP i4800 Figure 2 - BIG-IP i5600, BIG-IP i5800 and BIG-IP i5820-DF Figure 3

• BIG-IP i7600, BIG-IP i7800 and BIG-IP i7820-DF © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Figure 4 - BIG-IP i10600, BIG-IP i10800 and BIG-IP i11600-DS, BIG-IP i11800-DS Figure 5

• BIG-IP i15600, BIG-IP i15800, BIG-IP i15820-DF Figure 6 - B2250 blade mounted in VIPRION chassis C2400 with three blanks Figure 7 - B4450 blade mounted in VIPRION chassis 4480 with three blanks © 2024 F5, Inc. / atsec information security.

The cryptographic boundary of the module is defined by the exterior surface of the appliance (red dotted line in Figure 8). The block diagram below shows the module, its interfaces and the delimitation of its cryptographic boundary. Figure 8 also depicts the flow of status output (SO), control input (CI), data input (DI) and data output (DO). Description of the ports and interfaces can be found in Table 5. - PI SSL Accelerator Power Interface (PSU) Central Processing Unit (CPU) Memory Interface (RAM) Storage Interface (SSD/ HDD) Network Interface (Ethernet, Fiber) Display Interface (LED) - DO - SO - DI - DO - SO - CI Figure 8 - Hardware 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 data input, data The physical ports mapping to the logical interfaces and the flow of data passing over them are described in the Table 5. 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 of the module (administrator" is the CO). This entity performs module installation and initialization. This role has full access to the system and has the ability to create, delete, and manage other User roles on the system. At initialization of the module, the CO is the only available role. Only the CO can create the user roles. The FIPS140-3 User role is mapped to multiple module roles: Auditor, Certificate Manager, Firewall Manager, iRule Manager, Operator, Resource Manager and User Manager. Each of the module roles are responsible for different components of the system (e.g. auditing, certificate and key management, user management, etc.). The list of services available to the CO and user roles are defined in Table 8 and Table 9. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Create SSHkeyswap Delete SSHkeyswap N/A N/A N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 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 can be used to access the module:

• Command Line Interface (CLI): The module offers a CLI called traffic management shell (tmsh) which is accessed remotely using the SSHv2 secured session over the Ethernet connection. Web Interface (WebUI): The Web interface consists of HTTPS over TLS-enabled web browser which provides a graphical interface for system management tools. The User role can access the module through CLI or WebUI. However, the CO can restrict User role access to have the User accessing through WebUI 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 Web interface, 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). Table 7 lists the required role-based authentication method for the Crypto Office role and the User role depending upon which interface is being used. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 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 service indicator is returned in the high speed login /var/log remote.log file. The output 'Service Indicator: Approved' or the 'Service Indicator: Not Approved' are listed in Table 8. 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. The following variables are used in the Access rights to keys or SSPs column:

• 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. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 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 N/A W W N/A N/A E G W, E N/A N/A N/A E Z N/A © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module N/A N/A N/A N/A W R G N/A N/A E W, 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 N/A N/A N/A N/A N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

N/A N/A 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 N/A N/A N/A Z N/A Z W W G W, E N/A N/A N/A E © 2024 F5, Inc. / atsec information security.

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

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

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

The integrity of the module using the approved integrity technique HMAC-SHA2-384 is listed in the section 10.1.1 below. 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 powering the module off and powering it on again.

The executable code is defined by the firmware version 16.1.3.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 called TMOS 16.1.3.1. The module is a hardware validated at a Security Level 2 in Physical Security. Once the module is operational, it does not allow the loading of any additional firmware. There are no further requirements for this security area. © 2024 F5, Inc. / atsec information security.

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 internal components. 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 for the module to operate in approved mode of operation. The Crypto Officer is responsible for inspecting the quality of the tamper labels on a regular basis to confirm that the module has not been tampered with. In the event that the tamper evident labels require replacement, a kit providing 25 tamper labels is available for purchase (P/N: F5-ADD-BIG-FIPS140). The Crypto Officer shall be responsible for the 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 hardware appliance. Label application instructions are provided in Section 11.2.1 of the Crypto-Officer guidance below. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module VIPRION B4450 Figure 4: per evof ident holographic labels w it h ize

5cm Table 11Fiv– e t am Number Tamper Evident Labels per hardware appliance Figures below show t he placem ent of t he t am per evident labels on each of t he t est plat form s. Tam perare Labels are boxed red. circles in the pictures below. The tamper labels delineated withinorange i4000 series front zzzzzz z La b e l 1 La b e l 8 La b e l 2 La be l 6 La b e l 3 La b e l 4 La b e l 5 i4000 series back Figure 5

• Top v iew of i14000 series (BIG-IP i4 600 and BIG-IP i4 800 t est plat form s) w it h 8 / 8 t am per labels show n. Figure 9 - Tamper labels on BIG-IP i4600 and BIG-IP i4800 (8 / 8 tamper labels) CON FI D EN TI AL © 2024 at sec inform at ion securit y corporat ion © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module i5000 series front Label 1 Front Label 7 Label 2 Label 2 Label 6 Label 1 Label 3 Label 3 Label 2 Label 5 i5000 series back Label 4 Figure i5000labels series on (BIG-IP i5 600, BIG-IP i5 800 BIG-IP i5

est plat form s) w it h per labels show n. Figure6

• 10Top
• v iew Tamper BIG-IP i5600, BIG-IPand i5800 and BIG-IP i5820-DF (77 // 7

tamper labels) i7000 series front Label 1 Label 8 Label 2 Label 3 Label 4 Label 7 i7000 series back Label 5 Label 6 Label 3 Label 2 i11000 i11000 Figure 7

• Iso v iew i7000 series (BIG-IP i7 600, BIG-IP i7800 and BIG-IP i7820-DF). Label posit ions: on t he front side of t he plat form s -label 1-. On t he opposit e lat eral sides of t he plat form -labels On t he vent ilat ion fan t ray t hat allow s access CON EN TI AL 2,3 ,7,8 . security. © 2024 F5, Inc.FI /D atsec information t
• SSD -label 4. On t he replaceable PSUs -labels 5,6. © 2024 at secand inform at iononly securit corporat ion This document can be reproduced distributed wholey and intact, including

i7000 series back Device Cryptographic Module Label 5 Label 6 Label position is as Figure 11

• Tamper labels on BIG-IP i7600, BIG-IP i7800 and BIG-IP i7820-DF. follows: on the front side of the platform -label 1-; on the opposite lateral sides of the platform labels 2,3,7,8; on the ventilation fan tray that allows access to SSD -label 4. On the replaceable i7000 series (BIG-IP i7 600 , BIG-IP i7 800 and BIG-IP i7 820-DF). Label posit ions: on t he front side of t h e Iso v iew Figur PSUse 7
• -labels 5,6. a d i11000

i1 se ries fr ont a d i11000

i1 b ck se ries a plat form s -label 1-. On t he opposit e lat eral sides of t he plat form -labels 2,3 ,7 ,8. On t he v ent ilat ion fan t ray t hat allow s access t

• SSD -label 4. On t he replaceable PSUs -labels 5,6. Label 2 Label 3 Label 4 Label 1 Label 5 Label 7 Label 6 t est(7 / BIG-IP i11600-DS i1 1600-DS,BIG-IP and BIG-IP i1 0600BIG-IP BIG-IP (BIG-IP i1 0800, series i10800, and i11000 v iew i10000
• Top e 8 12 Figur Figure
• Tamper labels on BIG-IP BIG-IP i10600, i11600-DS, i11800-DS n. show labels per am t /7 h it w s) form plat

CON FI D EN TI AL © 2024 at sec inform at ion securit y corporat ion © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module i15000 series front Label 2 Label 1 Label 1 Label 2 i15000 series Label

Label 3 Label 7 Label 3 i15000 series back Label 6 i15000 series back Label 6 Label 4 Label 5 Label

4 i1 5800, BIG-IP i1 5820 -DF t est plat form s). 1 label on t he front , 4 labels

Figure 9 - Top v iew i15000series (BIG-IP i1 5600, BIG-IP Figure 13per

• labels Tamper labels oninBIG-IP i15600, BIG-IP i15800, andhorized BIG-IPrem ov al i15820-DF. label on the on t he sides,

show n circled orange t o m ark w it h ev idence t he unaut of t he 1 fan t ray and PSUs (replaceable s) t h at giv replaceable st orage drives.circled in orange to mark with evidence the front, 4 it em labels on thee access sides, t o2 tamper labels Label

unauthorized removal of the fan tray and PSUs (replaceable items) that give access to Figure 9 - Top view i15000series (BIG-IP i1 5600, BIG-IP i1 5800, BIG-IP i1 5820-DF t est plat form s). 1 label on t he front , 4 labels replaceable storage drives. on t he sides, 2 t am per labels show n circled in orange t o m ark w it h evidence t he unaut horized rem oval of t he fan t ray and PSUs (replaceable it em s) t hat give access t o replaceable st orage drives. Figure 10

• VIPRION B2250 t est plat form (delineat ed by a red box ) m ount ed in chassis w it h 1 of 1 t am per label show n Figure

VIPRION B2250 t est plat form (delineat ed box) m ount ed in chassis w it h 1 of 1 t amaper label show n Figure

Tamper labels on chassis withby a red VIPRION B2250 blade (delineated by red box) and three blanks (1 of 1 tamper label shown) CON FI D EN TI AL © 2024 F5, Inc. / atsec information security. © 2024 at sec inform at ion securit y corporat ion

CON FI D EN TI AL © 2024 at sec inform at ion securit y corporat ion

Device Cryptographic Module Figur e 11 -15

• VIPRION B4450labels blade mon ount ed in chassis h ree blanks and 2 / 2 t am per labels show Figure Tamper chassis withw it h t VIPRION B4450 blade (delineated by na red box) and three banks (2 of 2 tamper labels shown)

The t est lab used various m et hods t o m odify t he adhesion label propert ies by t est ing a range of t em perat ures around t he am bient (20C)

• using com m ercial heat gun (~ 120C) and elect ronic freeze spray (-50C) - and using chem icals (i.e. isopropyl alcohol and a m ixt ure of sodium hydroxide and oil i.e. soap) at room t em perat ure. Each t herm al or chem ical t reat m ent was applied for approxim at ely 15 m inut es. The t est er t hen at t em pt ed t o rem ove t he label using t he hand t ools (t weezers, needle-nose pliers, and X-Act o precision knives) following t he t herm al and chem ical t reat m ent or even using m echanical force alone.

Below is phot ographic evidence from t he t est ing perform ed on all of t he t est plat form s list ed in sect ion 1.1.

Ap ply ing high t em perat ure by heat gun on t he labels placed at t he enclosure t op-bot t om connect ion. The label is delam inat ed due t o t he heat . Under t his t reat m ent , t he m et alic layer of t h e label could be disolved. CON FI D EN TI AL © 2024 F5, Inc. / atsec information security. © 2024 at sec inform at ion securit y corporat ion

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

112bits to 150bits N/A 112bits to 150bits N/A A 128bits 192bits N/A A 128bits 192bits SP800133Rev2 SP800133Rev2 SP800133Rev2 SP800133Rev2 N/A

4 The " Import/Export" column also 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.

Device Cryptographic Module 128bits 192bits KASECCSSC 128bits 192bits KASECCSSC 150bits KASFFCSSC 150bits KASFFCSSC SP800133Rev2 SP800133Rev2 SP80056Arev3; SP80056Arev3; N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module preprima t t C) A A DiffieHellm 150bits DiffieHellm 128bits 192bits 256bits KASECCSSC or KASFFCSSC N/A SP80056ARev3 DiffieHellman DiffieHellman N/A 256bits 256bits ) 192bits N/A N/A delete sshkeyswap 192bits SP800133Rev2 SP800133Rev2 N/A delete sshkeyswap © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 192bits KASECCSSC 192bits KASECCSSC d t 192bits KASECCSSC C) 256bits 256bits ) SP800133Rev2 SP800133Rev2 N/A N/A N/A SP80056ARev3 KAS-ECCSSC N/A © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 7) N/A N/A 256bits 384bits (V s) N/A e N/A N/A N/A N/A © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module Table 12 - SSPs The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90ARev1] 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 with full entropy. 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 generation services compliant with [FIPS186-4], using a [SP800-90ARev1] DRBG. In accordance with FIPS 140-3 IG D.H, the cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per [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 and DH key pairs 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 actually maps to [FIPS 186-4]. and 5.6.1.1 FFC Key Pair Generation. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module 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] 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-56A Rev3 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.
• Diffie-Hellman key agreement scheme compliant with SP800-56A Rev3 and FIPS 140-3 IG D.F scenario 2 (path 2) is used as part of the TLS Protocols. The full Diffie-Hellman KAS implements a shared secret computation with the key derivation implemented by [SP 800135] TLS KDFs. Diffie-Hellman key agreement provides between 112 and 150-bits of encryption strength.
• [SP 800-38F], IG D.G key wrapping in the context of TLS protocol where a key may be within a packet or message that is encrypted and authenticated using:
• An approved authenticated encryption mode (i.e. AES-GCM, AES-CCM) provides 128 or 256 bits of encryption strength (AES Certs. #A2594 and # A2671). A combination method which includes an approved AES encryption and an approved HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Certs. #A2594 and # A2671). [SP 800-38F], IG D.G key wrapping in the context of SSH protocol where a key may be within a packet or message that is encrypted and authenticated using:
• A combination method which includes an approved AES-CBC or AES-CTR encryption mode and an approved HMAC authentication method provides 128 or 256 bits of encryption strength (AES and HMAC Cert. # A2594).

For TLS with EC Diffie-Hellman / 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/ AES-CCM or 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 and User role 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. © 2024 F5, Inc. / atsec information security.

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 SSPs stored in plaintext in the module's non-volatile memory (SSD/ HDD) are static and will remain on the system across power cycle. SSPs are only accessible to the authenticated operator, to which the SSPs are associated.

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 at the closing of the TLS/SSH connection. The zeroization can be enforced by the Crypto Officer and Resource Manager role with the following services:

• Using the Delete SSH-keyswap service will perform the destruction of the selected SSH ECDSA authentication key. 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. Using Secure Erase service (which can only be triggered during reboot of the device) will perform a single pass zeroization erasing the HDD or SSD contents and the module itself. © 2024 F5, Inc. / atsec information security.

The pre-operational self-test are performed automatically whenever the module is powered on. At initialization the module performed the pre-operational self-tests (the integrity test) and the conditional cryptographic algorithm tests (CASTs). 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. 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, the module enters operational mode and cryptographic services are available. If the module fails any of the tests, it will return an error code and enter into the error state to prohibit any further cryptographic operations.

The integrity of the module is verified by comparing the HMAC-SHA2-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 system enters the error state and the device will not be accessible. Data output and cryptographic operations are inhibited while the module is in the error state. In order to recover from this state, the module needs to be reinstalled. The HMAC-SHA384 algorithm is selftested prior to the integrity test being run.

The following sub-sections describe the conditional self-tests supported by the module. The conditional self-tests are specified in Table 14. If one of the conditional self-tests fails, the module transitions to the error state and a corresponding error indication is given. The module becomes inoperable, and no services are available. Data output and cryptographic operations are inhibited while the module is in the error State. runtime. If the entropy source health tests fail, then the module moves into the error state.

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

Device Cryptographic Module Table 14

• Conditional Cryptographic Algorithm Self-Tests © 2024 F5, Inc. / atsec information security.

A pairwise consistency test is run whenever asymmetric keys (RSA, Diffie-Hellman, EC DiffieHellman or ECDSA) are generated. PCT for ECDSA (Control and Data planes) and RSA (Control Plane) Key Pair Generation used for digital signatures is tested by the calculation and verification of a digital signature. PCT for Diffie-Hellman (Control and Data planes) Key Pair Generation is performed following the SP 800-56Arev3 requirements. PCT for EC Diffie-Hellman (Control Plane) Key Pair Generation is covered by ECDSA PCT (IG 10.3.A). PCTs for EC Diffie-Hellman (Data Plane) Key Pair Generation is performed following the SP 800-56Arev3 section 5.6.2.1.4 requirements.

On demand and periodic self-tests are performed by powering off the module and powering it on again. This service performs the same cryptographic algorithm tests executed during preoperational self-tests and CASTs. During the execution of the periodic and on-demand self-tests, crypto services are not available and no data output or input is possible.

Table 15 - Error States In any of the error states, any data output or cryptographic operations are prohibited. The module must reboot to 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 state. © 2024 F5, Inc. / atsec information security.

The module is distributed as a part of a BIG-IP product which includes the hardware and an installed copy of firmware with version 16.1.3.1. The hardware devices 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 model with the model number given on the shipping label and marked on the hardware device itself.

The Crypto Officer should verify that the following specific configuration rules are followed in order to operate the module in the approved 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/16

Before the device is installed in the production environment, tamper-evident labels must be installed in the location identified for each module in Section 7.2. The following steps should be taken when installing or replacing the tamper evident labels on the module. The instructions are also included in F5 Platforms: FIPS Kit Installation provided with each module.

• 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 24 hours. It is the responsibility of the Crypto Officer to inspect the tamper evident labels for damage or any missing labels as specified in Section 7.

Follow the instructions in the "BIG-IP System: Initial Configuration" guide for the initial setup and configuration of the 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. Installing the FIPS license for the host system is required for module activation. Guidance on Licensing the BIG-IP system can be found in https://support.f5.com/csp/article/K7752 and summarized as followed: Before you can activate the license for the BIG-IP system, you must obtain a base registration key. The © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module

• base registration key is pre-installed on new BIG-IP systems. When you power up the product and connect to the Configuration utility, the Licensing page opens and displays the registration key. After a license activation method is selected (activation method specifies how you want the system 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. If the automated activation method is selected, the BIG-IP system automatically connects to the F5 License Server and activates the license. If the manual method is selected, the Crypto Officer shall go to the F5 Product Licensing page at secure.f5.com, paste the dossier in the “Enter Your Dossier” box which produces a license. The Crypto Officer will then copy and paste it into the “License” box in the Configuration Utility. The BIG-IP system then reloads the configuration and is ready for additional system configuration. Once the device is installed, licensed and configured, the Crypto Officer should confirm that the system is installed and licensed correctly.

The Crypto Officer should call the show version service (with command "tmsh show sys version" and "tmsh show sys hardware"), then confirm that the provided firmware and hardware versions matches the validated versions shown in Table 2. Any firmware loaded into the module other than version 16.1.3.1 is out of the scope of this validation and will mean that the module is not operating as a FIPS validated module.

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 "tmsh show sys license"), then verify that the list of license flags includes "FIPS 140-3”.

The Crypto Officer should verify that the following specific configuration rules are followed in order to operate the module in the FIPS validated configuration.

• All command shells other than tmsh are not allowed. For example, bash and other userserviceable shells are excluded. Management of the module via the appliance's LCD display is not allowed. Usage of f5-rest-node and iAppLX and provisioning of iRulesLX is not allowed. Only the provisioning of AFM and LTM is included. Remote access to the Lights Out / Always On Management capabilities of the system are not allowed. Serial port console and USB port should be disabled after the initial power on and communications setup of the hardware. On the i11800-DS device, the Cavium Nitrox-V must be disabled using the following command since full support is not available: # lspci | grep -i encryption | awk '{print "device exclude " $1;}' > /config/tmm_init.tcl # bigstart restart tmm
• Use of command run util fips-util -f init is not allowed. Running this command followed by a System Reboot service or restart will mean that the module is not operating as a FIPS validated module. The Single Diffie-Hellman should be turned ON for the platform GUI. The server ssl profile shall be configured with "cert none" and "key none" option that disables client authentication. © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module

• All the RSA keys in "PubkeyAcceptedKeyTypes" section of the sshd_config file shall be deleted. The command "service sshd restart" updates the sshd_config file.

The module supports two modes of operation, Approved mode and non-Approved mode. The following two tables define which services are available in each mode: Table 8 - Approved Services and Table 9 - Non-Approved Services. Using the non-approved algorithms found in Table 4 - NonApproved Algorithms Not Allowed in the Approved Mode of Operation, means that the module operates in non- Approved mode for the particular session of a particular service.

The User shall consider the following requirements and restrictions when using the module. AESGCM IV is constructed in accordance with SP800-38D in compliance with IG C.H scenario 1. 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 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 1; thus, the module is compliant with [SP800-52 Rev2] section 3.3.1.

All the modulus sizes supported by the module have been ACVP tested (per IG C.F). © 2024 F5, Inc. / atsec information security.

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

Device Cryptographic Module Appendix A. Glossary and Abbreviations AES AES-NI Advanced Encryption Standard Advanced Encryption Standard New Instructions CAVP CBC CCM CFB Cryptographic Algorithm Validation Program Cipher Block Chaining Counter with Cipher Block Chaining-Message Authentication Code Cipher Feedback CMAC CMVP CSP Cipher-based Message Authentication Code Cryptographic Module Validation Program Critical Security Parameter CTR DES DSA Counter Mode Data Encryption Standard Digital Signature Algorithm DRBG ECB ECC ESV Deterministic Random Bit Generator Electronic Code Book Elliptic Curve Cryptography Entropy Source Validation FFC FIPS GCM Finite Field Cryptography Federal Information Processing Standards Publication Galois Counter Mode HMAC KAS KAT Hash Message Authentication Code Key Agreement Schema Known Answer Test KW KWP MAC AES Key Wrap AES Key Wrap with Padding Message Authentication Code NDF NIST OFB PR No Derivation Function National Institute of Science and Technology Output Feedback Prediction Resistance PSS RNG RSA Probabilistic Signature Scheme Random Number Generator Rivest, Shamir, Addleman SHA SHS SSH Secure Hash Algorithm Secure Hash Standard Secure Shell TDES XTS Triple-DES XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 F5, Inc. / atsec information security.

Device 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 March 2023 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 PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 http://www.ietf.org/rfc/rfc3447.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 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-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 © 2024 F5, Inc. / atsec information security.

Device Cryptographic Module SP800-90A 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-133 NIST Special Publication 800-133 Revision 2 - Recommendation for Cryptographic Key Generation June 2020 https://doi.org/10.6028/NIST.SP.800-133r2 SP800-135 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://support.f5.com/csp/article/K7752
• 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
• http://www.ietf.org/rfc/rfc3447.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://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://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