“The set of subscription-based voice services and features provided over carrier-managed packet networks, and includes wireline and wireless services.”

The document covers such surveillance events as:

• Registration and Authorization events including address registration and de-registration, mobility authorization and de-authorization
• Call Management events including call origination, termination, answer, call release, address resolution, admission control, and media modification
• Signaling events including subject signaling, network signaling, and post-cut-through dialing and signaling
• Feature Use events including call redirection, party hold, party retrieve, party join, party drop, call merge, and call split
• Communication Content events including content delivery start, change, and stop, as well as content unavailable
• Feature Management events including feature activation and deactivation
• Surveillance Status events including surveillance activation, continuation, change, and deactivation.

The document also discusses authorized access to identifying information and communication content, and more generalized surveillance requirements. It looks like they’ve fairly well covered the bases…

At a VON Europe panel this week, Cullen Jennings, Distinguished Engineer at Cisco, was talking about peer-to-peer (P2P) SIP, and how the P2P approach definitely helps with location privacy. He gave the example of emergency procedures in the USA, which require the country’s President and Vice President to be in different physical locations from each other yet still be able to communicate. At the same time, they must prevent eavesdropping enemies from locating the Vice President physically.

I said that ‘P2P helps’, but perhaps I should say ‘can help’, with the right systems in place. In the UK last week, Sky News ran a story about how criminals might use encrypted VoIP to run circles around the police, due to the difficulty of tapping and listening to the calls. I hope to be able to write in more detail in the next few weeks why this is basically untrue, but the information I have received is that the VoIP providers “can be very helpful” to the police in these cases. Even if a VoIP stream cannot be decrypted, it is often possible to obtain a list of times, durations, and IP addresses that can easily provide both location and evidence. Also, if a VoIP call breaks out onto the PSTN, a service offered by many or most VoIP telcos, then once again you have a location (albeit the call destination rather than the source), and you have the opportunity to monitor the call.

No-one likes to think that all their calls are being tracked, or that their location is known at all times, but of course in democratic countries we assume that there are enough checks and balances to ensure that this information is available to few and will not be abused. At the same time, criminals and terrorists should not assume that new technologies like VoIP and IM give them a cloak of anonymity, because this is definitely not the case.

It’s only a few years ago that MI5 were first allowed to openly advertise jobs (which makes you wonder what the recruitment process was before), but now they have a pretty nice website, which makes it much easier to see what the whole setup is about.

But it appears from its legal maneuvers that the FBI may also want to find a way to tap peer-to-peer calls, the ones that bypass the telephone system. And the FCC’s analysis of the FBI request suggests it might go along with a move to require wiretapping on any new Internet communications system.

Which leads to the obvious question of how a p2p system would actually do this… which leads to the opinion that some centralization would be required… which leads to the conclusion that this could therefore kill p2p VoIP systems in their true p2p form. The article refers people over to the Center for Democracy and Technology CALEA page where the CDT has copious amounts of info about CALEA (obviously from their point-of-view). Takahashi concludes with:

We have to balance the need to enforce laws with the need to move technology forward and at the same time protect our privacy. If we hobble technology to help law enforcement, we make ourselves vulnerable, not safer.

We faced this kind of issue in the early 1990s, when the debate was about whether to allow encryption technologies strong enough to hide data from the government. The government later decided to allow strong encryption to be used unencumbered, particularly as the technology was allowed overseas. The outcome here may be the same.

