At first sight, using any VoIP client on the iPhone or the iPod Touch (a.k.a. iDevices) may seem like a uninteresting thing. The reason for this is that Apple does not allow 3rd party applications to run in the background. So when a user close down his iVoIP Client he will not be able to receive any calls at all, thus defeating the reason for using VoIP on these devices in the first place.

However, if we take a look at some of the VoIP clients offerings available we notice that a few of these clients have the ability to receive incoming calls, even when the software it self is not running.

At first sight this seems to be a Good Thing – however, there are severe security implications by doing this. Users will in fact willingly, put them self under a man-in-the-middle attack.

3rd party proxies

Before continuing, let me use two pretty well known mobile applications as an example: Fring and Nimbuzz. Both applications support a whole slew of different means of communication – but if we take a closer look at the physical size of these program it become quite apparent that these applications does not have all the code for all the various services they let the user access.

The general rule is that these client providers will act as a proxy between the users client and the users service provider. Basically, when setting up your Nimbuzz client for SIP usage – it is not the client that will connect to your SIP server, but a server in the Nimbuzz network.

So in effect, Nimbuzz and Fring does keep a copy of your SIP credentials. It is unclear if they store the credential when the users client is not online.

SIP and the Apple Push Notification Service (APNS)

This is the new kid on the block. For quite some time now, the iDevices have had the ability to receive Push Notifications. This is something that could be of great use, and Apple has on numerous occasions stated how this technology can be used.

In practice a service provider can use the APNS to send out notifications to a specific iDevice. As far as I know, Apple has put no restriction on the content of such notifications.

What is happening behind the scene, is that SIP credentials stored in the iVoIP Client are transferred over to the client providers infrastructure (CPI). A server in the CPI will then re-register itself as a SIP client to your SIP server, with your SIP credentials.

When an incoming calls are present, the SIP signaling will be sent to the server in the CPI – and this server will then send out a Push Notification over the APNS netowrk, ending up in your iDevice. When the device receive the notification, it will display some information to the user. If the user confirm the notification – the VoIP Client is started, registering to your SIP server and will then accept the call.

In my opinion, giving away your SIP credentials to a 3rd party you have no control of, seems like a very bad idea. I also suspect that most service providers Acceptable End User Policy prohibit a user to give away his SIP credentials.

None of the companies providing 3rd party proxy solutions as their core business have, as far as I have found, publicly shown any documentation from a 3rd party stating that they do have a well funded security policy that is being upheld.

I do suspect that these companies are prime target for Black Hat telecom hackers. Just getting access to thousands of thousands SIP accounts which can be resold IS a tempting target.

Possible solutions

The easiest way out of this mess if of course not to enable the client to use the APNS network. However, this defeat using a iVoIP Client efficiently.

A much better solution would be for the CPI to offer a WebService solution.

When a call comes into the switch/PBX, the switch could then do a WebService call to the CPI, and the CPI would then issue the Push Notification message over the APNS.

This is a clean and efficient solution that will have the same result for the end user, without compromising security: A Push Notification message of a incoming call – enabling the iDevice to start up the iVoIP Client and let the client handle the call.

Another solution could be to let companies with their own APNS agreement, send out their own Push Notifications. I have not spent too much time with the rules that Apple have for the APNS, so I can not say if this is in fact possible.