Cryptographic Module for BIG-IP ®

Certificate

Approved Algorithms (31)

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

flowchart LR
  %% Deterministic review-risk graph for Cryptographic Module for BIG-IP ®
  %% 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</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Status Output<br/>Show status<br/>Self-Test</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</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 Cryptographic Module for BIG-IP ®
  %% 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</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Status Output<br/>Show status<br/>Self-Test</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>HTTPS<br/>library named: openssl</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<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 C2,C3,C5,C6 clueLow;

Security Policy, page by page

F5, Inc. Cryptographic Module for BIG-IP(R) version 1.0.2u-fips document version 1.1 Last update: June 2024 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 www.atsec.com

F5® and BIG-IP® are registered trademarks of F5, Inc. VMware ESXi™ is a registered trademark of VMware ®, Inc. Intel® Xeon® is a registered trademark of Intel® Corporation. Dell is a registered trademark of Dell, Inc. Azure and Hyper-V are registered trademarks of Microsoft AWS is a trademark of Amazon.com, Inc. © 2024 F5, Inc. / atsec information security.

3 of 41

This document is the non-proprietary FIPS 140-3 Security Policy for version 1.0.2u-fips of the Cryptographic Module for BIG-IP. It contains the security rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an Overall Security Level 1 Table 1 - Security Levels © 2024 F5, Inc. / atsec information security.

4 of 41

The Cryptographic Module for BIG-IP (hereafter referred to as “the module”) is a software library implementing general purpose cryptographic algorithms. The module is a multiple-chip standalone cryptographic module. The software module provides cryptographic services to applications through an Application Program Interface (API). The module also interacts with the underlying operating system via system calls.

The module has been tested on the following platforms with the corresponding module variants and configuration options with and without PAA: Table 2 - Tested Operational Environments In addition to the configurations tested by the atsec CST laboratory, vendor-affirmed testing was performed on the following platforms for the module by F5, Inc. Table 3 - Vendor Affirmed Operational Environments Note: The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. © 2024 F5, Inc. / atsec information security.

5 of 41

The module supports two modes of operation:

• The Approved mode of operation where only approved or vendor affirmed functions can be used as specified in Table 4.
• The non-Approved mode of operation where only non-approved security functions can be used (Table 5). The module becomes operational and enters the approved mode after pre-operational self-tests succeed. No operator intervention is required to reach this point. Once the module is operational, the mode of operation is implicitly assumed depending on the security function invoked and the security strength of the cryptographic keys. Using any non-approved algorithms from Table 5 will put the module in non-approved mode implicitly.

The table below lists all security functions of the module, including specific key size(s) employed for approved or vendor-affirmed security functions, and implemented modes of operation.

1 There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service

of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. © 2024 F5, Inc. / atsec information security.

6 of 41

© 2024 F5, Inc. / atsec information security.

7 of 41

Algorithm/Functions

Use/Function

Table 4 - Approved Algorithms The module does not implement any non-Approved but Allowed algorithm in Approved mode of operation with no security claimed. The module does not implement any Non-Approved Algorithms Allowed in the Approved Mode of Operation. The table below lists Non-Approved security functions that are not Allowed in the Approved Mode of Operation. © 2024 F5, Inc. / atsec information security.

8 of 41

© 2024 F5, Inc. / atsec information security.

9 of 41

Table 5 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

The software block diagram below shows the module, its interfaces with the operational environment and the delimitation of its cryptographic boundary with red lines. Figure 1

• Software Block Diagram The module is implemented as a shared library. The cryptographic module boundary consists of two components:
• the shared library, the binary for cryptographic implementations (libcrypto.so.1.0.2u) and © 2024 F5, Inc. / atsec information security.

10 of 41

• the file that holds the pre-computed integrity check value (.libcrypto.so.1.0.2u.hmac). The module is aimed to run on a general-purpose computer; the physical perimeter is the surface of the case of the target platform, as shown with orange dotted lines in the diagram below: Figure 2
• Cryptographic Module Physical Perimeter © 2024 F5, Inc. / atsec information security.

11 of 41

The logical interfaces are the API through which the applications request services. The following table summarizes the logical interfaces: Table 6 - Ports and Interfaces Cryptographic bypass capability is not supported by the module. The module does not implement © 2024 F5, Inc. / atsec information security.

12 of 41

