Hewlett Packard Enterprise OpenSSL 3 Provider

Certificate

Approved Algorithms (56)

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

flowchart LR
  %% Deterministic review-risk graph for Hewlett Packard Enterprise OpenSSL 3 Provider
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<br/>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/>HTTPS</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 Hewlett Packard Enterprise OpenSSL 3 Provider
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>HTTPS</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>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

Hewlett Packard Enterprise Hewlett Packard Enterprise OpenSSL 3 Provider Software version: 3.1.4a Document version: 0.8

This section describes:

• The purpose of this document.
• HPE documents related to this document contents.
• Where to go for additional HPE Aruba Networking product information.
• Acronyms and abbreviations.
• The assurance security levels for each of the areas described in the FIPS 140-3 Standard. This release supplement provides information regarding the Hewlett Packard Enterprise OpenSSL 3 Provider Module software version 3.1.4a FIPS 140-3 Level 1 validation from HPE Aruba Networking. HPE Aruba Networking is a Hewlett Packard Enterprise company. The material in this supplement modifies the general Hewlett Packard Enterprise software documentation included with this product and should be kept with your Hewlett Packard Enterprise product documentation. This supplement primarily covers the non-proprietary Cryptographic Module Security Policy for the Hewlett Packard Enterprise OpenSSL 3 Provider Module software version 3.1.4a. This security policy describes how the module meets the security requirements of FIPS 140-3 Level

1 and how to place and maintain the module in the secure FIPS 140-3 mode. This policy was

prepared as part of the FIPS 140-3 Level 1 validation of the product. FIPS 140-3 (Federal Information Processing Standards Publication 140-3, Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. FIPS 140-3 aligns with ISO/IEC 19790:2012(E) and includes modifications of the Annexes that are allowed to the Cryptographic Module Validation Program (CMVP), as a validation authority. The testing for these requirements will be in accordance with ISO/IEC 24759:2017(E), with the modifications, additions or deletions of vendor evidence and testing allowed as a validation authority under paragraph 5.2. More information about the FIPS 140-3 standard and validation program is available on the National Institute of Standards and Technology (NIST) website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program In addition, in this document, the Hewlett Packard Enterprise OpenSSL 3 Provider Module is referred to as the module, the cryptographic module, and HPE OpenSSL. This document may be freely reproduced and distributed whole and intact including the license required. © 2024 Hewlett Packard Enterprise Company. Hewlett Packard Enterprise Company trademarks include HPE Aruba Networking®, HPE Aruba Wireless Networks®, the registered HPE Aruba Networking the Mobile Edge Company logo, HPE Aruba Networking Mobility Management System®, Mobile Edge Architecture®, People Move. Networks Must Follow®, respective owners. HPE Aruba Networking is a Hewlett Packard Enterprise company.

Open Source Code Certain Hewlett Packard Enterprise Company products include Open Source software code developed by third parties, including software code subject to the GNU General Public License (GPL), GNU Lesser General Public License (LGPL), or other Open Source Licenses. The Open Source code used can be found at this site: https://www.arubanetworks.com/open_source Legal Notice The use of HPE Aruba Networking switching platforms and software or firmware, by all individuals or corporations, to terminate other vendors’ VPN client devices constitutes complete acceptance of liability by that individual or corporation for this action and indemnifies, in full, HPE Aruba Networking. from any and all legal actions that might be taken against it with respect Acronyms and Abbreviations AES Advanced Encryption Standard CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CCCS Canadian Centre for Cyber Security, a branch of CSE CMVP Cryptographic Module Validation Program CO Crypto Officer CSE Communications Security Establishment CSP Critical Security Parameter HMAC Hashed Message Authentication Code KAT Known Answer Test PCT Pairwise Consistency Test PSP Public Security Parameter SHA Secure Hash Algorithm SSP Sensitive Security Parameter

1 1

2 1

3 1

4 1

5 1

6 1

7 N/A

8 N/A

9 1

More information is available from the following sources:

• See the Hewlett Packard Enterprise web site for the full line of products from HPE: https://www.hpe.com
• See the HPE Aruba Networking web site for the full line of products from HPE Aruba Networking: https://www.arubanetworks.com
• The NIST Validated Modules web site contains contact information for answers to technical or sales-related questions for the product: https://csrc.nist.gov/projects/cryptographic-module-validation-program/validatedmodules/search Enter Hewlett Packard Enterprise in the Vendor field then select Search to see a list of FIPS validated Hewlett Packard Enterprise or HPE Aruba Networking products. Select the Certificate Number for the Module Name ‘Hewlett Packard Enterprise OpenSSL 3 Provider Module’.

Purpose and Use: The Hewlett Packard Enterprise OpenSSL 3 Provider Module (also referred to as ‘the module’) is a software type cryptographic module and was validated under FIPS 140-3 Level 1 requirements. The Hewlett Packard Enterprise OpenSSL 3 Provider Module is one of the components within a variety of Hewlett Packard Enterprise and HPE Aruba Networking products, including the Aruba Mobility Conductors, Mobility Controllers/Gateways, and controller-managed HPE Aruba Networking Access Points (APs) running the HPE ANW Wireless Operating System (AOS) operating system running on the HPE Aruba Networking hardware-based equipment or HPE Aruba Networking virtual appliances. The module provides cryptographic services for these products and is installed automatically as part of the product’s software package. For HPE Aruba Networking products, software is installed by HPE Aruba Networking technical support personnel or downloaded from the HPE Aruba Networking Support Portal (ASP) by authenticated licensed customer personnel. Hewlett Packard Enterprise's development processes are such that future releases under Hewlett Packard Enterprise OpenSSL 3 Provider Module should be FIPS validate-able and meet the claims made in this document. Only the versions that explicitly appear on the certificate, however, are formally validated. Any version of this module that is not shown on the module certificate is out of the scope of this validation and requires a separate FIPS 140-3 validation. The CMVP makes no claim as to the correct operation of the module or the security strengths of the generated keys when operating under a version that is not listed on the validation certificate. Module Type: Software Module Embodiment: Multichip Standalone Module Characteristics: Cryptographic Boundary: The Hewlett Packard Enterprise OpenSSL 3 Provider Module is comprised of a single component, which is a dynamically loadable OpenSSL 3 provider. The boundary of the module is defined as the shared library file, which on Unix/Linux is fips.so. Tested Operational Environment’s Physical Perimeter (TOEPP): The physical perimeter is the production grade enclosure of the hardware chassis of the HPE or HPE Aruba Networking hardware device or virtual appliance host.

Module Boundary

API

HPE or HPE Aruba Networking Hardware or Virtual Appliance Host Operating System Data In Data Out Control In Status Out Storage Volatile Network CPU Memory Figure 1: Block Diagram

Tested Module Identification – Hardware: N/A                         N/A                  N/A                       N/A              N/A Table 2: Tested Module Identification – Hardware Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets): Table 3: Tested Module Identification – Software, Firmware, Hybrid (Executable Code Sets) Tested Module Identification – Hybrid Disjoint Hardware: N/A                  N/A                      N/A                        N/A              N/A Table 4: Tested Module Identification – Hybrid Disjoint Hardware

