Design, Implementation, and Performance Analysis of DiscoSec — Service Pack for Securing WLANs

Please download to get full document.

View again

All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
  To improve the already tarnished reputation of WLAN security, the new IEEE 802.11i security standard provides means for an enhanced user authentication and strong data confidentiality. However, the standard focuses on securing higher-layer data,
  Design, Implementation, and Performance Analysis of DiscoSec –Service Pack for Securing WLANs Ivan Martinovic, Paul Pichota, Matthias Wilhelm,Frank A. Zdarsky, and Jens B. Schmittdisco | Distributed Computer Systems LabUniversity of Kaiserslautern, Germany{martinovic, p_pichot, m_wilhel, zdarsky, jschmitt} Abstract To improve the already tarnished reputation of WLAN security, the new IEEE 802.11i security standard providesmeans for an enhanceduser authenticationand strong dataconfidentiality. However, the standard focuses on secur-ing higher-layer data, i.e., protecting IEEE 802.11 data frames. Management frames used for connection admin-istration are left unprotected and a wide spectrum of knownattacks is still applicable and even extended against the IEEE 802.11i/IEEE 802.1X protocol execution.This workdescribesDiscoSec,aservice packfor“patch-ing” WLANs against the most prominent vulnerabilities re-sulting in resource-depletion and impersonation attacks. DiscoSec provides DoS-resilient key exchange, an efficient  frame authentication, and a performance-oriented imple-mentation. By means of extensive real-world measure-ments the performance of DiscoSec is evaluated showingthat even on very resource-limited devices the throughput isdecreasedby only22% comparedto the throughputwithout anyauthentication,andby 6% on more powerfulhardware.Todemonstrateits effectiveness,DiscoSecis availableasanopen-source WLAN device driver. 1. Introduction The various confidentiality and integrity vulnerabilitiesof Wired Equivalent Privacy (WEP) and the simplicityof mounting impersonation attacks by manipulating thesender’s MAC address caused the bad reputation of IEEE802.11 security. To regain back trust in this widespreadtechnology the IEEE Task Group  i  successfully finalizedthe new security standard  802.11i  [1]. The new standardprovides a security framework composed of several knownand approved protocols to ensure robust protection of wire-less communication. An enhanced user authentication, anew underlying cipher, and a reliable integrity verificationfinally enabled the protection of data equivalent to the secu-rity in wired networks.However, IEEE 802.11i focuses only on securing theuser’s data, i.e., it providessecurityfor the  dataframes  usedto transport higher layer protocol data, leaving the  manage-mentframes usedforchannelandconnectionadministrationwithout any protection. The reason seems to be twofold.First, the tragic end of WEP left wireless clients withoutstandardized protection giving rise to dispersion of propri-etary solutions, hence the interoperability certification pro-gram(e.g., Wi-Fi ProtectedAccess (WPA)) was impatientlyawaited by both the industry and the users. Secondly, at-tacks on management frames impact the  availability  of theIEEE 802.11 network, which especially in wireless net-works is the most vulnerable among all security goals. Dueto the frequency jamming vulnerability being an indige-nous property of wireless communication, the importanceof providing availability protection at the link-layer is oftendowngraded. Nevertheless, there is a significant differencebetween physical layer attacks aiming at the channel capac-ity, thus denying any  communication,and link-layerattacksaffecting the  services  provided by an access point and theconnection states of wireless stations.Inits infrastructuremodeanaccess point(AP)is control-ling the wireless channel and providing authentication andassociation procedures to wireless clients. Its flawless op-eration, availability to manage client associations, and theadministration of the wireless traffic have a direct impacton the users’ security. For example, the execution of theIEEE 802.11i security standard is only possible if a wire-less client reaches the final  authenticated and associated  connection state. State transitions within the IEEE 802.11state machine are achieved by management frames, and bymanipulating them even the sophisticated protection givenby IEEE 802.11i is easily obviated.Furthermore, the typical Man-In-The-Middle (MITM)978-1-4244-2100-8/08/$25.00 c  2008 IEEE  attacks in wireless networks are based on abusing unau-thenticated management frames. After installing a rogueAP with a stronger signal, an adversary can simply changeits MAC address to any of the already associated clients (orAP) and, by sending an impersonated deauthentication ordisassociation frame, it can reset a wireless client to its ini-tial state (for more details on such attacks see [3]). Conse-quently, a wireless client is not able to transmit any dataframes and must re-initiate the network discovery proce-dure which in most implementations chooses the AP withthe strongest signal, hence associating with the rogue AP.Although well known, these attacks are still applicable andvarious tools are available to facilitate their execution (e.g.,[8] demonstrates wireless phishing attacks within publichotspot scenarios).To sustain the fast deployment of IEEE 802.11 technol-ogy there is a need for protection against such low-cost, yetvery effective attacks. In this work, we describe and evalu-ate DiscoSec, a solution against the most prominent vulner-abilities within present WLANs. A similar goal was alsoset within the IEEE 802.11 Task Group  w  which is still inproposal stages, and therefore, we implement the conceptof DiscoSec as an open-source IEEE 802.11 device driverto serve as a benchmark and prototype for future develop-ments. 1 The rest of the paper is structured as follows. In Section2, we discuss various security objectives influencingthe de-sign of DiscoSec. The key exchange and implementation-related decisions are presented in Section 3, while Section4 illustrates the impact of resource-depletionattacks and in-troduces a protection to mitigate them. In Section 5, weevaluate DiscoSec using three different hardware platformsand conduct real-world measurements to analyze the keyexchange, the frame authentication, and the impact of Dis-coSec on overall network throughput. Various design andimplementation decisions were based on measurements us-ing modern equipment, hence this work describes not onlythe final results but also differentlessons learned during ourresearch. 2. Design Goals of DiscoSec In contrast to wired networks where end-devices havecomparable hardware capabilities and executing expensivecomputations does not present a performance problem, in-troducing cryptography-based protection in wireless net-works opens various performance-related issues. Espe-cially critical are protections using stateful protocol exe-cution and complex message exchanges, which by abusingthe broadcast nature of wireless communication, often re-sult in new resource-depletion attacks. Such examples can 1 DiscoSec’s source code for using it as a wireless device driver is avail-able at  also be found in IEEE 802.11i where a resource demandingprotocol and an unauthenticated exchange of key materialare prone to various protocol-blockingattacks (e.g., [5, 6]).To mitigate such attacks and to allow interoperability be-tween stations not supporting DiscoSec, we identified thethree most important requirements on which the solutionshould be based:1.  Simple and lightweight authentication protocol 2.  DoS resilient protocol execution 3.  No alterations to the current IEEE 802.11 state ma-chineSimple and lightweight   authentication is necessary for sev-eral reasons. Simplicity is a property affecting not onlyprotocol design but also its implementation. In wirelesscommunication where no assumption on a reliable channelshould be made, protocols consisting of many round-trips(e.g., many message exchanges) often create deadlock vul-nerabilities. The simplicity of authentication also assists usin reusing well-established cryptographic primitives avail-able within the standard Linux (kernel) Crypto API andthe OpenSSL library, thereby minimizing the potential forfaulty implementation.The  lightweight   property of an authentication protocolfocuses on the key exchange phase where public key cryp-tography is used. To avoid many message round-trips weabandon the negotiation of security properties and ratherutilize an anonymous Diffie-Hellman (DH) key exchange.The idea behind this decision is to shift the key exchangephase to the very beginning of the communication so thatno resource reservation is made before the key exchange isfinalized. At this stage no user identities are knownbut onlytheir link-layer addresses, and therefore DiscoSec  binds  thesender’s and receiver’s link-layer address for the remain-der of the session. Being protected from frame injection,devices can utilize identity authentication within the laterstages of communication relying upon more heavy-weightprotocols. As a result, the key exchange is executed withinonly  one round-trip  (i.e. two messages) whilst supportingthe second important design property — DoS resilient pro-tocol execution.  DoS resilience  of DiscoSec concerns both computation-and memory-depletion attacks. The key exchange is themost vulnerable part of the authentication protocol and itsarbitrary initiation should be avoided. For this reason weimplement a rate limitation of key exchangerequests whichtakes advantage of broadcast communication to providefairness in the association process. The DoS protection isprovided as a configuration parameter and its dimensioningcan be adapted to comply with performance characteristicsof the dedicated AP.  Management Frames Data FramesState 1  Beacon, Probe Req. /Resp.,Traffic Indication Message, Authentication Req./Resp.,Deauthentication. None(infrastructure BSS) State 2  Association Req./Resp.,Reassociation Req./Resp.,Deauthentication. None State 3  DeauthenticationDisassociationAll frames Table 1. IEEE 802.11 frame types and con-nection states within they are allowed to betransmitted. Bold frames are authenticatedby DiscoSec. TosupportlegacyandDiscoSecprotectedstationswithinthe same basic service set (BSS), we design and implementDiscoSec  without changing the current IEEE 802.11 statemachine . All required information is embedded within theexisting frames as  Information Elements  (IEs), i.e., the key-value data structure reserved by the IEEE 802.11 standardfor transmission of custom data. The authentication data isthereforeonlyprocessedif DiscoSec is implemented,other-wise it is simply discarded by the legacy driver. The framestructure remains unchanged, and a DiscoSec enhanced APhas no impact on the association procedure for legacy sta-tions.Variousotherpropertiesidentifiedasperformancevs. se-curity tradeoffs are offered as configuration parameters of DiscoSec’s implementation and can be adapted to the net-work requirements. 2.1. Contribution The security goals which DiscoSec fulfills are the  au-thentication  and  integrity  of management and (optionally)data frames exchanged between a wireless station and anAP. This eliminates the most prominent attacks based oninjecting fake or impersonated frames, such as Deauthenti-cation and Disassociation attacks.Table 1 provides an overview of all management anddata frames used within the three connection states of wire-less clients (DiscoSec authenticated frames are depictedas bold). Using DiscoSec, both station and AP hold ashared secret before entering the second connection state,which demands reservation of the AP’s memory resources.Both participants are able to prove that all subsequent uni-cast frames are sent from the devices that participated inthe network association procedure. Furthermore, due toits high performance DiscoSec offers authentication of all dataframes  transmittedduringthe session and thus protects kernelcryptonetInter-Process Communicationwirelessdevice driver KEdaemonCMACOpenSSL   u  s  e  r  s  p  a  c  e   k  e  r  n  e   l  s  p  a  c  e Figure 1. Architecture of DiscoSec the execution of more heavy-weight protocols transmittedwithin them.As a proof of concept DiscoSec is available as a WLANdevice driver for all Atheros-based chip-sets, using Linuxkernel (ver. 2.6.14+), and OpenSSL (ver. 0.9.8+). 3. DiscoSec’s Design and Implementation The design of DiscoSec followed the requirements dis-cussed in the previous section. The cryptographic prim-itives used as building blocks for implementation of Dis-coSec were chosen based on their performance properties.Decisions such as the choice of the underlying cipher, theuse of a block cipher-based message authentication code(CMAC) and elliptic curve cryptography(ECC) for the keyexchange were based on extensive measurements on dedi-cated APs (a more detailed discussion is given in Section5). 3.1. Architecture of DiscoSec ThearchitectureofDiscoSecis depictedinFigure1. Thefunctionalityis split into modules and logically dividedintothree functional units:  (i)  the wireless LAN device driverthat controls the WLAN hardware and contains the 802.11network stack   , (ii)  the Key Exchange (KE) daemon whichprovides public key cryptography features utilizing primi-tives offered by the OpenSSL library. It processes the keyexchange requests issued by the wireless device driver viaInter-Process Communication, and  (iii)  the CMAC kernelmodule which provides functions for calculating MessageAuthentication Codes (MACs) using the kernel’s standardCrypto API.The calculation of the MACs is a time-critical opera-tion and is thus implemented in  kernel space . Contraryto CMAC, the Key Exchange daemon runs in  user space   AP  Link-layer address of access point STA  Link-layer address of wireless station  EC  Param  Elliptic curve parameters PK   AP  Access Point’s public-key PK  STA  Station’s public-key  MK   Master key computed from ECDH SK   Session key used for authentication  MAC  SK  ( m )  Message Authentication Code  AT   Association Token Table 2. Notation used. with a lower priority. In case of a high CPU load, the KeyExchange daemon is scheduled less often, so the alreadyassociated stations are not influenced by expensive compu-tations and their data throughput remains stable as shownlater in the performance section of this work. 3.2. Terminology and Cryptographic Prim-itives Used Table 2 shows the notation used in DiscoSec’s frame au-thentication. All exchangedvariables are defined as customInformation Elements appended to existing IEEE 802.11frames.The key exchange utilizes Elliptic Curve Diffie-Hellman(ECDH) as it enjoys the advantage of much smaller keysizes comparedto Diffie-Hellman based on the discrete log-arithmproblem. Thepublickeys PK   AP  and PK  STA  are avail-able in 128 bit length (expandable to 256 bit).  EC  Param  de-fines an elliptic curve over a finite field supported by theOpenSSL library and changeable through DiscoSec’s con-figuration parameters.The shared secret  MK   is computed from the ECDH keyexchangeusing  PK   AP ,  PK  STA  andthe station’s and AP’s pri-vate keys. It serves as a  master key  to derive key materialfor authentication.The association token  AT   is used as a  nonce  for com-puting a fresh session key  SK   for frame authentication, andadditionallyfor providingDoS protectionto controlthe rateof association requests (more informationon tokens and theDoS protection is given in Subsection 4.1).The  MAC  SK   is a cipher-based message authenticationcode utilizing AES. We selected AES as the underlying ci-pher due to its inclusion in the IEEE 802.11i standard andits good performance characteristics. It is provided withintheLinuxCryptoAPI (ver. 2.4+). Animplementationof se-cure CMAC based on AES for authentication of messageswith variable length was not available during the develop-ment of DiscoSec. Therefore, we implemented RFC 4493[14], which defines AES-CMAC and serves as a NIST rec-ommendation for CMAC message authentication using theAES block cipher [12]. 3.3. Association Procedure - Key Deriva-tion We omit the detailed description of a public/private keyinitiation and the ECDH shared secret computation. Bothmethods are standardized and their implementations aregiven by OpenSSL ver. 0.9.8+ [7, 13]. In the followingwe describe DiscoSec’s specific parameter exchange andthe derivation of an authentication key.Thekeyexchangeis accomplishedwithinasingleround-trip:AP → STA : { PK   AP ,  EC  Param ,  AT  }AP ← STA : { PK  STA ,  AT  }During start-up the AP initializes its key pair based on theelliptic curve parameters  EC  Param  (the AP’s key pair canalso be precomputed and loaded during start-up). The re-sulting  PK   AP  and  EC  Param  are sent to the stations via pe-riodically emitted Beacon frames or a triggered Probe Re-sponse frame dependingon either active or passive network discovery.The wireless station extracts the supplied values, gener-ates its key pair based on  EC  Param , and computes the masterkey  MK   using the  ECDH   method. The session key  SK   iscreated by applying the cryptographic hash function  SHA-256   on the  MK   and a previously received association token  AT  . The 128 least-significant bits of the hash are selectedto provide the authentication key.The reason for deriving the authentication key from themasterkeyis tosupportthe key-caching techniquesimilartothe IEEE 802.11i standard. If the same wireless station de-cides to associate with the same AP and uses the static keypair, the computationally expensive  ECDH   key exchangecan be omitted. The fresh  SK   is then derived by applying asingle hash computation on the new association token andthe cached  MK  .The  PK  STA  and the  AT   are returned within the Authenti-cation Request to the AP, which computes the  MK   and  SK  analogously to the station side. This finalizes the key ex-change and both participants use their session key  SK   as thesecret key for the AES frame authentication (  MAC  SK  ( m ) ).This is also the most critical part of the association pro-cedure. While the AP’s key pair can be calculated offlineandloadedduringstart-up,thesessionkeyderivationis trig-geredby an AuthenticationRequest andits computationde-pends on PK  STA  and  AT  . This opensa new vulnerabilitybe-cause the Authentication Request can easily be faked, andvalidation is only possible after the AP has derived  MK   byperforming complex modular computations. If Authentica-tion Request frames are received faster than the AP’s trans-mission queue is processed, the AP can suffer from highframe loss and various operational anomalies. To prevent  MAC Header 2 2 6 6 6 2 6 0...2308 4Duration Address 1 Address 2 Address 3Seq.Control Address 4 FCSFrameControlFrameBodyfastauthfastauth SEQ 4fullauthfastauth Frame Control [bits]: Type FromDSToDSSubtypeProtocolVersion WEPMoreData Order RetryMoreFrag 2 2 4 1 1 1 1 1 1 1 1full/fastauthfull/fastauth IEEE 802.11 Generic Frame Format [bytes]: Pwr.Mgmt Figure 2. Authentication Modes: authenticated frame fields in  full _ auth  and  fast  _ auth  modes. this kind of resource-depletion attack, DiscoSec provides acountermeasure based on an association rate control whichis described in Section 4. 3.4. Frame Authentication - Variable vs.Fixed Frame Length The challenge of frame authentication lies in its per-formance. While the low number of transmitted manage-ment frames only marginally increases computational load,the authentication of every data frame significantly stressesperformance-limited APs. Consequently, data frame au-thentication directly impacts the throughput of the wirelessconnection.Forefficientframeauthenticationthemostinfluentialpa-rameter is the frame’s  size . The Maximum TransmissionUnit (MTU) of expected 1500 bytes is overrun in IEEE802.11 networks and currently, frames up to 3000 byte aretransmitted over the wireless channel. The reason lies inthe proprietaryfeatures of various WLAN cards whose pur-pose is to increase throughput by frame aggregation. Forexample the  SuperG  [2] extensions of Atheros utilize theso-called  FastFrame  and  Bursting  techniques. FastFrameexploits the wireless channel more efficiently by increas-ing the amount of data contained within a single frame, i.e.,it minimizes the frame overhead, while Bursting increasesa throughput by sending multiple frames within a singletransmission opportunity. Although not standardized, thesepropertiesarecommontovariousIEEE802.11vendors(un-der different names such as  108G Technology ,  Xtreme G , Plus ) and their standardization should be finalized withinthe  802.11n  standard.The authentication of such frames can often present acomputational burden for performance-limited APs. To beable to support these extensions DiscoSec provides twomodes of authentication - the  full _ auth  mode for APswithsufficientcomputationalcapabilitiesandthe  fast  _ auth mode for APs where full authenticationof frames would re-sultina newperformancebottleneck. Bothmodesarebasedon CMAC-AES authentication.The  full_auth  mode supports authentication of frameswith variable lengths, while the  fast  _ auth  mode limits thedata included in the MAC to a fixed amount of 128 bits(both modes and authenticated frame fields are depicted inFigure 2). In the  fast  _ auth  mode only certain header fieldsare authenticated and the frame’s payload is omitted fromcomputation. The authenticated fraction of the  fast  _ auth mode matches the block size of the AES cipher and can beauthenticated within a single AES block computation (the  AT   of 4 byte is included into the calculation, although notdepicted in the figure). Accordingly, the authentication ismore lightweight and may be performed much faster, for aquantitative comparison see Section 5. On the other side,this presents a tradeoff between security and performance,i.e., a complete authenticationvs. higherthroughput. Whilein our opinion a meaningful on-the-fly manipulation of thesingle bits during wireless transmission is hard to achieveand therefore  fast_auth  is sufficient for wireless communi-cation, the decision on which mode to use is left to the useras a configuration parameter. 3.5. Replay Protection Frames transmitted over the wireless channel can easilybe intercepted and used for replay attacks. To detect theresending of such frames, DiscoSec implements a replayprotection by authenticating the frame’s sequence numbers.The IEEE 802.11 generic frame format contains a sequencenumber field which is 16 bits long out of which 4 bits areused forfragmentcountand only12 bits as frame sequence.
Related Search
Similar documents
View more
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!