Illegal Wiretapping - Not so Easy

Recent news coverage of the Greek cell phone wiretapping scandal should put to rest some of the fears that people have over illegal wiretapping. Renewed interest in this story was sparked by an extensive analysis in the IEEE’s online magazine Spectrum (http://www.spectrum.ieee.org/jul07/5280 ). The article describes in detail how an illegal wiretapping operation existed in Greece, at cell phone carrier Vodaphone, for over nine months. In reading the news coverage and the IEEE article “The Athens Affair “ by Vassilis Prevelakis and Diomidis Spinellis, one can’t help but be amazed at the significant effort it took to illegally take advantage of the lawful intercept capabilities that existed on the phone switches.

Please understand that I’m not talking about the now infamous “warrant-less wiretaps” done by the Bush administration but rather the illegal use of technology to wiretap individuals where no authorization, warranted or otherwise, existed (except maybe in the mind of the perpetrators) to do the wiretaps.

For a long time now, skeptics have claimed that having an automated, centralized, standardized platform for performing lawful intercept, at carrier locations, actually creates a security risk rather than reducing it. The argument concludes that if a lawful intercept system is easy to use by the phone carriers, then surely the bad guys out there will be able to easily defeat the system and manipulate it to their own ends. On first glance the Greek incident seems to support this concern.

In fact, a report last year from the Information Technology Association of America (ITAA) raised that very issue: “Designing wiretapping into the communication system raises a fundamental security issue: can the capability be controlled so that only authorized parties can employ it?” However, the report concluded that for traditional wired and wireless telephony, such as the Greek Vodaphone system, it wasn’t a problem. The ITAA study even referenced the Greek incident and concluded that information available at the time pointed to an inside job instead of a malicious outside hacker.

The IEEE report carefully and fully reveals the lengths taken to achieve this feat, and justifies the assertion that this was not a trivial or easy thing to do. Through this revelation it becomes obvious just how much time, commitment, expertise and undetected access had to be garnered in order to defeat a system like this.

The experts will tell you there is no such thing as an absolutely impregnable system; rather, security is really a matter of making a system sufficiently difficult to breach. Hacking the Vodaphone system was certainly no cakewalk and it would be very difficult to replicate. Consider these four factors:

Time – significant time planning, designing and writing software went into this effort. This wasn’t an afternoon or weekend project someone thought they would throw together.

Commitment – since the software development work had to have gone on for weeks, if not months, surely this was a very committed effort and not an amateur’s hobby or prank

Expertise – the software used in the Ericsson switches is not a common programming language that the average software developer off the street can be successful with. In fact very few people know the language or the design of the system well enough to write code that will work, never mind secret code that is undetectable.

Undetected Access – again this is not something readily available to the public, it took the right person in the right position to gain access to the systems.

Even just looking at these factors quickly, the argument about how secure these solutions are becomes self-evident. Clearly this is not the stuff that the average bad guy or even organized crime could pull off. Based on this evidence the general public in Greece, the rest of Europe, North America, Asia or any where else in the world where these systems are used, should be reassured that they are secure and when used properly, can certainly benefit them.

Till next time ... (when I will return to Data Retention as I promised in my last post)

Google's Data Retention Policy Under Scrutiny and part of a Contradiction

Not only Google but now the data retention practices of all the big search engine companies (Yahoo, Ask etc.) are being reviewed. This is mainly coming from the European community, with Spain being the latest to announce an investigation.

Generically, data retention is the storing of communication session related information. This amounts to call data records in the telephony world and transaction logs (from routers/switches) in the IP world, with the possibility of also storing things like URLs and email headers. The point of these policies is to be able to determine, after the fact, who was communicating with whom and what sites were being visited. Data Retention policies do not include storage of the actual content of the communication or the information that was viewed/retrieved from a website but they do store information for all subscribers. This type of information proved to be very useful in investigating incidents like the Madrid train bombing and the UK subway bombing.

So why would a search engine company need this info? Presumably it is used to improve the accuracy and appropriateness of searches. Not only the searches of individuals based on previous searches but also the searches of people that fall generically into similar groups. Example: I search for "limousines in Connecticut" because I live in Connecticut and need a limousine, but out of the search results that are returned I pick the company that goes to New York City and so do a majority of other people. So this information can then be used to "tune" the results of future requests for people looking for limousines in Connecticut because they are probably either going to the airports in New York or the theater district in NYC for a show.

Ok, so they are storing my information and using it to improve their product, what is the problem? Well, there are very strict privacy protection rules in place in Europe that dictate how long information can be stored, who can view and how it can be used, so advocates for the different countries are trying to balance those requirements (which may have been on the books for many years now) against the commercial needs of today's service providers.

The thing that makes this even more interesting (and here is the contradiction), there was an EU Directive passed in March of 2006 that requires all EU member states to pass specific, national legislation supporting Data Retention of telephony service providers and ISPs. It requires, among other things, the telephony service providers to store call data information for two years and ISP event data for 6 months. The deadline for passing legislation is September 15th of this year with implementations starting in March of 2008.

So while the EU community is examining practices and working with the search engine companies to reduce the amount of data retained, they are at the same time under the gun to pass legislation that requires service providers to store more information.

This is a fairly broad subject and I'll continue on this subject in my next post. Till then ...

National Security Letters and the FBI

There has been a lot of hub bub this week over the FBI's use of National Security Letters and the Dept. of Justice's audit that was performed revealing that in over 1000 cases incorrect or additional information was collected.

A couple of points on this issue stood out in my mind:

1. The Audit concluded that in none of the cases did the agents intentionally over-collect info
2. Most of the extra information provided was done accidentally by the service provider / enterprise
3. This really had to do with static subscriber information not dynamic call information, which really means it had little to do with lawful intercept/wiretapping since addresses etc. are not provided as part of electronic surveillance

So if it wasn't intentional, how did the over-collection (providing) of information occur?

Now I don't have specifics on the actual use and implementation of the NSLs in these cases but if we look at the way CALEA based wiretapping is done and compare it to the use of the NSLs, you can draw some conclusions on what might have happened and why the over-collection occurred and why it doesn't occur for CALEA based wiretaps.

In CALEA based electronic surveillance, the fundamental concept is that the information is collected in real time as the communication session occurs. If that is to happen then specific target identifiers need to be articulated, the type of information to collect and directions on where to send the information need to be provided, otherwise the systems simply won't work. As long as those directions are followed then the system rules (not a person) within the Mediation/Delivery Functions control what information can be sent. In addition the protocols and standards (J-STD, PacketCable, ATIS etc.) only allow certain information, in specified parameters, with specified formats to be sent. And finally the collection function at law enforcement only accepts information that follows the prescribed formats and standards. Using this methodology, the information provided to law enforcement is very specific and well documented and significantly reduces the possibility of over-collection. Obviously over-collection could occur if someone put in the wrong end date etc. but in general the system has many checks and balances to ensure that CALEA based intercepts provide exactly what is permitted.

In contrast, the NSLs were more free form in their directions and use, and didn't have well established industry standards to fall back in the collection and delivery of information to law enforcement. It fell to the knowledge and capabilities the person receiving the NSL to determine what information was appropriate to send, how much to send and how to send it. Since it was determined that this was not intentionally done, clearly the problem was with the process and not the intention.

Till next time ...

DoJ Files Deficiency Petition with FCC over J-STD-025B

On May 15th 2007, the Dept. of Justice (as represented by the FBI, DEA and National Security Division) filed a "Petition for Expedited Rulemaking to Establish Technical Requirements and Standards Pursuant to Section 107(b) of the Communications Assistance for Law Enforcement Act", specifically in regard to J-STD-025B where it covers CDMA2000 packet data wireless services.

So what does this mean? Section 107 of CALEA covers the "Technical Assistance" portion of the CALEA law and during 2003 when the TIA and ATIS standards bodies were developing the JSTD25B standard, Law Enforcement (represented by the FBI at those meetings), raised several concerns over what they felt were technical deficiencies in the standard. Those concerns were never adequately satisfied in their opinion but the standards bodies moved forward anyway and the standard became effective in January of 2004. In March 2004 the standard (which at that point was only a "Trial Use" standard) was submitted for ballot to become an ANSI standard. In August 2006, J-STD-025B was adopted as an ANSI standard. At that time Law Enforcement began formulating a response to articulate the deficiencies they felt were still part of the standard. On May 15th (coincidence that it was the day after the May 14th deadline for Broadband and VoIP compliance? Probably not) they filed their official request for rulemaking to address these technical concerns.

So what are they asking for? On the technical side they are asking for 4 things:

1. Addition of Packet Activity Reporting - this would provide, among other things, the protocol in use, the Originating and Terminating IP address, the IP version and the Port number. The same types of things that are available as Call Data (or CII) for circuit switch calls today

2. Timing Information (Time stamping) - currently J-STD025B does not require any time stamping and they would like it to match the guidelines set forth by the commission for circuit switch time stamps (time stamp within 200ms and delivery to the LEA within 8 seconds).

3. More granular Location Information - currently cell site and sector are available but with the proliferation of location based services, it seems that more granular location information would be "reasonably available" (the metric used to determine what LI information can be made available to law enforcement).

4. Increased Security, Performance and Reliability of Delivery - these are fairly wide ranging items but the bottom line is that they want established rules over the protection of sensitive information and processes (internal as well as technical), along with assurances that they are receiving all of the packets from a communication session

On the process side, they are looking for an expedited ruling from the FCC along with a compliance deadline of 12 months after the FCC makes its' ruling.

Last week's ISS World conference didn't shed any new light on the subject even though the FBI, FCC and DEA were all represented there. They continued to reference the filing and the information contained within it.

So what does the timeline and next steps for this look like? Well this process has been followed before with both the Report and Orders over Broadband and VoIP compliance and with the original J-STD-025 (which is why J-STD-025A now exists). There is a response/comment period that is now underway and that will lead to a review period by the FCC. There is also a possibility that a second round of response/comments and review will take place. At some point the FCC will make a ruling, this will probably be somewhere between 8 and 18 months away. When the ruling occurs the standards bodies can then address the content of the ruling and implement any necessary changes to the standard. I say "necessary changes" because remember, as I noted above, this has happened before and just because capabilities are requested doesn't mean they are automatically granted. The original request for additional capabilities for J-STD-025 was for 11 items but only 7 were actually granted in the "Punchlist".

So how long will the changes to the standard take? Again it depends on how the FCC rules, but most likely 8 - 12 months. Which then begs the question, if compliance needs to be achieved within 12 months of the ruling but the standards body may take up to 12 months to modify the standard, how will compliance be achieved on time? Sound familiar?

Till next time ...

What is a Mediated Probe?

I've talked about probes in the past, both in the context of Active vs. Passive and with regard to doing VoIP intercept. And now as the May 14th date for compliance approaches for both broadband and VoIP providers, I'm taking a look at another category of probe, the Mediated Probe, since they seem to be popular with the ISPs.

As noted in previous entries, probes are typically used to fill a need when the network isn't able to provide Access to intercept traffic or if in some cases the network solution isn't cost effective. However, this new comer to the space tries to combine both the Access and Delivery (Mediation) components of the LI architecture into one device (harkening back to the days when switch manufacturers were putting an LI solution on every switch instead of letting the service provider own and operate one solution). Utilizing some type of packet sniffer or "Deep Packet Inspection" technology (the new buzzword for probes) the Mediated Probe identifies and replicates the traffic but instead of sending it to a central Mediation platform for correlation, formatting and delivery to the LEA(s), it sends it directly to the LEA.

This sounds reasonable but there are again several concerns, just like there were for probes in a VoIP environment. First concern is what if I need more than one probe? Law Enforcement now needs to connect to all the deployed devices? Second, what if I offer more than one type of service (VoIP, broadband, wireless data etc.)? How do these services get correlated and do I need a second solution for the other types of services? Will all delivery standards be supported on the probe or just a select one or two? What if there are multiple intercept access points for a session? Is this technology really an LI solution or is it some other kind of technology morphed to take advantage of the May 14 deadline?

Now it isn't all bad news as these products do have a place. For very small carrier's (ISPs) that only plan on being an ISP and don't want to offer other services, this may be a viable solution for them. A small compact, and theoretically, cost-effective solution.

So as long as you recognize what your needs are and what the limitations of a Mediated probe are, it could be a solution for you.

Till next time ...

New LI Standard for ISP data

On April 2, 2007, the ATIS Standard on Lawfully Authorized Electronic Surveillance (LAES) for Internet Access and Services (ATIS-1000013.2007) was approved. This standard has been defined primarily for use in the US for broadband (ISP, WISP) service providers in response to the FCC’s 2005 and 2006 Report and Orders. Those Report and Orders require all “facilities based broadband and interconnected VoIP” service providers to be CALEA compliant by May 14, 2007 (which is just around the corner). The FCC issued the Report and Orders after the FBI, DOJ and DEA filed a joint petition outlining the need to access communications deemed “information services” in the original CALEA legislation. Clearly broadband services today (email, video, chat, VoIP etc.) are no longer the one way data access “information services” that defined the internet in the early 90’s when CALEA was passed.

This standard is the latest standard to be adopted globally and is in keeping with international trends to keep law enforcement’s capabilities current with advancing technologies. The European standards body (ETSI) adopted a similar “data” standard several years ago as legislation there has existed for many years, with the Netherlands leading the way and passing legislation in 2001 that defined the very first data standard which was TIIT (Transport of Intercepted IP Traffic).

As would be suspected, like other standards, the ATIS standard covers the Handover interfaces (HI-2, HI-3) between the Mediation (Delivery) Function at the service provider and the Collection Function at law enforcement. Historically HI-2 for US standards has been primarily tasked with delivering call/signaling data (start of call, DTMF digits, call waiting signals etc.) for voice calls but obviously in the world of IP/data communications, the character of those “call” data messages has changed. In this standard the HI-2 data messages focus on network “access” (Attempt, Reject, Session End, Failed etc.) and “session” progress (Start, End, Failed, Already Established).

In addition, HI-3 has been defined to carry the “content” of the session. Again traditionally in a voice world this carried TDM voice (wireless or wireline) but now it is carrying the packets of the broadband sessions so that they can be recreated at the LEA.

Other standard bodies also continue their work, including PacketCable for PacketCable 2.0 (VoIP and data), ATIS-PP-1000678.2006 for wireline VoIP, and TIA-1066 for VoIP in CDMA networks.

As things evolve I’ll keep you posted. Till next time …

How Long Do I Get To Implement A Wiretap Request?

As carriers and service providers new to the world of Lawful Intercept start to implement their LI solutions in order to meet the May 14, 2007 deadline, one question that gets asked repeatedly centers on how fast an individual court order needs to be implemented. While no specific requirement exists, expectations do. And these expectations do not include a “10 day grace period for broadband intercepts” that is rumored to exist.

In seeking and receiving approval for a wiretap (typically a lengthy and intensive process) law enforcement and the court system assume that given the amount of work put into it, that it will start as soon as possible. In fact, the directions given to the carriers on the court order provide both a start and end date and instruct them to implement the intercept “expeditiously”. This is important because the start and stop dates bound the duration of the wiretap and everyday spent waiting for the wiretap to start is one less day law enforcement has to work on the investigation.

Normally with an active solution (see earlier entries) starting the intercept quickly isn’t an issue but as carriers consider “just in time” passive solutions, that include moving probes from one location to another, time constraints may become a consideration. Just in time solutions can prove to be a cost effective solution for carriers, but certain implementation strategies may not meet the intention and desire of law enforcement for an expeditious start to the intercept.

Till next time …

Do Probes Provide Complete Solutions for VoIP?

In my last entry I talked about Active vs. Passive intercept and the use of probes from a high level perspective. In this entry I want to identify a couple of cautions with regard to the use of probes to intercept VoIP calls.

Probes can be useful in VoIP LI solutions when positioned appropriately in the network. Typically they will need to be deployed to capture both the content (near the edge of the network) and the signaling (near the core). However, even with the appropriate positioning of probes they most likely won't be able to capture all call scenarios.

One of those scenarios includes calls that are forwarded or redirected off of the carrier's VoIP network to the PSTN (or any other network for that matter). In this scenario, the target has forwarded his phone to a number off of the VoIP carrier's network. An associate then calls the target's phone, the target's network determines that this call is forwarded to a number off of its' network and immediately redirects the call back out to the PSTN for proper termination. In this scenario the call content only reaches the gateway at the edge of the network and a probe solution wouldn't be able to access it.

Another area of caution includes the carrier's responsibility to provide Dialed Digit Extraction (DDE). DDE was one of the Punchlist requirements established with J-STD-025A. This requires that any DTMF digits entered during a call be identified, isolated and sent to the LEA as Call Data. Preferably these digits are extracted from the in-band content so that they can't be spoofed. Most probes don't have any DSP resources and therefore can not extract these digits and send them to the LEA as required by J-STD.

Just a few more reasons to make sure any investment in an LI implementation is comprehensive in nature and covers all scenarios, not just most.

Till next time ...

Doesn't a Probe actively intercept traffic?

When deciding on the proper technique for implementing an LI solution, quite often the question of "Active" vs. "Passive" comes up, especially in IP based networks. In order to understand what this means we have to understand that in lawful intercept parlance, Active and Passive have their own meanings.

An active solution is one in which the Mediation/Delivery Function has a defined interface with an Access Function (network element: router, SBC, switch etc.) that allows provisioning of target information, the exchange of session information and the replication of communication traffic (example: Cisco SII). This interface is called "active" because the network element (AF) is actively identifying and replicating target traffic based on requests from the Mediation Function (MF). Since the connections between the AF and MF are typically IP based, no special connectivity is needed and the AFs can be activated very quickly.

A passive solution employs a probe (sniffer) to identify and replicate traffic. To gain access to network traffic the probe requires either a network tap (like NetOptics) or a "SPAN" type of interface. The probe then uses the same targeting information to dynamically identify and replicate traffic. It isn't called a passive solution because it isn't actively working; it is passive because it isn't an inherent part of the active network and it sits outside of the network looking in.

Both solutions have pros and cons; an active solution is quickly implemented but only works on certain models and may require software upgrades. Probes can be expensive but are easily moved around a network and don't care about software releases or models of equipment.

Active = network element with support for a lawful intercept interface
Passive = probe attached to the network but not actively involved with network switching

Till next time ...

Filing date for CALEA "Monitoring Report" upon us

Everyone involved in CALEA and Lawful Intercept should be well aware of the May 14 CALEA compliance deadline for "facilities-based broadband" and "inter-connected VoIP" providers. But one of the other intermediary dates is fast approaching (only 11 days to go). February 12th is the deadline for the filing of Monitoring reports. And as such I thought a quick refresher and review of this form and its' purpose might be useful.

Back on December 12th the OMB (in compliance with the Reduction in Paperwork Act) authorized the FCC to move forward with requiring service providers to file Monitoring reports. The FCC's declaration of the approved dates and the forms themselves can be found at the link below.

http://www.fcc.gov/Daily_Releases/Daily_Digest/2006/dd061214.html

and look for:

Released: 12/14/2006. OMB APPROVES CALEA COMPLIANCE MONITORING REPORT FOR PROVIDERS OF FACILITIES-BASED BROADBAND INTERNET ACCESS AND INTERCONNECTED VOIP SERVICE; REPORTS ARE DUE FEBRUARY 12, 2007. (DA No. 06-2513). (Dkt No 04-295). PSHSB. Contact: Thomas J. Beers at (202) 418-0952 DA-06-2513A1.doc DA-06-2513A2.doc DA-06-2513A3.doc DA-06-2513A1.pdf DA-06-2513A2.pdf DA-06-2513A3.pdf DA-06-2513A1.txt DA-06-2513A2.txt DA-06-2513A3.txt

The reason for the Monitoring Report (445 form) filing is so that law enforcement understands the progress being made by carriers to reach compliance. In the late 90's when carriers were working to reach compliance for the first CALEA deadline(s), law enforcement had no idea where everyone stood until the deadline was reached. This time they are requiring "progress" reports to give them a better idea of where things stand.

For a 445 filing, there are 3 relevant documents:

DA-06-2513A1 - this describes the ruling and the fact that the Office of Management and Budget has now fulfilled the requirements of the Reduction in Paperwork Act (the item that held the dates up to begin with) and the reports can now be filed

DA-06-2513A2 - This is the instructions document. This describes each of the lines in the actual 455 form, what should be filled in, where copies are to be sent and by when.

DA-06-2513A3 - This is the 445 Form itself. This is a brief 4 page document with 12 line items (the first 7 really don't count) to fill in and a small glossary. No essay questions, no multiple choice, no true/false, just simple questions as described below.

Form 445 Questions:

1 -7 Contact information: Name, State, FCC #, 499 Id, affiliate names, parent company, address

8. Will your networks be compliant by May 14?
Type of facilities

9. Which networks will not be compliant?
Type of facilities
Expected date to reach compliance
Reasons for delay

10. Compliance Method(s) being used
Industry standard
Proprietary/custom
Consultation with DOJ
TTP If so which one?

11. What items are causing delays?
Type of Equipment
Installation
Manufacturer
Other
Mediation Actions being taken to resolve the delays

12. Signature of company officer


So all in all pretty simple. Take a look and feel free to comment. Till next time ...