Secure OLSR

In this section a solution that utilizes signatures to ensure integrity of OLSR control-traffic data is presented. A digest of the packet and a secret shared key is attached to all OLSR packets. Only a node with access to the secret key can produce such a signature.

In the implemented solution, all OLSR control traffic is signed for every hop. This means that one does not have to consider variable fields, such as hop-count and TTL, in messages. It also means that only one signature is needed although several OLSR messages are stacked in one OLSR packet. This hop-by-hop approach does not provide end-to-end signatures, which again means that the digest is not a true signature with respect to the originator, but rather a signature from the forwarder ensuring us that it trusts the source of the message in the previous hop. However, secure OLSR is designed to be as flexible as possible with regards to the encryption and hashing algorithms being used and the entire signature scheme.

The scheme and algorithms fields in the signature message header(figure 11.3) informs the receiver of what signature scheme and what algorithms are being used. In the implemented solution presented here, signatures created using the SHA-1[31] hashing algorithm are utilized to verify entire OLSR packets. A different scheme could include one signature for each OLSR message allowing for end-to-end signing. The signature message would then contain one signature for every OLSR-message in the OLSR-packet. One can also imagine that asynchronous or synchronous encryption could be used to ensure confidentiality by encrypting all data. These schemes could again utilize different algorithms for hashing and encryption, all being defined by the signature message header.

In the implemented solution, a node that does not have access to the shared secret key cannot produce a verifiable digest. Messages with non-verifiable digests are discarded by all receivers running secure OLSR. To prevent replay attacks secure OLSR uses timestamps. To exchange these timestamps, a two way timestamp exchange mechanism is utilized upon initial connection between two nodes. Signatures are transmitted in OLSR messages of their own. This is to ensure compatibility with nodes not running secure OLSR. Four different messages are defined. One which is the actual signature message as displayed in figure 11.3 and three messages used in timestamp exchange illustrated in figures 11.4, 11.5 and 11.6.

Figure: The basic signature message as used in the implementation. This is sent as the message body of an olsr message.

Figure: The timestamp exchange challenge message. This is sent as the message body of an olsr message.

Figure: The timestamp exchange challenge-response message. This is sent as the message body of an olsr message.

Figure: The timestamp exchange response-response message. This is sent as the message body of an olsr message.