[Commotion-dev] Whether to use encrypted meshing, how to accept new nodes?

[Daniel Golle]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jeremy,
Hi Ben,


On 12/07/2012 02:23 AM, Jeremy Lakeman wrote:
> On Fri, Dec 7, 2012 at 9:17 AM, Ben West <ben at gowasabi.net> wrote:
[...]
>> WPA2 encryption, while certainly better than no encryption, can still be 
>> broken readily w/o the users of the network knowing about it. 
>> Realistically, WPA2 encryption can deter casual snooping or routing 
>> interference, but it should not be considered robust. The decision to
>> use WPA2 encrypted meshing should likewise include the decision to use a
>> PSK key of maximum possible entropy (e.g. 63 random chars), and a mutual 
>> policy to change the key periodically on all nodes. Any wireless 
>> transmission of sensitive info to or from a remote node, whether or not 
>> the mesh uses WPA2 encryption, should itself be thru an SSH/SSL/VPN 
>> tunnel.  By 'sensitive' I understand firmware images, config data 
>> including PSK or OLSR keys, passwords, users' MAC addresses, etc.

I agree, sensitive payload should always use endpoint-to-endpoint
authentication and encryption using SSH/SSL/VPN/...

Let's take the problem we are facing apart. WPA2 inherited the claim for "Wire
Equivalent Privacy" which tries to solve authentication, access control and
transport security, but yet doesn't consider multi-hop scenarios. Even RSN
(WPA2 in Ad-Hoc and mesh) still relies on a commonly shared secret and you
correctly pointed out that those shared secrets (OLSR-security key and
WPA2-PSK passphrase) should be changed every once in a while.
And yes, just to mention it, there is http://sourceforge.net/projects/authsae/
for secure 802.11s which targets *only* 802.11 which also needs a single
shared secret which is used for both, transport encryption and securing the
routing information. (anyway, for those who forgot: we can use OLSR on all
types of physical media, and yes, wpa_supplicant can also be used for 802.1X
authentication in case you don't trust your wire; PNA also uses a AES key;
LiFi security is waiting to be invented)
The trust graph in a distributed infrastructure can change all the time, which
leads to the problem of having to change those shared secrets at least every
time a node is baned from the network (and preferably more often).

I know at least one (ancient) application which faces a similar challenge:
encryption-schemes in DVB for Pay-TV (the lack of 2-way communication is the
main difference, but has the side-effect of being a useful paradigm to solve
the problem). A shared symmetric session-key used to encrypt the payload needs
to be changed as often as possible and somehow all legitimate subscribers need
to get hold of the to-be-used-next key in-time. This is implemented using
public-key cryptography. The TV-station basically transmits the
to-be-used-next key as many times as they got subscribers, each transmission
being encrypted for the individual subscriber's private-key (i.e. the specific
smart-card)
Decryption-devices generally have a storage for a couple of session keys (4 or
so) and a new key being received and decrypted successfully refers to a
specific index of an to-be-overwritten key. To decrypt the payload, the
receiver tries all the (e.g. 4) stored session keys until it got a match (i.e.
now checksum error in payload)

(This is a very rough description, just to illustrate how this can be solved
in a *centralized* way using a broadcasted keystream. Don't take that
literally, just meant for inspiration)

>> Next, here are potential questions a Commotion user should answer for 
>> him/herself before encrypting the mesh.  These could help the mesh users 
>> better understand what security the encryption does and doesn't provide.
>> 
>> Do you want strangers whom you or other mesh custodians have never met to
>> have the ability to configure their nodes and join your mesh on their 
>> own? If so, you probably don't need encryption, at least not on the mesh 
>> where you would like strangers to join. Alternately, would you like such 
>> strangers to contact you (or other mesh custodians) in person, to
>> arrange proper configuration of their node?  If not, then this mesh
>> wouldn't benefit from encryption. Furthermore, do you mind recently
>> acquainted strangers, upon having their nodes configured to join your
>> encrypted mesh, thereafter gaining the ability to observe all
>> (non-tunneled) traffic on the mesh?  If you do mind, then this mesh
>> probably doesn't need encryption.

> 
> That's the $64k question.
> 
> In order to place any trust in the encryption layer you must also trust 
> every single person or device that knows the keys to join the mesh. Wifi 
> encryption may be providing a false sense of security.

True. They way most people seem to think about "securing the network" is very
misleading... (what they intend to do is probably to encrypt communication
content and prevent unauthorized system access)

