Wireless transmissions utilize a shared medium – the air – that is virtually accessible to anybody at any time. As it is not possible to limit access to the medium, the only way to protect messages is to use cryptography to sign or encrypt the exchanged data.
The IEEE 802.11b standard includes a scheme called WEP (Wired Equivalent Privacy) to secure communications. It uses the RC4 stream cipher coupled to an Initialization Vector for encryption, and the CRC-32 checksum for integrity check. WEP employs a 40-bit or 64-bit secret shared key, providing no infrastructure for key management. As its name implies, WEP offers a protection similar to that of an unsecured wired network, and therefore a quite low level of security (the AirSnort program can easily crack WEP keys). Despite its weakness, WEP may be considered useful as a deterrent against casual snoopers.
The vulnerabilities of WEP have been fixed in WPA (Wi-Fi Protected Access). WPA uses IEEE 802.1X authentication, providing port-based network access control capability, with a standard EAP (Extensible Authentication Protocol) [15].
A stronger security system is specified in the IEEE 802.11i standard [74], also known as WPA2. The WPA2 standard adds the AES (Advanced Encryption Standard) security protocol to IEEE 802.11.
In general, the desired security for the routing mechanism concerns integrity (less often non-repudiation) and service availability. Therefore, when talking about protecting routing control messages, we mostly consider how to generate and verify digests or digital signatures. Encryption is often left aside, because is more time- and power-consuming, and because confidentiality is not usually required, as routing information is not secret. (However, this is not always true. In the case of military applications, routing information may be tactical information of primary importance; for instance, it could help enemies identify and locate their targets on a battlefield.)
The protection of the network can be obtained through cryptographic tools such as IPsec, or via dedicated solutions. In the literature there are many proposals for secured routing protocols that provide message integrity (through digests) and/or sender authentication (through signatures). Several of these are modifications of standard non-secure routing protocols. Other protocols provide security in a different way.
IPsec [87, 98] is an IETF standard that incorporates various security services for the IP layer. The IPsec framework provides authentication and encryption of data packets [85, 86], maintenance of security associations (with shared secret keys) between peers [105], and manual or automated key management [61].
It has been pointed out [137, 128] that, in general, it is impossible (or at least impractical) to use IPsec to secure routing protocols in MANETs, because IPsec assumes that a security association between pairs of nodes already exists; and, of course, this is not the case in an emerging ad hoc network. The fundamental problems of IPsec with respect to securing OLSR are detailed in the following.
First, the automated key exchange, which also provides the automated timestamp exchange for protection against replay attacks, assumes that the parties can reach each other. This is not the general case with the secured version of OLSR, because messages must be authenticated before being accepted; hence a node which arrives in the network accepts no packets, and has no routes. Two remedies are possible: either using pure flooding for the messages, or changing the OLSR specifications as we show in Section 6.3.7.
Second, IPsec protects the packet itself, while the granularity of the protection that we propose is the message. For technical reasons, it is not possible to sign or generate a digest of a whole OLSR packet, nor it is desirable to do so; see Chapter 5. One remedy could be to forbid any change of the packets in transit, so that each message would go in a different packet. This would have a certain cost on wireless networks, where overhead per-packet on the MAC layer is large in some cases. Furthermore, this might not be sufficient and other requirements, such as the use of tunnel mode, should be made, along with technical necessities such as using the TTL field of the IP packet instead of the OLSR packet.
Third, the current IPsec implementations support essentially symmetric keys. However this may change, as a recent IETF draft proposes asymmetric signatures [157].
Last, managing a group key or a set of group keys in the context of an ad hoc network is a different problem than just the issues in the multicast or group key management protocols such as GKMP (Group Key Management Protocol) [62] or MIKEY (Multimedia Internet KEYing) [5]. This because in an ad hoc network all nodes are senders and all nodes are receivers of the OLSR protocol messages. Network splits or merges also need to be managed.
In general, few IPsec security schemes may be used, and even these need significant modifications such as pure flooding for message transmission. This comes at the cost of security granularity and performance: for instance, in a network of n nodes, if each node creates and transmits a session key with every other node using pure flooding, the cost is O(n3). This would also be likely to result in using IPsec on the limits of their domain of applicability. It is also worth noting that the complexity of many IPsec protocols is already greater than the complexity of the OLSR protocol itself.
SRP (Secure Routing Protocol) [116], by Papadimitratos and Haas, is built on the basis of DSR, and requires a security association between each pair of communicating nodes. When initiating a route discovery, a node inserts in the SRP header of the query packet the following information: a sequence number, a nonce, and a MAC. The MAC is a keyed hash computed on the IP header, the sequence number, the nonce, and the shared secret key. In the route reply message, the MAC includes also the route.
Unfortunately, it has been observed that a security flaw makes SRP defective
[103]. In a route discovery, a malicious intermediate node may not append its
address to the route request and reply messages (as it is supposed to do). As a
consequence, the originator of the route discovery validates a route which in fact
does not exist.
SLSP (Secure Link State routing Protocol) [117], by the same authors of
SRP, is a proactive secure routing protocol that makes use of asymmetric
cryptography to protect control messages. The security mechanisms of SLSP are
committed to the Neighbor Lookup Protocol, which maintains a mapping of IP
and MAC (hardware) addresses extracted from overheard frames; the
protocol uses this mapping to identify discrepancies such as multiple
addresses.
SAODV (Secure Ad hoc On-demand Distance Vector routing) [164] is the
secured version of AODV. RREQ and RREP messages are signed by a sending
node, and the signature is verified by intermediate nodes before forwarding the
message. Optionally, the RREQ message bears a second signature which, if an
intermediate node wants to reply with a RREP, is utilized in the reverse
route.
ARAN (Authenticated Routing for Ad hoc Networks) [137] is an on-demand
routing protocol which requires a TTP certificate server. Nodes request a
certificate from the certificate server, then they sign all generated messages.
A polyvalent technique based on certificates [128] consists in appending a
module, called MAE (MANET Authentication Extension) to each routing
message. This technique uses threshold cryptography to provide a distributed and
self-organized certification service. The MAE protocol can be applied to DSR,
AODV, OLSR, TBRPF, and possibly other routing protocols.
Ariadne [66] is based on DSR for the routing architecture and on TESLA (Timed Efficient Stream Loss-tolerant Authentication) [125, 124] for the authentication mechanism. TESLA guarantees the integrity of communications by adding a MAC in each message, and provides some form of authentication by one-way key chains (also called one-way hash chains), computed by agreeing on a hash function h. A node, during initialization, chooses a random number x and computes the list of values h0,h1,h2,…,hn, where h0 = x, and hi = h(hi-1) for i ≤ n. The node will afterwards publish these keys in reverse order from hn to h0, following a predetermined schedule. Before sending a message, the sender node estimates an upper bound Tu on the end-to-end network delay, and computes the MAC on the message with a key hi which will not be disclosed until after the delay. Upon reception of the message, the receiver node verifies that the key hi is still secret, then waits until hi is disclosed by the sender. After that, the receiver node authenticates hi. The receiver node is also able to authenticate a value hi-1 contained in a further message by verifying that h(hi-1) = hi, or authenticate any hi-j by applying j times the hash function i.e. hj(hi-j) = hi.
Ariadne uses symmetric encryption for efficiency reasons, but its authors
also provide a modification to include a Key Distribution Center for key
authentication. In Ariadne, a node originating a route discovery broadcasts a
Route Request message, containing a time interval greater than Tu and protected
with a MAC. Each intermediate node that receives the Route Request verifies if
the associated key is still undisclosed according to the time interval; if so, the
node appends its MAC to the message and forwards it. The target node performs
the same tests, then sends a Route Reply to the originator node via the reverse
path. Every intermediate node that receives the Route Reply waits until it
can disclose its key according to the time interval, then appends its key
to the message and forwards it. Finally, upon reception of the Route
Reply, the originator node checks that all included keys and MACs are
valid.
TIK (TESLA with Instant Key disclosure) [67] is a protocol designed for defense against wormhole attacks. TIK uses what its authors call a packet leash, i.e. a piece of information added to a packet to restrict the packet’s maximum allowed transmission distance (geographical leash) or lifetime (temporal leash). All nodes must have tightly synchronized clocks. Key authentication is accomplished using hash trees, which are an optimization of the one-way hash chains discussed above.
A sender node S generates the MAC, denoted by H(M,ki), of a message M
using key ki. Key ki has disclosure time ti (in the future) and can be
authenticated by the hash tree value hi. The MAC is included in the header part
of the packet. Before sending the packet, S estimates an upper bound on the
arrival time of the packet to the receiver node R, and appends the key ki to
the packet: S → R : {H(M,ki),M,hi,ki}. Upon arrival of the MAC, R
verifies that S has not yet started to send ki, based on the disclosure
time ti. If this is true, R authenticates the key ki using hi, and verifies
H(M,ki).
SEAD (Secure Efficient Ad hoc Distance vector routing) [65] is based on the design of DSDV. Nodes authenticate with each other by using hash chains. A node chooses a random number x and computes h0,h1,h2,…,hn, where h0 = x, and hi = h(hi-1) for i ≤ n as said before. The value hn is firstly distributed either by a Certification Authority, or by direct exchange (using symmetric cryptography) between nodes, or by any other infrastructure for key distribution. Afterwards, the node includes these values in its messages, one for each message, and in reverse order from hn-1 to h0. Receiving nodes , knowing hi, authenticate the value hi-1 contained in a further message by verifying that h(hi-1) = hi. With this protocol it is still possible for an attacker to tamper with messages while they are in transit.
Hu et al. propose RAP (Rushing Attack Prevention) [68], a generic component for secure route discovery in reactive routing protocols. RAP is aimed at protecting the network against rushing attacks. RAP contains three mechanisms: secure neighbor detection, secure route delegation, and randomized Route Request forwarding.
Secure neighbor detection is accomplished by observing the challenge-response delay, to evaluate the distance to a node and verify if the node can be a neighbor. Secure route delegation is done through exchange of Route Delegation / Accept Delegation messages between verified neighbors, before any forwarding of a Route Request. Furthermore, instead of forwarding the first received Route Request, a node collects a number of Route Requests and then randomly chooses the one to be forwarded.
RAP uses HORS [133] and the constructions of BiBa [123] as a fast one-time
signature mechanism. HORS, designed by Reyzin and Reyzin as an improvement
on BiBa, is a one-time signature scheme i.e. a signature scheme that can be used
once or a small number of times. The characteristics of HORS are a short
signature and very fast signature and verification, hence its suitability for
multicast and broadcast authentication.
SAR (Security-Aware ad hoc Routing) [163] is a modification of a
traditional, non-secured route discovery protocol (like AODV, DSR, or
ZRP) to include the security level of a node into routing metrics. The
nodes are organized in a trust hierarchy; a number is associated with each
privilege level and represents the security/importance/capability of a node.
RREQ and RREP packets are encrypted, and a cryptographic key is
assigned to each level; this can be obtained by setting the key length so
that it is proportional to the requested level of security. In this manner,
packets are routed only through safe nodes; nodes without the required
security rank cannot even read the control packets and must therefore drop
them.
Lee et al. [96] suggest securing DSR by adding two new control messages: Route Confirmation Request (CREQ) and Route Confirmation Reply (CREP). These messages are used as a confirmation in the RREQ/RREP route discovery mechanism.
When an intermediate node replies with a RREP, the protocol requires that it sends a CREQ to its next-hop node towards the destination. Then the next-hop node, if it has a route to the destination in its cache, replies with a CREP to the source of the RREQ. Hence, the source node can verify the validity of the obtained route by comparing the RREP with the CREP.
This mechanism does not use cryptography, and consequently is still
vulnerable to message tampering and identity spoofing.
Buttyán and Hubaux propose two mechanisms to improve service availability on an open network. Packet forwarding consumes the battery energy of a node; therefore, a node may be tampered with, or simply switched off, by its participating user so as not to provide this service.
The first mechanism [21] introduces an abstract currency called beans. This currency is paid by the originator of a packet to the forwarding nodes for the forwarding service (Packet Purse Model), or exchanged for a packet which will be sold to the next hop for a higher price (Packet Trade Model). The motivation of nodes to earn stimulates cooperation and avoids node selfishness. A PKI is used to guarantee authentication and establish secure communications.
In the second mechanism [22] a tamper resistant security module, embedded
in each node, maintains a nuglet counter which is decreased when the node
originates a packet and increased when the node forwards a packet. A node’s
cooperation is ensured by requiring that the value of the counter must remain
positive.
Privacy is often not of primary importance in routing, and secured routing protocols are more focused on providing other security goals; for this reason it is worth mentioning the PPR (Privacy Preserving Routing) protocol [154], which is aimed at protecting nodes’ identities.
Among the security solutions examined up to now, only a few could be applied or adapted to OLSR. For instance, SAODV is based on AODV and is aimed at protecting the route discovery mechanism, which in a proactive routing protocol such as OLSR would not make sense. The purpose of TIK is primarily to provide defense against the wormhole attack; furthermore, this protocol requires a tight synchronization between nodes, which is not easy to obtain in an ad hoc environment. The MAE architecture can be applied to OLSR, as well as to other routing protocols; however, our aim is to find a dedicated security architecture that can be interfaced with the functioning of OLSR so that the OLSR mechanisms are fully exploited. For instance, a clever use of the OLSR Duplicate Set can permit a loose synchronization: we illustrate this in our security solution for OLSR, discussed in Chapter 5.
In this section we give an overview of other security solutions explicitly designed for OLSR, as found in the literature.
Secure OLSR [60], a proposed technique for securing OLSR, involves protection and hop-by-hop check of a whole packet. A digest is computed by the forwarder node, added to the OLSR packet, and verified by the next-hop node. This allows the digest to encompass mutable fields such as the Time To Live or the Hop Count. The digest is added in the form of a control message, and includes a timestamp. The algorithm used to digest the packet is SHA-1 with a secret shared key. Time synchronization is done through a challenge-response mechanism, via dedicated control messages.
SOLSR [64] protects the traffic by adding a packet signature, while using hash chains to secure the Time To Live and Hop Count mutable fields. It also implements a defense against the wormhole attack. A node sends probe packets to measure their travel time, from which it can compute the travel distance. Then the node evaluates this distance: if it is greater than the transmission range, the message may have been tunneled through a wormhole.
There is a recent proposal of a secured OLSR protocol [78] that uses both symmetric and asymmetric keys. Nodes mutually authenticate using public key cryptography, performing re-authentication when moving to another neighborhood. During the authentication, nodes share two symmetric keys: a circle key, utilized among neighbors only, and an ad hoc key, utilized in the whole network. A MAC is computed with the circle key and added to control messages to ensure message integrity. Nodes periodically renew both keys, and the new key is distributed after being encrypted with the old key; for this purpose, the new ad hoc key is included in TC messages.
Winjum et al. [159, 160] propose an extension for OLSR that uses Trust Metric
Routing. The concept of Trust Metric Routing is to divide the network
into different security domains, where only nodes belonging to the same
domain share intra-domain security parameters like keys and such. A user
may choose to route packets through trustworthy routes, which are fully
contained in the same domain, or ordinary routes, which spread over
multiple domains. To this end, two routing tables are maintained by each
node: an ordinary routing table calculated with the standard shortest
path algorithm, and a trustworthy routing table calculated using trust
parameters and showing only intra-domain routes. The information about
the trust level of a link or route is integrated and exchanged in control
messages.