All modules
CMVP Validated Module · FIPS 140-3 Security Policy

AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points

Certificate#4916StandardFIPS 140-3Level2TypeHardwareEmbodimentMulti-Chip Stand AloneStatusActiveVendorAruba, a Hewlett Packard Enterprise company
Critical review priority  ·  exposes boot-chain verification, firmware-update authentication, network crypto parser/protocol  ·  last validated 19 months ago. How this is derived →

Certificate

StandardFIPS 140-3
Overall level2
Module typeHardware
EmbodimentMulti-Chip Stand Alone
StatusActive
Sunset date12/11/2026
CaveatInterim validation. When operated in the approved mode, with tamper evident labels installed as indicated in the Security Policy
VendorAruba, a Hewlett Packard Enterprise company
Hardware versionsAP-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)

Approved Algorithms (59)

AlgorithmACVP Cert
AES-CBCA2689
AES-CBCA2690
AES-CCMA2690
AES-CTRA2690
AES-ECBA2690
AES-GCMA2689
AES-GCMA2690
Counter DRBGA2690
DSA KeyGen (FIPS186-4)A2689
DSA KeyGen (FIPS186-4)A2690
DSA PQGGen (FIPS186-4)A2689
DSA PQGGen (FIPS186-4)A2690
ECDSA KeyGen (FIPS186-4)A2689
ECDSA KeyGen (FIPS186-4)A2690
ECDSA KeyVer (FIPS186-4)A2689
ECDSA KeyVer (FIPS186-4)A2690
ECDSA SigGen (FIPS186-4)A2689
ECDSA SigGen (FIPS186-4)A2690
ECDSA SigVer (FIPS186-4)A2689
ECDSA SigVer (FIPS186-4)A2690
HMAC-SHA-1A2689
HMAC-SHA-1A2690
HMAC-SHA2-256A2689
HMAC-SHA2-256A2690
HMAC-SHA2-384A2689
HMAC-SHA2-384A2690
KAS-ECC-SSC Sp800-56Ar3A2689
KAS-ECC-SSC Sp800-56Ar3A2690
KAS-FFC-SSC Sp800-56Ar3A2689
KAS-FFC-SSC Sp800-56Ar3A2690
KDA TwoStep Sp800-56Cr1A2690
KDF IKEv1A2690
KDF IKEv2A2689
KDF SP800-108A2690
RSA KeyGen (FIPS186-4)A2689
RSA KeyGen (FIPS186-4)A2690
RSA SigGen (FIPS186-4)A2689
RSA SigGen (FIPS186-4)A2690
RSA Signature PrimitiveA2689
RSA Signature PrimitiveA2690
RSA SigVer (FIPS186-2)A2689
RSA SigVer (FIPS186-2)A2690
RSA SigVer (FIPS186-4)A2688
RSA SigVer (FIPS186-4)A2689
RSA SigVer (FIPS186-4)A2690
Safe Primes Key GenerationA2689
Safe Primes Key GenerationA2690
Safe Primes Key VerificationA2689
Safe Primes Key VerificationA2690
SHA-1A2689
SHA-1A2690
SHA2-256A2688
SHA2-256A2689
SHA2-256A2690
SHA2-384A2689
SHA2-384A2690
SHA2-512A2689
SHA2-512A2690
SHA3-256A2738

Security Levels (Table 1)

Requirement areaLevel
Cryptographic Module Specification2
Cryptographic Module Interfaces2
Roles, Services, and Authentication2
Software/Firmware Security2
Operational EnvironmentN/A
Physical Security2
Non-Invasive SecurityN/A
Sensitive Security Parameter Management2
Self-Tests2
Life-Cycle Assurance2
Mitigation of Other AttacksN/A

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

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;
Underlying clues
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;

Security Policy, page by page

Page 1

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

Page 2

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

6280 America Center Dr

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

Page 3

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

Page 4

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

Page 5
VersionDateDescription
1.0October 2024Initial 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

Page 6
1 General

This section describes:

1.1 Purpose of this Document

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.

1.2 Additional HPE Aruba Networking Product Information

More information is available from the following sources:

Page 7
1.3 Acronyms and Abbreviations

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

Page 8
Security level
NameISO SectionRequirementLevel
11General2
22Cryptographic Module Specification2
33Cryptographic Module Interfaces2
44Roles, Services, and Authentication2
55Software/Firmware Security2
66Operational EnvironmentN/A
77Physical Security2
88Non-Invasive SecurityN/A
99Sensitive Security Parameter Management2
1010Self-Tests2
1111Life-Cycle Assurance2
1212Mitigation of Other AttacksN/A
OverallOverallOverall Security Rating of the Module2
1.4 Security Levels

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

Page 9
ComponentTypeVersionsCAVP Cert. #
ArubaOS OpenSSL ModuleFirmware1.0A2690
Aruba CPU Jitter Entropy SourceFirmware3.3.1A2738
ArubaOS Crypto ModuleFirmware1.0A2689
ArubaOS Bootloader ModuleFirmware1.0A2688
TypeVersions
HardwareHPE Aruba Networking AP-514, AP-515, AP-534, AP-535, AP-584, AP-585, AP-587, AP-635 and AP-655 Access Points (APs)
FirmwareArubaOS 8.10.0.5-FIPS
2 Cryptographic Module Specification
2.1 Description

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

2.1.1 Cryptographic Module Boundary

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

2.2 Version Information

Table 4