The module supports the Crypto Officer role only. No support is provided for multiple concurrent operators or a Maintenance Operator.

Table below describes the authorized role(s) in which the service can be performed with specification of the service input parameters and associated service output parameters. © 2024 F5, Inc. / atsec information security.

13 of 41

FIPS 140-3 does not require an authentication mechanism for level 1 modules. Therefore, the module does not implement an authentication mechanism for Crypto Officer. The Crypto Officer role is authorized to access all services provided by the module (see Table - Approved Services and Table - Non-Approved Services below).

The table below lists all approved services that can be used in the approved mode of operation. The status output from the FIPS_set_indicator_status service indicator's call is provided in Indicator column in Table 8. To read this indicator, the calling application must register a callback function using `FIPS_register_indicator_callback'. The callback function shall take the input of the form "char *" which is the form of the indicator being output by the module. © 2024 F5, Inc. / atsec information security.

14 of 41

D.G © 2024 F5, Inc. / atsec information security.

15 of 41

© 2024 F5, Inc. / atsec information security.

16 of 41

Table 8 - Approved Services G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). © 2024 F5, Inc. / atsec information security.

17 of 41

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. The table below lists all non-Approved services that can only be used in the non-Approved mode of operation. © 2024 F5, Inc. / atsec information security.

18 of 41

Service RSA encryption and decryption Domain parameter generation Domain parameter verification DSA key pair generation DSA signature generation DSA signature verification Random number generation Diffie-Hellman shared secret computation EC Diffie-Hellman shared secret computation

Description Encryption/ decryption Generating domain parameters Verifying domain parameters Generating key pair Generating signature Verifying signature Generating deterministic random number Calculating shared secret

Algorithms Accessed RSA with modulus sizes up to 16384 bits DSA HMAC_DRBG and Hash_DRBG for all SHA sizes CTR_DRBG with AES-128 or AES-192 ANSI X9.31 RNG Diffie-Hellman key agreement with groups other than ffdhe2048, ffdhe3072, ffdhe4096 EC Diffie-Hellman Ephemeral without KDF Unified with curves other than P-256, P- 384 EC Diffie-Hellman without KDF one PassDh and StaticUnified

Role

Indic ator None None None None None None

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

19 of 41

The integrity of the module is verified by comparing a HMAC value calculated at run time on the libcrypto.so.1.0.2u file, with the HMAC-SHA2-256 value stored in the module file .libcrypto.so.1.0.2u.hmac that was computed at build time. Integrity tests are performed as part of the Pre-Operational Self-Tests.

The on-demand integrity test is performed as part of the Pre-Operational Self-Tests by powercycling the module. © 2024 F5, Inc. / atsec information security.

20 of 41

The module operates in a modifiable operational environment. The module runs on a BIG-IP

16.1.3.1 operating system executing on the hardware and hypervisor specified in section 2.2. BIG-

IP consists of a Linux based operating system customized for performance that runs directly on the hardware or in virtual environment.

The module should be installed as stated in section 11. The operator should confirm that the module is installed correctly by sub-section 11.2. © 2024 F5, Inc. / atsec information security.

21 of 41

The module is comprised of software only and therefore this section is Not Applicable (N/A). © 2024 F5, Inc. / atsec information security.

22 of 41

Currently the non-invasive Security is not required by FIPS 140-3 (see NIST SP 800-140F). © 2024 F5, Inc. / atsec information security.

23 of 41

© 2024 F5, Inc. / atsec information security.

24 of 41

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

25 of 41

© 2024 F5, Inc. / atsec information security.

26 of 41

© 2024 F5, Inc. / atsec information security.

27 of 41

© 2024 F5, Inc. / atsec information security.

28 of 41

Key/ SSP Name/ Type (IG D.L) /CSP

Strength

S ecurity Function and Cert. Number

Generation

Import /Export phic boundary No Export

Establis hment

Storage

Zeroizati on

Use and related keys Related keys: DRBG seed (V and Key values), RSA private key, RSA public key, ECDSA private key, ECDSA public key, EC Diffie- Hellman private key, EC Diffie- Hellman public key, Diffie- Hellman private key, Diffie- Hellman public key