Given that VOIPSA is a global organization that encompasses a wide range of companies, people and geographic regions, its not really our place as an organization to wade into the debate of legislation in one particular country. But it is definitely a matter that does merit discussion and attention. There are very legitimate needs by law enforcement. There are also very legitimate privacy concerns – and security concerns. Where do we as nations, companies and individuals strike the balance?

]]> http://voipsa.org/blog/2007/02/05/mercurynewscom-will-us-wiretapping-regulations-kill-peer-to-peer-voip-like-skype/feed/ 1 http://voipsa.org/blog/2007/01/18/lawful-intercept-and-crocodile-clips/ http://voipsa.org/blog/2007/01/18/lawful-intercept-and-crocodile-clips/#comments Thu, 18 Jan 2007 12:14:54 +0000 Martyn Davies http://voipsa.org/blog/2007/01/18/lawful-intercept-and-crocodile-clips/ Those interested in the topic of Lawful Intercept (LI) and CALEA might be interested in a new blog over on the TMC site.  Scott Coleman of SS8 is writing a new column called Demystifying Lawful Intercept and CALEA.  The cunningly-named SS8 market a number of products including LI solutions. And no, LI is not done with crocodile clips.

]]> http://voipsa.org/blog/2007/01/18/lawful-intercept-and-crocodile-clips/feed/ 0 http://voipsa.org/blog/2007/01/10/building-a-voip-network/ http://voipsa.org/blog/2007/01/10/building-a-voip-network/#comments Wed, 10 Jan 2007 15:25:43 +0000 Martyn Davies http://voipsa.org/blog/2007/01/10/building-a-voip-network/ Dean Elwood, one of the founders of voipuser.org (a free VoIP service provider and online magazine) recently wrote an interesting article called “How To Build A Voip Network: 7 rules for the VoIP entrepreneur in 2007.“  It’s a great read from someone with experience of creating value from a VoIP service, rather than the usual marketing “talking head”.  It also raises some interesting VoIP security questions, including Session Border Controllers, Lawful Intercept, Denial of Service and confidentiality.

]]> http://voipsa.org/blog/2007/01/10/building-a-voip-network/feed/ 1 http://voipsa.org/blog/2006/11/28/nsa-warrantless-wire-tapping-to-be-investigated/ http://voipsa.org/blog/2006/11/28/nsa-warrantless-wire-tapping-to-be-investigated/#comments Tue, 28 Nov 2006 11:15:34 +0000 Martyn Davies http://voipsa.org/blog/2006/11/28/nsa-warrantless-wire-tapping-to-be-investigated/ CBS reports here that investigators have been given the go ahead to look at the NSA’s wire-tapping programme.

 

]]> http://voipsa.org/blog/2006/11/28/nsa-warrantless-wire-tapping-to-be-investigated/feed/ 0 http://voipsa.org/blog/2006/11/21/click-to-harass/ http://voipsa.org/blog/2006/11/21/click-to-harass/#comments Tue, 21 Nov 2006 23:26:19 +0000 Dustin D. Trammell http://voipsa.org/blog/2006/11/21/click-to-harass/ Various “Click to Call” services have begun to emerge recently, bringing with them some very interesting and questionable service behavior. In a nut-shell, Click-to-Call provides a website user with a button that they can click to initiate a voice session with the website or business, such as a customer service department. Most of these types of services work in a similar way with only minor variations; when a user clicks on the click-to-call button or link, the user is asked for their phone number. The “called” party’s phone system or click-to-call provider then essentially initiates a 3-way call, first calling the website user at the number they provided, then once the user answers, connecting that call to the number of the business or website owner. In most cases these sysetms spoof the Caller-ID of the called party toward the user and may or may not spoof the Caller-ID of the user toward the callee.

Google has recently introduced their Click-to-Call feature for Google Ad-Words, as well as adding it to Google Maps, allowing users to “call” businesses found on their ads or maps directly from the website. When a user selects a location on a Google map and then clicks the “call” link next to the displayed phone number, Google prompts the user for their phone number and the call progresses as described above.

While investigating Google’s implemenation of this feature on Google Maps, I also noticed another feature that I hadn’t noticed before. Google Maps allows you to forward the location’s information such as name, address, and phone number to a mobile device via SMS. It works much the same way as their click-to-call service in that via the location description you click the “send to phone” link and enter your phone number so that Google can forward the information via SMS.

Currently Google seems to have restricted their service to AdWords advertisers and people who are paying for this servcie, however other systems also exist that provide much the same functionality without the “called” party being aware of what is happening or even expecting it, resulting in cases where their Caller-ID information may be spoofed toward the “calling” party’s number, which may or may not actually be the person that initiated the call via the website’s click-to-call form.

The inherent problem with Click-to-Call and similar services is an amplified version of one of the most prevalent current problems with VoIP overall; general lack of verifiable user identity. Not only are users of click-to-call services usually not required to authenticate with the site before clicking-to-call, they are allowed to provide their own call-back number which usually isn’t verified in any way. Then, to make things worse, a role-reversal happens where the entity that would normally be the receiver of the call becomes the initiator of the call, or at least the 3rd-party assist mechanism initiates, potentially spoofing one or both of the other parties as the initiator.

Remember when BBS systems back in the day started requiring user phone number verification by not allowing users to register or activate their accounts until they provided a call-back number and let the BBS connect back to them? Yea, there was a reason many boards stopped doing that, or at least severely restricted what numbers they could call back… Nobody likes a modem calling them up in the middle of the night and screeching in their ear, especially victims of a BBS call-back system that was fed their number by some punk kid at 3am. I’m going to go out on a limb here and say that most people also won’t like answering their phone to find a ringing line, which is then answered by Joe’s XXX Empornium, or possibly their Ex-girlfriend.

