Surveillance or Security?: The Risks Posed by New Wiretapping Technologies (13 page)

Cryptography is no silver bullet. It provides security only for the communications contents. In particular, the transactional information-who
is communicating with whom when-is not encrypted. It is often the case
that transactional information is more valuable than content, but this
somewhat private information may be public even when the communications contents are hidden. Transactional data are remarkably revealing: it
can indicate that a company merger is about to occur, that nation-states are engaged in negotiation, that someone is having an affair. Yet because
routers do need to know where packets are going, hiding such transactional
information is quite difficult.84

It has become a national, indeed, international, priority to increase
network security (by which I mean the security of the communications
network itself). This is not an easy matter. It is made more difficult by
the fact that any solution must be backward compatible: changes to the
protocols must be made in such a way that the new version works
seamlessly with products that have not been so updated. Securing the
network is not the same as securing the communications that travel on it,
though the two are closely related; securing the network includes communications security, but also ensuring availability and nonrepudability
of communications.

3.9 Efforts to Secure the Internet

Internet protocols were designed to provide network reliability and
availability, and they do so well. They were not designed to provide security and, in general, they do not (one exception is the protocol SSL/TLS,
which encrypts transport-layer communications). Some aspects of security
can be relatively easily handled. Cryptography, for example, can ensure
the end-to-end confidentiality, authenticity, and integrity of a communication. Cryptography itself cannot ensure network security; more infrastructure is needed. There are currently a number of different efforts to
accomplish this.

Fundamental to the correct functioning of the network is assurance:
ensuring that the communication arrives at the correct network destination. This is harder than it sounds. Recall that DNS-the mechanism that
associates a domain name, such as www.bankofamerica.com, with an IP
address-can be spoofed, sending a user to a bogus website. Domain Name
System Security Extensions (DNSSEC) is a protocol for guaranteeing that
DNS resolvers receive correct IP addresses for their queries. DNSSEC provides two things:

Source authentication A DNS resolver can verify that the information it
received originally came from a DNS authoritative nameserver (one that
the DNS resolver can "trust").

Integrity verification A DNS resolver can determine that the information it
has received from a DNS nameserver has not been tampered with during
transit from the original authoritative nameserver.

When a DNS resolver receives an IP address via DNSSEC lookup, it validates the response through verifying that an authoritative nameserver has
signed the response. Under DNSSEC, each DNS nameserver generates a
/files/01/87/67/f018767/public/private key pair for using in public-key cryptography. The nameserver publishes the public key and places a cryptographically shortened
version of the public key-this is called a hash-in its parent DNS nameserver. Using its private key, the nameserver signs its zone's records connecting domain names with their IP addresses. Of course, the resolver
needs to know that the local DNS server has fully checked the authenticity
of the information (and that the local DNS server is not being spoofed). If
its parent zone has signed its record, and the parent zone is authoritative,
then that is proof.

But it may be that the resolver does not have proof that the parent DNS
nameserver is authoritative.

So the question can recurse all the way "up the chain" of DNS nameservers to the root nameserver, which is the trust anchor-the one party you
have to trust, regardless-in most DNSSEC implementations.

The trust anchor has signed its record connecting the top-level zone
nameserver to its IP address, making the top-level nameserver authoritative. Then the top-level nameserver has signed its records using its own
private key to show that the nameserver for the next zone down is authoritative (to know that the names.google.com nameserver is authoritative
requires knowing that the google.com nameserver is authoritative, which
in turn requires that the.com nameserver is authoritative). This is complicated. DNSSEC works only if all the DNS nameservers in the lookup chain
are DNSSEC-enabled; if one of them is not, then there cannot be a trusted
chain of authenticity.

Of course, there needs to be a way for the DNS resolver to check the
validity of the DNS root. In theory-in practice this has not yet been
done-there is a key for the root that each DNS resolver has, which it has
received not through the network but by some other means.

The other difficulty with DNSSEC is complexity. Beginning with the
root nameserver, the resolver has to go through the DNS nameserver chain
and (1) find the authoritative IP address for the next level down the chain,
as well as (2) verifying the public key of the signature of the zone so that
the resolver knows that the IP address of the next DNS resolver in the chain
is valid (e.g., the chain for maps.google.com would be the "." DNS nameserver-the root, the com DNS nameserver, and the google.com DNS
nameserver). It should be no surprise that this algorithm is complex to
implement.

