Mukesh Singhal
WIRELESS NETWORK SECURITY 149 can authenticate subsequent elements, k i, i > j , from a nodes hash chain by using the
equationkj =Hi−j(ki). However, other nodes cannot generatekidue to the one-way property of the hash function.
For broadcast authentication using TESLA, a node generates a broadcast packet, adds a Message Authentication Code (MAC) of the packet generated by the node using its future (next in its schedule) TESLA key and then releases the key used in MAC at a later time. A node receiving the packet verifies the TESLAsecurity conditionthat the keykiused to authenticate the packet has not yet been released by the nodes2. If the condition holds, then the receiving node waits for the TESLA key to be released by the sender and verifies the key (using the one-way hash function) and the MAC of the packet. If they are authentic, then the receiver accepts the packet, else it drops the packet.
The Protocol: Ariadne protocol assumes that the source and the destination share a secret keyKST that allows them to authenticate each other. To establish a secure route to the destination, the source node floods a RREQ packet that has eight fields<ROUTE REQUEST, initiator, target, id, time interval, hash chain, node list, MAC list>. The initiator and the target are set to the source ID and the destination ID, respectively. The ‘id’ is an identifier that has not been recently used in route discovery. The ‘time interval’ is set to TESLA time interval at the pessimistic arrival time of the request at the target, with maximum possible clock offset/skew and maximum transmission delay. The hash chain field is initialized by the initiator to the MAC calculated over initiator, target, id, time interval, using the keyKST (M ACKST(initiator, target, id, time interval)). The
node list and MAC list are empty initially and will be filled by the intermediate and target nodes.
When an intermediate node,A, receives a RREQ, the node checks its local table for the (initiator, id) entry. If it finds an entry for the same route discovery, it discards the RREQ, else the node verifies the time interval of the RREQ. If the time interval is too much in the future or the key corresponding to it has been disclosed, the RREQ is discarded. Otherwise, the node appends its address to the node list in the RREQ packet, and replaces the hash chain field withH(A, oldhashchain). The node then appends a MAC of the entire request to the MAC list, where the MAC is calculated using key
ki corresponding to the time interval in the RREQ. The node then rebroadcasts the modified RREQ.
When the destination node receives the RREQ, it determines whether the keys corresponding to the time interval mentioned in the RREQ have not been disclosed yet, and the hash chain field is equal to
H(In, H(In−1, H(· · ·, H(I1, M ACKST(initiator, target, id, time interval))· · ·))),
whereIiis the intermediate node at positioniandnis the number of nodes in the node list. If both the conditions hold, then the destination is assured that the RREQ is valid, and it constructs a RREP packet.
150 VENKATA C. GIRUKA and MUKESH SINGHAL The RREP packet consists of target, initiator, time interval, node list, MAC list (which correspond to fields from the corresponding RREQ), target MAC and key list. Target MAC is a MAC calculated by the destination over first five fields with the key
KST. Key list is left empty to be initialized by the intermediate nodes, along the reverse route in the RREQ. The destination sends the RREP to the initiator along the source route which is the reverse of the sequence of hops in the node list in the RREQ. The node forwarding the route RREP waits until it is able to disclose the key for the specified time interval. The node then appends the key to the key list field in the RREP and forwards the RREP to the next hop towards the source. The waiting delays do not add significant computation overhead but adds to storage overheads. When the initiator receives the RREP, it checks if the keys in the key list are valid, target MAC is valid and each MAC in the MAC list is valid. If all these are valid only then will it accept the RREP.
One-way hash chain in RREQ/RREP ensures that no hop is omitted by some malicious node. To change or remove a previous hop form the RREQ/RREP, the attacker must be able to invert the one-way hash function, which is computationally infeasible. However, a malicious node might succeed in removing the address of any previous node from the node list, but won’t be able to remove that node’s address from the hash chain field. Such a fabrication would be easily detected by the destination/source, since the computed hash chain field won’t be the same as the hash chain in the received packet and hence the RREQ/RREP would be discarded.
When an intermediate node detects a route break, i.e., it is unable to deliver the packet to the next hop after a fixed finite number of retransmissions, it generates a route error RERR and sends it to the source node. To deal with false RERR messages, the protocol requires the source to authenticate the RERR messages using TESLA. If the authentication succeeds, then the source tries to reestablish a route to the destina- tion, else it drops the RERR. However, the protocol does not guard against attackers intentionally dropping genuine RERR messages.
4.4. ARAN
Authenticated Routing for Ad-hoc Networks (ARAN) [24] detects and protects against malicious actions by third parties and peers in an ad-hoc environment. ARAN assumes a managed-open environment, meaning that there is an opportunity for pre- deployment of certain security infrastructure. Using such an infrastructure helps nodes exchange initialization parameters before hand through a trusted third party like a certification authority. With the help of initialization parameters, like a certificate from a trusted server, ARAN provides authentication, message integrity, and non-repudiation in an ad-hoc environment. Table 1 presents the notations used in the rest of this section. ARAN protocol assumes a trusted certification server T, whose public key is known to all the valid nodes in the networks. The protocol consists of three stages, the prelim- inary certification stage, the authenticated route discovery phase, and the authenticated route setup phase. In the preliminary certification stage, each node obtains a certificate,
certA, from the server T. The certificate of a node,certA = [IPA, KA+, t, e]KT−, contains the IP address of A, the public key of A, a timestamp t of the time the certifi-
WIRELESS NETWORK SECURITY 151
Table 1.Notations used in ARAN KA+ Public-key of node A. KA− Private-key of node A.
{d}KA+ Encryption of data d with keyKA+.
{d}KA− Data d digitally signed by node A
certA Certificate belonging to node A. Na Nonce issued by node A.
IPA IP address of node A.
RDP Route Discovery Packet identifier. REP REPly packet identifier.
ERR ERRor packet identifier.
cate was generated by the server, and a time e at which the certificate expires. These variables are concatenated and signed by the server. Nodes maintain a fresh certificate issued to them by the trusted server, which helps them authenticate themselves to the other nodes during the exchange of control messages.
The authenticated route discovery phase provides end-to-end authentication, in which the source node verifies that the intended destination is reached. The source node, A, initiates a route discovery for the destination X, by broadcasting a route dis- covery packet (RDP). The broadcast message,[RDP, IPX, NA]KA−, certA, includes
a packet type identifier (RDP), the IP address of the destination (IPX), A’s certificate (certA), and a monotonically increasing nonceNA, the all signed with A’s private key.
Upon receiving an RDP packet, an intermediate node stores(IPA, NA)of the RDP
packet. If an intermediate node has already seen the(IPA, NA)tuple, it drops the RDP
packet. Otherwise, it keeps track of the predecessor node from which it received the RDP packet, validates the signature with the given certificate, removes A’s certificate from the RDP, and rebroadcasts the RDP packet by signing it. For instance, if B is a neighbor of A, then B broadcasts
[[RDP, IPX, NA]KA−]KB−, certA, certB.
Such message signing prevents spoofing attacks that may alter the route or form loops. When node C receives the broadcast packet, C validates signatures of A and B using their respective certificates in the RDP packet. C removes B’s signature and certificate, records B as its predecessor node, signs the contents[[RDP, IPX, NA]KA−]with its
private key and appends its own certificate, and broadcasts the RDP.
152 VENKATA C. GIRUKA and MUKESH SINGHAL Each intermediate node repeats the same process as node C, and eventually the desti- nation receives the RDP packet.
The destination replies to the first RDP packet it receives. Note that such an RDP packet may not have traversed the shortest path due to network congestion, or due to the presence of malicious nodes. The rationale behind choosing such a path is to prefer them over a congested least-hop path that reduces the end-to-end delay. As a response to the RDP, the destination generate a Reply packet (REP), and unicasts it along the reverse path to the source node. If D is the next node towards the source from the destination X, then X unicasts a REP ([REP, IPA, NA]KX−, certX) packet to D, where REP in the packet is a packet-type identifier. Since nodes keep track of predecessor nodes during the RDP phase, an intermediate node forwards the REP to the predecessor. Each intermediate node along the reverse path signs the REP and appends its own certificate before forwarding the REP. For instance, if C is be the predecessor of D, then D unicasts
[[REP, IPA, NA]KX−]KD−, certX, certD.
to C. Node C validates D’s signature on the received message, removes the signature and certificate, then signs the contents of the message and appends its own certificate before unicasting the REP to its predecessor. This avoids impersonation and replay of the message sent by X. When the source receives the REP, it verifies the destination’s signature and the nonce returned by the destination. If they are valid, then it starts transmitting the date along the established path.
Route maintenance: In ad-hoc networks, routes may not be used actively by the source node for a long time or they may break due to the node mobility. In ARAN, nodes purge route table entries that are not used by the source-destination for a predetermined time period (route’s lifetime). An intermediate node generates an error message (ERR) if there is no active route towards the destination in its route table, or if the node finds a link break due to node mobility. If a node B finds a route break, then it generates and sends a ERR ([ERR, IPA, IPX, NB]KB−, certB,) message to its predecessor node C. The
ERR message is forwarded along the path towards the source without modification. The nonceNBensures the ERR message is fresh. Because messages are signed, malicious
nodes cannot generate ERR messages for other nodes. Non-repudiation provided by the signed ERR message allows a node to be verified as the source of each ERR message that it sends. A node which transmits a large number of ERR messages, whether the ERR messages are valid or fabricated, should be avoided.
Key revocation: ARAN attempts a best effort key revocation that is backed with limited time certificates. In the event of a certificate revocation, the trusted certificate server, T, sends a broadcast message ([revoke, CertR]KT−) to the ad-hoc group that announces the revocation. Any node receiving this message re-broadcasts it and stores the message until the revoked certificate expires normally. Neighbors of the node with the revoked certificate need to reform routes as necessary to avoid transmission through such nodes.
WIRELESS NETWORK SECURITY 153