WMNSec – Security for Wireless Mesh Networks Georg Lukas, Christian Fackroth Institute for Distributed Systems University of Magdeburg Universitätsplatz 2 39106 Magdeburg, Germany
[email protected],
[email protected] ABSTRACT Wireless Mesh Networks (WMNs) are gaining popularity as a flexible and inexpensive replacement for Ethernet-based infrastructure. However, WMN security has not been covered adequately by existing standards and implementations. We propose WMNSec, an adaptation of the IEEE 802.11i security standard, specifically targeted at Wireless Mesh Networks and accounting for limited CPU power, node mobility and interruption-free connectivity. WMNSec has been implemented on top of the MadWifi Linux driver and the hostapd suite. Experimental results from a real WMN show that even in a small eight-node network, WMNSec reduces the authentication time by up to a factor of 3 compared to 802.11i, while allowing mobile stations to move without performing additional authentications. The reduced overhead and the mobility feature confirm the practical usability of WMNSec, finally allowing to deploy WMNs in a secure way.
Categories and Subject Descriptors C.2.1 [Computer-Communication Networks]: Network Architecture and Design—Wireless; K.6.5 [Management of Computing and Information Systems]: Security and Protection—Authentication
General Terms Security, Reliability
Keywords
industry networking. However, the existing security mechanisms for IEEE 802.11[2] based Wireless LAN networks are either broken (WEP[3]) or do not scale well for WMNs (IEEE 802.11i[4]; application level VPNs). The IEEE 802.11 task group ”s”, which is responsible for the upcoming Wireless Mesh amendment[5] is still in a draft phase and will take several years to the standard’s completion. This work is embedded in a project to develop reliable and dependable WMNs[6]. As one aspect of reliability, it aims to close the security gap of todays WMNs. For this we present WMNSec, a security algorithm based on the 802.11i security standard and aspects from the 802.11s Mesh proposal. WMNSec was specifically designed to protect Wireless Mesh Networks against external attackers with no insider knowledge. It copes with the requirement for node mobility without re-authentications and allows seamless key exchange during the network run time. It uses the Wireless LAN hardware encryption engine, making it possible to deploy the protocol on embedded Mesh Point devices. In difference to 802.11s the protocol relies on the assumption that all Mesh Points, once authenticated, are credible – endto-end security has to be implemented at the application layer. The paper is structured as follows: section 2 discusses the available security mechanisms usable in a WMN. Section 3 presents the concept of WMNSec and its rationale. The implementation of WMNSec is presented in section 4 and its evaluation is shown in section 5. Conclusions are drawn in section 6.
Wireless Mesh Networks, Security, Authentication, Mobility
1.
INTRODUCTION
In scenarios where Ethernet cabling is too expensive or does not provide enough flexibility, Wireless Mesh Networks (WMNs) are gaining increasing popularity[1]. They provide self-x features like self-organization, self-configuration and self-healing. This reduces deployment time and maintenance expenses, making them ideal for logistics and process
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. IWCMC’09 June 21–24, 2009, Leipzig, Germany. Copyright 2009 ACM 978-1-60558-569-7/09/06 ...$10.00.
2.
RELATED WORK - SECURITY MECHANISMS
Every security solution has to consider five security aspects: authenticity, integrity, confidentiality, availability and non-repudiation. Typically, availability cannot be guaranteed in wireless networks due to the shared broadcast medium. Non-repudiation is usually required for financial and legal applications only, and is best covered by the according applications. The remaining three aspects are usually implemented using cryptographic protocols at the network layer. This section starts with a discussion of the IEEE 802.11i wireless security standard from a WMN point of view. It is followed by an outlook into the 802.11s Mesh proposal and a short discussion of other security mechanisms available in the context of WMNs.
2.1
IEEE 802.11i
The 802.11i standard ratified by the IEEE LAN/MAN Standards Committee in 2004 defines security mechanisms to provide authenticity, integrity and confidentiality in WLAN-based networks by using an authentication scheme to generate dynamic session keys which are used to encrypt the data traffic.
2.1.1
Authentication
802.11i defines an authentication mechanism, the 4-WayHandhake, which is used between an Access-Point (authenticator ) and a Client (supplicant) to verify the mutual authenticity using a common secret (the pre-shared key) or upperlayer authentication mechanisms like a PKI with client certificates or a RADIUS client database. The 4-Way-Handshake is based on the EAPOL protocol. However, 802.11i mainly covers the Infrastructure operation mode of WLAN networks. For the Ad-Hoc mode the standard requires every station to perform a 4-Way-Handhake with every neighbor, once as a supplicant and once as an authenticator. This is acceptable for small networks with two or three nodes. However, it does not scale well to WMNs, which are also implemented using the Ad-Hoc mode. In a typical roof-net WMN the node degree is d ≈ 4, meaning that every station has on average four neighbors (d = 4.02 for Berlins Freifunk” with ø 316 nodes[7], requir” ing 4.02 · 316 · 2 = 2541 handshakes a ´ 4 packets for a full network authentication). The situation worsens for industrial scenario WMNs, which need much higher node degrees to establish redundant communication links.
2.1.2
Key Management
During the 4-Way-Handhake, both the authenticator and the supplicant can derive the Pairwise Transient Key (PTK) used for unicast communication between the AP and the station. Multicast frames sent by the AP are encrypted with a Group Transient Key (GTK) which is periodically re-generated and sent to all stations using a group key handshake. PTK and GTK are used to encrypt and verify all communication between the client and the AP ensuring integrity and confidentiality of the data. Every key is accompanied with a sequence number to prevent replay attacks. In Ad-Hoc mode every station has to generate its own GTK which it will use for multicast transmissions. Additionally, it has to store a PTK per neighbor and every neighbor’s GTK (for receiving multicast frames) in its local key table. That means a station with N neighbors has to store 1 + 2 · N keys. However, most wireless cards only allow for either a total of four keys (originating from the WEP standard), or at most one key per neighbor. This is sufficient for a client or AP in Infrastructure mode, but makes it impossible to implement Ad-Hoc 802.11i with hardware encryption and verification.
2.1.3
Cryptographic Methods
The standard allows two different types of encryption/authentication suites, the Temporal Key Integrity Protocol (TKIP) based on the legacy RC4 algorithm also used in WEP, and the newer AES[8]-based Counter-Mode CBCMessage Authentication Code Protocol (CCMP). Both algorithms use a key derived from the PTK/GTK combined with a 48-bit Initialization Vector (IV) and the sender’s MAC address to prevent replay attacks.
One part of the key is used to encrypt the data, another to calculate a message authentication code which is sent with the packet. When a packet is received the according key is looked up in the key table either using a 2-bit key index or the sender’s MAC address; then the message is decrypted and its integrity verified. If the authentication code is wrong or the IV was not incremented, the message is discarded.
2.2
IEEE 802.11s (Draft)
To cope with the increasing relevance of WMNs, the IEEE is working on a new standard to define interoperation of different WMN implementations, the 802.11s amendment[5] to the Wireless LAN standard. This amendment specifies new operation modes and mesh routing protocols. However, in its current draft 2.0 it does not adequately cover security. It proposes a new Simultaneous Authentication of Equals protocol for the mutual authentication of stations which is based on elliptic curve cryptography. In addition it extends the key exchange algorithm to a three-level scheme, the Mesh Security Architecture[9], dividing the stations into a central Mesh Key Distributor (MKD), Mesh Authenticators (MA) and Mesh Points (MP). The MKD is the center for key generation and authentication, delegating some of its work to the MAs. MPs are regular stations which have to be authenticated by an MA or the MKD before they can participate in the network.
2.3
Other Approaches
In [10] Khan and Akbar present a light-weight multi-hop authentication scheme which could be used as an upper-layer mechanism on top of WMNSec or 802.11i to authenticate mobile clients without using a shared secret. Zhang and Fang show an approach for a different scenario where different Mesh Points are operated by different parties, posing another set of security vectors and issues like billing[11].
3.
WMNSEC CONCEPT
The 802.11i standard provides a very high security standard for Infrastructure and Ad-Hoc networks where different stations have no reason to believe each other and every link is encrypted using an individual key. However, when deployed in a WMN the protocol only ensures security of the single links of a multi-hop connection – a gateway node forwarding the data can not only read, but also manipulate any packets it is passing along; end-to-end security has to be implemented at the application layer. Nevertheless it is desirable to protect the less critical application data and mesh protocol traffic (routing tables, link metrics) from outside attackers. We propose an improved security protocol for WMNs. It deploys only one encryption key used by the whole network and generated by a dedicated station similar to the MKD. The key is propagated from the MKD to authenticated stations (the MPs) using the 4-Way-Handhake from 802.11i. The authentication process efficiently forms a spanning tree of the network. The time a key can be actually used is limited using a key validity field. Periodic re-keying ensures that all stations are using up-to-date key material. In the following, the exact rationale and concepts of Key Management, Authentication and Re-Keying are discussed in detail.
3.1
Key Management
To protect the WMN against outside attackers it is sufficient to deploy one single dynamically-generated key for the whole network – the Global Key (GK). Because the effective transmission key also contains the sender’s MAC address and a station-generated sequence number (IV), there is no reuse of key material, provided that the GK is re-generated periodically and on every network restart using a reliable random number generator. This approach requires a single assigned station, the Mesh Key Distributor (MKD), to generate the initial and following GKs. Similar to the MKD in the 802.11s proposal this can be a station connected to the backbone network and having direct access to the user database. However, it is possible to use a leader election protocol as well, either once or for every round of GK generation. Because there is only one key, all Mesh Points can decrypt and verify the messages from any other MP. However, when a station leaves the network or when the key has been used for some time, it needs to be re-generated. To allow that, every key is augmented with a relative validity value VN . This value is generated by the MKD and propagated together with the key. A sane value for typical networks is in the order of ten minutes.
3.2
Authentication and Key Distribution
Initially, only the MKD knows the newly generated GK. However, the key has to be transmitted to all stations which are allowed to participate in the network. Both requirements are fulfilled by combining key distribution and authentication using the 4-Way-Handhake for authentication and the Group Key Handhake to transmit the GK. Because the handshakes are used unmodified, it is possible to deploy the same authentication schemes as allowed by 802.11i: either the simple Pre-Shared Key based scheme, where every node is pre-configured with a passphrase; or more sophisticated upper-layer authentication mechanisms. The 802.11i standard requires every station to authenticate to every other station. However, this is not really required to ensure secure communication. In WMNSec every station has to perform only one authentication to become part of the network and to receive the Global Key. At the beginning the MKD is the only ”authenticated” station – the WMN consists only of the MKD. A station S1 which wants to participate in the WMN has to authenticate with the MKD using the 4-Way-Handhake. Hereby the MKD is the authenticator and S1 is the supplicant. When the mutual authentication succeeds the new station becomes an ”authenticated” part of the WMN and receives the GK using the Group Key Handhake. After that it can switch its role to authenticator and further distribute the key. Another station now can authenticate with the MKD or S1 , depending on which connection is more stable. Thus, the iterative authentication forms a spanning tree starting at the MKD and expanding to the whole network. Because a GKx is always augmented by its validity time Vx , the latter has to be transmitted during the handshake. The 802.11i standard allows to transfer user-specific fields as part of the handshake payload, so that the Group Key handshake has been extended to always include Vx for a transmitted GKx .
3.3
Station Roles
Two roles are used in the 4-Way-Handhake: supplicant and authenticator. Whenever a station needs to receive a GK it becomes a supplicant – either when it was just started, or when the GK it uses is expiring. A station in possession of the current GK becomes an authenticator and allows other stations to prove their authenticity and to receive the GK. The MKD is always an authenticator because it can generate a new GK whenever required. No station shall play both roles at the same time – either it does not have a current key, and thus cannot spread one, or it has one and does not require a key update. In Infrastructure mode of 802.11 authentication is triggered by the AP association process, whereby client and AP exchange special management frames and an explicit connection is setup. In Ad-Hoc mode (and thus also in WMNs) there is no explicit association, requiring a different approach to initiate the 4-Way-Handhake. In WMNSec every supplicant emits authentication requests periodically (a typical interval being 1s), which can be answered by a near-by authenticator. This imposes additional overhead whenever a new station is activated or a new key has to be deployed. However, no extra packets are needed once all stations are authenticated.
3.4
Re-Keying and Re-Authentication
When a cryptographic key is used actively, the amount of data encrypted with it grows and it becomes easier to perform attacks on the encryption algorithm. To prevent breaking of the security, every key has to be replaced after a certain amount of data has been encrypted with it. This also holds true for the GK, which has to be updated periodically to prevent IV-overflows. When a key is replaced by a new one it can happen that stations are using different keys and thus are not able to communicate with each-other. Because a WMN is a distributed system it is not possible to replace the key in the whole network instantaneously. Still, some applications demand interruption-free communication, requiring seamless exchange of the encryption keys. To provide service without interruptions a transition phase has been devised (example in Figure 1). This transition phase allows a station to migrate from the old to the new key without losing its ability to communicate with its neighbors, without a strict synchronization scheme. The transition begins when the validity VN of the current global key GKN is almost expired and consists of six steps: First, the new key GKN +1 is received using the 4-WayHandhake and Group Key Handshake, at the same time re-verifying the station’s authentication (1). After that both the old and the new key are set up as receiver (RX) keys (2). Now the station can receive packets from stations which already have completed the re-keying as well as from stations which have not started it yet. Now, to give other stations enough time to perform the rekeying, a transition delay T is performed (3). This time interval has to be dimensioned to allow all neighbors of the current station to perform a re-keying and to receive GKN +1 . A typical value is in the order of 10s. After the delay the station can assume that all neighbors have received the new GKN +1 , so it can be used for transmissions (TX; 4). Still, it is possible that other nodes are
in their own transition phase, and still use the deprecated GKN for transmitting. To allow neighbors to finish their own transition the old key GKN has to be allowed as a receive key (RX) for the same time other stations could use it: it is kept valid for a second transition time T (5). Finally, when it can be assumed that all stations have completed step 4 and thus are using GKN +1 , the old GKN can be invalidated and deleted from the key storage (6). transition step of M Pi : RX M Pi TX
M Pj
1
2
T3
4
T5
6
GKN , GKN +1
GKN
GKN +1
GKN
RX TX
GKN +1 GKN , GKN +1
GKN
GKN +1
GKN
transition step of M Pj :
GKN +1 1
2
T3
4
T5
6
t
Figure 1: Re-Keying: Six Steps of Distributed GK Update and Transition. (M Px = Mesh Point x; RX = receive key(s); TX = transmit key)
fundament for the management suite. It implements the 802.11i security standard for authenticators (hostapd) as well as for supplicants (wpa supplicant). These two components are designed for Infrastructure mode, directly mapping the roles to Access Point and client. They implement support for the 4-Way-Handhake using the pre-shared key or an upper-layer authentication mechanism and they setup the encryption keys in the wireless card, allowing to use the encryption hardware. For WMNSec, hostapd and wpa supplicant had to be merged into a single application running in a common context. This was required to allow switching the mode of operation between supplicant and authenticator, depending on knowledge of the GK. Also, the wpa supplicant implementation has been extended to allow multiple simultaneous handshakes with different authenticators. This is required in situations where the signal quality to one authenticator is not sufficient to fulfill a handshake. The key handling had to be changed to allow using one GK for all communication. Also, the group key handshake has been extended to always transmit a key and its validity time: (GKx , Vx )
4.2 The whole transition phase requires 2 · T to complete, meaning that it should be started when the remaining key validity is VN = 2 · T , preventing the old key from being used after its expiry. The transition of two stations M Pi and M Pj can be seen in Figure 1. Even though M Pj begins the transition at a later time, interruption-free communication is possible: when M Pi switches to the new key, M Pj has already completed step 2 and can successfully decrypt the packets. When M Pj switches to the new key, M Pi accepts packets encrypted with both keys, causing no packet losses. The transition algorithm steps are summarized as follows: 1. Change role to supplicant, perform Global Key Handshake, receive GKN +1 2. Change role to authenticator, install GKN +1 as additional receive key 3. Wait transition time T (T3 ) 4. Setup GKN +1 as new transmit key 5. Wait transition time T (T5 ) 6. Invalidate GKN
4.
IMPLEMENTATION
The implementation of WMNSec consists of several parts. First, the authentication and key handshake mechanisms must be put into practice. Then, the keys have to be stored locally and used for decrypting incoming and encrypting outgoing packets. Because the encryption process is very time consuming, it has to be implemented in hardware. WMNSec has been implemented based on the hostapd / wpa supplicant software and the Atheros WLAN driver on top of the Linux operating system.
4.1
Management Suite: Authentication and Handshake
The hostapd and wpa supplicant software suite by Jouni Malinen (http://hostap.epitest.fi/) has been used as a
Hardware-aided Encryption: Driver Extensions
Most Mesh Points are using embedded hardware with low-end CPUs. Thus it is not feasible to implement encryption in software. Instead, the hardware encryption engine provided by most wireless cards can be used. However, this requires the ability to flexibly change the use of the encryption keys, which is best possible with SoftMAC based wireless cards where most of the 802.11 protocol is implemented in software. The MadWifi project (http://madwifi-project.org/) has been chosen for this as it provides a SoftMAC implementation for Atheros based WLAN cards, which are easily available. In MadWifi keys are stored in the hardware’s key cache. A key has different attributes A: it can be associated to a MAC address (pairwise key), used for transmitting (tx) or receiving (rx), and optionally as a broadcast (group) key. Typically a station stores the APs group key with A = (rx, group) and the pairwise key with A = (M ACAP , rx, tx). The driver interface had to be changed to allow A = (rx, tx, group), which is required to use a global key. The driver also performs replay checks according to an internal key-associated IV counter. However, when more than one station is using the same key, the replay detection mechanism has to be adopted. It has to be extended to store an individual IV for every neighbor for a given key. These driver changes have made it possible to use the hardware encryption engine for WMNSec’s GK, allowing the protocol to run on embedded hardware without performance penalties.
5.
EVALUATION
To verify the correctness and performance of WMNSec, the implementation has been compared to the 802.11i standard protocol for Ad-Hoc mode using a real mesh network testbed. Two aspects were analyzed by the experiments: First, the initial authentication time has been measured for varying network sizes with two different kinds of topologies. Second, a functionality test of the re-authentication and rekeying process has been performed.
The initial authentication time of a network is the time duration from the initialization of the stations up to the moment when all stations are authenticated and have received all required keys (In WMNSec the GK, in 802.11i a pair of keys for every neighbor). The measured time allows conclusions about several aspects of the protocol: a) the overhead required to authenticate a number of stations; b) The actual time which is required until the network is initialized – this is especially important for large backbone networks with a central power supply switch; c) the time required for a new station to join an existing network (here the number of nodes in the experiment can be interpreted as the number of neighbors for the newcomer).
2
8
3
7
4
6
5
Experimental Setup and Topologies
The experiments were performed on a set of eight PCs running Debian GNU/Linux (testing; kernel version 2.6.24) equipped with Atheros AR5212 based wireless cards (MadWifi svn r3861). The experiments took place on channel 6 in 802.11g mode using the WMNSec extension of the hostap software (based on 0.6.1) with Pre-Shared Key authentication. First, a chain topology (Figure 2) has been evaluated, where the node degree grows from d = 1 (for N = 2 stations) to d = 1.75 (N = 8). This topology is the optimum for the 802.11i concept, because the total number of 4-WayHandhakes is very low (2 · (N − 1)) and all handshakes can be performed simultaneously. However, this topology is the worst case for WMNSec, because no parallelization is possible: the GK has to be propagated from the MKD (station 1) hop by hop through the whole network.
Figure 3: Fully Connected Network Topology; Eight Nodes ranges from the minimum to the maximum times for each network size for 802.11i, the light red area displays the minimums and maxmimums for WMNSec. 12
802.11i WMNSec
10 Time [s]
5.1
1
8 6 4 2
1
2
3
4
5
6
7
8 0
2
3
4
5
6
7
8
number of stations Figure 2: Chained Network Topology; Eight Nodes
Figure 4: Authentication Times of Chained Network
The second topology – a fully connected network (Figure 3) – has the opposite properties: here, the node degree of every node grows linearly with the number of nodes: d = (N − 1). 802.11i has to perform a mutual authentication between every pair of stations, causing significant authentication overhead (N · (N − 1) = N 2 − N handshakes). WMNSec can perform direct authentication of every node to the MKD (station 1) simultaneously, with a total of (N − 1) handshakes. The network size has been increased from two (stations 1 and 2) to eight (all stations) step-by-step to show the impact of the network size on the protocol overhead. For every network size a total of 20 experiment runs have been performed on each topology.
Figure 4 depicts the results from the chained network topology. It can be seen that WMNSec has a significantly higher time for a two-node network. This is due to the fact that the authentication is initiated based on a polling mechanism (supplicants are sending periodic authentication requests) whereas 802.11i is using the driver’s event interface to get an immediate information about new neighbors; the periodic polling adds a time penalty of one second. Besides of this the protocols behave as expected: with growing network size the time requirement of 802.11i stays almost constant due to the parallel handshaking, whereas WMNSec has a linear development due to its chained authentication. Still, for eight nodes the authentication time for WMNSec is only slightly higher than for 802.11i, despite the worst-case topology. Figure 5 shows the measurement results for the fully connected network. Again, the polling penalty of WMNSec can be seen for the smallest network size. However, for bigger topologies the significant overhead of 802.11i clearly shows its problems: more messages have to be passed through the
5.2
Measurements
Figures 4 and 5 depict the initial authentication time for the measured network topologies with different network sizes. The blue and red lines show the average times for 802.11i and WMNSec, respectively. The light blue area
12 10 Time [s]
6.
802.11i WMNSec
8 6 4 2 0
2
3
4
5
6
7
8
number of stations Figure 5: Authentication Times of Fully Connected Network
network, the parallel authentication with different stations causes higher collision probabilities, leading to an average initialization time of t802.11i = 9.01s. On the other hand WMNSec can show its strength with this topology: every station has to be authenticated only once and all handshakes can be performed in parallel. With tW M N Sec = 3.16 the average time is almost one third of the authentication overhead of the standard mechanism.
5.3
Discussion of Results
The presented measurements show that the 802.11i approach of mutual authentication between all stations does not scale well in dense networks. In typical WMNs its drawback is not that large, however it still imposes a big overhead on the network. The aspect of mobility has not been explicitly measured in the evaluation. However, it can be derived from the measurement results: For N = 2 both network topologies show that one authentication between two stations requires t = 0.52s on average. Because 802.11i requires a moving station to authenticate to all new neighbors, this extra delay has to be considered before any data traffic can be transmitted. This is not acceptable for applications like robot tele-operation, which require mobility and interruption-free communication. WMNSec on the other hand does not impose additional authentications for mobile stations. The initialization time penalty of WMNSec is based on the fact that WMNSec uses periodic authentication requests. It can be mitigated by reducing the period, causing additional network overhead; however it is not really required – the delay only occurs once for a station when it is just initialized. It does not affect existing connections and neither occurs during roaming. Another important aspect is the re-authentication. It has been verified using a UDP packet generator sending a continuous stream of packets from S1 to S2 , saturating the medium. During this both S1 and S2 performed several reauthentications to a third station, the MKD. The measured packet loss was lower than 0.004% for all experiments, the difference to a control experiment with re-authentications disabled was lower than the variance. There was no measurable interruption of data traffic.
CONCLUSION
In this paper we have presented WMNSec, an adaptation of the IEEE 802.11i security standard to the needs of Wireless Mesh Networks. By concentrating on protection against external attackers the authentication and key management overhead could be significantly reduced. This allows WMNSec to be deployed in scenarios where interruption-free connectivity and mobility are required, e.g. teleoperation of mobile robots. Still WMNSec relies on the secure mechanisms introduced by 802.11i – the 4-Way-Handhake and the periodic update of the used cryptographic keys. With these means it provides a much higher security barrier than WEP, which was the only feasible mean to secure WMNs before. The main restriction compared to 802.11i is that there is no protection against attackers with insider knowledge (i.e. participants of the WMN). While this has some relevance in roof-net WMNs, it is not an issue in centrally organized industrial networks. In future work WMNSec will be evaluated using a larger scale WMN test bed with 30-40 stations. Additionally it can be evaluated using client certificates issued for every station to verify the upper layer authentication support. WMNSec is however only one of the aspects covered in the ongoing work on reliable and dependable Wireless Mesh Networks. Other elements will ensure wireless network coverage, prevent overloads of the network and use more than one wireless channel to increase the redundancy.
7.
REFERENCES
[1] I. Akyildiz, X. Wang, and W. Wang, “Wireless mesh networks: a survey,” Computer Networks, vol. 47, no. 4, pp. 445–487, 2005. [2] 802.11 - Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, (ISO/IEC 8802-11: 1999) ed., IEEE Computer Society, 1999. [3] E. Tews, R.-P. Weinmann, and A. Pyshkin, “Breaking 104 bit WEP in less than 60 seconds,” Cryptology ePrint Archive, Report 2007/120, Apr 2007. [4] IEEE 802.11i standard, IEEE Computer Society, July 2004. [5] IEEE P802.11s Draft 2.0, IEEE Computer Society, April 2008. [6] G. Lukas, A. Herms, S. Ivanov, and E. Nett, “An integrated approach for reliability and dependability of wireless mesh networks,” in 13th IEEE Workshop on Dependable Parallel, Distributed and Network-Centric Systems DPDNS ’08, 2008. [7] B. Milic and M. Malek, “Analyzing large scale real-world wireless multihop network,” Communications Letters, IEEE, vol. 11, no. 7, pp. 580–582, July 2007. [8] J. Daemen and V. Rijmen, The Design of Rijndael: AES – the Advanced Encryption Standard. Secaucus, NJ, USA: Springer-Verlag New York, Inc., 2002. [9] D. Kuhlman, R. Moriarty, T. Braskich, S. Emeott, and M. Tripunitara, “A Proof of Security of a Mesh Security Architecture,” Cryptology ePrint Archive, Report 2007/364, 2007. [10] K. Khan and M. Akbar, “Authentication in Multi-Hop Wireless Mesh Networks,” in Proceedings of World Academy Of Science, Engineering and Technology, vol. 16, November 2006. [11] Y. Zhang and Y. Fang, “ARSA: An Attack-Resilient Security Architecture for Multihop Wireless Mesh Networks,” Selected Areas in Communications, IEEE Journal on, vol. 24, no. 10, pp. 1916–1928, October 2006.
