Law and Technology
Designing the
Right Wiretap Solution
Setting Standards under CALEA
The Communications Assistance for Law Enforcement Act
(CALEA) requires telecommunications providers, including
VoIP and broadband ISPs, to provide wiretapping
capabilities with their services. Law enforcement and the
telecommunications industry must work together to set
CALEA-compliant standards.
“If you build it, they will come.”
—“Shoeless Joe” Jackson in Field of Dreams
he “field of dreams” today for communications
T service providers and equipment manufacturers
seems without limits. But these organizations
need to understand that the much anticipated
“they” also includes law enforcement agencies—with
court orders in hand—demanding technical assistance in
wiretapping the bad guys who find these new services so
delightful. So “if you build it”—for use in the US any-
way—you had better “bake” a wiretap capability into the
equipment, facilities, or service. The law requires this ca-
pability for telecommunications providers, and the Fed-
eral Communications Commission (FCC) has extended
the law to cover interconnected voice over IP (VoIP) and
all facilities-based, broadband Internet access providers.1
Since 1995, the Communications Assistance for Law
Enforcement Act (CALEA)2 has required tele-
communications carriers to install or deploy equipment,
facilities, and services with surveillance capabilities at the
ready. (To reflect the fact that CALEA now applies to
more than just local incumbent carriers and traditional
telephone companies, this article uses the term “service
provider” throughout). But who decides what capabili-
ties the law requires? Is it a technical or legal decision?
The short answer is that the communications industry
sets the standards in the first instance; law enforcement
and the FCC have significant influence on the process;
and, ultimately, the courts are the final arbiters of what
CALEA requires. Thus, it’s both a technical and a legal
question, joining lawyers and engineers at the proverbial
hip to define and design CALEA’s assistance capability
PUBLISHED BY THE IEEE COMPUTER SOCIETY
requirements for tomorrow’s com-
munications networks.
ALBERT G IDARI
CALEA’s purpose Perkins Coie
The US government passed CALEA in 1994 to preserve
its “ability, pursuant to court order or other lawful au-
thorization, to intercept communications involving
advanced technologies such as digital or wireless trans-
mission modes, or features and services such as call for-
warding, speed dialing, and conference calling, while
protecting the privacy of communications and without
impeding the introduction of new technologies, fea-
tures, and services.”3 This was landmark legislation—
never before had service providers been required to
build their systems with surveillance in mind.
CALEA was necessary because by 1994, new tech-
nologies were presenting enormous technical challenges
for law enforcement surveillance efforts. Indeed, by the
time CALEA passed, law enforcement had been over-
whelmed by the digital revolution in communications.
The movement from analog to digital communications
and the introduction of new services and features left law
enforcement well behind the technological surveillance
curve. Aptly enough, CALEA was initially called the
Digital Telephony Act.
Moreover, a host of new entrants arrived in the mar-
ketplace. With the Telecommunications Act of 1996 on
the horizon, competitive access providers and alterna-
tives to the local exchange were appearing in all major
markets, and the wireless industry had begun its rapid and
steady growth. No longer could law enforcement go to
one service provider to capture all of a target’s communi-
cations. At the same time, market forces were causing the
■ 1540-7993/06/$20.00 © 2006 IEEE ■ IEEE SECURITY & PRIVACY 29
 Law and Technology
