FIPS 140-2 Non-Proprietary Security Policy for Aruba AP-120 Series Wireless Access Points Version 1.1 March 6, 2009 Aruba NetworksTM 1322 Crossman Ave. Sunnyvale, CA 94089-1113 1 1 INTRODUCTION .................................................................................................................................3 1.1 ACRONYMS AND ABBREVIATIONS ................................................................................................... 3 2 PRODUCT OVERVIEW......................................................................................................................4 2.1 AP-120 SERIES ................................................................................................................................ 4 2.1.1 Physical Description............................................................................................................... 4 2.1.1.1 Dimensions/Weight ............................................................................................................ 4 2.1.1.2 Interfaces ............................................................................................................................ 5 2.1.1.3 Indicator LEDs ................................................................................................................... 5 3 MODULE OBJECTIVES.....................................................................................................................6 3.1 SECURITY LEVELS ........................................................................................................................... 6 3.2 PHYSICAL SECURITY ....................................................................................................................... 6 3.2.1 AP-124 TEL Placement .......................................................................................................... 7 3.2.2 AP-125 TEL Placement .......................................................................................................... 8 3.2.3 Inspection/Testing of Physical Security Mechanisms ............................................................. 8 3.3 MODES OF OPERATION .................................................................................................................... 9 3.4 OPERATIONAL ENVIRONMENT....................................................................................................... 11 3.5 LOGICAL INTERFACES ................................................................................................................... 11 4 ROLES, AUTHENTICATION, AND SERVICES...........................................................................13 4.1 ROLES ........................................................................................................................................... 13 4.1.1 Crypto Officer Authentication .............................................................................................. 13 4.1.2 User Authentication.............................................................................................................. 13 4.1.3 Wireless Client Authentication ............................................................................................. 13 4.1.4 Strength of Authentication Mechanisms ............................................................................... 14 4.2 SERVICES ...................................................................................................................................... 15 4.2.1 Crypto Officer and User Services......................................................................................... 15 4.2.2 Wireless Client Services ....................................................................................................... 16 4.2.3 Unauthenticated Services ..................................................................................................... 16 5 CRYPTOGRAPHIC KEY MANAGEMENT...................................................................................17 5.1 IMPLEMENTED ALGORITHMS ......................................................................................................... 17 6 CRITICAL SECURITY PARAMETERS.........................................................................................18 7 SELF TESTS........................................................................................................................................21 2 1 Introduction This document constitutes the non-proprietary Cryptographic Module Security Policy for the AP-120 series 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://www.nist.gov/cmvp This document can be freely distributed. 1.1 Acronyms and Abbreviations AES Advanced Encryption Standard AP Access Point CBC Cipher Block Chaining CLI Command Line Interface CO Crypto Officer 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 3 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-120 Series This section introduces the Aruba AP-120 series Wireless Access Points (APs) with FIPS 140-2 Level 2 validation. It describes the purpose of the AP, its physical attributes, and its interfaces. Figure 1 - AP-120 Series Wireless Access Points The Aruba AP-124 and AP-125 are high-performance 802.11n (3x3) MIMO, dual-radio (concurrent 802.11a/n + b/g/n) indoor wireless access points capable of delivering combined wireless data rates of up to 600Mbps. These multi-function access points provide wireless LAN access, air monitoring, and wireless intrusion detection and prevention over the 2.4-2.5GHz and 5GHz RF spectrum. The access points work in conjunction with Aruba Mobility Controllers to deliver high-speed, secure user-centric network services in education, enterprise, finance, government, healthcare, and retail applications. 2.1.1 Physical Description The Aruba AP-120 series Access Point is a multi-chip standalone cryptographic module consisting of hardware and software, all contained in a hard plastic case. The module contains IEEE 802.11a, 802.11b, 802.11g, and 802.11n transceivers, and up to 3 integrated or external omni-directional multi-band dipole antenna elements may be attached to the module. The plastic case physically encloses the complete set of hardware and software components and represents the cryptographic boundary of the module. The evaluated hardware versions are designated as · AP-124-F1: Rev 01 · AP-125-F1: Rev 01 The evaluated firmware version is designated as ArubaOS 3.3.2-FIPS. 2.1.1.1 Dimensions/Weight The AP has the following physical dimensions: · 4.9" x 5.13" x 2.0" (124mm x 130mm x 51mm) · 15oz (0.42 Kgs) 4 2.1.1.2 Interfaces The module provides the following network interfaces: · 2 x 10/100/1000 Base-T Ethernet (RJ45) Auto-sensing link speed and MDI/MDX · Antenna (model AP-124 only) o 3 x RP-SMA antenna interfaces (supports up to 3x3 MIMO with spatial diversity) · 1 x RJ-45 console interface The module provides the following power interfaces: · 48V DC 802.3af or 802.3at or PoE + interoperable Power-over-Ethernet (PoE) with intelli-source PSE sourcing intelligence · 5V DC for external AC supplied power (adapter sold separately) 2.1.1.3 Indicator LEDs There are 5 bicolor (power, ENET 0, 1, and WLAN) LEDs which operate as follows: Label Function Action Status PWR AP power / ready status Off No power to AP Red Power applied, bootloader starting Flashing - Green Device booting, not ready On - Green Device ready ENET 0 Ethernet Network Link Off Ethernet link unavailable Status / Activity On - Amber 10/100Mbs Ethernet link negotiated On - Green 1000Mbs Ethernet link negotiated Flashing Ethernet link activity ENET 1 Ethernet Network Link Off Ethernet link unavailable Status / Activity (Dual radio On - Amber 10/100Mbs Ethernet link negotiated only) On - Green 1000Mbs Ethernet link negotiated Flashing Ethernet link activity WLAN 2.4Ghz 2.4GHz Radio Status Off 2.4GHz radio disabled On - Amber 2.4GHz radio enabled in WLAN mode On ­ Green 2.4GHz radio enabled in 802.11n mode Flashing 2.4GHz Air monitor WLAN 5Ghz 5GHz Radio Status Off 5GHz radio disabled On - Amber 5GHz radio enabled in WLAN mode On ­ Green 5GHz radio enabled in 802.11n mode Flashing 2.4GHz Air monitor Table 1- Indicator LEDs 5 3 Module Objectives This section describes the assurance levels for each of the areas described in the FIPS 140-2 Standard. In addition, it provides information on placing the module in a FIPS 140-2 approved configuration. 3.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 3.2 Physical Security The Aruba Wireless AP is a scalable, multi-processor standalone network device and is enclosed in a robust plastic housing. The AP enclosure is resistant to probing (please note that this feature has not been tested 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. For physical security, the AP requires Tamper-Evident Labels (TELs) to allow detection of the opening of the device, and to block the serial console port (on the bottom of the device). To protect the device from tampering, TELs should be applied by the Crypto Officer as pictured below: 6 3.2.1 AP-124 TEL Placement Following is the TEL placement for the AP-124: 1 2 3 7 3.2.2 AP-125 TEL Placement Following is the TEL placement for the AP-125: 1 2 3 3.2.3 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 Opaque module enclosure Once per month Examine module enclosure for any evidence of new openings or other access to the module internals. 8 3.3 Modes of Operation The module supports a FIPS approved mode of operation (Remote AP mode) as well as a non-approved mode This section explains how to place the module in FIPS mode, and how to verify that it is in this mode. The access point is managed by an Aruba Mobility Controller, 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 and issued certificate #1075 or #1077, prior to initiating AP provisioning. After setting up the Access Point by following the basic installation instructions in the module User Manual, the Crypto Officer performs the following steps: 1. Apply TELs according to the directions in section 3.2 2. Log into the administrative console of the staging controller 3. Create a Remote AP profile. For detailed instructions on creating a Remote AP profile, see Volume 3, "Configuring APs", Section 7, "Configuring Remote APs" in the module User Manual. a. Configure an IKE pre-shared key which is at least 8 characters 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. 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, and then click "Apply and Reboot" to complete the provisioning process. During the provisioning process, the IKE pre-shared key is input to the module. In the initial provisioning of an AP, this keys will be entered in plaintext; subsequently, during provisioning, it will be entered encrypted over the secure IPSec session. For more detail on this process, see Volume 3, "Configuring APs", Section 5, "Configuring Access Points" in the module User Manual. 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 9 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 using IPsec. 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 config" 4. Terminate the administrative session 10 3.4 Operational Environment The operational environment is non-modifiable. The Operating System (OS) is Linuz, a real-time multi- threaded operating system that supports memory protection between processes. Access to the underlying Linux implementation is not provided directly. Only Aruba-provided Crypto Officer interfaces are used. There is no user interface provided. 3.5 Logical Interfaces The physical interfaces are divided into logical interfaces defined by FIPS 140-2 as described in the following table. FIPS 140-2 Logical Interface Module Physical Interface Data Input Interface 10/100/1000 Ethernet Ports 802.11a/b/g/n Radio Transceiver Data Output Interface 10/100/1000 Ethernet Ports 802.11a/b/g/n Radio Transceiver Control Input Interface 10/100/1000 Ethernet Ports (PoE) 5V power input jack Status Output Interface 10/100/1000 Ethernet Ports 802.11a/b/g/n Radio Transceiver RJ-45 Serial Console Interface LEDs Power Interface Power Supply PoE Table 2 - FIPS 140-2 Logical Interfaces Data input and output, control input, status output, and power interfaces are defined as follows: · 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 (5V DC or PoE). It also consists of all of the data that is entered into the access point while using the management interfaces. · 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. · A power supply may be used to connect the electric power cable. Operating power may also be provided via Power Over Ethernet (POE) device when connected. The power is provided through the connected Ethernet cable. 11 The module distinguishes between different forms of data, control , and status traffic over the network ports by analyzing the packet headers and contents. 12 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. · Here are the defining characteristics of the roles: 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 standard 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 an advanced Remote AP configuration, a wireless client can create a connection to the module using WPA2-PSK. The Wireless Client can access wireless bridging services. 4.1.1 Crypto Officer Authentication The Aruba Mobility Controller implements the Crypto Officer role. Connections between the module and the mobility controller are protected using IPsec. Crypto Officer authentication is accomplished via proof of possession of the IKE preshared key, which occurs during the IKE key exchange. 4.1.2 User Authentication The User role is authenticated via the same IKE pre-shared key that is used by the Crypto Officer. 4.1.3 Wireless Client Authentication The wireless client role, in the Remote AP advanced configuration authenticates to the module via the WPA2 preshared key. Note that when the Remote AP advanced configuration options are used, WPA2- PSK must be used for authentication. WEP and/or Open System configurations are not permitted in FIPS mode. 13 4.1.4 Strength of Authentication Mechanisms The following table describes the relative strength of each supported authentication mechanism. Authentication Mechanism Strength Mechanism IKE shared secret For IKE, there are a 95^8 (=6.63 x 10^15) possible preshared keys. In order (CO role) to test the guessed key, the attacker must complete an IKE aggressive mode exchange with the module. IKE aggressive mode consists of a 3 packet exchange, but for simplicity, let's ignore the final packet sent from the AP to the attacker. An IKE aggressive mode initiator packet with a single transform, using Diffie-Hellman group 2, and having an eight character group name has an IKE packet size of 256 bytes. Adding the eight byte UDP header and 20 byte IP header gives a total size of 284 bytes (2272 bits). The response packet is very similar in size, except that it also contains the HASH_R payload (an additional 16 bytes), so the total size of the second packet is 300 bytes (2400 bits). Assuming a link speed of 1Gbits/sec (this is the maximum rate supported by the module), this gives a maximum idealized guessing rate of 60,000,000,000 / 4,672 = 12,842,466 guesses per minute. This means the odds of guessing a correct key in one minute is less than 12,842,466/(6.63x10^15) = 1.94 x 10^- 9, which is much less than 1 in 10^5. Wireless Client For WPA2-PSK there are at least 95^16 (=4.4 x 10^31) possible WPA2-PSK combinations. In order to test a guessed key, the attacker must complete the (Wireless Client 4-way handshake with the AP. Prior to completing the 4-way handshake, the Role) attacker must complete the 802.11 association process. That process involves the following packet exchange: · Attacker sends Authentication request (at least 34 bytes) · AP sends Authentication response (at least 34 bytes) · Attacker sends Associate Request (at least 36 bytes) · AP sends Associate Response (at least 36 bytes) Total bytes sent: at least 140. Note that since we do not include the actual 4- way handshake, this is less than half the bytes that would actually be sent, so the numbers we derive will absolutely bound the answer. The theoretical bandwidth limit for IEEE 802.11n is 300Mbit, which is 37,500,000 bytes/sec. In the real world, actual throughput is significantly less than this, but we will use this idealized number to ensure that our estimate is very conservative. This means that the maximum number of associations (assume no delays, no inter-frame gaps) that could be completed is less than 37,500,000/214 = 267,857 per second, or 16,071,429 associations per minute. This means that an attacker could certainly not try more than this many keys per second (it would actually be MUCH less, due to the added overhead of the 4-way handshake in each case), and the probability of a successful attack in any 60 second interval MUST be less than 16,071,429/(4.4 x 10^31), or roughly 1 in 10^25, which is much less than 1 in 10^5. 14 4.2 Services The module provides various services depending on role. These are described below. 4.2.1 Crypto Officer and User Services Service Description CSPs Accessed (see section 6 below for complete description of CSPs) FIPS mode enable/disable The CO/User selects/de-selects None. FIPS mode as a configuration option. Key Management The CO/User can · IKE shared secret configure/modify the IKE shared secret and the WPA2 PSK. Also, · WPA2 PSK the CO/User implicitly uses the · KEK KEK to read/write configuration to non-volatile memory. Remotely reboot module The CO/User can remotely KEK is accessed when trigger a reboot configuration is read during reboot. The firmware verification key and firmware verification CA key are accessed to validate firmware prior to boot. Self-test triggered by CO/User The CO/User can trigger a KEK is accessed when reboot programmatic reset leading to configuration is read during self-test and initialization reboot. The firmware verification key and firmware verification CA key are accessed to validate firmware prior to boot. Update module firmware The CO/User can trigger a The firmware verification key module firmware update and firmware verification CA key are accessed to validate firmware prior to writing to flash. Configure non-security related CO/User can configure various None. module parameters operational parameters that do not relate to security Creation/use of secure The module supports use of IPsec · IKE Preshared Secret management session between for securing the management module and CO/User channel. · DH Private Key · DH Public Key · IPsec session encryption keys · IPsec session authentication keys System Status CO/User may view system status See creation/use of secure information through the secured management session above. management channel 15 4.2.2 Wireless Client Services The following Module Services are provided for the Wireless Client role: Service Description CSPs Accessed (see section 6 below for complete description of CSPs) Generation and use of 802.11i When the module is in Remote · 802.11i PMK cryptographic keys AP advanced configuration, the links between the module and · 802.11i PTK wireless client are secured with · 802.11i EAPOL MIC 802.11i. Key · 802.11i EAPOL Encryption Key · 802.11i AES-CCM key · 802.11i GMK · 802.11i GTK Use of WPA preshared key for When the module is in Remote establishment of IEEE 802.11i AP configuration, the links keys between the module and the · WPA2 PSK wireless client are secured with 802.11i. This is authenticated with a shared secret 4.2.3 Unauthenticated Services The module provides the following unauthenticated services, which are available regardless of role. No CSPs are accessed by these services. · System status ­ SYSLOG and module LEDs · 802.11 a/b/g/n · FTP · TFTP · NTP · GRE tunneling of 802.11 wireless user frames (when acting as a "Local AP") · Reboot module by removing/replacing power · Self-test and initialization at power-on 16 5 Cryptographic Key Management 5.1 Implemented Algorithms FIPS-approved cryptographic algorithms have been implemented in hardware and software. Some modules provide Cavium Octeon 5010 hardware encryption acceleration for bulk cryptographic operations for the following FIPS-approved algorithms: · AES (Cert. #861) - CBC; 128,192,256 bits - CCM; 128 bits, Assoc. Data Len Range: 15 - 30, Payload Length Range: 0 - 32, Nonce Length(s): 13, Tag Length(s): 8 · TDES (Cert. #708) - CBC; 192 bits (168 used)/1,2,3 keys keying option · SHA-1 (Cert. #856) - BYTE oriented · HMAC SHA-1 (Cert. #478) Hardware encryption is provided for the following non-FIPS-approved algorithms. · MD5 The firmware implementation uses OpenSSL FIPS crypto library version 1.1.1, as well as the UBOOT boot loader. The firmware implements the following FIPS-approved algorithms: · OpenSSL Module o AES (Cert. #900) - CBC: 128, 192, 256 bits o Triple-DES (Cert. #734)- CBC key options Keying Options 1,2,3 used o SHA-1 (Cert. #892) - BYTE oriented o HMAC SHA-1 (Cert. #503) o RSA (Cert. #436) o RNG (Cert. #516) · UBOOT Bootloader cryptographic module o SHA-1 (Cert. #891) - BYTE oriented o RSA (Cert. #435) The firmware implements the following non-FIPS-approved algorithms in firmware: · MD5 The firmware implements the following non-approved but allowed algorithms in firmware: · Diffie-Hellman Diffie-Hellman key establishment methodology provides 80-bits of encryption strength. 17 6 Critical Security Parameters The following Critical Security Parameters (CSPs) are used by the module: STORAGE CSP CSP TYPE GENERATION And USE ZEROIZATION KEK TDES key Hard-coded Stored in flash, Encrypts IKE zeroized by the preshared keys and `ap wipe out flash' configuration command. parameters IKE Pre-shared 64 character Externally generated Encrypted in flash Module and crypto secret preshared key using the KEK; officer authentication zeroized by during IKE; entered updating through into the module in administrative plaintext during interface, or by the initialization and `ap wipe out flash' encrypted over the command. IPSec session subsequently. IPsec session 168-bit TDES, Established during Stored in plaintext Secure IPsec traffic encryption keys Diffie-Hellman key in volatile 128/192/256 bit agreement memory; zeroized AES keys; when session is closed or system powers off IPsec session HMAC SHA-1 Established during Stored in plaintext Secure IPsec traffic authentication keys Diffie-Hellman key in volatile keys agreement memory; zeroized when session is closed or system powers off IKE Diffie- 1024-bit Diffie- Generated internally Stored in plaintext Used in establishing Hellman Private Hellman during IKE negotiation in volatile the session key for key private key memory; zeroized IPsec when session is closed or system is powered off IKE Diffie- 1024-bit Diffie- Generated internally Stored in plaintext Used in establishing Hellman public Hellman during IKE negotiation in volatile memory the session key for key private key IPsec PRNG seeds PRNG Seed (8 Generated by non- In volatile memory Seed PRNG bytes) approved PRNG only; zeroized on reboot PRNG Keys PRNG Keys Generated by non- In volatile memory PRNG operation (16 bytes, approved PRNG only; zeroized on TDES 2-keying reboot option) 18 STORAGE CSP CSP TYPE GENERATION And USE ZEROIZATION WPA2 PSK 16-64 character Externally generated Encrypted in flash Used to derive the shared secret using the KEK; PMK for 802.11i used remote zeroized by advanced Remote AP AP advanced updating through connections; entered configuration administrative into the module in interface, or by the plaintext during `ap wipe out flash' initialization and command. encrypted over the IPSec session subsequently. 802.11i 512-bit shared Internally generated In volatile memory Used to derive Pairwise Master secret used to using WPA PSK only; zeroized on 802.11i Pairwise Key (PMK) derive 802.11i reboot Transient Key (PTK) session keys 802.11i 512-bit shared Derived during 802.11i In volatile memory All session Pairwise secret from 4-way handshake only; zeroized on encryption/decryption Transient Key which reboot keys are derived from (PTK) Temporal Keys the PTK (TKs) are derived 802.11i 128-bit shared Derived from PTK In volatile memory Used for integrity secret used to only; zeroized on validation in 4-way EAPOL MIC protect 4-way reboot handshake Key (key) handshake 802.11i EAPOL 128-bit shared Derived from PTK In volatile memory Used for Encr Key secret used to only; zeroized on confidentiality in 4- protect 4-way reboot way handshake handshakes 802.11i data 128-bit AES- Derived from PTK Stored in plaintext Used for 802.11i AES-CCM CCM key in volatile packet encryption and encryption/mic memory; zeroized integrity verification key on reboot (this is the CCMP or AES-CCM key) 802.11i Group 256-bit secret Internally generated Stored in plaintext Used to derive Group Master Key used to derive from approved RNG in volatile Transient Key (GTK) (GMK) GTK memory; zeroized on reboot 802.11i Group 256-bit shared Internally derived by Stored in plaintext Used to derive Transient Key secret used to AP which assumes in volatile multicast (GTK) derive group "authenticator" role in memory; zeroized cryptographic keys (multicast) handshake on reboot encryption and integrity keys 19 STORAGE CSP CSP TYPE GENERATION And USE ZEROIZATION 802.11i Group 128-bit AES- Derived from 802.11 Stored in plaintext Used to protect AES-CCM Data CCM key group key handshake in volatile multicast message Encryption/MIC derived from memory; zeroized confidentiality and Key GTK on reboot integrity (AES-CCM) Firmware 2048-bit RSA Externally generated Stored in plaintext Used to validate the verification key public key in bootloader signature on firmware image image Firmware CA 2048-bit RSA Externally generated Stored in plaintext Used to validate key public key in bootloader certificate containing image Firmware verification key 20 7 Self Tests The module performs both power-up and conditional self-tests. 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-up self-tests: · Software Integrity Test­The module checks the integrity of its firmware by validating a 2048-bit RSA digital signature over the same image to ensure its authenticity. · Cryptographic Algorithm Tests ­ These tests are run at power-up for the TDES encryption/decryption, AES and AES-CCM encryption/decryption, SHA-1 known answer test, HMAC SHA-1 known answer test, RSA signature verification, and the PRNG random data generation. The following Conditional Self-tests are performed in the module: · Continuous Random Number Generator Test­This test is run upon generation of random data by the module's random number generators to detect failure to a constant value. These self-tests are run for the Cavium hardware cryptographic implementation as well as for the OpenSSL implementation. 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 OpenSSL KAT failure: AP rebooted [DATE][TIME] : Restarting System, SW FIPS KAT failed For an AES cavium hardware POST failure: Starting HW SHA1 KAT ...Completed HW SHA1 KAT Starting HW HMAC-SHA1 KAT ...Completed HW HMAC-SHA1 KAT Starting HW DES KAT ...Completed HW DES KAT Starting HW AES KAT ...Restarting system. 21