Page 10
Module configuration
NameModelHardware VersionFirmware VersionProcessorFeatures
AP-514-USF1AP-514-USF1HPE SKU Q9H68AArubaOS 8.10Broadcom BCM (64-bit ARMv8) - No acceleration2.3.1 AP-510 Series
AP-515-USF1AP-515-USF1HPE SKU Q9H73AArubaOS 8.10
AP-534-USF1AP-534-USF1HPE SKU JZ342AArubaOS 8.10Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration2.3.2 AP-530 Series
AP-535-USF1AP-535-USF1HPE SKU JZ347AArubaOS 8.10
AP-584-US TAA AP-584-RW TAAAP-584-US TAA AP-584-RW TAAHPE SKU R7T14A HPE SKU R7T15AArubaOS 8.10Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration2.3.3 AP-580 Series
AP-585-US TAA AP-585-RW TAAAP-585-US TAA AP-585-RW TAAHPE SKU R7T19A HPE SKU R7T20AArubaOS 8.10
AP-587-US TAA AP-587-RW TAAAP-587-US TAA AP-587-RW TAAHPE SKU R7T24A HPE SKU R7T25AArubaOS 8.10
AP-635-RW TAA AP-635-US TAAAP-635-RW TAA AP-635-US TAAHPE SKU R7J32A HPE SKU R7J33AArubaOS 8.10Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration2.3.4 AP-630 Series
AP-655-RW TAA AP-655-US TAAAP-655-RW TAA AP-655-US TAAHPE SKU R7J43A HPE SKU R7J44AArubaOS 8.10Qualcomm IPQ (64-bit ARM Cortex A53) - No acceleration2.3.5 AP-650 Series
2.3 Operating Environments

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

Page 11
2.3.1 AP-510 Series

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

Page 12

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:

Page 13

Non-Proprietary

Page 14
LED TypeColor/StateMeaning
System Status (Left)OffAP powered off
Green - BlinkingDevice booting; not ready
Green - SolidDevice ready
Amber - SolidDevice ready; power-save mode (802.3af PoE): * Single radio * USB disabled
Green or Amber FlashingDevice ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode
RedSystem error condition
Radio Status (Right)OffAP powered off, or both radios disabled
Green - SolidBoth radios enabled in access mode
Amber - SolidBoth radios enabled in monitor mode
Green or Amber BlinkingOne radio enabled in access (green) or monitor (amber) mode, other disabled
Green/Amber AlternatingGreen: one radio enabled in access mode, Amber: one radio enabled in monitor mode

Non-Proprietary Other Interfaces:

Page 15
2.3.2 AP-530 Series

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

Page 16

Non-Proprietary Figure 9 - AP-535 Campus Access Point

Page 17

Non-Proprietary 2.3.2.2 Dimensions / Weight The AP has the following physical dimensions:

Page 18
LED TypeColor/StateMeaning
System Status (Left)OffAP powered off
Green - BlinkingDevice booting; not ready
Green - SolidDevice ready
Amber - SolidDevice ready; power-save mode (802.3at PoE): * Single radio * USB disabled
Green or Amber FlashingDevice ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode
RedSystem error condition
Radio Status (Right)OffAP powered off, or both radios disabled
Green - SolidBoth radios enabled in access mode
Amber - SolidBoth radios enabled in monitor mode
Green or Amber BlinkingOne radio enabled in access (green) or monitor (amber) mode, other disabled
Green/Amber AlternatingGreen: one radio enabled in access mode, Amber: one radio enabled in monitor mode

Non-Proprietary Figure 10 - AP-530 Series Campus Access Point

Page 19
2.3.3 AP-580 Series

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

Page 20

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:

Page 21

Non-Proprietary 2.3.3.3

Page 22
LED TypeColor/StateMeaning
System Status (during Boot Up)OffAP powered off
RedInitial power-up
Green - FlashingAP booting; not ready
Green - SolidAP ready and GbE (or better) or SFP+ connected. The LED turns off after 1200 seconds.
Green / Amber Alternating, 6 seconds periodAP ready and 100Mbps Ethernet link established. The LED turns off after 1200 seconds.
Green – Flashing, 6 seconds periodAP in deep sleep
Red – FlashingAP in thermal shutdown
System Status (during Operation)Red - SolidSystem error condition
Red – One red blink every 3 secondsRadio 0 fault (5 GHz)
Red – Two quick blinks 0.5 seconds apart, cycled every 3 secondsRadio 1 fault (2.4 GHz)

Non-Proprietary Figure 16 - AP-585 Outdoor Access Point

Page 23
2.3.4 AP-630 Series

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

Page 24

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:

Page 25
LED TypeColor/StateMeaning
System Status (Left)OffAP powered off
Green - BlinkingDevice booting; not ready
Green - SolidDevice ready
Amber - SolidDevice ready; power-save mode (802.3at PoE): * Single radio * USB disabled
Green or Amber FlashingDevice ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode
RedSystem error condition
Radio Status (Right) 2GHz/5GHz/6GHzOffAP powered off, or radio disabled
Green - SolidRadio enabled in access mode
Amber - SolidRadio enabled in monitor or spectrum analysis mode
Green FlashingRadio enabled in uplink or mesh mode

Non-Proprietary Bluetooth 5.0 Low Energy (BLE5.0) and Zigbee (802.15.4) radio:

Page 26
2.3.5 AP-650 Series

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

Page 27

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:

Page 28
LED TypeColor/StateMeaning
System Status (Left)OffAP powered off
Green - BlinkingDevice booting; not ready
Green - SolidDevice ready
Amber - SolidDevice ready; power-save mode (802.3at PoE): * Single radio * USB disabled
Green or Amber FlashingDevice ready, restricted mode: * Uplink negotiated in sub optimal speed; or * Deep sleep mode
RedSystem error condition
Radio Status (Right) 2GHz/5GHz/6GHzOffAP powered off, or radio disabled
Green - SolidRadio enabled in access mode
Amber - SolidRadio enabled in monitor or spectrum analysis mode
Green FlashingRadio enabled in uplink or mesh mode

