[Olsr-dev] "Secure" Mesh networks
Sven-Ola Tuecke
(spam-protected)
Tue Feb 9 10:32:05 CET 2010
Hey,
you still gave no good answer to the question "what do you want to secure?"
IMO.
* Prevent access to the radio/spectrum? That's impossbile. Everyone can use
it. Simply use other BSSID.
* Prevent third party from evasdropping? I would think it's sufficient to grab
a hardware node and reverse-engineer.
* Prevent untrusted node from inserting bogus routing data? Iptables will do
the job - as an alternative the olsr-secure plugin can be used (but iptables
is superior IMO)
* Protect your valuable resources (aka. Internet Gatway, couple of
live-porn-webcams etc): use openvpn or similar. Sell keys to the customers.
* You don't what to be visible as "please join" type of net: simply do not
send ESSID or do not answer DHCP requests.
There are enough techniques to secure data communication in unfriendly network
environments. Ask you favorite chinese dissident on that. Any encryption
technology will fail - besides really sophisticated stuff not possible with
cheap retail hardware from next supermarket. Or at least has disadvantages /
alternatives. On the other hand: beeing hospitable and invite other to extend
you network has advantages.
Note: if you have installed a protected mesh in my neighourhood, and I want to
join: I would simply install an analog Babycam with a strong directional
antenna sending a picture "let me in, tel: 1234" and waiit a couple of weeks.
// Sven-Ola
Am Dienstag 09 Februar 2010 08:59:12 schrieb John Barrett:
> 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.
More information about the Olsr-dev
mailing list