Specifications

Security Target Version 1.0 9/29/2014
75
• FMT_MTD.1(2): The TOE provides no interfaces that allow user passwords to be read. Passwords are not
stored in plaintext. They are stored on flash using a SHA1 hash. They are used for administrative
authentication. Wireless user passwords are found in an external AAA/RADIUS server.
• FMT_MTD.1(3): The TOE provides no interfaces that allow pre-shared, symmetric, or private keys to be
read.
• FMT_SMF.1: The TOE provides administrative functions to manage all TOE security functions identified
in this Security Target including but not limited to management of cryptographic functions, secure TOE
updates, banner message configuration, etc.
• FMT_SMR.1: The TOE supports role-based authentication. Administrators can make use of both local and
remotely accessible administrator interfaces.
6.6 Protection of the TSF
Communication between the Mobility Controller and APs is protected in two manners. All control traffic (i.e., TSF
data) is protected from disclosure and modification using IPsec. All data traffic is protected in the same way that it is
protected over-the-air since that traffic is encrypted and decrypted at the Mobility Controller and not at the APs.
The Mobility Controller has an internal battery-backed hardware clock that provides reliable time stamps used for
auditing. The internal clock may be synchronized (not required) with a time signal obtained from an external NTP
server.
The Mobility Controller and AP run a suite of self-tests during power-up and periodically during operation, which
includes demonstration of the correct operation of the hardware and the use of cryptographic functions to verify the
integrity of TSF executable code and static data. An administrator can choose to reboot the TOE to perform power-
up self-tests. The Mobility Controller and AP runs the suite of FIPS 140-2 validated cryptographic module self-tests
during start-up or on request from the administrator, including immediately after generation of a key (FIPS self-
tests, including the continuous RNG test). If a self-test fails, the TOE will immediately halt operation thereby
preventing potentially insecure operations (i.e., maintaining a secure state). The controller will reboot after a self-test
failure. During reboot, memory is re-initialized, which wipes all keys and user data. If a self-test failure continues
to occur, the controller will continue to reboot repeatedly.
The TOE uses IPsec, TLS, and SSH for all communications terminating at the TOE. Each of these protocols
includes features to detect replayed data and the TOE will reject any such data that is received.
In order to update the firmware, the administrator can download the firmware file from the Aruba support website.
Using TFTP, FTP, SCP, or HTTPS (Web UI only), the administrator can import the image into the controller.
The Protection of the TSF function is designed to satisfy the following security functional requirements:
• FPT_FLS.1: The TOE will stop when power-on self-tests fail in order to prevent entering an insecure
operational state.
• FPT_ITT.1: The TOE protects TSF data sent between the Mobility Controller and APs using IPsec.
• FPT_RPL.1: The TOE can detected repeated IPsec, TLS, or SSH packets and will discard any such packets
when received.
• FPT_STM.1: The TOE provides its own time and/or relies on an external trusted time server for this
function.
• FPT_TST_EXT.1: The TOE offers a suite of self-tests for administrator (in FIPS terminology, the Crypto
Officer which is mapped to the administrator role) to verify the correct operation of the key generation and
static TSF cryptographic data. Software images are hashed and cryptographically signed, and an image
with an invalid signature will not be copied by the controller into the image partition. Likewise, a software
image stored in the image partition through external means will be rejected by the hardware bootloader if
the image hash or signature is invalid. RSA2048 and SHA1 are used to sign the image. The signing
certificate is issued by Aruba’s internal CA. This CA is stored offline with private keys protected by an
HSM. The public root CA certificate is programmed into the bootROM of all Aruba products at the time of
manufacturing. On the Aruba 7200 series controller, the public root CA certificate is programmed into the