Commotion Wireless : interview of Josh King
[This interview was made in prevision of a different article, about cyber-dissidency and its repercussions in International Relations. This interview is extracted from an exchange of emails between Josh King, Sascha Meinrath, and me. I would like to thank them for their patience.]
Adrien Gévaudan: Why are you developing Commotion? It seems that it’s a very common question, but I mean: if we agree that there are two big ways to see the future (of the) Internet, a Facebook/Google one, and a 4chan one, in which do you recognize you the most? Certainly Commotion is a (future) tool that will serve the anonymity of its users, and thus be closer to a way of seeing Internet as a space of anonymous liberty (close to the 4chan point of view), but can you acknowledge this ideological proximity? How do you conceive the Internet?
Josh King: We’re developing Commotion primarily because we see a great need, in efforts like the Arab Spring protests, for activists to have the ability to communicate securely and anonymously in a local fashion, as well as share sparse sources of Internet connectivity. It deals only obliquely with the question of identity and anonymity on the Internet. However, I think most of the rest of the team at OTI would probably agree with me though that for the purposes of upholding and protecting freedom of speech on the Internet, though we may not hang out on 4chan, we consider a disaggregated and distributed system that protects peoples’ privacy to be preferable to an authoritative system that always reveals your true identity. I personally think that true security and anonymity can only be accomplished through the architecture of the network and the mathematics of strong cryptography, not through the good-will and sufferance of corporate institutions.
AG: How would you describe the philosophical, sociological filiation of your project? (any relations with Indymedia, a specific (hacker?) philosophy, etc.)
JK: The Commotion Project doesn’t have any specific affiliations, but many people at OTI (including myself) are Indymedia veterans. Since the project is run as a Free Software project, and is aimed at activists, it implicitly aligns with those philosophies. But beyond that, we’re attempting to be as open to uses and philosophies as possible as long as those uses don’t conflict with the core architecture of the project as being open-source and for secure communication.
AG: How do you see the support of your government? I think you know very well how suspicious some people can become when they learn that a US department is supporting a project, even regarding the little amount that your subvention represents. So do you see it as in « we don’t care, we need money, and if they think they can instrumentalize us they will be disappointed », or like in « the official support is a pledge of credibility, and we shouldn’t fall in a Manichean pseudo-anarchist vision of the State »?
JK: We’re very conscious of the perceptions associated with something like this, and it’s definitely something that we discussed internally before accepting the grant. However, the State Department has been very hands-off on the way the project has been managed and we’re ensuring the credibility of our assertions that we’re not creating surveillance tech or something like that by releasing everything open-source. On the whole, they’ve been very supportive of our efforts and are committed to demonstrating that this is not a government project. In the end, working with them was a natural fit, simply because they wanted to fund exactly what we wanted to do anyway, for exactly the stated reasons that we wanted to do it, with no strings that could redefine the mission of the project.
AG: What will happen after the release of Commotion? Are you working on other projects? How will you release it? Under which license?
JK: Commotion will continue to expand and be developed after the grant period expires, and we’re hoping to participate in deploying the technology both domestically and abroad. A big goal of the project is to build an open-source development community around it, and we’re also seeking additional funding to carry our paid development efforts forward. I definitely intend to keep working on the project for the foreseeable future, funding or no funding ;-)
All original code will be released under the GPLv3, LGPL, or AGPL where appropriate. Since we’re working with a bunch of other open-source software projects, contributed parts might be under other open-source licenses. The project will be released both as sourcecode and as application bundles for multiple platforms (think Tor browser bundle), along with the embedded images for router devices.
AG: [a member of Intelligence-Stratégique.eu, Félix Aimé, developed a few weaknesses; you can find his article: here (in french); the following questions are mainly extracted from it] The protocol OLSR has well known vulnerabilities (such as DDoS, hijacking of nodes, false announcement): how do you plan to secure Commotion?
JK: It’s true that the OLSR protocol wasn’t designed with security in mind, but that doesn’t mean that it’s impossible to secure. In order to address concerns around false announcements and control traffic trying to alter routers, each router in the network will utilize public key encryption and have its own key, which it will use to sign all of its control traffic. These public keys will form the basis of a trust metric that will allow for untrusted and suspicious nodes being ‘downvoted’ so that traffic is not passed through them. Establishing secure transport between nodes via opportunistic IPSEC encryption will help ensure that traffic passing through a given node is not eaves droppable. DDoS is not a problem of OLSR specifically and is much harder to address in a completely comprehensive way, but restriction of packet flooding via MPRs and detection of excessive and suspicious flows at the edges of the network will hopefully go a long way towards mitigating it.
AG: The Onion Router (TOR) is part of Commotion, right? But the problem when you incorporate other softwares in a project is that you incorporate their weaknesses, too. How do you plan to resolve this? For instance, the last node in a TOR network is vulnerable because the data isn’t encrypted at this point. Another example: a lot of people are using TOR as Internet proxy, and they only configure it in their navigator, but forgetting to configure their plugins as well. This could permit to get the IP address of a TOR user with a simple object in Flash/Silverlight/Java or another protocol (FTP, SMB, DNS, etc.)
JK: We’re working with the TOR project, but it’s unlikely that TOR itself is going to be used as the basis of security and anonymity inside the network. We’re probably going to end up creating a simpler, TOR-like onion routing system that optionally runs inside of the network (in order to deal with resource constraints on embedded devices), and then provide the option to run Torrouters at the edges to transit traffic onto the Internet. Torrouters are a subproject of TOR for creating a router firmware that transparently proxies all traffic onto the TOR network without user intervention or configuration.
AG: A part of a MAC address of a device composes an IP address of a Commotion node (the 4th, 5th and 6th byte). Therefore, knowing the IP address of a Commotion node will permit to locate it geographically. If we know the geographic position of the node that has access to the Internet in a Commotion network, isn’t it possible to find a source node, using a triangulation based on the intensity of the signal emitted by the node? And next you only need WIFI jammers to scramble an area…
JK: It’s true that currently by default the backhaul network is an IPv4 network where the node address is derived from the MAC address of the node. This is largely a function of attempting maintain compatibility with other community wireless network solutions that do the same thing. It’s currently in the works to change the default addressing mechanism to IPv6, with optional anonymization of the MAC address. Since most networks probably wouldn’t have publicly-routable IPs for all nodes, you couldn’t necessarily tell the location by doing IP-geolocation from the Internet side. Given a picture of the whole network, if you have enough connections and enough known geographical locations, you might be able to narrow down the physical location of a given node, but we’ll be working to minimize the amount of information that any given node knows about the network through Fisheye, MPRs and Onion Routing. Of course there’s no way to completely defeat jamming, but given the relatively low power of the wireless connections it will be at least difficult to detect and jam enough nodes to bring down an entire network such that it can’t route around the areas of jamming, without doing broad-spectrum jamming across that entire band for a whole geographical area. One of our aims is to make these attacks prohibitive in their consequences.
AG: Of course, nothing can be perfectly securized, and there is always « the human vulnerability ». So which softwares do you recommend the use, as a complement of Commotion?
JK: The same software that you would use to secure your connection over the open Internet. SSH tunnels, SSL connections, VPNs and Tor are all good choices. Since, as you said, perfect security is impossible, it is best to use a variety of tools in combination where possible in order to minimize single points of failure. A major focus of the project is being informative and educational with regards to exactly how much security you’re getting and what the ramifications are of using the network.
AG: How would you do, you the Commotion creators, to break it? :-) I will reformulate: what are the known vulnerabilities of Commotion?
JK: It’s difficult to speak about known vulnerabilities when we’re so early in the project that most of the security architecture isn’t written yet ;-) We definitely intend to pentest our networks, and possibly even offer a reward for people who are able to break it, in order to ensure that we can refine our security model and address problems with it.