Hi All,<br><br>Apologies for the serial emails.<br><br>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.<br>
<br>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).<br><br>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:<br><ul><li>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.</li>
<li>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.</li>
<li>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.<br>
</li></ul>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.<br>
<ul><li>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.</li>
<li>Alternately, would you like such strangers to contact you (or other mesh custodians) <i>in person</i>, to arrange proper configuration of their node?  If not, then this mesh wouldn't benefit from encryption.</li><li>
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.<br>
</li></ul>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.<br><ul><li><i>Quantum entanglement</i> 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.</li>
<li><i>Airmail pickup</i> metaphor, as illustrated in <a href="http://npm.si.edu/exhibits/2c2b4_2_stinson.html">this photo</a>.  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.<br>
</li></ul><br>Further thoughts?<br><br>-- <br>Ben West<div><a href="http://gowasabi.net" target="_blank">http://gowasabi.net</a><br><a href="mailto:ben@gowasabi.net" target="_blank">ben@gowasabi.net</a><br>314-246-9434<br>
</div><br>