A Proposal for Solving the Caller ID Problemby John Todd
Editor's Note: This article was adapted from a post that John Todd made recently to the Voice Over IP Security Alliance VOIPSEC mailing list, following a lengthy discussion of the issues surrounding the reliability of Caller ID data. VOIPSA is an excellent resource for VoIP security topics. John is not a lawyer, and any law-related opinions he expresses here should not be used as legal advice or guidance.
There is growing concern over the interaction of VoIP systems with the legacy PSTN, and the transmission of caller identity data--most notably, Caller ID on the PSTN. It is not always possible, or obvious how, to handle Caller ID data when moving to or from VoIP and the PSTN networks. There are even business models predicated on the ability of Caller ID to be transmitted to the PSTN with a value that is not "expected"; call centers are an obvious example, where customer-support staff make outbound calls with a Caller ID that may be from one of many possible clients. More troubling is the possibility that Caller ID may be used to trick unsuspecting call recipients into certain actions or beliefs, and it is this concern that's currently creating a legislative threat I believe must be averted.
I have a proposal at the end of this article that attempts to address these issues, but first some background.
Congress is currently considering legislation titled The Truth in Caller ID Act, which certainly sounds noble. Who doesn't want correct Caller ID when receiving a call? The truth is that this bill is redundant--the Wire Fraud Act already covers this issue, and adding more wording seems to be merely a re-statement of a certain circumstance or type of Wire Fraud. While the wording of this legislation does not effectively change the amount of power a prosecutor currently has, I believe it will certainly create confusion and fear in the technical and investment community because of the uncertainty it promotes. It's like saying, "I want you to not break the speeding laws AND I want you to not go over the speed limit!" A legal staff could spend a week--at $200 an hour--explaining that to a CEO, despite the consistency.
In my opinion, the real threat is not the pending legislation, but other legislation that may likely be appended to it in a year or two's time. That legislation will more clearly identify an impossible or prohibitively expensive technical solution to combat fraudulent Caller ID data from being passed over the network. This would be detrimental to the overwhelming majority of legitimate Caller ID rewrite methods upon which many companies base their business plans, and which many customers have come to expect as basic parts of their service.
At the root of the problem is the desire for law enforcement agencies to have quick and accurate data when trying to uncover who made a call to a certain number. I believe this should be possible, or at least it should be possible when the endpoints are on the PSTN, which is a (more) clearly regulated environment. The problem is that the trust that once existed (possibly falsely) in the PSTN to deliver an accurate Caller ID is eroding due to the flood of interconnecting services that deliver voice but don't have typical E.164 numbering endpoint data associated with them, or that treat E.164 data as a customizable field that may be asserted by the customer. This moves the trust level out another step, which breaks the current model of "phone companies are probably not lying to each other."
For several firms that I have worked in, including my current employer, the Caller ID issue has been a central concern, and the fear of inappropriate legislation puts at risk some of the products and features customers have come to expect. Users without E.164 numbers, users with several E.164 numbers, users wanting to move E.164 numbers to their calling device and network of choice--these users are all affected by the issues that arise with the development of mobile and VoIP infrastructures that decouple devices with E.164 addresses. Advanced combinations of transmitting Caller ID are part of the natural progression of next-generation services, and customers are demanding a better set of methods to control the way their company and personal calls are identified. It's going to get much more complex and customized from the customer and service provider's perspective, and it's up to us as an industry to figure out how to provide accountability for our customers and ourselves to law enforcement agencies.
- Caller ID (and ANI) is insufficient for authentication purposes other than as a "hint." It is wildly irresponsible to assume that the person attached to a device is "authenticated" merely by using that device, when control of those devices has no additional universal, or even commonplace, security policy.
- Identity presentation should be separate from the network provider. As users become more and more distinct from telephony devices, this will only become more pronounced. This applies to E.164 numbering as well as other identity methods.
- I do not believe that there is a technical solution to this problem that works on the front-end. SIMs, biometric authentication, or other methods are too complex, or at the least, are going to be selected independently by each vendor. (But I do think there is a solution on the back-end--keep reading.)
- Law enforcement does need a way to determine who made a call, or at least to what company a warrant should be presented for further data. Currently that does not seem to be the case.
- I think that the "Truth in Caller ID Act" is probably more political grandstanding than actual effective legislation, since wire fraud statutes already exist that make false impersonation a crime, and I seem to recall already prosecuted cases on the topic of Caller ID. This pre-existing law will not prevent assertion #6...
- Law enforcement in the United States currently can ask for and receive almost anything it wants as far as legislation. As soon as an investigation reveals that Caller ID rewriting was integral to some type of "terrorism," the industry will find itself at the wrong end of an even more poorly written legislative cannon that will crush companies and investments. Other nations are already in situations where certain products are illegal or relegated to a grey market due to bad legislation, and some will follow the lead of the U.S. I believe that being prepared for this with a prebuilt solution is the only way to avert such a crisis.
Problems to Overcome with Any Solution
- Many "next-generation" telephony/mobile application firms that are receiving funding right now use Caller ID as a key to their services. I don't think their investors have been shown the potential for fraud yet or understand the threat of legislative hysteria. Hasn't everyone learned from the calling-card business yet?
- The PSTN cannot turn on a dime and restrict ANI/CLID from many clients using "whitelist" filters. Caller ID manipulation is used too widely for completely legitimate purposes, and any firm providing interconnection will almost always ask for a removal of the ingress filter when sending calls to another carrier. I believe that a "check-ahead database" that is consulted before call completion at any/every border is unworkable as a matter of cost and willpower.
- Most firms are unwilling to participate in a system where their user data or CDRs with user relationships are centrally managed, as they have serious legal and commercial privacy concerns about the control of that data.
So clearly we have a looming problem. There does not seem to be a feasible solution that works on the front-end (authentication before completion.) And there is a legitimate fear of centralized databases, since many of the service providers don't want to expose their customers to an unknown trust element in the center of the network ("Wait!" you say. "You mean we can't trust AT&T not to give our records to the NSA?"). Legislation will happen if nothing else is inserted into the vacuum, and it will be far more unpleasant than that which is currently proposed. So, what to do?
Pages: 1, 2