disaggregation of telecommunications network compo-
nents, and more entities than just the “corporate logo”
on a customer’s phone bill were providing raw transmis-
sion, signaling, and new applications.
As for the communications industry, it’s fair to say
that no one considered law enforcement needs in de-
sign criteria. Indeed, the notion of engineering a back
door into a communications system for anything other
than troubleshooting or maintenance was the equiva-
lent of designing a security flaw into the product. It’s
one thing to tell the government which copper wire
serves which customer so they can attach a pair of alli-
gator clips to the line and listen; it’s quite another to
dedicate ports, rack space, and computer processing to
enable wiretaps in the central office, with service
provider personnel responsible for flipping the prover-
bial switch. Moreover, with increasingly intense com-
petition for subscribers, some were concerned that the
added cost of developing surveillance solutions could
delay or preclude the time to market or stifle innova-
tion altogether.
Against this backdrop, and realizing that industry
would continue to deploy new communications services
without surveillance capabilities, the US Congress de-
cided to require that surveillance capabilities be included
in the deployment of all future telecommunications
equipment. According to CALEA’s drafters, it embodies
three key congressional policy goals:
• preserve a narrowly focused capability for law en-
forcement agencies to carry out properly authorized
intercepts;
• protect privacy in the face of increasingly powerful and
personally revealing technologies; and
• avoid impeding the development of new communica-
tions services and technologies.4
In the end, the government passed CALEA to help
preserve law enforcement’s investigative capabilities in
the face of a changing telecommunications landscape.
Some might argue that Congress actually set the stage
for industry to significantly enhance surveillance capa-
bilities through design improvements in the surveil-
lance architecture, making it easier, faster, and cheaper
to conduct wiretaps. This outcome could be good or
bad, depending on your political viewpoint, but one
thing is certain—the current architecture provides for
greater accountability and transparency, as wiretaps
now occur with the affirmative intervention of service
provider personnel.
Requirements and consequences
Section 103 of CALEA requires telecommunications
carriers to ensure that their systems have the technical ca-
pability to
30 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006
• isolate expeditiously the content of targeted communi-
cations transmitted within the carrier’s service area;
• isolate expeditiously information identifying the tar-
geted communications’ originating and destination
numbers, but not targets’ physical locations;
• provide intercepted communications and call-identifying
information to law enforcement in a format transmit-
table over lines or facilities leased by law enforcement to
a separate location; and
• carry out intercepts unobtrusively, so electronic sur-
veillance targets aren’t aware of the interception, and in
a way that doesn’t compromise other communications’
privacy and security.5
CALEA doesn’t tell manufacturers or service providers
how to meet these requirements, but lets individual en-
tities decide how to comply, either ad hoc or through
standards-setting organizations, which I discuss in the
next section.
Telecommunications equipment installed or de-
ployed before 1 January 1995 is grandfathered and
deemed compliant unless or until the government pays to
upgrade it to meet CALEA or the service provider itself
replaces or significantly upgrades the grandfathered
equipment, installs new equipment, or launches new ser-
vices.6 Providers deploying equipment or services after
this date receive no reimbursement for meeting
CALEA’s assistance capability requirements.6
Failure to meet these requirements could result in
penalties of up to US$10,000 per day.7,8 Courts can also
order service providers to undertake network or equip-
ment modifications to meet them.8 However, before it
can impose any penalty, a court must find that compli-
ance is “reasonably achievable through the application of
available technology to the equipment, facility, or service
at issue or would have been reasonably achievable if
timely action had been taken.”7
This limitation on the court’s power is no loophole.
CALEA requires a service provider to consult with its
manufacturers in a timely fashion to ensure that current
and planned equipment, facilities, and services comply.9
Additionally, manufacturers must make the necessary
CALEA-compliant features or modifications available to
service providers in a timely manner and at a reasonable
charge.9 Significantly, the absence of technical standards
is no defense to an enforcement action, but involvement
in a standards effort might be important evidence of
whether service providers took timely action to ensure
available compliant equipment.
The role of standards
Although the absence of standards is no excuse for
avoiding CALEA compliance, section 107 of the act
does create a “safe harbor” for service providers or man-
ufactures whose equipment, facilities, or services are in

