[Olsr-users] Network address associated with fingerprint of the node's public key?

[Henning Rogge]

On 02/28/2012 12:24 PM, Wojciech Zabolotny wrote:
> Hi,
>
> I've experimented a little with spontaneously created mesh networks
> based on olsr protocol.
> The idea was, that the net is totally open, without any management
> nodes (so the network should survive as long as sufficient amount
> of users is on-line, creating the mesh).
> Therefore it was also not possible to provide any DHCP server.
> Everyone could connect selecting any free IP belonging to the pool of
> the addresses belonging to the network.
Maybe a distributed address distribution could help. Or just switch to 
IPv6 and choose your IP based on the MAC address of your WLAN card (or 
just with a random suffix).

> Unfortunately, such simplistic scheme is not immune against IP
> conflicts (either occuring due to random selection of IP, or caused
 > by malicious intruders trying to destroy the network).
The random collision could be solved by moving to IPv6. Choosing 
randomly out of a pool of 2^64 addresses should be enough (assuming the 
network just use a /64 prefix).

> The network could be protected, if the IP address could be associated
> with the public key of the node (e.g. it could be based on fingerprint
> of this key).
Hmm...

 > In this case the intruder could not spoof the particular node, unless
> he has the secret key associated with public key matching that IP.
> When maintaining the network, nodes should check, that  the node
> claiming to have particular IP really has the key pair matching
> it (by sending challenge encrypted with the public key, and
> requesting the response).

This doesn't solve the spoofing problem, unless you
a) send a challenge for every packet your receive (and base the 
challenge on the packet)
or
b) the sender puts a signature into each packet.

For point-2-point traffic this is a little bit easier, source and 
destination can just use their public/private keys to agree on a common 
session key and use it to encrypt and authenticate their data stream 
(see IPsec).

Public/Private key operations are quite expensive in terms of cpu power 
and storage space (in network packets).

The other problem associated with public/private key pairs is that you 
have to know which one is valid.

> Of course it could be difficult to add such mechanism to the IP4 based
> network (as with less than 2^32 possible IP numbers it could could be
> possible to generate key matching any selected IP - even though
> it should be time consuming), but in IPv6 it should be doable.
> I don't know if this idea is new, neither if it is possible to
> implement in reasonable way, but it seems interesting...

I would suggest NOT following this idea, stay with established 
cryptographic algorithms and protocols. Its very easy to build "crypto 
protocols" that look interesting but are insecure. Do not invent the 
wheel again, try to use the proven wheels others have already looked at 
and see if they can solve your problem.

For your idea to be feasible each node has to have the algorithm to 
generate the private key for each IP, because otherwise it cannot join 
the network!

And if a valid node can do it, how do you want to prevent the attacker 
from doing it?

Even if you go the way of "choose secret, IP is hashvalue of secret", 
you face the problem of "trust/not trust" an incoming packet. If you 
don't sign every packet (which is A LOT of overhead), you still don't 
know if the packet is from a valid node until you send the challenge and 
got the response.

If you are still interested in designing a 'secure' mesh, I will be 
happy to continue to discuss it with you.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6156 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20120228/496f0fc3/attachment.bin>