Reply
Thread Tools
Posts: 6 | Thanked: 17 times | Joined on Jun 2010
#1
Hi all

For a while now I've been crushing my brains on how to best implement secure (read: encrypted) telephony on the n900. My focus is on media encryption, though signalling will have to be thought of as well.
What does the community think?

Here's the options I see so far:
- Use a ZRTP-enabled client (twinkle-port anyone? sflphone?)
- Extend existing telepathy framework to support encryption (gstreamer seems to support SRTP trough gstreamer-plugins-bad, what about key management?)
- Transparent (local) media proxy (proxy-to-proxy encryption - rtpproxy, mediaproxy?)
- On demand TLS-tunneling - VPN-style
- Other ideas?
 

The Following 7 Users Say Thank You to wirr For This Useful Post:
Posts: 1,417 | Thanked: 2,619 times | Joined on Jan 2011 @ Touring
#2
What you are contemplating looks like it will be for voip and not standard GSM calling. Still a reliable secure way to make a call that is not suspected at server side of compliance with US/UK intercept demands in their war of terror would be great.
Gstreamer layer to encrypt in a low bitrate codec and send over GSM voice chanel to another enabled N900 or other phone would be brilliant.
 

The Following User Says Thank You to biketool For This Useful Post:
Posts: 6 | Thanked: 17 times | Joined on Jun 2010
#3
Yes, you're right - I've missed to mention IP being used for transport.

If you suggest a gstreamer layer (which could be used independently of the transport layer i suppose), how would you address key management?
 

The Following User Says Thank You to wirr For This Useful Post:
Posts: 1,417 | Thanked: 2,619 times | Joined on Jan 2011 @ Touring
#4
Looks like this would do the trick:
https://en.wikipedia.org/wiki/Mumble_%28software%29
http://mumble.sourceforge.net/FAQ/English

Last edited by biketool; 2013-04-08 at 11:39.
 

The Following User Says Thank You to biketool For This Useful Post:
Posts: 68 | Thanked: 43 times | Joined on Jun 2010
#5
There are already several encrypted sip/rtsp clients around, porting one to maemo shouldn't be hard if it's not already done. For peer to peer, maybe just tunnel speex through dtls.

I think it will be hard to achieve real security (black suit level) with this type of device though. Too many layers in the software stack for bugs and exploits, too many radios to spew data, too much possibility of analog audio leaking out into the digital signal (this is a very serious concern with wired crypto devices, at least), plus issues like EM radiation from headset wires and weak encryption of Bluetooth, if you use headsets. Otherwise you have to get to the voice stream of the built in mic and speaker, and in some phones (dunno about the N900) that's rather difficult.

Overall a software secure phone can help against some types of attackers but if you are trying to do better than that, you need a hardware product. I know some people who made these in the past, though things are quiet now.
 

The Following User Says Thank You to phr For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#6
Originally Posted by biketool View Post
Gstreamer layer to encrypt in a low bitrate codec and send over GSM voice chanel to another enabled N900 or other phone would be brilliant.
This is actually something I have been thinking about doing, but implementation platform for me is of course N9. (no reason though why it wouldn't be easily portable to N900)

Call scenario is something like this:
  • start call normally as a a/b subscriber voice call
  • at any point both callers agree to switch to encrypted mode and start the application
  • both ends authenticate PKI
  • when the exchange is complete the voice transfer is transparently directed through the encryption layer
 

The Following User Says Thank You to juiceme For This Useful Post:
nokiabot's Avatar
Posts: 1,974 | Thanked: 1,834 times | Joined on Mar 2013 @ india
#7
wana nuke some contry or relay the mesage that your gf preagnent
personaly i apprecate your effort
 
Alecsandru's Avatar
Posts: 439 | Thanked: 282 times | Joined on Oct 2012
#8
that would be interesting , encrypted voice , what kind of algorithm do you think at ?
 

The Following User Says Thank You to Alecsandru For This Useful Post:
Community Council | Posts: 4,920 | Thanked: 12,867 times | Joined on May 2012 @ Southerrn Finland
#9
Encryption is not the problem, any decent stream cipher is usable.

The limiter here is the bandwidth of the audio connection between subscribers. The codecs normally used to encode/decode the audio limit the usable modulation range and frequencies.
It would need to be determined first what is the usble raw bitrate obtained via the modem algorithms. Note that there has to be quite a lot of redundancy as the encrypted payload gets unrecognizable even with single-bit errors.
 

The Following 2 Users Say Thank You to juiceme For This Useful Post:
Posts: 68 | Thanked: 43 times | Joined on Jun 2010
#10
If you're using IP connectivity then there is plenty of bandwidth. The Speex codec (speex.org) can get down below 5000 bits/sec and sound ok, or 2 kbit if you don't mind robotic sound. If you drop some frames here and there due to errors, it is ok. I don't know what it takes to get data through a GSM voice channel but the standard GSM codec uses 13 kilobits/sec, so if you can bypass the codec and get a bit stream into that pipe somehow, you are fine. If not, it is probably hopeless due to the way the GSM codec would mess up any signal you put into it. I know there are some very low bandwidth speech codecs that get below 1 kbit/sec but sound terrible. Even that may be pushing it though.
 

The Following 2 Users Say Thank You to phr For This Useful Post:
Reply


 
Forum Jump


All times are GMT. The time now is 12:19.