VIEWS: 3 PAGES: 17 POSTED ON: 2/8/2012
802.11 WLAN ARCHITECTURE – BEST PRACTICES February 16, 2005 A Whitepaper Prepared by 3e Technologies International 9715 Key West Avenue, Fifth Floor Rockville, MD 20850 Page 1 of 17 802.11 WLAN ARCHITECTURE – BEST PRACTICES EXECUTIVE SUMMARY This whitepaper presents the two major approaches for deploying Wireless Local Area Networks (WLANs) in the enterprise. Both approaches require Wireless 802.11 based Access Points (APs) and some method for managing these network elements. However, the two approaches have some basic philosophical differences which can have a major impact on deployment costs, security and manageability. 3e Technologies, a company at the forefront of providing secure wireless solutions to the Federal Government, makes a case for the so-called “Distributed” or “Extension” Architectural approach. This paper points out the superiority of such an approach over the “Centralized” or “Overlay” approach to WLAN network deployment. Some of the major points described in this paper are the complexities and potential security vulnerabilities of deploying Virtual Private Network or VPN technology. While the authors of this whitepaper agree that VPN technology is the best choice for Remote Network Access for so-called “road warriors” or personnel who need to access base resources remotely, VPNs are not the optimal solution for day to day wireless connectivity on the base. The technical details of a layer 3 VPN Trojan attack are described as well as the protection offered by Layer 2 encryption approaches such as those offered by 3eTI. Furthermore, this paper shows that only distributed encryption, that is where each Access Point (AP) has built in Cryptographic Modules, provides sufficient security. This would preclude the use of so-called layer 2.5 solutions from vendors such as AirFortress which pass encryption through generic APs. This type of solution is still vulnerable to the Trojan attack described in this paper. 3eTi firmly believes that the “security edge” should begin as close to the end user as is possible, at the AP, not further into the trusted network and only true layer 2 encryption provides adequate security for Sensitive But Unclassified (SBU) data. In terms of ensuring maximum interoperability between vendors, 3eTI supports the use of industry standards such as IEEE 802.11i, the newly ratified and improved WLAN security standard which supports strong Layer 2 AES based encryption. With the Wi-Fi Alliances WPA2 certification that uses 802.11i as the core, we foresee 802.11i being adopted across the Federal government. However, systems that employ cryptography MUST still be validated under FIPS 140-2 and in many cases must also be certified under the Common Criteria. Only those vendors focused on Federal Government requirements will meet these other rigorous security standards. The US Army has already mandated that Layer 2 security be used for Wireless Local Area Networks (see policy document 03-EC-M-0003). The US Air Force has deployed a WLAN system in a test lab using an older Layer 3 architecture called CITS I. Recently, the Air Force let an RFP for the CITS II Next Generation WLAN. The Air Force decided to still mandate Layer 3 VPN technology as a Threshold requirement in the latest RFP. Unfortunately, VPN technologies have many interoperability issues and a very complex to manage. It is interesting the Air Force is attempting to use a Remote Access Technology for Local Wireless Network Access. This approach will be more costly and complex than a Layer 2 approach. However, the Air Force has decided that 802.11i, a Layer 2 technology is an Objective requirement as well for WLANs, thus showing some recognition of the potential importance of Layer 2 security and the need for vendor interoperability. In order to meet the requirements of the US Army, 3eTI has developed the 3e-525A and 3e-527 Wireless Access Systems which support many Federal Government and Industry standards such as FIPS 140-2, 802.11i, TIC, DoD PKI and many other requirements. In addition, 3eTI also in the NIAP queue for Common Criteria Certification. As a Secure Wireless Product provider to the US Government, 3eTI also has many advanced features such as wireless Mesh Networking, built-in Video Servers for Secure Video surveillance, RFID technology and other infrastructure products which pass stringent Federal Government and Military requirements. Page 2 of 17 802.11 WLAN ARCHITECTURE – BEST PRACTICES INTRODUCTION This paper is intended to: (1) Define two major architectural approaches to WLAN Deployment – Distributed and Centralized (2) Compare and Contrast the two approaches (3) Discuss the Use of VPN Technology for Wireless Implementations (4) Describe the impact of the 802.11i WLAN Security Standard on existing deployments (5) Elaborate on the capabilities and features of equipment from 3eTI which adheres to industry standard Wi-Fi interoperability standards and meet Federal Government requirements such as FIPS 140-2 and Common Criteria. WLAN DEPLOYMENT ARCHITECTURES There are two major approaches today for deploying WLAN networks in the enterprise. Both approaches require Wireless 802.11 based Access Points (APs) and some method for managing these network elements. However, the two approaches have some basic philosophical differences which can have a major impact on deployment costs, security and manageability. The first architecture to be presented is the so-called “Centralized” WLAN Architecture. The Centralized Architecture requires one or more servers or special purpose switches to be deployed in conjunction with Wireless Access Points. In the Centralized approach, all wireless traffic is sent through the WLAN switch. The WLAN switch is often also a layer 3 VPN server which sets up end to end tunnels between the WLAN switch and the wireless client devices. Some vendors offer WLAN switches that provide layer 2 security instead of a layer 3 VPN. In either case, the centralized approach is considered to be an “Overlay” architecture. That is, it rides on top of the existing Ethernet network. Another approach is the “Distributed” Access Point WLAN Architecture. The Distributed Architecture adheres closely to the principles of the IEEE 802.11 standard. In the Distributed approach, APs have built-in WLAN security, layer 2 bridging, and access control features. Depending on the number of APs required, Centralized Management may be required. Distributed AP vendors may provide Centralized Management tools or the APs may be managed by the existing Network Management Infrastructure. The AP is connected directly to the trusted wired infrastructure and “extends” the wired network by providing wireless connections to wireless client devices. In most cases the WLAN security provided by the AP employs Layer 2 MAC level encryption as defined by the IEEE. Some vendors also provide APs which provide Layer 3 Wireless VPN connections as well. One of the advantages of the Distributed or Page 3 of 17 Wireless Extension approach is that the wireless traffic load is literally distributed across the APs and does not depend on a centralized element to process all of the wireless traffic. In the Centralized approach, loss of the WLAN Switch results in loss of the wireless network, whereas with the Distributed architecture, there is no single point of failure. From a performance point of view, the Distributed Architecture is superior from a performance/efficiency point of view. This is because the Centralized approach requires all wireless packets to be processed by the centralized WLAN Switch whereas in the Distributed Architecture, the packets are handled by the APs and only management traffic needs to go to and from a central point. Centralized Architectures tend to be difficult to scale because each WLAN switch can only handle a limited number of APs. Once multiple WLAN Switches are introduced, another entire layer of equipment needs to be managed. One of the goals of the Centralized Architecture was AP independence. However, in practice, most WLAN switch vendors offer their own APs with proprietary management protocols built in. From a manageability point of view, the Distributed Architecture offers several advantages over the Centralized approach. First of all, Distributed APs generally support standard management interfaces such as SNMP and therefore are manageable by legacy systems such as HP OpenView. Since the Distributed Architecture is an extension of the existing Wired LAN, it fits into the legacy network framework. The Centralized approach on the other hand introduces a whole new network element, the WLAN switch which then in turn manages wireless APs. The Centralized approach “overlays” a Wireless network on top of the existing Wired network, in effect creating two separate networks. In the Distributed approach wireless clients act as standard Ethernet wired clients and the operation of the wireless technology is often transparent for the end user and easy for the IT Administrator to manage. The Centralized approach on the other hand often requires more complex planning and configuration for the IT administrator in terms of permissions, access control, roaming etc. CENTRALIZED VERSUS DISTRIBUTED – A SECURITY PERSPECTIVE The two network diagrams below illustrate both architectural approaches from the perspective of where the “security edge” is. In any vulnerability analysis it is important to identify where the trusted and un-trusted parts of the network are. Traditionally, the wireless links have been thought of as “un-trusted” because of the invisibility of wireless and its reach. It is difficult to determine where the signal may leak and who may be eavesdropping on the signal or utilizing the signal for unauthorized access. In the Centralize approach, the security edge is at the WLAN switch. The APs often do not have strong encryption capabilities or authentication technology built in. This architecture is vulnerable to “rogue communications” between APs. Page 4 of 17 Authentication DHCP WLAN Management System Server Server Encrypted Communications Unencrypted 7x 8x 9x 10x 11x 12x 7x 8x 9x 10x 11x 12x Communications Ethernet Switch Ethernet C 7 8 9 101112 A 12 3456 1x 2x 3x 4x 5x 6x 1x 2x 3x 4x 5x 6x A B Rogue Communications Security Access Controller / Edge WLAN Switch Attack Ethernet Switch 7x 8x 9x 10x 11x 12x 7x 8x 9x 10x 11x 12x C Ethernet 7 8 9 101112 A 1 2 34 5 6 1x 2x 3x 4x 5x 6x 1x 2x 3x 4x 5x 6x A Attack B Attack Generic AP Generic AP Generic AP Generic AP Generic AP Attack Vendor Client Vendor Client SW SW Rogue Client Rogue Client Rogue Client FIGURE 1 – VULNERABILITY OF A CENTRALIZED APPROACH On the other hand, the Distributed or Extension Architecture pushes the security edge out the Access Points and extends layer 2 security to the Client devices. In this case, strong encryption occurs at both the Access Points and Client devices along with authentication. Attacks are much more difficult to launch because the security edge is closer to the users while rogue communications are prevented. Page 5 of 17 3e-030 Security Server / WLAN Management System Certificate Authority DHCP Server Dynamic Key Exchange (client-security server example) Encrypted Communications Unencrypted Communications Rogue Communications Ethernet Switch 7x 8x 9x 10x 11x 12x 7x 8x 9x 10x 11x 12x Ethernet C 7 8 9 101112 A 123456 1x 2x 3x 4x 5x 6x 1x 2x 3x 4x 5x 6x A B Security 3e-Wireless AP X3e-Wireless APX 3e-Wireless AP Edge 3e-010F 3e-010F Crypto Client Crypto Client Rogue Client Rogue Client FIGURE 2 – DISTRIBUTED APPROACH PUSHES SECURITY EDGE TOWARDS USERS CENTRALIZED VERSUS DISTRIBUTED – SECURITY CONCERNS Aside from the differences presented above with regard to the location of the “security edge” there are several other important security related differences between the Centralized and Distributed approaches to WLAN deployment. For network-based systems, the Open System Interconnection (OSI) 7-layer model is a standard reference, which defines a networking framework for implementing protocols in these layers that make up the networking “stack”. Using this context, one can envision the OSI layers and compare the security implementations typically found in both the Centralized and Distributed implementations of WLANs. A centralized approach will typically utilize Virtual Private Networking (VPN) technology with IPSec. IPSec provides an Encapsulating Security Payload (ESP), which is a protocol header inserted into an Internet Protocol (IP) datagram at the (layer 3) network layer. IPSec is intended to provide confidentiality, data origin authentication, anti-replay, and data integrity services to IP frames. Virtual Private Networks (VPNs) typically rely on IPSec for implementing secure tunnels. The drawback to this approach is that for wireless systems, the datalink Page 6 of 17 (layer-2) and physical (layer 1) frames are completely unprotected using IPSec alone. Spoofing and replay attacks on the MAC (Media Access Control) and physical layer packets are possible. With IPSec, the contents of the Layer-2 802.11 MAC header are transmitted in the clear. These “wireless packet headers” are effectively unprotected, allowing an intruder or rogue device to intercept and freely decode the following information that is unprotected by IPSec in the 802.11 MAC headers: (1) Frame Control Contents (2) Duration / ID Material (3) Destination & Source Addresses (4) Sequence Control Information FIGURE 3 – OSI MODEL AND HEADER FORMATS Distributed Architecture implementations typically utilize layer 2 security based on IEEE 802.11 standards. Strong FIPS 140-2 validated Layer 2 AES encryption protects critical portions of the MAC header, while IPSec and VPNs do nothing to protect these MAC headers that encapsulate the 802.11 “wireless packets”. This point is illustrated above in FIGURE 3. Furthermore, layer 3 implementations are vulnerable to “Trojan” software attacks. For example, if a client device gets “infected” with a Trojan software program, the user will most likely be unaware of this and data can be transferred into and out of the device without the knowledge of the user opening the door for several types of attacks and loss of sensitive data. This scenario is illustrated below in FIGURE 4. Page 7 of 17 TCP/IP TCP/IP Trojan App. TCP/IP VPN shim VPN Shim Trojan TCP/IP NDIS driver NDIS driver NDIS driver Stolen WLAN card Unencrypted WLAN card WLAN card Packets Standard Windows Windows Networking Windows Networking Stack with Stack Stack with a VPN a VPN and a Trojan Application FIGURE 4 – STANDARD IMPLEMENTATION OF VPN AND TROJAN ATTACK PRINCIPLE In the above scenario, a standard layer 3 VPN Shim configuration found in a client device is compromised by a Trojan TCP/IP stack and an associated malicious application. Once the WLAN hacker establishes connections to the Trojan, the Ethernet Switch will forward no more traffic to the VPN server. There will effectively be a virtual connection between the WLAN client and the WLAN hacker that is very difficult to detect. In fact, most IDS/firewall tools that can be run on the user's PC will not see this traffic. The WLAN hacker now has complete remote control of a system that is properly authenticated via the VPN into a corporate network. Security at Layer 2 while providing Strong Encryption can also remediate the situation illustrated above. As shown in FIGURE 5, a layer 2 solution encrypts all packets which wirelessly enter or leave the device at the Driver Level. This prevents ANY unencrypted data from being sent out the wireless interface. As can be seen in FIGURE 5, the malicious Trojan application with the intention of stealing information is thwarted. Trojan App. TCP/IP Trojan TCP/IP Clear Text NDIS crypto- NDIS Driver performs driver Layer 2 Encryption WLAN card And data cannot be Transmitted in the Clear, even if a Trojan Windows Networking Stack with Is inserted – Trojan Cannot steal information a 3eTI Layer 2crypto Client and a Trojan FIGURE 5 – LAYER TWO STILL PROTECTS DATA FROM A TROJAN ATTACK Page 8 of 17 The 3e Technologies Crypto Client encrypts all packets at layer 2 so even if a Trojan TCP/IP stack and Rogue Application is inserted it will be unable to send unencrypted packets in the clear, thus defeating the intention of the Trojan application. The choice of layer 2 or layer 3 security is actually independent of the choice of WLAN Architecture. In fact, there are distributed APs with built in VPNs and WLAN switches which have layer 2 security. We have already explored the superiority of security at layer 2. Let’s take a deeper look at WLAN Switches which implement “layer 2” security. Strictly speaking, in order to have true layer security, the encryption must be done at the Driver level and there should not be a way to bypass this encryption as there is with a layer 3 VPN solution illustrated above. If one looks closely at so-called Access Point “independent” solutions offering layer 2 encryption, they will find that in actuality although the encryption is implemented in driver, it is actually at a higher layer which for the sake of discussion we will call “layer 2.5”. FIGURE 6 below illustrates this. MicroSoft Trojan Aplication TCP/IP Driver TCP UDP IP Routing Trojan TCP/IP Stack NDIS API Used by Protocols Competitor NDIS Trojan NDIS NDIS API Intermediate Intermediate Security Solution 3eTI NDIS Miniport Driver cannot be NDISWRAPPER bypassed 3eTI NDIS Miniport Competitor NDIS Off-the-Shelf NDIS AES/3DES Intermediate Miniport Encryption Security Solution can be bypassed NIC NIC FIGURE 6 – FLAW WITH “PASS THROUGH” NON-AP BASED LAYER TWO SOLUTIONS Page 9 of 17 As can be seen above, even though the security solution is “layer 2”, encryption can be bypassed using techniques similar to the Trojan VPN attack. The 3eTI layer 2 solution which follows the IEEE principles, replaces the NDIS driver completely and thus cannot be bypassed as shown above. Therefore, in WLAN security architecture and design, one should be wary of “Non-AP” based Layer 2 security solutions for the aforementioned reasons. With advent of the 802.11i security standard, the IEEE has fully endorsed layer 2 security with 802.11i. As can be seen, the US Government Departments and Agencies are rapidly embracing this standard with the caveat that it must be FIPS 140-2 Validated. VPN TECHNOLOGY – FIT FOR WIRELESS? A typical implementation of a wireless network is shown below in FIGURE 7: Link Encryption Key Layer 3 Unencrypt Layer 3 Network Router Firewall Internet Remote VPN WLAN Switch Server AP VPN Client VPN Client AP AP VPN Client VPN Client VPN Client VoWLAN Phone w/VPN FIGURE 7 – A LAYER 3 CENTRALIZED WLAN SWITCH ARCHITECTURE WITH VPN SERVER OUTSIDE OF THE FIREWALL (NOT RECOMMENDED) Page 10 of 17 VPN technology in the above case is used as a Remote Access method for both wired and wireless clients as well as a LOCAL Access solution. Utilizing Layer 3 VPN technology for a local access solution is not the optimal approach for a number of reasons: (1) Scalability (2) Manageability (3) Solution Overhead (4) Vulnerability to Trojan Attacks (5) VPN outside of Firewall A better approach is to use Layer 2 Security for Local Access and VPN Technology for Remote Access. Link Encryption Key Layer 3 Unencrypt Layer 2 Layer 3 Network Router Firewall Internet Generic Remote LAN VPN Switch Server AP Layer 3 Protection for Remote VPN Client Access VPN Client AP AP Superior Layer 2 Protection for Base, Post/Fort and Camp 802.11i 802.11i 802.11i VoWLAN Phone Client Client Client 802.11i Client w/FIPS w/FIPS w/FIPS w/FIPS 140-2 140-2 140-2 140-2 FIGURE 8 – A DISTRIBUTED WLAN ARCHITECTURE UTILIZING LAYER 2 Page 11 of 17 SECURITY FOR ON BASE AND LAYER 3 FOR REMOTE ACCESS (BETTER APPROACH) With the centralized approach, loss of a WLAN switch leaves several APs unable to communicate and a major loss of RF coverage. The distributed approach illustrated above has several advantages over the centralized approach including performance efficiency (no central bottleneck), better on base security (immunity to Trojan attack), better interoperability with 802.11i and easier to maintain and scale than a VPN based LAN solution. In the distributed approach the loss of a secure AP due to malfunction only results in a small loss of RF coverage, but no loss in overall security. Government Security requirements specify FIPS 140-2 for security, but do not explicitly define the type of technology or specific layer where the encryption resides. The US Army has published a document 03-EC-M-0003: Issuance date: 22 June 04 this specifically spells out the layer 2 security requirement for WLAN deployment – Section C: “Wireless solutions must protect layer two (link layer OSI model) with an approved FIPS 140-2 level 1 encryption module. Vendors must demonstrate movement to FIPS 140-2, Level 2 certification for continued use” In terms of remote users or “Road Warriors”, the Army further elaborates on the requirements in section D which are at Layer 3: “D. Standards for mobile wireless computing “Road Warrior” (1) Mobile devices must have a VPN client configured to establish a secure tunnel. Reason: Layer 2 cannot be protected with current technology unless we own the network. VPN’s operate at layer 3, helping to mitigate, but not eliminate, layer 2 risks. VPNs must meet encryption certification requirements, i.e., FIPS 140-2 level 1. Vendors must demonstrate movement to FIPS 140-2 level 2, before authorization to use. (2) Mobile devices must have an EAL 4 + approved firewall configured to only allow authorized communications. Firewall must operate at the Network Driver Interface Specification (NDIS) Layer using stateful packet inspection.” The US Air Force has deployed WLANs using the CITs I Architecture. This Architecture has proven to be too expensive and problematic and recently the Air Force has put out a proposal for the CITS II program. Unfortunately, although the Air Force has asked for improvements over the CITS I Architecture, they have essentially asked for a similar Architecture in CITS II. 3eTI has had several meetings with the Air Force and has explained some of the issues with CITS I – specifically the complexity of managing a VPN for daily on Base use, inherent performance issues with VPN technology, cost of VPN technology, the placement of a VPN Server outside a Firewall as a security risk, the inherent Security risks of Layer 3 solutions and the fact that VPNs are really intended for Remote Access not daily access not for local LAN users. Furthermore, the Air Force Requirements ask for layer 2 802.11i technology to protect the wireless links AND layer 3 VPNs. These requirements are somewhat contradictory at worst and redundant at best. Page 12 of 17 In addition, the Air Force requirements for CITS II specify several outdated products such as CiscoWorks which is at “End of Life” status. In order to help the Air Force meet its Software Requirements for CITS II, 3eTI is proposing a solution which utilizes both Layer 2 and Layer 3 technology plus DoD PKI compliant authentication. 3eTI strongly believes that solely using layer 3 technology for on base operation is not a good choice for wireless security. First of all, RF signals are “invisible” and can leak outside the base perimeter. Hackers and other criminals and passively monitor stray RF transmissions and can also send signals into areas where the WLAN receivers will pick up the signals. Daily patterns of military personnel can be monitored – who goes into the base, when the log in etc. Because of this situation, Layer 2 security such as 802.11i or some other layer 2 driver encryption scheme is highly recommended as a primary requirement. The 802.11i security must also be FIPS 140-2 validated. 802.11i is the best choice in terms of guaranteeing interoperability between vendors. The 3eTI proposed solution for CITS II is shown below in FIGURE 9: Page 13 of 17 Link Encryption Key Layer 2 Unencrypt Layer 3 Layer 3 Network Router Internet Remote VPN Server VPN Server 3eTI 3eTI 3eTI Secure Secure Secure Enterpri AP AP 3eTI AP 3eTI 3eTI 3eTI 3eTI VoWLAN CryptoClient CryptoClient CryptoClient CryptoClient CryptoClient Phone w/VPN w/VPN w/VPN w/VPN and w/VPN w/VPN CryptoClient FIGURE 9 – HYBRID SOLUTION PROPOSED FOR US AIR FORCE CITS II PROGRAM With the above architecture, both layer 2 and layer 3 security runs simultaneously. The 3eTI equipment provides 802.11i layer 2 protection. This Architecture meets the CITS II specification. Running a VPN on top of WiFi adds overhead to network and tasks for administrator and user, however, an IPSEC VPN is required by the Air Force. One option in the future is once 802.11i Access Points with FIPS 140-2 validation are in the network, layer 3 security will be turned off behind the firewall since the VPN will be redundant for local wireless security. The VPN will still be used for point-to-point over internet, not security over WiFi. 3eti is teaming with layer 3 companies to provide a combined security solution (VPN over secure WiFi) where customers such as the Air Force require this. The above architecture solves the Page 14 of 17 problem of the VPN server location. A VPN server can be place outside the firewall for remote users, however, the daily on based wireless infrastructure will reside completely within the firewall with a separate VPN server infrastructure. UNDERSTANDING WI-FI CERTIFICATION AND FIPS 140-2 VALIDATION – A QUESTION OF INTEROPERABILITY From the Wi-Fi website (www.weca.net): “Wi-Fi Certification comes from the Wi-Fi Alliance, a nonprofit international trade organization that tests 802.11-based wireless equipment to make sure it meets the Wi-Fi standard and works with all other manufacturers' Wi-Fi equipment. Thanks to the Wi-Fi Alliance, you don't have to read the fine print or study technical journals: if it says Wi-Fi, it will work.” To achieve the goal of interoperability, Wi-Fi certification, and FIPS 140-2 validation, certain technological tradeoffs must be made. Layer 2 AES encryption protects the “wireless” packets at the MAC sublayer. Wi-Fi also provides a mechanism to achieve Layer 2 encryption, called Wi-Fi Protected Access (WPA). Again, it should be emphasized that the main goal of the Wi-Fi alliance, which is networking interoperability, has been achieved; however, Wi-Fi is not the guiding authority or de facto standard when wireless security is at stake, and Wi-Fi cannot replace FIPS 140-2 or the Common Criteria in specifying security requirements for the DoD, including the U.S. Navy. It should also be noted that Wi-Fi certification of FIPS 140-2 validated equipment is certainly achievable in a non-(FIPS 140-2) mode, in order to achieve interoperability with other Wi-Fi certified equipment and vendors. However, it is important to note that this arrangement can not currently achieve DoD-mandated accreditation at Layer 2 due to Wi-Fi’s employment of RC4 encryption. Currently, the Wi-Fi Alliance offers WPA2 certification which uses 802.11i as the built- in security standard, thus ensuring that next generation WLAN products will interoperate with the option of using strong AES encryption at layer 2. However, individual vendors will STILL have to go through the rigorous FIPS 140-2 Validation process. Getting 802.11i/WPA2 certification is NOT equal to getting FIPS 140-2 Validated. The impact of the new 802.11i ratified IEEE standard and WPA2 will be enormous. The military has recognized this and has deemed 802.11i as an important standard going forward. Vendors such as 3eTI who specialize in wireless security are well positioned to utilize the new standard and take products through the FIPS 140-2 validation. This will entail the use of special modes to ensure that the non-FIPS approvable modes of 802.11i are not used in while operating in FIPS 140-2 mode, along with many other security related modifications. The FIPS 140-2 certification process is itself a rigorous ordeal that ensures all hardware and software within a “cryptographic boundary” is correct-by-construction and Page 15 of 17 cryptographically sound. FIPS 140-2 certification requires a comprehensive design and verification process, to satisfy eleven chapters of FIPS derived test requirements (DTRs). These DTRs focus on the cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; the detailed finite state model; physical security; operational environment; cryptographic key management; EMI/EMC requirements; power-up and conditional self-tests; design assurance; and mitigation of possible attacks. The FIPS 140-2 certification process involves proof-of-design and proof-of-cryptographic-soundness with one of nine worldwide NIST-approved independent NVLAP (National Voluntary Laboratory Accreditation Program) cryptographic module testing facilities. Once the cryptographic module design and documentation has been demonstrated to the NVLAP testing facility, NIST performs a final review of the NVLAP findings. 3eTI has a lot of experience designing , building and successfully bringing secure wireless products through this process. WI-FI CERTIFICATION OF 3eTI WIRELESS PRODUCTS In order to be interoperable with a large market share of industry-standard wireless equipment which are based on the Intersil and Atheros chipsets and drivers, 3e supports a non-FIPS mode which is fully Wi-Fi compliant. Today, 3e equipment is compatible with Intersil Prism 2.5 and higher (Linux and Windows drivers) Atheros (Linux and Windows drivers), and Centrino (Linux driver). 3eTI plans are to work with as many cards as possible on the market. The primary difference in the 3e solution and others is that we replace the active NDIS driver from the manufacturer with our 3e driver (Crypto) NDIS. While this does require us to build drivers for each chipset type, it also offers a greater level of layer 2 encryption over other solutions which only really achieve layer 2.5 of the OSI model without directly building a NDIS driver. The Prism2.5 and Prism3 chipsets are evolution of the PrismII chipset, offering even higher integration, lower cost and backward compatibility. With respect to the driver, these 3 chipset look the same, and therefore the 3e driver supporting PrismII hardware will also support Prism2.5 and Prism3 hardware. In order to meet FIPS 140-2 validation requirements AES, 3DES, or Skipjack data encryption is required. Of these three, AES is specified by NIST FIPS-197 and is the only encryption algorithm that will be compatible with the near-final 802.11i standard. If interoperability is a higher priority than pure security, 3e equipment can be placed in non- FIPS mode for Wi-Fi interoperable operation. Page 16 of 17 . 3eTI Leads Competition in Meeting DISA/DOD Wireless Requirements o Common Criteria - 3eTI meets the NSA Sponsored Protection Profile for WLAN Access System o FIPS 140-2 o JITC DoD PKI Certification o Wireless LAN Technical Guidance (SPAWAR) o Wireless DISA Security Technical Information Guide (STIG) o DoD Directive 8100.2 Use of Commercial Wireless Devices, Services, and Technologies in the DoD Global Information Grid (GIG) o NIST 800-60 Special Publication Volume I: Guide for Mapping Types of Information Systems to Security Categories; Volume II: Appendices to Guide for Mapping Types of Information and Information Systems to Security Categories o NIST FIPS 199 Standards for Security Categorization of Federal Information and Information Systems o DoD JIEO Report 8307 Guide to Selecting Computer-Based Multimedia Standards, Technologies, Products and Practices o DoD 8510.1-M DITSCAP Department of Defense Information Technology Security Certification and Accreditation Process o Common criteria EAL 2+ (In-Process) o PMW (Program Management Warfare) 165 Afloat Engineering SPAWAR C4I Afloat Wireless Guidance o US Army NETCOM 9th Army Signal Corps Information Assurance Testing and Validation o US Army Test & Integration Center (TIC) Testing o NIST SP 800-48 Wireless Security Guidance Document o NIST FIPS 140-2 Cryptographic Module Certification Program o MIL-STD-901D (Grade A & B Shock Mounts) Shock Validation o MIL-STD-461E EMI Emissions and Susceptibility o MIL-STD-167 Vibration o MIL-STD-810F Humidity o DD1494 – Circulation of Frequency and attenuation usage to Host Nations o SEA/53H – HERO, HERP, HERF Validation o FCC Part 15, Subpart B o 802.11i /WPA2 Page 17 of 17
"802.11 WLAN A"