Tested Operational Environments - Software, Firmware, Hybrid: Table 5: Tested Operational Environments - Software, Firmware, Hybrid Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid:

Table 6: Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid 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.

Not Applicable – There are no excluded components for the module.

Modes List and Description: Table 7: Modes List and Description

Mode Change Instructions and Status: Not Applicable

• The module only supports a single approved mode of operation. Not Applicable
• The module does not support a degraded mode of operation.

Table 8 Approved Algorithms Vendor-Affirmed Algorithms:

Table 9: Vendor-Affirmed Algorithms The module does not implement any non-approved but allowed algorithms. The module does not implement any non-approved but allowed algorithms with no security claimed. The module does not implement any non-approved, not allowed algorithms.

Table 10: Security Function Implementations

TLS and SSH No parts of the TLS or SSH protocols, other than the KDF, have been reviewed or tested by the CAVP and CMVP. implementation of AES-GCM is used together with an application that runs outside the module’s cryptographic boundary. For TLS v1.2, the module’s GCM implementation is compatible with RFC 5288 and the ciphersuites from section 3.3.1 of SP 800-52 rev 2. When the counter (nonce_explicit) part of the IV exhausts the maximum number of possible values for session key, the module will return an error, triggering a handshake to establish a new encryption key. For TLS v1.3, the module’s GCM implementation is compatible with RFC 8446. The module also supports randomly generated IVs. The IV is generated using the module’s Approved DRBG and the minimum length of the IV is 96 bits. If power on the host system is lost, the operator must reestablish new keys. AES XTS

When XTS keys are loaded the module performs a key check per IG C.I to ensure that Key_1 ≠ Key_2. PBKDF The module's implementation of PBKDF,

• Uses option 1a from FIPS 140-3 IG D.N, for deriving a data protection key
• Requires passwords between 8 and 128 ASCII characters long. The likelihood of guessing this password at random is 1-in-6.1x1015.
• Uses an iteration count of 1 to 10,000.

The module receives entropy passively via a callback per IG 9.3.A scenario 2 (b). The caveat 'No assurance of the minimum strength of generated SSPs' applies. The callback must provide a minimum of 112 bits of entropy or return an error if this minimum cannot be met. Table 11: Key Generation Key generation is provided as a service to the calling application. Generated keys are not used directly by the module.

Table 12: Key Establishment The methods of key transport are approved per FIPS 140-3 IG D.G. The methods of shared secret computation are approved per FIPS 140-3 IG D.F

Key transport and key agreement are provided as services to the calling application. Established keys are not used directly by the module.

The module implements the KDFs for TLS 1.2, TLS 1.3, and SSH, however does not implement these protocols.

Table 13: Ports and Interfaces As a software module, the module interfaces are defined as Software or Firmware Module Interfaces (SFMI), and there are no physical ports. The logical interfaces are defined as the API of the cryptographic module. All data output via data output interface is inhibited when the module is performing preoperational tests or zeroization or when the module enters error state. Notes:

• The module does not implement a control output interface.
• As software, the module does not have a power interface.