compliance with publicly available technical require-
ments or standards adopted by an industry association or
standards-setting organization, or as set by the FCC, to
meet CALEA’s requirements.10 (The FCC currently is
contemplating which bodies can promulgate standards
or requirements, including whether to recognize those
developed by non-US standards organizations.) Con-
gress determined that although the communications in-
dustry should consult with law enforcement regarding
surveillance needs, industry itself would decide how to
meet those needs.5 As Congress put it, “Those whose
competitive future depends on innovation will have a
key role in interpreting the legislated requirements and
finding ways to meet them without impeding the de-
ployment of new services.”11
Congress understood that disputes might arise over
standards’ adequacy and, in response, provided a proce-
dure for the FCC to review them. Section 107 provides
that any person who believes a published standard is defi-
cient can petition the FCC to set the requisite technical
requirements in a public rulemaking.10 To be clear, a pri-
vacy advocate can challenge a standard because it fails to
protect the privacy of communications not authorized to
be intercepted, just as a local law enforcement agency can
bring a challenge because the standard fails to provide all
the required capabilities.
If the FCC finds the standard deficient, it must set
technical requirements that
• meet CALEA’s assistance capability requirements with
cost-effective methods;
• protect the privacy and security of communications
not authorized to be intercepted;
• minimize the cost of such compliance on residential
ratepayers;
• serve the US’s policy of encouraging the provision of
new technologies and services to the public; and
• provide reasonable time and conditions for compliance
with and the transition to any new standard.10
Any person who disagrees with the FCC’s findings can
appeal the resulting order to an appropriate federal Cir-
cuit Court of Appeals.
The standards process in practice
The efficacy of CALEA’s standards process was tested
almost immediately. Subcommittee TR45.2 of the
Telecommunications Industry Association (TIA)
worked for more than two years to develop Joint Stan-
dard 025, Lawfully Authorized Electronic Surveillance,
to serve as a “safe harbor” for wireline and wireless carri-
ers under section 107(a) of CALEA (you can buy copies
of the standard and its subsequent iterations at
www.tiaonline.org). Law enforcement came into the
standards process with a long list of desired capabilities,
Law and Technology
whereas industry representatives took a minimalist ap-
proach, addressing only those it understated the law
clearly required.
The subcommittee’s meetings were often con-
tentious, with law enforcement offering contributions
explaining why certain capabilities were desirable or re-
quired and industry participants rejecting many of the
demands as not clearly required by CALEA. For exam-
ple, law enforcement desired, and industry refused to in-
clude, a feature status message that would require a
service provider to notify law enforcement “when spe-
cific subscription-based calling services are added to or
deleted from the facilities under surveillance, including
when the subject modifies capabilities remotely through
another phone or through an operator.”12
Conversely, after many arguments, industry partici-
pants finally included in the standard a capability to report
a cell phone’s location at the beginning and end of a call.
This “compromise” (which excluded a law enforcement
desire to also receive messages whenever a call was passed
between cell towers—that is, a tracking capability) disap-
pointed privacy advocates, who believed that CALEA
didn’t include a requirement to report wireless call loca-
tion information. (The FCC and ultimately the courts
sustained the location requirement.)
TIA and Committee T1 (sponsored by the Alliance
for Telecommunications Industry) published the final
standard in December 1997. It defined the services and
features that must support surveillance (for example, call
forwarding) and specified the permissible interfaces (such
as allocation of call content and data channels) for deliv-
ery of intercepted communications and call-identifying
information to law enforcement.
Privacy advocates challenged the standard almost im-
mediately: on 27 March 1998, they petitioned the FCC
for review, claiming that the standard didn’t do enough to
protect privacy because it permitted delivery of location
information and packet-mode communications. The
next day, the US Department of Justice (DoJ) likewise
The government passed CALEA
to help preserve law enforcement’s
investigative capabilities in the face
of a changing telecommunications
landscape.
filed its expected petition, claiming that the standard
failed to provide all the required capabilities. (For a list of
the nine “essential” capabilities considered and rejected
during the meeting, see the sidebar.)
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 31
 Law and Technology
