CALEA Communications Assistance for Law Enforcement Act

1. CALEACommunications Assistance for Law Enforcement Act Columbia University, Dept of Computer Science COMS W4995: VoIP Security December 3, 2008 John Morales

2. Outline • History and motivation • Implication for VoIP • IETF’s Position • Current Research • Implication for greater Internet • Resistance Clay Bennett, Christian Science Monitor, http://www.csmonitor.com/news/cartoonClassics.html

3. CALEA History • U.S. Wiretapping law, enacted January 1, 1995 • Purpose: • “…to make clear a telecommunications carrier's duty to cooperate in the interception of communications for Law Enforcement purposes, and for other purposes.” • Intended audience: “telecommunication carriers” • “Common Carriers” (Ma Bell) • ISPs • VoIP?

4. CALEA Participants? OK, so what does “interception” mean? • Able to wiretap any conversation for listening • Save call detail records (dialer #, receiver #, time, duration of call) • Parties cannot discover when this is happening. (Duh.) Fine, but “telecommunication providers” is so fuzzy! • “First Report and Order” (Sept 2005) • Facilities-based broadband ISPs are covered • PSTN-interconnected VoIP services are covered (Vonage = YES, Google Chat = NO) • “Second Report and Order” (May 2006) • Providers can meet requirements via Trusted Third Parties • Carriers have to foot the bill, cannot pass surcharge onto customers

5. IETF Weighs In • RFC 2804 (2000) • Will wiretapping considerations be included in standards? • Nope • “[The IETF is] the wrong forum for designing protocol or equipment features that address needs arising from the laws of individual countries…” • Comment on moral position? • Nope • “The IETF…is not in a position to dictate that its product is only used in moral or legal ways.”

6. IETF Weighs in (Observations) • RFC 2804 does highlight some observations: • Copying bytes between two known, static internet endpoints is a solved problem. • Associating identities with network endpoints is the hard problem. • (Just ask RIAA/MPAA) • Easy to circumvent: • Anonymous proxies • Use public “Internet cafes” • Encryption

7. Current Research - Jan Seedorf Lawful Interception in P2P-Based VoIP Systems (IPTComm 2008) • SIP difficult to intercept • Signaling and media take different paths. • BUT, can still be done; something’s centralized • Network provider and VoIP provider could be same. • If different, might have SBC to force signaling to central server. • If no SBC, get IP address and request ISP snoop in real-time. • However…

8. Current Research (Cont’d) – P2PSIP Lawful Interception in P2P-Based VoIP Systems Wicked stepsister: P2PSIP • No centralized server for call setup. • No single service provider for intercept. • P2P Networks are dynamic! • Can't try to snoop on who has which registrations; adjusted frequently. • Can’t even know first hop a priori!

9. Current Research (Cont’d) – Potential Solutions Main problem: lack of centralized place to intercept signaling • At least 4 Possible Solutions 1.)Put bugs in all devices. Access to incoming and outgoing voice at endpoints. • Deals with mobility; media monitored at device, not in network. • Can ignore network topology (P2PSIP). • SIP and P2PSIP are open standards; softphones could have bug stripped out. • Hardphone firmware could be hacked to strip out bug.

10. Current Research (Cont’d) – Potential Solutions Main problem: lack of centralized place to intercept signaling 2.)Intercept at IP layer Stateful Packet Inspection (SPI) to intercept all target’s traffic • Feasible if target often uses same ISP. • Have to know ISP of target a priori to initiate LI request. • All ISPs would need to participate and have SPI hardware. • i.e., Time & Money Image: Banksy, http://www.dailymail.co.uk/news/article-559547/Graffiti-artist-Banksy-pulls-audacious-stunt-date--despite-watched-CCTV.html

11. Current Research (Cont’d) – Potential Solutions Main problem: lack of centralized place to intercept signaling 3.) Follow Hollywood’s Example Have fake P2P nodes in network watching. • Good if want to find some traffic. • Some always better than none. • Difficult to monitor any traffic; to cover all nodes, must have: • Detailed knowledge of DHT (non-trivial problem) • Nodes strategically placed for coverage (non-trivial problem) “…we quantify the probability of a P2P user of being contacted by such entities [and] observe that 100% of our nodes run into entities in these lists.” A. Banerjee, M. Faloutsos, L. Bhuyan, The P2P war: Someone is monitoring your activities! http://www.cs.ucr.edu/~bhuyan/P2P/paper%206.pdf

12. Current Research (Cont’d) – Potential Solutions • DHTs typically vulnerable to poisoning attacks, which are mitigated through an enrollment server. • Server assigns public keys to nodes for authentication. 4.) Have relationship with enrollment server to statically assign node IDs • Handles mobility; nodes statically ID’ed. • Still very difficult; would require bootstrapping the P2P network with specific nodes at specific locations coordinated by LEA.

13. Greater Impact for the Internet • Scary: CALEA forces integration of network layers: • As noted in ITAA report by Steve Bellovin, Vinton Cerf, Whitfield Diffie, et al.: “In order to extend authorized interception…it is necessary either to eliminate the flexibility that Internet communications allow…or else introduce serious security risks to domestic VoIP implementations. The former would have significant negative effects on U.S. ability to innovate, while the latter is simply dangerous.” • From RFC 2084 “Correlating users' identities with their points of attachment to the Internet can be significantly harder, but not impossible, if the user uses standard means of identification. However, this means linking into multiple Internet subsystems…this is not trivial.”

14. CALEA Resistance • Wiretapping already allowed and easy enough • Existing U.S. law allows surveillance of internet users. • VoIP just another protocol and application. • Potential to stifle innovation • Any new service in the US would have to keep CALEA in mind; other countries free to invent openly. • Potential to harm internet functionality • It’s the architecture, stupid! • Won’t work anyway • Again, monitoring easily bypassed

15. Biblio http://en.wikipedia.org/wiki/Communications_Assistance_for_Law_Enforcement_Act http://en.wikipedia.org/wiki/Lawful_interception http://en.wikipedia.org/wiki/Mass_surveillance http://en.wikipedia.org/wiki/Secrecy_of_correspondence http://en.wikipedia.org/wiki/Call_detail_record http://en.wikipedia.org/wiki/Baby_Bells http://en.wikipedia.org/wiki/List_of_telephone_operating_companies#United_States http://en.wikipedia.org/wiki/ETSI http://tools.ietf.org/html/rfc2804 http://tools.ietf.org/html/rfc3924 http://www.eff.org/issues/calea http://www.fcc.gov/calea/ http://www.itaa.org/news/docs/CALEAVOIPreport.pdf http://i230.photobucket.com/albums/ee151/sjk2udu66/Bittorrent.png http://blogs.zdnet.com/open-source/images/new%20att%20logo.jpg http://www.yourhtmlsource.com/sitemanagement/media/ie404error.png http://www.healthcareconsumers.org/images/protest.gif http://www.dailymail.co.uk/news/article-559547/Graffiti-artist-Banksy-pulls-audacious-stunt-date--despite-watched-CCTV.html http://www.cs.ucr.edu/~bhuyan/P2P/paper%206.pdf