It should also be no surprise that thus, despite its importance, DNSSEC
deployment has been slow. One cause is political-the root trust anchor
determines which sites are authentic and which are not, and that has
presented policy problems as to who should control Internet trust anchors.
For a number of years there was conflict over who should sign the "."
server. There were a number of contenders, including the Internet Corporation for Assigned Names and Numbers, the nonprofit organization established in 1998 to run Internet-related tasks that previously the U.S.
government had done; the U.S. Department of Commerce, which believed
it had the authority to do so (recall that although the Internet is now an
international network, it had its origins in the United States);` and the
International Telecommunications Union, which was preferred by some
since it is a United Nations agency. In 2009, the issue was resolved in favor
of VeriSign, a U.S. company that operates two of the Internet's root nameservers, as well as the top-level domains of com and net.

The other problem is technical. DNS is difficult to implement, and
DNSSEC even more so. What makes the situation worse is that DNSSEC
only works if the DNS nameservers in a lookup chain are all DNSSEC
enabled; just updating the local DNS nameserver to DNSSEC will not solve
the problem. In some sense, the difference between a DNS and DNSSEC
response resembles the difference between obtaining a notarized signature
and a signature guarantee;86 the former is a witnessing of the signature,
the latter, a financial institution guarantee that the signature is genuine.87
The challenges in setting up DNSSEC are large, and given that attacks are
still rare, the difficulty involved in setting up DNSSEC can make deploying
the protocol a risky proposition. Deployment was slow until a particularly
destructive attack on DNS surfaced in the summer of 2008;88 after this, the
pace of adoption picked up.

DNS is not the only problem that the security network faces. When the
original DARPA network was set up, 32 bits seemed more than ample for
network addresses; after all, that provides for over four billion distinct
addresses. Three decades later, the crunch is apparent. The network is not
only being used for people; it is being used for billions and billions of
devices. Hence the move to IPv6, or version 6 of the Internet Protocol.89
This allows for 128-bit, or over 3 x 1028, distinct addresses, enough for every
human on earth to have an Internet address for every word they have time
to utter.

IPv6 has some security features as well. IPsec, a protocol for key establishment and mutual authentication, enables packet-level encryption.9o
But IPsec is quite limited in scope. In particular, it does not solve the fundamental problem of authenticity: Is the connection to the real site?
(For example, is http://www.Iloydstsb.com/ the Lloyds Bank website or a
fraudulent site reached as a result of a poisoned DNS cache?) Thus IPsec is
mostly useful for establishing a virtual private network,' a virtual network
established over a public one (such as the Internet) that securely connects
remote users with an organization. The implementation of IPv6 has been
remarkably slow, with the result that IPsec has also been implemented
in IPv4.

By the late 1990s, it was apparent that the Internet was an experiment
that had escaped the lab. While the network is no Frankenstein, the problems that have already arisen leave no doubt about the need for improved
security.92 Bolting on security afterward is exceedingly difficult, and because
attribution, authentication, and identity are social concerns as well as
technical ones, solutions will not simply be a matter of a patch here
and a patch there. Fundamental design must be examined, with the intent
of bringing protocols to the network that are "secure by design." The
European Commission, the United States, Korea, Japan, and several other
nations have launched research projects on that effort. These efforts will
not bear fruit for some time. I examine them in chapter 11.

It is well known that human perception and actual events are often
at odds. That dissonance is particularly notable in our perceptions of
the patterns of our daily lives. Once certain practices have been
present for a period of time, it becomes difficult to recall that things
were ever different. Whether this is our present reliance on cell phones,
or law enforcement and national security reliance on wiretapping, our
belief systems would have us think that circumstances were always
like this.

In the case of cell phones and legalized wiretapping, such beliefs are
false, of course. Cell phones became common beginning only in the late
1990s, while the legal basis for law enforcement and national-security
wiretapping was, at least in the United States, established only about a
generation earlier.

The first U.S. wiretapping law was the 1968 Omnibus Crime Control
and Safe Streets Act of 1968,1 which established warrant procedures for
wiretaps in criminal investigations. (The U.S. law for electronic surveillance
in national security cases, the Foreign Intelligence Surveillance Act, came
into existence ten years later.) The current discussion of wiretapping
accepts as a given that electronic surveillance is necessary for law enforcement and national-security investigations. The reality is that the tool is
only relatively recent and is used in ways that were not necessarily expected.
In this chapter, I discuss wiretapping laws as well as the inextricably linked
subject of how they are applied.

Wiretapping law is a subject about which much has been written, of
course. My coverage will be a quick tour; those who wish a longer exegesis
are urged to consult one of the large number of books on the subject. In
particular, Whitfield Diffie and I wrote about wiretapping law in Privacy on
the Line: The Politics of Wiretapping and Encryption.

4.1 The Antecedents of U.S. Wiretapping Law

The Fourth Amendment to the Constitution was written in reaction to the
British writs of assistance, general search warrants used in the American
colonies. The writs' lack of specificity in the "persons, houses, papers, and
effects" to be searched and seized were viewed as instruments of arbitrary
power.' The writs were a main grievance against the British. Thus the
Fourth Amendment requires that warrants shall particularly describe "the
place to be searched, and the persons or things to be seized."

In the early days of the colonies, mail delivery was dependent on the
kindness of strangers, often done with the help of a traveler or merchant
along the route. Privacy was certainly not assured. Even after postal delivery was somewhat regularized in the early eighteenth century, communications privacy remained a problem. Such leaders as Benjamin Franklin and
Thomas Jefferson worried that their written messages were less than private,
although from early on, privacy of the mails was built into U.S. law. The
1792 act3 establishing the U.S. Postal Service included two important
features: low rates for newspapers (to enable the populace to participate in
political activity) and privacy of the mails. Postal officials were prohibited
from opening letters. In establishing these features as part of the postal
system, the United States set itself apart from England and France, where
the post was used as an instrument of government surveillance. But what
was law was not necessarily practice, and there were multiple instances of
snooping on the mails.' Postal privacy protections were strengthened with
an 1878 Supreme Court ruling that a warrant was required before the
government could open first-class mail.'