Law enforcement “punch list” items
L aw enforcement claimed the industry’s first standard was
deficient because it didn’t have these nine capabilities:
• Content of subject-initiated conference calls. This capability would let
law enforcement access the content of conference calls supported by
the subject’s service (including the call content of parties on hold).
• Party hold, join, drop. Law enforcement would receive messages that
identify a call’s active parties. Specifically, on a conference call, these
messages would indicate whether a party is on hold, has joined, or
has been dropped from a call.
• Subject-initiated dialing and signaling information. This capability
would give a law enforcement agent (LEA) access to all dialing and
signaling information available from the subject and would inform
the agent of a subject’s use of features (such as flash-hook and other
feature keys).
• In-band and out-of-band signaling (notification message). A LEA
would receive a message whenever a subject’s service sends a tone
The FCC put the petitions out for public comment in
April 1998,13 but didn’t resolve the challenges until Au-
gust 1999, when it published an order generally support-
ing most but not all of law enforcement’s requests.12 The
telecommunications industry challenged this order be-
fore the US Court of Appeals for the District of Colum-
bia, and in August 2000, the court concluded that the
FCC had adequately considered privacy concerns, but
hadn’t engaged in “reasoned decision-making” in regard
to law enforcement’s requests.14 Essentially, the court
concluded that the FCC didn’t adequately explain the
basis of its decision.
The court sent the case back to the FCC for further
consideration. Unsurprisingly, the FCC engaged in
reasoned decision-making on remand, and in April
2002, upheld its initial determination that CALEA re-
quired law enforcements’ requested enhancements.15
The FCC gave the telecommunications industry 90
days to comply with the requirements, and no one ap-
pealed this decision.
While these legal maneuvers were progressing, the
telecommunications industry also moved to standardize
law enforcement’s so-called “punch list” items and pub-
lished an amendment to JSTD–025 in May 2000.
JSTD-025A contains only those capabilities the FCC
identified as required by CALEA in its order after re-
mand by the court (see the sidebar). It didn’t include law
enforcement’s other desired capabilities, and they aren’t
available today.
Standards for Internet access and VoIP
As I noted previously, the FCC has extended CALEA
to cover all facilities-based broadband Internet access
32 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006
•
or other network message to the subject or associate (such as a noti-
fication that a line is ringing or busy).
Timing information. A LEA would receive information necessary to
correlate call-identifying information with the call content of a com-
munications interception.
• Surveillance status. A LEA would receive a message verifying that an
interception is still functioning on the appropriate subject.
• Continuity check tone (c-tone). An electronic signal would alert a LEA
if the facility used for delivering a call-content interception has failed
or lost continuity.
• Feature status. A message would affirmatively notify a LEA of any
changes in features to which a subject subscribes.
• Dialed digit extraction. Information a LEA receives would include
those digits a subject dialed after the initial call setup was completed.
A federal court ultimately agreed that six were required, excluding
feature and surveillance status, as well as continuity check capabilities.
and all interconnected VoIP service providers. How-
ever, JSTD-025 actually included a surveillance capa-
bility for packet-mode communications, including
those delivered using IP. The solution calls for a service
provider to deliver each packet to law enforcement re-
gardless of the form of legal process received. On a pen-
register order, which records a user’s dialing and signaling
activity associated with a call, law enforcement would
extract the communications’ identifying information
(that is, the packet header) itself. This “capability” was
part of the challenge to the standard I just described.14
The court upheld the capability on the grounds that any
acquisition of identifying information had to be law-
fully authorized, implying at least that a wiretap order
based on probable cause—which is much more difficult
than a pen-register order for law enforcement to get—
was necessary.
The FCC itself was uneasy with how the standard calls
for responding to packet communication pen-register
requests. As part of its 1999 order, it requested that the
communications industry report on how to better ad-
dress privacy concerns raised by lawfully authorized
surveillance of packet-mode communications.16 In re-
sponse, industry convened a series of Joint Experts Meet-
ings (JEMs) to determine the feasibility of separating
packet content from the information identifying its ori-
gin, destination, termination, and direction.
The industry submitted its final JEM report to the
FCC on 29 September 2000, but the FCC took no ac-
tion on it or its recommendations. At the time, law
enforcement wasn’t opposed to the JEM report recom-
mendations—it didn’t like the JSTD-025 approach of
delivering a packet’s entire content on a pen-register

