[Olsr-dev] "Secure" Mesh networks
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