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

[Ben West]

Hi All,

Apologies for the serial emails.

I've been successfully deploying WPA2-encrypted adhoc meshes using OpenWRT
v12.09 beta (aka Attitude Adjustment) here in St. Louis, so I'm starting
this discussion thread now to anticipate Commotion itself presumably moving
the OpenWRT v12.09 stable, when available.  Likewise for when or if Android
adhoc support (and all the Bug 82 drama) achieves enough resolution to also
support encrypted meshing.

This thread doesn't need to have any bearing on the current n2n tunneling
application in Commotion, which can effectively operate as an independent
layer of encryption (albeit with bandwidth constrained by the node's CPU).

First off, here are the assumptions I'm making w/r/t to security, both for
maintenance of such security and to help manage expectations:

   - 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.

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.

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<http://npm.si.edu/exhibits/2c2b4_2_stinson.html>.
   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?

-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20121206/945a0e8c/attachment-0001.html>