order, and it viewed a separated delivery capability for
packet headers to be more desirable from an evidentiary
viewpoint. Essentially, law enforcement only wanted to
receive that which the law authorized, and it preferred to
have service providers take the necessary steps to ensure
that no more than this was delivered. (For more informa-
tion, see the Packet Surveillance Fundamental Needs
Document, available on request via www.askcalea.net.)
In an effort to develop a new standard that would sep-
arate call-identifying information from packet content,
the communications industry conducted a new round of
standards meetings in 2003 under the same auspices of
TIA. TIA approved JSTD-025B for trial use in January
2004. This standard incorporates all broadband access
surveillance standards under one umbrella, including
CDMA2000, Internet access and voice-over packets
using UMTS wireless technology, and wireline voice-
over packet services.
Unfortunately, industry and law enforcement rep-
resentatives were again at odds over CALEA require-
ments, and law enforcement actually withdrew from
participating in the process. Law enforcement today
claims that the standards are deficient and don’t provide
the same type of information and capabilities as do cir-
cuit-mode communications. (You can find its updated
packet requirements in Electronic Surveillance Needs for
Carrier Grade Voice over Packet Service and Electronic Sur-
veillance Needs for Public IP Network Access Services, both
available via www.askcalea.net.) Industry representa-
tives who developed the standard counter that, assum-
ing CALEA extends to certain packet-based services
(which is in dispute and currently on appeal by privacy
groups and others), the FCC should examine the re-
quirements with respect to a particular technology
platform rather than on a service-focused basis.17 This
view is based on the belief that a platform approach
could define a set of network events common to all ser-
vices and specify call-identifying information that law
enforcement could extract without analyzing more of
the packet than necessary.17
The real fight, however, is over how to define call-
identifying information in packet-based technologies
when you can find relevant information within several
encapsulated layers of the protocol stack. The FCC rec-
ognized the issue, which is as yet unresolved:
“The data link layer (supported by switches or
bridges) contains hardware source and destination
address information; the network layer (supported
by routers) contains the source and destination IP
address; and the transport/session/presentation/
applications layers (supported by host devices and
gateways) contain source and destination port ad-
dresses, session sources and destinations, and ses-
sion start and stop times. [These providers] may
Law and Technology
not be able to easily isolate call-identifying infor-
mation … without examining the packet in detail,
or in other words, examining the packet content.”18
It seems that history is about to repeat itself in terms of
the standards process now that the FCC has deemed facil-
ities-based broadband ISPs and interconnected VoIP
providers to be subject to CALEA—although the FCC
has said who’s covered, it has yet to say what’s required.
Several areas of contention exist. One of the punch-
list capabilities for circuit-mode communications, for
example, involved the extraction of post-cut-through
dialed digits (that is, numbers dialed after a call has been
connected or “cut through,” such as bank account num-
bers or voicemail passwords). Under packet standards,
such extraction isn’t required for VoIP calls, but law en-
forcement claims it should be. Another example in-
volves law enforcement’s request for information about
each packet an Internet Service Provider (ISP) carries
that includes information at a protocol layer that the ISP
doesn’t manage.17
It’s unclear when the saga of the packet-mode com-
munications standard will be resolved, or if doing so will
even be necessary once the courts resolve the challenges to
the FCC’s extension of CALEA. Regardless of whether
CALEA applies to these Internet services, however, law
enforcement might still seek an order for technical assis-
tance in wiretapping packet-mode communications.19
ISP’s will likely still implement some capability require-
ments, if not those identified in JSTD-025B.
In addition, the TIA effort with JSTD-025B isn’t the
only ongoing standard setting activity. CableLabs, for ex-
ample, has produced a standard that law enforcement has
found suitable.20 In fairness, law enforcement participa-
tion in other venues has been less contentious. The
question remains, however, whether any uniform under-
standing of CALEA requirements exists, and how each of
these standards compares with others in terms of defining
call-identifying information.
Enforcement today claims that the
standards are deficient and don’t
provide the same type of information
and capabilities as do circuit-mode
communications.
Lessons learned
CALEA created a natural conflict: industry trying to
minimize the cost of compliance through efficient stan-
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 33
 Law and Technology