Non-Proprietary Bluetooth 5.0 Low Energy (BLE5.0) and Zigbee (802.15.4) radio:

2.4 Excluded Components

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

Page 29
Service
NameDescriptionRole AccessYes
Non- Approved ModeA 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 DisabledNo
Approved algorithm
NameCAVP CertMode MethodKey SizeUse Function
AES [FIPS 197] [SP 800-38A]A2690CBC, ECB, CTR (256, ext only, encryption only)128, 192, 256Data Encryption/Decryption
AES [FIPS 197] [SP 800-38A] [SP 800-38D]A2690GCM, CCM128, 256Data Encryption/Decryption
CKG [SP 800-133 Rev2]Vendor Affirmed1CTR_DRBGN/ACryptographic Key Generation (using output from DRBG2 as per IG D.H)
2.5 Modes of Operation

Table 11

Page 30
Approved algorithm
NameCAVP CertMode MethodKey SizeUse Function
CVL IKEv13 KDF [SP 800-135 Rev1]A2690IKEv1: DSA, PSKIKEv1: DH 2048-bit; SHA2-256, SHA2-384Key Derivation
DRBG [SP 800-90A Rev1]A2690AES CTR256Deterministic Random Bit Generation
ESV program certificate #7 [SP 800-90B]N/AAruba 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]A2690keyGen, pqgGenL=2048, N=256, SHA2-256Key Generation, Domain Parameter Generation
ECDSA [FIPS 186-4]A2690KeyGen, KeyVer, SigGen, SigVerKeyGen: 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-512Key Generation and Verification, Digital Signature Generation and Verification
HMAC [FIPS 198-1]A2690HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384(minimum 112 bits)Message Authentication
KBKDF [SP 800-108 Rev1]A2690CTRHMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384Key-based Key Derivation
KAS-SSC [SP 800-56A Rev3]A2690FFC: dhEphem, ECC: Ephemeral UnifiedFFC: FC with SHA2-256, MODP-2048 with SHA2-256 ECC: P-256 with SHA2-256, P-384 with SHA2-384 KAS Roles - initiator, responderKey Agreement Scheme – Shared Secret Computation (as per IG D.F, Scenario 2 (2))
KDA [SP 800-56C Rev2]A2690Two-step key derivationHMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384Key Derivation Algorithm
RSA [FIPS 186-2]A2690SigVer: SHA-14, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.51024 (for legacy SigVer only), 2048Digital Signature Verification
RSA [FIPS 186-4]A2690KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-15, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048Key Generation, Digital Signature Generation and Verification
Safe Primes [SP 800-56A Rev3]A2690KeyGen, KeyVerSafe Prime Groups: MODP-2048Safe Primes Key Generation and Key Verification
SHS [FIPS 180-4]A2690SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only160, 256, 384, 512Message Digest
KTS [SP 800-38F]AES A2690AES-GCM6128, 256Key Wrapping / Key Transport via IKE/IPSec
KTS [SP 800-38F] [FIPS 198-1]AES A2690 HMAC A2690AES-CBC7 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384128, 192, 256Key Wrapping / Key Transport via IKE/IPSec
SHA-3 [FIPS 202]A2738SHA3-256256Entropy Generation and Conditioning
AES [FIPS 197] [SP 800-38A] [SP 800-38D]A2689CBC, GCM8128, 192, 256Data Encryption/Decryption
CVL IKEv29 KDF [SP 800-135 Rev1]A2689IKEv2IKEv2: DH 2048-bit; SHA2-256, SHA2-384Key Derivation
DSA [FIPS 186-4]A2689keyGen, pqgGenL=2048, N=256, SHA2-256Key Generation, Domain Parameter Generation
ECDSA [FIPS 186-4]A2689KeyGen, KeyVer, SigGen, SigVerKeyGen: 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-512Key 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

Page 31
Approved algorithm
NameCAVP CertMode MethodKey SizeUse Function
Safe Primes [SP 800-56A Rev3]A2690KeyGen, KeyVerSafe Prime Groups: MODP-2048Safe Primes Key Generation and Key Verification
SHS [FIPS 180-4]A2690SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only160, 256, 384, 512Message Digest
KTS [SP 800-38F]AES A2690AES-GCM6128, 256Key Wrapping / Key Transport via IKE/IPSec
KTS [SP 800-38F] [FIPS 198-1]AES A2690 HMAC A2690AES-CBC7 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384128, 192, 256Key Wrapping / Key Transport via IKE/IPSec
SHA-3 [FIPS 202]A2738SHA3-256256Entropy Generation and Conditioning
AES [FIPS 197] [SP 800-38A] [SP 800-38D]A2689CBC, GCM8128, 192, 256Data Encryption/Decryption
CVL IKEv29 KDF [SP 800-135 Rev1]A2689IKEv2IKEv2: DH 2048-bit; SHA2-256, SHA2-384Key Derivation
DSA [FIPS 186-4]A2689keyGen, pqgGenL=2048, N=256, SHA2-256Key Generation, Domain Parameter Generation
ECDSA [FIPS 186-4]A2689KeyGen, KeyVer, SigGen, SigVerKeyGen: 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-512Key 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

