1
FIPS 140-2 Non-Proprietary Security Policy
for Aruba AP-324 and AP-325
Wireless Access Points
Version 2.4
July 2017
3333 Scott Blvd
Santa Clara, CA 95054
2
Copyright
© 2017 Aruba an HP Enterprise Company. Aruba trademarks include
,Aruba Networks®, Aruba Wireless Networks®, the registered Aruba
the Mobile Edge Company logo, Aruba Mobility Management System®, Mobile Edge
Architecture®, People Move. Networks Must Follow®, RFProtect®, Green Island®. All
rights reserved. All other trademarks are the property of their respective
owners. Open Source Code
Certain Aruba 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:
http://www.arubanetworks.com/open_source
Legal Notice
The use of Aruba. switching platforms and software, 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, Aruba Networks, Inc. from any and all legal
actions that might be taken against it with respect to infringement of
copyright on behalf of those vendors.
Warranty
This hardware product is protected by the standard Aruba 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.
Copyright
© 2017 Aruba an HP Enterprise Company. Aruba trademarks include , Aruba
Networks®, Aruba Wireless Networks®,the registered Aruba the Mobile Edge
Company logo, and Aruba Mobility Management System®.
3
1 INTRODUCTION.................................................................................................................................5
1.1 ACRONYMS AND ABBREVIATIONS................................................................................................... 5
2 PRODUCT OVERVIEW......................................................................................................................6
2.1 AP-324............................................................................................................................................ 6
2.1.1 Physical Description............................................................................................................... 6
2.1.1.1 Dimensions/Weight ............................................................................................................ 7
2.1.1.2 Interfaces ............................................................................................................................ 7
2.2 AP-325............................................................................................................................................ 9
2.2.1 Physical Description............................................................................................................... 9
2.2.1.1 Dimensions/Weight ............................................................................................................ 9
2.2.1.2 Interfaces .......................................................................................................................... 10
3 MODULE OBJECTIVES...................................................................................................................12
3.1 SECURITY LEVELS......................................................................................................................... 12
3.2 PHYSICAL SECURITY ..................................................................................................................... 12
3.2.1 Applying TELs ...................................................................................................................... 12
3.2.2 Inspection/Testing of Physical Security Mechanisms ........................................................... 13
3.2.3 TELs Placement.................................................................................................................... 13
3.2.3.1 TELs Placement on the AP-324........................................................................................ 13
3.2.3.2 TEL Placement on the AP-325......................................................................................... 14
3.2.4 Inspection/Testing of Physical Security Mechanisms ........................................................... 16
3.3 OPERATIONAL ENVIRONMENT....................................................................................................... 16
3.4 LOGICAL INTERFACES ................................................................................................................... 16
4 ROLES, AUTHENTICATION AND SERVICES............................................................................18
4.1 ROLES ........................................................................................................................................... 18
4.1.1 Crypto Officer Authentication .............................................................................................. 19
4.1.2 User Authentication.............................................................................................................. 19
4.1.3 Wireless Client Authentication ............................................................................................. 19
4.1.4 Strength of Authentication Mechanisms ............................................................................... 19
4.2 SERVICES ...................................................................................................................................... 20
4.2.1 Crypto Officer Services......................................................................................................... 20
4.2.2 User Services........................................................................................................................ 22
4.2.3 Wireless Client Services ....................................................................................................... 22
4.2.4 Unauthenticated Services ..................................................................................................... 23
4.2.5 Service Available in Non-FIPS Mode................................................................................... 23
5 CRYPTOGRAPHIC ALGORITHMS ..............................................................................................24
6 CRITICAL SECURITY PARAMETERS.........................................................................................28
7 SELF TESTS........................................................................................................................................34
4
8 SECURE OPERATION......................................................................................................................36
8.1 CONFIGURING REMOTE AP FIPS MODE........................................................................................ 36
8.2 CONFIGURING CONTROL PLANE SECURITY (CPSEC) PROTECTED AP FIPS MODE........................ 37
8.3 CONFIGURING REMOTE MESH PORTAL FIPS MODE...................................................................... 38
8.4 CONFIGURING REMOTE MESH POINT FIPS MODE......................................................................... 39
8.5 VERIFY THAT THE MODULE IS IN FIPS MODE................................................................................. 40
8.6 FULL DOCUMENTATION ................................................................................................................ 41
5
1 Introduction
This document constitutes the non-proprietary Cryptographic Module Security Policy for the Aruba AP-
324 and AP-325 Wireless Access Points with FIPS 140-2 Level 2 validation from Aruba Networks. This
security policy describes how the AP meets the security requirements of FIPS 140-2 Level 2, and how to
place and maintain the AP in a secure FIPS 140-2 mode. This policy was prepared as part of the FIPS 140-
2 Level 2 validation of the product.
FIPS 140-2 (Federal Information Processing Standards Publication 140-2, Security Requirements for
Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More
information about the FIPS 140-2 standard and validation program is available on the National Institute of
Standards and Technology (NIST) Web-site at:
http://csrc.nist.gov/groups/STM/cmvp/index.html
This document can be freely distributed.
 The exact firmware version: ArubaOS 6.5.1-FIPS
In addition, in this document, the Aruba AP-324 and AP-325 Wireless Access Points are referred to as the
Access Point, the AP, the module, the cryptographic module, Aruba Wireless AP.
1.1 Acronyms and Abbreviations
AES Advanced Encryption Standard
AP Access Point
CBC Cipher Block Chaining
CLI Command Line Interface
CO Crypto Officer
CPSec Control Plane Security protected
CSEC Communications Security Establishment Canada
CSP Critical Security Parameter
ECO External Crypto Officer
EMC Electromagnetic Compatibility
EMI Electromagnetic Interference
FE Fast Ethernet
GE Gigabit Ethernet
GHz Gigahertz
HMAC Hashed Message Authentication Code
Hz Hertz
IKE Internet Key Exchange
IPsec Internet Protocol security
KAT Known Answer Test
KEK Key Encryption Key
L2TP Layer-2 Tunneling Protocol
LAN Local Area Network
LED Light Emitting Diode
SHA Secure Hash Algorithm
SNMP Simple Network Management Protocol
SPOE Serial & Power Over Ethernet
TEL Tamper-Evident Label
TFTP Trivial File Transfer Protocol
WLAN Wireless Local Area Network
6
2 Product Overview
This section introduces the various Aruba Wireless Access Points, providing a brief overview and summary
of the physical features of each model covered by this FIPS 140-2 security policy.
2.1 AP-324
Figure 1 - Aruba AP-324
This section introduces the Aruba AP-324 Wireless Access Point (AP) with FIPS 140-2 Level 2 validation.
It describes the purpose of the AP, its physical attributes, and its interfaces.
These compact and cost-effective dual-radio APs deliver wireless data rates of up to 1.733 Gbps to 5-GHz
devices with 802.11ac technology. They also support MU-MIMO with four spatial streams as well as 2.4-
GHz 802.11n clients at data rates up to 800 Mbps. 2.4-GHz and 5-GHz (1.733 Gbps max rate) radios, each
with 4SS MU-MIMO and four combined, duplexed (dual-band) external RP-SMA antenna connectors.
When managed by Aruba Mobility Controllers, AP-324 offers centralized configuration, data encryption,
policy enforcement and network services, as well as distributed and centralized traffic forwarding.
2.1.1 Physical Description
The Aruba AP-324 Access Point is a multi-chip standalone cryptographic module consisting of hardware
and software, all contained in a hard, opaque plastic and metal case. The module contains 802.11 a/b/g/n/ac
transceivers and supports external antennas through four N-type female connectors for external antennas.
The case physically encloses the complete set of hardware and software components and represents the
cryptographic boundary of the module.
The Access Point configuration validated during the cryptographic module testing included:
 HW: AP-324-F1 (HPE SKU JW185A)
7
2.1.1.1 Dimensions/Weight
The AP has the following physical dimensions:
 Dimensions/weight (unit, excluding mount accessories): - 203mm (W) x 203mm (D) x 57mm (H)
8.0” (W) x 8.0” (D) x 2.2” (H) - 950g/34 oz
 Dimensions/weight (shipping): - 315mm(W) x 265mm(D) x 100mm (H) 12.4” (W) x 10.4” (D) x
3.9” (H) - 1,350g/48 oz
Environmental
 Operating: - Temperature: 0° C to +50° C (+32° F to +122° F) - Humidity: 5% to 95% non-
condensing
Storage and transportation:
 Temperature: -40° C to +70° C (-40° F to +158° F)
Temperature: -40° C to +70° C (-40° F to +158° F)
2.1.1.2 Interfaces
The module provides the following network interfaces:
 Two 10/100/1000BASE-T Ethernet network interfaces (RJ-45)
 Auto-sensing link speed and MDI/MDX
 Link Aggregation support to achieve platform throughput up to 2 Gbps
 802.3az Energy Efficient Ethernet (EEE)
 PoE-PD: 48 Vdc (nominal) 802.3af or 802.3at PoE
DC power interface, accepts 2.1/5.5-mm center-positive
 12V DC power interface circular plug with 9.5-mm length
 USB 2.0 host interface (Type A connector)
Bluetooth Low Energy (BLE) radio
 Up to 4dBm transmit power (class 2) and -94dBm receive sensitivity
Other Interfaces
 Visual indicators (tri-color LEDs): For system and radio status
 Reset button: Factory reset (during device power up)
 Serial console interface (RJ-45)
8
AP-324 LED Status Indicators
LED Color/State Meaning
System Status
(Left)
Off AP powered off
Green/Amber
Alternating
Device booting; not ready
Green- Solid Device ready
Amber- Solid
Device ready; power-save mode (802.3af
PoE):
* Single radio
* USB disabled
Green or Amber
Flashing
Restricted mode:
* Uplink negotiated in sub optimal speed;
or
* Radio in non-high throughput (HT)
mode
Red System error condition
Radio Status
(Right)
Off AP powered off, or both radios disabled
Green- Solid Both radios enabled in access mode
Amber- Solid Both radios enabled in monitor mode
Green/Amber
Alternating
One radio enabled in access mode, one
enabled in monitor mode
9
2.2 AP-325
Figure 2 - Aruba AP-325
This section introduces the Aruba AP-325 Wireless Access Point (AP) with FIPS 140-2 Level 2 validation.
It describes the purpose of the AP, its physical attributes, and its interfaces.
These compact and cost-effective dual-radio APs deliver wireless data rates of up to 1.733 Gbps to 5-GHz
devices with 802.11ac technology. They also support MU-MIMO with four spatial streams as well as 2.4-
GHz 802.11n clients at data rates up to 800 Mbps. 2.4-GHz and 5-GHz (1.733 Gbps max rate) radios, each
with 4SS MU-MIMO and eight combined, duplexed (dual-band) internal antennas.
When managed by Aruba Mobility Controllers, AP-325 offers centralized configuration, data encryption,
policy enforcement and network services, as well as distributed and centralized traffic forwarding.
2.2.1 Physical Description
The Aruba AP-325 Access Point is a multi-chip standalone cryptographic module consisting of hardware
and software, all contained in a hard, opaque plastic and metal case. The module contains 802.11 a/b/g/n/ac
transceivers and contains eight combined, duplexed (dual-band) internal antennas..
The case physically encloses the complete set of hardware and software components and represents the
cryptographic boundary of the module.
The Access Point configuration validated during the cryptographic module testing included:
 HW: AP-325-F1(HPE SKU JW187A)
2.2.1.1 Dimensions/Weight
The AP has the following physical dimensions:
10
 Dimensions/weight (unit, excluding mount accessories): - 203mm (W) x 203mm (D) x 57mm (H)
8.0” (W) x 8.0” (D) x 2.2” (H) - 950g/34 oz
 Dimensions/weight (shipping): - 315mm(W) x 265mm(D) x 100mm (H) 12.4” (W) x 10.4” (D) x
3.9” (H) - 1,350g/48 oz
Environmental
 Operating: - Temperature: 0° C to +50° C (+32° F to +122° F) - Humidity: 5% to 95% non-
condensing
Storage and transportation:
 Temperature: -40° C to +70° C (-40° F to +158° F)
Temperature: -40° C to +70° C (-40° F to +158° F)
2.2.1.2 Interfaces
The module provides the following network interfaces:
 Two 10/100/1000BASE-T Ethernet network interfaces (RJ-45)
 Auto-sensing link speed and MDI/MDX
 Link Aggregation support to achieve platform throughput up to 2 Gbps
 802.3az Energy Efficient Ethernet (EEE)
 PoE-PD: 48 Vdc (nominal) 802.3af or 802.3at PoE
DC power interface, accepts 2.1/5.5-mm center-positive
 12V DC power interface circular plug with 9.5-mm length
 USB 2.0 host interface (Type A connector)
Bluetooth Low Energy (BLE) radio
 Up to 4dBm transmit power (class 2) and -94dBm receive sensitivity
Other Interfaces
 Visual indicators (tri-color LEDs): For system and radio status
 Reset button: Factory reset (during device power up)
 Serial console interface (RJ-45)
11
AP-325 LED Status Indicators
LED Color/State Meaning
System Status
(Left)
Off AP powered off
Green/Amber
Alternating
Device booting; not ready
Green- Solid Device ready
Amber- Solid
Device ready; power-save mode (802.3af PoE):
* Single radio
* USB disabled
Green or Amber
Flashing
Restricted mode:
* Uplink negotiated in sub optimal speed; or
* Radio in non-high throughput (HT) mode
Red System error condition
Radio Status
(Right)
Off AP powered off, or both radios disabled
Green- Solid Both radios enabled in access mode
Amber- Solid Both radios enabled in monitor mode
Green/Amber
Alternating
One radio enabled in access mode, one
enabled in monitor mode
12
3 Module Objectives
This section describes the assurance levels for each of the areas described in the FIPS 140-2 Standard.
3.1 Security Levels
Table 1 - Security Levels
Section Section Title Level
1 Cryptographic Module Specification 2
2 Cryptographic Module Ports and Interfaces 2
3 Roles, Services, and Authentication 2
4 Finite State Model 2
5 Physical Security 2
6 Operational Environment N/A
7 Cryptographic Key Management 2
8 EMI/EMC 2
9 Self-tests 2
10 Design Assurance 2
11 Mitigation of Other Attacks N/A
Overall Overall module validation level 2
3.2 Physical Security
The Aruba Wireless AP is a scalable, multi-processor standalone network device and is enclosed in a robust
plastic and metal housing. The AP enclosure is resistant to probing (please note that this feature has not
been validated as part of the FIPS 140-2 validation) and is opaque within the visible spectrum. The
enclosure of the AP has been designed to satisfy FIPS 140-2 Level 2 physical security requirements.
3.2.1 Applying TELs
The Crypto Officer must apply Tamper-Evident Labels (TELs) to the AP to allow detection of the opening
of the device, and to block the serial console port (on the bottom of the device). The TELs shall be installed
for the module to operate in a FIPS Approved mode of operation. Vendor provides FIPS 140 designated
TELs which have met the physical security testing requirements for tamper evident labels under the FIPS
140-2 Standard. TELs are not endorsed by the Cryptographic Module Validation Program (CMVP). Aruba
provides double the required amount of TELs with shipping and additional replacement TELs can be
obtained by calling customer support and requesting part number 4011570-01 (HPE SKU JY894A).
The Crypto Officer is responsible for securing and having control at all times of any unused tamper evident
labels. If evidence of tampering is found with the TELs, the module must immediately be powered down
and the administrator must be made aware of a physical security breach. The Crypto Officer should employ
TELs as follows:
 Before applying a TEL, make sure the target surfaces are clean and dry.
13
 Do not cut, trim, punch, or otherwise alter the TEL.
 Apply the wholly intact TEL firmly and completely to the target surfaces.
 Ensure that TEL placement is not defeated by simultaneous removal of multiple modules.
 Allow 24 hours for the TEL adhesive seal to completely cure.
 Record the position and serial number of each applied TEL in a security log.
 To obtain additional or replacement TELS, please order Aruba Networks part number: 4011570—
01 (HPE SKU JY894A).
Once applied, the TELs included with the AP cannot be surreptitiously broken, removed or reapplied
without an obvious change in appearance:
Each TEL has a unique serial number to prevent replacement with similar label. To protect the device from
tampering, TELs should be applied by the Crypto Officer as pictured below:
3.2.2 Inspection/Testing of Physical Security Mechanisms
Table 3.2 - Inspection/Testing of Physical Security Mechanisms
Physical Security Mechanism Recommended Test Frequency Guidance
Tamper-evident labels (TELs) Once per month Examine for any sign of removal,
replacement, tearing, etc. See
images below for locations of
TELs. If any TELS are found to
be missing or damaged, contact a
system administrator immediately
Opaque module enclosure Once per month Examine module enclosure for
any evidence of new openings or
other access to the module
internals. If any TELS are found
to be missing or damaged, contact
a system administrator
immediately
3.2.3 TELs Placement
This section displays all the TELs locations on each of module.
3.2.3.1 TELs Placement on the AP-324
The AP-324 requires 3 TELs. One on each edge (labels 1 and 2) and one covering the console port (label
3). See figures 6, and 7 for placement.
14
Figure 6 - Top View of AP-324 with TELs
Figure 7 – Bottom View of AP-324 with TELs
3.2.3.2 TEL Placement on the AP-325
The AP-325 requires 3 TELS. One on each edge (labels 1 and 2) and one covering the console port (label
3). See figures 8 and 9 for placement.
15
Figure 8 – Top View of AP-325 with TELs
Figure 9 – Bottom View of AP-325 with TELs
16
3.2.4 Inspection/Testing of Physical Security Mechanisms
Table 2 - Inspection/Testing of Physical Security Mechanisms
Physical Security Mechanism Recommended
Test Frequency
Guidance
Tamper-evident labels (TELs) Once per month Examine for any sign of removal, replacement,
tearing, etc. See images above for locations of
TELs. If any TELS are found to be missing or
damaged, contact a system administrator
immediately
Opaque module enclosure Once per month Examine module enclosure for any evidence of new
openings or other access to the module internals. If
any indication is found that indicates tampering,
contact a system administrator immediately
3.3 Operational Environment
The FIPS 140‐2 Operational Environment requirements are not applicable because the module is
designated as a non-modifiable operational environment. The module only allows the loading of trusted and
verified firmware that is signed by Aruba.
3.4 Logical Interfaces
The physical interfaces are divided into logical interfaces defined by FIPS 140-2 as described in the
following table.
Table 3 - Logical Interfaces
FIPS 140-2 Logical Interface Module Physical Interface
Data Input Interface  10/100/1000 Ethernet Ports
 802.11a/b/g/n/ac Antenna Interfaces
 USB 2.0 Interface
Data Output Interface  10/100/1000 Ethernet Ports
 802.11a/b/g/n/ac Antenna Interfaces
 USB 2.0 Interface
Control Input Interface  10/100/1000 Ethernet Ports
 802.11a/b/g/n/ac Antenna Interfaces
 Reset button
Status Output Interface  10/100/1000 Ethernet Ports
 802.11a/b/g/n/ac Antenna Interfaces
 USB 2.0 Interface
Power Interface  Power Input
 Power-over-Ethernet (POE)
Data input and output, control input, status output, and power interfaces are defined as follows:
17
 Data input and output are the packets that use the networking functionality of the module.
 Control input consists of manual control inputs for power and reset through the power interfaces
(power supply or POE). It also consists of all of the data that is entered into the access point while
using the management interfaces. A reset button is present which is used to reset the AP to factory
default settings.
 Status output consists of the status indicators displayed through the LEDs, the status data that is
output from the module while using the management interfaces, and the log file.
o LEDs indicate the physical state of the module, such as power-up (or rebooting),
utilization level, and activation state. The log file records the results of self-tests,
configuration errors, and monitoring data.
 The module may be powered by an external power supply. Operating power may also be provided
via Power Over Ethernet (POE) device, when connected, the power is provided through the
connected Ethernet cable.
 Console port is disabled when operating in FIPS mode by TEL.
The module distinguishes between different forms of data, control, and status traffic over the network ports
by analyzing the packet headers and contents.
18
4 Roles, Authentication and Services
4.1 Roles
The module supports the roles of Crypto Officer, User, and Wireless Client; no additional roles (e.g.,
Maintenance) are supported. Administrative operations carried out by the Aruba Mobility Controller 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 CSPs.
Defining characteristics of the roles depend on whether the module is configured as in either Remote AP
FIPS mode, Control Plane Security (CPSec) Protected AP FIPS mode or Mesh AP FIPS Mode. There are
four FIPS approved modes of operations, which are Remote AP FIPS mode, Control Plane Security
(CPSec) Protected AP FIPS mode and the two Mesh Modes, Remote Mesh Portal FIPS Mode and Remote
Mesh Point FIPS Mode. Please refer to section 8 in this documentation for more information.
 Remote AP FIPS mode:
o Crypto Officer role: the Crypto Officer is the Aruba Mobility Controller that has the
ability to configure, manage, and monitor the module, including the configuration,
loading, and zeroization of CSPs.
o User role: in the configuration, the User operator shares the same services and
authentication techniques as the Mobility Controller in the Crypto Officer role.
o Wireless Client role: in Remote AP FIPS mode configuration, a wireless client can create
a connection to the module using 802.11i and access wireless network access/bridging
services. When Remote AP cannot communicate with the controller, the wireless client
role authenticates to the module via 802.11i Pre-shared secret only.
 CPSec Protected AP FIPS mode:
o Crypto Officer role: the Crypto Officer is the Aruba Mobility Controller that has the
ability to configure, manage, and monitor the module, including the configuration,
loading, and zeroization of CSPs.
o User role: in the configuration, the User operator shares the same services and
authentication techniques as the Mobility Controller in the Crypto Officer
o Wireless Client role: in CPSec Protected AP FIPS mode configuration, a wireless client
can create a connection to the module using 802.11i Pre-shared secret and access wireless
network access services.
 Remote Mesh Portal FIPS mode:
o Crypto Officer role: the Crypto Officer is the Aruba Mobility Controller that has the
ability to configure, manage, and monitor the module, including the configuration,
loading, and zeroization of CSPs.
o User role: the adjacent Mesh Point APs in a given mesh cluster. Please notice that
Remote Mesh Portal AP must be physically wired to Mobility Controller.
o Wireless Client role: in Remote Mesh Portal FIPS AP configuration, a wireless client can
create a connection to the module using WPA2 and access wireless network access
services.
 Remote Mesh Point FIPS mode:
o Crypto Officer role: the Crypto Officer role is the Aruba Mobility Controller that has the
ability to configure, manage, and monitor the module, including the configuration,
19
loading, and zeroization of CSPs. The first mesh AP configured is the only AP with the
direct wired connection.
o User role: the adjacent Mesh APs in a given mesh cluster. Please notice that User role can
be a Mesh Point AP or a Mesh Portal AP in the given mesh network.
o Wireless Client role: in Mesh Remote Mesh Point FIPS AP configuration, a wireless
client can create a connection to the module using WPA2 and access wireless network
access services.
4.1.1 Crypto Officer Authentication
In each of FIPS approved modes, the Aruba Mobility Controller implements the Crypto Officer role.
Connections between the module and the mobility controller are protected using IPSec. Crypto Officer’s
authentication is accomplished via either Pre-shared secret (IKEv1), RSA digital certificate (IKEv1/IKEv2)
or ECDSA digital certificate (IKEv2).
4.1.2 User Authentication
Authentication for the User role depends on the module configuration. When the module is configured in
Remote Mesh Portal FIPS mode or Remote Mesh Point FIPS mode, the User role is authenticated via the
WPA2 pre-shared key or EAP. When the module is configured as a Remote AP FIPS mode and CPSec
protected AP FIPS mode, the User role is authenticated via the same IKEv1/IKEv2 pre-shared key or
RSA/ECDSA certificate that is used by the Crypto Officer
4.1.3 Wireless Client Authentication
The wireless client role defined in each of FIPS approved modes authenticates to the module via 802.11i.
Please notice that WEP and TKIP configurations are not permitted in FIPS mode. When Remote AP cannot
communicate with the controller, the wireless client role authenticates to the module via 802.11i Pre-shared
secret only.
4.1.4 Strength of Authentication Mechanisms
The following table describes the relative strength of each supported authentication mechanism.
Table 4 - Strength of Authentication Mechanisms
Authentication
Mechanism
Mechanism Strength
IKEv1 Pre-shared
secret based
authentication
(CO/User role)
Passwords are required to be a minimum of eight ASCII characters and a
maximum of 64 with a minimum of one letter and one number, or 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 is less than 1 in
100,000 required by FIPS 140-2.
20
Authentication
Mechanism
Mechanism Strength
802.11i Pre-shared
secret based
authentication
(Wireless Client and
Mesh AP user roles)
Passwords are required to be a minimum of eight 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’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 is
less than 1 in 100,000 required by FIPS 140-2.
RSA Certificate
based authentication
(CO/User role)
The module supports 2048-bit RSA key authentication during IKEv1 and
IKEv2. RSA 2048 bit keys correspond to 112 bits of security. Assuming the
low end of that range, the associated probability of a successful random
attempt is 1 in 2^112, which is less than 1 in 1,000,000 required by FIPS 140-
2. 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 is less than 1 in 100,000 required by FIPS 140-2.
ECDSA Certificate
based authentication
(CO/User role)
ECDSA signing and verification is used to authenticate to the module during
IKEv1/IKEv2. Both P-256 and P-384 curves are supported. ECDSA P-256
provides 128 bits of equivalent security, and P-384 provides 192 bits of
equivalent security. Assuming the low end of that range, the associated
probability of a successful random attempt during a one-minute period is 1 in
2^128, which is less than 1 in 1,000,000 required by FIPS 140-2. 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
is less than 1 in 100,000 required by FIPS 140-2.
4.2 Services
The module provides various services depending on role. These are described below.
4.2.1 Crypto Officer Services
The CO role in each of FIPS modes defined in section 4.1 has the same services.
Table 5 - Crypto Officer Services
21
Services Description CSPs Accessed (see section 6
below for a complete description
to each CSP and the associated
cryptographic algorithms)
FIPS mode enable/disable The CO selects/de-selects FIPS
mode as a configuration option.
None.
Key Management The CO can configure/modify the
IKEv1/IKEv2 shared secret (The
RSA private key is protected by
non-volatile memory and cannot
be modified) and the 802.11i Pre-
shared secret (used in advanced
Remote AP configuration). Also,
the CO/User implicitly uses the
KEK to read/write configuration
to non-volatile memory.
1 (read), 13 and 25(write)
Remotely reboot module The CO can remotely trigger a
reboot
None
Self-test triggered by CO/User
reboot
The CO can trigger a
programmatic reset leading to
self-test and initialization
None.
Update module firmware The CO can trigger a module
firmware update
1, 12 (read)
Configure non-security related
module parameters
CO can configure various
operational parameters that do not
relate to security
None.
Creation/use of secure
management session between
module and CO
The module supports use of
IPSec for securing the
management channel.
2, 3, 4, 5. 6, 7, .8, 9, 10, 11 (read,
write) 13 (read) 14, 15, 16, 17,
18, 19, 20, 21, 22, 23, 24 (read,
write)
System Status CO may view system status
information through the secured
management channel
See creation/use of secure
management session above.
Creation/use of secure mesh
channel
The module requires secure
connections between mesh points
using 802.11i
1, 25 (read)
26, 27, 28, 29, 30 (read/write)
22
Services Description CSPs Accessed (see section 6
below for a complete description
to each CSP and the associated
cryptographic algorithms)
Zeroization The cryptographic keys stored in
SDRAM memory can be zeroized
by rebooting the module. The
cryptographic keys (IKEv1 Pre-
shared secret and 802.11i Pre-
shared secret) stored in the flash
can be zeroized by using
command ‘ap wipe out flash’ or
by overwriting with a new secret.
The other keys/CSPs (KEK,
RSA/ECDSA public key/private
key and certificate) stored in
Flash memory can be zeroized by
using command ‘ap wipe out
flash’.
All CSPs will be destroyed.
4.2.2 User Services
The User role for Remote AP FIPS mode and Control Plane Security (CPSec) Protected AP FIPS mode
supports the same services listed in the Section 4.2.1 Crypto Officer Services.
The User role for Remote Mesh Portal FIPS mode and Remote Mesh Point FIPS mode supports the
services listed in Section 4.2.3 Wireless Client Role.
4.2.3 Wireless Client Services
The following services are provided for the Wireless Client role in Remote AP FIPS mode, CPSec
protected AP FIPS mode, Remote Mesh Portal FIPS mode and Remote Mesh Point FIPS mode.
Table 6- User Services (Wireless Client Services)
Service Description CSPs Accessed (see section 6
below for a complete description
to each CSP and the associated
cryptographic algorithms)
Generation and use of 802.11i
cryptographic keys
In all modes, the links between
the module and wireless client are
secured with 802.11i.
1, 25 (read) 26,27,28,29,30
(read/write)
Use of 802.11i Pre-shared secret
for establishment of IEEE
802.11i keys
When the module is in advanced
Remote AP configuration, the
links between the module and the
wireless client are secured with
802.11i. This is authenticated
with a shared secret only.
1, 25 (read)
Wireless bridging services The module bridges traffic
between the wireless client and
the wired network.
None
23
4.2.4 Unauthenticated Services
The module provides the following unauthenticated services, which are available regardless of role.
 System status – module LEDs
 Reboot module by removing/replacing power
 Self-test and initialization at power-on.
4.2.5 Service Available in Non-FIPS Mode
• All of the services that are available in FIPS mode are also available in non-FIPS mode.
• When operating in the non-FIPS mode, the TLS, SSH, and 802.11i services can utilize the non-Approved
algorithms listed in the “Non-FIPS Approved Cryptographic Algorithms used only in Non-FIPS 140
Mode” section at the end of section 5.
• Upgrading the firmware via the console port.
• Debugging via the console port.
Please note that all CSPs will be zeroized automatically when switching from FIPS mode to non-FIPS
mode, or from non-FIPS mode to FIPS mode.
24
5 Cryptographic Algorithms
The firmware in each module contains the following cryptographic algorithm implementations/crypto
libraries to implement the different FIPS approved cryptographic algorithms that will be used for the
corresponding security services supported by the module in FIPS mode: NOTE: The modes listed for each
algorithm are only those actually used by the module (additional modes may have been tested during
CAVS testing and not currently used).
 ArubaOS OpenSSL Module algorithm implementation
 ArubaOS Crypto Module algorithm implementation
 ArubaOS UBOOT Bootloader algorithm implementation
 Aruba AP Hardware algorithm implementation
Below are the detailed lists for the FIPS approved algorithms and the associated certificate implemented by
each crypto library
ArubaOS OpenSSL
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
3998 AES
FIPS 197,
SP 800-
38A
ECB, CBC,
CFB
(128only),
CTR (192,
256, ext only)
128, 192, 256
Data
Encryption/Decryption
825
CVL
RSASP1
PKCS 1.5
FIPS 186-4 MOD 2048 RSA
1188 DRBG
SP 800-
90A
AES CTR 256
Deterministic Random
Number Generation
891 ECDSA 186-4
PKG, SigGen,
SigVer
P256, P384
Digital Key
Generation, Signature
Generation and
Verification
2610 HMAC FIPS 198-1
HMAC-
SHA1,
HMAC-SHA-
256, HMAC-
SHA-384,
HMAC-SHA-
512
112, 126, 160,
256
Message
Authentication
92 KBKDF SP 800-108 CTR
HMAC-
SHA1,HMAC-
SHA256,
HMAC-SHA384
Deriving Keys
2054 RSA FIPS 186-2
SHA-1, SHA-
256, SHA-
384, SHA-512
PKCS1 v1.5
1024 (legacy
SigVer only),
2048
Digital Signature
Verification
25
2054 RSA FIPS 186-4
SHA-1, SHA-
256, SHA-
384, SHA-512
PKCS1 v1.5
2048
Key Gen, Digital
Signature Generation
and Verification
3300 SHS FIPS 180-4
SHA-1, SHA-
256, SHA-
384, SHA-512
Byte Only
Message Digest
2196 Triple-DES SP 800-67 TEBC, TCBC 192
Data
Encryption/Decryption
Note:
o RSA (non-compliant with the following functions:)
 FIPS186-2:
ALG[ANSIX9.31]: Key(gen)(MOD: 1024 PubKey Values: 65537)
ALG[RSASSA-PKCS1_V1_5]: SIG(gen): 1024, SHS: SHA-1/SHA-256/SHA-
384/SHA-512, 2048, SHS: SHA-1
o ECDSA (non-compliant with the following functions:)
 FIPS186-2:
SIG(gen): CURVES(P-256 P-384), SHS: SHA-1
ArubaOS Crypto Module
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
4138 AES
FIPS 197,
SP 800-38A
CBC, GCM,
CTR (ext
only)
128, 192, 256
Data
Encryption/Decryption
944
CVL
IKEv1,
IKEv2
SP800-135
IKEv1(DSA,
PSK 2048,
SHA-256,
384),
IKEv2(2048
SHA-356,
384)
Key Derivation
945 RSASP1 186-4
2048 PKCS
#1.5
Key Gen, SigVer,
SigGen
950 ECDSA 186-4
PKG, SigGen,
SigVer (P-
256, 384, SHA
1, 256, 384,
512
P256, P384
PKG,Digital Signature
Generation and
Verification
2711 HMAC FIPS 198-1
HMAC-
SHA1,
HMAC-SHA-
256, HMAC-
SHA-384,
HMAC-SHA-
112, 126, 160,
256
Message
Authentication
26
512
2254 RSA FIPS 186-2
SHA-1, SHA-
256, SHA-
384, SHA-512
PKCS1 v1.5
1024 (legacy
SigVer only),
2048
Digital Signature
Verification
2254 RSA FIPS 186-4
SHA-1, SHA-
256, SHA-
384, SHA-512
PKCS1 v1.5
2048, 1024
(legacy SigVer
only)
Key Generation,
Digital Signature
Generation and
Verification
3408 SHS FIPS 180-4
SHA-1, SHA-
256, SHA-
384, SHA-512
Byte Only
Message Digest
2262 Triple-DES SP 800-67 TCBC 192
Data
Encryption/Decryption
Note:
o RSA (non-compliant with the following functions:)
 FIPS186-2:
ALG[ANSIX9.31]: Key(gen)(MOD: 1024 PubKey Values: 65537)
ALG[RSASSA-PKCS1_V1_5]: SIG(gen): 1024, SHS: SHA-1/SHA-256/SHA-
384/SHA-512, 2048, SHS: SHA-1
o ECDSA (non-compliant with the following functions:)
 FIPS186-2:
SIG(gen): CURVES(P-256 P-384), SHS: SHA-1
ArubaOS UBOOT Bootloader
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
2395 RSA FIPS 186-4
SHA-1,
SHA256
2048
Digital Signature
Verification
3633 SHS FIPS 180-4
SHA-1, SHA-
256 Byte Only
Message Digest
NOTE: Only Firmware signed with SHA-256 is permitted in the Approved mode. Digital signature
verification with SHA-1, while available within the module, shall only be used while in the non-Approved
mode.
Aruba AP Hardware
CAVP
Certificate #
Algorithm Standard Mode/Method
Key Lengths,
Curves, Moduli
Use
1648 AES
FIPS 197,
SP 800-38A
ECB, CBC,
CFB128,
OFB, CTR
128, 192, 256
Data
Encryption/Decryption
27
(ext only)
CCM,
GCM(used for
self-test only)
538 HMAC FIPS 198-1
HMAC-
SHA1,
HMAC-SHA-
256, HMAC-
SHA-384,
HMAC-SHA-
512
112, 126, 160,
256
Message
Authentication
934 SHS FIPS 180-4
SHA-1, SHA-
256, SHA-
384, SHA-512
Byte Only
Message Digest
758 Triple-DES SP 800-67
TEBC, TCBC,
TOFB
192
Data
Encryption/Decryption
Non-FIPS Approved Algorithms Allowed in FIPS Mode
 Diffie-Hellman (key agreement; key establishment methodology provides 112 bits of encryption
strength)
 EC Diffie-Hellman (key agreement; key establishment methodology provides 128 or 192 bits of
encryption strength)
 NDRNG (used solely to seed the Approved DRBG)
NOTE: IKEv1 and IKEv2 protocols have not been reviewed or tested by the CAVP and CMVP.
Non-FIPS Approved Cryptographic Algorithms used only in Non-FIPS 140
Mode
The cryptographic module implements the following non-approved algorithms that are not
permitted for use, and are not used, in the FIPS 140-2 mode of operations:
 DES
 HMAC-MD5
 MD5
 RC4
Note: DES, MD5, HMAC-MD5 and RC4 are used for older versions of TLS, SSH and WEP non-
approved mode
28
6 Critical Security Parameters
The following Critical Security Parameters (CSPs) are used by the module:
Table 7 - Critical Security Parameters
#
Name Algorithm/Key Size Generation/Use Storage Zeroization
General Keys/CSPs
1 Key Encryption Key
(KEK)
Triple-DES
(192 bits)
Hardcoded during
manufacturing. Used only
to protect keys stored in
the flash, not for key
transport. (3 Key, CBC)
Stored in Flash
memory (plaintext)
Zeroized by using
command ‘ap wipe
out flash’.
2 DRBG entropy input SP 800-90a
CTR_DRBG
(512 bits)
Entropy inputs to DRBG
function used to construct
the DRBG seed. 64 bytes
are gotten from the
entropy source on each
call by any service that
requires a random number.
Testing estimates 505.26
bits of entropy are returned
in the 512 bit string.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
3 DRBG seed SP 800-90a
CTR_DRBG
(384-bits)
Input to the DRBG that
determines the internal
state of the DRBG.
Generated using DRBG
derivation function that
includes the entropy input
from the entropy source.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
4 DRBG Key SP 800-90a
CTR_DRBG
(256 bits)
This is the DRBG key
used for SP 800-90a
CTR_DRBG.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
5 DRBG V SP 800-90a
CTR_DRBG V
(128 bits)
Internal V value used as
part of SP 800-90a
CTR_DRBG.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
29
6 Diffie-Hellman
private key
Diffie-Hellman
Group 14 (224 bits)
Generated internally by
calling FIPS approved
DRBG (Cert. #1188) to
derive Diffie-Hellman
shared secret used in both
IKEv1 and IKEv2.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
7 Diffie-Hellman public
key
Diffie-Hellman
Group 14 (2048
bits)
Derived internally in
compliance with Diffie-
Hellman key agreement
scheme. Used for
establishing DH shared
secret.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
8 Diffie-Hellman shared
secret
Diffie-Hellman
Group 14 (2048
bits)
Established during Diffie-
Hellman Exchange. Used
for deriving IPSec/IKE
cryptographic keys.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
9 EC Diffie-Hellman
private key
EC Diffie-Hellman
(Curves: P-256 or
P-384).
Generated internally by
calling FIPS approved
DRBG (Cert #1188)
during EC Diffie-Hellman
Exchange. Used for
establishing ECDH shared
secret.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
10 EC Diffie-Hellman
public key
EC Diffie-Hellman
(Curves: P-256 or
P-384).
Derived internally in
compliance with EC
Diffie-Hellman key
agreement scheme. Used
for establishing ECDH
shared secret.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
11 EC Diffie-Hellman
shared secret
EC Diffie-Hellman
(Curves: P-256 or
P-384)
Established during EC
Diffie-Hellman Exchange.
Used for deriving
IPSec/IKE cryptographic
keys.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
12 Factory CA Public
Key
RSA
(2048 bits)
This is RSA public key.
Loaded into the module
during manufacturing.
Used for Firmware
verification.
Stored in Flash
encrypted with
KEK
Zeroized by using
command ‘ap wipe
out flash’
IPSec/IKE
30
13 IKEv1 Pre-shared
secret
Shared secret
(8 - 64 ASCII or 64
HEX characters)
Entered by CO role.
Used for IKEv1 peers
authentication.
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’ or by
overwriting with a
new secret
14 skeyid Shared Secret
(160/256/384 bits)
A shared secret known
only to IKEv1 peers. It
was established via key
derivation function
defined in SP800-135
KDF (IKEv1). Used for
deriving other keys in
IKEv1 protocol
implementation.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module.
15 skeyid_d Shared Secret
(160/256/384 bits)
A shared secret known
only to IKEv1 peers. It
was derived via key
derivation function
defined in SP800-135
KDF (IKEv1). Used for
deriving IKEv1 session
authentication key.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
16 SKEYSEED Shared Secret
(160/256/384 bits)
A shared secret known
only to IKEv2 peers. It
was derived via key
derivation function
defined in SP800-135
KDF (IKEv2) and it will
be used for deriving
other keys in IKEv2
protocol.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
17 IKE session
authentication key
HMAC-SHA-
1/256/384
(160/256/384 bits)
The IKE session (IKE
Phase I) authentication
key. This key is derived
via key derivation
function defined in
SP800-135 KDF
(IKEv1/IKEv2). Used
for IKEv1/IKEv2
payload integrity
verification.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
18 IKE session
encryption key
Triple-DES
(192 bits, 3 Key CBC)
/AES (128/192/256
bits, CBC)
The IKE session (IKE
Phase I) encrypt key.
This key is derived via
key derivation function
defined in SP800-135
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
31
KDF (IKEv1/IKEv2).
Used for IKE payload
protection.
19 IPSec session
encryption keys
Triple-DES (192 bits, 3
KEY CBC) / AES
(CBC) and AES-GCM
(128/192/256 bits)
The IPsec (IKE phase II)
encryption key. This key
is derived via a key
derivation function
defined in SP800-135
KDF (IKEv1/IKEv2).
Used for IPSec traffics
protection.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
20 IPSec session
authentication keys
HMAC-SHA-1 (160
bits)
The IPsec (IKE Phase
II) authentication key.
This key is derived via
using the KDF defined
in SP800-135 KDF
(IKEv1/IKEv2). Used
for IPSec traffics
integrity verification.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
21 IKE RSA Private
Key
RSA private key
(2048 bits)
This is the RSA private
key. This key is
generated by the module
in compliance with FIPS
186-4 RSA key pair
generation method. In
both IKEv1 and IKEv2,
DRBG (Cert. #1188) is
called for key
generation. It is used for
RSA signature signing
in either IKEv1 or
IKEv2.
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’
22 IKE RSA public
key
RSA public key
(2048 bits)
This is the RSA public
key. This key is derived
in compliance with FIPS
186-4 RSA key pair
generation method in the
module. It is used for
RSA signature
verification in either
IKEv1 or IKEv2.
This key can also be
entered by the CO on
the Mobility Controller
via SSH (CLI) and/or
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’
32
TLS (for the GUI).
23 IKE ECDSA
Private Key
ECDSA suite B
(Curves: P-256 or P-
384)
This is the ECDSA
private key. This key is
generated by the module
in compliance with FIPS
186-4 ECDSA key pair
generation method. In
IKEv2, DRBG (Cert
#1188) is called for key
generation. It is used for
ECDSA signature
signing in IKEv2.
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’.
24 IKE ECDSA Public
Key
ECDSA suite B
(Curves: P-256 or P-
384)
This is the ECDSA
public key. This key is
derived in compliance
with FIPS 186-4
ECDSA key pair
generation method in the
module. It is used for
ECDSA signature
verification in IKEv2.
This key can also be
entered by the CO on
the Mobility Controller
via SSH (CLI) and/or
TLS (for the GUI).
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’
802.11i
25 802.11i Pre-shared
secret
Shared secret
(8-63 ASCII
characters, or 64 HEX
characters)
Entered by CO role.
Used for 802.11i
client/server
authentication.
Stored in Flash
memory encrypted
with KEK
Zeroized by using
command ‘ap wipe
out flash’ or by
overwriting with a
new secret.
26 802.11i Pair-Wise
Master key (PMK)
Shared secret
(256 bits)
The PMK is
transported to the
module, protected by
IPSec secure tunnel.
Used to derive the
Pairwise Transient Key
(PTK) for 802.11i
communications.
Stored in SDRAM
(plaintext)
Zeroized by
rebooting the
module
33
27 802.11i Pairwise
Transient Key
(PTK)
HMAC
(384 bits)
This key is used to
derive 802.11i session
key by using the KDF
defined in SP800-108.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
28 802.11i session key AES-CCM
(128 bits)
Derived during 802.11i
4-way handshake by
using the KDF defined
in SP800-108 then used
as the session key.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
29 802.11i Group
Master Key (GMK)
Shared secret
(256 bits)
Generated by calling
DRBG (Cert. #1188).
Used to derive 802.11i
Group Transient Key
GTK.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
30 802.11i Group
Transient Key
(GTK)
AES-CCM
(256 bits)
Derived from 802.11
GMK by using the
KDF defined in SP800-
108. The GTK is the
802.11i session key
used for broadcast
communications
protection.
Stored in SDRAM
memory (plaintext)
Zeroized by
rebooting the
module
Please note that:
 AES GCM IV generation is performed in compliance with the Implementation Guidance A.5
scenario 2. FIPS approved DRBG (Cert. #1188) is used for IV generation and 96 bits of IV is
supported).
 For keys identified as being "Generated internally by calling FIPS approved DRBG", the
generated seed used in the asymmetric key generation is an unmodified output from the DRBG.
 CSPs labeled as “Entered by CO” (as well as the ECDSA/RSA public keys) are entered into the
module via SSH/TLS or from the controller via IPSec.
34
7 Self Tests
The module performs Power On Self-Tests regardless the modes (non-FIPS mode, Remote AP FIPS mode,
Control Plane Security (CPSec) Protected AP FIPS mode, Remote Mesh Portal FIPS mode or Remote
Mesh Point FIPS mode). In addition, the module also performs Conditional tests after being configured
into either Remote AP FIPS mode, Control Plane Security (CPSec) Protected AP FIPS mode Remote
Mesh Portal FIPS mode or Remote Mesh Point FIPS mode. In the event any self-test fails, the module
enters an error state, logs the error, and reboots automatically.
The module performs the following power on self-tests:
ArubaOS OpenSSL Module:
 AES (encrypt/decrypt) KATs
 Triple-DES (encrypt/decrypt) KATs
 DRBG KAT
 RSA (sign/verify) KATs
 ECDSA (sign/verify) KATs
 SHS (SHA1, SHA256, SHA384 and SHA512) KATs
 HMAC (HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) KATs
ArubaOS Crypto Module
 AES (encrypt/decrypt) KATs
 AES-GCM (encrypt/decrypt) KATs
 Triple-DES (encrypt/decrypt) KATs
 SHA (SHA1, SHA256, SHA384 and SHA512) KATs
 HMAC (HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) KATs
 RSA (sign/verify) KATs
 ECDSA (sign/verify) KATs
ArubaOS UBOOT Bootloader Module
 Firmware Integrity Test: RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-
256 (the integrity test is the KAT)
Aruba AP Hardware algorithm implementation power on self-tests:
 AES (encrypt/decrypt) KATs
 AES-CCM (encrypt/decrypt) KATs
 AES-GCM (encrypt/decrypt) KATs
 Triple-DES (encrypt/decrypt) KATs
 SHA-1 KAT
 HMAC (HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 and HMAC-SHA512) KATs
The following Conditional Tests are performed in the module:
ArubaOS OpenSSL Module algorithm implementation
 CRNG Test to Approved RNG (DRBG)
 SP800-90A Section 11.3 Health Tests for CTR_DRBG (Instantiate, Generate and Reseed).
 ECDSA Pairwise Consistency Test
35
 RSA Pairwise Consistency Test
ArubaOS Crypto Module algorithm implementation
 RSA Pairwise Consistency Test
 ECDSA Pairwise Consistency Test
ArubaOS UBOOT Bootloader Module algorithm implementation
 Firmware Load Test - RSA PKCS#1 v1.5 (2048 bits) signature verification with SHA-256
CRNG test to NDRNG
These self-tests are run for the hardware cryptographic implementation as well as for the Aruba OpenSSL
and ArubaOS cryptographic module implementations.
Self-test results are written to the serial console.
In the event of a KATs failure, the AP logs different messages, depending on the error.
For an ArubaOS OpenSSL AP module and ArubaOS cryptographic module KAT failure:
AP rebooted [DATE][TIME] : Restarting System, SW FIPS KAT failed
For an AES Atheros hardware POST failure:
Starting HW SHA1 KAT ...Completed HW SHA1 AT
Starting HW HMAC-SHA1 KAT ...Completed HW HMAC-SHA1 KAT
Starting HW AES KAT ...Restarting system.
36
8 Secure Operation
The module can be configured to be in the following FIPS approved modes of operations via corresponding
Aruba Mobility Controllers that have been certified to FIPS level 2:
• Remote AP FIPS mode – 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.
• Control Plane Security (CPSec) Protected AP FIPS mode – 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.
• Remote Mesh Portal FIPS mode – When the module is configured in Mesh Portal mode, 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 802.11i
session. The Crypto Officer role is the Mobility Controller that authenticates via IKEv1/IKEv2
pre-shared key or RSA/ECDSA certificate authentication method, and Users are the "n" Mesh
Points that authenticate via 802.11i preshared key.
• Remote Mesh Point FIPS mode – an AP that establishes all wireless path to the Remote Mesh
portal in FIPS mode over 802.11 and an IPSec tunnel via the Remote Mesh Portal to the
controller.
In addition, the module also supports a non-FIPS mode – an un-provisioned AP, which by default does not
serve any wireless clients. The Crypto Officer must first enable and then provision the AP into a FIPS AP
mode of operation. Only firmware updates signed with SHA-256/RSA 2048 are permitted.
This section explains how to place the module in each FIPS mode and how to verify that it is in FIPS mode.
An important point in the Aruba APs is that to change configurations from any one mode to any other mode
requires the module to be re-provisioned and rebooted before any new configured mode can be enabled.
The access point is managed by an Aruba Mobility Controller in FIPS 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 FIPS mode. The controller used to provision the AP is referred to below as the
“staging controller”. The staging controller must be provisioned with the appropriate firmware image for
the module, which has been validated to FIPS 140-2, prior to initiating AP provisioning. The Crypto
Officer shall perform the following steps:
8.1 Configuring Remote AP FIPS Mode
1. Apply TELs according to the directions in section 3.2
2. Log into the administrative console of the staging controller
3. Deploying the AP in Remote FIPS mode configure the controller for supporting Remote APs, For
detailed instructions and steps, see Section “Configuring the Secure Remote Access Point Service”
in Chapter “Remote Access Points” of the Aruba OS User Manual.
4. Enable FIPS mode on the controller. This is accomplished by going to the Configuration >
Network > Controller > System Settings page (this is the default page when you click the
Configuration tab), and clicking the FIPS Mode for Mobility Controller Enable checkbox.
37
5. Enable FIPS mode on the AP. This accomplished by going to the Configuration > Wireless > AP
Configuration > AP Group page. There, you click the Edit button for the appropriate AP group,
and then select AP > AP System Profile. Then, check the “Fips Enable” box, check “Apply”, and
save the configuration.
6. If the staging controller does not provide PoE, either ensure the presence of a PoE injector for the
LAN connection between the module and the controller, or ensure the presence of a DC power
supply appropriate to the particular model of the module.
7. 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.
8. Once the module is connected to the controller by the Ethernet cable, navigate to the
Configuration > Wireless > AP Installation page, where you should see an entry for the AP.
Select that AP, click the “Provision” button, which will open the provisioning window. Now
provision the AP as Remote AP by filling in the form appropriately. Detailed steps are listed in
section entitled “Provisioning an Individual AP” in the ArubaOS User Guide. Click “Apply and
Reboot” to complete the provisioning process.
(The User Guide is available at:
https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/EntryId/23053/Def
ault.aspx)
a. During the provisioning process as Remote AP if Pre-shared secret is selected to be the
Remote AP Authentication Method, the IKE Pre-shared secret (8 - 64 ASCII or 64 HEX
characters) is input to the module during provisioning. In the initial provisioning of an
AP, this key will be entered in plaintext; subsequently, during provisioning, it will be
entered encrypted over the secure IPSec session. If certificate based authentication is
chosen, the AP’s RSA or ECDSA key pair is used to authenticate AP to controller during
IPSec.
9. Via the logging facility of the staging controller, ensure that the module (the AP) is successfully
provisioned with firmware and configuration
10. Terminate the administrative session
11. Disconnect the module from the staging controller, and install it on the deployment network; when
power is applied, the module will attempt to discover and connect to an Aruba Mobility Controller
on the network.
8.2 Configuring Control Plane Security (CPSec) Protected
AP FIPS mode
1. Apply TELs according to the directions in section 3.2
2. Log into the administrative console of the staging controller
3. Configure the staging controller with CPSec under Configuration > Controller > Control Plane
Security tab. AP will authenticate to the controller using certificate based authentication (IKEv2)
to establish IPSec. The AP is configured with an RSA key pair at manufacturing. The AP’s
certificate is signed by Aruba Certification Authority (trusted by all Aruba controllers) and the
AP’s RSA private key is stored in non-volatile memory. Refer to the “Configuring Control Plane
Security” section in the ArubaOS User Manual for details on the steps.
38
4. Enable FIPS mode on the controller. This is accomplished by going to the Configuration >
Network > Controller > System Settings page (this is the default page when you click the
Configuration tab), and clicking the FIPS Mode for Mobility Controller Enable checkbox.
5. Enable FIPS mode on the AP. This accomplished by going to the
Configuration > Wireless > AP Configuration > AP Group page. There, you click the Edit
button for the appropriate AP group, and then select AP > AP System Profile. Then, check the
“FIPS Enable” box, check “Apply”, and save the configuration.
6. If the staging controller does not provide PoE, either ensure the presence of a PoE injector for the
LAN connection between the module and the controller, or ensure the presence of a DC power
supply appropriate to the particular model of the module
7. 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.
8. Once the module is connected to the controller by the Ethernet cable, navigate to the
Configuration > Wireless > AP Installation page, where you should see an entry for the AP.
Select that AP, click the “Provision” button, which will open the provisioning window. Now
provision the CPSec Mode by filling in the form appropriately. Detailed steps are listed in Section
“Provisioning an Individual AP” of Chapter “The Basic User-Centric Networks” of the Aruba OS
User Guide. Click “Apply and Reboot” to complete the provisioning process.
a. For CPSec AP mode, the AP always uses certificate based authentication to establish
IPSec connection with controller. AP uses the RSA key pair assigned to it at
manufacturing to authenticate itself to controller during IPSec. Refer to “Configuring
Control Plane Security” Section in Aruba OS User Manual for details on the steps to
provision an AP with CPSec enabled on controller.
9. Via the logging facility of the staging controller, ensure that the module (the AP) is successfully
provisioned with firmware and configuration
10. Terminate the administrative session
11. Disconnect the module from the staging controller, and install it on the deployment network; when
power is applied, the module will attempt to discover and connect to an Aruba Mobility Controller
on the network.
8.3 Configuring Remote Mesh Portal FIPS Mode
1. Apply TELs according to the directions in section 3.2
2. Log into the administrative console of the staging controller
3. Deploying the AP in Remote Mesh Portal mode, create the corresponding Mesh Profiles on the
controller as described in detail in Section “Mesh Profiles” of Chapter “Secure Enterprise Mesh”
of the Aruba OS User Manual.
a. For mesh configurations, configure a WPA2 PSK which is 8-63 ASCII characters or 64
hexadecimal digits in length; generation of such keys is outside the scope of this policy.
4. Enable FIPS mode on the controller. This is accomplished by going to the Configuration >
Network > Controller > System Settings page (this is the default page when you click the
Configuration tab), and clicking the FIPS Mode for Mobility Controller Enable checkbox.
5. Enable FIPS mode on the AP. This accomplished by going to the Configuration > Wireless > AP
Configuration > AP Group page. There, you click the Edit button for the appropriate AP group,
and then select AP > AP System Profile. Then, check the “FIPS Enable” box, check “Apply”,
and save the configuration.
39
6. If the staging controller does not provide PoE, either ensure the presence of a PoE injector for the
LAN connection between the module and the controller, or ensure the presence of a DC power
supply appropriate to the particular model of the module.
7. 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.
8. Once the module is connected to the controller by the Ethernet cable, navigate to the
Configuration > Wireless > AP Installation page, where you should see an entry for the AP.
Select that AP, click the “Provision” button, which will open the provisioning window. Now
provision the AP as Remote Mesh Portal by filling in the form appropriately. Detailed steps are
listed in Section “Provisioning an Individual AP” of Chapter “The Basic User-Centric Networks”
of the Aruba OS User Guide. Click “Apply and Reboot” to complete the provisioning process.
a. During the provisioning process as Remote Mesh Portal, if Pre-shared key is selected to
be the Remote IP Authentication Method, the IKE pre-shared key (which is at least 8
characters in length) is input to the module during provisioning. Generation of this key is
outside the scope of this policy. In the initial provisioning of an AP, this key will be
entered in plaintext; subsequently, during provisioning, it will be entered encrypted over
the secure IPSec session. If certificate based authentication is chosen, AP’s RSA key pair
is used to authenticate AP to controller during IPSec. AP’s RSA private key is contained
in the AP’s non volatile memory and is generated at manufacturing time in factory.
b. During the provisioning process as Remote Mesh Portal, the WPA2 PSK is input to the
module via the corresponding Mesh cluster profile. This key is stored on flash encrypted.
9. Via the logging facility of the staging controller, ensure that the module (the AP) is successfully
provisioned with firmware and configuration
10. Terminate the administrative session
11. Disconnect the module from the staging controller, and install it on the deployment network; when
power is applied, the module will attempt to discover and connect to an Aruba Mobility Controller
on the network.
To verify that the module is in FIPS mode, do the following:
1. Log into the administrative console of the Aruba Mobility Controller
2. Verify that the module is connected to the Mobility Controller
3. Verify that the module has FIPS mode enabled by issuing command “show ap ap-name <ap-
name> config”
4. Terminate the administrative session
8.4 Configuring Remote Mesh Point FIPS Mode
1. Apply TELs according to the directions in section 3.2
2. Log into the administrative console of the staging controller
3. Deploying the AP in Remote Mesh Point mode, create the corresponding Mesh Profiles on the
controller as described in detail in Section “Mesh Points” of Chapter “Secure Enterprise Mesh” of
the Aruba OS User Manual.
a. For mesh configurations, configure a WPA2 PSK which is 8-63 ASCII characters or 64
hexadecimal digits in length; generation of such keys is outside the scope of this policy.
4. Enable FIPS mode on the controller. This is accomplished by going to the Configuration >
Network > Controller > System Settings page (this is the default page when you click the
Configuration tab), and clicking the FIPS Mode for Mobility Controller Enable checkbox.
40
5. Enable FIPS mode on the AP. This accomplished by going to the Configuration > Wireless > AP
Configuration > AP Group page. There, you click the Edit button for the appropriate AP group,
and then select AP > AP System Profile. Then, check the “Fips Enable” box, check “Apply”, and
save the configuration.
6. If the staging controller does not provide PoE, either ensure the presence of a PoE injector for the
LAN connection between the module and the controller, or ensure the presence of a DC power
supply appropriate to the particular model of the module.
7. 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.
8. Once the module is connected to the controller by the Ethernet cable, navigate to the
Configuration > Wireless > AP Installation page, where you should see an entry for the AP.
Select that AP, click the “Provision” button, which will open the provisioning window. Now
provision the AP as Remote Mesh Portal by filling in the form appropriately. Detailed steps are
listed in Section “Provisioning an Individual AP” of Chapter “The Basic User-Centric Networks”
of the Aruba OS User Guide. Click “Apply and Reboot” to complete the provisioning process.
a. During the provisioning process as Remote Mesh Point, if Pre-shared key is selected to
be the Remote IP Authentication Method, the IKE pre-shared key (which is 8 – 64 ASCII
characters or 64 HEX characters in length) is input to the module during provisioning.
Generation of this key is outside the scope of this policy. In the initial provisioning of an
AP, this key will be entered in plaintext; subsequently, during provisioning, it will be
entered encrypted over the secure IPSec session. If certificate based authentication is
chosen, AP’s RSA key pair is used to authenticate AP to controller during IPSec. AP’s
RSA private key is contained in the AP’s non volatile memory and is generated at
manufacturing time in factory.
b. During the provisioning process as Mesh Point, the WPA2 PSK is input to the module via
the corresponding Mesh cluster profile. This key is stored on flash encrypted.
9. Via the logging facility of the staging controller, ensure that the module (the AP) is successfully
provisioned with firmware and configuration
10. Terminate the administrative session
11. Disconnect the module from the staging controller, and install it on the deployment network; when
power is applied, the module will attempt to discover and connect to an Aruba Mobility Controller
on the network.
8.5 Verify that the module is in FIPS mode
For all the approved modes of operations in either Remote AP FIPS mode or Control Plane Security
(CPSec) Protected AP FIPS modedo the following to verify the module is in FIPS mode:
1. Log into the administrative console of the Aruba Mobility Controller
2. Verify that the module is connected to the Mobility Controller
3. Verify that the module has FIPS mode enabled by issuing command “show ap ap-name <ap-
name> config”
4. Terminate the administrative session
41
8.6 Full Documentation
Can be found at:
https://support.arubanetworks.com/Documentation/tabid/77/DMXModule/512/Default.aspx?EntryId=2305
4