dards development and minimalist design requirements
set against law enforcement needs and the desire to want
all the bells and whistles, especially because someone else
is paying for it. Add to this mix the fact that the law
The two sides will always dispute
how much is enough, with standards
organizations acting as the battlefield
but not the court of last resort.
doesn’t clearly articulate the legal requirements, and pro-
tracted conflict is inevitable, leading to protracted de-
ployment dates for any solution, leading to great
frustration for law enforcement, which sees the process as
aiding and abetting the bad guy. In the end, the goal is to
arm law enforcement with the tools it needs to do its job
while protecting privacy and shareholder value. To
achieve that goal, a public-private partnership is needed
with adequate public funding of the process. After all, a
nation’s security is the quintessential public good, and we
all have a stake in it.
Lack of definition breeds dispute
Ten years of surveillance standards development has re-
vealed a gulf between law enforcement needs and ser-
vice-provider requirements. To law enforcement, any
and all information about subscribers’ use of services is of
interest and could yield intelligence. To a service
provider, information unrelated to communications
processing (such as users receiving voicemail alerts) isn’t
call-identifying and doesn’t fall under CALEA’s require-
ments. A further corollary is that information not relied
on by the subscriber’s provider to route a call shouldn’t be
required (post-cut-through signaling acted on by another
carrier, for example).
Law enforcement and service providers can’t bridge
this gulf because the difference relates to cost and who
bears it. Extracting signals that have no call-processing
function and delivering them to law enforcement creates
a vastly different surveillance architecture than merely
delivering user input when a call begins. Whether
CALEA requires one or the other remains to be seen, but
until it’s clear, the two sides will always dispute how much
is enough, with standards organizations acting as the
battlefield but not the court of last resort. (To be clear,
there is no law against providing more capabilities, as long
as the resulting output is lawfully authorized.)
Standards are always late
Although we might view the CALEA framework as pro-
viding a thoughtful and deliberate process to ensure that
34 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006
its goals are met in a balanced way, lawyers who have
practiced before the FCC and engineers who have sat
through standards meetings know that the process is any-
thing but efficient and prompt. It’s also a myth, albeit one
now enshrined in law, that standards ever really precede
service or capability development and deployment. Usu-
ally, standards follow innovation and market acceptance
as service providers and manufacturers compete to be the
first to introduce a service or feature.
In short, there is no real “industry” standard until a
critical mass of industry participants is willing to share in-
formation to create one. The myth finally crumbles be-
cause surveillance standards development is divorced
from service standardization itself. The surveillance solu-
tion will never arrive when an organization is ready to
deploy a service.
Thus, both law enforcement and the communica-
tions industry are in an endless cycle of CALEA “catch-
up” and “catch-22.” Catch-up for the reasons I just
outlined, and catch-22 because no safe harbor exists if
services are deployed without CALEA capabilities. True
enough, Congress made it unequivocally clear that
CALEA wasn’t to hinder new service deployment, stat-
ing that if a service or technology couldn’t reasonably be
brought into compliance with interception require-
ments, then it could still be deployed. Of course, this is no
real alternative because service providers won’t want to
risk an enforcement action.
Nor will they want to design some rudimentary, or
even reasonably sophisticated, ad hoc solution. CALEA
doesn’t mandate using a standards-based solution, but a
service provider that “goes it alone” runs the risk of law
enforcement deeming its solution unacceptable. Worse
yet, subsequent standards could render it obsolete or in-
adequate by comparison.
Such “one-off ” solutions don’t help law enforcement
either, which must buy up-to-date collection equipment.
Vendors rely on standards to make collection equipment
extensible so that law enforcement can buy one box to re-
ceive data from multiple service providers regardless of the
underlying technology. Standardization saves law enforce-
ment a fortune.
Nevertheless, extending the compliance obligation
pending standards development or commercialization
isn’t authorized under CALEA, although the act does
permit the FCC, upon petition from a service provider
or manufacturer, to extend the date if compliance “is
not reasonably achievable through application of tech-
nology available within the compliance period.”10
However, the FCC has determined that this provision
doesn’t let it grant any extensions beyond the original
CALEA compliance date of 1998. Although the courts
will debate this issue in the future, industry can’t fill the
deployment gap if the FCC won’t grant extensions in
the meantime.

