Re: Secure telephones
Jack Lloyd wrote: Well, nothing stopping you from treating your datagram-based VPN (ie, DTLS) as an IP tunnel, and doing TCP-like stuff on top of it to handle the IM and file transfer. Actually I'm working on something rather like that now, which may or not get finished soon. *lol* aren't we all. I suppose its a sign of the times - a decade ago, we were all writing our own crypto packages - now, we are all writing our own VPN (or zero knowledge routers) :)
Re: Secure telephones
On Sat, 17 Jul 2004, Steve Schear wrote: How about building a secure cell phone using GnuRadio as a core? That way you have maximum control afforded by the protocols. Several reasons valid at this moment (though I suppose (and hope) the situation will improve in next couple years). There is no available implementation for the low-level GSM protocols. Doing it from scratch looks like a royal bitch. The ADC/DAC chips for the required bandwidth are AWFULLY expensive. (I'd be happy if proven wrong here. (Well, I'd be happy if proven wrong in other two arguments too.)) The required processing power (and the related power (and cooling) consumption) is impractically high. But principially it is a very good idea, whose time will hopefully come soon.
Re: Secure telephones
On Sun, 18 Jul 2004, Bill Stewart wrote: If you're trying to build a usable cellphone, you've got much more stringent design criteria than a deskphone. I am painfully aware of it. You've got packaging requirements that force you into serious industrial design if you want something pocket-sized with good battery life, plus you've got to implement all the cellular interface features. Or use the off-the-shelf modules for industrial applications that already do it, and add some glue logic. If you're willing to build a backpack-phone, that's a lot simpler, because you can use a laptop with a [pick-your-favorite-cellular-data-standard] card and either a wired headset or a Bluetooth frob for a BT headset. Check the Gumstix and the Enfora Enabler specs. The first is the equivalent of a grossly stripped-down laptop (80x20x6 mm, few mA sleep, 50 mA command-wait, 250mA full power w/o Bluetooth), the second one is the equivalent of a comm card (GSM/GPRS, 50x30x3 mm, tri-band 5mA standby). The laptop approach is good for prototyping, though. I'm not aware of any cellular data cards in PDA-usable format (unless you've got a PDA big enough for PCMCIA), but you could take a GSM etc. phone with a wired interface to a PDA. I'd try the Enfora module in that case. RS232 for data and control, and analog I/O for voice. The PDA approach definitely has its merit.
Re: Secure telephones
At 11:45 AM 7/17/2004, Thomas Shaddack wrote: 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 If you're trying to build a usable cellphone, you've got much more stringent design criteria than a deskphone. You've got packaging requirements that force you into serious industrial design if you want something pocket-sized with good battery life, plus you've got to implement all the cellular interface features. If you're willing to build a backpack-phone, that's a lot simpler, because you can use a laptop with a [pick-your-favorite-cellular-data-standard] card and either a wired headset or a Bluetooth frob for a BT headset. An intermediate design, which other people have done, is an 802.11 phone - take your favorite high-end multimedia PDA and an 802.11 card and write whatever UI you want. Again, you can either do a wire to your pocket or Bluetooth, or do what some of the early Compaq Ipaq phones did and just hold the thing up to your cheek. I'm not aware of any cellular data cards in PDA-usable format (unless you've got a PDA big enough for PCMCIA), but you could take a GSM etc. phone with a wired interface to a PDA. The fun UI to implement is an all-audio one, with speech recognition for commands. There's a lot of market space out there for that. Bluetooth headsets aren't necessarily a great match for it, because you're getting a low bit-rate signal from a cheap microphone, as opposed to 11kHz 16-bit audio sampling.
Re: Secure telephones
At 11:45 AM 7/17/2004, Thomas Shaddack wrote: 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.) How about building a secure cell phone using GnuRadio as a core? That way you have maximum control afforded by the protocols. steve
Re: Secure telephones
On Sun, Jul 18, 2004 at 08:53:35PM +0100, Dave Howe wrote: That may have just been an artifact of a bad implementation, though. DTLS might be a better pick for securing VoIP. There's also SRTP. The strength of a pure VPN solution is that you aren't limited to *just* VoIP - you can transfer files, use whiteboarding, run videoconferencing, support text channels. even play games :) Well, nothing stopping you from treating your datagram-based VPN (ie, DTLS) as an IP tunnel, and doing TCP-like stuff on top of it to handle the IM and file transfer. Actually I'm working on something rather like that now, which may or not get finished soon. -Jack
Re: Secure telephones
Thomas Shaddack wrote: 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.) IIRC, PGPfone (http://www.pgpi.org/products/pgpfone/) did something similar, with a verbal handshake protocol that relied on you being able to recognise the remote party's voice over the phone while speaking a list of words always seemed both unreliable and odd in something with PGP in the name, but 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. Raw data streams would be fine over a point to point modem link - but I can see an advantage to compartmentalization - you can break your secure phone problem down into two distinct subproblems a) establishing a secure IP VPN between two nodes b) optimizing VoIP for low bandwidth links I would add a third - a modem protocol based on something like CSMA/CD to allow conference calls to be used as carrier media for secure conversations, but that is too hairy for me :) Something like OpenVPN (http://openvpn.sourceforge.net/) seems ideal for the secure VPN part of the problem, but requires an underlying IP network the VoIP part of the problem has a embarrassment of riches; H323 used to come as standard with windows, in the form of Netmeeting (complete with videoconferencing and whiteboarding) and SIP is now part of Windows XP (a not-particuarly-well-documented) feature of windows messager. There are many, many more, and Asterix (sadly not particularly well known, and unix only) is a complete, open source PBX which is conventional telephony, SIP and H323 aware. OpenVPN is of course built on SSL, and can use either X509 certificates or a preshared key for authentication. Sadly, there is no convenient way to use DNS-SEC key records for OpenVPN.
Re: Secure telephones
Jack Lloyd wrote: How well is VoIP going to work over SSL/TLS (ie, TCP) though? you can do SSL over UDP if you like - I think most VPN software is UDP only, while OpenVPN has a fallback TCP mode for cases where you can't use UDP (and TBH there aren't many) I've never used any VoIP-over-TCP software before, but some people I know who have say it sucks (terrible latency, sometimes as bad as 5-10 seconds). PGPfone had that problem, even over landlines (no IP involved) - however, I think that was more do to with the compression codecs and the crypto than any external problems, as switching to half-duplex usually cleared the problems up. That may have just been an artifact of a bad implementation, though. DTLS might be a better pick for securing VoIP. There's also SRTP. The strength of a pure VPN solution is that you aren't limited to *just* VoIP - you can transfer files, use whiteboarding, run videoconferencing, support text channels. even play games :)
Re: Secure telephones
On Sun, Jul 18, 2004 at 07:31:59PM +0100, Dave Howe wrote: OpenVPN is of course built on SSL, and can use either X509 certificates or a preshared key for authentication. Sadly, there is no convenient way to use DNS-SEC key records for OpenVPN. How well is VoIP going to work over SSL/TLS (ie, TCP) though? I've never used any VoIP-over-TCP software before, but some people I know who have say it sucks (terrible latency, sometimes as bad as 5-10 seconds). That may have just been an artifact of a bad implementation, though. DTLS might be a better pick for securing VoIP. There's also SRTP.