The module employs a Deterministic Random Bit Generator (DRBG) based on [SP800-90ARev1] for the generation of random value used in asymmetric keys, and for providing a RNG service to calling applications. The Approved DRBG provided by the module is the Counter DRBG with AES256. The module uses the Entropy source specified in Table 11 to seed the DRBG. 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 1. Table 11 - Non-Deterministic Random Number Generation Specification © 2024 F5, Inc. / atsec information security.

29 of 41

The module generates SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per section 4 [SP800133Rev2] (vendor affirmed), using DRBG compliant with [SP800-90ARev1]. A seed (i.e., the random value) used in asymmetric key generation is a direct output from [SP800-90ARev1] Counter DRBG. The following methods are implemented:

• RSA KeyGen (FIPS186-4), according to Appendix B.3.3 of FIPS 186-4, compliant with SP800133r2, Section 5.1: generates 2048, 3072 and 4096-bit keys with 112-150 bits of strength.
• ECDSA KeyGen (FIPS186-4), according to Appendix B.4.2 of FIPS 186-4, compliant with SP800-133r2, Section 5.1 and Section 5.2: P-256 and P-384 curves with 128 and 192 bits of key strength. Note that this generation method is also used to generate ECDH key pairs.
• Safe Primes Key Generation (SP80056Ar3): according to Section 5.6.1.1 of SP800-56Ar3, compliant with SP800-133r2, Section 5.2: Safe Prime Groups: ffdhe2048, ffdhe3072, ffdhe4096 with 112-150 bits of strength. The key generation services for RSA, Diffie-Hellman, EC Diffie-Hellman and ECDSA key pairs as well as the [SP 800-90ARev1] DRBG have been CAVP tested with certificates found in Table 4. The module does not implement symmetric key generation.

The module does not support manual SSP entry or intermediate key generation output. The module does not support entry and output of SSPs beyond the physical perimeter of the operational environment. The SSPs can be provided to the module in plaintext form via API parameters, to and from the calling application running on the same operational environment. This is allowed by [FIPS 140-3_IG] IG 9.5.A Table 1, according to the “CM Software to/from App via TOEPP Path” entry which refers to keys communicated within the physical perimeter of the GPC.

The module provides:

• KAS-FFC-SSC, SP800-56Ar3 The module implements Diffie-Hellman shared secret computation, compliant with SP800-56ARev3 and scenario 2 (path 1) only of IG D.F. The shared secret computation with groups ffdhe2048, ffdhe3072, ffdhe4096, SSP establishment methodology, provides between 112 and 150 bits of strength.
• KAS-ECC-SSC, SP800-56Ar3 The module implements EC Diffie-Hellman shared secret computation, compliant with SP80056ARev3 and scenario 2 (path 1) only of IG D.F. The shared secret computation with curves P-256 or P-384, SSP establishment methodology, provides 128 or 192 bits of strength.
• AES-GCM Key Wrapping (KTS) The module also provides key wrapping is used in the context of using TLS protocol implemented outside of the module boundary to send and receive key material in the payload. The key wrapping methods are provided by the TLS record layer using an approved authenticated encryption mode (i.e. AES-GCM). The key wrapping method using AES-GCM is an approved key transport method according to IG D.G. AES-GCM, SSP establishment methodology, provides 128 or

256 bits of strength. The TLS protocol has not been reviewed or tested by the CAVP or CMVP.

© 2024 F5, Inc. / atsec information security.

30 of 41

SSPs are provided to the module by the calling process and are destroyed when released by the appropriate API function calls. The module does not perform persistent storage of SSPs.

The memory occupied by SSPs and keys is allocated by regular memory allocation operating system calls. The application is responsible for calling the appropriate destruction functions provided in the module's API. The destruction functions (listed in Table 10) overwrite the memory occupied by keys with “zeros” and deallocate the memory with the regular memory deallocation operating system call. © 2024 F5, Inc. / atsec information security.

31 of 41

Pre-operational self-tests are performed automatically when the module is loaded into memory; the pre-operational self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected. While the module is executing the pre-operational self-tests, services are not available, and input and output are inhibited. The module does not return control to the calling application until the tests are completed. 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 the error state to prohibit any further cryptographic operations. The module provides the Self-Test service to perform periodic and on-demand self-tests. Both periodic and on demand self-tests (i.e., Conditional Cryptographic Algorithm Self-Tests (CASTs) and integrity test) can be invoked by powering-off and reloading the module. During the execution of the periodic and on-demand self-tests, crypto services are not available, and no data output or input is possible.