So, although standards should theoretically drive
CALEA compliance in a timely and effective manner, in
reality, the framework is unlikely to serve any one well.
Engineers playing lawyers is a bad idea;
lawyers playing engineers is worse
The law should define the necessary capabilities—it
doesn’t. Leaving it to engineers to guess is both unfair and
unlikely to yield a standard that actually meets either the
law or law enforcement needs. CALEA “round 1” re-
sulted in an exhausting eight-year process to implement a
standard for circuit-switched communications that were
already losing ground to new IP-based communications
services. Industry didn’t develop those services with sur-
veillance in mind because it believed them to be exempt
from CALEA as information services. The FCC has de-
veloped a theory to extend CALEA to these services
today, years after their marketplace deployment and
adoption by customers.
But how well did industry do with the first standard
with regard to noncontroversial capabilities? It still made
some fundamental mistakes despite law enforcement’s
active involvement. JSTD-025, for example, requires
that law enforcement receive a message showing the
numbers a subject dials on each origination or the in-
coming numbers of each call to the subject. One is a pen
register, whereas the other is a trap and trace; both re-
quire separate authorization, but law enforcement gets
them combined regardless.
Another example is location information. Location
reporting is a parameter in each origination and termina-
tion message. In other words, to get location, you must
also get the number dialed or the incoming one. The
problem is that a separate legal standard (which is neither
a pen register nor a trap and trace) must authorize loca-
tion. Not all manufacturers implemented the standard
with location parameters as conditional; law enforce-
ment routinely received location information on pen
registers despite CALEA’s express prohibition of doing so
pursuant to pen-register authorization.
Yet another example is the failure to differentiate be-
tween electronic and wire communications. Thus, law
enforcement would receive a voice call on a content
channel and short-message-service traffic or other elec-
tronic communications on the data channel. Again, the
two require separate legal authorizations, but the standard
provided law enforcement with both regardless of the au-
thorization’s nature or CALEA’s admonition to protect
the confidentiality of communications not authorized to
be intercepted.
Eventually, vendors, service providers, and collec-
tion-equipment manufacturers built solutions to rectify
these problems, but the standards remain unchanged in
addressing these infirmities, despite subsequent revisions.
The point is that surveillance law is arcane enough for
Law and Technology
prosecutors and lawyers advising service providers with-
out making engineers put these legal requirements into
software code.
What’s more, an old axiom says that lawyers can find
ambiguity in a “no smoking” sign. How is it, then, that
Congress expected engineers to find clarity enough in
CALEA to set quasi-legal standards? Because the courts
are the final arbiters, the circle is complete as lawyers play
engineers in explaining standards to courts, who then de-
cide whether technical requirements meet the law. (Dur-
ing the oral argument in the court of appeals on the initial
standard, one judge asked Ted Olsen, who represented
the telecommunications industry and who ultimately
became the US solicitor general, what JSTD stood for.
The courtroom full of lawyers looked blankly on, until
one offered that it meant “joint standard”—not that this
was illuminating in any way.)
It’s broken; fix it
Despite everyone’s best intentions, the standards-setting
process for surveillance under CALEA is permanently
broken. The post-9/11 environment has given new
urgency to law enforcement’s demands for robust capa-
bilities in all new communications technologies. The
slowness of the standards-developing process has led law
enforcement to seek mandatory compliance deadlines
from the FCC.
Of equal concern, industry views some law enforce-
ment requests as gold-plating on an already expensive de-
velopment process. Because service providers exclusively
bear the development and implementation costs, they
have every incentive to develop fewer capabilities and less
complex solutions.
And what of privacy concerns? They aren’t present at
the standards table, and the more complex standards be-
come as they extend to packet communications, the less
transparent or understandable the privacy impact could be.
I n the end, all would be better served by a publicly
funded, joint industry–government development pro-
cess. CALEA’s purpose was good—keep law enforce-
ment current, don’t impede innovation, and protect
privacy—but could be better achieved with this collabo-
rative approach. The time has come to replace CALEA’s
standards-setting provisions with a new, rapid, and fair
system of capability development.
Acknowledgments
The views expressed in this article are my own and should not be attrib-
uted to any of my clients.
References
1. In the Matter of Communications Assistance for Law Enforce-
ment Act and Broadband Access and Services, First Report
www.computer.org/security/ ■ IEEE SECURITY & PRIVACY 35
 Law and Technology

