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

[Paul Gardner-Stephen]

Hi All,

We have been thinking about some of these problems with the Serval
Project for a while as well.
While we have not come up with a complete solution, we realised early
on that having an unforgeable network identity would be a very useful
thing for any sensible solution in this space.  This is why we use
public keys as the network identifier on the Serval Overlay Mesh
(which is what VoMP sits on).

This means you can at least work out, in a completely distributed
system, whether you are talking to the node that you think you are.
>From there you can start building up the necessary features to obtain
Byzantine Robustness.

On that note, Radia Perlman
(http://en.wikipedia.org/wiki/Radia_Perlman), who wrote the paper
about achieving Routing with Byzantine Robustness
(http://labs.oracle.com/techrep/2005/smli_tr-2005-146.pdf), is one of
the keynotes at Linux Conf Australia this coming January.  A bunch of
us from Serval intend to be there, and might pick her brains on this.

More generally her paper about Routing with Byzantine Robustness is
well worth us all reading (or re-reading) as we look for solutions in
this space.

Paul.

On Fri, Dec 7, 2012 at 10:40 PM, Daniel Golle <daniel.golle at gmail.com> wrote:
> -----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-----
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev