Comments 0

Document transcript

Ad hoc networks securityPietro Michiardi and Refik Molva1. IntroductionAn ad hoc network is a collection of wireless mobile hosts forming a temporarynetwork without the aid of any established infrastructure or centralized administration. Insuch an environment, it may be necessary for one mobile host to enlist the aid of otherhosts in forwarding a packet to its destination, due to the limited range of each mobilehost’s wireless transmissions. Mobile ad hoc networks (MANET) do not rely on anyfixed infrastructure but communicate in a self-organized way.Security in MANET is an essential component for basic network functions likepacket forwarding and routing: network operation can be easily jeopardized ifcountermeasures are not embedded into basic network functions at the early stages oftheir design. Unlike networks using dedicated nodes to support basic functions likepacket forwarding, routing, and network management, in ad hoc networks those functionsare carried out by all available nodes. This very difference is at the core of the securityproblems that are specific to ad hoc networks. As opposed to dedicated nodes of aclassical network, the nodes of an ad hoc network cannot be trusted for the correctexecution of critical network functions.If a priori trust relationship exists between the nodes of an ad hoc network, entityauthentication can be sufficient to assure the correct execution of critical networkfunctions. A priori trust can only exist in a few special scenarios like military networksand corporate networks, where a common, trusted authority manage the network, andrequires tamper-proof hardware for the implementation of critical functions. Entityauthentication in a large network on the other hand raises key management requirements.An environment where a common, trusted authority exists, is called a managedenvironment.When tamper-proof hardware and strong authentication infrastructure are notavailable, like for example in an open environment where a common authority thatregulates the network does not exist, any node of an ad hoc network can endanger thereliability of basic functions like routing. The correct operation of the network requiresnot only the correct execution of critical network functions by each participating node butit also requires that each node performs a fair share of the functions. The latterrequirement seems to be a strong limitation for wireless mobile nodes whereby powersaving is a major concern. The threats considered in the MANET scenario are thus notlimited to maliciousness and a new type of misbehavior called selfishness should also betaken into account to prevent nodes that simply do not cooperate.With lack of a priori trust, classical network security mechanisms based onauthentication and access control cannot cope with selfishness and cooperative securityschemes seem to offer the only reasonable solution. In a cooperative security scheme,page2node misbehavior can be detected through the collaboration between a number of nodesassuming that a majority of nodes do not misbehave.The rest of the chapter is organized as follows: section 2 presents the recentresearch that has been done in order to come up with secure routing protocols for ad hocnetworks that cope with threats that are specific to the ad hoc environment. All of thepresented secure protocols, however, do not take into account the node selfishnessproblem, which is detailed in section 3. Recent solutions to combat the lack of nodecooperation are presented in section 3. The basic requirement of a large number ofproposed security scheme is the presence of a key distribution mechanism managed by atrusted authority that take part in the initialization phase of the network: recent advancesin order to provide an automated key management scheme that does not require thepresence of any external infrastructure nor bootstrap phase where keys are distributed arepresented in section 4. In section 5, currently available security mechanisms implementedin the data link layer are detailed and analyzed. Furthermore section 5.3 focuses on adiscussion about the relevance for the ad hoc environment of security mechanismsimplemented in the data link layer.2. Secure RoutingRouting protocols for ad hoc networks are challenging to design: wired networksprotocols (such as BGP) are not suitable for an environment where node mobility andnetwork topology rapidly change; such protocols also have high communication overheadbecause they send periodic routing messages even when the network is not changing. Sofar, researchers in ad hoc networking have studied the routing problem in a non-adversarial network setting, assuming a reasonably trusted environment. However, unlikenetworks using dedicated nodes to support basic functions like packet forwarding,routing, and network management, in ad hoc networks, those functions are carried out byall available nodes. This very difference is at the core of the increased sensitivity to nodemisbehavior in ad hoc networks and the current proposed routing protocols are exposedto many different types of attacks.Section 2.1 presents and classifies the threats that a misbehaving node canperpetrate to jeopardize the network operation. Recent research brought up the need totake into account node misbehavior at the early stages of the routing protocol design:current efforts in secure routing protocol design are outlined and analyzed in section 2.2.2.1 Exploits allowed by existing routing protocolsCurrent ad hoc routing protocols are basically exposed to two different types ofattacks: active attacks and passive attacks. An attack is considered to be active when themisbehaving node has to bear some energy costs in order to perform the threat whilepassive attacks are mainly due to lack of cooperation with the purpose of saving energyselfishly. Nodes that perform active attacks with the aim of damaging other nodes bycausing network outage are considered to be malicious while nodes that perform passivepage3attacks with the aim of saving battery life for their own communications are considered tobe selfish.Malicious nodes can disrupt the correct functioning of a routing protocol bymodifying routing information, by fabricating false routing information and byimpersonating other nodes. Recent research studies [10] brought up also a new type ofattack that goes under the name of wormhole attack. On the other side, selfish nodes canseverely degrade network performances and eventually partition the network (refEW2002) by simply not participating to the network operation.2.1.1 Threats using modificationExisting routing protocols assume that nodes do not alter the protocol fields ofmessages passed among nodes. Malicious nodes can easily cause traffic subversion anddenial of service (DoS) by simply altering these fields: such attacks compromise theintegrity of routing computations. By modifying routing information an attacker cancause network traffic to be dropped, redirected to a different destination or take a longerroute to the destination increasing communication delays.2.1.2 Threats using impersonationSince current ad hoc routing protocols do not authenticate routing packets amalicious node can launch many attacks in a network by masquerading as another node(spoofing). Spoofing occurs when a malicious node misrepresents its identity in order toalter the vision of the network topology that a benign node can gather. As an example, aspoofing attack allows to create loops in routing information collected by a node with theresult of partitioning the network.2.1.3 Threats using fabricationThe notation “fabrication” is used when referring to attacks performed bygenerating false routing messages. Such kind of attacks can be difficult to identify as theycome as valid routing constructs, especially in the case of fabricated routing errormessages claiming that a neighbor can no longer be contacted.2.1.4 Wormhole attackA more subtle type of active attack is the creation of a tunnel (or wormhole) in thenetwork between two colluding malicious nodes linked through a private networkconnection. This exploit allows a node to short-circuit the normal flow of routingmessages creating a virtual vertex cut in the network that is controlled by the twocolluding attackers.page42.1.5 Lack of cooperationA selfish node that wants to save battery life for its own communication canendanger the correct network operation by simply not participating to the routing protocolor by not executing the packet forwarding (this attack is also known as the black holeattack) . Current ad hoc routing protocols can not cope with the selfishness problem andnetwork performances severely degrade.2.2 Secure routing protocolsCurrent efforts towards the design of secure routing protocols are mainly orientedto reactive (on-demand) routing protocols such as DSR [12] or AODV [13], where a nodeattempts to discover a route to some destination only when it has a packet to send to thatdestination. On-demand routing protocols have been demonstrated to perform better withsignificantly lower overheads than proactive routing protocols in many scenarios(references) since they are able to react quickly to topology changes, yet being able toreduce routing overhead in periods or areas of the network in which changes are lessfrequent. It is possible to find, however, interesting security solutions for proactiverouting protocols which are worthwhile to mention.Common to the secure routing protocols proposed in the literature, is the type ofattack they address: major effort is put into finding countermeasures against activeattacks performed by malicious nodes that aim at intentionally disrupt the routingprotocol execution while the selfishness problem is not addressed. Furthermore, theprerequisite for all the available solutions is a managed environment: in such scenario,nodes whishing to communicate may be able to exchange initialization parametersbeforehand, for example within the security of a dedicated network where session keysmay be distributed or through a trusted third party.Following, the major secure routing protocols for ad hoc networks will beoutlined and analyzed.2.2.1 SRPThe Secure Routing Protocol [1] proposed by Papadimitratos and Haas isconceived as an extension that can be applied to a multitude of existing reactive routingprotocols. SRP combats attacks that disrupt the route discovery process and guaranteesthe acquisition of correct topological information: a node initiating a route discovery isable to identify and discard replies providing false routing information or avoid receivingthem.The underlying assumption is the existence of a security association (SA)between the source node (S) and the destination node (T). The trust relationship could beinstantiated, for example, by the knowledge of the public key of the other communicatingend. The two nodes can negotiate a shared secret key (KS,T) and then, using the SA, verifythat the principal that participated in the exchange was indeed the trusted node.page5SRP copes with non-colluding malicious nodes that are able to modify (corrupt),replay and fabricate routing packets. Based on the dynamic source routing protocol(DSR, references) SRP requires the addition of a 6-word header containing uniqueidentifiers that tag the discovery process and a message authentication code (MAC). Inorder to initiate a route request (RREQ) the source node has to generate a MAC by akeyed hash algorithm that accepts as input the entire IP header, the basis protocol RREQpacket and the shared key KS,T.The intermediate nodes that relays the RREQ towards the destination measure thefrequencies of queries received from their neighbors in order to regulate the querypropagation process: each node maintains a priority ranking that is inversely proportionalto the queries rate. A node that maliciously pollutes network traffic with unsolicitedRREQ will be served last (if not ignored) because of its low priority ranking.Upon reception of a RREQ, the destination node verifies the integrity andauthenticity of the RREQ by calculating the keyed hash of the request fields andcomparing them with the MAC contained in the SRP header. If the RREQ is valid, thedestination initiates a route replay (RREP) using the SRP header the same way the sourcedid when initiating the request. The source node discards replays that do not match withpending query identifiers and checks the integrity using the MAC generated by thedestination.The basic version of SRP suffers from the route cache poisoning attack: routinginformation gathered by nodes that operate in promiscuous mode in order to improve theefficiency of the DSR protocol could be invalid, because fabricated by malicious nodes.The authors propose two alternative designs of SRP that uses an Intermediate NodeReply Token (INRT). INRT allows intermediate nodes that belong to the same group thatshare a common key (KG) to validate RREQ and provide valid RREP messages.SRP suffers also from the lack of a validation of route maintenance messages:route errors packets are not verified. However, in order to minimize the effects offabricated error messages, SRP source-routes error packets along the prefix of the routereported as broken: as a consequence the source node can verify that the provided routeerror feedback refers to the actual route and is not generated by a node that is not evenpart of the route. A malicious node can harm only the route it belongs.Assuming that the neighbor discovery mechanism maintains information on thebinding of the medium access control and the IP addresses of nodes, SRP is proven to beessentially immune to IP spoofing [1].SRP is, however, not immune to the wormhole attack: two colluding maliciousnodes can misroute the routing packets on a private network connection and alter thenetwork topology vision a benign node can collect.2.2.2 ARIADNEHu, Perrig and Johnson present an on-demand secure ad hoc routing protocolbased on DSR that withstands node compromise and relies only on highly efficientsymmetric cryptography. ARIADNE guarantees that the target node of a route discoveryprocess can authenticate the initiator, that the initiator can authenticate each intermediatenode on the path to the destination present in the RREP message and that no intermediatenode can remove a previous node in the node list in the RREQ or RREP messages.page6As for the SRP protocol, ARIADNE needs some mechanism to bootstrapauthentic keys required by the protocol. In particular, each node needs a shared secret key(KS,D, is the shared key between a source S and a destination D) with each node itcommunicates with at a higher layer, an authentic TESLA [3, 4] key for each node in thenetwork and an authentic “Route Discovery chain” element for each node for which thisnode will forward RREQ messages.ARIADNE provides point-to-point authentication of a routing message using amessage authentication code (MAC) and a shared key between the two parties. However,for authentication of a broadcast packet such as RREQ, ARIADNE uses the TESLAbroadcast authentication protocol. ARIADNE copes with attacks performed by maliciousnodes that modify and fabricate routing information, with attacks using impersonationand, in an advanced version, with the wormhole attack. Selfish nodes are not taken intoaccount.In ARIADNE, the basic RREQ mechanism is enriched with eight fields used toprovide authentication and integrity to the routing protocol:<ROUTE REQUEST, initiator, target, id, time interval, hash chain, node list, MAC list>The initiator and target are set to the address of the initiator and target nodes,respectively. As in DSR, the initiator sets the id to an identifier that it has not recentlyused in initiating a Route Discovery. The time interval is the TESLA time interval at thepessimistic expected arrival time of the request at the target, accounting for clock skew.The initiator of the request then initializes the hash chain to MACKS,D(initiator, target, id,time interval) and the node list and MAC list to empty lists.When any node A receives a RREQ for which it is not the target, the node checksits local table of <initiator, id> values from recent requests it has received, to determine ifit has already seen a request from this same Route Discovery. If it has, the node discardsthe packet, as in DSR. The node also checks whether the time interval in the request isvalid: that time interval must not be too far in the future, and the key corresponding to itmust not have been disclosed yet. If the time interval is not valid, the node discards thepacket. Otherwise, the node modifies the request by appending its own address (A) to thenode list in the request, replacing the hash chain field with H [A, hash chain], andappending a MAC of the entire REQUEST to the MAC list. The node uses the TESLAkey KAito compute the MAC, where i is the index for the time interval specified in therequest. Finally, the node rebroadcasts the modified RREQ, as in DSR.When the target node receives the RREQ, it checks the validity of the request bydetermining that the keys from the time interval specified have not been disclosed yet,and that the hash chain field is equal to:H [n, H [n-1, H [ . . . , H [1, MACKSD(initiator, target, id, time interval) ] . . . ] ] ]where iis the node address at position i of the node list in the request, and wheren is the number of nodes in the node list. If the target node determines that the request isvalid, it returns a RREP to the initiator, containing eight fields:<ROUTE REPLY, target, initiator, time interval, node list, MAC list, target MAC, key list>page7The target, i ni ti ator, ti me i nterval, node li st, and MAC li st fi elds are set to thecorrespondi ng values from the RREQ, the target MAC i s set to a MAC computed on theprecedi ng fi elds i n the reply wi th the key KDS , and the key li st i s i ni ti ali zed to the emptyli st. The RREP i s then returned to the i ni ti ator of the request along the source routeobtai ned by reversi ng the sequence of hops i n the node li st of the request.A node forwardi ng a RREP wai ts unti l i t i s able to di sclose i ts key from the ti mei nterval speci fi ed, then i t appends i ts key from that ti me i nterval to the key li st fi eld i n thereply and forwards the packet accordi ng to the source route i ndi cated i n the packet.Wai ti ng delays the return of the RREP but does not consume extra computati onal power.When the i ni ti ator recei ves a RREP, i t veri fi es that each key i n the key li st i svali d, that the target MAC i s vali d, and that each MAC i n the MAC li st i s vali d. If all ofthese tests succeed, the node accepts the RREP; otherwi se, i t di scards i t.In order to prevent the i njecti on of i nvali d route errors i nto the network fabri catedby any node other than the one on the sendi ng end of the li nk speci fi ed i n the errormessage, each node that encounters a broken li nk adds TESLA authenti cati oni nformati on to the route error message, such that all nodes on the return path canauthenti cate the error. However, TESLA authenti cati on i s delayed, so all the nodes on thereturn path buffer the error but do not consi der i t unti l i t i s authenti cated. Later, the nodethat encountered the broken li nk di scloses the key and sends i t over the return path, whi chenables nodes on that path to authenti cate the buffered error messages.ARIADNE i s protected also from a flood of RREQ packets that could lead to thecache poi soni ng attack. Beni gn nodes can fi lter out forged or excessi ve RREQ packetsusi ng Route Di scovery chai ns, a mechani sm for authenti cati ng route di scovery, allowi ngeach node to rate-li mi t di scoveri es i ni ti ated by any other node. The authors present twodi fferent approaches that can be found i n [2].ARIADNE i s i mmune to the wormhole attack only i n i ts advanced versi on: usi ngthe TIK (TESLA wi th Instant Key di sclosure, references) protocol that allows for verypreci se ti me synchroni zati on between the nodes of the network, i t i s possi ble to detectanomali es i n routi ng traffi c flows i n the network.2.2.3 ARANThe ARAN secure routi ng protocol proposed by Dahi ll, Levi ne, Royer andShi elds i s concei ved as an on-demand routi ng protocol that detects and protects agai nstmali ci ous acti ons carri ed out by thi rd parti es and peers i n the ad hoc envi ronment. ARANi ntroduces authenti cati on, message i ntegri ty and non-repudi ati on as part of a mi ni malsecuri ty poli cy for the ad hoc envi ronment and consi sts of a preli mi nary certi fi cati onprocess, a mandatory end-to-end authenti cati on stage and an opti onal second stage thatprovi des secure shortest paths.ARAN requi res the use of a trusted certi fi cate server (T): before enteri ng i n the adhoc network, each node has to request a certi fi cate si gned by T. The certi fi cate contai nsthe IP address of the node, i ts publi c key, a ti mestamp of when the certi fi cate was createdand a ti me at whi ch the certi fi cate expi res along wi th the si gnature by T. All nodes aresupposed to maintain fresh certificates with the trusted server and must know T’s publickey.page8The goal of the fi rst stage of the ARAN protocol i s for the source to veri fy thatthe i ntended desti nati on was reached. In thi s stage, the source trusts the desti nati on tochoose the return path. A source node, A, i ni ti ates the route di scovery process to reach thedesti nati on X by broadcasti ng to i ts nei ghbors a route di scovery packet called RDP:[RDP; IPX; certA; NA; t]KA-The RDP includes a packet type identifier (“RDP”), the IP address of thedestination (IPX), A's certificate (certA), a nonce NA, and the current time t, all signedwith A's private key. Each time A performs route discovery, it monotonically increasesthe nonce.Each node records the neighbor from which it received the message. It thenforwards the message to each of its neighbors, signing the contents of the message. Thissignature prevents spoofing attacks that may alter the route or form loops. Let A'sneighbor be B. It will broadcast the following message:[[RDP; IPX; certA; NA; t]KA-]KB-; certBNodes do not forward messages for which they have already seen the (NA; IPA)tuple. The IP address of A is contained in the certificate, and the monotonicallyincreasing nonce facilitates easy storage of recently-received nonces.Upon receiving the broadcast, B's neighbor C validates the signature with thegiven certificate. C then rebroadcasts the RDP to its neighbors, first removing B'ssignature:[[RDP; IPX; certA; NA; t]KA-]KC-; certCEventually, the message is received by the destination, X, who replies to the firstRDP that it receives for a source and a given nonce. There is no guarantee that the firstRDP received traveled along the shortest path from the source. The destination unicasts aReply (REP) packet back along the reverse path to the source. Let the first node thatreceives the RDP sent by X be node D. X will send to D the following message:[REP; IPA; certX; NA; t]KX-The REP includes a packet type identifier (“REP”), the IP address of A, thecertificate belonging to X, the nonce and associated timestamp sent by A. Nodes thatreceive the REP forward the packet back to the predecessor from which they received theoriginal RDP. All REPs are signed by the sender. Let D's next hop to the source be nodeC. D will send to C the following message:[[REP; IPA; certX; NA; t]KX-]KD-; certDC validates D's signature, removes the signature, and then signs the contents ofthe message before unicasting the following RDP message to B:[[REP; IPA; certX; NA; t]KX-]KC-; certCpage9A node checks the signature of the previous hop as the REP is returned to thesource. This avoids attacks where malicious nodes instantiate routes by impersonationand re-play of X's message. When the source receives the REP, it verifies that the correctnonce was returned by the destination as well as the destination's signature. Only thedestination can answer an RDP packet. Other nodes that already have paths to thedestination cannot reply for the destination. While other protocols allow this networkingoptimization, A RA N removes several possible exploits and cuts down on the reply trafficreceived by the source by disabling this option.The second stage of the A RA N protocol guarantees in a secure way that the pathreceived by a source initiating a route discovery process is the shortest. Similarly to thefirst stage of the protocol, the source broadcasts a Shortest Path Confirmation (SPC)message to its neighbors: the SPC message is different from the RDP message only intwo additional fields that provide the destination X certificate and the encryption of theentire message with X’s public key (which is a costly operation). The onion-like signingof messages combined with the encryption of the data prevents nodes in the middle fromchanging the path length because doing so would break the integrity of SPC the packet.Also the route maintenance phase of the ARAN protocol is secured by digitallysigning the route error packets. However it is extremely difficult to detect when errormessages are fabricated for links that are truly active and not broken. Nevertheless,because messages are signed, malicious nodes cannot generate error messages for othernodes. The non-repudiation provided by the signed error message allows a node to beverified as the source of each error message that it sends.As with any secure system based on cryptographic certificates, the key revocationissue has to be addressed in order to make sure that expired or revoked certificates do notallow the holder to access the network. In ARAN, when a certificate needs to be revoked,the trusted certificate server T sends a broadcast message to the ad hoc group thatannounces the revocation. Any node receiving this message re-broadcast it to itsneighbors. Revocation notices need to be stored until the revoked certificate would haveexpired normally. Any neighbor of the node with the revoked certificate needs to reformrouting as necessary to avoid transmission through the now un-trusted node. This methodis not failsafe. In some cases, the un-trusted node that is having its certificate revokedmay be the sole connection between two parts of the ad hoc network. In this case, the un-trusted node may not forward the notice of revocation for its certificate, resulting in apartition of the network, as nodes that have received the revocation notice will no longerforward messages through the un-trusted node, while all other nodes depend on it toreach the rest of the network. This only lasts as long as the un-trusted node's certificatewould have otherwise been valid, or until the un-trusted node is no longer the soleconnection between the two partitions. At the time that the revoked certificate shouldhave expired, the un-trusted node is unable to renew the certificate, and routing acrossthat node ceases. Additionally, to detect this situation and to hasten the propagation ofrevocation notices, when a node meets a new neighbor, it can exchange a summary of itsrevocation notices with that neighbor; if these summaries do not match, the actual signednotices can be forwarded and re-broadcasted to restart propagation of the notice.The ARAN protocol protects against exploits using modification, fabrication andimpersonation but the use of asymmetric cryptography makes it a very costly protocol topage10use in terms of CPU and energy usage. Furthermore, A RA N is not immune to thewormhole attack2.2.4 SEADHu, Perrig and Johnson present a proactive secure routing protocol based on theDestination-Sequenced Distance Vector protocol (DSDV). In a proactive (or periodic)routing protocol nodes periodically exchange routing information with other nodes inattempt to have each node always know a current route to all destinations [7].Specifically, SEA D is inspired by the DSDV-SQ version of the DSDV protocol. TheDSDV-SQ version of the DSDV protocol has been shown to outperform other DSDVversions in previous ad hoc networks simulations [8, 9].SEA D deals with attackers that modify routing information broadcasted during theupdate phase of the DSDV-SQ protocol: in particular, routing can be disrupted if theattacker modifies the sequence number and the metric field of a routing table updatemessage. Replay attacks are also taken into account.In order to secure the DSDV-SQ routing protocol, SEA D makes use of efficientone-way hash chains rather than relaying on expensive asymmetric cryptographyoperations. However, like the other secure protocols presented in this chapter, SEA Dassumes some mechanism for a node to distribute an authentic element of the hash chainthat can be used to authenticate all the other elements of the chain. A s a traditionalapproach, the authors suggest to ensure the key distribution relaying on a trusted entitythat signs public key certificates for each node; each node can then use its public key tosign a hash chain element and distribute it.The basic idea of SEA D is to authenticate the sequence number and metric of arouting table update message using hash chains elements. In addition, the receiver ofSEA D routing information also authenticates the sender, ensuring that the routinginformation originates form the correct node.To create a one-way hash chain, a node chooses a random initial value{}1,0x,where  is the length in bits of the output of the hash function, and computes the list ofvalues h0,h1,h2,h3,…,hn, where h0=x , and hi= H(hi-1) for 0< i  n , for some n. As anexample, given an authenticated hivalue, a node can authenticate hi-3by computingH(H(H(hi-3))) and verifying that the resulting value equals hi.Each node uses a specific authentic (i.e. signed) element from its hash chain ineach routing update that it sends about itself (metric 0). Based on this initial element, theone-way hash chain provides authentication for the lower bound on the metric in otherrouting updates for that node. The use of a hash value corresponding to the sequencenumber and metric in a routing update entry prevents any node from advertising a routeto some destination claiming a greater sequence number than that destination’s owncurrent sequence number. Likewise, a node can not advertise a route better than those forwhich it has received an advertisement, since the metric in an existing route cannot bedecreased due to the on-way nature of the hash chain.When a node receives a routing update, it checks the authenticity of theinformation for each entry in the update using the destination address, the sequencenumber and the metric of the received entry, together with the latest prior authentic hashpage11value received from that destination’s hash chain. Hashing the received elements thecorrect number of times (according to the prior authentic hash value) assures theauthenticity of the received information if the calculated hash value and the authentichash value match.The source of each routing update message in SEAD must also be authenticated,since otherwise, an attacker may be able to create routing loops through theimpersonation attack. The authors propose two different approaches to provide nodeauthentication: the first is based on a broadcast authentication mechanism such asTESLA, the second is based on the use of Message Authentication Codes, assuming ashared secret key between each couple of nodes in the network.SEAD does not cope with wormhole attacks though the authors propose, as in theARIADNE protocol, to use the TIK protocol to detect the threat.2.3 Notes on the wormhole attackThe wormhole attack is a severe threat against ad hoc routing protocols that isparticularly challenging to detect and prevent. In a wormhole attack a malicious node canrecord packets (or bits) at one location in the network and tunnel them to another locationthrough a private network shared with a colluding malicious node. Most existing ad hocrouting protocols, without some mechanism to defend them against the wormhole attack,would be unable to find consistent routes to any destination, severely disruptingcommunication.A dangerous threat can be perpetrated if a wormhole attacker tunnels all packetsthrough the wormhole honestly and reliably since no harm seems to be done: the attackeractually seems to provide a useful service in connecting the network more efficiently.However, when an attacker forwards only routing control messages and not data packets,communication may be severely damaged. As an example, when used against an ondemand routing protocol such as DSR, a powerful application of the wormhole attack canbe mounted by tunneling each RREQ message directly to the destination target node ofthe request. This attack prevents routes more than two hops long from being discoveredbecause RREP messages would arrive to the source faster than any other replies or,worse, RREQ messages arriving from other nodes next to the destination than theattacker would be discarded since already seen.Hu, Perrig and Johnson propose an approach to detect a wormhole based onpacket leashes [10]. The key intuition is that by authenticating either an extremely precisetimestamp or location information combined with a loose timestamp, a receiver candetermine if the packet has traversed a distance that is unrealistic for the specific networktechnology used.Temporal leashes rely on extremely precise time synchronization and extremelyprecise timestamps in each packet. The travel time of a packet can be approximated as thedifference between the receive time and the timestamp. Given the precise timesynchronization required by temporal leashes, the authors propose efficient broadcastauthenticators based on symmetric primitives. In particular they extend the TESLAbroadcast authentication protocol to allow the disclosure of the authentication key withinthe packet that is authenticated.page12Geographical leashes are based on location information and loosely synchronizedclocks. If the clocks of the sender and the receiver are synchronized within a certainthreshold and the velocity of any node is bounded, the receiver can compute an upperbound on the distance between the sender and itself and use it to detect anomalies in thetraffic flow. In certain circumstances however, bounding the distance between the senderand the receiver cannot prevent wormhole attacks: when obstacles preventcommunication between two nodes that would otherwise be in transmission range, adistance-based scheme would still allow wormholes between the sender and the receiver.To overcome this problem, in a variation of the geographical leashes the receiver verifiesthat every possible location of the sender can reach every possible location of the receiverbased on a radio propagation model implemented in every node.In some special cases, wormholes can also be detected through techniques thatdon’t require precise time synchronization nor location information. As an example, itwould be sufficient to modify the routing protocol used to discover the path to adestination so that it could handle multiple routes: a verification mechanism would thendetect anomalies when comparing the metric (e.g. number of hops) associated to eachroute. Any node advertising a path to a destination with a metric considerably lower thanall the others could raise the suspect of a wormhole.Furthermore, if the wormhole attack is performed only on routing informationwhile dropping data packets, other mechanisms can be used to detect this misbehavior.When a node doesn’t correctly participate to the network operation by not executing aparticular function (e.g. packet forwarding) a collaborative monitoring technique candetect and gradually isolate misbehaving nodes. Lack of cooperation and securitymechanism used to enforce node cooperation to the network operation is the subject ofthe next section.3. Cooperation enforcement in Mobile AdHoc NetworksAs opposed to networks using dedicated nodes to support basic networkingfunctions like packet forwarding and routing, in ad hoc networks these functions arecarried out by all available nodes in the network. There is no reason, however, to assumethat the nodes in the network will eventually cooperate one with another since networkoperation consumes energy, a particularly scarce resource in a battery poweredenvironment like MANET. The new type of node misbehavior that is specific to ad hocnetworks is caused by lack of cooperation and goes under the name of node selfishness. Aselfish node does not directly intend to damage other nodes with active attacks (mainlybecause performing active attacks can be very expensive in terms of energy consumption)but it simply does not cooperate to the network operation, saving battery life for its owncommunications.Damages provoked by selfish behavior can not be underestimated: a simulationstudy present in the literature [11] shows the impact of a selfish behavior in terms ofglobal network throughput and global communication delay when the DSR routingprotocol is used. The simulation results show that even a little percentage of selfish nodespresent in the network leads to a severe degradation of performances. Furthermore, anypage13security mechanism that tries to enforce cooperation among the nodes should focus notonly on one particular function, but on both the routing and the packet forwardingfunction: as an example, if a source routing mechanism as DSR is used, any node thatdoes not participate to the routing protocol cannot claim to participate to the packetforwarding function since it cannot appear in any route, meaning that it will never beasked to relay packets for other nodes of the network.The node selfishness problem has only recently been addressed by the researchcommunity, and still few mechanisms are provided to combat such misbehavior.Mechanisms that enforce node cooperation in a MANET can be divided in twocategories: the first is currency based (see section 3.1) and the second uses a localmonitoring technique (see sections 3.2, 3.3). On one side, currency based systems aresimple to implement but rely on a tamperproof hardware. The main drawback of thisapproach resides in the difficulty to establish how the virtual currency has to beexchanged making their use not realistic in a practical system. On the other side,cooperative security schemes based on local monitoring seem to offer the most suitablesolution to the selfishness problem. Every node of the MANET monitors its localneighbors evaluating for each of them a metric that is directly related to the nodes’behavior. Based on that metric, a selfish node can be gradually isolated from the network.The main drawback of this second approach is related to the absence of a mechanism thatsecurely identifies the nodes of the network: any selfish node could elude the cooperationenforcement mechanism and get rid of its bad reputation just by changing its identity.Following, the main research efforts towards the solution of the node selfishnessproblem are presented.3.1 NugletsIn [14], ] Buttyan and Hubaux present two important issues targeted specificallyat the ad hoc networking environment: first, end-users must be given some incentive tocooperate to the network operation (especially to relay packets belonging to other nodes);second, end-users must be discouraged from overloading the network. The solutionpresented in their paper consists in the introduction of a virtual currency (that they callNuglets) used in every transaction. Two different models are described: the Packet PurseModel and the Packet Trade Model. In the Packet Purse Model each packet is loaded withnuglets by the source and each forwarding host takes out nuglets for its forwardingservice. The advantage of this approach is that it discourages users from flooding thenetwork but the drawback is that the source needs to know exactly how many nuglets ithas to include in the packet it sends. In the Packet Trade Model each packet is traded fornuglets by the intermediate nodes: each intermediate node buys the packet from theprevious node on the path. Thus, the destination has to pay for the packet. The directadvantage of this approach is that the source does not need to know how many nugletsneed to be loaded into the packet. On the other hand, since the packet generation is notcharged, malicious flooding of the network cannot be prevented. There are some furtherissues that have to be solved: concerning the Packet Purse Model, the intermediate nodesare able to take out more nuglets than they are supposed to; concerning the Packet Tradepage14Model, the intermediate nodes are able to deny the forwarding service after taking outnuglets from a packet.3.2 ConfidantThe acronym given to the cooperation mechanism proposed by Buchegger and LeBoudec stands for “Cooperation Of Nodes, Fairness In Dynamic Ad-hoc NeTworks”[15,16] and it detects malicious nodes by means of observation or reports about severaltypes of attacks, thus allowing nodes to route around misbehaved nodes and to isolatethem. CONFIDANT works as an extension to a routing protocol such as Dynamic SourceRouting (DSR).Nodes have a monitor for observations, reputation records for first-hand andtrusted second-hand observations about routing and forwarding behavior of other nodes,trust records to control trust given to received warnings, and a path manager to adapt theirbehavior according to reputation and to take action against malicious nodes. The termreputation is used to evaluate routing and forwarding behavior according to the networkprotocol, whereas the term trust is used to evaluate participation in the CONFIDANTmeta-protocol.The dynamic behavior of CONFIDANT is as follows. Nodes monitor theirneighbors and change the reputation accordingly. If they have reason to believe that anode misbehaves, they can take action in terms of their own routing and forwarding andthey can decide to inform other nodes by sending an ALARM message. When a nodereceives such an ALARM either directly or by promiscuously listening to the network, itevaluates how trustworthy the ALARM is based on the source of the ALARM and theaccumulated ALARM messages about the node in question. It can then decide whether totake action against the misbehaved node in the form of excluding routes containing themisbehaved node, re-ranking paths in the path cache, reciprocating by non-cooperation,and forwarding an ALARM about the node.The first version of CONFIDANT was, despite the filtering of ALARM messagesin the trust manager, vulnerable to concerted efforts of spreading wrong accusations. Thisproblem has been addressed by the use of Bayesian statistics for classification and theexclusion of liars.Simulations with nodes that do not participate in the forwarding function haveshown that CONFIDANT can cope well, even if half of the network population actsmaliciously. Further simulations concerning the effect of second-hand information andslander have shown that slander can effectively be prevented while still retaining asignificant detection speed-up over using merely first-hand information.The limitations of CONFIDANT lie in the assumptions for detection-basedreputation systems. Events have to be observable and classifiable for detection, andreputation can only be meaningful if the identity of each node is persistent, otherwise it isvulnerable to spoofing attacks.page153.3 COREThe security scheme proposed by Michiardi and Molva [18, 19], stimulates nodecooperation by a collaborative monitoring technique and a reputation mechanism. Eachnode of the network monitors the behavior of its neighbors with respect to a requestedfunction and collects observations about the execution of that function: as an example,when a node initiates a Route Request (e.g., using the DSR routing protocol) it monitorsthat its neighbors process the request, whether with a Route Reply or by relaying theRoute Request. If the observed result and the expected result coincide, then theobservation will take a positive value, otherwise it will take a negative value.Based on the collected observations, each node computes a reputation value forevery neighbor using a sophisticated reputation mechanism that differentiates betweensubjective reputation (observations), indirect reputation (positive reports by others), andfunctional reputation (task-specific behavior), which are weighted for a combinedreputation value. The formula used to evaluate the reputation value avoids falsedetections (caused for example by link breaks) by using an aging factor that gives morerelevance to past observations: frequent variations on a node behavior are filtered.Furthermore, if the function that is being monitored provides an acknowledgementmessage (e.g., the Route Reply message of the DSR protocol), reputation information canalso be gathered about nodes that are not within the radio range of the monitoring node.In this case, only positive ratings are assigned to the nodes that participated to theexecution of the function in its totality.The CORE mechanism resists to attacks performed using the security mechanismitself: no negative ratings are spread between the nodes, so that it is impossible for a nodeto maliciously decrease another node’s reputation. The reputation mechanism allows thenodes of the MANET to gradually isolate selfish nodes: when the reputation assigned to aneighboring node decreases below a pre-defined threshold, service provision to themisbehaving node will be interrupted. Misbehaving nodes can, however, be reintegratedin the network if they increase their reputation by cooperating to the network operation.As for the other security mechanism based on reputation the CORE mechanismsuffers from the spoofing attack: misbehaving nodes are not prevented from changingtheir network identity allowing the attacker to elude the reputation system. Furthermore,no simulation results prove the robustness of the protocol even if the authors propose anoriginal approach based on game theory in order to come up with a formal assessment ofthe security properties of CORE.3.4 Token-based cooperation enforcementIn the approach presented by Yang, Meng, Lu [20] each node of the ad hocnetwork has a token in order to participate in the network operations, and its localneighbors collaboratively monitor it to detect any misbehavior in routing or packetforwarding services. Upon expiration of the token, each node renews its token via itsmultiple neighbors: the period of validity of a node’s token is dependent on how long ithas stayed and behaved well in the network. A well-behaving node accumulates its creditand renews its token less and less frequently as time evolves.page16The security solution proposed by the authors is composed of four closelyinteracted components: the neighbor verification, which describes how to verify whethereach node in the network is a legitimate or malicious node, the neighbor monitoring,which describes how to monitor the behavior of each node in the network and detectoccasional attacks from malicious nodes, the intrusion reaction, which describes how toalert the network and isolate the attackers and the security enhanced routing protocol,which explicitly incorporates the security information collected by the other componentsinto the ad hoc routing protocol.Concerning the token issuing/renewal phase, the authors assume a globalsecret/public key pair SK/PK, where PK is well known by every node of the network. SKis shared by k neighbors who collaboratively sign the token requested or renewed by localnodes. Token verification, on the other side, follows three steps: 1) identity matchbetween the node’s ID and the token ID, 2) validity time verification, 3) issuer signature.If the token verification phase fails, the corresponding node is rejected from the networkand both routing and data packets are dropped for that node.Routing security relies on the redundancy of routing information rather thancryptographic techniques: the routing protocol that the authors use as a basis is the Adhoc On demand Distance Vector protocol (AODV) which is extended in order to detectfalse routing update messages by comparing routing information gathered from differentneighboring nodes. Packet forwarding misbehavior is also detected using a modifiedversion of the watchdog technique presented in [17] bypassing the absence of any sourceroute information by adding a next hop field in the routing messages.The proposed solution presents some drawbacks: the bootstrap phase needed togenerate a valid collection of partial tokens which will be used by a node to create itsfinal token has some limitations. For example to the number of neighbors necessary tocomplete the signature of every partial token has to be at least k, suggesting the use ofsuch security mechanism in rather large and dense ad hoc networks. On the other side,the validity period of a token increases proportionally to the time during which the nodebehave well: this interesting feature has less impact if node mobility is high. Frequentchanges in the local subset of the network that shares a key for issuing valid tokens cancause high computational overhead, not to mention the high traffic generated byissuing/renewing a token, suggesting that the token-based mechanism is more suitable inad hoc networks where node mobility is low. Spoofing attacks, where a node can requestmore than one token claiming different identities, are not taken into account even if theauthors suggest that MAC addresses can be sufficient for node authentication purposes.4. Authentication and Public KeyInfrastructure (PKI)Providing security support for ad hoc networks is challenging for a number ofreasons: wireless networks are susceptible to security attacks ranging from passiveeavesdropping to active interfering and DoS attacks; occasional break-ins in a large-scalemobile network are inevitable over a large time interval; ad hoc networks provide noinfrastructure support; mobile nodes may constantly leave or join the network; mobility-induced wireless links breakage/reconnection and wireless channel errors make timelypage17communications over multiple hops highly unreliable; and a scalable solution is a mustfor a large scale network. However, the provision of basic security services such asauthentication, confidentiality, integrity and non-repudiation is critical in order to deploythe mobile wireless ad hoc technology in commercial and military environments.Authentication services specific to the ad hoc environment have been recentlystudied by the research community in order to come up with a fully self-organizedarchitecture to overcome the limitations intrinsic to the secure routing protocols that havebeen presented in section 2.2.The basic assumption adopted by some secure routing protocol such as SRP is theexistence of an a-priori security association between all the communicating nodes of thenetwork: the limitations introduced by this approach range from the need of a managedenvironment, such as a common authority that pre-charges all the mobile terminals with asecret key shared by every couple of communicating nodes, to scalability problems.Other secure routing protocols (such as Ariadne) rely on an initialization phaseduring which a well known trusted third party (TTP) issues public key certificates used toauthenticate (together with the private key of each certificate holder) hash chain elementsthat will be subsequently used to provide some low cost (in terms of CPU usage)authentication services. In this case, the use of such a secure protocol is not limited to themanaged environment, and the open environment can be targeted: indeed, it is notnecessary for the mobile nodes that form the ad hoc network to be managed by the sameauthority that provides the initial authentication setup. However, the bootstrap phaserequires an external infrastructure, which has to be available also during the lifetime ofthe ad hoc network to provide revocation services for certificates that have expired or thathave been explicitly revoked.Current efforts in order to provide scalable, fully self-organized public keyinfrastructure and authentication services can be classified in two categories, one basedon a PGP-like architecture and one based on the polynomial secret sharing technique, andare presented in the next sections.4.1 Self-Organized Public-Key Management based onPGPCapkun, Buttyan and Hubaux propose a fully self-organized public keymanagement system that can be used to support security of ad hoc network routingprotocols [21]. The suggested approach is similar to PGP [22] in the sense that users issuecertificates for each other based on their personal acquaintances. However, in theproposed system, certificates are stored and distributed by the users themselves, unlike inPGP, where this task is performed by on-line servers (called certificate directories). In theproposed self-organizing public-key management system, each user maintains a localcertificate repository. When two users want to verify the public keys of each other, theymerge their local certificate repositories and try to find appropriate certificate chainswithin the merged repository that make the verification possible.The success of this approach very much depends on the construction of the localcertificate repositories and on the characteristics of the certificate graphs. By a certificategraph is meant to be a graph whose vertices represent public-keys of the users and thepage18edges represent public-key certificates issued by the users. The authors investigate onseveral repository construction algorithms and study their performance. The proposedalgorithms take into account the characteristics of the certificate graphs in a sense that thechoice of the certificates that are stored by each mobile node depends on the connectivityof the node and its certificate graph neighbors.More precisely, each node stores in its local repository several directed andmutually disjoint paths of certificates. Each path begins at the node itself, and thecertificates are added to the path such that a new certificate is chosen among thecertificates connected to the last node on the path (initially the node that stores thecertificates), such that the new certificate leads to the node that has the highest number ofcertificates connected to it (i.e., the highest vertex degree). The authors call this algorithmthe Maximum Degree Algorithm, as the local repository construction criterion is thedegree of the vertices in a certificate graph.In a second, more sophisticated algorithm that is called the Shortcut HunterAlgorithm, certificates are stored into the local repositories based on the number of theshortcut certificates connected to the users. The shortcut certificate is a certificate that,when removed from the graph makes the shortest path between two users previouslyconnected by this certificate strictly larger than two.When verifying a certificate chain, the node must trust the issuer of thecertificates in the chain for correctly checking that the public key in the certificate indeedbelongs to the node identification (ID) named in the certificate. When certificates areissued by the mobile nodes of an ad hoc network instead of trusted authorities, thisassumption becomes unrealistic. In addition, there may be malicious nodes who issuefalse certificates. In order to alleviate these problems, the authors propose the use ofauthentication metrics [23]: it is not enough to verify a node ID key binding via a singlechain of certificates. The authentication metric is a function that accepts two keys (theverifier and the verified node) and a certificate graph and returns a numeric valuecorresponding to the degree of authenticity of the key that has to be verified: one exampleof authentication metric is the number of disjoint chains of certificates between twonodes in a certificate graph.The authors emphasize that before being able to perform key authentication, eachnode must first build its local certificate repository, which is a relatively expensiveoperation (in terms of bandwidth and time). However this initialization phase must beperformed rarely and once the certificate repositories have been built, then any node canperform key authentication using only local information and the information provided bythe targeted node. It should also be noted that local repositories become obsolete if alarge number of certificate are revoked, as then the certificate chains are no longer valid;the same comment applies in the case when the certificate graph changes significantly.Furthermore, PGP-like schemes are more suitable for small communities because that theauthenticity of a key can be assured with a higher degree of trustiness. The authorspropose the use of authentication metrics to alleviate this problem: this approach howeverprovides only probabilistic guarantees and is dependent on the characteristics of thecertificate graph on which it operates. The authors also carried out a simulation studyshowing that for the certificate graphs that are likely to emerge in self-organized systems,the proposed approach yields good performances both in terms of the size of the localrepository stored in each node and scalability.page194.2 Ubiquitous and Robust Authentication Servicesbased on polynomial secret sharingIn [24] Luo and Lu present a mechanism that provides ubiquitous authenticationservice availability by taking a certificate-based approach. In the proposed scheme, anytwo communicating nodes can establish a temporary trust relationship via globallyverifiable certificates. With a scalable threshold sharing of the certificate signing key,certification services (issuing, renewal and revocation) are distributed among each nodein the network: a single node holds just a share of the complete certificate signing key.While no single node has the power of providing full certification services, multiplenodes in a network locality can collaboratively provide such services.The authors propose a localized trust model to characterize the localized nature ofsecurity concerns in large ad hoc wireless networks. When applying such trust model, anentity is trusted if any k trusted entities claim so: these k trusted entities are typically theneighboring nodes of the entity. A locally trusted entity is globally accepted and a locallydistrusted entity is regarded untrustworthy anywhere. k is a system wide parameter thatsets the global acceptance criteria and should be honored by each entity in the system.The basic assumption that are necessary for the security mechanism to functionproperly are: 1) each node has a unique nonzero identifier (ID), such as its MAC layeraddress; 2) each node has some one-hop discovery mechanism; 3) each node has at leastk one-hop legitimate neighboring nodes, or the network has a minimum density of well-behaving nodes; 4) each node is equipped with some detection mechanism to identifymisbehaving nodes among its one-hop neighborhood; 5) the mobility is characterized bya maximum node moving speed Smax.In the security architecture proposed [24], each node carries a certificate signedby the share certificate signing key SK, while the corresponding public key PK isassumed to be well-known by all the nodes of the network, so that certificates areglobally verifiable. Nodes without valid certificates will be isolated, that is, their packetswill not be forwarded by the network. Essentially, any node without a valid certificate aretreated the same as adversaries. When a mobile node moves to a new location, itexchanges certificates with its new neighbors and goes through mutual authenticationprocess to build trust relationships. Neighboring nodes with such trust relationship helpeach other to forward and route packets. They also monitor each other to detect possibleattacks and break-ins. Specific monitoring algorithms and mechanisms are left to eachindividual node’s choice. When a node requests a signed certificate by the coalition of knodes, each of the certificate issuing nodes checks its record on the requesting node. Ifthe record shows that the requestor is a well-behaving legitimate node it returns a partialcertificate by applying its share of SK. Otherwise the request is dropped. By collecting kpartial certificates the requesting node combines them together to generate the full newcertificate as if it was issued from a certification authority server. A misbehaving orbroken node that is detected by its neighbors will be unable to get a new certificate.The security of the certificate signing key SK is protected by a k-thresholdpolynomial sharing mechanism. However, this technique requires a bootstrapping phasewhere a “dealer” has to privately send to each node its share of the SK. The authorspropose a scalable initialization mechanism that they called “self-initialization”. In thiscase, the dealer is only responsible to initialize the very first k nodes, no matter how largepage20the network would be. The initialized nodes collaboratively initialize other nodes:repeating this procedure, the network progressively self-initializes itself. The samemechanism is applied when new nodes join the network.Certificate revocation is also handled by the proposed architecture and an originalapproach to handle roaming adversaries is presented: without this additional mechanism,any misbehaving node that moves to a location of the network where its new neighborshave no information in their monitoring records about the attacker, could get a new validcertificate. Roaming nodes are defeated with the flooding of “accusation” messages thattravel in the network and inform distant nodes about the behavior of a suspect node.Accusation messages are accepted only if they come from well-behaving nodes and havea specific time to live (TTL) field that is calculated based on the maximum node speedspecified in the assumptions.The main drawbacks of the proposed architecture range from the necessity of anexternal, trusted dealer that initializes the very first k nodes of a coalition to the choice ofthe system-wide parameter k. To cope with the first problem, the authors propose to use adistributed RSA key pair generation [25] for the very first k nodes. On the other side, nopractical solutions are presented to cope with the strong assumption that every node ofthe network has at least k trusted and not compromised neighbors. This limitation makesthe proposed architecture un-useful for all the nodes that are located at the perimeter ofthe ad hoc network. More over, the authors assume that any new node that joins thesystem already has an initial certificate: initial certificates can be obtained in two ways.Every node may be issued an initial certificate by an offline authority or every new nodemay use any coalition of k neighbors to issue the initial certificate via a collaborativeadmission control mechanism. These problems reduce the effectiveness of the proposedarchitecture as a fully self organized infrastructure.5. Security Mechanisms in Layer 2This section presents data link layer security solutions that are suitable for MANET. Themost prevalent solutions are the security mechanisms as part of 802.11 and Bluetoothspecifications. Further to a detailed overview of their specifications the weaknesses ofeach solution is analyzed. The relevance of these solutions with respect to the securityrequirements of MANET are then discussed.5.1 Wired Equivalent Privacy (WEP)The first security scheme provided in the series of IEEE 802.11 standards is WiredEquivalent Privacy (WEP) specified as part of the 802.11b Wireless Fidelity (Wi-Fi)standard [26]. WEP was originally designed to provide security for wireless local areanetworks (WLAN) with a level of protection that is similar to the one expected in wiredLAN’s. The latter enjoys security and privacy due to the physical security mechanismslike building access control. Physical security mechanisms unfortunately do not preventeavesdropping and unauthorized access in case of wireless communications. WEP thusaims at covering the lack of physical security akin to WLANs with security mechanismspage21based on cryptography. Unfortunately WEP suffers from various design flaws and someexposure in the underlying cryptographic techniques that seriously undermine its securityclaims.5.1.1 WEP Security MechanismsWEP security mechanisms include data encryption and integrity. Both mechanisms arehandled simultaneously for each frame as illustrated inFigure 1.page22Figure 1: WEP Frame Security MechanismsTo prepare a protected frame, first an integrity check value (ICV) of the frame payload iscomputed using a cyclic redundancy check (CRC) function. The cleartext payloadconcatenated with ICV is then encrypted using a bit-wise exclusive-or operation with akeystream as long as the payload concatenated with ICV. The keystream is a pseudo-random bit stream generated by the RC4 [28] algorithm from a 40-bit secret keyprepended with a 24-bit Initialization Value (IV). The resulting protected frame includesthe cleartext frame header, the cleartext IV, the result of the encryption and a cleartextframe check sequence field.The recipient of a WEP frame first generates the keystream with RC4 using the sharedsecret key and the IV value retrieved from the received frame. The resulting keystream isexclusive-ored with the encrypted field of the frame to decrypt the payload and the ICV.The integrity of the payload is then checked by comparing the integrity check computedon the cleartext payload with the ICV resulting from the decryption.The secret key can either be a default key shared by all the devices of a WLAN or a pair-wise secret shared only by two communicating devices. Since WEP does not provide anysupport for the exchange of pair-wise secret keys, the secret key must be manuallyinstalled on each device.5.1.1.1 Security Problems in WEPWEP suffers from many design flaws and some weaknesses in the way the RC4 cipher isused in WEP.Data encryption in WEP is based on an approximation of the “one-time pad” [28]algorithm that can guarantee perfect secrecy under some circumstances. Like WEPPayloadIntegrityCheckICVRC4keystreamX-ORIVkeyPayload + ICVIVHeaderFCSEncryptedClearClear24-bit 40-bitWEPFramepage23encryption, one-time pad encryption consists of the bit-wise exclusive-or between abinary plaintext message and a binary keystream as long as the message. The secrecy ofthe resulting ciphertext is perfect provided that each new message is encrypted with adifferent secret random keystream. The secrecy is not guaranteed when the keystream isre-used or its values can be predicted. Hence a first class of attacks on WEP exploitpossible weaknesses in WEP’s keystream generation process that make the secretkeystream easily predictable or cause its re-use.The first type of exposure is due to the likeliness of keystream re-use between a pair ofcommunicating devices. Using the same secret key, the only variation in the input to thekeystream generator is due to the variation in the IV. Since the IV is 24-bit value sent incleartext, the re-use of a keystream can be easily detected. The re-use of a keystream isalso very likely because of the small set of possible IV values that can be exhausted in afew hours in busy traffic between two nodes. This type of exposure gets even worse ifsome care is not taken during the implementation of the standard: some products set theIV to a constant value (0 or 1) at the initialization of the encryption process for eachframe sequence. The second type of exposure is due to the use of a 40-bit secret that ishighly vulnerable to exhaustive search with current computational power.WEP data encryption is also exposed through an advanced attack that takes into accountthe characteristics of the RC4 algorithm [29] and drastically reduces the set of possiblekeystream values based on the attacker’s ability to recover the first byte of encryptedWEP payload.Another class of exposure on WEP concerns the data integrity mechanism using CRC incombination with the one-time pad encryption. Encryption using exclusive-or operationis transparent with respect to modification in that flipping bits of the encrypted messagecause flipped bits on the same positions of the cleartext values resulting from decryption.As opposed to a cryptographically secure hash function, an integrity check computedwith CRC yields predictable changes on the ICV with respect to single-bit modificationson the input message. Combining the transparency of exclusive-or with the predictablemodification property of CRC, an attacker can flip bits on well known positions of anencrypted WEP payload and on the corresponding positions of the encrypted ICV so thatthe resulting cleartext payload is modified without the modification being detected by therecipient. It should be noted that the transparent modification of the WEP payload doesnot require the knowledge of the secret payload value since the attacker only needs toknow the location of some selected fields in the payload to force the tampering of theirvalue.Last weakness of WEP is the lack of key management that is a potential exposure formost attacks exploiting manually distributed secrets shared by large populations.5.1.1.2 New ProposalTo address the shortcomings of WEP IEEE has set up a special Task Group I (TGi) incharge of designing the new security architecture as part of the forthcoming version ofthe standard called 802.11i . To cope with brute force attacks, TGi has already proposedto include a 128-bit RC4 seed of which 104 bits are secret. TGi also proposed a long termarchitecture based on the IEEE 802.1x standard, which itself is based on the IETF’sExtensible Authentication Protocol (EAP). IEEE 802.1x has a flexible design supportingpage24various authentication modes. However the new proposal based on 802.1x alreadysuffers from problems like lack of data integrity for wireless frames and lack of mutualauthentication.5.2 Bluetooth Security MechanismsBluetooth specification [27] includes a set of security profiles defined for the applicationlayer in the so-called service level security and security profiles for the data link layer.Both types of profiles rely on key management, authentication and confidentialityservices based on cryptographic security mechanisms implemented in the data link layer.Each Bluetooth device stands for an independent party from the point of view of thesecurity protocols. In each device security mechanisms use a set of basic components:· the device address (BD_ADDR): a-48 bit address defined by the IEEE that is uniquefor each Bluetooth device· a 128-bit authentication key· a128-bit symmetric data encryption key· a random number (RAND) generated by a pseudo-random or (physical) randomnumber generator.5.2.1 Key ManagementBluetooth key management services provide each device with a set of symmetriccryptographic keys required for the initialization of a secret channel with another device,the execution of an authentication protocol, and the exchange of encrypted data withanother device.5.2.1.1 Key hierarchyThe key hierarchy of Bluetooth includes two generic key types:· the link key that is shared by two or more parties and used as a key encrypting key(KEK) to encrypt other keys during key exchange or as a seed to generate other keys· the encryption key that is a shared data encryption key (DEK).Both the link key and the encryption key are 128-bit symmetric keys. The link key canfurther be qualified as an initia liza tion key, a unit key, a com bina tion key or a m a ster key.When two devices need to communicate using link level security and have noprior engagement, they establish a secure channel based on the initia liza tion key. Thischannel is then used by the communicating devices to establish a sem i-perm a nent linkkey that will be used several times to assure further key exchange between the devices.The initia liza tion key is not used beyond the first key exchange. Each communicatingdevice generates the initia liza tion key using a pseudo-random number generator seededwith a secret personal identification number (PIN) entered by the user of each device andthe value of RAND exchanged between the devices. In order for two communicatingpage25devices to generate the same value for the initialization key, the same PIN value musttherefore be entered on both devices.Based on the key generation and storage capabilities of each communicatingdevice the sem i-perm a nent shared link key can either be a unit key or a com bina tion keydepending on the key generation and storage capabilities of communicating devices. Theunit key is a device specific key that is generated during the initialization of each device.Its value changes rarely. It is generated using a pseudo-random number generator seededwith RAND and BD_ADDR (device address). The com bina tion key is a pairwise keycomputed by two communicating devices based on a device specific key generated byeach device. In order to compute a com bina tion key first each device generates a devicespecific key based on RAND and BD_ADDR, the resulting keys are then exchangedbetween the pair of devices using the secure channel encrypted with the initia liza tion key.The com bina tion key is then derived by each of the pair of devices based on a simplecombination of the two device specific keys.The type of the link key to be used on a pairwise connection between two communicatingdevices is negotiated during link establishment. If one of the devices has restrictedstorage then this device’s unit key is used as the pairwise link key, with obviousdrawbacks due to the widespread disclosure of a semi-permanent device specific key. Ifboth communicating devices have sufficient computing (key generation) and storagecapabilities then they choose to use a combination key as a pairwise link key that has adifferent value for each pair of entities.In a master-slave scenario, a short-lived link key called m a ster key can be used betweenthe master device and the slave devices. The lifetime of a m a ster key is limited to theduration of the master-slave session. The m a ster key is generated by the master deviceusing pseudo-random number generator seeded by RAND and PIN. The resulting key isdistributed through a channel secured under the initia liza tion key to each slave the masterwants to share the m a ster key with.The encryption key is generated by a pair of devices that share a link key using a pseudo-random number generator seeded by the link key, the random number RAND generatedby one of the devices and transmitted to the other device prior to encrypted dataexchange, and the secret Authenticated Ciphering Offset (ACO) generated by each deviceduring the authentication process.5.2.2 AuthenticationThe Bluetooth authentication scheme is based on a challenge-response protocol asdepicted in Figure 2. When device A wants to authenticate device B using this protocol,A generates a random number (RAND) and sends it to B as a challenge then both devicescompute a result (SRES) using the authentication algorithm E1 with RAND, the link key,and the device address of B. B then sends A SRES as the response to A’s challengeRAND. B is successfully authenticated if the result SRES’ computed by A matchesSRES. During authentication each device also obtains the Authenticated Ciphering Offset(ACO) generated by the authentication algorithm E1. The ACO value is further used togenerate the data encryption key that will be used between the pair of devices.page26Figure 2: Authentication of Device B by Device A5.2.2.1 Data EncryptionBluetooth devices can perform data encryption using a stream cipher based on LinearFeedback Shift Registers (LFSR). The stream cipher generates a key stream that is usedby the sender to encrypt the payload field of each packet using the one-time padtechnique (the ciphertext is obtained as a result of the bit-wise exclusive-or operationperformed on the payload and the key stream). The recipient of the packets decrypts theencrypted payload field of each packet by generating the key stream and combining itwith the encrypted payload fields based on the one-time technique. The stream cipher isinitialized by both communicating devices with the device address of the master device,the value of the shared encryption key and the clock of the master device. The streamcipher is resynchronized for each payload using the master’s clock, a new key stream isthus generated to encrypt each payload.5.2.2.2 Security EvaluationThe Bluetooth security architecture suffers from some weaknesses in the keymanagement scheme. The main concern is the weakness of the key generation process forthe initialization key. The initialization key is derived from a random number and a secretPIN whereby the only secret is the PIN. Due to limited capability of human memory thePIN typically is chosen as a number with at most 6 digits. A 6-digit secret can easily beretrieved by exhaustive search. Another exposure exists when a device’s unit key is usedas the link key. If a device’s unit key is used as the link key for the purpose of parallel orE1RANDBD_ADDRof Device BLink KeyE1BD_ADDRof Device BLink KeySRES’ ?= SRESACOACORANDSRESDevice A Device Bpage27subsequent communications between this device and several other devices, the secret unitkey of the device is disseminated to several devices that might include potential intruders.Various types of attacks ranging from the impersonation of the legitimate owner of theunit key to the decryption of encrypted traffic by intruders become feasible based on theknowledge of a device’s unit key by intruders.5.3 Relevance of Security Mechanisms in the Data LinkLayerWhile the relevance of security mechanisms implemented in the data link layer is oftenargued, this question deserves careful analysis in the light of requirements raised by thetwo different environments in which these mechanisms can be deployed:1. wireless extension of a wired infrastructure as the original target of 802.11 andBluetooth security mechanisms,2. wireless ad hoc networks with no infrastructure.In case of 1. the main requirement for data link layer security mechanisms is the need tocope with the lack of physical security on the wireless segments of the communicationinfrastructure. Data link layer security is then perfectly justified as a means of building a“wired equivalent” security as stated by the objectives of WEP. Data link layermechanisms like the ones provided by 802.11 and Bluetooth basically serve for accesscontrol and privacy enhancements to cope with the vulnerabilities of radiocommunication links. However, data link layer security performed at each hop cannotmeet the end-to-end security requirements of applications neither on wireless linksprotected by 802.11 or Bluetooth nor on physically protected wired links.In case of wireless ad hoc networks as defined in 2. there are two possible scenarios:· managed environments whereby the nodes of the ad hoc network are controlled by anorganization and can thus be trusted based on authentication,· open environments with no a priori organization among network nodes.The managed environment raises requirements similar to ones of 1..Data link layersecurity is justified in this case by the need to establish a trusted infrastructure based onlogical security means. If the integrity of higher layer functions implemented by thenodes of a managed environment can be assured (i.e. using tamper-proof hardware) thendata link layer security can even cover higher level security requirements raised by therouting protocol or the applications.Open environments on the other hand offer no trust among the nodes and acrosscommunication layers. In this case trust in higher layers like routing or applicationprotocols cannot be based on data link layer security mechanisms. The only relevant useof the latter appears to be ad hoc routing security proposals whereby the data link layersecurity can provide node-to-node authentication and data integrity as required by thepage28routing layer. Moreover the main impediment to the deployment of existing data linklayer security solutions (802.11 and Bluetooth) would be the lack of support forautomated key management which is mandatory in open environments whereby manualkey installation is not suitable.6. ConclusionsThe need for security mechanisms that cope with the threats that are specific tothe ad hoc environment has recently gained attention among the research community. Inorder to avoid the same problems that raised in wired networks like the Internet, securityhas to be taken into account at the early stages of the design of basic networkingmechanisms like the data link layer and the network layer protocols. Since the correctnetwork operation can be heavily jeopardized by threats that range from simple lack ofcooperation to routing message modification, ad hoc networks without a proper defenseagainst attacks that are specific to this new networking paradigm cannot exist.Current efforts carried out by the research community in order to support ad hocnetworks with practical security mechanisms have to cope with a challengingenvironment, were limitations on the battery life, the computational power and thestorage resources, not to mention the lack of any fixed infrastructures, make the design ofa security infrastructure very difficult.The security mechanisms presented in this chapter are a practical response tospecific problems that rise at a particular layer of the network stack. However, theproposed solutions only cover a subset of all possible threats and are difficult to integrateone with the other: as an example, the secure routing protocols analyzed in this chapterdo not cope with the lack of cooperation of the nodes of the network, and are notdesigned to incorporate a cooperation enforcement mechanism. An exhaustive securityinfrastructure has to consider a wide range of attacks and has to be made of easy-to-integrate components. Furthermore, security needs may vary accordingly to differentnetworking scenarios and the security mechanisms adopted to combat misbehaving orcompromised nodes have to be flexible enough to be used in different environments. Thedirection that has been taken by the research community in order to support ad hocnetworks with security mechanisms confirms this vision and the proposed solutions aregradually reaching a mature stage, making ad hoc networking a realistic alternative towireless and 3G networks.page297. Bibliography[1] P. Papadimitratos, Z. Haas, Secure Routing for Mobile Ad Hoc Networks, inproceedings of CNDS 2002.[2] Y-C Hu, A. Perrig, D. B. Johnson, Ariadne : A secure On-Demand Routing Protocolfor Ad Hoc Networks, in proceedings of MOBICOM 2002.[3] A. Perrig, R. Canetti, D. Song, J.D. Tygar, Efficient and secure source authenticationfor multicast, in proceedings of NDSS 2001.[4] A. Perrig, R. Canetti, J.D. Tygar, D. Song, Efficient authentication and signing ofmulticast streams over lossy channels, in IEEE Symposium on Security and Privacy,2000.[5] B. Dahill, B. N. Levine, E. Royer, C. Shields, ARAN: A secure Routing Protocol forAd Hoc Networks, UMass Tech Report 02-32, 2002.[6] Y-C Hu, D. B. Johnson, A. Perrig, SEAD: Secure Efficient Distance Vector Routingfor Mobile Wireless Ad Hoc Networks, in the Fourth IEEE Workshop on MobileComputing Systems and Applications.[7] C. E. Perkins, P. Bhagwat, Highly Dynamic Destination-Sequenced Distance-VectorRouting (DSDV) for Mobile Computers, in proceedings of SIGCOMM 1994.[8] J. Broch, D. A. Maltz, D. B. Johnson, Y-C Hu, J. G. Jetcheva, A performanceComparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols, in proceedingsof MOBICOM 1998.[9] P. Johansson, T. Larsson, N. Hedman, B. Mielczarek, M. Degermark, Scenario-basedPerformance Analysis of Routing Protocols for Mobile Ad Hoc Networks, in proceedingsof MOBICOM 1999.[10] A. Perrig, Y-C Hu, D. B. Johnson, Wormhole Protection in Wireless Ad HocNetworks, Technical Report TR01-384, Dep. Of Computer Science, Rice University.[11] P. Michiardi, R. Molva, Simulation-based Analysis of Security Exposures in MobileAd Hoc Networks, in proceedings of European Wireless Conference, 2002.[12] D. B. Johnson, D. A. Maltz, Dynamic Source Routing in Ad Hoc WirelessNetworks, Mobile Computing, edited by Tomasz Imielinski and Hank Korth, Chapter 5,pages 153-181, Kluwer Academic Publishers, 1996.[13] Charles Perkins, Ad hoc On Demand Distance Vector (AODV) Routing, Internetdraft, draft-ietf-manet-aodv-00.txt.page30[14] L. Buttyan, J.-P. Hubaux, Nuglets: a virtual currency to stimulate cooperation inself-organized ad hoc networks, Technical Report DSC/2001/001, Swiss Federal Instituteof Technology -- Lausanne, 2001.[15] S. Buchegger, J.-Y. Le Boudec, Nodes Bearing Grudges: Towards Routing Security,Fairness, and Robustness in Mobile Ad Hoc Networks, in proceedings of the 10thEuromicro Workshop on Parallel, Distributed and Network-based Processing.[16] S. Buchegger, J.-Y. Le Boudec, Performance Analysis of the CONFIDANTProtocol, in proceedings of MobiHoc 2002.[17] S. Marti, T. Giuli, K. Lai, and M. Baker, Mitigating routing misbehavior in mobilead hoc networks, in proceedings of MOBICOM 2000.[18] P. Michiardi, R. Molva, Core: A COllaborative REputation mechanism to enforcenode cooperation in Mobile Ad Hoc Networks, IFIP - Communication and MultimediaSecurity Conference 2002.[19] P. Michiardi, R. Molva, Game Theoretic Analysis of Security in Mobile Ad HocNetworks, Institut Eurecom Research Report RR-02-070 - April 2002.[20] H. Yang, X. Meng, S. Lu, Self-Organized Network-Layer Security in Mobile AdHoc Networks.[21] S. Capkun, L. Buttyan and J-P Hubaux, Self-Organized Public-Key Management forMobile Ad Hoc Networks, in ACM International Workshop on Wireless Security, WiSe2002.[22] P. Zimmermann, The Official PGP User’s Guide. MIT Press, 1995.[23] M. Reiter, S. Stybblebine, Authentication metric analysis and design, ACMTransactions on Information and System Security, 1999.[24] H. Luo, S. Lu, Ubiquitous and Robust Authenticaion Services for Ad Hoc WirelessNetworks, UCLA-CSD-TR-200030.[25] A. Shamir, How to share a secret, Communications of ACM 1979.[26] IEEE 802.11b-1999 Supplement to 802.11-1999,Wireless LAN MAC and PHYspecifications: Higher speed Physical Layer (PHY) extension in the 2.4 GHz band[27] “Specification of the Bluetooth System”, Bluetooth Special Interest Group, Version1.1, February 22, 2001,http://www.bluetooth.com/pdf/Bluetooth_11_Specifications_Book.pdfpage31[28] “Applied Cryptography”, Bruce Schneier, John Wiley & Sons, 1996[29] “Using the Fluhrer, Mantin, and Shamir Attack to Break WEP”, Stubblefield,Loannidis, and Rubin, AT&T Labs Technical Report 2001