> 
>> Finally, what are your thoughts for mechanisms for adding new nodes to an
>> encrypted mesh?  At least, so that the mesh's encryption retains some 
>> degree of usefulness.
>> 
>> Quantum entanglement metaphor.  Similar to how quantum particles become 
>> entangled only when in the immediate vicinity of each other, new nodes 
>> (and their owners) must be brought physically to an existing node and
>> its owner. The new node is configured with the mesh WPA key in person
>> only, and thereafter taken to its desired location. Airmail pickup
>> metaphor, as illustrated in this photo.  A new node is flashed with
>> default settings and installed at a location w/in useful wireless range
>> of a encrypted mesh, and the MAC of that node's radio is emailed to the
>> mesh custodians, who add it to an internal whitelist on their end.
>> Thereafter, the nodes in the encrypted mesh all periodically (e.g. once
>> per day, at off-hours) disable their APs and switch their mesh interface
>> to the default channel, w/o encryption, and scan for the MAC of the new
>> node.  Upon completing the scan, the nodes switch back to encrypted
>> operation.  If an already-configured node finds it is range of the new
>> node, it transmits (via SSH/SSL/VPN tunnel) relevant config data and the
>> WPA key to new node, who then reboots to join the encrypted mesh.
>> 
>> 
>> Further thoughts?

To reflect the social trust structures accurately, we will probably not get
around the distributed PKI problem, which is a hot-topic in for more than a
decade.
I also wasted a lot of thought on that one specifically having the challenge
to secure decentralized mesh infrastructure in mind.

To make it short: Imagine a PGP-like web-of-trust which uses a special type of
DHT for object storage on each node:
- - In order to add/update an object (signed public key, signed session key,
trust revoker) to/in the DHT the object needs to be signed by an already
trusted entity
- - Depending on the type of the object, PKI operations are performed instead of
plainly storing the object. e.g. signatures are added to certificates instead
of overwriting or appending them separately, once a revoker for a certificate
is received, the revoker is stored while the entry for the revoked signature
is subsequently removed from the PKI
- - Redundant storage is decided by the length of the trust-chain (instead of
the usual bucket-approach in normal DHTs)

Granting access to a new node is then achieved by signing the new node's
public-key and subsequently encrypting and signing the session keys (WPA2-PSK,
OLSR) for all directly trusted nodes as well as for all nodes N hops away in
the key-chain (i.e. friends-of-friends-of-friends-...). The higher N chosen,
the more robustness towards single-node-failures can be obtained by the price
of higher CPU and network load and slower reaction to changes in the trust-graph.
The distribution of the session keys can then work similarly to the pay-tv
example above (i.e. having a couple of key-slots which are periodically updated)
With the main interface operating encrypted, we'll need to use the
packet-injection and monitoring API to allow communication during the initial
handshake (or, at least in the beginning, find a way around it and use some
other means, such as Ethernet-connecting the new node to an existing one for
provisioning and authentication)

Yet, there are more problems to face when all this is entirely decentralized.
e.g. when to change the key for transmission?

However, I believe this can be implemented as a compact background-process
using OpenSSL or GnuTLS (or, if we got too much time and not enough storage on
the node, we can extend px5g or CyaSSL) which does *not* handle the
P2P-communication part itself (but rather let the application(s) accessing it
do that, e.g. OLSR). This would allow reusing the code in other routing
protocols or even entirely different applications.

Make some web-searches for the topics will and see that there is a lot of
theory ("DHT-PKI", "distributed PKI", "P2P-PKI" are good keywords)

However, the implementations known to me are all far too desktop-targetted (->
dependencies) and are solving to many problems at once imho (e.g. peer-cert).
I guess, the start would be to specify a *simple* API for the interaction
between a distributed PKI backend and a P2P/mesh application.

If anyone is interested in joining such a (GPLv3 or even AGPL) project, please
contact me!


PS: A friend recently pointed out that securing the routing-information in
mesh network can also be behavior-based. E.g. the protocol itself could be
constructed in a way that would make it possible to detect malicious nodes
(which is e.g. corrupting the routing tables). However, to subsequently blame
or even ban the node, again, we will not get around a distributed PKI as a
means to identify the node (as addresses can easily be spoofed, obviously).

PPS: In our local community mesh we started deploying px5g in our firmware to
generate an initial private key on the node itself (once the user decides to
do that and after harvesting some entropy off the air). The plan is that the
node should publish (i.e. broadcast) a certificate signing request
(unfortunately, this is not yet implemented in px5g) and verify if the
received signature is what it was waiting for (by checking if a valid
key-chain leading to our root-certificate contained in the firmware can be
constructed). For now, we'll only use that for HTTPS-client-authentication
when a node wants to submit status information to be displayed on our website...




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJQwdzEAAoJECBgbL4bcbCQ8pQH/25uIzkUaRF5sLqUl4SeSt+a
9ZRMfHhw08n1N32NwmGM/XNt/bbD5UqY7AKSTyEisLlBOoDLJ0fwr5C1JEvyOQqy
Tc0qtUcPoZVEckS3auSOx9JGMHuCn7R3fekRHjtJTM1mPA8vUKq/Y8HSkwRu7cOd
dTr/H1+xkh+rVXoVt9xPmtFlgNiFpu+km2MXnwejiIPXYOotdknHOpX0H9Kdx/rv
c6HuRyiscMlwM/9v7wETo25/jFDiPmx3Nu9Q4cnELzU7JM/PgA/gP4zBmainnwQ1
v5lO84TUqhRioLLLco2ITE4yICPSmFGS3X0YDLQnpT4TpwvxL3k139Fn4LTJzGo=
=nYgM
-----END PGP SIGNATURE-----