[Olsr-dev] "Secure" Mesh networks

[John Barrett]

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 
other.