There was a recent discussion relating to Caller-ID on the VoIPSec e-mail list centered around what acceptable uses for Caller-ID information are, if there are legitimate cases in which Caller-ID should be able to be spoofed, and if Caller-ID really provides any value as an identification of the calling party (or more accurately, the calling line’s owner). At first glance, the spoofing of Caller-ID in either direction of a 3rd-party assisted call would seem to make sense; once the call is established the 3rd-party (human operator or automated system alike) is usually no longer involved in the call other than perhaps maintaining the connection, so the information of the two parties remaining involved is what is used as Caller-ID. However, while the website user originally initiated the call by clicking on the click-to-call link, either the called party or a 3rd-party assist mechanism is actually initiating the call via the phone system, potentially from the “called” party’s line or equipment. What could this potentially mean for the accuracy of call records when subpoenad in a legal battle? “No, Detective, they called ME, I never initiated any coorespondance with them at all…” Unless the business or click-to-call provider is keeping complete and accurate records of which calls were initiated by whom at what internet address via this system, select call records could prove to be questionable. When combined with the lack of user identity required by most click-to-call systems, unless an ISP is willing to get involved there will be a difficult time of attempting to track down who actually initiated any given call that was completed in this manner.

In my opinion, not only do “Click-to-Call” services in their current forms open up a huge can of worms technically, but when they start employing what is essentially a vulnerability in VoIP systems such as the ability to spoof Caller-ID in order to mask what is actually taking place from the parties involved in the call, the potential for abuse sky-rockets. On the positive side however, I guess 3rd-party assisted calls provide an excellent middle-man monitoring point for the spooks, Customer Support Quality Assurance, and anyone having to comply with CALEA. (:

]]> http://voipsa.org/blog/2006/11/21/click-to-harass/feed/ 3 http://voipsa.org/blog/2006/11/17/100-top-voices-of-ip-communications/ http://voipsa.org/blog/2006/11/17/100-top-voices-of-ip-communications/#comments Fri, 17 Nov 2006 17:14:45 +0000 Martyn Davies http://voipsa.org/blog/2006/11/17/100-top-voices-of-ip-communications/ The October edition of Internet Telephony Magazine (free download can be found on the TMC website) names the 100 Top Voices of IP Communications.  A nice list of industry thought leaders, including VOIPSA Chairman, David Endler.

The same issue also has an article about CALEA, if that floats your boat. 

 

]]> http://voipsa.org/blog/2006/11/17/100-top-voices-of-ip-communications/feed/ 0 http://voipsa.org/blog/2006/10/11/just-plain-cuckoo/ http://voipsa.org/blog/2006/10/11/just-plain-cuckoo/#comments Wed, 11 Oct 2006 16:13:04 +0000 Martyn Davies http://voipsa.org/blog/2006/10/11/just-plain-cuckoo/ According to news in PC Pro magazine, authorities in Switzerland have come up with an unorthodox plan to tackle call tapping of Skype and other VoIP users.  VoIP calls can be end-to-end encrypted, which means that tapping on the Internet itself is often not practical.  For example Skype use an undisclosed encryption algorithm and key exchange system.  Phil Zimmermann’s Zfone employs perfect secrecy so that the conversation cannot even be listened to later offline when the encryption key has been obtained.

So the Swiss plan?  Tap the calls on the PC, by means of installing some kind of trojan to tap into the audio stream before it is encrypted.  It would be installed either by the authorities or remotely by the ISP.

Now, this is a daft idea on so many different levels that it’s hard to know where to begin.  In an ordered society like Switzerland you could expect a high level of compliance with this kind of procedure.  Unfortunately, the ones that won’t comply (for example malevolent hackers; gangsters; terrorists) are probably the ones that you are most interested in gathering intelligence about.  Secondly, it’s a gift for criminals, since if you leave a backdoor open, the PC already compromised, then someone will likely exploit this for criminal purposes.

With the right software in place, audio could be relayed in from elsewhere, allowing criminals to make calls “on your phone”, possibly implicating you in a crime.  Similarly, audio could be relayed out, so that those outside the government service could tap your phone, a boon to tabloid newspapers and blackmailers.

Finally, in a world of ever more mobile users, is this approach even practical?  Mobile users with GPRS in their phone or PDA can connect to the Internet without even touching a Swiss ISP.  Crime doesn’t necessarily stop at borders these days, couldn’t criminals just be in and out of the country before the G-Man sneaks some tapping software onto their laptop?

 

 

]]> http://voipsa.org/blog/2006/10/11/just-plain-cuckoo/feed/ 0