wirr | # 1 | 2013-04-01, 10:13 | Report

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?

biketool | # 2 | 2013-04-02, 16:31 | Report

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.

wirr | # 3 | 2013-04-03, 00:21 | Report

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?

biketool | # 4 | 2013-04-08, 11:33 | Report

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.

phr | # 5 | 2013-04-10, 10:42 | Report

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.

juiceme | # 6 | 2013-04-10, 11:07 | Report

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

nokiabot | # 7 | 2013-04-10, 17:02 | Report

wana nuke some contry or relay the mesage that your gf preagnent
personaly i apprecate your effort

Alecsandru | # 8 | 2013-04-10, 18:01 | Report

that would be interesting , encrypted voice , what kind of algorithm do you think at ?

juiceme | # 9 | 2013-04-10, 20:25 | Report

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.

phr | # 10 | 2013-04-11, 04:47 | Report

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.