| Standard | FIPS 140-3 |
|---|---|
| Overall level | 2 |
| Module type | Hardware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 12/11/2026 |
| Caveat | Interim validation. When operated in the approved mode, with tamper evident labels installed as indicated in the Security Policy |
| Vendor | Aruba, a Hewlett Packard Enterprise company |
| Hardware versions | AP-514-USF1 (HPE SKU Q9H68A), AP-515-USF1 (HPE SKU Q9H73A), AP-534-USF1 (HPE SKU JZ342A), AP-535-USF1 (HPE SKU JZ347A), AP-584-US TAA (HPE SKU R7T14A), AP-584-RW TAA (HPE SKU R7T15A), AP-585-US TAA (HPE SKU R7T19A), AP-585-RW TAA (HPE SKU R7T20A), AP-587-US TAA (HPE SKU R7T24A), AP-587-RW TAA (HPE SKU R7T25A), AP-635-RW TAA (HPE SKU R7J32A), AP-635-US TAA (HPE SKU R7J33A), AP-655-RW TAA (HPE SKU R7J43A), AP-655-US TAA (HPE SKU R7J44A) with FIPS Kit 4011570-01 (HPE SKU JY894A) |
| Requirement area | Level |
|---|---|
| Cryptographic Module Specification | 2 |
| Cryptographic Module Interfaces | 2 |
| Roles, Services, and Authentication | 2 |
| Software/Firmware Security | 2 |
| Operational Environment | N/A |
| Physical Security | 2 |
| Non-Invasive Security | N/A |
| Sensitive Security Parameter Management | 2 |
| Self-Tests | 2 |
| Life-Cycle Assurance | 2 |
| Mitigation of Other Attacks | N/A |
flowchart LR
%% Deterministic review-risk graph for AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points
%% 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>ArubaOS 8.10.0.5-FIPS</i>"]
C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Update module firmware<br/>Update module firmware16<br/>Upgrade module firmware via the console port</i>"]
C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-test triggered by CO/User reboot</i>"]
C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IKEV</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>bootloader</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 AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points
%% 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>ArubaOS 8.10.0.5-FIPS</i><br/>src: certificate.firmwareVersions"]
C2["[high] Firmware update / recovery / rollback services<br/><i>Update module firmware<br/>Update module firmware16<br/>Upgrade module firmware via the console port</i><br/>src: securityPolicy.services"]
C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-test triggered by CO/User reboot</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/>linux<br/>bootloader</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;Non-Proprietary AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Document Version 1.0 October 2024 1| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary © 2024 Hewlett Packard Enterprise Company. Hewlett Packard Enterprise Company trademarks include , HPE Aruba Wireless Networks, HPE Aruba Networking, the registered HPE Aruba Networking the Mobile Edge Company logo, HPE Aruba Networking Mobility Management System, Mobile Edge trademarks are the property of their respective owners. HPE Aruba Networking is a Hewlett Packard Enterprise company. The resource assets in this firmware may include abbreviated and/or legacy terminology for HPE Aruba Networking products. See www.arubanetworks.com for current and complete HPE Aruba Networking product lines and names. 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 Hewlett Packard Enterprise Company 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, Hewlett Packard Enterprise Company, from vendors. Warranty This hardware product is protected by the standard HPE Aruba Networking warranty of one year parts/labor. For more information, refer to the ARUBACARE SERVICE AND SUPPORT TERMS AND CONDITIONS. Altering this device (such as painting it) voids the warranty. www.arubanetworks.com
San Jose, CA, USA 95002 Phone: 408.941.4300 2| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary Contents 1.1 1.2 1.3 1.4 2.1 2.1.1 2.2 2.3 2.3.1 2.3.2 2.3.3 2.3.4 2.3.5 2.4 2.5 2.6 2.7 2.8 2.9 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 7.1 7.2 7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5 7.3.6 7.3.7 7.3.8 7.4 9.1 11.1 11.2 11.3 11.4 11.5 11.6 11.6.1 3| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary 11.6.2 11.6.3 11.7 11.8 11.8.1 11.9 Figures 4| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Version | Date | Description | |||
|---|---|---|---|---|---|
| 1.0 | October 2024 | Initial FIPS 140-3 Release for HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points with ArubaOS version 8.10 Firmware |
Non-Proprietary Tables Preface notice. Products identified herein contain confidential commercial firmware. Valid license required. Document Revision History The following table lists the history of the revisions of this document by version number and date of revision. Table 1
This section describes:
This release supplement provides information regarding the HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 validation from HPE Aruba Networking. HPE Aruba Networking is a Hewlett Packard Enterprise company. The material in this supplement modifies the general HPE Aruba Networking hardware and firmware documentation included with this product and should be kept with your HPE Aruba Networking product documentation. This supplement primarily covers the non-proprietary Cryptographic Module Security Policy for the HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP655 Access Points with ArubaOS FIPS Firmware. This security policy describes how the Wireless Access Points (APs) meet the security requirements of FIPS 140-3 Level 2 and how to place and maintain the APs in the secure FIPS 140-3 mode. This policy was prepared as part of the FIPS 140-3 Level 2 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 HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points with ArubaOS FIPS Firmware are referred to as the Wireless Access Point, the AP, the module, the cryptographic module, HPE Aruba Networking Wireless Access Points, HPE Aruba Networking Wireless APs, HPE Aruba Networking Access Points, HPE Aruba Networking APs, and AP-5XX and AP-6XX Wireless APs.
More information is available from the following sources:
AES AP CAVP CBC CCCS CLI CMVP CO CPSec CSE CSP ECO EMC EMI ESV FE GE GHz HMAC Hz IKE IPsec KAT KEK L2TP LAN LED PCT PSP SFTP SHA SNMP SSP SPOE TEL TFTP WLAN 7| Advanced Encryption Standard Access Point Cryptographic Algorithm Validation Program Cipher Block Chaining Canadian Centre for Cyber Security, a branch of CSE Command Line Interface Cryptographic Module Validation Program Crypto Officer Control Plane Security protected Communications Security Establishment Critical Security Parameter External Crypto Officer Electromagnetic Compatibility Electromagnetic Interference Entropy Source Validation Fast Ethernet Gigabit Ethernet Gigahertz Hashed Message Authentication Code Hertz Internet Key Exchange Internet Protocol security Known Answer Test Key Encryption Key Layer-2 Tunneling Protocol Local Area Network Light Emitting Diode Pairwise Consistency Test Public Security Parameter Secure File Transfer Protocol Secure Hash Algorithm Simple Network Management Protocol Sensitive Security Parameter Serial & Power Over Ethernet Tamper-Evident Label or seal Trivial File Transfer Protocol Wireless Local Area Network HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | ISO Section | Requirement | Level |
|---|---|---|---|
| 1 | 1 | General | 2 |
| 2 | 2 | Cryptographic Module Specification | 2 |
| 3 | 3 | Cryptographic Module Interfaces | 2 |
| 4 | 4 | Roles, Services, and Authentication | 2 |
| 5 | 5 | Software/Firmware Security | 2 |
| 6 | 6 | Operational Environment | N/A |
| 7 | 7 | Physical Security | 2 |
| 8 | 8 | Non-Invasive Security | N/A |
| 9 | 9 | Sensitive Security Parameter Management | 2 |
| 10 | 10 | Self-Tests | 2 |
| 11 | 11 | Life-Cycle Assurance | 2 |
| 12 | 12 | Mitigation of Other Attacks | N/A |
| Overall | Overall | Overall Security Rating of the Module | 2 |
The HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points and associated modules are intended to meet overall FIPS 140-3 Level 2 requirements as shown in the following table. Table 2
| Component | Type | Versions | CAVP Cert. # | ||||
|---|---|---|---|---|---|---|---|
| ArubaOS OpenSSL Module | Firmware | 1.0 | A2690 | ||||
| Aruba CPU Jitter Entropy Source | Firmware | 3.3.1 | A2738 | ||||
| ArubaOS Crypto Module | Firmware | 1.0 | A2689 | ||||
| ArubaOS Bootloader Module | Firmware | 1.0 | A2688 |
| Type | Versions | ||
|---|---|---|---|
| Hardware | HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points (APs) | ||
| Firmware | ArubaOS 8.10.0.5-FIPS |
Purpose and Use: AP-655 Access Points (each also referred to as ‘the module’ and ‘AP’) are hardware type cryptographic modules with ArubaOS version 8.10 FIPS Firmware, all contained in hard, opaque plastic cases. Each under FIPS 140-3 Level 2 requirements. ArubaOS is the operating system for HPE Aruba Networking Mobility Conductors, Mobility Cryptographic services are provided by components of ArubaOS. An access point is a hardware device that creates a wireless local area network (WLAN), connects to a wired router, switch, or hub via an Ethernet cable, and projects a Wi-Fi signal to a designated area. See the diagram and tables below and in following sub-sections for AP details. Module Embodiment: Multiple-chip Standalone Module Characteristics: None
Each access point’s case physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the module. Refer to section 2.3, Operating Environments, for information on each HPE Aruba Networking AP’s hardware, including the processor for each listed in Table 5, Cryptographic Module Tested Configurations. The cryptographic services available to each HPE Aruba Networking AP are provided by the following components: Table 3
Table 4
| Name | Model | Hardware Version | Firmware Version | Processor | Features |
|---|---|---|---|---|---|
| AP-514-USF1 | AP-514-USF1 | HPE SKU Q9H68A | ArubaOS 8.10 | Broadcom BCM (64-bit ARMv8) - No acceleration | 2.3.1 AP-510 Series |
| AP-515-USF1 | AP-515-USF1 | HPE SKU Q9H73A | ArubaOS 8.10 | ||
| AP-534-USF1 | AP-534-USF1 | HPE SKU JZ342A | ArubaOS 8.10 | Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration | 2.3.2 AP-530 Series |
| AP-535-USF1 | AP-535-USF1 | HPE SKU JZ347A | ArubaOS 8.10 | ||
| AP-584-US TAA AP-584-RW TAA | AP-584-US TAA AP-584-RW TAA | HPE SKU R7T14A HPE SKU R7T15A | ArubaOS 8.10 | Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration | 2.3.3 AP-580 Series |
| AP-585-US TAA AP-585-RW TAA | AP-585-US TAA AP-585-RW TAA | HPE SKU R7T19A HPE SKU R7T20A | ArubaOS 8.10 | ||
| AP-587-US TAA AP-587-RW TAA | AP-587-US TAA AP-587-RW TAA | HPE SKU R7T24A HPE SKU R7T25A | ArubaOS 8.10 | ||
| AP-635-RW TAA AP-635-US TAA | AP-635-RW TAA AP-635-US TAA | HPE SKU R7J32A HPE SKU R7J33A | ArubaOS 8.10 | Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration | 2.3.4 AP-630 Series |
| AP-655-RW TAA AP-655-US TAA | AP-655-RW TAA AP-655-US TAA | HPE SKU R7J43A HPE SKU R7J44A | ArubaOS 8.10 | Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration | 2.3.5 AP-650 Series |
The module contains a limited operational environment. The HPE Aruba Networking operating system runs on the HPE Aruba Networking access point hardware with cryptographic services provided by the ArubaOS operating system. See the following table of Cryptographic Module Tested Configurations for details. Only the versions that explicitly appear on the validation certificate are formally validated. Table 5
This section introduces the HPE Aruba Networking AP-510 Series Campus Access Points (APs) with FIPS 140-3 Level 2 validation. It describes the purpose of the AP-514 and AP-515 APs, their physical attributes, and their interfaces. Figure 1 - AP-514 Campus Access Point
Non-Proprietary Figure 4 - AP-515 Campus Access Point
5 GHz; 40 MHz in 2.4 GHz), and up to 1024-QAM modulation. Each AP supports up to 512 associated client
devices per radio and has a total of four dual band antennas. In addition to 802.11ax standard capabilities, the Wi-Fi 6 510 Series supports unique features like Aruba ClientMatch radio management and additional radios (Bluetooth 5 and Zigbee) for location services, asset tracking services, security solutions and IoT sensors, as well as ArubaOS 8 features like Aruba Activate and AirMatch with machine learning technology to automatically optimize the wireless network performance. The AP-514 has four (female) RP-SMA connectors for external dual band antennas (A0 through A3, corresponding with radio chains 0 through 3). The AP-515 has four integrated dual-band downtilt omnidirectional antennas for 4x4 MIMO with peak antenna gain of 4.2 dBi in 2.4 GHz and 7.5 dBi in 5 GHz. Builtin antennas are optimized for horizontal ceiling mounted orientation of the AP. The downtilt angle for maximum gain is roughly 30 degrees. Additionally, Advanced Cellular Coexistence (ACC) minimizes the impact of interference from 3G/4G LTE cellular networks, Dynamic Frequency Selection (DFS) maximizes the use of available RF spectrum, and Maximum Ratio Combining (MRC) improves receiver performance. When managed by HPE Aruba Networking Mobility Controllers, AP-514 and AP-515 offer centralized configuration, data encryption, policy enforcement and network services, as well as distributed and centralized traffic forwarding. 2.3.1.1 Physical Description The HPE Aruba Networking AP-514 and AP-515 Campus Access Points are multiple-chip standalone cryptographic modules consisting of hardware and firmware, all contained in hard, opaque plastic cases. The modules contain 802.11 a/b/g/n/ac/ax transceivers and support four integrated omni-directional downtilt antennas each. The case physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the module. The Access Point configurations validated during the cryptographic module testing included:
Non-Proprietary
| LED Type | Color/State | Meaning | |||
|---|---|---|---|---|---|
| System Status (Left) | Off | AP powered off | |||
| Green - Blinking | Device booting; not ready | ||||
| Green - Solid | Device ready | ||||
| Amber - Solid | Device ready; power-save mode (802.3af PoE): * Single radio * USB disabled | ||||
| Green or Amber Flashing | Device ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode | ||||
| Red | System error condition | ||||
| Radio Status (Right) | Off | AP powered off, or both radios disabled | |||
| Green - Solid | Both radios enabled in access mode | ||||
| Amber - Solid | Both radios enabled in monitor mode | ||||
| Green or Amber Blinking | One radio enabled in access (green) or monitor (amber) mode, other disabled | ||||
| Green/Amber Alternating | Green: one radio enabled in access mode, Amber: one radio enabled in monitor mode |
Non-Proprietary Other Interfaces:
This section introduces the HPE Aruba Networking AP-530 Series Campus Access Points (APs) with FIPS 140-3 Level 2 validation. It describes the purpose of the AP-534 and AP-535 APs, their physical attributes, and their interfaces. Figure 6 - AP-534 Campus Access Point
Non-Proprietary Figure 9 - AP-535 Campus Access Point
Non-Proprietary 2.3.2.2 Dimensions / Weight The AP has the following physical dimensions:
| LED Type | Color/State | Meaning | |||
|---|---|---|---|---|---|
| System Status (Left) | Off | AP powered off | |||
| Green - Blinking | Device booting; not ready | ||||
| Green - Solid | Device ready | ||||
| Amber - Solid | Device ready; power-save mode (802.3at PoE): * Single radio * USB disabled | ||||
| Green or Amber Flashing | Device ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode | ||||
| Red | System error condition | ||||
| Radio Status (Right) | Off | AP powered off, or both radios disabled | |||
| Green - Solid | Both radios enabled in access mode | ||||
| Amber - Solid | Both radios enabled in monitor mode | ||||
| Green or Amber Blinking | One radio enabled in access (green) or monitor (amber) mode, other disabled | ||||
| Green/Amber Alternating | Green: one radio enabled in access mode, Amber: one radio enabled in monitor mode |
Non-Proprietary Figure 10 - AP-530 Series Campus Access Point
This section introduces the HPE Aruba Networking AP-580 Series Outdoor Access Points (APs) with FIPS 140-3 Level 2 validation. It describes the purpose of the AP-584, AP-585 and AP-587 APs, their physical attributes, and their interfaces. Figure 11 - AP-585 Outdoor Access Point
6 performance to large scale outdoor environments including universities, large enterprises, and industrial
applications. Weatherproofed, and temperature hardened to survive in the harshest outdoor environments, the 580 Series APs withstand exposure to extreme high and low temperatures, persistent moisture, and precipitation, and are fully sealed to keep out airborne contaminants. All electrical interfaces include industrial surge protection and are IP66/67 certified. 19| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary The high performance and high density 802.11ax 580 Series Access Points support all mandatory and several optional 802.11ax features, which include Uplink and Downlink Orthogonal Frequency Division Multiple Access (OFDMA) for increased user data rates and reduced latency, bi-directional Multi-User Multiple Input Multiple Output (MU-MIMO) for improved network capacity with multiples devices capable to transmit simultaneously, dual-radio 4x4 MIMO with up to four spatial streams (4SS) in 5 GHz and 4x4 with up to four spatial streams (4SS) in 2.4 GHz, and up to 1024-QAM modulation. Each AP supports up to 1,024 associated client devices per radio and up to 16 BSSIDs per radio. The AP-584 has a total of five Nf connectors for external antennas (four external dual band antennas and one BT antenna), the AP-585 has four internal dualband omni-directional antennas for 4x4 MIMO in 2.4 GHz with peak antenna gain of 4.4 dBi and 4x4 MIMO in
5 GHz with peak antenna gain of 5.8 dBi plus a BT antenna with 4.8 dBi, and the AP-587 has four internal
dual-band directional antennas for 4x4 MIMO in 2.4 GHz with peak antenna gain of 5.8 dBi and 4x4 MIMO in
5 GHz with peak antenna gain of 6.6 dBi plus a BT antenna with 6.3 dBi. In addition to 802.11ax standard
capabilities, the Wi-Fi 6 AP-580 Series supports unique features like Aruba ClientMatch radio management and an additional radio (Bluetooth Low-Energy (BLE)) for location services, asset tracking services, security solutions and IoT sensors, as well as ArubaOS 8+ features like Aruba Activate and Air Slice with machine learning technology to automatically optimize the wireless network performance. Additionally, Aruba Advanced Cellular Coexistence (ACC) minimizes the impact of interference from cellular networks, distributed antenna systems (DAS), and commercial small cell or femtocell equipment, plus Dynamic Frequency Selection (DFS) maximizes the use of available RF spectrum, and Maximum Ratio Combining (MRC) improves receiver performance. When managed by HPE Aruba Networking Mobility Controllers, AP-580 Series APs offer centralized configuration, data encryption, policy enforcement and network services, as well as distributed and centralized traffic forwarding. 2.3.3.1 Physical Description The HPE Aruba Networking AP-584, AP-585 and AP-587 Outdoor Access Points are multiple-chip standalone cryptographic modules consisting of hardware and firmware, all contained in hard, opaque plastic cases. The modules contain 802.11 a/b/g/n/ac/ax transceivers and support both external antennas (AP-584) and internal integrated omni-directional antennas (AP-585 and AP-587). The case physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the module. The AP-580 Series Access Points configurations validated during the cryptographic modules testing included:
Non-Proprietary 2.3.3.3
| LED Type | Color/State | Meaning | |||
|---|---|---|---|---|---|
| System Status (during Boot Up) | Off | AP powered off | |||
| Red | Initial power-up | ||||
| Green - Flashing | AP booting; not ready | ||||
| Green - Solid | AP ready and GbE (or better) or SFP+ connected. The LED turns off after 1200 seconds. | ||||
| Green / Amber Alternating, 6 seconds period | AP ready and 100Mbps Ethernet link established. The LED turns off after 1200 seconds. | ||||
| Green – Flashing, 6 seconds period | AP in deep sleep | ||||
| Red – Flashing | AP in thermal shutdown | ||||
| System Status (during Operation) | Red - Solid | System error condition | |||
| Red – One red blink every 3 seconds | Radio 0 fault (5 GHz) | ||||
| Red – Two quick blinks 0.5 seconds apart, cycled every 3 seconds | Radio 1 fault (2.4 GHz) |
Non-Proprietary Figure 16 - AP-585 Outdoor Access Point
This section introduces the HPE Aruba Networking AP-630 Series Campus Access Points (APs) with FIPS 140-3 Level 2 validation. It describes the purpose of the AP-635 APs, their physical attributes, and their interfaces. Figure 18 - AP-635 Campus Access Point
2.4 Gbps in the 6 GHz band (for an aggregate peak data rate of 3.9 Gbps), the 630 Series Access Points
deliver more wireless capacity and/or wider channels with less interference in indoor environments for any enterprise environment. The 630 Series Access Points with Wi-Fi 6E can better support low-latency, bandwidth hungry applications like high-definition video and artificial reality/virtual reality applications while using comprehensive tri-band coverage to meet the growing demands of Wi-Fi from increased use of video, growth in client and IoT devices, and expanded use of cloud. The AP-635 APs support 802.11ax features which include Orthogonal Frequency Division Multiple Access (OFDMA) with up to 37 resource units for increased user data rates and reduced latency, Multi-User Multiple Input Multiple Output (MU-MIMO) for improved network capacity with multiples devices capable to transmit simultaneously, 2x2 MIMO with up to two spatial streams (2SS) in all three bands, channel bandwidths up to 160 MHz (in 6 GHz; 80 MHz in 5GHz, and 20 MHz in 2.4 GHz), and up to 1024-QAM modulation. Each AP supports up to 512 associated client devices per radio and has a total of four dual band antennas. In addition to 802.11ax standard capabilities, the Wi-Fi 6E 630 Series supports unique features like Aruba ClientMatch radio management and an additional radio (for Bluetooth 5 and Zigbee) for location services, asset tracking services, security solutions and IoT sensors, as well as ArubaOS features like Air Slice and AirMatch with machine learning technology to automatically optimize the wireless network performance. The AP-635 has four integrated dual-band downtilt omni-directional antennas for 2x2 MIMO with peak antenna gain of 4.6 dBi in 2.4 GHz, 7.0 dBi in 5 GHz, and 6.3 dBi in 5 GHz. Built-in antennas are optimized for horizontal ceiling mounted orientation of the AP. The downtilt angle for maximum gain is roughly 30 to 40 degrees. Also, the BLE5.0 / Zigbee radio uses an integrated omnidirectional antenna with roughly 30 to 40 degrees downtilt and peak gain of 3.0 dBi. 23| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary Additionally, Advanced Cellular Coexistence (ACC) minimizes the impact of interference from cellular networks, Dynamic Frequency Selection (DFS) optimizes the use of available RF spectrum, and Maximum Ratio Combining (MRC) improves receiver performance. When managed by HPE Aruba Networking Mobility Controllers, AP-635 offers centralized configuration, data encryption, policy enforcement and network services, as well as distributed and centralized traffic forwarding. 2.3.4.1 Physical Description The HPE Aruba Networking AP-635 Access Points are multiple-chip standalone cryptographic modules consisting of hardware and firmware, all contained in hard, opaque plastic cases. The modules contain
802.11 a/b/g/n/ac/ax transceivers and support four integrated omni-directional downtilt antennas.
The case physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the module. The Access Point configuration validated during the cryptographic module testing included:
| LED Type | Color/State | Meaning | |||
|---|---|---|---|---|---|
| System Status (Left) | Off | AP powered off | |||
| Green - Blinking | Device booting; not ready | ||||
| Green - Solid | Device ready | ||||
| Amber - Solid | Device ready; power-save mode (802.3at PoE): * Single radio * USB disabled | ||||
| Green or Amber Flashing | Device ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode | ||||
| Red | System error condition | ||||
| Radio Status (Right) 2GHz/5GHz/6GHz | Off | AP powered off, or radio disabled | |||
| Green - Solid | Radio enabled in access mode | ||||
| Amber - Solid | Radio enabled in monitor or spectrum analysis mode | ||||
| Green Flashing | Radio enabled in uplink or mesh mode |
Non-Proprietary Bluetooth 5.0 Low Energy (BLE5.0) and Zigbee (802.15.4) radio:
This section introduces the HPE Aruba Networking AP-650 Series Campus Access Points (APs) with FIPS 140-3 Level 2 validation. It describes the purpose of the AP-655 APs, their physical attributes, and their interfaces. Figure 21 - AP-655 Campus Access Point
Non-Proprietary Additionally, Advanced Cellular Coexistence (ACC) minimizes the impact of interference from cellular networks, Dynamic Frequency Selection (DFS) optimizes the use of available RF spectrum, and Maximum Ratio Combining (MRC) improves receiver performance. When managed by HPE Aruba Networking Mobility Controllers, AP-650 Series APs offer centralized configuration, data encryption, policy enforcement and network services, as well as distributed and centralized traffic forwarding. 2.3.5.1 Physical Description The HPE Aruba Networking AP-655 Access Points are multiple-chip standalone cryptographic modules consisting of hardware and firmware, all contained in hard, opaque plastic cases. The modules contain 802.11 a/b/g/n/ac/ax transceivers and support eight integrated omni-directional downtilt antennas. The case physically encloses the complete set of hardware and firmware components and represents the cryptographic boundary of the module. The Access Point configuration validated during the cryptographic module testing included:
| LED Type | Color/State | Meaning | |||
|---|---|---|---|---|---|
| System Status (Left) | Off | AP powered off | |||
| Green - Blinking | Device booting; not ready | ||||
| Green - Solid | Device ready | ||||
| Amber - Solid | Device ready; power-save mode (802.3at PoE): * Single radio * USB disabled | ||||
| Green or Amber Flashing | Device ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode | ||||
| Red | System error condition | ||||
| Radio Status (Right) 2GHz/5GHz/6GHz | Off | AP powered off, or radio disabled | |||
| Green - Solid | Radio enabled in access mode | ||||
| Amber - Solid | Radio enabled in monitor or spectrum analysis mode | ||||
| Green Flashing | Radio enabled in uplink or mesh mode |
Non-Proprietary Bluetooth 5.0 Low Energy (BLE5.0) and Zigbee (802.15.4) radio:
There are no excluded components for the module. 28| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Description | Role Access | Yes |
|---|---|---|---|
| Non- Approved Mode | A provisioned AP where FIPS Settings are not enabled. | To verify Approved mode has NOT been enabled, issue the command: show fips to see: FIPS Settings: Mode Disabled | No |
| Name | CAVP Cert | Mode Method | Key Size | Use Function |
|---|---|---|---|---|
| AES [FIPS 197] [SP 800-38A] | A2690 | CBC, ECB, CTR (256, ext only, encryption only) | 128, 192, 256 | Data Encryption/Decryption |
| AES [FIPS 197] [SP 800-38A] [SP 800-38D] | A2690 | GCM, CCM | 128, 256 | Data Encryption/Decryption |
| CKG [SP 800-133 Rev2] | Vendor Affirmed1 | CTR_DRBG | N/A | Cryptographic Key Generation (using output from DRBG2 as per IG D.H) |
Table 11
| Name | CAVP Cert | Mode Method | Key Size | Use Function | ||
|---|---|---|---|---|---|---|
| CVL IKEv13 KDF [SP 800-135 Rev1] | A2690 | IKEv1: DSA, PSK | IKEv1: DH 2048-bit; SHA2-256, SHA2-384 | Key Derivation | ||
| DRBG [SP 800-90A Rev1] | A2690 | AES CTR | 256 | Deterministic Random Bit Generation | ||
| ESV program certificate #7 [SP 800-90B] | N/A | Aruba CPU Jitter Entropy Source non-physical entropy source (min-entropy 427.696/512 bits) with SP 800-90B vetted Hash_df (SHA3-256) conditioning component, used solely for seeding min-entropy 256 bits to the SP 800-90A Rev1 approved AES-256 CTR_DRBG (A2690). | Entropy Generation | |||
| DSA [FIPS 186-4] | A2690 | keyGen, pqgGen | L=2048, N=256, SHA2-256 | Key Generation, Domain Parameter Generation | ||
| ECDSA [FIPS 186-4] | A2690 | KeyGen, KeyVer, SigGen, SigVer | KeyGen: P-256, P-384 KeyVer: P-256, P-384 SigGen: P-256, P-384 with SHA2-256, SHA2-384, SHA2-512 SigVer: P-256, P-384 with SHA-1, SHA2-256, SHA2-384, SHA2-512 | Key Generation and Verification, Digital Signature Generation and Verification | ||
| HMAC [FIPS 198-1] | A2690 | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | (minimum 112 bits) | Message Authentication | ||
| KBKDF [SP 800-108 Rev1] | A2690 | CTR | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | Key-based Key Derivation | ||
| KAS-SSC [SP 800-56A Rev3] | A2690 | FFC: dhEphem, ECC: Ephemeral Unified | FFC: FC with SHA2-256, MODP-2048 with SHA2-256 ECC: P-256 with SHA2-256, P-384 with SHA2-384 KAS Roles - initiator, responder | Key Agreement Scheme – Shared Secret Computation (as per IG D.F, Scenario 2 (2)) | ||
| KDA [SP 800-56C Rev2] | A2690 | Two-step key derivation | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | Key Derivation Algorithm | ||
| RSA [FIPS 186-2] | A2690 | SigVer: SHA-14, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | 1024 (for legacy SigVer only), 2048 | Digital Signature Verification | ||
| RSA [FIPS 186-4] | A2690 | KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-15, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048 | Key Generation, Digital Signature Generation and Verification | ||
| Safe Primes [SP 800-56A Rev3] | A2690 | KeyGen, KeyVer | Safe Prime Groups: MODP-2048 | Safe Primes Key Generation and Key Verification | ||
| SHS [FIPS 180-4] | A2690 | SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only | 160, 256, 384, 512 | Message Digest | ||
| KTS [SP 800-38F] | AES A2690 | AES-GCM6 | 128, 256 | Key Wrapping / Key Transport via IKE/IPSec | ||
| KTS [SP 800-38F] [FIPS 198-1] | AES A2690 HMAC A2690 | AES-CBC7 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | 128, 192, 256 | Key Wrapping / Key Transport via IKE/IPSec | ||
| SHA-3 [FIPS 202] | A2738 | SHA3-256 | 256 | Entropy Generation and Conditioning | ||
| AES [FIPS 197] [SP 800-38A] [SP 800-38D] | A2689 | CBC, GCM8 | 128, 192, 256 | Data Encryption/Decryption | ||
| CVL IKEv29 KDF [SP 800-135 Rev1] | A2689 | IKEv2 | IKEv2: DH 2048-bit; SHA2-256, SHA2-384 | Key Derivation | ||
| DSA [FIPS 186-4] | A2689 | keyGen, pqgGen | L=2048, N=256, SHA2-256 | Key Generation, Domain Parameter Generation | ||
| ECDSA [FIPS 186-4] | A2689 | KeyGen, KeyVer, SigGen, SigVer | KeyGen: P-256, P-384 KeyVer: P-256, P-384 SigGen: P-256, P-384 with SHA2-256, SHA2-384, SHA2-512 SigVer: P-256, P-384 with SHA-1, SHA2-256, SHA2-384, SHA2-512 | Key Generation and Verification, Digital Signature Generation and Verification |
Non-Proprietary N/A (2)) No parts of the IKEv1 protocol, other than the approved cryptographic algorithms and KDF, have been tested by the CAVP and CMVP. 30| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | CAVP Cert | Mode Method | Key Size | Use Function | ||
|---|---|---|---|---|---|---|
| Safe Primes [SP 800-56A Rev3] | A2690 | KeyGen, KeyVer | Safe Prime Groups: MODP-2048 | Safe Primes Key Generation and Key Verification | ||
| SHS [FIPS 180-4] | A2690 | SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only | 160, 256, 384, 512 | Message Digest | ||
| KTS [SP 800-38F] | AES A2690 | AES-GCM6 | 128, 256 | Key Wrapping / Key Transport via IKE/IPSec | ||
| KTS [SP 800-38F] [FIPS 198-1] | AES A2690 HMAC A2690 | AES-CBC7 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | 128, 192, 256 | Key Wrapping / Key Transport via IKE/IPSec | ||
| SHA-3 [FIPS 202] | A2738 | SHA3-256 | 256 | Entropy Generation and Conditioning | ||
| AES [FIPS 197] [SP 800-38A] [SP 800-38D] | A2689 | CBC, GCM8 | 128, 192, 256 | Data Encryption/Decryption | ||
| CVL IKEv29 KDF [SP 800-135 Rev1] | A2689 | IKEv2 | IKEv2: DH 2048-bit; SHA2-256, SHA2-384 | Key Derivation | ||
| DSA [FIPS 186-4] | A2689 | keyGen, pqgGen | L=2048, N=256, SHA2-256 | Key Generation, Domain Parameter Generation | ||
| ECDSA [FIPS 186-4] | A2689 | KeyGen, KeyVer, SigGen, SigVer | KeyGen: P-256, P-384 KeyVer: P-256, P-384 SigGen: P-256, P-384 with SHA2-256, SHA2-384, SHA2-512 SigVer: P-256, P-384 with SHA-1, SHA2-256, SHA2-384, SHA2-512 | Key Generation and Verification, Digital Signature Generation and Verification |
Non-Proprietary AES-GCM 6 Table 13 - Approved Algorithms - Aruba CPU Jitter Entropy Source Table 14 - Approved Algorithms - ArubaOS Crypto Module CBC, GCM 8 AES-GCM is an authenticated encryption algorithm that is approved for use in key transport per FIPS 140-3 IG D.G. This key establishment methodology provides 128 or 256 bits of encryption strength. AES-CBC combined with HMAC is approved for use in key transport per FIPS 140-3 IG D.G. This key establishment methodology provides between 128 and 256 bits of encryption strength. AES GCM IV generation is performed in compliance with IG C.H, Scenario 2. The IV is generated internally and randomly using the Approved DRBG that is internal to the module’s boundary and has a length of 96 bits. No parts of the IKEv2 protocol, other than the approved cryptographic algorithms and KDF, have been tested by the 31| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | CAVP Cert | Mode Method | Key Size | Use Function |
|---|---|---|---|---|
| HMAC [FIPS 198-1] | A2689 | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | (minimum 112 bits) | Message Authentication |
| KAS-SSC [SP 800-56A Rev3] | A2689 | FFC: dhEphem, ECC: Ephemeral Unified | FFC: FC with SHA2-256, MODP- 2048 with SHA2-256 ECC: P-256 with SHA2-256, P- 384 with SHA2-384 KAS Roles - initiator, responder | Key Agreement Scheme – Shared Secret Computation |
| RSA [FIPS 186-2] | A2689 | SigVer: SHA-110, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | 1024 (for legacy SigVer only), 2048 | Digital Signature Verification |
| RSA [FIPS 186-4] | A2689 | KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-111, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048 | Key Generation, Digital Signature Generation and Verification |
| Safe Primes [SP 800-56A Rev3] | A2689 | KeyGen, KeyVer | Safe Prime Groups: MODP-2048 | Safe Primes Key Generation and Key Verification |
| SHS [FIPS 180-4] | A2689 | SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only | 160, 256, 384, 512 | Message Digest |
| KTS [SP 800-38F] | AES A2689 | AES-GCM12 | 128, 256 | Key Wrapping / Key Transport via IKE/IPSec |
| KTS [SP 800-38F] [FIPS 198-1] | AES A2689 HMAC A2689 | AES-CBC13 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | 128, 192, 256 | Key Wrapping / Key Transport via IKE/IPSec |
| RSA [FIPS 186-4] | A2688 | SigVer: SHA2-256 PKCS1 v1.5 | SigVer: 2048 | Digital Signature Verification (only) |
| SHS [FIPS 180-4] | A2688 | SHA2-256 Byte Only | 256 | Message Digest |
| Name | CAVP Cert | Mode Method | Key Size | Use Function | Algorithm and Standard |
|---|---|---|---|---|---|
| HMAC [FIPS 198-1] | A2689 | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | (minimum 112 bits) | Message Authentication | |
| KAS-SSC [SP 800-56A Rev3] | A2689 | FFC: dhEphem, ECC: Ephemeral Unified | FFC: FC with SHA2-256, MODP- 2048 with SHA2-256 ECC: P-256 with SHA2-256, P- 384 with SHA2-384 KAS Roles - initiator, responder | Key Agreement Scheme – Shared Secret Computation | |
| RSA [FIPS 186-2] | A2689 | SigVer: SHA-110, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | 1024 (for legacy SigVer only), 2048 | Digital Signature Verification | |
| RSA [FIPS 186-4] | A2689 | KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-111, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 | KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048 | Key Generation, Digital Signature Generation and Verification | |
| Safe Primes [SP 800-56A Rev3] | A2689 | KeyGen, KeyVer | Safe Prime Groups: MODP-2048 | Safe Primes Key Generation and Key Verification | |
| SHS [FIPS 180-4] | A2689 | SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only | 160, 256, 384, 512 | Message Digest | |
| KTS [SP 800-38F] | AES A2689 | AES-GCM12 | 128, 256 | Key Wrapping / Key Transport via IKE/IPSec | |
| KTS [SP 800-38F] [FIPS 198-1] | AES A2689 HMAC A2689 | AES-CBC13 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | 128, 192, 256 | Key Wrapping / Key Transport via IKE/IPSec | |
| RSA [FIPS 186-4] | A2688 | SigVer: SHA2-256 PKCS1 v1.5 | SigVer: 2048 | Digital Signature Verification (only) | |
| SHS [FIPS 180-4] | A2688 | SHA2-256 Byte Only | 256 | Message Digest | |
| Triple-DES-ECB | Triple-DES-ECB | Used with the KEK only for internal key obfuscation as per IG 2.4.A | [no security claimed] | ||
| DES | Used for older versions of WEP in non-Approved mode | ||||
| HMAC-MD5 | Used for older versions of WEP in non-Approved mode | ||||
| MD5 | Used for older versions of WEP in non-Approved mode | ||||
| RC4 | Used for older versions of WEP in non-Approved mode | ||||
| Null Encryption | Used for older versions of WEP in non-Approved mode | ||||
| RSA | Non-compliant less than 112 bits, or when used with SHA-1 for signature generation, or when other than 2048-bit modulus sizes are used | ||||
| Diffie-Hellman | key agreement; non-compliant less than 112 bits of encryption strength | ||||
| EC Diffie-Hellman | key agreement; non-compliant less than 112 bits of encryption strength | ||||
| ECDSA | Non-compliant when using 186-2 signature generation | ||||
| Triple-DES-CBC | As used in IKE/IPSec |
Non-Proprietary AES-GCM 12 AES-CBC 13 Table 15 - Approved Algorithms - ArubaOS Bootloader Module AES-GCM is an authenticated encryption algorithm that is approved for use in key transport per FIPS 140-3 IG D.G. This key establishment methodology provides 128 or 256 bits of encryption strength. AES-CBC combined with HMAC is approved for use in key transport per FIPS 140-3 IG D.G. This key establishment methodology provides between 128 and 256 bits of encryption strength. 32| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | CAVP Cert | Key Size | Use Function | Algorithm and Standard |
|---|---|---|---|---|
| Triple-DES-ECB | Triple-DES-ECB | Used with the KEK only for internal key obfuscation as per IG 2.4.A | [no security claimed] | |
| DES | Used for older versions of WEP in non-Approved mode | |||
| HMAC-MD5 | Used for older versions of WEP in non-Approved mode | |||
| MD5 | Used for older versions of WEP in non-Approved mode | |||
| RC4 | Used for older versions of WEP in non-Approved mode | |||
| Null Encryption | Used for older versions of WEP in non-Approved mode | |||
| RSA | Non-compliant less than 112 bits, or when used with SHA-1 for signature generation, or when other than 2048-bit modulus sizes are used | |||
| Diffie-Hellman | key agreement; non-compliant less than 112 bits of encryption strength | |||
| EC Diffie-Hellman | key agreement; non-compliant less than 112 bits of encryption strength | |||
| ECDSA | Non-compliant when using 186-2 signature generation | |||
| Triple-DES-CBC | As used in IKE/IPSec |
Non-Proprietary Operation The cryptographic module implements no non-Approved algorithms allowed for use in the Approved The cryptographic module implements the following non-Approved algorithms allowed in the Approved Table 16
| Name | Physical Port | Logical Interface | Data That Passes |
|---|---|---|---|
| • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces | • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces | Data Input Interface | • The packets that use the networking functionality of the module |
| • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces | • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces | Data Output Interface | • The packets that use the networking functionality of the module |
| • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces • Reset button | • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces • Reset button | Control Input Interface | • Manual control inputs for power and reset through the power interfaces (power supply or POE) • All of the data that is entered into the access point while using the management interfaces |
| • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces • LED Status Indicators | • Ethernet Ports • SFP Ports (AP-584/585/587) • 802.11a/b/g/n/ac/ax Antenna Interfaces • LED Status Indicators | Status Output Interface | • The status indicators displayed through the LEDs (which indicate the physical state of the module, such as power- up (or rebooting), utilization level, and activation state) • The status data that is output from the module while using the management interfaces • The log file (which records the results of self-tests, configuration errors, and monitoring data) |
| • Power Input • Power-Over-Ethernet (POE) | • Power Input • Power-Over-Ethernet (POE) | Power Interface | • The module may be powered by an external power supply (no data passes over the interface) • Operating power may also be provided via a Power Over Ethernet (POE) device (when connected), where the power is provided through the connected Ethernet cable (no data passes over the interface) |
Non-Proprietary passing over the five (5) logical interfaces defined by FIPS 140-3. Notes:
| Name | Roles | Input | Output |
|---|---|---|---|
| Approved mode enable/disable from Mobility Controller14 | Crypto Officer, User | Command | Status of command |
| Key Management | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Reboot module | Crypto Officer, User | Command | Progress information |
| Self-test triggered by CO/User reboot | Crypto Officer, User | None | Error messages logged if a failure occurs |
| Update module firmware | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Configure non-security related module parameters | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Creation/use of secure management session between module and CO | Crypto Officer, User | IPSec inputs, commands, and data | IPSec outputs, status, and data |
| System Status and System Status – module LEDs | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Creation/use of secure mesh channel | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Openflow Agent | Crypto Officer, User | Commands and configuration data | Status of commands and configuration data |
| Generation and use of WPA2/WPA3 cryptographic keys | User, Wireless Client | WPA2/WPA3 inputs, commands and data | WPA2/WPA3 outputs, status and data |
| Use of WPA2/WPA3 Pre-shared secret for establishment of WPA2/WPA3 keys | User, Wireless Client | WPA2/WPA3 inputs, commands and data | WPA2/WPA3 outputs, status and data |
| Wireless bridging services | User, Wireless Client | Commands and configuration data | Status of commands and configuration data |
The following section lists the roles supported by the module, authentication mechanisms used by the module, and
The module supports the role-based authentication of Crypto Officer, User, and Wireless Client; no additional roles (e.g. Maintenance) are supported. Administrative operations carried out by the HPE Aruba Networking Mobility Controller or Mobility Conductor map to the Crypto Officer role. The Crypto Officer has the ability to configure, manage, and monitor the module, including the configuration, loading, and zeroization of SSPs. Configuration can be performed through a standalone Mobility Controller or by a Mobility Conductor if deployed in the environment. The Mobility Conductor also acts as a CO for the APs. The module supports multiple concurrent operators and internally maintains the separation of the roles assumed by each operator and the corresponding services. Refer to the section 4.2, Authentication below for details on the roles’ sessions authentication. Mobility Controller 14 APs must be deployed in a controller-based network running ArubaOS. For APs to be deployed in a controllerless network, refer to the most recent Aruba Instant NIST CMVP validation for guidance on Approved modes. 35| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Mode Method | Use Function | |||
|---|---|---|---|---|---|
| Wireless Client Role | AP | Description | Crypto Officer (CO) Role | User Role | |
| In the configuration, a wireless client can create a connection to the module using WPA2/WPA3 Pre- shared secret and access wireless network access services. | When the module is configured as a Control Plane Security protected AP, it is intended to be deployed in a local/private location (LAN, WAN, MPLS) relative to the Mobility Controller. The module provides cryptographic processing in the form of IPSec for all Control traffic to and from the Mobility Controller. | The CO is the Mobility Controller or Mobility Conductor that has the ability to configure, manage, and monitor the module, including the configuration, loading, and zeroization of SSPs. | In the configuration, the User operator shares the same services and authentication techniques as the Mobility Controller in the CO role. | Control Plane Security (CPSec) Protected AP configuration | |
| In the configuration, a wireless client can create a connection to the module using WPA2/WPA3 and access wireless network access/bridging services. When the Remote AP cannot communicate with the controller, the wireless client role authenticates to the module via WPA2/WPA3 Pre- shared secret only. | When the module is configured as a Remote AP, it is intended to be deployed in a remote location (relative to the Mobility Controller). The module provides cryptographic processing in the form of IPSec for all traffic to and from the Mobility Controller. | The CO is the Mobility Controller or Mobility Conductor that has the ability to configure, manage, and monitor the module, including the configuration, loading, and zeroization of SSPs. | In the configuration, the User operator shares the same services and authentication techniques as the Mobility Controller in the CO role. | Remote AP configuration | |
| In the configuration, a wireless client can create a connection to the module using WPA2/WPA3 and access wireless network access services. | When the module is configured as a Mesh Portal AP, it is intended to be connected over a physical wire to the Mobility Controller. These modules serve as the connection point between the Mesh Point and the Mobility Controller. Mesh Portals communicate with the Mobility Controller through IPSec and with Mesh Points via WPA2/WPA3 session. The Crypto Officer role is the Mobility Controller that authenticates via IKEv2 pre- shared key or RSA/ECDSA certificate authentication method, and Users are the "n" Mesh Points that authenticate via WPA2/WPA3 pre-shared key. | The CO is the Mobility Controller or Mobility Conductor that has the ability to configure, manage, and monitor the module, including the configuration, loading, and zeroization of SSPs. | In the configuration, the Mesh Portal AP and adjacent Mesh Point APs are in a given mesh cluster. The Mesh Portal AP must be physically wired to the Mobility Controller. | Mesh Portal AP configuration |
Non-Proprietary The defining characteristics of the roles depend on whether the module is configured in one of the four (4) AP configurations listed in the table below. If the AP is configured via corresponding HPE Aruba Networking Mobility Controllers that are in Approved mode and have been validated against FIPS 140-3 requirements, then the 36| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Mesh Point AP configuration | When the module is configured as a Mesh Point AP, it is an AP that establishes an all wireless path to the Mesh portal over WPA2/WPA3 and an IPSec tunnel via the Mesh Portal to the Controller. Note: for an AP-587 in Mesh Point AP configuration, it can only connect to another AP-587 in Mesh Portal AP configuration. | The CO is the Mobility Controller or Mobility Conductor that has the ability to configure, manage, and monitor the module, including the configuration, loading, and zeroization of SSPs. The first mesh AP configured is the only AP with the direct wired connection. | In the configuration, the Mesh Point AP and adjacent mesh APs are in a given mesh cluster. User role can be a Mesh Point AP or a Mesh Portal AP in the given mesh network. | In the configuration, a wireless client can create a connection to the module using WPA2/WPA3 and access wireless network access services. |
|---|
Non-Proprietary
The CO must follow the guidance below in section 11.6, Secure Operation, and in the ArubaOS 8.10 User Guide section titled Controller-based AP with AP Console Access to ensure the configured HPE Aruba operation, and is running the Approved version of ArubaOS (see the following subsections for details on the Once the AP is provisioned to be managed by the Controller, during any subsequent reboots of the AP, the AP boot process will continue automatically to boot the Approved version of ArubaOS (with the appropriate self-tests run) and the AP will be placed in the provisioned AP configuration by the Controller.
configurations, the HPE Aruba Networking Mobility Controller or Mobility Conductor implements the Crypto Crypto Officer’s authentication is accomplished via either Pre-shared secret (IKEv1), RSA digital certificate (IKEv1/IKEv2) or ECDSA digital certificate (IKEv2). The Mobility Conductor interacts with the APs through the Mobility Controller through provisioning of configurations.
the same IKEv1 pre-shared key or RSA/ECDSA certificate that is used by the Crypto Officer. With the module in the Approved mode of operation, the wireless client role (defined in each of the four (4) configurations are not permitted in Approved mode. When a Remote AP cannot communicate with the 37| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Key Size | |
|---|---|---|
| IKEv1 Pre- shared secret based authentication | Passwords are required to be a minimum of eight (8)15 ASCII characters and a maximum of 64 with a minimum of one letter and one number, or the password must be exactly 64 HEX characters. Assuming the weakest option of 8 ASCII characters with the listed restrictions, the probability of randomly guessing the correct sequence is one (1) in 3,608,347,333,959,680 (this calculation is based on the assumption that the typical standard American QWERTY computer keyboard has 10 Integer digits, 52 alphabetic characters, and 32 special characters providing 94 characters to choose from in total. The calculation should be 94^8 (Total number of 8-digit passwords) – 84^8 (Total number of 8-digit passwords without numbers) – 42^8 (Total number of 8-digit passwords without letters) + 32^8 (Total number of 8-digit passwords without letters or numbers, added since it’s double-counted in the previous two subtractions) = 3,608,347,333,959,680). At optimal network conditions (assuming 1ms round-trip latency), an attacker would only get 60,000 guesses per minute. Therefore, the associated probability of a successful random attempt during a one-minute period is 60,000/3,608,347,333,959,680, which meets the authentication objective. | Crypto Officer and User |
| RSA Certificate based authentication | The module supports 2048-bit RSA key authentication during IKEv1 and IKEv2. RSA 2048-bit keys correspond to 112 bits of security. Assuming the low end of that range, the associated probability of a successful random attempt is one (1) in 2^112, which meets the authentication objective. At optimal network conditions (assuming 1ms round- trip latency), an attacker would only get 60,000 guesses per minute. Therefore, the associated probability of a successful random attempt during a one-minute period is 60,000/2^112, which meets the authentication objective. | Crypto Officer and User |
| ECDSA Certificate based authentication | ECDSA signing and verification is used to authenticate to the module during IKEv1/IKEv2. Both P-256 and P-384 curves are supported. ECDSA P-256 provides 128 bits of equivalent security, and P-384 provides 192 bits of equivalent security. Assuming the low end of that range, the associated probability of a successful random attempt is one (1) in 2^128, which meets the authentication objective. At optimal network conditions (assuming 1ms round-trip latency), an attacker would only get 60,000 guesses per minute. Therefore, the associated probability of a successful random attempt during a one-minute period is 60,000/2^128, which meets the authentication objective. | Crypto Officer and User |
| WPA2/WPA3 Pre-shared secret based authentication | Passwords are required to be a minimum of eight (8)18 ASCII characters and a maximum of 63 with a minimum of one letter and one number, or the password must be exactly 64 HEX characters. Assuming the weakest option of 8 ASCII characters with the listed restrictions, the probability of randomly guessing the correct sequence is one (1) in 3,608,347,333,959,680 (this calculation is based on the assumption that the typical standard American QWERTY computer keyboard has 10 Integer digits, 52 alphabetic characters, and 32 special characters providing 94 characters to choose from in total. The calculation should be 94^8 (Total number of 8-digit passwords) – 84^8 (Total number of 8-digit passwords without numbers) – 42^8 (Total number of 8-digit passwords without letters) + 32^8 (Total number of 8-digit passwords without letters or numbers, added since it is double-counted in the previous two subtractions) = 3,608,347,333,959,680). At optimal network conditions (assuming 1ms round-trip latency), an attacker would only get 60,000 guesses per minute. Therefore, the associated probability of a successful random attempt during a one-minute period is 60,000/3,608,347,333,959,680, which meets the authentication objective. | Wireless Client and Mesh AP User |
Non-Proprietary The following table describes the relative strength of each supported authentication mechanism. Each authentication mechanism has been designed such that:
| Name | Description | Roles | Csps Accessed | Approved Functions | Access | Indicator |
|---|---|---|---|---|---|---|
| Update module firmware16 | The CO can trigger a module firmware update in a controller- based network by issuing related CLI commands (e.g. update) or WebGUI (e.g. Managed NetworkMaintenanceSoftware Management). | Crypto Officer, User17 | [11] Factory CA Public Key | RSA SigVer SHA2-256 (A2690, A2688) | E | Successful completion of firmware update shown via output of CLI command to show updated firmware version (e.g. show ver) or related WebGUI display updates (e.g. Managed NetworkConfig urationAccess Points).. |
The module provides various services depending on role. These are described in the sections below.
All Crypto Officer role services are the same for the module in the Approved mode of operation and the AP in any of the four (4) AP configurations - Remote AP configuration, CPSec protected AP configuration, Mesh Portal AP configuration, and Mesh Point AP configuration. The User role for Remote AP configuration and Control Plane Security (CPSec) Protected AP configuration supports the same services as the Crypto Officer role services. The User role for Mesh Portal AP configuration and Mesh Point AP configuration supports the same services as the Wireless Client role services. All Wireless Client role services are the same for the module in the Approved mode of operation and the AP in any of the four (4) AP configurations - Remote AP configuration, CPSec protected AP configuration, Mesh Portal AP configuration, and Mesh Point AP configuration. Table 22
| Name | Security Function | Use | Output | AES-GCM AES-CBC HMAC-SHA2-256 HMAC-SHA2-384 (A2690, A2689) | [12] IKE Pre-shared Key [15] SKEYSEED [18] IPSec Session Encryption Key [19] IPSec Session Authentication Key [21] IKE RSA Public Key [23] IKE ECDSA Public Key [24] WPA2/WPA3 Pre- shared Key | W W E E W W W |
|---|---|---|---|---|---|---|
| Creation/use of secure mesh channel19 | The module requires secure connections between mesh points using WPA2/WPA3. | Crypto Officer, User20 | Successful completion of mesh channel configurations shown via output of related CLI commands (e.g. ap mesh CLI commands for configuring AP mesh options) or WebGUI updates (e.g. Managed NetworkConfig urationAP Groups). | KBKDF KDA AES-CCM AES-GCM (A2690) | [24] WPA2/WPA3 Pre- shared Key [25] WPA2/WPA3 Pair- Wise Master Key (PMK) [26] WPA2/WPA3 Pairwise Transient Key (PTK) [27] WPA2/WPA3 Session Key [28] WPA2/WPA3 Group Master Key (GMK) [29] WPA2/WPA3 Group Transient Key (GTK) | E E G/E G/E G/E G/E |
| Generation and use of WPA2/WPA3 cryptographic keys | In all Approved modes, the links between the module and wireless client are secured with WPA2/WPA3. | User20, Wireless Client | Successful completion of wireless client configurations shown via output of related CLI commands (e.g. ap mesh CLI commands for configuring AP mesh options) or WebGUI updates (e.g. Managed NetworkConfig urationAP Groups). | KBKDF KDA AES-CCM AES-GCM (A2690) | [24] WPA2/WPA3 Pre- shared Key [25] WPA2/WPA3 Pair- Wise Master Key (PMK) [26] WPA2/WPA3 Pairwise Transient Key (PTK) [27] WPA2/WPA3 Session Key [28] WPA2/WPA3 Group Master Key (GMK) [29] WPA2/WPA3 Group Transient Key (GTK) | E E G/E G/E G/E G/E |
| Creation/use of secure management session between module and CO21 | The module supports use of IPSec for securing the management channel. | Crypto Officer, User22 | Successful completion of management channel configurations shown via output of CLI command to show management session tunnel status (e.g. show ap database- summary) or related WebGUI display updates (e.g. Managed NetworkConfig urationServices VPNCertifica tes for VPN Clients). | CTR_DRBG KAS-FFC-SSC SafePrimes KeyGen/KeyVer KAS-ECC-SSC ECDSA KeyGen/KeyVer/ SigGen/SigVer IKEv1 KDF HMAC-SHA2-256 HMAC-SHA2-384 IKEv2 KDF AES-CBC AES-GCM RSA SigGen/SigVer (A2690, A2689) | [1] DRBG Entropy Input [2] DRBG Seed [3] DRBG Key [4] DRBG V [5] DH Private Key [6] DH Public Key [7] DH Shared Secret [8] ECDH Private Key [9] ECDH Public Key [10] ECDH Shared Secret [12] IKE Pre-shared Key [13] skeyid [14] skeyid_d [15] SKEYSEED [16] IKE Session Authentication Key [17] IKE Session Encryption Key [18] IPSec Session Encryption Key [19] IPSec Session Authentication Key [20] IKE RSA Private Key [21] IKE RSA Public Key [22] IKE ECDSA Private Key [23] IKE ECDSA Public Key | E G/E G/E G/E G/E G/R/W/E G/E G/E G/R/W/E G/E W/E G/E G/E G/E G/E G/E G/E G/E E R/W/E E R/W/E |
| Use of WPA2/WPA3 Pre-shared secret for establishment of WPA2/WPA3 keys | When the module is in advanced Remote AP configuration, the links between the module and the Wireless Client are secured with WPA2/WPA3. This is authenticated with a shared secret only. | User23, Wireless Client | Successful completion of wireless client configurations shown via output of related CLI commands (e.g. show ap mesh) or WebGUI updates (e.g. Managed NetworkConfig urationAP Groups). | AES-CCM AES-GCM (A2690) | [24] WPA2/WPA3 Pre- shared Key | E |
Non-Proprietary User 18 User 20 W W E E W W W E E G/E G/E G/E G/E E E G/E G/E G/E G/E ). Remote AP and Control Plane Security (CPSec) Protected AP configurations only. This service is only applicable in the Mesh Portal AP and Mesh Point AP configurations. It is not applicable in Remote AP and Control Plane Security (CPSec) Protected AP configurations. Mesh Portal AP configuration and Mesh Point AP configuration only. 40| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Description | Roles | Csps Accessed | Approved Functions | Access | Indicator |
|---|---|---|---|---|---|---|
| Approved mode enable/disable | The CO enables Approved mode by following the procedures under the Secure Operation section to ensure the AP is configured for Secure Operations. The CO can disable Approved mode by reverting these changes. | Crypto Officer, User22 | None | None | None | Successful completion of Approved mode configurations shown via output of related CLI commands (e.g. show fips). |
Non-Proprietary User 22 User 23, E G/E G/E G/E G/E G/R/W/E G/E G/E G/R/W/E G/E W/E G/E G/E G/E G/E G/E G/E G/E E R/W/E E R/W/E E will be between the Mesh Portal and the controller, not the Mesh Point and the controller. 41| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Reboot module | The CO can remotely trigger a reboot of the AP from the Mobility Controller or Mobility Conductor. The module can also reboot by removing/replacing power. | None | None | Crypto Officer, User24 | None | Successful completion of module reboot shown via output of related CLI commands (e.g. reboot) or WebGUI updates (e.g. Managed Network Maintenance Software Management Reboot), and module reboots. |
|---|---|---|---|---|---|---|
| Self-test triggered by CO/User reboot | The CO can trigger a programmatic reset leading to self-test and initialization. | None | None | Crypto Officer, User24 | None | Status of self- tests in log after reboot shows successful completion of self-tests. |
| System Status | CO may view system status information through the secured management channel. | None | [See Creation/use of secure management session above] | Crypto Officer, User24 | [See Creation/use of secure managemen t session above] | Successful completion shown via output of CLI command to show AP status (e.g. show ap database) or related WebGUI status displays (e.g. Managed NetworkConfig urationAccess Points). |
| System Status – module LEDs | The CO may view system status by viewing the module’s LEDs. | None | None | Crypto Officer, User | None | Successful completion shown via module LEDs (refer to Status Indicator LEDs tables for each AP Series in section 2.3 above). |
| Configure non- security related module parameters | CO can configure various operational parameters that do not relate to security. | None | None | Crypto Officer, User24 | None | Status of command to show operational parameter settings shows successful completion of configurations. |
| Openflow Agent | Agent run on device for use with Mobility Conductor SDN. Leveraged by the SDN for discovering of hosts and networks, configuration of networks, and collection of statistics. | None | None | Crypto Officer, User24 | None | Successful completion shown via output of related CLI commands (e.g. show openflow). |
Non-Proprietary User 24 Remote AP and Control Plane Security (CPSec) Protected AP configurations only. 42| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary User 25, User 26 Z
The following table lists non-Approved services available in non-Approved mode (FIPS Settings: Mode Disabled). To indicate if the module is in Approved mode or non-Approved mode, issue the CLI command show fips (see Modes of Operation section above). To change from Approved mode (FIPS Settings: Mode Enabled) to non-Approved mode (FIPS Settings: Mode Disabled) requires the operator of the module to zeroize and reboot the module. The module does not support a degraded mode of operation. An un-provisioned AP, which by default does not serve any wireless clients, is out of scope of this validation. The Crypto Officer must ensure that the Wireless Access Point is kept in the Approved mode of operation. All of the Approved services (see Table 22 and Table 23 above) that are available in Approved mode are also available in non-Approved mode. Mesh Portal AP configuration and Mesh Point AP configuration only. Remote AP and Control Plane Security (CPSec) Protected AP configurations only. 43| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Description | Roles | Approved Functions | Indicator |
|---|---|---|---|---|
| IPSec/IKE using Triple-DES | IPSec/IKE key management using Triple-DES. This is a non-Approved service available in Approved mode but that is non-Approved for use. | Crypto Officer, User | Triple-DES | Implicit indication via successful completion of the service. |
| Suite-B (bSec) protocol | The Suite-B (bSec) protocol is a pre-standard protocol that has been proposed to the IEEE 802.11 committee as an alternative to 802.11i. This is a non-Approved service available in Approved mode but that is non- Approved for use. | Crypto Officer, User | Suite-B (bSec) protocol | Implicit indication via successful completion of the service. |
| Upgrade module firmware via the console port | The CO can update the module firmware using the console port if the FIPS TEL or seal is not blocking the console port and the console port has been enabled. This is a non-Approved service that is non-Approved for use in the Approved mode. | Crypto Officer, User27 | Triple-DES RSA SigVer SHA2-256 | Status of command to enable console and to show firmware version. |
| Debugging via the console port | The CO can issue commands for debugging using the console port if the FIPS TEL or seal is not blocking the console port and the console port has been enabled. This is a non-Approved service that is non-Approved for use. | Crypto Officer, User27 | None | Status of command to enable console and to debug. |
| Use of non- Approved algorithms and/or sizes. | If the module has not been provisioned to operate in one of the Approved modes, then non-Approved algorithms and/or sizes are available for use. This is a non-Approved service that is non-Approved for use. | Crypto Officer, User | Non-Approved algorithms and/or sizes | Implicit indication via successful completion of the service. |
Non-Proprietary Table 24
The module only allows the loading of trusted and verified firmware that is signed by HPE Aruba Networking within the module’s defined cryptographic boundary. Any firmware loaded into 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. HPE Aruba Networking firmware in electronic form is installed by HPE Aruba Networking technical support personnel or downloaded from the HPE Networking Support Portal (NSP) by authenticated licensed customer personnel. ArubaOS (in executable binary format) is the operating system for the HPE Aruba Networking hardware-based HPE Aruba Networking Mobility Conductors, Mobility Controllers, Gateways, and controller-managed Access Points (APs). ArubaOS (in OVA File format) is also the operating system for the HPE Aruba Networking virtual-based HPE Aruba Networking Mobility Controller Virtual Appliances and Mobility Conductor Virtual Appliances. Within the same version of ArubaOS (e.g. ArubaOS version 8.10), all features are the same, but there are components of ArubaOS that are appropriate for different hardware-based or virtual-based HPE Aruba Networking devices, which is why there are different ArubaOS executable binary formats for the same ArubaOS version available. The HPE Aruba Networking ArubaOS Bootloader Module is preloaded and shipped with each HPE Aruba Networking AP device and is executed to boot the ArubaOS operating system from the image partition after performing the firmware integrity test. Rebooting also zeroizes all SSPs prior to execution of the newly loaded firmware. The operator can initiate the firmware integrity test on demand by rebooting the module. The module performs a firmware integrity test when powered on and conditionally whenever a firmware load request is received (refer below to section 10, Self-Tests for details). Both the Firmware Integrity Test and Firmware Load Test use RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA2-256. All data output via the data output interface is inhibited until the software/firmware loading and load test has completed successfully. If the firmware integrity test fails, the module enters the error state (while in this state, the module provides no functionality). The temporary values generated during the firmware integrity test are zeroized upon completion of the integrity test. The operator can determine the version of the loaded firmware through reviewing the log after the firmware upgrade and by using the show status CLI command (use the link in section 1.8, Full Documentation to refer to ArubaOS 8.10 Command-Line Interface Reference Guide and ArubaOS 8.10 User Guide).
The module operates in a non-modifiable operational environment. The control plane Operating System (OS) is Linux, a real-time, multi-threaded operating system that supports memory protection between processes. Access to the underlying Linux implementation is not provided directly. Only HPE Aruba Networking provided interfaces are used, and the Command Line Interface (CLI) is a restricted command set. These operating control mechanisms protect against unauthorized execution, unauthorized modification, and unauthorized reading of SSPs, control and status data. The module only allows the loading of trusted and verified firmware that is signed by HPE Aruba Networking. Any firmware loaded into 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 module was tested on the platforms listed above in section 2.3, Table 5, Cryptographic Module Tested Configurations. 45| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
The HPE Aruba Networking Wireless Access Point is a scalable, multiple-chip standalone network device and is enclosed in a hard, opaque plastic case. The AP enclosure is resistant to probing (please note that this feature has not been validated as part of the FIPS 140-3 validation) and is opaque within the visible spectrum. The enclosure of the AP has been designed to satisfy FIPS 140-3 Level 2 physical security requirements. The HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points require Tamper-Evident Labels (TELs) (also known as seals) to allow the detection of the opening of the device and to block the Serial console port. To protect the Access Points (APs) from any tampering with the product, TELs should be applied by the Crypto Officer as covered in the sections below. When applied properly, the TELs allow the Crypto Officer to detect the opening of the device, or physical access to restricted ports like the serial console port (on the bottom of the device). HPE Aruba Networking provides FIPS 140-3 designated TELs which have met the physical security testing requirements for tamper evident labels under the FIPS 140-3 Standard. TELs are not endorsed by the Cryptographic Module Validation Program (CMVP). The tamper-evident labels shall be installed for the module to operate in the Approved mode of operation. HPE Aruba Networking provides double the required amount of TELs. If a customer requires replacement TELs, please call customer support and HPE Aruba Networking will provide the TELs. The Crypto officer shall be responsible for securing the extra TELs at a safe location and managing the use of the TELs.
Once applied, the TELs included with the Wireless Access Point cannot be surreptitiously broken, removed, or reapplied without an obvious change in appearance: Figure 25 - Tamper-Evident Labels If evidence of tampering is found with the TELs, the module must immediately be powered down and the Crypto Officer must be made aware of a physical security breach. Each TEL also has a unique serial number to prevent replacement with similar labels. To protect the device from tampering, TELs should be applied by the Crypto Officer as pictured below. 46| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
The Crypto Officer should employ Tamper-Evident Labels (TELs) (also known as seals) by referencing the following general application guidance and the device specific guidance in section 7.3, Required TEL Locations:
This section displays the locations of all TELs on each module (AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points). 47| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
The AP-514 and AP-515 are the same device in all areas except that the AP-514 uses external antennas and the AP-515 uses internal antennas (see above section 2.3.1, AP-510 Series). The AP-514 and AP-515 each require 3 TELs placed in the same locations on each: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 26 and 27 for placement (only AP-514 is shown). TELs 1 and 2 shall be placed on opposite sides of the enclosure along a segment that manifests the least curvature (as shown below). These TELs shall be applied such that between one-quarter and one-third of the TEL is adhered to the white cover of the AP enclosure. The remaining portion shall be wrapped around the side of the cover and the chassis. TELs must be firmly pressed down, removing any air bubbles or creases, to ensure proper adhesion. Figure 26
The AP-534 and AP-535 are the same device in all areas except that the AP-534 uses external antennas and the AP-535 uses internal antennas (see above section 2.3.2, AP-530 Series). The AP-534 and AP-535 each require 3 TELs placed in the same locations on each: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 28 and 29 for placement (only AP-535 is shown). TELs 1 and 2 shall be placed on opposite sides of the enclosure along a segment that manifests the least curvature (as shown below). These TELs shall be applied such that between one-quarter and one-third of the TEL is adhered to the white cover of the AP enclosure. The remaining portion shall be wrapped around the side of the cover and the chassis. TELs must be firmly pressed down, removing any air bubbles or creases, to ensure proper adhesion. Figure 28
The AP-584, AP-585, and AP-587 are all outdoor APs of different sizes (see above section 2.3.3, AP-580 Series). Each of the AP-580 Series APs (AP-584, AP-585 and AP-587) requires 3 TELs, one on each side to detect opening the device (label 1 and 2) and one covering the console port to detect access to a restricted port (label 3). The subsequent three sections illustrate the placement of each TEL by device. For all three models, TELs must be applied as described below, with the aesthetic cover removed. Once the TELs have been applied and their serial numbers recorded, the aesthetic cover should be reinstalled. Figure 30
The AP-584 requires 3 TELs: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 32, 33, and 34 for placement. Figure 32
The AP-585 requires 3 TELs: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 35, 36, and 37 for placement. Figure 35
The AP-587 requires 3 TELs: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 38, 39, and 40 for placement. Figure 38
The AP-635 is a campus AP (see above section 2.3.4, AP-630 Series). The AP-635 requires 3 TELs: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 41 and
TELs 1 and 2 shall be placed on opposite sides of the enclosure (as shown below). These TELs shall be applied such that between one-quarter and one-third of the TEL is adhered to the white cover of the enclosure. The remaining portion shall be wrapped around the side of the cover and the chassis. TEL 1 shall be located such that it lands on the flat surface of the chassis. TEL 2 shall be placed approximately opposite TEL 1. TELs must be firmly pressed down, removing any air bubbles or creases, to ensure proper adhesion. It is especially important that TELs 2 and 3 be firmly adhered to the chassis. Figure 41
The AP-655 is a campus AP (see above section 2.3.5, AP-650 Series). The AP-655 requires 3 TELs: one on each side edge (labels 1 and 2) to detect opening the device and one covering the console port (label 3) to detect access to a restricted port. See figures 43 and
TELs 1 and 2 shall be placed on opposite sides of the enclosure (as shown below). These TELs shall be applied such that between one-quarter and one-third of the TEL is adhered to the white cover of the enclosure. The remaining portion shall be wrapped around the side of the cover and the chassis. TEL 2 shall be located such that it lands on the flat surface of the chassis. TEL 1 shall be placed approximately opposite TEL 2. TELs must be firmly pressed down, removing any air bubbles or creases, to ensure proper adhesion. It is especially important that TEL 1 be firmly adhered to the chassis. Figure 43
| Physical Security Mechanism | Recommended Frequency of | Inspection/Test Guidance Details | |
|---|---|---|---|
| Inspection/Test | |||
| Tamper-evident labels (TELs) | Once per month | Examine for any sign of removal or tampering. See images above for locations of TELs. If any TELS are found to be missing or damaged, contact a system administrator immediately. | |
| Opaque module enclosure | Once per month | Examine module enclosure for any evidence of new openings or other access to the module internals. If any indication is found that indicates tampering, contact a system administrator immediately. |
Non-Proprietary The Crypto Officer should inspect/test the physical security mechanisms according to the Table 25 - Physical Security Inspection Guidelines
Since the module has not been purposely designed, built and publicly documented to include noninvasive mitigation techniques, the Non-Invasive Security requirements are not applicable. 56| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Strength | Security Function | Generation | Establishment | Storage | Zeroization | Import Export | # | Key / SSP Name / Type |
|---|---|---|---|---|---|---|---|---|---|
| Entropy inputs to the DRBG function, used to construct the DRBG Seed. | 512 bits | SP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690 | 64 bytes are retrieved from the entropy source read from entropy source on each call by any service that requires a random number. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 1 | DRBG Entropy Input – CSP |
| Input to the DRBG that determines the internal state of the DRBG (DRBG Key and V). | 384 bits | SP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690 | Generated using DRBG derivation function that includes the entropy input from the entropy source read from entropy source. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 2 | DRBG Seed – CSP |
| This is the internal DRBG key used for SP 800-90A Rev1 CTR_DRBG during generation of random numbers. | 256 bits | SP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690 | Derived from the DRBG Seed. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 3 | DRBG Key – CSP |
| Internal V value used as part of SP 800-90A Rev1 CTR_DRBG during generation of random numbers. | 128 bits | SP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690 | Derived from the DRBG Seed. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 4 | DRBG V – CSP |
| Used during the IPSec handshake to establish the Diffie-Hellman Shared Secret. | 224 bits | Diffie- Hellman Group 14 Cert. #A2690 Cert. #A2689 | Generated internally in compliance with Diffie-Hellman key agreement scheme by calling Approved DRBG (Cert. #A2690) | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 5 | Diffie-Hellman Private Key – CSP |
| Used during the IPSec handshake to establish the Diffie-Hellman Shared Secret. | 2048 bits | Diffie- Hellman Group 14 Cert. #A2690 Cert. #A2689 | Generated internally in compliance with Diffie-Hellman key agreement scheme by calling Approved DRBG (Cert. #A2690) | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: in plaintext | 6 | Diffie-Hellman Public Key – PSP |
| Used for deriving IPSec/IKE cryptographic keys. | 2048 bits | Diffie- Hellman Group 14 Cert. #A2690 Cert. #A2689 | N/A | Established during Diffie- Hellman Exchange. | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 7 | Diffie-Hellman Shared Secret – CSP |
| Used for establishing EC Diffie- Hellman Shared Secret. | Curves: P-256 or P-384 | EC Diffie- Hellman Cert. #A2690 Cert. #A2689 | Generated internally by calling Approved DRBG (Cert. #A2690) during EC Diffie-Hellman Exchange. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 8 | EC Diffie- Hellman Private Key – CSP |
| Used for establishing EC Diffie- Hellman Shared Secret. | Curves: P-256 or P-384 | EC Diffie- Hellman Cert. #A2690 Cert. #A2689 | Generated internally by calling Approved DRBG (Cert. #A2690) during EC Diffie-Hellman Exchange. | N/A | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: in plaintext | 9 | EC Diffie- Hellman Public Key – PSP |
| Used for deriving IPSec/IKE cryptographic keys. | Curves: P-256 or P-384 | EC Diffie- Hellman Cert. #A2690 Cert. #A2689 | N/A | Established during EC Diffie- Hellman Exchange. | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 10 | EC Diffie- Hellman Shared Secret – CSP |
| This is a RSA public key. Used for Firmware verification. | 2048 bits | RSA | N/A Loaded into the module during manufacturing (i.e. out of scope of module). | N/A | Stored in TPM | Since this is a public key and protected in TPM, the zeroization requirements do not apply. | Import: N/A Export: N/A | 11 | Factory CA Public Key –PSP |
| Used for IKEv1 peers authentication. | 8 - 64 ASCII or 64 HEX characters | Shared Secret Cert. #A2690 | Entered by CO role. | N/A | Stored in Flash memory obfuscated with KEK | Zeroized by using command ‘ap wipe out flash’. | Import: in plaintext Export: N/A | 12 | IKE Pre- shared Key29 – CSP |
| A shared secret known only to IKEv1 peers. Used for deriving other keys in IKEv1 protocol implementation. | 160 / 256 / 384 bits | Shared Secret Cert. #A2690 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1). | Stored in SDRAM memory (plaintext) | Zeroized by rebooting the module. | Import: N/A Export: N/A | 13 | Skeyid – CSP |
| A shared secret known only to IKEv1 peers. Used for deriving IKEv1 Session Authentication Key. | 160 / 256 / 384 bits | Shared Secret Cert. #A2690 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1). | Stored in SDRAM memory (plaintext) | Zeroized by rebooting the module. | Import: N/A Export: N/A | 14 | skeyid_d – CSP |
| A shared secret known only to IKEv2 peers. Used for deriving other keys in IKEv2 protocol. | 160 / 256 / 384 bits | Shared Secret Cert. #A2689 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv2). | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 15 | SKEYSEED – CSP |
| The IKE session (IKE Phase I) authentication key. Used for IKEv1/IKEv2 payload integrity verification. | 160 / 256 / 384 bits | HMAC-SHA- 1/256/384 Cert. #A2690 Cert. #A2689 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1/IKEv2). | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 16 | IKE Session Authentication Key – CSP |
| The IKE session (IKE Phase I) encrypt key. Used for IKE payload protection. | 128 / 192 / 256 bits | AES (CBC) Cert. #A2690 Cert. #A2689 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1/IKEv2). | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 17 | IKE Session Encryption Key – CSP |
| The IPSec (IKE phase II) encryption key. Used for IPSec traffics protection. IPSec session encryption keys can also be used for the Double Encrypt feature. | 128 / 192 / 256 bits 128 / 256 bits | AES (CBC) and AES (GCM) Cert. #A2690 Cert. #A2689 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1/IKEv2). | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 18 | IPSec Session Encryption Key – CSP |
| The IPSec (IKE Phase II) authentication key. Used for IPSec traffics integrity verification. | 160 bits | HMAC-SHA- 1 Cert. #A2690 Cert. #A2689 | N/A | Derived via key derivation function defined in SP 800-135 Rev1 KDF (IKEv1/IKEv2). | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 19 | IPSec Session Authentication Key – CSP |
| This is the RSA private key. Used for RSA signature signing in either IKEv1 or IKEv2. | 2048 bits | RSA Private Key Cert. #A2690 Cert. #A2689 | Generated by the module in compliance with FIPS 186-4 RSA key pair generation method. In both IKEv1 and IKEv2, DRBG (Cert. #A2690) is called for key generation. This key can also be entered by the CO. | N/A | Stored in Flash memory obfuscated with KEK | Zeroized by using command ‘ap wipe out flash’. | Import: N/A Export: N/A | 20 | IKE RSA Private Key – CSP |
| This is the RSA public key. Used for RSA signature verification in either IKEv1 or IKEv2. | 2048 bits | RSA Public Key Cert. #A2690 Cert. #A2689 | Generated by the module in compliance with FIPS 186-4 RSA key pair generation method. In both IKEv1 and IKEv2, DRBG (Cert. #A2690) is called for key generation. This key can also be entered by the CO. | N/A | Stored in Flash memory obfuscated with KEK | Zeroized by using command ‘ap wipe out flash’. | Import: N/A Export: N/A | 21 | IKE RSA Public Key – PSP |
| This is the ECDSA private key. Used for ECDSA signature signing in IKEv2. | Curves: P-256 or P-384 | ECDSA suite B Cert. #A2689 | Generated by the module in compliance with FIPS 186-4 ECDSA key pair generation method. In IKEv2, DRBG (Cert. #A2690) is called for key generation. This key can also be entered by the CO. | N/A | Stored in Flash memory obfuscated with KEK | Zeroized by using command ‘ap wipe out flash’. | Import: N/A Export: N/A | 22 | IKE ECDSA Private Key – CSP |
| This is the ECDSA public key. Used for ECDSA signature verification in IKEv2. | Curves: P-256 or P-384 | ECDSA suite B Cert. #A2689 | Generated by the module in compliance with FIPS 186-4 ECDSA key pair generation method. In IKEv2, DRBG (Cert. #A2690) is called for key generation. This key can also be entered by the CO. | N/A | Stored in Flash memory obfuscated with KEK | Zeroized by using command ‘ap wipe out flash’. | Import: N/A Export: N/A | 23 | IKE ECDSA Public Key – PSP |
| Used for WPA2/WPA3 client/server authentication. | 8-63 ASCII or 64 HEX characters | Shared Secret Cert. #A2690 | Entered by CO role. | N/A | Stored in Flash memory (obfuscated with KEK). | Zeroized by using command ‘ap wipe out flash’. | Import: in plaintext Export: N/A | 24 | WPA2/WPA3 Pre-shared Key – CSP |
| Used to derive the Pairwise Transient Key (PTK) for WPA2/WPA3 communications. | 256 bits | Shared Secret Cert. #A2690 | The PMK is transferred to the module, protected by IPSec secure tunnel. | N/A | Stored in SDRAM (plaintext). | Zeroized by rebooting the module. | Import: in plaintext Export: N/A | 25 | WPA2/WPA3 Pair-Wise Master Key (PMK) – CSP |
| Used to derive the WPA2/WPA3 Session Key. | 384 bits | HMAC Cert. #A2690 | N/A | Derived via key derivation function defined in SP 800-108 Rev1 and SP 800-56C Rev2. | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 26 | WPA2/WPA3 Pairwise Transient Key (PTK) – CSP |
| Used as the WPA2/WPA3 Session Key. | 128 bits, 128 / 256 bits | AES (CCM) and AES (GCM) (WPA3 only) Cert. #A2690 | N/A | Derived during WPA2/WPA3 4- way handshake by using the KDF defined in SP 800-108 Rev1 and SP 800-56C Rev2. | Stored in SDRAM memory (plaintext). | Zeroized by rebooting the module. | Import: N/A Export: N/A | 27 | WPA2/WPA3 Session Key – CSP |
| Used to derive WPA2/WPA3 Group Transient Key GTK. | 256 bits | Shared Secret Cert. #A2690 | Generated internally by calling Approved DRBG (Cert. #A2690). | N/A | Stored in SDRAM memory (plaintext) | Zeroized by rebooting the module | Import: N/A Export: N/A | 28 | WPA2/WPA3 Group Master Key (GMK) – CSP |
| The GTK is the WPA2/WPA3 session key used for broadcast communications protection. | 256 bits | AES (CCM) and AES (GCM) Cert. #A2690 | N/A | Derived from WPA2/WPA3 GMK by using the KDF defined in SP 800-108 Rev1 and SP 800-56C Rev2. | Stored in SDRAM memory (plaintext) | Zeroized by rebooting the module | Import: N/A Export: N/A | 29 | WPA2/WPA3 Group Transient Key (GTK) – CSP |
The following are the Sensitive Security Parameters (SSPs) and Keys used in the module. The operator is responsible for zeroizing all SSPs when switching modes. As specified in the Zeroization column of the following table, the majority of SSPs/Keys used in the module are zeroized implicitly by rebooting the module, indicated via the successful completion of the module reboot service. Also as specified in the Zeroization column of the following table, there are a minority of SSPs/Keys used in the module that are zeroized by using the command ‘ap wipe out flash’, indicated via the status of the ‘ap wipe out flash’ command. # N/A N/A N/A 57| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # N/A N/A N/A N/A during DiffieHellman N/A DiffieHellman DiffieHellman DiffieHellman 58| EC DiffieHellman EC DiffieHellman HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # EC DiffieHellman EC DiffieHellman EC DiffieHellman EC DiffieHellman N/A N/A N/A N/A N/A IKE Preshared Key 29 Not used in Mesh Point AP configuration. Applicable only to Remote AP and Mesh Portal modes 59| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # N/A N/A N/A 60| N/A N/A HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # N/A HMAC-SHA1 61| N/A N/A HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # 62| B N/A N/A HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # B N/A N/A N/A N/A While operating in Mesh Point AP configuration or Mesh Portal AP configuration, the AP will only use PSK for WPA2/WPA3. Remote AP configuration and CPSec Protected AP configuration use both Certificate-based and PSK-based WPA2/WPA3. HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary # N/A 64| N/A N/A HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
| Name | Key Size | |
|---|---|---|
| Details | Minimum Number of Bits of Entropy | Entropy Sources |
| The module employs a SP 800-90A Rev1-compliant Deterministic Random Bit Generator (DRBG) using an AES-256 CTR_DRBG mechanism with DF for random number generation (Cert. #A2690). The module performs the DRBG health tests as defined in section 11.3 of SP 800-90A Rev1. The module uses a SP 800-90B-compliant non-physical entropy source that uses CPU jitter provided by the operational environment as a noise source (Jitterentropy (JENT) with SHA-3 as the vetted conditioning component). | Oversampling of 512 bits is performed to ensure that 256 bits of entropy is available to the DRBG. | Aruba CPU Jitter Entropy Source (see NIST Entropy Source Validation (ESV) program certificate #7) |
Non-Proprietary Notes:
| Name | Algorithm Or Test | Test Type | Details | HPE Aruba Networking Cryptographic Module Component | Test Properties | Condition |
|---|---|---|---|---|---|---|
| RSA Firmware Integrity Test | RSA Firmware Integrity Test | SigVer | The ArubaOS Bootloader Module performs the firmware integrity test when module powered on, before booting the ArubaOS operating system. | ArubaOS Bootloader Module | 2048-bit public key, PKCS#1-v1.5, signature verification with SHA2-256 message digest | |
| RSA | RSA | KAT | Verify | ArubaOS Bootloader Module | 2048, PKCS#1-v1.5 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms |
| SHS | SHS | KAT | ArubaOS Bootloader Module | SHA2-256 |
| Name | Algorithm Or Test | Test Type | Details | HPE Aruba Networking Cryptographic Module Component | Test Properties | Condition |
|---|---|---|---|---|---|---|
| RSA Firmware Integrity Test | RSA Firmware Integrity Test | SigVer | The ArubaOS Bootloader Module performs the firmware integrity test when module powered on, before booting the ArubaOS operating system. | ArubaOS Bootloader Module | 2048-bit public key, PKCS#1-v1.5, signature verification with SHA2-256 message digest | |
| RSA | RSA | KAT | Verify | ArubaOS Bootloader Module | 2048, PKCS#1-v1.5 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms |
| SHS | SHS | KAT | ArubaOS Bootloader Module | SHA2-256 | ||
| AES ECB | AES ECB | KAT | Encrypt, Decrypt | ArubaOS OpenSSL Module | AES-ECB-128 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms |
| AES CCM | AES CCM | KAT | Encrypt, Decrypt | ArubaOS OpenSSL Module | AES-CCM-192 | |
| AES GCM | AES GCM | KAT | Encrypt, Decrypt | ArubaOS OpenSSL Module | AES-GCM-256 | |
| DRBG | DRBG | KAT | SP 800-90A Rev1 Section 11.3 Health Tests for CTR_DRBG (Instantiate, Generate and Reseed) | ArubaOS OpenSSL Module | AES-CTR-256, CTR_DRBG with DF, with and without PR | |
| ArubaOS CPU Jitter Entropy Source | RCT | SP800-90B Section 4.4 Approved Continuous Health Tests (RCT and APT) | ArubaOS CPU Jitter Entropy Source | Tests are applied continuously to digitized samples of the output of the non-physical noise source | ||
| ECDSA | ECDSA | KAT | Sign, Verify | ArubaOS OpenSSL Module | P-256, P-384 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms |
| HMAC | HMAC | KAT | ArubaOS OpenSSL Module | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512 | ||
| KAS-SSC-ECC | KAS-SSC-ECC | KAT | Ephemeral Unified SP 800- 56A Rev3 based | ArubaOS OpenSSL Module | Primitive ‘Z’ computation with P-256 curve | |
| KAS-SSC-FFC | KAS-SSC-FFC | KAT | dhEphem SP 800-56A Rev3 based | ArubaOS OpenSSL Module | Shared secret computation, p=2048, q=256 | |
| KDA | KDA | KAT | SP 800-56C Rev2 based | ArubaOS OpenSSL Module | Two-step KDF: HMAC-SHA-1, L=2048 | |
| KBKDF | KBKDF | KAT | SP 800-108 Rev1 based | ArubaOS OpenSSL Module | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384 | |
| KDF135 | KDF135 | KAT | SP 800-135 Rev1 based: IKEv1 | ArubaOS OpenSSL Module | Key derivation | |
| RSA | RSA | KAT | Sign, Verify | ArubaOS OpenSSL Module | 2048, PKCS#1-v1.5 | |
| SHS | SHS | KAT | ArubaOS OpenSSL Module | SHA-1, SHA2-256, SHA2-384, SHA2-512 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms | |
| Triple-DES | Triple-DES | KAT | Encrypt, Decrypt, Triple-DES used with KEK only to obfuscate internal keys. No security claimed. | ArubaOS OpenSSL Module | TDES-ECB-192 | |
| SHA-3 | SHA-3 | KAT | FIPS 202 based | ArubaOS CPU Jitter Entropy Source | SHA3-256 | Run when module powered on, which is prior to the first operational use of the cryptographic algorithm |
| AES CBC | AES CBC | KAT | Encrypt, Decrypt | ArubaOS Crypto Module | AES-CBC-256 | Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms |
| AES GCM | AES GCM | KAT | Encrypt, Decrypt | ArubaOS Crypto Module | AES-GCM-256 | |
| ECDSA | ECDSA | KAT | Sign, Verify | ArubaOS Crypto Module | P-256 | |
| HMAC | HMAC | KAT | ArubaOS Crypto Module | HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512 | ||
| KAS-SSC-ECC | KAS-SSC-ECC | KAT | Ephemeral Unified SP 800- 56A Rev3 based | ArubaOS Crypto Module | Primitive ‘Z’ computation with P-256 curve | |
| KAS-SSC-FFC | KAS-SSC-FFC | KAT | dhEphem SP 800-56A Rev3 based | ArubaOS Crypto Module | Shared secret computation, p=2048, q=256 | |
| KDF135 | KDF135 | KAT | SP 800-135 Rev1 based: IKEv2 | ArubaOS Crypto Module | Key derivation | |
| RSA | RSA | KAT | Sign, Verify | ArubaOS Crypto Module | 2048, PKCS#1-v1.5 | |
| SHS | SHS | KAT | ArubaOS Crypto Module | SHA-1, SHA2-256, SHA2-384, SHA2-512 | ||
| Triple-DES | Triple-DES | KAT | Encrypt, Decrypt, Triple-DES used with KEK only to obfuscate internal keys. No security claimed. | ArubaOS Crypto Module | TDES-CBC-192 | Run when module powered on, which is prior to the first operational use of the cryptographic algorithm |
| ECC key pairs | ECC key pairs | PCT | Sign, Verify | ArubaOS OpenSSL Module | P-256, P-384 | Each run on key pair generation |
| FFC key pairs | FFC key pairs | PCT | SP800-56A Rev3 assurances as per SP 800-56A Rev3 Section 5.6.2.1.4 for PCT | ArubaOS OpenSSL Module | DH key pair generation | |
| RSA key pairs | RSA key pairs | PCT | Sign, Verify | ArubaOS OpenSSL Module | 2048, PKCS#1-v1.5 | |
| ECC key pairs | ECC key pairs | PCT | Sign, Verify | ArubaOS Crypto Module | P-256, P-384 | |
| FFC key pairs | FFC key pairs | PCT | SP800-56A Rev3 assurances as per SP 800-56A Rev3 Section 5.6.2.1.4 for PCT | ArubaOS Crypto Module | DH key pair generation | |
| RSA key pairs | RSA key pairs | PCT | Sign, Verify | ArubaOS Crypto Module | 2048, PKCS#1-v1.5 | |
| RSA Firmware Load Test | RSA Firmware Load Test | SigVer | ArubaOS OpenSSL Module | 2048, PKCS#1-v1.5, signature verification with SHA2-256 | Test is applied by the main ArubaOS code for firmware load during operation | |
| RSA Firmware Load Test | RSA Firmware Load Test | SigVer | ArubaOS Bootloader Module | 2048, PKCS#1-v1.5, signature verification with SHA2-256 | Test is applied by the ArubaOS Bootloader Module on request to load firmware |
The module performs Cryptographic Algorithm Self-Tests (CASTs) when powered on, regardless of which of the four (4) AP configurations is selected. The module also performs Pre-Operational Self-Tests (POSTs) automatically when the module is powered on. In addition, the module performs Conditional tests in the Approved mode of operation (refer to the Modes of Operation section). When a cryptographic algorithm self-test or pre-operational self-test fails, or when a conditional self-test fails, the module enters the Critical Error state (while in this state, the module provides no functionality including inhibition of data output), logs the error, and reboots automatically. During the process when the HPE Aruba Networking Access Point (AP) is powered on and booted, RSA and SHS Conditional Cryptographic Algorithm Self-Test are executed after ArubaOS is booted. The module transitions to the operational state only after the cryptographic algorithm and pre-operational self-tests are The module performs the following Pre-Operational Self-Tests (POSTs): Table 28
Non-Proprietary 67| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary 68| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary Table 30
Non-Proprietary Table 31
This section specifies the procedures for secure installation, initialization, provisioning, start-up, configuration, and operation of the module. Guidance is provided, including references to where to find more guidance documentation.
The units are shipped to the Crypto Officer in factory-sealed boxes using trusted commercial carrier shipping companies. The Crypto Officer should examine the carton for evidence of tampering. Tamper-evidence includes tears, scratches, and other irregularities in the packaging.
The product carton should include the following:
You will need the following during installation:
For detailed instructions on identifying AP installation locations, refer to the specific HPE Aruba Networking 5XX or 6XX Series Wireless Access Points Installation Guide, and the section, Identifying Specific Installation Locations. 71| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
The HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points meet FIPS 140-3 Level 2 requirements. The information below describes how to keep the Wireless Access Point in the Approved mode of operation. The module can be configured to be in one of four (4) AP configurations and in the Approved mode of operation (see section 2.5, Modes of Operation) via corresponding HPE Aruba Networking Mobility Controllers that are in Approved mode and that have been validated against FIPS 140-3 requirements, provided that the guidelines on services, algorithms, physical security and key management found in this Security Policy are followed.
The Crypto Officer must ensure that the Wireless Access Point is always operating in the Approved mode of operation. This can be achieved by ensuring the following:
Non-Proprietary
Although outside the boundary of the Wireless Access Point, the operator should be directed to be careful not to provide authentication information and session keys to other parties. Note that the module does not possess persistent storage of SSPs. Any SSP value only exists in volatile memory and that value vanishes when the module is powered off. In the case when the module’s power is lost and then restored, a new key for use with the AES-GCM encryption/decryption shall be established. HPE Aruba Networking generally recommends that the communication between the Controller/Gateways and Access Points be restricted either by having a dedicated layer 2 segment/VLAN or, if Controller/Gateways and Access Points cross layer 3 boundaries, to have firewall policies restricting the communication of these authorized devices.
The HPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP655 Access Points meet FIPS 140-3 Security Level 2 requirements. The sections below describe how to place and keep the Wireless Access Point in the Approved mode of operation. The Crypto Officer (CO) must ensure that the Wireless Access Point is kept in the Approved mode of operation. The Wireless Access Point can be configured to be in one of four (4) AP configurations: Control Plane Security (CPSec) Protected AP, Remote AP and the two (2) Mesh AP configurations, Mesh Portal AP and Mesh Point AP. The module must operate in Approved mode (see Modes of Operation section above). By default, the Wireless Access Point operates in the standard non-Approved mode. The Access Point is managed by an HPE Aruba Networking Mobility Controller in Approved mode, and access to the Mobility Controller’s administrative interface via a non-networked general purpose computer is required to assist in placing the module in Approved mode. The Controller used to provision the AP is referred to as the “staging controller”. The staging controller must be provisioned with the appropriate HPE Aruba Networking firmware image for the module, which has been validated to FIPS 140-3, prior to initiating AP provisioning. Additionally, if a Mobility Conductor appliance is deployed in the environment, provisioning of the APs can be performed by passing policies down from the Mobility Conductor to the Mobility Controller which then provisions the AP.
The Crypto Officer shall perform the following steps to ensure the APs are placed in the secure operational state:
Non-Proprietary
8.10 User Guide: Remote AP configuration, CPSec protected AP configuration, Mesh Portal AP
configuration, or Mesh Point AP configuration.
For FIPS 140-3 compliance, users cannot be allowed to access the Wireless Access Point until the CO changes the mode of operation on the staging controller to the Approved mode. There is only one way to enable Approved mode on the staging controller:
Login to the staging controller using an SSHv2 client. Enable Approved mode using the following commands: #configure terminal Enter Configuration commands, one per line. End with CNTL/Z (config) #fips enable (config) #exit #write memory Saving Configuration... Configuration Saved. To verify that Approved mode has been enabled, issue the command: show fips to see: FIPS Settings: Mode Enabled If logging in to the staging controller via the Mobility Conductor, please reference the ArubaOS 8.10 User Guide on how to access a managed device. Once connected to the staging controller, the above commands will successfully execute. 74| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Non-Proprietary Please abide by the sub-section above in this section named, Crypto Officer Management, and subsection below named, Non-Approved Approved Mode Configurations.
When operating in the Approved mode, the following configuration options are non-Approved:
Documentation for any HPE Aruba Networking product can be found on the HPE Networking Support Portal (NSP). Filters can be used to limit the displayed results by Product(s), Product Series, Version(s), and File Category. For example,
The following HPE Aruba Networking documents can be referenced to ensure that ArubaOS and the HPE Aruba Networking hardware-based equipment or HPE Aruba Networking virtual appliances that run ArubaOS are installed and operated correctly in Approved mode:
To determine if an HPE Aruba Networking product is considered end of life, refer to the HPE Aruba Networking end-of life information at https://networkingsupport.hpe.com/end-of-life. If an HPE Aruba Networking product is deemed end-of-life, the CO should work with their HPE Aruba Networking representative to determine the appropriate HPE Aruba Networking product upgrade path to use a newer Approved version. Note that any firmware loaded into 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 module does not possess persistent storage of SSPs. Any SSP value only exists in volatile memory and that value vanishes when the module is powered off. For secure sanitization, firstly the module shall be powered off. Then, if the module is deprecated, the module will be replaced with a newer Approved version with the help of an HPE Aruba Networking-Certified Mobility Professional (ACMP).
As per IG 12.A, since the module has not been purposely designed, built and publicly documented to mitigate one or more specific attacks, the Mitigation of Other Attacks requirements are not applicable. 76| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy