[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FYI] (Fwd) Open Source Wiretapping

------- Forwarded message follows -------
To:             	cryptography@c2.net
Subject:        	Open Source Wiretapping
Date sent:      	Thu, 20 Jul 2000 20:24:19 -0400
From:           	Matt Blaze <mab@research.att.com>

On Monday, July 24, 2000, the House Judiciary Committee's Subcommittee
on the Constitution will be holding hearings on "Fourth Amendment
Issues Raised by the FBI's 'Carnivore' Program."  The hearings will be
in the Rayburn building, room 2141 at 1pm, for those interested in
attending.  There will be witnesses from the FBI and Department of
Justice as well as technical experts, civil liberties advocates, and
representatives from ISPs.  I've been invited to testify as an expert
on the risks of Internet wiretapping generally and on the issues that
would be raised by making the Carnivore software open-source in

As we all know by now, the "Carnivore" system runs on an FBI-owned PC
that can be installed at an ISP to collect IP traffic as part of a
court-ordered wiretap. Not much detail is publicly known about exactly
how Carnivore works or what kinds of traffic it collects.  This has
contributed to an atmosphere of mistrust and confusion, which would be
at least partly addressed if the FBI would provide more information,
including making the Carnivore source code available for public

Internet wiretapping raises some very difficult technical, as well as
legal, issues.  The wide range of Internet access methods coupled with
the fact that the Internet is based on a packet-switched, rather than
connection-oriented, model, makes it much more difficult to reliably
and faithfully collect exactly the Internet traffic associated with a
particular source or destination than it is to perform traditional
voice wiretaps.  The security benefits of making software open-source
are well understood by the security community; open source could be
expected to do much to strengthen a system as complex and
security-critical as Carnivore.

Of course, making Carnivore open source is not a complete panacea for
protecting against abuses or errors.  First of all, it's likely rather
complex, so simply scanning the source code probably won't tell us
much about whether it is vulnerable to attack or misbehaves in the
kinds of traffic it collects.  That would require extensive, focused
review.  Open source code attracts several different kinds of
reviewers.  One is made up of people who are interested in and want to
study a system for its own sake, but the main source of meaningful
review usually comes from people who have to read and understand the
code because they want to make useful modifications to it.  Carnivore
isn't likely to attract much of that latter (and I think more
important) kind of review, at least from among the open community.  On
the other hand, groups of focused expert reviewers can (and often do)
miss things.  Any meaningful review, therefore, should include both
independent expert reviewers as well as releasing the code to the

More seriously, I suspect that the meat (so to speak) of any
meaningful analysis of Carnivore's security and behavior of lies not
in its core source code but rather in the parameters used when it is
actually configured and installed.  It is similar to asking whether
Unix is secure - we can look at its source code and find (or not find)
specific bugs, but the real issue in the security of any particular
Unix installation is how it is managed and administered, not what
version of the kernel it runs.

Still, releasing the source code is a critical first step in assuring
the public that Carnivore can at least be configured to do what it is
supposed to do, and I hope the FBI sees fit to take this step soon.

I've submitted as part of my written testimony a position paper I
wrote with Steve Bellovin that makes the case that there is little
harm, and much good, to be done by releasing the Carnivore code.  It
is available at


------- End of forwarded message -------