[Olsr-dev] "Secure" Mesh networks

John Barrett (spam-protected)
Tue Feb 9 08:59:12 CET 2010

Roar Bjørgum Rotvik wrote:
> Henning Rogge wrote:
>> On Tue February 9 2010 01:16:14 John Barrett wrote:
>>> OK -- just looked over that code -- and its getting close :)
>>> I think I have everything in place to flash a couple of routers -- I'll
>>> make sure I get the secure module in the build and see if it still works
>>> as is, then probably base my work off that code :)
>> Just a warning about the "secure" plugin. The only thing it does it to use a 
>> shared secret to calculate a hash value and put it into each packet (plus a 
>> timestamp against replay attacks). You can get more security by just 
>> encrypting your Layer 2 with a symmetric key (not WEP because it's broken).
> Hi all,
> As one of the persons that designed the "secure" plugin, I must point out that the purpose 
> of the "secure" plugin is not to encrypt data traffic or routing traffic.
> It's only purpose is to be a simple addon to olsrd that may protect the routing traffic 
> from "unwanted" nodes, i.e. only nodes with the correct group key is allowed to 
> participate in the mesh network. Simple, lightweight (I admit we did not test this on 
> embedded devices), works with olsrd without changing message format or internal code in olsrd.
> Regarding the distribution of the shared key; We also designed a system for establishing 
> trust and sharing the shared key to new nodes as long as they are trusted by one of the 
> nodes already part of the "secure" network. This solution was meant to establish a shared 
> key before starting up olsrd with the secure plugin using this shared key.
> I did not work on this part and does not remember all the details from my head, sorry.
I'm not looking to add any more encryption than necessary, but I am 
looking for something more secure than a shared key.  WPA already gives 
us that much, and most likely, if the WPA key is compromised, then the 
shared key will also be compromised (someone steals a router and reads 
out the data with a jtag cable for instance). What I'm looking at with 
certificates and TLS is providing a means of blocking out a single 
compromised node if needed (by updating the certificate revocation 
list), with just a little more overhead than the current secure plugin, 
and that overhead mostly at "startup" when 2 nodes become aware of each 

More information about the Olsr-dev mailing list