Page 32
Approved algorithm
NameCAVP CertMode MethodKey SizeUse Function
HMAC [FIPS 198-1]A2689HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384(minimum 112 bits)Message Authentication
KAS-SSC [SP 800-56A Rev3]A2689FFC: dhEphem, ECC: Ephemeral UnifiedFFC: FC with SHA2-256, MODP- 2048 with SHA2-256 ECC: P-256 with SHA2-256, P- 384 with SHA2-384 KAS Roles - initiator, responderKey Agreement Scheme – Shared Secret Computation
RSA [FIPS 186-2]A2689SigVer: SHA-110, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.51024 (for legacy SigVer only), 2048Digital Signature Verification
RSA [FIPS 186-4]A2689KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-111, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048Key Generation, Digital Signature Generation and Verification
Safe Primes [SP 800-56A Rev3]A2689KeyGen, KeyVerSafe Prime Groups: MODP-2048Safe Primes Key Generation and Key Verification
SHS [FIPS 180-4]A2689SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only160, 256, 384, 512Message Digest
KTS [SP 800-38F]AES A2689AES-GCM12128, 256Key Wrapping / Key Transport via IKE/IPSec
KTS [SP 800-38F] [FIPS 198-1]AES A2689 HMAC A2689AES-CBC13 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384128, 192, 256Key Wrapping / Key Transport via IKE/IPSec
RSA [FIPS 186-4]A2688SigVer: SHA2-256 PKCS1 v1.5SigVer: 2048Digital Signature Verification (only)
SHS [FIPS 180-4]A2688SHA2-256 Byte Only256Message Digest
Approved algorithm
NameCAVP CertMode MethodKey SizeUse FunctionAlgorithm and Standard
HMAC [FIPS 198-1]A2689HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384(minimum 112 bits)Message Authentication
KAS-SSC [SP 800-56A Rev3]A2689FFC: dhEphem, ECC: Ephemeral UnifiedFFC: FC with SHA2-256, MODP- 2048 with SHA2-256 ECC: P-256 with SHA2-256, P- 384 with SHA2-384 KAS Roles - initiator, responderKey Agreement Scheme – Shared Secret Computation
RSA [FIPS 186-2]A2689SigVer: SHA-110, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.51024 (for legacy SigVer only), 2048Digital Signature Verification
RSA [FIPS 186-4]A2689KeyGen, SigGen: SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5 SigVer: SHA-111, SHA2-256, SHA2-384, SHA2-512 PKCS1 v1.5KeyGen: 2048 SigGen: 2048 SigVer: 1024 (for legacy SigVer only), 2048Key Generation, Digital Signature Generation and Verification
Safe Primes [SP 800-56A Rev3]A2689KeyGen, KeyVerSafe Prime Groups: MODP-2048Safe Primes Key Generation and Key Verification
SHS [FIPS 180-4]A2689SHA-1, SHA2-256, SHA2-384, SHA2-512 Byte Only160, 256, 384, 512Message Digest
KTS [SP 800-38F]AES A2689AES-GCM12128, 256Key Wrapping / Key Transport via IKE/IPSec
KTS [SP 800-38F] [FIPS 198-1]AES A2689 HMAC A2689AES-CBC13 HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384128, 192, 256Key Wrapping / Key Transport via IKE/IPSec
RSA [FIPS 186-4]A2688SigVer: SHA2-256 PKCS1 v1.5SigVer: 2048Digital Signature Verification (only)
SHS [FIPS 180-4]A2688SHA2-256 Byte Only256Message Digest
Triple-DES-ECBTriple-DES-ECBUsed with the KEK only for internal key obfuscation as per IG 2.4.A[no security claimed]
DESUsed for older versions of WEP in non-Approved mode
HMAC-MD5Used for older versions of WEP in non-Approved mode
MD5Used for older versions of WEP in non-Approved mode
RC4Used for older versions of WEP in non-Approved mode
Null EncryptionUsed for older versions of WEP in non-Approved mode
RSANon-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-Hellmankey agreement; non-compliant less than 112 bits of encryption strength
EC Diffie-Hellmankey agreement; non-compliant less than 112 bits of encryption strength
ECDSANon-compliant when using 186-2 signature generation
Triple-DES-CBCAs 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

Page 33
Approved algorithm
NameCAVP CertKey SizeUse FunctionAlgorithm and Standard
Triple-DES-ECBTriple-DES-ECBUsed with the KEK only for internal key obfuscation as per IG 2.4.A[no security claimed]
DESUsed for older versions of WEP in non-Approved mode
HMAC-MD5Used for older versions of WEP in non-Approved mode
MD5Used for older versions of WEP in non-Approved mode
RC4Used for older versions of WEP in non-Approved mode
Null EncryptionUsed for older versions of WEP in non-Approved mode
RSANon-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-Hellmankey agreement; non-compliant less than 112 bits of encryption strength
EC Diffie-Hellmankey agreement; non-compliant less than 112 bits of encryption strength
ECDSANon-compliant when using 186-2 signature generation
Triple-DES-CBCAs 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

Page 34
Ports and interfaces
NamePhysical PortLogical InterfaceData 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 InterfacesData 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 InterfacesData 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 buttonControl 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 IndicatorsStatus 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:

Page 35
Service
NameRolesInputOutput
Approved mode enable/disable from Mobility Controller14Crypto Officer, UserCommandStatus of command
Key ManagementCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Reboot moduleCrypto Officer, UserCommandProgress information
Self-test triggered by CO/User rebootCrypto Officer, UserNoneError messages logged if a failure occurs
Update module firmwareCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Configure non-security related module parametersCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Creation/use of secure management session between module and COCrypto Officer, UserIPSec inputs, commands, and dataIPSec outputs, status, and data
System Status and System Status – module LEDsCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Creation/use of secure mesh channelCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Openflow AgentCrypto Officer, UserCommands and configuration dataStatus of commands and configuration data
Generation and use of WPA2/WPA3 cryptographic keysUser, Wireless ClientWPA2/WPA3 inputs, commands and dataWPA2/WPA3 outputs, status and data
Use of WPA2/WPA3 Pre-shared secret for establishment of WPA2/WPA3 keysUser, Wireless ClientWPA2/WPA3 inputs, commands and dataWPA2/WPA3 outputs, status and data
Wireless bridging servicesUser, Wireless ClientCommands and configuration dataStatus of commands and configuration data
4 Roles, Services, and Authentication