and Order and Further Notice of Proposed Rulemak-
ing, ET Docket No. 04-295, RM-10865, 23 Sept. 2005;
www.askcalea.net/docs/20050923-fcc-05-153.pdf.
2. Communications Assistance for Law Enforcement Act, Public
Law No. 103–414, Statutes at Large, vol. 108, 1994, p.
4279 (codified as US Code, Title 47, sections 1001–1010
and US Code, Title 47, section 229).
3. House Report No. 103–827, section 1; reprinted in US
Code Congressional and Administrative News, vol. 3489,
1994.
4. House Report No. 103–827, section 1; reprinted in US
Code Congressional and Administrative News, vol. 3489,
1994, p. 3493.
5. US Code, Title 47, section 1002, 1994.
6. US Code, Title 47, section 1008, 1994.
7. US Code, Title 47, section 1007, 1994.
8. US Code, Title 18, section 2522, 2000.
9. US Code, Title 47, section 1005, 1994.
10. US Code, Title 47, section 1006, 1994.
11. House Report No. 103–827, section 1; reprinted in US
Code Congressional and Administrative News, vol. 3489,
1994, p. 3499.
12. In the Matter of Communications Assistance for Law Enforce-
ment Act, Third Report and Order, CC Docket No.
97–213, 14 FCC Rcd 16794, paragraph 107, 31 Aug.
1999; www.askcalea.net/docs/fcc99230.pdf.
13. Federal Comm. Commission, Public Notice DA-98-762,
20 Apr. 1998; www.askcalea.net/docs/da980762.pdf.
14. United States Telecom. Assoc. v. FCC, Federal Reporter, 3rd
Series, vol. 227, 2000, p. 450 (US Court of Appeals for
the District of Columbia Circuit); www.fcc.gov/ogc/
documents/opinions/2000/99-1442.html.
15. In the Matter of Communications Assistance for Law Enforce-
ment Act, Order on Remand, CC Docket No. 97–213,
17 FCC Rcd 6896, 11 Apr. 2002; www.askcalea.net/
docs/fcc02108.pdf.
16. In the Matter of Communications Assistance for Law Enforce-
ment Act, Third Report and Order, CC Docket No.
97–213, 14 FCC Rcd 16794, paragraph 55, 31 Aug.
1999; www.askcalea.net/docs/fcc99230.pdf.
17. Notice of Proposed Rule Making, ET Docket No. 04-295,
paragraphs 77–85, 9 Aug. 2004; www.askcalea.net/
docs/20040809.fcc.04-187.pdf.
18. Notice of Proposed Rule Making, ET Docket No. 04-295,
paragraph 65, 9 Aug. 2004; www.askcalea.net/docs/2004
0809.fcc.04-187.pdf.
19. US Code, Title 18, section 2518(4), 2000.
20. PacketCable Electronic Surveillance Specification, PKT-SP-
ESP-I03-040113, specification by CableLabs, 13 Jan.
2004; www.cablelabs.com/specifications/archives/PKT
-SP-ESP-I03-040113.pdf.
Albert Gidari is a partner with Perkins Coie, where he leads the
firm’s privacy and security practice. He represents service
providers in the implementation of CALEA and participated in
development of JSTD-025, the first electronic surveillance stan-
dard developed to meet CALEA’s requirements under the aus-
pices of the Telecommunications Industry Association, and
subsequent standardization and implementation efforts. Gidari
has a law degree from George Mason University Law School
and a masters of law degree from the University of Washing-
ton. Contact him at gidari@worldnet.att.net.

IEEE TRANSACTIONS ON DEPENDABLE

AND SECURE COMPUTING
Learn how others are achieving systems and networks design and
development that are dependable and secure to the desired
degree, without compromising performance.

This new journal provides original results in research, design, and

development of dependable, secure computing methodologies,
strategies, and systems including:

• Architecture for secure systems

Learn more about this new
publication and become a
subscriber today.
www.computer.org/tdsc
• Intrusion detection and error tolerance
• Firewall and network technologies
• Modeling and prediction
• Emerging technologies
Publishing quarterly
Member rate: $31
Institutional rate: $285

36 IEEE SECURITY & PRIVACY ■ MAY/JUNE 2006