Business security surveillance & privacy voip

Why are the Major Telcos Afraid of encrypted voip?

A significant disconnect exists between the reality of today’s IP communications and the security concerns and needs of the customer (read encrypted voip). welcomes VoIP Week guest contributor Peter Cox, UM Labs Ltd. Founder and CEO.

One of UM Labs’ long-standing customers is using our product to provide encrypted VoIP connections from remote users (mostly home workers) and to encrypt calls they make and receive on their SIP trunk. Their motivation is simple: They are in the USA and their business makes it necessary for them to work closely with federal government, a connection that subjects them to security and compliance requirements. This customer’s view is that applying encryption to all VoIP calls — including those made and received on their SIP trunk — is an essential step towards meeting these requirements. Even if some SIP trunk calls are then relayed in clear text, as is the case for PSTN calls, the encryption applied on the connection to their trunk provider protects their network and ensures the confidentiality of SIP trunk calls on the connection between the service provider and their office. This effort demonstrates that they are taking all reasonable steps to secure the network connections under their own control and is thus a significant step towards meeting the compliance requirements.

Recently, our customer’s existing service provider announced that they were considering discontinuing encrypted SIP trunk connections, and being unable to find an alternative they asked me for some alternative service provider recommendations. I posted the question to the SIP Trunking & Enterprise VoIP LinkedIn group and received a number of helpful replies. My question also sparked some interesting discussion. A number of the participants gave spurious reasons why encryption was too difficult or not needed on a SIP trunk. What surprised me most was that representatives of two very large and well known telcos weighed in against encryption. One claimed that providing an encrypted SIP trunk connection was incompatible with legal intercept requirements, while the other tried to claim that since enterprises trust their data on “private” networks shouldn’t they trust their voice as well?