Not applicable – The module does not implement a trusted channel.

Not applicable – The module does not implement a control interface.

The Hewlett Packard Enterprise OpenSSL 3 Provider Module does not provide any identification or authentication methods of its own. Table 14: Roles These roles are implicitly assumed by the operator of the module when performing a service. The module does not support multiple concurrent operators, a maintenance role, nor bypass capability.

s G, E G, E W, E W, E Generate only Generate only

N/A N/A N/A N/A Table 16: Non-Approved Services Not applicable – The module does not implement any non-approved services.

Not applicable – The module does not implement software loading.

Not applicable – The module does not implement bypass.

Not applicable – The module does not implement self-initiated cryptographic output capability.

The module performs a software integrity test when initialized. The test is performed by calculating the HMAC-SHA2-256 value of the module’s shared library file and comparing it with the expected value in the module’s configuration file. Prior to performing the integrity test, the module performs a HMAC-SHA2-256 KAT. If the integrity test fails, the module enters an error state where no cryptographic operations are possible.

The software integrity test can be initiated on demand using the on demand self-test service.

The module is distributed in binary form.

Type of Operational Environment: Modifiable How Requirements are Satisfied: The module’s operational environment is Linux, multi-threaded operating system that supports memory protection between processes. The operating control mechanisms protect against unauthorized execution, unauthorized modification, and unauthorized reading of SSPs, control and status data.

No specific configuration settings or restrictions are required.

Not applicable – The module is implemented exclusively in software.

Not Applicable – The module does not implement any non-invasive security mitigation techniques.

Table 17: Storage Areas As specified in the Storage Areas table, the module does not persistently store any SSPs.

Table 18: SSP Input-Output Methods

Table 19: SSP Zeroization Methods As specified in the SSP Zeroization Methods table, all SSPs/Keys used in the module are zeroized by rebooting the host platform, indicated implicitly via the successful completion of the reboot. Rebooting the

No algorithm or security strength transitions are forecasted to occur over the lifetime of the validation.

Table 22: Pre-Operational Self-Tests The module performs Pre-Operational Self-Tests (POSTs) at initialization. While the module is executing the pre-operational self-tests, services are not available, and so input and output are inhibited. After the POST and CASTs are successfully concluded, the module automatically transitions to the operational state. If the POST fails, the module enters the Error state. Self-test results can be obtained using the show status service.

5.6.2 5.6.2 Table 23: Conditional Self-Tests All Cryptographic Algorithm Self-Tests (CASTs) are run at initialization along with the POST. This ensures they are run prior to the first operational use of the cryptographic algorithm. As with the POST, once the CASTs are successfully concluded the module automatically transitions to the operational state. If a CAST fails, the module enters the Error state. If a conditional PCT or key check test fails, the service returns an error.

Table 24: Error States The module has a single error state. While in this state, the module provides no cryptographic functionality and inhibits all data output.

The module’s POST and CASTs can be run anytime using the On-Demand Self-Test service by calling OSSL_PROVIDER_self_test(), or by reloading the module.

The Hewlett Packard Enterprise OpenSSL 3 Provider Module is one of the components within Hewlett Packard Enterprise products. Full details about configuring Hewlett Packard Enterprise products can be found in the product documentation. The module is initialized by loading the shared library and executing the Initialize Module service.

Complete Crypto Officer documentation for the Hewlett Packard Enterprise OpenSSL 3 Provider is provided in the module’s Administrator guidance documentation. The module’s Show Version service can be invoked by obtaining OSSL_PROV_PARAM_NAME and OSSL_PROV_PARAM_VERSION using OSSL_PROVIDER_get_params(). The module will return the following values: The module always operates in Approved mode. The Crypto Officer must ensure the following runtime checks, which are enabled by default, are not disabled in the configuration file or using any other method:

• security-checks
• tls1-prf-ems-check
• hpe-hmac-min-key-len

Complete User documentation for the Hewlett Packard Enterprise OpenSSL 3 Provider is provided in the module’s Administrator guidance documentation. Keys derived from passwords (using PBKDF) shall only be used for storage applications.

Details about end-of-life procedures for Hewlett Packard Enterprise products can be found in the product documentation. The module itself does not have any special end of life procedures. All SSPs can be zeroized by restarting the host platform.

The module mitigates against timing-based side-channel attacks using constant-time implementations and blinding.

Constant-time Implementations protect cryptographic implementations in the Module against timing analysis since such attacks exploit differences in execution time depending on the cryptographic operation, and constant-time implementations ensure that the variations in execution time cannot be traced back to the key, CSP or secret data. Numeric Blinding protects the RSA and ECDSA algorithms from timing attacks. These algorithms are vulnerable to such attacks since attackers can measure the time of signature operations or RSA decryption. To mitigate this the Module generates a random blinding factor which is provided as an input to the decryption/signature operation and is discarded once the operation has completed and resulted in an output. This makes it difficult for attackers to attempt timing attacks on such operations without the knowledge of the blinding factor and therefore the execution time cannot be correlated to the RSA/ ECDSA key.

These mitigations are enabled by default.