Mobile Ad Hoc Networks M. Avula Internet Draft S. M. Yoo Intended status: Informational University of Alabama in Huntsville Expires: August 8, 2014 S. G. Lee Dongseo University February 4, 2014 Secure Hybrid Wireless Mesh Protocol (SHWMP) Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 8, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract Secure Hybrid Wireless Mesh Protocol (SHWMP) for a Wireless Mesh Network (WMN) is a modified version of Hybrid Wireless Mesh Protocol (HWMP) which ensures both end-to-end and point-to-point authentication and integrity by using ID based signature schemes and key agreement schemes. Avula, et al. Expires August 8, 2014 [Page 1] Internet Draft shwmp-internet-draft February 4, 2014 Table of Contents 1. Introduction ....................................................2 2. Preliminary notes ...............................................3 2.1. Security requirement of WMN ................................3 2.2. Security features of secure HWMP............................3 3. Overview of secure HWMP .........................................4 4. Terminology .....................................................6 5. Message formats .................................................6 5.1. PREQ Message Extension .....................................6 5.2. PREP Message Extension .....................................7 5.3. PERR Message Extension .....................................8 5.4. RANN Message Extension .....................................9 5.5. GANN Message Extension ....................................10 6. Secure HWMP Operation ..........................................12 6.1. Non-mutable field protection ..............................12 6.2. Mutable field protection ..................................12 7. Security Analysis ..............................................13 8. References .....................................................14 1. Introduction In a Wireless Mesh Network (WMN), the default routing protocol is Hybrid Wireless Mesh Protocol (HWMP). HWMP is vulnerable to several routing attacks such as wormhole attacks, routing disruption attacks, flooding attacks etc. These attacks target the mutable fields of the frames exchanged in this protocol which change at every intermediate node and are prone to modification by malicious nodes. In HWMP, there are routing messages (frames) that are used for finding a route from source to destination. These frames require security mechanisms to prevent external and internal attacks. End-to- end encryption schemes can be employed to prevent external attacks. The real challenge in a WMN lies in preventing internal attacks. These frames contain two types of fields: mutable and non-mutable. Mutable fields are those that get changed at every hop of their journey. Therefore, the mutable fields require authentication at every hop in order to prevent illegal modification or deletion attacks. This can be achieved by employing a low cost two-hop authentication method where a two-hop neighbor will check if the node at previous hop has illegally modified the contents of the frame. This will also ensure that no malicious nodes impersonate as a legal node and be able to modify the contents of the frame. Non-mutable fields are not modified at every hop of the journey. Therefore, an end-to-end authentication using a signature scheme should be enough to prevent external attacks. SHWMP is a secure version of HWMP that uses cryptographic schemes to Avula, et al. Expires August 8, 2014 [Page 2] Internet Draft shwmp-internet-draft February 4, 2014 protect the routing messages by providing authentication and integrity security features. It uses ID based signature and broadcast encryption with non-interactive key agreement schemes to protect the non-mutable and mutable fields of HWMP in a WMN. 2. Preliminary notes This section describes the security requirements of a WMN and also lists the security features provided by SHWMP. HWMP is the default routing protocol of a WMN and this paper discusses the protection of HWMP routing messages but not the data messages. 2.1. Security requirement of WMN Simultaneous Authentication of Equals (SAE) and 802.1x authentication protocols are some of the security services for authentication of HWMP frames that can be applied to prevent external attacks in a WMN. Message integrity code can be used to ensure the integrity of the contents of a HWMP frame. On the other hand, algorithms like Advanced Encryption Standard (AES) can help protect the confidentiality. External attacks can be detected by using end-to-end based security. The major problem that is plaguing the WMNs is the detection of internal attacks. Internal attacks might involve modification of contents of the HWMP frame such as hop count and air time metric. Some of the fields of a HWMP frame get modified at every hop while others stay the same throughout their journey to the destination. For those fields that do not change, end-to-end security service such as a signature scheme should be enough to ensure protection. However, the fields that get changed is quite important to provide link-to- link based security so that every node along the journey should authenticate the frame before passing it on. This ensures that the contents of the frame are not modified and the frames can get dropped if they are modified. 2.2. Security features of Secure HWMP With regard to the security requirements discussed in the previous section, a secure version of HWMP is proposed with the following security features. These security features address the security of the two types of fields in a HWMP frame. Non-mutable fields are those fields which do not change from source to destination. Therefore, SHWMP used an ID based signature scheme to authenticate non-mutable fields. This scheme is a good candidate because the signer does not need to have a signed public-key certificate to be verified by other entities to verify the signatures generated by the signer. The public key is derived from the user's identity information such as a MAC address and a Private Key Generator (PKG) generates a corresponding Avula, et al. Expires August 8, 2014 [Page 3] Internet Draft shwmp-internet-draft February 4, 2014 private key from a master secret key. For the mutable fields' protection, a multi-source broadcast encryption scheme using probabilistic key distribution is used. This scheme will let multiple nodes to broadcast secrets without using asymmetric cryptographic primitives. Broadcast Encryption (BE) is a technique used to provide secret keys to a set of privileged members revoking access to other members of the network. The main idea behind using this scheme is that a key distribution center (KDC) will allocate a subset of keys to every node in the network from a total set of keys using a probabilistic key pre-distribution scheme. 3. Overview of SHWMP The solution proposed in this draft is a modified version of the HWMP wherein the HWMP routing frames have extensions to provide security features such as authentication and integrity. When a Path Request (PREQ) frame is generated by a source node, the non-mutable fields of the default PREQ frame are signed using an online/offline ID based signature scheme [1] and the signature is included in the message extension of the frame. Since non-mutable fields do not change at every hop, intermediate node authentication is not necessary and therefore the source node signs the non-mutable fields of the HWMP PREQ frame such as addresses and sequence numbers of originator and targets, lifetime, flags, PREQ ID, Element ID, Length and Target Count. The message extension also consists of a top hash value which is a random value hashed 'n' times, previous node metric which is nothing but the metric value of the previous node and a hash value corresponding the current hop count which is generated by applying hash function over maximum hop count, top hash and shared key between source and destination. Finally, Hashed Message Authentication Code (HMAC) is also appended to the message extension for the purpose of two-hop authentication using broadcast encryption mechanism [2]. This HMAC is hashed over a broadcast secret which is not available to the one-hop neighbor of the source as per the broadcast encryption scheme. Only the two-hop neighbor of the originator of the PREQ will be able to decrypt the HMAC. The entire PREQ is encrypted by the source node with a one-hop shared key which is used by its neighbor to decrypt when the source broadcasts this PREQ. The one-hop neighbor node will decrypt the PREQ generated by the source, increments the hop count, updates metric and previous node metric, and broadcasts it by encrypting using its one-hop secret key that it had shared with its one-hop neighbors as well. Note that it does not have access to source's broadcast secret. When the current node re-broadcasts the PREQ, it reaches the two-hop neighbor of the source node. This two-hop neighbor will have the broadcast secret as per the broadcast encryption and so will be able to access Avula, et al. Expires August 8, 2014 [Page 4] Internet Draft shwmp-internet-draft February 4, 2014 the HMAC and verify if the intermediate node has illegally modified contents of the PREQ. This provided for two-hop authentication. If everything is verified, this node will increment the hop count, update the metric, previous node metric, and appends a new HMAC and re-broadcasts it. This process repeats until the PREQ reaches the destination or one of the nodes knows a route to the destination. Pairwise transient keys are distributed using non-interactive key agreement scheme. These keys can be used when a Path Reply (PREP) frame needs to be generated by the destination/intermediate node. HMAC can be applied to mutable fields using these keys and appended to the message extension of a PREP. When the destination node receives a PREQ, it can unicast the PREP to the source because it is aware of the route to the source. PREP message extension is similar to PREQ except that HMAC uses the pairwise keys generated by non- interactive key agreement scheme. In case an intermediate node already has a route to the destination due to its previous encounter with either a PREQ or the PREP from the destination, it can generate a PREP to be unicasted to the source if the Destination Only (DO) flag is not set in the PREQ frame and if the last known sequence number of the destination in the PREQ it just received is lower than the sequence number of the destination the intermediate possesses in its route cache. Ideally, this process of intermediate node replying to a PREQ is basically an extension to the regular PREP reply process except that in this case the intermediate node fetches an extra step for authentication and verification purposes by contacting the adjacent node in the route to the destination. In case a node finds a broken link, it will generate a Path Error (PERR) message to its precursor node informing the broken link. The message extension field of PERR consists of signature of the non- mutable fields using online/offline ID based signature scheme and Time-To-Live (TTL). The whole PERR frame is encrypted using a Pairwise Master Key (PMK) generated by a mechanism known as Simultaneous Authentication of Equals (SAE). When a mesh station is generating and sending a Gate Announcement (GANN) frame announcing itself as the mesh gate, the gate announcement gets propagated in the network similar to a PREQ. Therefore, the frame flow of a GANN and a Root Announcement (RANN) is similar to a PREQ except that there is no set destination in the GANN/RANN because it is an announcement to all the mesh nodes. The message flow of a RANN is very similar to that of a GANN except that the mutable fields of a RANN in the message extension field include metric and previous node metric. Avula, et al. Expires August 8, 2014 [Page 5] Internet Draft shwmp-internet-draft February 4, 2014 4. Terminology This memo uses the conventional meanings [3] for the capitalized words MUST, SHOULD and MAY. It also uses terminology taken from the specifications of AODV and IPSec [4]. 5. Message formats This section describes proposed message extensions of the standard HWMP routing messages. The original HWMP message formats are not described here but only the extensions to them which are used for providing security features are described in the following sub- sections. 5.1. PREQ Message Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PNM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Top Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length The length of type specific data, not including the Type and Length fields. Reserved Reserved for future use. PNM This indicated the metric of the node at the previous hop. Top Hash The top hash for the hop count authentication. This is Avula, et al. Expires August 8, 2014 [Page 6] Internet Draft shwmp-internet-draft February 4, 2014 the result of hashing an initial value 'n' times, where 'n' is the maximum hop count. Hash This is the hashed value corresponding to the actual hop count of the current node under consideration. Signature This is the signature of the non-mutable fields of the HWMP frame that is obtained by using ID based signature scheme. The three bits of this signature in addition to the 60 bytes denote that only x-coordinates of the points on an elliptic curve are used. The ID based signature scheme is based on elliptic curve cryptography. HMAC This is the Hashed Message Authentication Code generated by using the Multi-Source Broadcast Encryption scheme. 5.2. PREP Message Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PNM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Top Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 Length The length of type specific data, not including the Type and Length fields. Reserved Reserved for future use. PNM This indicated the metric of the node at the previous hop. Avula, et al. Expires August 8, 2014 [Page 7] Internet Draft shwmp-internet-draft February 4, 2014 Top Hash The top hash for the hop count authentication. This is the result of hashing an initial value 'n' times, where 'n' is the maximum hop count. Hash This is the hashed value corresponding to the actual hop count of the current node under consideration. Signature This is the signature of the non-mutable fields of the HWMP frame that is obtained by using ID based signature scheme. The three bits of this signature in addition to the 60 bytes denote that only x-coordinates of the points on an elliptic curve are used. The ID based signature scheme is based on elliptic curve cryptography. HMAC This is the Hashed Message Authentication Code generated by using the Multi-Source Broadcast Encryption scheme. 5.3. PERR Message Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length The length of type specific data, not including the Type and Length fields. Reserved Reserved for future use. Signature This is the signature of the non-mutable fields of the HWMP frame that is obtained by using ID based signature scheme. The three bits of this signature in addition to the 60 bytes denote that only x-coordinates of the points on an elliptic curve are used. The ID based signature scheme is based on elliptic curve cryptography. HMAC This is the Hashed Message Authentication Code generated Avula, et al. Expires August 8, 2014 [Page 8] Internet Draft shwmp-internet-draft February 4, 2014 by using the Multi-Source Broadcast Encryption scheme. 5.4. RANN Message Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PNM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Top Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 Length The length of type specific data, not including the Type and Length fields. Reserved Reserved for future use. PNM This indicated the metric of the node at the previous hop. Top Hash The top hash for the hop count authentication. This is the result of hashing an initial value 'n' times, where 'n' is the maximum hop count. Hash This is the hashed value corresponding to the actual hop count of the current node under consideration. Signature This is the signature of the non-mutable fields of the HWMP frame that is obtained by using ID based signature scheme. The three bits of this signature in addition to the 60 bytes denote that only x-coordinates of the points on an elliptic curve are used. The ID based signature scheme is based on elliptic curve cryptography. Avula, et al. Expires August 8, 2014 [Page 9] Internet Draft shwmp-internet-draft February 4, 2014 HMAC This is the Hashed Message Authentication Code generated 5.5. GANN Message Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Top Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hash | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signature | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HMAC | ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 5 Length The length of type specific data, not including the Type and Length fields. Reserved Reserved for future use. Top Hash The top hash for the hop count authentication. This is the result of hashing an initial value 'n' times, where 'n' is the maximum hop count. Hash This is the hashed value corresponding to the actual hop count of the current node under consideration. Signature This is the signature of the non-mutable fields of the HWMP frame that is obtained by using ID based signature scheme. The three bits of this signature in addition to the 60 bytes denote that only x-coordinates of the points on an elliptic curve are used. The ID based signature scheme is based on elliptic curve cryptography. HMAC This is the Hashed Message Authentication Code generated The most important security feature of a path discovery process is to use cryptographic methods and provide authentication of non-mutable Avula, et al. Expires August 8, 2014 [Page 10] Internet Draft shwmp-internet-draft February 4, 2014 and mutable fields of the frame. This is accomplished by adding message extension fields to the HWMP path selection frame elements such as PREQ, PREP, GANN, RANN and PERR. The mesh station receiving the frame will be able to identify if the frame is accompanied by an extension by observing the flags field of the corresponding type of element. For example, the PREQ element format has Flags field which is eight bits long (B0:B7). Bits B3-B5 and B7 are reserved in general and thus, can be used in our case to notify the receiver of the existence of an extension field to the incoming frame. Similarly, PREP and PERR elements have Flags field which has B0-B5 and B7 bits reserved which can be used for the same purpose as mentioned above. Also, RANN and GANN elements have B1 through B7 and B0 through B7 bits reserved, respectively that can be used for notification of message extension fields. NAME LENGTH(bytes) DESCRIPTION Type 1 1 - PREQ 2 - PREP 3 - PERR 4 - RANN 5 - GANN Length 1 The length of type specific data, not including the Type and Length fields Reserved 2 For future use Top Hash 20 The top hash for the hop count authentication. PNM 4 Previous Node Metric Hash 20 The hash corresponding to the actual hop count. HMAC 20 HMAC for Mutable Fields using Multi-Source Broadcast Encryption scheme Signature 60 + 3bits The signature for Non-Mutable Fields using ID based scheme Similarity of message extensions: Both PREP and RANN message extensions are the same as PREQ message extension. PERR message extension is the same as PREQ message extension except that PNM, Top Hash, and Hash fields are not required. GANN message extension is the same as PREQ message extension except that PNM is not required. Avula, et al. Expires August 8, 2014 [Page 11] Internet Draft shwmp-internet-draft February 4, 2014 6. Secure HWMP Operation This section describes how SHWMP verifies authentication and integrity of the routing messages. Routing messages are secured based on the field type. Both mutable and non-mutable fields use different schemes for security. 6.1 Non-mutable field protection The following are the non-mutable fields of the PREQ frame used for path discovery process by mesh stations: Element ID, Length, Flags, Hop Count, Element TTL, Path Discovery ID, Originator Mesh Station Address, Originator HWMP Sequence Number, Originator External Address, Lifetime, Metric, Target Count, Per Target Flags, Target Address and Target Sequence Number. These fields need to be provided with end-to-end security from a source node to a destination node from illegal modification by intermediate nodes. In this case, end-to-end security is sufficient because these fields do not change from hop to hop and therefore, this offline/online signature scheme can be used to sign these fields by the source node requesting the route and can be verified by the destination node to ensure the integrity of the non-mutable fields. Using an ID based offline/online signature scheme detects the illegal modification of non-mutable fields of HWMP frames by malicious intermediate nodes and thus, it avoids potential internal attacks. Therefore, this scheme provides integrity assurance of non-mutable fields from the intermediate nodes on the transmission path to protect non-mutable field modification attacks. 6.2 Mutable field protection The proposed approach for securing mutable fields in route discovery process uses symmetric cryptographic primitives. Usually, broadcast encryption schemes are assumed to have single source broadcasting to multiple receivers. However, the proposed approach applies a broadcast encryption technique that has been adapted to support multiple sources thus, making it a good candidate for the HWMP protocol. An offline Key Distribution Center (KDC) is assumed to have distributed secrets to every node for establishing, between nodes, pairwise secrets and it is also assumed that the KDC has distributed, to every node, authentication and verification schemes of a multi- source broadcast encryption scheme. The source node uses Group Temporal Key (GTK) as the one-hop group secret (KS), encrypts it with its Pairwise Master Key (PMK) generated by Simultaneous Authentication of Equals (SAE) authentication protocol and delivers it to its one-hop neighbors. SAE is a peer-to-peer mutual Avula, et al. Expires August 8, 2014 [Page 12] Internet Draft shwmp-internet-draft February 4, 2014 authentication protocol which assumes that the nodes in the network already possess a pre-shared common password. A PMK generated by this protocol is shared between any given two nodes trying to authenticate and is used to encrypt the secret randomly selected by the nodes (say, in this case, KS). The source node also provides a Broadcast Encryption (BE) message (BS) which includes its encrypted broadcast secret TS. All one-hop neighbors of the source do revoked access to broadcast secret. One-hop neighbors of the source are expected to relay the BE message they receive to their one-hop neighbors. The two-hop neighbors of the source will be able to verify the integrity of BS that they receive with the pre-distributed broadcast keys that they possess already. This scheme ensures that a node securely recognizes its two-hop neighbors without having to trust one-hop neighbors. Any two-hop neighbor of the source that receives BS will be able to extract TS and verify that the previous node from which it received BS did not have access to TS. By verifying the HMAC in the BE message, it can verify the integrity of the message as well. 7. Security Analysis In the ID based signature scheme used in SHWMP, the hassle of requiring a pairing operation for signature generation/verification can be avoided. Also, no certificates are required to be attached to the signature for verification and no secret key information is required as it is generated by the Private Key Generator (PKG). The integrity of non-mutable fields can be verified at the destination using the ID based signature scheme. The shared key between the two end points of communication prevents the illegal deletion of nodes from the network. Non-interactive key agreement scheme prevents the eavesdropping attacks as the mutual keys are derived without any interaction between the communicating nodes. Broadcast encryption provides two-hop authentication which avoids any illegal modification of the contents of the frame and prevents non- authenticated nodes from joining the network unless they collude. Hashing at every intermediate node provides an additional layer of security. When the most known attacks can be avoided, replay attacks are still subjects of various research works due to their easy technique based on recording and re-sending a valid signed messages in the network. The detection of compromised nodes in a WMN is a vast research area and is out of the scope of this draft. SHWMP mostly focuses on security verification rather than malicious node detection and elimination. If a malicious node gets access to the common shared keys or if a healthy node turns rogue, the node must be detected and Avula, et al. Expires August 8, 2014 [Page 13] Internet Draft shwmp-internet-draft February 4, 2014 quarantined from the network. 8. References [1] Joseph K. Liu, Joonsang Baek, Jianying Zhou, Yanjiang Yang, and Jun Wen Wong. 2010. Efficient online/offline identity-based signature for wireless sensor network. Int. J. Inf. Secur. 9, 4 (August 2010), 287-296. [2] M. Ramkumar, "Broadcast Encryption with Probabilistic Key Distribution and Applications," Journal of Computers, June 2006. [3] S. Bradner: Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. [4] S. Kent, R. Atkinson: Security Architecture for the Internet Protocol. RFC 2402, November 1998. Authors' Addresses Mallikarjun Avula Dept. of Electrical & Computer Engineering The University of Alabama in Huntsville 301 Sparkman Dr Huntsville, AL 35899 EMail: ma0004@uah.edu Seong-Moo Yoo Dept. of Electrical & Computer Engineering The University of Alabama in Huntsville 301 Sparkman Dr Huntsville, AL 35899 EMail: yoos@uah.edu Sang-Gon Lee Division of Computer & Information Engineering Dongseo University 47 Jurye-ro, Sasang-gu Busan, 617-716, Korea EMail: nok60@dongseo.ac.kr Avula, et al. Expires August 8, 2014 [Page 14]