Addressing the claim that SIP trunk connections are not compatible with legal intercept requirements, I submit that when properly implemented and with the appropriate systems encrypted VoIP does not prevent legal intercept or call recording for compliance purposes. What it does stop is unauthorised call monitoring. The risk of unauthorised call monitoring is not confined to VoIP, as there is a significant risk to calls on cellular networks (see my recent blog at Encryption also has a role to play in controlling other threats, including call fraud.

Regarding the comment about enterprises trusting their data on private network connections to service providers, this I found even more surprising. I have spent many years in network security and this is the first time I have heard a connection to a 3rd party service provider classified as sufficiently private to trust for data transmission without some form or additional security. While connection to service providers may be more controlled than the open Internet, they are not private. Most enterprises will naturally want to protect their data with a VPN, so it makes sense to do the same for voice.

Part of the problem is that part of the telecoms industry is stuck in the past, back in the days when the phone companies owned and operated the networks. Things have moved on, and a significant proportion of all communications now runs on IP networks, much of it on the Internet. The move to IP has spawned new applications such as presence and IM and is the driving force behind convergence. The use of IP networks, and specifically the Internet for voice and UC, is a big step forward, but we must recognise that a different set of security rules apply. We have the knowledge and technology to address the security issues. Rather than finding reasons to avoid implementing VoIP and UC security technologies, the industry needs to embrace them and promote their implementation.

I won’t name the two telcos, but if you are interested in seeing them incriminate themselves you can follow the full LinkedIn discussion at

This is a VoIP week post on Check out other VoIP themed posts this week:

Why are major telcos afraid of encrypted VoIP? by Peter Cox
Emergency calls and VoIP by Peter Farmer
VoIP, the Bible and own brand chips by Simon Woodhead
Why the desktop VoIP telephone isn’t going away by Jeff Rodman
Small business VoIP setup by Trefor Davies
VoIP fraud-technological-conventionality-achieved  by Colin Duffy

security voip

Wot? No Password?

UM Labs Ltd. Founder and CEO Peter Cox’s post is based on a presentation given at a recent ITSPA workshop on the risks of auto provisioning.

Everyone understands the need for security on the Internet. We all know the importance of using strong passwords and — painful as it may be — regularly changing those passwords. As such, would it surprise you to learn that there is one widely used Internet service that routinely provides sensitive information to anyone that asks without asking for a password or employing any other form of authentication?

The service I refer to is phone auto provisioning. If your company has an IP phone system (as most mid-to-large companies do) or if you outsource your phone system to an IP service provider, the chances are that your phones are using auto provisioning and possibly without using authentication. ITSPA has recognised the problem and is working on producing guidelines to address it.

One of the benefits of VoIP is that you can take a phone out of the box, plug it in just about anywhere, and it works. Of course, there is a lot going on behind the scenes. For instance, for an IP phone to work it must first be configured with such details as a phone number, the network address of the system it should connect to, and a password the phone uses to authenticate itself to the service provider or internal phone system. Calls cost money, so phones must be identified and authenticated when they connect to the service and when they are used to make calls. The problem is that the complete configuration for a phone is long and complex. It could include 100 or more parameters, for example:

	sips persistent tls:     1
	download protocol:       HTTPS
        sip line1 proxy ip:
	sip line1 registrar ip:
        sip line1 proxy port:    5060
	sip line1 registrar port:506
	sip line1 password:      xxxxxxxxxxxxxxxxx

Of course, nobody wants to have to type such information in, so this is where provisioning steps in. When a handset is connected it contacts a pre-defined provisioning server (just a specialised web server), identifies itself via its unique MAC address, and downloads its configuration. Simple! The problem, though, is that most provisioning servers identify the phone (particularly when hardware IP phones are connected) solely via its MAC address — a 12-digit value unique to each phone that is normally printed on the phone alongside the serial number.* As such, if a provisioning server gets a request for a MAC address it recognises the server replies with the complete configuration needed to configure the phone….and most provisioning servers DO NOT ask for a password or use any other authentication mechanism. Thus, anyone who knows or is able to guess your phone’s MAC address can download its configuration, including the password needed by the phone to make calls.

Distributing passwords to anyone who asks without some form of authentication is clearly a bad idea. And guessing MAC addresses is not as difficult as it sounds. All an attacker has to do is to connect to a provisioning server and try each of the 16.7 million possible addresses for a specific vendor, which may sound like a big challenge but which in truth is not. To support this point I recently wrote a very simple script to do exactly this in just 5 minutes. I then pointed my script at a service provider’s provisioning server and ran it using a restricted set of 1,000 address. Running on a £25 Raspberry Pi, my script took roughly 7 minutes to complete and returned the complete configuration of two phones including passwords. And as I had no way of knowing if any of the 1,000 MAC addresses belonged to phones connecting to the service provider, 1,000 is a good hit rate.

At a rate of 7 minutes to scan 1,000 MAC addresses it would take 86 days to scan the entire range of 16.7 Million addresses used by a particular phone manufacturer. Then, having done that, I could get the configuration — including the password — for every phone from a single vendor used by the targeted service provider. And what if I was not willing to wait 86 days? I could invest in faster hardware or spend a bit more time writing a more efficient script (or both) and easily complete the scan in a week.

The information that my script returns would be invaluable to an attacker, offering an easy route for call fraud that could leave the victim with a bill of tens or thousands of pounds. Thus, ITSPA’s initiative to address the problem could not be more timely.

*All systems connecting to a network, whether a wired Ethernet connection or a WiFi connection, must have a globally unique MAC address hard-wired in when the device is built. These MAC addressees are managed by the IEEE, with each manufacturer assigned a six digit prefix (A list of vendor prefixes is published at MAC addresses are base 16 numbers, so the remaining 6 digits can be used to create 16.7 million unique addresses.

Business UC voip

Microsoft Lync, Embrace or Ignore? welcomes VoIP Week guest contributor Peter Cox, UM Labs Ltd. Founder and CEO

As the VoIP industry continues to grow, a new and potentially disruptive force has emerged. Microsoft Lync. While not exactly a newcomer (tracing its origins back through LCS and OCS), the latest version of Lync — Lync 2013 — is clearly making an impact on both VoIP and the Telecommunications industry in general. So the question is, should VoIP service providers and users embrace Lync or ignore it?

Microsoft is clearly positioning Lync to extend their reach from data into the VoIP world. The product is understandably popular with end-users who like the features that it offers, as well as with CIOs who see Lync’s Unified Communication services as a way of getting more out their investment in Exchange and Active Directory. Lync also provides Enterprise Telephony features, albeit at an additional cost.

So what does all of this mean for VoIP service providers and users?

One thing not in short supply is opinions on the merits of Lync.  The consensus is that Lync is great for Instant Messaging and for integration with Exchange, but that it does not deliver the industrial strength telephony needed by many end-users, particularly those in call centres. Mixed deployments are the result — with Lync in the back-office, and a more traditional PBX in areas with tougher call processing requirements — and these present a challenge.
UMlabs new logo.jamie.pike

One of the hurdles facing any Lync deployment is the product’s sheer complexity. Even a simple system for a small office requires three or more servers, with scaling for larger numbers of users and multi-site deployments complicating the picture still further. But the greatest challenge comes from attempting to interconnect Lync with other VoIP systems. The Lync architecture includes the Mediation Server for 3rd party connections, which can connect to a PSTN Gateway (Microsoft’s terminology), and as its name suggests can also provide restricted connectivity to other VoIP systems. The Mediation Server does not enable callers to be identified with anything other than a caller-ID, nor does it support presence or instant messaging, and therefore it cannot provide integrated Unified Communication services across a multi vendor network.

Lync is based on the Session Initiation Protocol (SIP), the same protocol that virtually all other VoIP products and services use. Microsoft have added so many extensions to the Lync version of SIP, though, that providing the level of integration needed for a mixed Lync and standard SIP deployment is beyond virtually all end-users and many system integrators. On the plus side, Microsoft has published details of the SIP extensions they have implemented. While these specifications will not help the average end-user, they have enabled the development of enhanced connectivity solutions for Lync. It is now possible to deploy a mixed environment, for instance, with Lync in the back-office and an alternative VoIP system in other areas.

The Microsoft marketing machine will clearly continue to promote Lync, end-users will continue praise the integrated services it offers, and CIOs will continue to value the improved ROI. Also, the ability to provide true interconnection with other VoIP products and services means that there is now an opportunity for service providers to offer new services centred on Lync, and for end-user organisations to benefit from the optimal mix of Lync’s UC services and call centre grade services from other vendors. End-users will continue to adopt Lync, and thus service providers and system integrators able to provide Lync integrated with other VoIP products and services will have an edge. As such, the VoIP industry needs to embrace Lync or become a casualty of its advance.

VoIP Week Posts: