Phone Call Security
bhook at kssb.net
Tue Jun 5 02:02:55 CEST 2007
Since all of the communications of a cell phone are digital (nothing is
analog between mic and speaker), encrypting the voice data stream should
be rather trivial (at least is in my understanding of the universe),
even if you have to resort to implementing a "virtual" mic device that
emits an encrypted sound stream.
As I understand it, the hard part is doing key exchange, because for
effective fast encryption you frequently swap out mid-sized symmetric
keys that are traded using asymmetric encryption (right? correct me if
I'm wrong). Since you can't easily do this over the voice channel, and
you can't reliably fit the voice over the data channel, and you can't
have both active simultaneously (or even intermittently), then you have
But what about the recently announced wifi capabilities of P2 phones?
This could make encrypted calls possible, and has an added security
bonus. In secure VoIP setups, we have authentication, key exchange, and
voice stream which are all sent over the same carrier. If you use the
wifi capabilities of the Neo, then you have authentication and key
exchange (wifi) done out-of-band from the voice stream (GSM). This means
that when the "bad guys" are some government, they have to tap two
entirely different and separate networks to have even a remote chance of
knowing what all you are communicating (let alone actually decrypting it).
The latency of the encryption, as long as it can be kept under about .5
seconds, really isn't all that noticeable in practice. Try calling a
land-line from a cell phone in the same room, and you will usually
notice anywhere from a .25 to 1.5 second delay. I've had cell phone to
cell phone calls that exceeded a 2 second delay, and the effect wasn't
even noticeable until the two of us are in the same room. If someone
INSISTS on a secure line, an added .5 second delay will hardly be a
concern considering the advantages.
Just my two cents.
Matthew S. Hamrick wrote:
> Encrypted voice calls is a question that's been around for a while. When
> I worked for RSA and later Certicom, we had frequent discussions about
> the strength (or lack thereof) of the LFSR-based encryption that was
> then in frequent use in GSM phones.
> I should probably mention that GSM and CDMA provide over the air
> authentication and confidentiality services. So if you're worried about
> bad guys cloning or eavesdropping on your phone calls (or text
> messages), you're safe already.
> Now... if your definition of "bad guys" includes the people who have
> operational control over the GSM network, then the story gets a little
> more complicated. Now, before you start saying, "oh, Matt's just being
> paranoid" or "oh, Matt's going to say something that will help the
> terrorists," let me just remind you that outside the US, there's some
> pretty clear evidence that national governments are eavesdropping on the
> conversations of traveling tech company executives and passing economic
> intelligence along to competing companies in their own nations. So
> end-to-end encryption is an issue that's near and dear not only to the
> hearts of the bleeding heart liberals at the EFF, but also the
> uber-industrialists of the far right.
> "End to end" security is the term used to describe confidentiality and
> origin integrity services that provide assurance that the two endpoints
> in a communication are a) really talking to the person they think
> they're talking to, and b) the content of the call is not being
> intercepted by a malicious eavesdropper. This is distinct from the
> existing GSM security services which protect only the over the air
> portion of the comm link.
> Approaches to end to end security on GSM phones started with layering
> voice data over the GSM data channel. There are some significant issues
> with this approach. First is obviously that you've got to have a phone
> that can be programmed to channel encrypted voice data across the GSM
> data channel. But, this message is going out to a community that groks
> this concept, so the only thing I'll say is... if we do something like
> this, let's fully specify what we do so people working on other
> programmable phones can interoperate with us.
> Next is the issue of carrier support. I don't know if it's still an
> issue, but in the olden days it seemed that Cingular required you to
> call them up and explicitly activate your GSM data line. Then at the end
> of the month, they would turn it off requiring you to call up and get it
> activated again. But that's less of an issue these days as we move into
> an era where we have EDGE now and HSDPA on the horizon.
> But... the issue of latency is important. The GSM data channel has
> terrible latency characteristics. Products like the CryptoPhone
> (http://cryptophone.de/ ) suffer from this. If your latency is too high,
> the delay makes a normal conversation virtually impossible. You wind up
> having to say "over" after each thing you say to tell the other person
> it's okay for them to speak. This is okay if you're a whacked out
> cypherpunk who gets off on acting like a spy, but having been in the
> military already, it's just annoying for me to have a half duplex channel.
> EDGE latency characteristics can be better than GSM data, but there's a
> fair amount of variability in EDGE latency. Sometimes it's high,
> sometimes it's low. Ditto for EVDO.
> A couple years ago Nick Lane-Smith gave a presentation at DefCon about
> doing putting encrypted voice over "data over GSM voice." More info at:
> The last I heard about this project, they discovered they couldn't get
> enough throughput to maintain a voice channel, encrypted or otherwise.
> All this and we haven't even talked about SIP over DTLS and SRTP...
> -Matt H.
> On Jun 3, 2007, at 6:08 AM, Mikko Rauhala wrote:
>> su, 2007-06-03 kello 07:08 +0200, Ortwin Regel kirjoitti:
>>> IIRC there has been lots of discussion about this a few months back.
>>> Take a look at the mailing list archives or the wiki if you can find
>> Spesifically, see subjects "Voice over GPRS?" and "Encrypting
>> voice communications" in the February archive page at
>> Summary: Possible to code support for this using GSM data calls (not GSM
>> voice calls due to GSM chip restrictions), which come with the quality
>> of service GPRS lacks. May cost a bit extra depending on your provider.
>> Compatibility with cryptophone.de probably possible, since their
>> protocol seems to be up for reimplementation. Either way, at least
>> Moko-to-Moko encrypted calls are quite possible to implement, just that
>> somebody (TM) needs to do the work.
>> --Mikko Rauhala <mjrauhal at cc.helsinki.fi>
>> University of Helsinki
>> OpenMoko community mailing list
>> community at lists.openmoko.org
> OpenMoko community mailing list
> community at lists.openmoko.org
More information about the community