[SVHMPC] Phone Call Security

Tue Jun 5 08:01:59 CEST 2007

> -----Original Message-----
> From: svhmpc-bounces at telefono.revejo.org [mailto:svhmpc-
> bounces at telefono.revejo.org] On Behalf Of Bradley Hook

> 
> 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.

No ... coding theory shows how more 'random' signals require more bandwidth.
Entropy IS information.  Typically, the bandwidth of the voice signal is
first compressed, digitized and then encrypted.  Subsequent mapping of the
digits by modulation would have to fit in the available channel.  Without
the compression, the encrypted and modulated voice takes up more bandwidth
than a unencrypted voice.

> 
> 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). 
Ok ... you're wrong :-)   Key exchange is required only once per session.
For strong symmetric algorithms (like AES), the session can be a very long
duration (potentially even multiple calls)

>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
> a problem.
> 
> 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). 

Yes!  WiFi has better bandwidth ... the voice is already packetized and
compressed .. and standard key exchanges and IP encryption are already
available.

Paul

>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.
> 
> ~Bradley
> 
> 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:
> >
> > http://www.hbmobile.org/wiki/index.php?title=Data_over_GSM_Voice
> >
> > 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...
> >
> > -Cheers
> > -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
> >>> it!
> >>
> >> Spesifically, see subjects "Voice over GPRS?" and "Encrypting
> >> voice communications" in the February archive page at
> >> http://lists.openmoko.org/pipermail/community/2007-February/thread.html
> >>
> >> 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
> >> http://lists.openmoko.org/mailman/listinfo/community
> >
> >
> > _______________________________________________
> > OpenMoko community mailing list
> > community at lists.openmoko.org
> > http://lists.openmoko.org/mailman/listinfo/community
> >
> >
> 
> 
> _______________________________________________
> SVHMPC mailing list
> SVHMPC at telefono.revejo.org
> http://telefono.revejo.org/mailman/listinfo/svhmpc_telefono.revejo.org
> 
> __________ NOD32 2308 (20070604) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com

Paul A. Lambert
CTO, Picomobile Networks Inc.
256 Gibraltar Drive, Ste 108
Sunnyvale, CA, 94089
cell: +1-650-787-9141
skype: paulatpico