OK so I'm not much of a blogger.. Been busy coding instead, and I have an alpha-release available- http://countertap.sourceforge.net.

"Hello, old bean"

Imagine the processing power you could fit into this old phone's shell now- we could use public-key encryption on every packet!

I've been looking at VOIP protocols and there's quite the little family there. Here's a non exhaustive list of the most basic:

• H.323 - Used for setup and session signalling
• SIP - Session Initialisation Protocol - Competing standard H.323
• RTP - Real Time Protocol - Used for transmitting media packets
• SRTP - Secure Real Time Protocol - Confidentiality & authentication for media packets
• H.248 - Used on gateway devices
• MGCP - Media Gateway Control Protocol - Competing standard to H.248
• SDP - Session Description Protocol - Used to describe streaming media parameters

Whilst pretty much every VOIP device uses RTP to send the media packets, choosing a main session protocol (SIP or H.323) is a bit more involved. Although both perform the same basic functions, H.323 is older and more feature-rich (some say too-complex). SIP is newer, regarded as simpler to debug, and gaining in popularity. Both do some simple authentication, both are vulnerable to MITM attacks, and both can use IPSEC or TLS to mitigate against those attacks. SIP uses SRTP (which in turn uses AES encryption) if it wants to secure the media channel, H.323 uses AES more directly, but then still employs RTP for transmission.

For this project, I've chosen to implement SIP/SRTP over H.323/RTP. Frankly, the security abilities of each appear about the same. SIP/SRTP has a greater amount of existing OpenSource libraries & utils to get me started. This also allows me to split the project into phases- I can go off an implement call confidentiality using SRTP on its own as one phase, and handle the equally important key-exchange problem independently as a second phase.

The Navajo know

Check out this 'secure phone in a briefcase' used by NSA operatives in the 1980's. It uses Linear Predictive Encoding (LPC) for encryption. LPC is better suited to compression rather than encryption, so I'm sure the Soviets had a good laugh at that.

It's already apparent that for my own Crypto-phone that I won't be able to encrypt calls over the voice RF channel of the mobile device. The reason for this is straightforward- mobile manufactures invest heavily in hardware design and related software API's for their RF baseband; they're unlikely to share that Intellectual Property unless they expect to make some money from it. This is a pity, but understandable. Thus the remaining avenue is to implement VOIP (Voice over IP) on the mobile devices in a secure manner. VOIP has some well understood protocols (H.323, SIP, RTP etc.), and even some IETF RFC's for secure versions of these protocols. While I could go ahead and implement my own proprietary protocols for exchange voice calls, I think it makes sense to use the standards. As it happens, as far as I can tell, this has not been done on mobile device, at least not in an open manner. There are, however a number of non-secure VOIP clients ported to mobile devices, some open source. Thus the plan-of-attack is to choose appropriate secure VOIP protocols, evaluate them from a security and performance perspective, and implement them on an existing non-secure VOIP client. That almost sounds easy!

"Luca Brasi sleeps with the fishes"

The Don, under constant FBI surveillance, and tired of using Sicilian messages ("he sleeps with the fishes") to get his point across has decided to 'call in a favour' and asked me to design mobile phone software that employs end-to-end security. This blog will record my attempts at this project. Loosely, we're looking at:

- Call confidentialy, encrypted end-to-end
- Protection from Man-in-the-Middle (MITM) attacks

In a voice call, users can usually decide for themselves about Integrity (that the voice stream has not been altered) and Authentication (that they can verify who they're talking to). Whilst attacking a voice system in real time like that may still be the stuff of science fiction or Mission Impossible, history has proven that making such assumptions when designing a cryptography system leads to disaster. So both integrity and user-to-user authentication will be in-scope. The usual problem of key distribution arises of course, and may put the kibosh on authentication perhaps, so we'll see about that.

So why do this? Well, you probably know GSM (A5/1, A5/2) encryption has long ago been broken. Commercial GSM intercepters are available to buy, or you could roll your own. 3G voice encryption utilises an improved A5/3 algorithm, which has been shown to have weaknesses, although no practical attacks exist as yet. But even if you only make 3G calls, and your network operator (and their peers) implement it properly, and they actually turn the encryption on, you still have no end-to-end encryption, so calls can be intercepted. In-fact, by law your network operator may be required to be able to intercept calls, for law-enforcement purposes etc.

Some commercial solutions exist. I intend to make this one freely available. Stay tuned for details!