Pondering construction of a secure telephone. (Or at least a cellphone in general. The user interfaces and features available on virtually all the mass-market phones suck, to put it very very mildly, not even mentioning that there's no access to their firmware (so no chance of audit), poor or no support for SSL (while running HTTP through the operator's proxy), and typically no possibility to run more than one Java applet (or other program) at the same time. A combination of a GSM/GPRS module with a suitable embedded Linux-running computer could be the right solution.)
The easiest way is probably a hybrid of telephone/modem, doing normal calls in "analog" voice mode and secure calls in digital modem-to-modem connection. The digital layer may be done best over IP protocol, assigning IP addresses to the phones and making them talk over TCP and UDP over the direct dialup. (We cannot reliably use GPRS, as the quality of service is not assured, so we have to use direct dialup. But we can implement "real" IP later, when the available technology reaches that stage.) Once we have the phones talking over IP with each other, we can proceed with the handshake. I'd suggest using OpenSSL for this purpose, as it offers all we need for certificates and secure transfer of the key. Then use UDP for the voice itself, using eg. stripped-down SpeakFreely as the engine. So during the call, two connections will be open over the IP channel: the command one (SSL-wrapped TCP, for key and protocol handshake, ensuring the identity of the caller, etc.), and the data one (a bidirectional UDP stream). As the command connection should be silent for most of the time, a 14k4 modem should offer us enough bandwidth for 9k6 GSM codec, even with the UDP/IP overhead. The problem is with the calls themselves, determining if they have to be connected as secure or as insecure. For landlines, it's easy; we can hold the line open while switching the modem between voice and data modes, even if we'd have to do it the "hardcore" way with a relay and a 600-ohm resistor connected to the phone line during modem hangup. We then can freely alternate between voice and data, starting in voice and getting the telephones negotiate over "analog sound" using some sequences of beeps, like during the time of acoustically coupled modems. We need just few 100s bps to tell each other that we both support secure call, and that we want to switch to it. However, the cellphones pose a much worse problem. The voice/data call type is determined at the connection time, and as far as I know, can't be changed on-fly. So we would have to have the desired call mode specified in the phone's addressbook (with eventual secure mode advertising through the mentioned beep sequence when in insecure mode, and eventual automatic or manual redial in secure mode). Does anybody here know if there is a workaround available for this? How does the Siemens crypto-phone <http://www.vnunet.com/news/1125124> solve this? It is possible to place data calls from a GSM phone. But it is possible to RECEIVE the data calls on it? Can I connect a cellphone to a laptop and have a dial-in server? A workaround here could be exploiting the always-on properties of GPRS (if the Enfora modules offer GPRS simultaneously with GSM calls, it could provide a lot fo advantages), and use eg. Jabber as a messaging platform (overcoming the difficulties with secure SMS messaging), and optionally also for secure call negotiation, serving here as a control connection. A nice feature could be a phone-located voicemail (won't cover the situations when the phone is outside of the network reach, but could be handy for the situations where the phone is just told to not ring). The advantages would be the possibility of the voice being transported in secure mode, and the possibility of encrypting the messages in storage. Another feature, that could make the device rather attractive in some demographics, is the possibility of having the phonebook stored encrypted on the handset, inaccessible without a PIN, or not located there at all, stored remotely. Yet another advantage, useful for closed groups, is the possibility of using Jabber UIDs dynamically mapped to phone numbers, allowing the users to swap the handsets, bringing a bit of deniability into the location tracking. The modularity of the design should allow low degree of lock-in to the vendors and networks; other modules than Enfora can be used for different standards, Enfora produces tri-band (and even quad-band, adding 850 MHz to the mix) ones for both US and EU/AU/NZ markets, the control computer should be exchangeable for any other kind, with just minor tweaks in the software itself. Openness of the design should allow the implementation of other emerging secure comm standards, including but not limited to Skype. Various message-anonymizing tricks could be also done, using mixmaster-style forwarding within the network, and/or using secure messaging clients instead, like eg. Silc <http://www.silcnet.org/>. Any comments from the Collective? -- ....Enfora Enabler tri-band GSM module, <http://www.enfora.com/shop/detail.aspx?ID=32>, $120. Full-featured embedded Gumstix computer, <http://www.gumstix.com/>, $185. Big fat lithium battery, $50. Display, keypad, other circuits, case: $100-200. Writing the firmware, 2-3 weeks. Warm fyzzu feeling from pissing into the wiretap operators' beer - priceless!