The integrity of the module is verified by comparing an HMAC-SHA2-256 value calculated at runtime with the HMAC-SHA2-256 value stored in the module that was computed at build time. Prior to using HMAC-SHA2-256, a CAST is performed. If the CAST on the HMAC-SHA2-256 is successful, the HMAC value of the runtime image is recalculated and compared with the stored HMAC value pre-computed at compilation time.

The following sub-sections describe the conditional self-tests supported by the module. If one of the Conditional self-tests fails, the module transitions to the ‘Halt Error’ state and a corresponding error indication is given. While the module is executing the CASTs, services are not available, and input and output are inhibited. The entropy source performs its required self-tests; those are not listed in this section, as the entropy source is not part of the cryptographic boundary of the module.

The module performs cryptographic algorithm self-tests (CASTs) on all Approved cryptographic algorithms. The module performs CASTs before the integrity test. The CASTs consist in Known Answer Tests for all the approved cryptographic algorithms and the SP800-90ARev1 Health Tests for DRBG. © 2024 F5, Inc. / atsec information security.

32 of 41

Table 12 - Conditional Cryptographic Algorithm Self-Tests

A pairwise consistency test (PCT) is run whenever asymmetric keys (RSA, DH, ECDH/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 Diffie-Hellman key pair generation is performed following the SP 800-56Arev3 requirements. PCT for EC Diffie-Hellman key pair © 2024 F5, Inc. / atsec information security.

33 of 41

Error State

Cause of Error Failure of any of the PCTs

Status Indicator Error message a PCT failure for RSA, DH, ECDH or ECDSA pairwise consistency test and the flag 'fips_selftest_fail' is set.

Table 13 - Error States © 2024 F5, Inc. / atsec information security.

34 of 41

The module i.e. 1.0.2u-fips binary and its integrity check file are distributed and installed as a part of the BIG-IP product ISO. There are no maintenance requirements.

The FIPS validated module activation requires installation of the BIG-IP System License key file. The Crypto Officer should install this file as /config/bigip.license and verify the FIPS validated module license activation (or reactivation) by running the command: ‘tmsh show sys license' which should output FIPS 140, BIG-IP VE-1G to 10G,’ under the ‘Active Modules’ list. After the FIPS validated module license is installed, the command prompt will change to ‘REBOOT REQUIRED’. The Crypto Officer must reboot the BIG-IP for all FIPS-compliant changes to take effect. On the BIG-IP product the Crypto Officer should call the dedicated Show version API, fips_get_f5fips_module_version, to ensure that the module identifier and version are shown as: Cryptographic Module for BIG-IP OpenSSL 1.0.2u-fips 20 Dec 2019. 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

The Crypto Officer shall consider the following requirements and restrictions when using the module. For TLS 1.2, the module offers the AES-GCM implementation and uses the context of Scenario 1 of IG C.H. The module is compliant with SP800-52Rev2 section 3.3.1 and the mechanism for IV generation is compliant with RFC5288. The module does not implement the TLS protocol. The module’s implementation of AESGCM is used together with an application that runs outside the module’s cryptographic boundary. The design of the TLS protocol implicitly ensures that the counter (the nonce_explicit part of the IV) does not exhaust the maximum number of possible values for a given session key. In the event the module’s power is lost and restored, the consuming application must ensure that a new key for use with the AES-GCM key encryption or decryption under this scenario shall be established.

To comply with the assurances found in Section 5.6.2 of SP 800-56Ar3, the keys for KAS-FFC-SSC and KAS-ECC-SSC must be generated using the approved key generation services specified in section 9.2. For KAS-FFC-SSC the module generates keys using Safe Primes Key Generation with Safe Prime Groups: ffdhe2048, ffdhe3072, ffdhe4096. For KAS-ECC-SSC, the module generates keys using ECDSA KeyGen, Testing Candidates, with curves P-384 and P-256. The module performs full public key validation on the generated public keys. Additionally, the module performs full public key validation on the received public keys. © 2024 F5, Inc. / atsec information security.

35 of 41

Per IG C.F, the module implements FIPS 186-4 RSA SigVer and RSA SigGen with modulus lengths of 2048, 3072, 4096 bits. All these modulus lengths have been CAVP tested. © 2024 F5, Inc. / atsec information security.

36 of 41

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

37 of 41

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

38 of 41