The following section lists the roles supported by the module, authentication mechanisms used by the module, and

4.1 Roles

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

Page 36
Approved algorithm
NameMode MethodUse Function
Wireless Client RoleAPDescriptionCrypto Officer (CO) RoleUser 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

Page 37
Mesh Point AP configurationWhen 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

4.2 Authentication

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.

4.2.1 Crypto Officer Authentication

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.

4.2.2 User Authentication

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

Page 38
Approved algorithm
NameKey Size
IKEv1 Pre- shared secret based authenticationPasswords 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 authenticationThe 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 authenticationECDSA 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 authenticationPasswords 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:

Page 39
Service
NameDescriptionRolesCsps AccessedApproved FunctionsAccessIndicator
Update module firmware16The 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 NetworkMaintenanceSoftware Management).Crypto Officer, User17[11] Factory CA Public KeyRSA SigVer SHA2-256 (A2690, A2688)ESuccessful 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 NetworkConfig urationAccess Points)..
4.3 Services

The module provides various services depending on role. These are described in the sections below.

4.3.1 Approved Services

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

Page 40
Sensitive security parameter
NameSecurity FunctionUseOutputAES-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 KeyW W E E W W W
Creation/use of secure mesh channel19The module requires secure connections between mesh points using WPA2/WPA3.Crypto Officer, User20Successful 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 NetworkConfig urationAP 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 keysIn all Approved modes, the links between the module and wireless client are secured with WPA2/WPA3.User20, Wireless ClientSuccessful 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 NetworkConfig urationAP 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 CO21The module supports use of IPSec for securing the management channel.Crypto Officer, User22Successful 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 NetworkConfig urationServices VPNCertifica 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 KeyE 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 keysWhen 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 ClientSuccessful completion of wireless client configurations shown via output of related CLI commands (e.g. show ap mesh) or WebGUI updates (e.g. Managed NetworkConfig urationAP Groups).AES-CCM AES-GCM (A2690)[24] WPA2/WPA3 Pre- shared KeyE

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

Page 41
Service
NameDescriptionRolesCsps AccessedApproved FunctionsAccessIndicator
Approved mode enable/disableThe 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, User22NoneNoneNoneSuccessful 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

Page 42
Reboot moduleThe 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.NoneNoneCrypto Officer, User24NoneSuccessful 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 rebootThe CO can trigger a programmatic reset leading to self-test and initialization.NoneNoneCrypto Officer, User24NoneStatus of self- tests in log after reboot shows successful completion of self-tests.
System StatusCO 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 NetworkConfig urationAccess Points).
System Status – module LEDsThe CO may view system status by viewing the module’s LEDs.NoneNoneCrypto Officer, UserNoneSuccessful 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 parametersCO can configure various operational parameters that do not relate to security.NoneNoneCrypto Officer, User24NoneStatus of command to show operational parameter settings shows successful completion of configurations.
Openflow AgentAgent 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.NoneNoneCrypto Officer, User24NoneSuccessful 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

Page 43

Non-Proprietary User 25, User 26 Z

4.3.2 Non-Approved Services

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

Page 44
Service
NameDescriptionRolesApproved FunctionsIndicator
IPSec/IKE using Triple-DESIPSec/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, UserTriple-DESImplicit indication via successful completion of the service.
Suite-B (bSec) protocolThe 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, UserSuite-B (bSec) protocolImplicit indication via successful completion of the service.
Upgrade module firmware via the console portThe 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, User27Triple-DES RSA SigVer SHA2-256Status of command to enable console and to show firmware version.
Debugging via the console portThe 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, User27NoneStatus 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, UserNon-Approved algorithms and/or sizesImplicit indication via successful completion of the service.

Non-Proprietary Table 24

Page 45
5 Software / Firmware Security

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).

6 Operational Environment

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

Page 46
7 Physical Security

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.

7.1 Reading 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

Page 47
7.2 Applying TELs

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:

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

Page 48
7.3.1 TELs Placement on the AP-514 and AP-515

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

Page 49
7.3.2 TELs Placement on the AP-534 and AP-535

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

Page 50
7.3.3 TELs Placement on the AP-584, AP-585, and AP-587

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

Page 51
7.3.4 TELs Placement on the AP-584

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

Page 52
7.3.5 TELs Placement on the AP-585

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

Page 53
7.3.6 TELs Placement on the AP-587

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

Page 54
7.3.7 TELs Placement on the AP-635

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

42 for placement.

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

Page 55
7.3.8 TELs Placement on the AP-655

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

44 for placement.

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

Page 56
Physical Security MechanismRecommended Frequency ofInspection/Test Guidance Details
Inspection/Test
Tamper-evident labels (TELs)Once per monthExamine 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 enclosureOnce per monthExamine 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

8 Non-Invasive Security

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

