WIRELESS NETWORK SECURITY 95 Route discovery

Here, we want to secure a DSR-like reactive ad hoc routing protocol [29] with identity-based key management. It is feasible to secure other routing protocols with the designed security procedures [30, 31]. In DSR, when a peeriwants to send a message

mto another peerkand has no known routes tokin its route cache,iinitiates a route discovery procedure by broadcasting a route request message RREQ{idk, rn, idi} with the identities ofiandk, and a sequence numberrnto suppress broadcast loops. If a neighboring peerjhas a valid route tokin its cache (e.g.,{j+ 1,· · ·, k−1, k}),j

can respond a route reply messageRREP{idk, rn, idi, idj, idj+1,· · · , idk}toiwith its identityidj and the cached route; otherwise,j appendsidjtoi’s request message and broadcasts the updatedRREQ{idk, rn, idi, idj}. This process is recursive, until the request message reachesk, where a route reply message will be generated and sent back toiby reversing the forward path. Withrn, peers never react on duplicated or outdated routing messages, but can learn from bypassed messages.

Obviously, DSR-like routing schemes rely on voluntary peer collaborations, and are highly vulnerable to false routing information corrupted or injected by malicious peers. To fight against these attacks, routing messages should be authenticated by their initiators and verified by their recipients. First,iauthenticates its routing request message with its private keypki, which is verifiable by all other peers knowingidi’s identity. Similar procedures are required for peers that forward the appended request message. When a routing reply message is generated byj or k, the initiator should also authenticate itself and the route information. Finally, whenireceives the reply message, the authenticity of peers (e.g.,jandk) among the discovered route is verified by their identities (idjandidk). The BLS-IBS-based routing request message arriving atkthen has the format

RREQ{{{idk, rn, idi}pki, idj}pkj,··, idk₋1}pk

k−1, (6)

where{·}pkj implies that the message has been authenticated byj’s private-keypkj,

and is verifiable byj’s identityidj. En-route peer identity has to appear in routing messages no matter whether systems are powered by IBC. The construction in (6) is similar to that with a regular PKC; however, with IBC, there is no need to obtain the public-key of a peer to verify its messages, which is very attractive for wireless ad hoc networks. The routing reply message generated bykand arriving atihas the format

RREP{{{idk, rn, idi}pki, idj}pkj,· · ·, idk}_pkk. (7) If the reply message is generated byjaccording to its route cache, it has the following format instead

RREP{{idk, rn, idi}pki, idj, idj+1,· · · , idk}pkj. (8)

With (7) and (8),ican tell whether a route tokis actually certified bykor just endorsed byj. Hence, no peer can corrupt a relayed routing message without altering message authenticity or revealing its identity.

96 JIANPING PAN, et al. In the above route discovery procedure, all involved peers have authenticated them- selves, so the discovered route is cacheable by all peers, which can reduce the commu- nication cost if these peers also want to obtain the route tokor other downstream peers. However, this procedure requires every en-route peer to sign the hash of the appended request message, which may impose a non-negligible computing overhead in dense ad hoc networks. An alternative is to have all en-route peers authenticate themselves only to the request initiatori, by using a keyed hash of the appended request message with the pairwise shared-key derived from their private-key andi’s identity. Accordingly, (6) can be redefined in the following format

RREQ{{{idk, rn, idi}pki, idj}ski,j,· · · }_ski,k−1, (9)

where{·}ski,j implies that the message is protected by an HMAC with the shared-key

ski,jdefined by (5). Similarly, (7) then is redefined in the following format

RREP{{{idk, rn, idi}pki, idj}ski,j,··, idk}ski,k. (10)

By doing so, onlyican verify the authenticity of all peers that appear in the discovered route, which suggests that the route is not cacheable by peers other thani, unless they have already established trustworthiness with downstream peers. These peers have to initiate their own route discovery if necessary, although some heuristics can help them verify route validity (e.g.,iandkexchange data packets successfully after route discovery).

Route Maintenance

Another procedure in DSR is route maintenance. If a peer finds that a route is broken, it notifies the source peer with a route error message, and the source peer initiates another route discovery if there are no alternative routes in its route cache. Apparently, a malicious peer can abuse error report messages and mount DoS attacks. Therefore, report messages should be authenticated by the report initiator with its private-key and be verifiable for everyone knowing its identity (which is included in the message, along with the sequence number and the reversed forward path). The route error message generated byjhas the format

RERR{idk, rn, idi,· · ·, idj−1, idj}pkj, (11)

or alternatively with HMAC,

RERR{idk, rn, idi,· · · , idj−1, idj}ski,j. (12)

The source peer and other upstream peers should verify the authenticity and integrity of the message, and update their route cache accordingly. Again, the reporting peer has to trade off computing and communication overhead, by choosing either to sign

WIRELESS NETWORK SECURITY 97