Marriage Of Phone Services, Biz Apps Could Be A Security Risk
By Bruce Schneier
One of the key reasons businesses have yet to link their business applications with telephone services is there's no common interface. While two standards under development promise to let businesses integrate and control telephony services, such as call forwarding and automatic number identification, with software, such as Web-based call center apps, these standards could introduce huge security risks.
These standards address key issues. One organization working in this space is The Parlay Group (www.parlay.org), a consortium of software, hardware and telecommunication service providers. The group is creating a specification and an application programming interface that will enable phone-system control from outside the secure telco network. This interface can be embedded in applications to reroute calls, provide notification of call attempts, retrieve the location of mobile users and link to telco billing systems, among other features.
The other spec, which the Internet Engineering Task Force is defining, is called the Session Initiation Protocol (SIP) for voice over IP. This protocol will let an individual define complicated ways to redirect calls. While these features are nominally controlled by the user, the programs are stored in the telco network and a Domain Name Service-like service is used to handle the profile and call forwarding. SIP is becoming a big thing; it's currently being used for VoIP telephony, will control calls in third-generation wireless networks and is being envisaged for all sorts of other uses, such as instant messaging.
I am terrified at the security implications of these services. Sure, the Parlay spec says that communication between the Parlay client and the Parlay server in the telco network is encrypted and authentication will be enforced, but I don't believe for a minute that this will remain unhacked. SIP contains security provisions, but I don't trust them either.
It doesn't matter how many bits the key is, or what authentication protocol they employ: We've learned from experience that all systems like this are hackable. I worry that these protocols will open a huge hole into the telephone system. They will be hacked, and then things will get ugly.
Think about the possibilities for a minute. Denial-of-service attacks will be a breeze: Suddenly hackers can just reroute all calls to a person elsewhere. Or they can reroute all calls to a popular phone-sex service. Or maybe they will just choose to eavesdrop. All they have to do is set up a three-way conference bridge whenever someone receives a phone call. It gets worse. The FCC is mandating that cell phone companies pinpoint phone locations to within 100 meters (for use with 911 calls). The carriers plan to use this information to create new data services based on location. The location information will also be available through services like Parlay for third parties to use. Imagine the security implications of that information getting into unauthorized hands.
Telephone hacking isn't new. But it's a hard network to hack. Telephony is a controlled closed universe. The protocols are often proprietary, access is limited and information is scarce. The Internet, on the other hand, is much easier to hack. What we're seeing is another example of the tension between functionality versus security.
Opening the network is a good thing from the perspective of creating innovative new services, speeding up development cycles, adding value to data and voice. Yet when we do this, we open up the potential for the bad things as well. Soon the phone network will become just like the Internet. Putting control of telephony networks on the Internet means anyone can hack a service provider's network over the Web. These protocols will turn control over to authorized, and also unauthorized, Internet control. If you think phone phreaking, in which sophisticated hackers break into public network and switches, was bad, just wait until anyone can do it.
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.