Page 57
Sensitive security parameter
NameStrengthSecurity FunctionGenerationEstablishmentStorageZeroizationImport Export#Key / SSP Name / Type
Entropy inputs to the DRBG function, used to construct the DRBG Seed.512 bitsSP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A269064 bytes are retrieved from the entropy source read from entropy source on each call by any service that requires a random number.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A1DRBG Entropy Input – CSP
Input to the DRBG that determines the internal state of the DRBG (DRBG Key and V).384 bitsSP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690Generated using DRBG derivation function that includes the entropy input from the entropy source read from entropy source.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A2DRBG Seed – CSP
This is the internal DRBG key used for SP 800-90A Rev1 CTR_DRBG during generation of random numbers.256 bitsSP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690Derived from the DRBG Seed.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A3DRBG Key – CSP
Internal V value used as part of SP 800-90A Rev1 CTR_DRBG during generation of random numbers.128 bitsSP 800-90A Rev1 CTR_DRBG AES-256 Cert. #A2690Derived from the DRBG Seed.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A4DRBG V – CSP
Used during the IPSec handshake to establish the Diffie-Hellman Shared Secret.224 bitsDiffie- Hellman Group 14 Cert. #A2690 Cert. #A2689Generated internally in compliance with Diffie-Hellman key agreement scheme by calling Approved DRBG (Cert. #A2690)N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A5Diffie-Hellman Private Key – CSP
Used during the IPSec handshake to establish the Diffie-Hellman Shared Secret.2048 bitsDiffie- Hellman Group 14 Cert. #A2690 Cert. #A2689Generated internally in compliance with Diffie-Hellman key agreement scheme by calling Approved DRBG (Cert. #A2690)N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: in plaintext6Diffie-Hellman Public Key – PSP
Used for deriving IPSec/IKE cryptographic keys.2048 bitsDiffie- Hellman Group 14 Cert. #A2690 Cert. #A2689N/AEstablished during Diffie- Hellman Exchange.Stored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A7Diffie-Hellman Shared Secret – CSP
Used for establishing EC Diffie- Hellman Shared Secret.Curves: P-256 or P-384EC Diffie- Hellman Cert. #A2690 Cert. #A2689Generated internally by calling Approved DRBG (Cert. #A2690) during EC Diffie-Hellman Exchange.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A8EC Diffie- Hellman Private Key – CSP
Used for establishing EC Diffie- Hellman Shared Secret.Curves: P-256 or P-384EC Diffie- Hellman Cert. #A2690 Cert. #A2689Generated internally by calling Approved DRBG (Cert. #A2690) during EC Diffie-Hellman Exchange.N/AStored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: in plaintext9EC Diffie- Hellman Public Key – PSP
Used for deriving IPSec/IKE cryptographic keys.Curves: P-256 or P-384EC Diffie- Hellman Cert. #A2690 Cert. #A2689N/AEstablished during EC Diffie- Hellman Exchange.Stored in SDRAM memory (plaintext).Zeroized by rebooting the module.Import: N/A Export: N/A10EC Diffie- Hellman Shared Secret – CSP
This is a RSA public key. Used for Firmware verification.2048 bitsRSAN/A Loaded into the module during manufacturing (i.e. out of scope of module).N/AStored in TPMSince this is a public key and protected in TPM, the zeroization requirements do not apply.Import: N/A Export: N/A11Factory CA Public Key –PSP
Used for IKEv1 peers authentication.8 - 64 ASCII or 64 HEX charactersShared Secret Cert. #A2690Entered by CO role.N/AStored in Flash memory obfuscated with KEKZeroized by using command ‘ap wipe out flash’.Import: in plaintext Export: N/A12IKE Pre- shared Key29 – CSP
A shared secret known only to IKEv1 peers. Used for deriving other keys in IKEv1 protocol implementation.160 / 256 / 384 bitsShared Secret Cert. #A2690N/ADerived 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/A13Skeyid – CSP
A shared secret known only to IKEv1 peers. Used for deriving IKEv1 Session Authentication Key.160 / 256 / 384 bitsShared Secret Cert. #A2690N/ADerived 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/A14skeyid_d – CSP
A shared secret known only to IKEv2 peers. Used for deriving other keys in IKEv2 protocol.160 / 256 / 384 bitsShared Secret Cert. #A2689N/ADerived 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/A15SKEYSEED – CSP
The IKE session (IKE Phase I) authentication key. Used for IKEv1/IKEv2 payload integrity verification.160 / 256 / 384 bitsHMAC-SHA- 1/256/384 Cert. #A2690 Cert. #A2689N/ADerived 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/A16IKE Session Authentication Key – CSP
The IKE session (IKE Phase I) encrypt key. Used for IKE payload protection.128 / 192 / 256 bitsAES (CBC) Cert. #A2690 Cert. #A2689N/ADerived 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/A17IKE 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 bitsAES (CBC) and AES (GCM) Cert. #A2690 Cert. #A2689N/ADerived 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/A18IPSec Session Encryption Key – CSP
The IPSec (IKE Phase II) authentication key. Used for IPSec traffics integrity verification.160 bitsHMAC-SHA- 1 Cert. #A2690 Cert. #A2689N/ADerived 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/A19IPSec Session Authentication Key – CSP
This is the RSA private key. Used for RSA signature signing in either IKEv1 or IKEv2.2048 bitsRSA Private Key Cert. #A2690 Cert. #A2689Generated 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/AStored in Flash memory obfuscated with KEKZeroized by using command ‘ap wipe out flash’.Import: N/A Export: N/A20IKE RSA Private Key – CSP
This is the RSA public key. Used for RSA signature verification in either IKEv1 or IKEv2.2048 bitsRSA Public Key Cert. #A2690 Cert. #A2689Generated 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/AStored in Flash memory obfuscated with KEKZeroized by using command ‘ap wipe out flash’.Import: N/A Export: N/A21IKE RSA Public Key – PSP
This is the ECDSA private key. Used for ECDSA signature signing in IKEv2.Curves: P-256 or P-384ECDSA suite B Cert. #A2689Generated 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/AStored in Flash memory obfuscated with KEKZeroized by using command ‘ap wipe out flash’.Import: N/A Export: N/A22IKE ECDSA Private Key – CSP
This is the ECDSA public key. Used for ECDSA signature verification in IKEv2.Curves: P-256 or P-384ECDSA suite B Cert. #A2689Generated 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/AStored in Flash memory obfuscated with KEKZeroized by using command ‘ap wipe out flash’.Import: N/A Export: N/A23IKE ECDSA Public Key – PSP
Used for WPA2/WPA3 client/server authentication.8-63 ASCII or 64 HEX charactersShared Secret Cert. #A2690Entered by CO role.N/AStored in Flash memory (obfuscated with KEK).Zeroized by using command ‘ap wipe out flash’.Import: in plaintext Export: N/A24WPA2/WPA3 Pre-shared Key – CSP
Used to derive the Pairwise Transient Key (PTK) for WPA2/WPA3 communications.256 bitsShared Secret Cert. #A2690The PMK is transferred to the module, protected by IPSec secure tunnel.N/AStored in SDRAM (plaintext).Zeroized by rebooting the module.Import: in plaintext Export: N/A25WPA2/WPA3 Pair-Wise Master Key (PMK) – CSP
Used to derive the WPA2/WPA3 Session Key.384 bitsHMAC Cert. #A2690N/ADerived 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/A26WPA2/WPA3 Pairwise Transient Key (PTK) – CSP
Used as the WPA2/WPA3 Session Key.128 bits, 128 / 256 bitsAES (CCM) and AES (GCM) (WPA3 only) Cert. #A2690N/ADerived 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/A27WPA2/WPA3 Session Key – CSP
Used to derive WPA2/WPA3 Group Transient Key GTK.256 bitsShared Secret Cert. #A2690Generated internally by calling Approved DRBG (Cert. #A2690).N/AStored in SDRAM memory (plaintext)Zeroized by rebooting the moduleImport: N/A Export: N/A28WPA2/WPA3 Group Master Key (GMK) – CSP
The GTK is the WPA2/WPA3 session key used for broadcast communications protection.256 bitsAES (CCM) and AES (GCM) Cert. #A2690N/ADerived 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 moduleImport: N/A Export: N/A29WPA2/WPA3 Group Transient Key (GTK) – CSP
9 Sensitive Security Parameters (SSP) Management

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

