This blog article is nominally an “office tech” article talking about how to encrypt your telephone traffic. But it’s also a legal ethics article. I suggest that the attorney’s ethical duty to preserve client confidences calls for the attorney to be continually aware of the confidentiality risks for various types of communications, and for the ways to protect those communications. Today’s article talks about protecting your SIP telephone trunks, and it talks about how our firm’s favorite VOIP service provider has just now enhanced our options for protecting our SIP trunks.
First a bit of review. Unlike the old days where a telephone call was a dedicated analog channel from end to end, today’s telephone calls involve packet-switched data. In today’s world of VOIP, the analog sounds spoken by humans into telephones get converted into data packets which are sent through the Internet and reassembled at the other end into analog sounds. The first step for a modern telephone call is “SIP traffic”. The SIP packets are sent back and forth to dial the call, to check to see if the answering device is willing to answer the call, and to agree upon a separate data path (the RTP path) over which the actual telephone call will take place. At the end of the call, a few more SIP packets get sent back and forth to permit all of the participating devices to reach agreement that the telephone call has concluded.
The SIP traffic, then, is filled with things like “what telephone number are you trying to call?” and “what is your caller ID number?” and “what codec shall we use to compress the audio information?”
The RTP traffic is filled with data packets that represent analog sound bites that have been converted into ones and zeroes.
An eavesdropper listening only to RTP traffic might not know who was calling whom, but would have the chance of working out what was said during the telephone call. An eavesdropper listing only to SIP traffic would know nothing about what was said, but would know almost everything about who was calling whom.
It will be no surprise to the long-suffering reader of my blog articles that one of my areas of interest is how to encrypt such things, so as to protect them from prying eyes (or ears).
It turns out that lots of smart people have worked on this and the result is that protocols and standards are by now well developed for ways to provide extremely secure protection. These include the Diffie-Hellman algorithm that reduced the need for briefcases handcuffed to couriers, as I discuss here.
For the RTP traffic, there is a protocol called SRTP. This secures the audio talk path. For the SIP traffic, there is a protocol called TLS. This secures the call setup and the wrapping-up of the call.
We can now turn to our figure to explain what it is that just changed. We start by looking at the various communications links that make telephone calls possible. In our office for example we have a Grandstream PBX 2. It is connected via a so-called “SIP trunk” B to a voice over IP service provider 1. (Actually in our case our PBX is connected to several VOIP service providers, each by means of at least one SIP trunk.) Our incoming and outgoing telephone calls pass over the SIP trunk B.
Many desktop telephones 5 are connected to our PBX 2, each by means of a SIP connection D. Likewise many of our people carry smart phones 4 on which a VOIP app has been installed. Each such smart phone 4 connects to our PBX 2 by means of a respective SIP connection C.
It might also happen that some customers of the VOIP service provider 1 make their connections by means of smart phones 3 (again on which a VOIP app has been installed) and connected to the service provider 1 by means of a SIP trunk A.
Each SIP connection A, B, C, and D has the possibility of passing through an insecure communications channel such as a path through the Internet. Which then prompts the alert reader to realize that it would be just as well to set up TLS and SRTP for each of the SIP connections.
It is easy enough for the diligent system administrator to accomplish such call security if you control both ends of a particular SIP link. If you control the equipment at both ends of a SIP link, you can then simply configure the equipment at both ends to use TLS and SRTP. For example in our office, given that we control our PBX 2 and our phones 4 and 5, from the very beginning of our use of VOIP we were encrypting our connections C and D.
What is conspicuously absent from the picture, of course, is encryption for the SIP trunks that go to and from the VOIP service providers 1. And that is the point of this article. It turns out that you can search and search, and you will not easily find any VOIP service provider that offers the ability to set up TLS and SRTP for the SIP trunks like B in the figure.
Our firm had been using the services of VOIP.MS for over a year now. And then last week came the invitation from VOIP.MS to do beta-testing of its new encrypted-SIP-trunk system. We tried it out and it works perfectly. Now our SIP trunks B are encrypted (both for signaling and for audio traffic). And we have some devices 3 (for example ATAs for fax machines) that connect directly to the VOIP.MS server rather than going through our PBX 2. These devices 3 also now enjoy encrypted links A.
It will be appreciated that if we dial a telephone call to some other law firm that uses VOIP.MS and that has likewise set up TLS and SRTP as described above, then we come very close to having end-to-end encryption of our call.
If the other law firm uses a different service provider that is nonetheless as up-to-date as VOIP.MS (with encrypted trunks) then likewise a call to that firm would be very close to being end-to-end encrypted. (It will be appreciated that VOIP service providers that are so sophisticated as to provide encrypted SIP trunks for their own customers will also, to the extent possible, employ encrypted SIP trunks for the provider-to-provider SIP traffic and provider-to-provider RTP traffic.)
How do you know if you have succeeded in setting up such encryption? One way is by setting up a device so that it will simply refuse to connect to the device at the other end of the SIP link unless it can accomplish the encrypted connection on that link. When things are set up this way, then you know you have succeeded in setting up the encryption simply by noticing that your call went through.
Most individual devices can also tell you the encryption status of their links to the next device. Many of the desktop telephones in our office, for example, will display a padlock icon (right) on the screen during each telephone call that is protected with SRTP.
I mentioned smartphones running a VOIP app. Our favorite VOIP app these days is Grandstream Wave, which was very clunky when first released a couple of years ago but is now quite slick. When a call is taking place that is protected by SRTP, a very small padlock appears on the screen (click to enlarge at right). Also note the telephone number +1-720-230-1331 which you might as well write down for future use. This is our test call number, which we at OPLF provide for you free of charge. If you are ever setting up a VOIP phone and wonder if it is working correctly, just dial that number. Punch 4 for an echo test. If you hear your words echoed back to you, then you know your phone has been set up correctly. You can also punch 5 for a DTMF (touch-tone) test.
But the padlocks just mentioned only tell you about encryption for links such as A, C, or D in the figure. What about encryption to and from a VOIP service provider 1? How do you know if a SIP trunk B is actually encrypted?
A well designed user interface for a VOIP service provider 1 will include an easy way to check the status of each SIP trunk. The screen shot at right shows the user interface at VOIP.MS. It shows a SIP trunk A that is connected to a smart phone 3 in the figure. At the time of the screen shot, the smart phone was at IP address 63.147.166.40. (The smart phone is not at that location now!) And at the time of the screen shot, the connection was an encrypted connection, as denoted by the padlock.
The devices that might be at the customer (client) end of SIP trunks from a service provider 1 as in the figure might be any of a wide range of SIP clients. When we launched into our beta participation in this encrypted SIP trunk program, we found ourselves turning on TLS and SRTP in the following devices:
- Grandstream UCM PBXs
- Grandstream GXP1625 desktop phones
- Grandstream DP750 base stations for cordless DECT phones
- Smart phones running Grandstream WAVE apps
- Cisco SPA122 analog telephone adapters
- Grandstream HT503 analog telephone adapters
In each case we succeeded. In most cases it was easy — just a matter of turning on SRTP and changing the SIP signaling from UDP to TLS. But in the case of the Cisco ATAs, it was actually not easy at all. I have written up configuration guides for three of these encryption projects, namely for the Cisco SPA122, the Grandstream HT503, and for the Grandstream UCM PBX.
Have you set up TLS and SRTP for your SIP trunks? Please post a comment below.
3 Replies to “Encrypting your telephone trunks”