Page 58

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

Page 59

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

Page 60

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

Page 61

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

Page 62

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

Page 63

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

Page 64

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

Page 65
Approved algorithm
NameKey Size
DetailsMinimum Number of Bits of EntropyEntropy 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:

Page 66
Self test
NameAlgorithm Or TestTest TypeDetailsHPE Aruba Networking Cryptographic Module ComponentTest PropertiesCondition
RSA Firmware Integrity TestRSA Firmware Integrity TestSigVerThe ArubaOS Bootloader Module performs the firmware integrity test when module powered on, before booting the ArubaOS operating system.ArubaOS Bootloader Module2048-bit public key, PKCS#1-v1.5, signature verification with SHA2-256 message digest
RSARSAKATVerifyArubaOS Bootloader Module2048, PKCS#1-v1.5Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
SHSSHSKATArubaOS Bootloader ModuleSHA2-256
Self test
NameAlgorithm Or TestTest TypeDetailsHPE Aruba Networking Cryptographic Module ComponentTest PropertiesCondition
RSA Firmware Integrity TestRSA Firmware Integrity TestSigVerThe ArubaOS Bootloader Module performs the firmware integrity test when module powered on, before booting the ArubaOS operating system.ArubaOS Bootloader Module2048-bit public key, PKCS#1-v1.5, signature verification with SHA2-256 message digest
RSARSAKATVerifyArubaOS Bootloader Module2048, PKCS#1-v1.5Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
SHSSHSKATArubaOS Bootloader ModuleSHA2-256
AES ECBAES ECBKATEncrypt, DecryptArubaOS OpenSSL ModuleAES-ECB-128Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
AES CCMAES CCMKATEncrypt, DecryptArubaOS OpenSSL ModuleAES-CCM-192
AES GCMAES GCMKATEncrypt, DecryptArubaOS OpenSSL ModuleAES-GCM-256
DRBGDRBGKATSP 800-90A Rev1 Section 11.3 Health Tests for CTR_DRBG (Instantiate, Generate and Reseed)ArubaOS OpenSSL ModuleAES-CTR-256, CTR_DRBG with DF, with and without PR
ArubaOS CPU Jitter Entropy SourceRCTSP800-90B Section 4.4 Approved Continuous Health Tests (RCT and APT)ArubaOS CPU Jitter Entropy SourceTests are applied continuously to digitized samples of the output of the non-physical noise source
ECDSAECDSAKATSign, VerifyArubaOS OpenSSL ModuleP-256, P-384Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
HMACHMACKATArubaOS OpenSSL ModuleHMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512
KAS-SSC-ECCKAS-SSC-ECCKATEphemeral Unified SP 800- 56A Rev3 basedArubaOS OpenSSL ModulePrimitive ‘Z’ computation with P-256 curve
KAS-SSC-FFCKAS-SSC-FFCKATdhEphem SP 800-56A Rev3 basedArubaOS OpenSSL ModuleShared secret computation, p=2048, q=256
KDAKDAKATSP 800-56C Rev2 basedArubaOS OpenSSL ModuleTwo-step KDF: HMAC-SHA-1, L=2048
KBKDFKBKDFKATSP 800-108 Rev1 basedArubaOS OpenSSL ModuleHMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384
KDF135KDF135KATSP 800-135 Rev1 based: IKEv1ArubaOS OpenSSL ModuleKey derivation
RSARSAKATSign, VerifyArubaOS OpenSSL Module2048, PKCS#1-v1.5
SHSSHSKATArubaOS OpenSSL ModuleSHA-1, SHA2-256, SHA2-384, SHA2-512Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
Triple-DESTriple-DESKATEncrypt, Decrypt, Triple-DES used with KEK only to obfuscate internal keys. No security claimed.ArubaOS OpenSSL ModuleTDES-ECB-192
SHA-3SHA-3KATFIPS 202 basedArubaOS CPU Jitter Entropy SourceSHA3-256Run when module powered on, which is prior to the first operational use of the cryptographic algorithm
AES CBCAES CBCKATEncrypt, DecryptArubaOS Crypto ModuleAES-CBC-256Each run when module powered on, which is prior to the first operational use of the cryptographic algorithms
AES GCMAES GCMKATEncrypt, DecryptArubaOS Crypto ModuleAES-GCM-256
ECDSAECDSAKATSign, VerifyArubaOS Crypto ModuleP-256
HMACHMACKATArubaOS Crypto ModuleHMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-384, HMAC-SHA2-512
KAS-SSC-ECCKAS-SSC-ECCKATEphemeral Unified SP 800- 56A Rev3 basedArubaOS Crypto ModulePrimitive ‘Z’ computation with P-256 curve
KAS-SSC-FFCKAS-SSC-FFCKATdhEphem SP 800-56A Rev3 basedArubaOS Crypto ModuleShared secret computation, p=2048, q=256
KDF135KDF135KATSP 800-135 Rev1 based: IKEv2ArubaOS Crypto ModuleKey derivation
RSARSAKATSign, VerifyArubaOS Crypto Module2048, PKCS#1-v1.5
SHSSHSKATArubaOS Crypto ModuleSHA-1, SHA2-256, SHA2-384, SHA2-512
Triple-DESTriple-DESKATEncrypt, Decrypt, Triple-DES used with KEK only to obfuscate internal keys. No security claimed.ArubaOS Crypto ModuleTDES-CBC-192Run when module powered on, which is prior to the first operational use of the cryptographic algorithm
ECC key pairsECC key pairsPCTSign, VerifyArubaOS OpenSSL ModuleP-256, P-384Each run on key pair generation
FFC key pairsFFC key pairsPCTSP800-56A Rev3 assurances as per SP 800-56A Rev3 Section 5.6.2.1.4 for PCTArubaOS OpenSSL ModuleDH key pair generation
RSA key pairsRSA key pairsPCTSign, VerifyArubaOS OpenSSL Module2048, PKCS#1-v1.5
ECC key pairsECC key pairsPCTSign, VerifyArubaOS Crypto ModuleP-256, P-384
FFC key pairsFFC key pairsPCTSP800-56A Rev3 assurances as per SP 800-56A Rev3 Section 5.6.2.1.4 for PCTArubaOS Crypto ModuleDH key pair generation
RSA key pairsRSA key pairsPCTSign, VerifyArubaOS Crypto Module2048, PKCS#1-v1.5
RSA Firmware Load TestRSA Firmware Load TestSigVerArubaOS OpenSSL Module2048, PKCS#1-v1.5, signature verification with SHA2-256Test is applied by the main ArubaOS code for firmware load during operation
RSA Firmware Load TestRSA Firmware Load TestSigVerArubaOS Bootloader Module2048, PKCS#1-v1.5, signature verification with SHA2-256Test is applied by the ArubaOS Bootloader Module on request to load firmware
10 Self-Tests

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

Page 67

Non-Proprietary 67| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy

Page 68

Non-Proprietary 68| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy

Page 69

Non-Proprietary Table 30

Page 70

Non-Proprietary Table 31

Page 71
11 Life-Cycle Assurance

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.

11.1 Product Examination

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.

11.2 Package Contents

The product carton should include the following:

11.3 Pre-Installation Checklist

You will need the following during installation:

11.4 Identifying Specific Installation Locations

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

Page 72
11.5 Precautions
11.6 Secure Operation

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.

11.6.1 Crypto Officer Management

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:

Page 73

Non-Proprietary

11.6.2 User Guidance

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.

11.6.3 Set-up and Configuration

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.

11.6.3.1 Setting Up Your Wireless Access Point

The Crypto Officer shall perform the following steps to ensure the APs are placed in the secure operational state:

  1. Review the Aruba AP Software Quick Start Guide. Select the deployment scenario that best fits your installation and follow the scenario’s deployment procedures.
  2. Apply TELs according to the directions in the above Physical Security section 7.2, Applying TELs. 73| HPE Aruba Networking AP-5XX and AP-6XX Access Points with ArubaOS FIPS Firmware FIPS 140-3 Level 2 Security Policy
Page 74

Non-Proprietary

  1. Enable Approved mode on the staging controller: Log into the staging controller via an SSH client and enter the commands shown in the sub-section below named, Enabling Approved Mode on the Staging Controller.
  2. Connect the module via an Ethernet cable to the staging controller - note that this should be a direct connection, with no intervening network or devices. If PoE is being supplied by an injector, this represents the only exception; that is, nothing other than a PoE injector should be present between the module and the staging controller.
  3. Provision the AP into one of four (4) AP configurations following the guidance in the ArubaOS

8.10 User Guide: Remote AP configuration, CPSec protected AP configuration, Mesh Portal AP

configuration, or Mesh Point AP configuration.

  1. Via the logging facility of the staging controller, ensure that the module (the AP) is successfully provisioned with firmware and configuration and in Approved mode. To verify that the image is being run, the CO can enter ‘show ap image’ on the controller to verify the correct image is present on the device. To verify that Approved mode is enabled, enter ‘show fips’.
  2. Terminate the administrative session.
  3. Disconnect the module from the staging controller and install it on the deployment network. When power is applied, the module (the AP) will attempt to discover and connect to an HPE Aruba Networking Mobility Controller on the network. Once the AP has been provisioned, it is considered to be in Approved mode, provided that the guidelines on services, algorithms, physical security and key management found in this Security Policy are followed.
11.6.3.2 Enabling Approved Mode on the Staging Controller

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:

11.6.3.2.1 Enabling Approved Mode on the Staging Controller with the CLI

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

Page 75

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.

11.7 Non-Approved Approved Mode Configurations

When operating in the Approved mode, the following configuration options are non-Approved:

11.8 Full Documentation

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,

11.8.1 Related HPE Aruba Networking Documents

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:

Page 76
11.9 End of Life

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).

12 Mitigation of Other Attacks

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

Referenced URLs