From: Bruce Schneier
To: [log in to unmask]
Sent: 16/01/01 04:19
Subject: CRYPTO-GRAM, January 15, 2001
CRYPTO-GRAM
January 15, 2001
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
[log in to unmask]
<http://www.counterpane.com>
A free monthly newsletter providing summaries, analyses, insights, and
commentaries on computer security and cryptography.
Back issues are available at <http://www.counterpane.com>. To subscribe
or
unsubscribe, see below.
Copyright (c) 2001 by Counterpane Internet Security, Inc.
** *** ***** ******* *********** *************
In this issue:
A Cyber UL?
Crypto-Gram Reprints
News
Counterpane Internet Security News
Crypto-Gram News
Solution in Search of a Problem: SafeMessage
A Social Engineering Example
The Doghouse: Gianus Technologies
NIST Crypto Update
Code Signing in Microsoft Windows
PGP Broken
Comments from Readers
** *** ***** ******* *********** *************
A Cyber UL?
Underwriters Laboratories (UL) is an independent testing organization
that
rates electrical equipment, safes, and a whole lot of other things. It
all
started in 1893, when William Henry Merrill was called in to find out
why
the Palace of Electricity at the Columbian Exposition in Chicago kept
catching on fire (not the best way to tout the wonders of
electricity). After making the exhibit safe, he realized he had a
business
model on his hands. He approached insurance underwriters with the idea
of
an independent testing lab. They were all sick of paying for
electricity
fires, and took him up on the deal. Eventually, if your electrical
equipment wasn't UL certified, you couldn't get insurance.
Today, UL rates many different things. Safes, for example, are rated
based
on time and materials. A "TL-15" rating means that the safe is secure
against a burglar limited to safecracking tools and 15 minutes' working
time. Other ratings certify the safe for longer periods of time, or
against burglars with blowtorches and explosives. These ratings are not
theoretical; actual hotshot safecrackers, employed by UL, take actual
safes
and test them. If a company comes out with a new version of a safe, it
has
to get it retested -- the rating does not carry forward.
Applying this sort of thinking to computer networks -- firewalls,
operating
systems, Web servers -- is a natural idea. And the newly formed Center
for
Internet Security plans to implement it. I'll talk about the general
idea
first, and then the specifics.
I don't believe that this is a good idea, certainly not now and possibly
not ever. First, network security is too much of a moving target.
Safes
are easy. Safecracking tools don't change much. Maybe someone invents
a
hotter torch. Or someone else invents a more sensitive microphone. But
most of the time, techniques of safecracking remain constant. Not so
with
the Internet. There are always new vulnerabilities, new attacks, new
countermeasures. There are a couple of dozen new vulnerabilities each
week
in major software products; any rating is likely to become obsolete
within
months, if not weeks.
Second, network security is much too hard to test. Again, safes are
easy. Breaking into them requires skill, but is reasonably
straightforward. Modern software is obscenely complex: there are an
enormous number of features, configurations, implementations. And then
there are interactions between different products, different vendors,
and
different networks. In the past, I've written extensively about
complexity
and the impossibility of testing security. For now, suffice it to say
that
testing any reasonably sized software product would cost millions of
dollars, and wouldn't guarantee anything at the end. And worse, if you
updated the product you'd have to test it all over again.
Third, I'm not sure how to make security ratings meaningful.
Intuitively,
I know what it means to have a safe rated at 30 minutes and another
rated
at an hour. But computer attacks don't take time in the same way that
safecracking does. The Center for Internet Security talks about a
rating
from 1 to 10. What does a 9 mean? What does a 3 mean? How can ratings
be
anything other than binary: either there is a vulnerability or there
isn't?
The moving-target problem particularly exacerbates this issue. Imagine
a
server with a 10 rating; there are no known weaknesses. Someone
publishes
a single vulnerability that allows an attacker to easily break in. What
is
the server's rating now? 9? 1? How are users notified of this
change? Is the manufacturer required to change his official rating on
his
Web site? On his packaging? How does the Center re-rate the server
once
it is updated? But then the rating only affects certain patch levels of
the product; how do you explain that? And once you've solved that, how
do
you deal with vulnerabilities that only affect the product in some
configurations?
Fourth, failures in network security are not always obvious. If a safe
is
broken into, the owner learns about it when he next opens his safe. If
a
network is broken into, the owner might never know. Data isn't stolen
in
the same way as diamonds or cash: it is copied, it is modified, or it is
just examined. Remember that Microsoft's network was compromised for
weeks
before anyone knew about it. I believe that most network intrusions are
never even noticed. A "secure" network product might fail completely,
and
no one would be the wiser.
Fifth, I don't see how a rating could take context into account. Safes
are
just as hard to crack in a bank as they are in a house; network security
products are highly dependent on their environment. A product rating
cannot take into account the environment and interactions that a
component
will deal with. Network components would be certified in isolation, but
deployed in a complex interacting environment. It is common to have
several individual "secure" components completely blow a security model
when they are all forced to interact with each other.
Sixth, I don't see how to combine this concept with security
practices. Today the biggest problem with firewalls is not how they're
built, but how the user configures them. How does a security rating
take
that into account? How does a security rating take into account the
people
problem: users naively executing e-mail attachments, or resetting
passwords
when a stranger calls and asks them to?
And seventh, this kind of thing could easily fall into the trap of
bashing
small products and protecting large products. A little-discussed fact
of
computer security is that minority products are more secure than popular
products for the simple reason that there aren't as many exploits for
them. But the unpopularity of those products might make it difficult
for
them to pay for evaluation. And can major vendors be held to the same
standards as everyone else? It will take a lot of organizational
fortitude
to fail Microsoft's security, for example.
This is not to say that there's no hope. I believe that the insurance
industry will eventually drive network security, and that some sort of
independent testing is inevitable. But I don't think that providing a
rating, or a seal of approval, is possible anytime soon.
Even so, the Center for Internet Security is tackling the
challenge. Unfortunately, I don't particularly like what I see so far
(although admittedly, I haven't seen much). Looking at their Web site,
it
seems more like a marketing scheme than anything else. A security
supplier
or consulting organization can spend $25K to become a
member. (Organizations that use security can join for only $7K.)
Benefits
include "your organization's name...on Center brochures and benchmarks
documents," "your organization's name included on the Center's website,"
and "the privilege of using the Center's logo on your website." The
last
time I checked, there were 71 charter members.
Their initial push is to consolidate a bunch of the mediocre security
requirements documents out there (such as BS7799) and come up with a
"final
set of minimum benchmarks to be used as a basis for demonstrating due
care," and to create a suite of tests that can give computer owners some
kind of security rating or feeling of confidence.
I see ideas like this as part of the Citadel model of security, as
opposed
to the Insurance model. The Citadel model basically says: "If you have
this stuff and do these things, you'll be safe." The Insurance model
says:
"Inevitably things will go wrong, so you need to plan for what happens
when
they do." In theory, the Citadel model is a much better model than the
pessimistic, fatalistic Insurance model. But in practice, no one has
ever
built a citadel that is both functional and dependable.
My worry is that the Center for Internet Security will become an
"extort-a-standard" body, which charges companies for a seal of
approval. I believe that the people behind the Center for Internet
Security have completely pure motives; you can be an ethical
extortionist
with completely honorable intentions. What makes it extortion is the
detriment from *not* paying. If you don't have the "Security Seal of
Approval," then (tsk, tsk) you're just not concerned about security.
Center for Internet Security:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2667644,00.html>
<http://www.cisecurity.org/>
Underwriters Laboratory history:
<http://www.bergen.com/biz/safe2219970921o1.htm>
<http://www.ul.com/about/otm/otmv2n4/fire.html>
Early discussions of a cyber-UL:
<http://www.l0pht.com/cyberul.html>
Complexity and security:
<http://www.counterpane.com/crypto-gram-0003.html#SoftwareComplexityandS
ecur
ity>
A version of this article appeared on ZDNet:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2669708,00.html>
** *** ***** ******* *********** *************
Crypto-Gram Reprints
Publicity attacks:
<http://www.counterpane.com/crypto-gram-0001.html#KeyFindingAttacksandPu
blic
ityAttacks>
Block and stream ciphers:
<http://www.counterpane.com/crypto-gram-0001.html#BlockandStreamCiphers>
** *** ***** ******* *********** *************
News
Timing attacks on Web browsers. The basic idea is that by timing how
long
a browser takes to download a page, you can learn whether the page is
stored in the browser's cache...and therefore whether or not the person
visited that Web site recently.
<http://www.sciencedaily.com/releases/2000/12/001208074325.htm>
The White House released an "International Crime Threat Assessment."
The
report discusses organized crime's use of computer and network attacks.
<http://www.whitehouse.gov/WH/EOP/NSC/html/documents/pub45270/pub45270ch
ap1.
html>
Only 25% of people who have break-ins report them. People are more
worried
about malicious code than break-ins, but information theft is the most
damaging. Spending on security is predicted to more than triple in four
years.
<http://www.thestandard.com/article/display/0,1151,20500,00.html>
Personal firewalls have security holes. Is anyone surprised that
commercial software fails real-world security tests?
<http://www.internetnews.com/intra-news/article/0,,7_529661,00.html>
Clever steganography application: turn a message into innocuous spam:
<http://www.spammimic.com/>
Here's a product that until now has only been available to intelligence
services. It's a special spray that allows someone to examined the
contents of sealed opaque envelopes without opening them. When sprayed
on
the envelope, it renders envelopes temporarily transparent, enabling you
to
view the contents within. The company claims that it will only market
the
chemical to law enforcement, but you know how things get around.
<http://www.mistraldetection.com/seethrough.htm>
<http://www.newscientist.com/news/news.jsp?id=ns226930>
If you can't wait, though, there's an electronic component cooling spray
you can get at Radio Shack that does the same thing.
Last month I complained that Microsoft is prohibiting services like
BugTraq
from reposting its security advisories. Now @Stake, a company I
expected
better from, is doing the same thing.
<http://cgi.zdnet.com/slink?70609:8469234>
<http://www.theregister.co.uk/content/6/15533.html>
BugTraq fights back:
<http://www.theregister.co.uk/content/4/15491.html>
Good analysis of the European CyberCrime Treaty. Short summary: it's
still
horrible.
<http://www.securityfocus.com/commentary/124>
Interesting interview on (among other topics) encryption with Eben
Moglen,
general counsel of the Free Software Foundation:
<http://www.immaterial.net/page.php3?id=44>
<http://www.immaterial.net/page.php3?id=45>
Nasty story of what an insider can do to your network:
<http://www.businessweek.com/bwdaily/dnflash/dec2000/nf20001213_253.htm>
Clever things to do with Internet bugs:
<http://www.theregister.co.uk/content/6/15423.html>
Last month I discussed a New Yorker story about someone who pretended to
be
an employee for a few weeks. The company in question is Luminant, which
wasn't pleased with the goings on:
<http://www.thestandard.com/article/display/0,1151,20534,00.html>
And here's an apology from the magazine for making up some of the
details:
<http://www.cnn.com/2000/US/12/05/newyorker.apology.ap/>
Looks like the guy social engineered the New Yorker's editors and
readers
(including me), as well as the folks at Luminant.
However, I have another story about a teen pretending to be a doctor at
a
DC-area hospital:
<http://www.washingtonpost.com/wp-dyn/articles/A13455-2000Dec15.html>
And a very strange story about a group impersonating the World Trade
Organization:
<http://www.nytimes.com/2001/01/07/weekinreview/07WORD.html?pagewanted=a
ll>
Along a similar line, a non-computer story about social engineering and
industrial espionage:
<http://www.nytimes.com/library/magazine/home/20001203mag-penenberg.html
>
Ireland is rushing into electronic voting:
<http://www.ireland.com/newspaper/ireland/2000/1218/hom18.htm>
MIT and CalTech announce a voting technology initiative:
<http://www.wired.com/news/politics/0,1283,40674,00.html>
Hacker tool that does a man-in-the-middle attack against SSL and HTTPS
(among other things):
<http://www.securityportal.com/cover/coverstory20001218.html>
<http://www.monkey.org/~dugsong/dsniff/>
A rebuttal:
<http://sysadmin.oreilly.com/news/silverman_1200.html>
And a follow-up by the original article's author:
<http://www.securityportal.com/seifried/sslssh-followup20001222.html>
Good information on various security resources on the WWW:
<http://www.infosecuritymag.com/dec00/heiser.htm>
The Counterpane Labs Web site is mentioned in the article.
An article about the FBI's current hypocritical pretense of protecting
"national security" and "privacy" by increasing its wiretapping
abilities,
using laws that were written to prevent hostile foreign domination of
critical national infrastructure.
<http://www.totaltele.com/view.asp?ArticleID=35057&pub=tt&categoryid=0>
The Center for Strategic and International Studies has released a
report:
"Cyber Threats and Information Security: Meeting the 21st Century
Challenge."
<http://www.csis.org/homeland/reports/cyberthreatsandinfosec.pdf>
In the report, the authors speculate that the Microsoft break-in, if
source
code was modified, could have grave security implications. The news
story
below has a funny Microsoft reaction. A Microsoft spokesman said: "The
CSIS quote sensationalizes the incident and misstates the facts in a
number
of important ways. Most important, Microsoft has repeatedly stated that
after tracking the intruders and investigating their activities, there
is
no evidence and no basis to believe that they had any access at all to
Windows or Office source code." Yes, we know that Microsoft has
repeatedly
stated that. We also know that Microsoft is not telling the truth about
the incident. The report expresses concern about what may have happened
when the Microsoft network was broken into, not what Microsoft *claims*
to
have happened.
<http://computerworld.com/cwi/story/0,1199,NAV65-663_STO55656_NLTs,00.ht
ml>
The NSA has finally declassified "NACSIM 5000: TEMPEST Fundamentals" and
"NSTISS 7000: TEMPEST Countermeasures for Facilities." They're old
documents, and redacted, but still interesting to read.
<http://cryptome.org/nacsim-5000.htm>
<http://cryptome.org/nstissi-7000.htm>
<http://www.eskimo.com/~joelm/tempest.html>
This really isn't a review of _Secrets and Lies_, but it is a good
article
that discusses some of its conclusions.
<http://www.webreview.com/pi/2000/12_29_00.shtml>
Excellent ActiveX security document from CERT:
<http://www.cert.org/reports/activeX_report.pdf>
Weird story about an abandoned NSA facility:
<http://www.sunspot.net/content/cover/story?section=cover&pagename=story
&sto
ryid=1150520223288>
Good article on Unicode and how it can be used to evade Intrusion
Detection
System products:
<http://www.securityfocus.com/frames/?focus=ids&content=/focus/ids/artic
les/
utf8.html>
The FBI tries to get industry to tell it about security incidents:
<http://washingtonpost.com/wp-dyn/articles/A25955-2001Jan5.html>
New security threats:
<http://cgi.zdnet.com/slink?74956:8469234>
Read the new federal guidelines for search and seizure of computer
equipment: the recently updated Computer Crime and Intellectual Property
Section of the Department of Justice manual. There are lots of invasive
searches discussed here -- car searches, work place searches, no-knock
searches, secret searches, border searches -- all of whose guidelines do
little to protect personal privacy. The page is 500+KB, but it's fun to
search it for keywords like "palm," "pager," or "trip-wire."
<http://www.cybercrime.gov/searchmanual.htm>
<http://www.wired.com/news/politics/0,1283,41133,00.html>
Now it seems that Egghead.com is claiming the hackers who broke in
didn't
get millions of credit card numbers like they previously thought. As I
say
in this article, that doesn't matter at this point. The damage was done
the moment anyone thought his or her credit card number was compromised;
the reality is much less relevant.
<http://news.cnet.com/news/0-1007-201-4421335-0.html?tag=st.ne.1002.thed
.sf>
** *** ***** ******* *********** *************
Counterpane Internet Security News
Password Safe has won best password protection freeware (admittedly, a
pretty narrow category) from Personal Firewall Guide:
<http://www.firewallguide.com/freeware.htm>
** *** ***** ******* *********** *************
Crypto-Gram News
Crypto-Gram has been nominated for an "Information Security Excellence
Award" by Information Security Magazine, in the "On-Line Security
Resource"
category. If you are a subscriber -- it's a free subscription -- you
can
vote. You will need a copy of your magazine's mailing label. Voting is
open until 19 January.
<http://www.cyclonecafe3.com/isawards/>
The biometrics article from the August 98 Crypto-Gram has been
republished
on the TechTV Web site:
<http://www.techtv.com/cybercrime/privacy/story/0,23008,3301301,00.html>
** *** ***** ******* *********** *************
Solution in Search of a Problem: SafeMessage
SafeMessage's security model is encrypted communications that is not
e-mail. E-mail is risky, because the encrypted messages can get stored
on
servers along the way, can get backed up on disks, can leave
footprints. The security model is someone so paranoid that even that is
too risky. Think of it as kind of a secure instant messaging.
There are lot of details about how the product actually works, and
whether
those are the best choices. But that's not the point here. I can't
figure
out the business model here. Surely there can't be a sustainable market
of
people this paranoid. There's barely a sustainable market of people
willing to use encrypted e-mail.
<http://www.safemessage.com>
** *** ***** ******* *********** *************
A Social Engineering Example
The Industry Standard published an example of social engineering in an
article on @Stake's vulnerability assessment service:
"We pretended to be employees of the (b-to-b) company. That allowed us
to
wreak havoc, because we had 10 accounts to play with. I could order a
piece of heavy equipment, like a backhoe, and have it financed instantly
online and have it shipped to Chile."
Here's the attack: Someone calls the company's Help Desk and pretends
to
be an employee. He has a known userID, and convinces the Help Desk
person
to reset his password. He then dials in (or VPNs in, or whatever) to
the
network using the reset password, and orders a tractor shipped to Chile.
This is almost impossible to catch automatically. There's not a company
out there that tracks which IP addresses are "valid" for their remote
sales
force; those people need to dial in from random ISPs that assign
addresses
from a pool. Even if the company recorded all successful logins and
their
originating addresses or phone numbers, it's nearly impossible to track
what's allowed and what isn't.
Even for the large number of telecommuters using DSL/cable modem VPNs to
get into their corporate networks, the vast majority of companies do not
restrict VPN connections to specific addresses. It's just too hard to
manage.
You improve things immensely -- assuming you're using a VPN -- by
requiring
client side certificates on the PC or laptop making the connection, and
by
using a one-time password system. You also improve things by convincing
your Help Desk staff to not reset passwords based on phone calls, but
that's hardly enforceable. The best idea I've heard is to train Help
Desk
employees not to give out reset passwords over the phone, but instead to
leave it on their voicemail. This makes a lot of sense to me.
The story:
<http://www.thestandard.com/article/display/0,1151,20472,00.html?nl=nr>
** *** ***** ******* *********** *************
The Doghouse: Gianus Technologies
Gianus claims that their dual boot system is more secure than an
encrypted
file system, just because they are hiding their partition. The hype on
their Web site is beyond decency.
<http://www.gianus.com>
** *** ***** ******* *********** *************
NIST Crypto Update
On January 5, 2001, NIST announced a Draft FIPS for HMAC (Keyed-Hash
Message Authentication Code) that is a generalization of HMAC as
specified
in Internet RFC 2104 and ANSI X9.71. A 90-day public comment period
ends
April 5, 2001.
<http://www.nist.gov/hmac>
On January 2, 2001, NIST posted a white paper that discusses plans for
developing standards and recommendations for public key-based key
management. This will be a two-part process, involving the development
of
1) a scheme definition document, and 2) a key management
guideline. <http://www.nist.gov/kms>
NIST will release the draft FIPS for the AES for public review "in the
very
near future." Final approvals for the release of this document are
pending. When an announcement is made, information on the draft and for
providing public comments will be available at the AES Web site.
<http://www.nist.gov/aes>
** *** ***** ******* *********** *************
Code Signing in Microsoft Windows
There's a report that the new version of Microsoft Windows, code named
"Whistler," will include code signing as a security feature. The idea
is
to protect users from Internet-borne viruses and Trojan horses. It is
unclear how much protection there really will be, and the side effects
are
significant.
Exactly how the system works is unknown (it's an application of
Authenticode), but the general idea is that code -- software programs,
plug-ins, whatever -- will come with a digital signature attached. The
operating system will check the digital signature and could allow only
--
presumably this will be optional -- signed code to execute. (Note the
word
"could"; this is an option you can turn off.)
The Internet allows viruses to spread faster than we've ever seen
before,
and clearly something has to be done. Assuming that this is implemented
correctly, it could help somewhat. But will this security feature be
turned on by default, or turned off by default? This is important; most
home users don't turn security features on. And Microsoft has a history
of
insecure default configurations.
User interface is vital. Will unsigned code be ignored, or will the
user
get a dialog box on the order of: "This code is unsigned. Do you
really
want it to run?" Most users are incapable of making intelligent
security
decisions, and are likely to let the unsigned code run anyway. "What's
the
problem, Ron? It's just a Christmas card from Sue. It can't possibly
do
anything bad." Code signing can't protect you if you can't figure out
whom
to trust.
The easiest way to defeat this security feature is to disable, or
corrupt,
the signature verification function on the computer. There are lots of
ways to do this: change the public key, modify the comparison so that
all
unsigned code is trusted, etc. This is not hard to do, if you can get a
malicious program to run on the victim's machine. But if the victim has
the code signing feature turned on, then presumably you can't do that.
So
it works.
At least, it works until someone figures out how to get his Trojan
signed. This brings us to some very important questions about the
system. What does it mean when a piece of code is signed? Is the idea
that all signed code will be verified as not being malicious, or simply
that signed code will be tied to the identity of the author? In the
first
case, you can be sure that anything signed is okay. In the latter case,
all you can be sure of is that you know who to blame when things go
wrong. Remember, digital signatures provide accountability, not
protection.
How is code signed? Do software companies get the blanket ability to
sign
code, or is each piece of code individually submitted? If it is the
former, defeating it can be as easy as breaking into a software
company's
network and slipping the malicious code into the signing process. Not
easy, but there are a lot of software companies out there; even if only
1%
of them have sloppy security, that's a lot of targets.
Who is in charge of signing code? If it is Microsoft, can they use this
as
a way of influencing software vendors? Steve Bellovin painted an
interesting scenario: "Remember the Instant Messenger war between
Microsoft and AOL? Now, suppose that the tables were reversed, that
Microsoft had a service that it didn't want AOL to access. Could they
revoke AOL's certificate? Would that be legal?" Do we really want
Microsoft to be the final arbiter on who can and cannot be a Windows
developer? There are other questions: Would small developers be able
to
cheaply get their code signed? What about shareware and public-domain
programs? Sometimes it's hard to tell the difference between a hacker
who
wrote a cool utility and one who has written a new piece of malware.
And what about script files and macros? While this feature could help
defend against executable viruses like ILOVEYOU from spreading, it
wouldn't
stop macro viruses like Melissa. Think about it. Melissa is embedded
in a
data file, so it can't be signed like a piece of software is. The whole
point of macros is that users can easily create them. If Microsoft adds
a
feature whereby the creator of the data file can sign it, that won't
help
either since Melissa sent copies of itself to people already in the
computer's address book. The point is that there is a big difference
between trusting a person and trusting a person's computer, and this
difference can fell many a system.
Code signing in Microsoft Windows is not new. There are two systems in
Windows 2000. Something called a "trusted application" is signed by the
software publisher, allowing users to verify that it has not been
tampered
with. (Anyone with a valid VeriSign signature key can sign their own
code.) But Windows doesn't warn users if the signature does not verify;
users have to manually check, and there's no automatic rejection of
unsigned applications. Another security option allows users to block
unsigned drivers from being installed in Windows. Microsoft controls
the
signing process for this system. The new security feature is an
extension
of this driver signing, so presumably Microsoft will control the signing
process here as well.
This is probably a good idea, although it won't do much to improve
Windows
security overall. It's just too easy to sign bad code or to subvert
signed
code. Most ActiveX exploits, for example, don't involve explicitly evil
code; they subvert vendor-supplied pre-installed signed code. And my
guess
is that most people will either turn it off or learn to automatically
click
"run it anyway." Preventing computers from executing every piece of
code
that comes across the Internet is probably a good thing; preventing them
from executing *any* piece of code that comes from the Internet is not.
<http://cgi.zdnet.com/slink?66540:8469234>
<http://www.zdnet.com/intweek/stories/news/0,4164,2657517,00.html>
** *** ***** ******* *********** *************
PGP Broken
Well, not really. No one has broken the cryptographic algorithms that
protect PGP traffic. No one has found a software flaw in the PGP
program,
allowing someone to read PGP-encrypted traffic. What someone did was to
install a keyboard sniffer on a computer. That someone was then able to
eavesdrop on every keystroke the user made: his PGP passphrase, the
plaintext of messages he typed, everything.
The victim is an alleged mobster, Nicodemo S. Scarfo, who was using PGP
to
encrypt his e-mail messages. The attacker is the FBI, who ran a
black-bag
operation against Scarfo and installed the keyboard sniffer. But the
principles surrounding this case could have profound effects on all of
us.
There are lots of constitutional issues here. The FBI did obtain a
warrant, but it is unclear if the warrant allowed this sort of
surveillance. Scarfo's attorney certainly doesn't think so, and many
civil
rights groups agree. Lots of people are watching this case, which may
force the courts to sort out some of these complicated issues.
My interest is more in the technical issues. The story graphically
illustrates an important lesson of computer and network security: it's
only
as secure as the weakest link. PGP provides just one piece of an e-mail
security solution. It protects messages in transit from the sender to
the
receiver. It protects against eavesdropping and impersonation attacks
that
happen during transit, in the network. PGP does not protect either
endpoint. Keyboard sniffers can capture plaintext and passphrases.
Trojan
horses and viruses can send signed PGP traffic in the computer user's
name. A clever attacker can even find printed copies of PGP-encrypted
e-mail in the trash. Last year I cowrote a paper that described a
social-engineering attack that could trick someone into decrypting his
own
PGP mail for an eavesdropper.
I worry that many cryptographers -- I have been as guilty as everyone
else
-- have lulled people into a false sense of security. We toss about
phrases like "2048-bit RSA" and "trillions of years to break," and we
believe them. Instead of building a defensive wall, we're planting a
huge
stake in the ground and hoping the attacker will only take the path that
runs into the stake. We can argue about whether the stake should be a
mile
tall or a mile and a half tall, but the reality is that a smart attacker
will simply go around the stake.
To be sure, cryptography is a good stake. It blocks the narrow gap
where
the attacker could easily pass through, protecting against non-invasive
attacks. Attackers can still "go around" the stake, but by doing things
such as breaking into Scarfo's home and installing the keyboard
sniffer. Many attackers are not motivated enough -- or even capable of
doing so.
There is another lesson we can learn from the story: in order to do its
job, the police do not need any escrow techniques for cryptographic
keys,
nor laws to force people to reveal their passphrases or keys on
demand. The lack of such things makes mass surveillance much more
difficult, but effective law enforcement is clearly possible.
A final comment in the Philadelphia Enquirer story is quite
telling: "Manno [Scarfo's attorney] would not discuss what his client
was
storing on the encrypted program but said Scarfo was using software
known
as PGP. 'It stands for Pretty Good Privacy,' the lawyer said with a
chuckle." That chuckle might raise the hackles of your average
cypherpunk,
but you have to admit he's right.
News reports:
<http://inq.philly.com/content/inquirer/2000/12/04/front_page/JMOB04.htm
>
<http://www.wirednews.com/news/politics/0,1283,40541,00.html>
<http://www.theregister.co.uk/content/4/15268.html>
<http://www.usatoday.com/life/cyber/tech/cti881.htm>
<http://slashdot.org/yro/00/12/06/0255234.shtml>
The FBI application to the court is at:
<http://www.epic.org/crypto/breakin/application.pdf>
The resulting court order is at:
<http://www.epic.org/crypto/breakin/order.pdf>
My PGP attack paper:
<http://www.counterpane.com/chotext.html>
** *** ***** ******* *********** *************
Comments from Readers
From: [log in to unmask]
Subject: Voting
Here in France (a technologically advanced country about 1/4 the
population
of the USA), we use paper ballots put into a transparent sealed box.
Ballots are counted immediately after the vote by volunteers supervised
by
representatives of each candidate.
This century-old system seems to be equal or superior to any mechanized
voting system I've heard of along each of your five dimensions. In
particular, it scales well as the number of available (human) ballot
counters is proportional to the number of voters. The time required to
get
the first, unchecked results is practically constant for all elections:
local, regional or national. The delay for definitive, officially
announced results grows logarithmically with the number of voters as
partial counts are transmitted up a hierarchical structure, with
additions
and verifications at each node.
In a typical French presidential election, the media announce their
first
poll-based estimated results as soon as the voting booths close (they
are
not allowed to do it before). Estimates based on actual counting are
published about two hours later, "official" preliminary results on the
next
morning, and final results after a week. I seriously doubt that any
mechanized voting system would significantly reduce these figures. Nor
would it offer any advantage in case of a particularly tight election
requiring a second counting.
Voting machines were tested, a few decades ago, in some regions of
France
with a high fraud rate. The goal was to reduce fraud, not increase
speed. As far as I know, these machines did not show any superiority of
any kind over paper ballots, and are no longer used anywhere in the
country.
You write: "in the rush to improve the first four attributes, accuracy
has
been sacrificed." Not only that, but it remains to be shown that any of
the first four attributes were actually improved.
From: Louis Bertrand <[log in to unmask]>
Subject: Voting
There is no improvement in the democratic process by counting the votes
ever faster, only playing to the media's horse race mentality. All this
technology aims to solve a non-existent problem.
Consider Canada's 100% manual system: pencils and hand-counted paper
ballots. The polling stations are run by political appointees, but the
catch is that appointees who work together must be from at least two
different political parties. People simply put their differences aside,
get some coffee and pizza, and count ballots all evening.
Canada's latest national election was counted in less than twelve hours
after the polling stations closed, as was Ontario's round of municipal
elections a few weeks before. Recounts? No problem. The ballots are
available but there's fewer people to count them, so it takes about a
week. That's still better than five weeks.
From: Daniel Balparda de Carvalho <[log in to unmask]>
Subject: Voting
Here in Brazil, voting is a duty. You *must* vote. Many citizens are
also
required to help in the elections. I have been for many elections
called
to help. Something like six years ago we had plain normal paper
elections.
Since then the system has been substituted by an electronic one. In our
last elections (last October) we had an 100% electronic system. It
worked
perfectly and the results of the election were known in the same day.
The
system has been very very successful and I think we can be proud of it.
If
you don't mind me saying, the gross errors in the US elections have
become
quite a joke in Brazil.
How does it work? The machine is a tamperproof modified PC that the
police
delivers at the voting site. It has a display, a keypad with the
numbers
and three buttons, a mini printer, a 3.5 floppy drive and a remote
module.
Before voting starts the machine prints a slip of paper showing its
initial
"internal state"; that is, the initial number of votes for all
candidates.
This is just to show that everyone has zero votes to start with. After
this a small ballot box is attached to the machine. Every voter can see
in
the display the photograph of his candidate before confirming the vote
so
that misvotes are minimal. For every vote, the machine records the vote
in
its internal disk and drops a slip of paper into the ballot box. All
the
process of voting can be commanded by a small "remote control" that the
machine has. Of course the controller can't see the vote, but he can
see
the status of the machine and he is the one that authorizes a valid
voter
so that he can use the machine. At the end of the election the ballot
box
is sealed, and the machine records the results on a 3.5 floppy that is
also
sealed. Then the machine prints several copies of the results for that
machine. All of these are se
nt to the processing facilities. If the floppy is OK then it's all that
is
needed. If the floppy fails you have the printed results, and if that
also
fails you can manually count the votes in the ballot box. It is
interesting to note that one copy of the machine's results is placed in
the
voting place so that voters can come and see the partial result of their
section.
I have twice worked in an electronic election with these machines and I
can
say (as a person highly involved with security processes) that it is
very
well designed. I can't think of any obvious way to defraud the system.
I
have heard of no grave problem with this system and I am reasonably
confident that it is a good system.
From: [log in to unmask] (Phil Howard)
Subject: Voting
One idea is to go back to the traditionally hand marked paper ballot,
but
add an on-the-spot scanner to read it. The scanner will check for
inconsistencies like voting twice in a one-vote office. It can also
report
how many offices recorded no vote at all. A more sophisticated scanner
can
measure the level of reading for each box marked and give an assessment
of
the accuracy of that read, and reject a ballot with marginal markings.
The
voter can read the screen and confirm that their votes are read
properly,
or see what mistakes are made, much like a digital system with data at 0
volts and 1 volt would reject levels between 0.3 volts and 0.7 volts as
potentially ambiguous. The "error correction" would be to "resend"
(re-mark the ballot or make a new one).
The scanner/computer would serve ONLY to test the ballots for accuracy
of
voting, AND (when a button is pressed to indicate acceptance) record the
vote in the first round of counting. If this component fails, voting
can
still go on, with voters (and polling place workers assisting) checking
their own ballots, and early totals being unavailable.
One thing we need to do in all this not only make a system WE know can
be
very accurate and incorruptible, but also make a system that actually
appears to be accurate and probably incorruptible to the largest number
of
people.
From: "C.P. Crossno" <[log in to unmask]>
Subject: Voting
Use lottery terminals. In general, when you make a whole lot of things
they tend to work well and cost less. There are probably at least 50
times
as many lottery ticket machines as there are voting machines and they
work
very well. Using the same technology as the lottery ticket machine,
most
of the dilemmas we have faced during the past few weeks could be
avoided.
In Texas, the lottery cards have five columns and each column has 54
numbers. A total of 270 choices are available using just these five
columns. To eliminate the need of a hand recount, the voter must mark
three separate numbers for each candidate. A vote will be registered if
two out of three of the numbers are marked (maybe one out of three in
Palm
Beach County). Each ballot will permit the selection of up to 90
candidates or issues, each with a triple redundancy.
Another benefit would be a fixed numbered set of ballots using very
large
numbers with random gaps for identification that would detect illegally
printed ballots.
The lottery ticket machines (modified for voting) could even print a
receipt showing the voter how his votes were registered.
From: Mark Seecof, <[log in to unmask]>
Subject: Digital Signatures
Respectfully, Ben Wright is wrong in his December Crypto-Gram letter.
Part
of the E-Sign law (Section 102(a)(2)(A)(ii)) forbids states to enforce
technical standards for electronic signatures. This may be read as
promoting technical "competition" (e.g., states can't require electronic
sigs to use a specific vendor's implementation of RSA) but will have the
effect of legitimizing completely worthless (e.g., checkbox on Web form)
so-called e-signatures.
When you go to state court to deny some alleged signature and your
experts
testify that the technical basis of the alleged signature makes it
impossible to authenticate, your opponent will whap you with the E-Sign
law
-- the state court is expressly forbidden to enforce any technical
standard, so you must defend your case on other, fuzzier grounds.
See: <http://www.ecommerce.gov/ecomnews/ElectronicSignatures_s761.pdf>
From: "Bluefish (P.Magnusson)" <[log in to unmask]>
Subject: Retaliation
> And the question of retaliation: should you strike back
> against hackers if the police can't do anything?
>
<http://computerworld.com/cwi/story/0,1199,NAV65-663_STO53869_NLTs,00.ht
ml>
The story features Ira Winkler, "president of security consulting firm
Internet Security Advisors Group in Severna Park, MD" who has a few
interesting quotes. For example: "There's nothing wrong with doing a
Traceroute [a tracking program] back to the IP address, so long as you
alert the administrator...."
Ira seems to not be aware of the fact that traceroutes are perfectly
normal
tools, used commonly to track network faults. Why on earth would anyone
even consider telling someone they were about to use it? It would be
incredibly stupid to even try to log usage of traceroute.
Also: "When you detect an attack, dump all logs to read-only tape so
you
can prove that the data hasn't been tampered with."
Where do I get this Mission Impossible stuff that I can write to, but is
read only, and at the same time verifies that what is written hasn't
been
tampered with? Seems like Ira has gone shopping in the same store where
Mulder bought "copy protected" floppies for an X-Files movie.
From: "Penafiel, Cathy" <[log in to unmask]>
Subject: Marcus Ranum's essay on the Window of Exposure
In my experience working on a large government contract, it is very
difficult to get patches/tools into operational computer systems. By
operational systems, I mean a collection of computing resources,
hardware
and software, which are dedicated to perform a mission. Our systems
have
real-time, near real-time, and/or rigorous production
schedules. Collectively, our various facilities process thousands of
megabytes of spacecraft and science telemetry on a daily basis.
In these environments, there is great reluctance on the part of
administrators, developers, operations, and the government to perturb
the
operational systems. Any changes are rolled out with the greatest of
caution, and for good reasons too. We have had instances where vendor
patches have taken out critical mission capabilities which were not
discovered until after the systems were delivered to operations.
Although
it was possible to recover before a spacecraft was put into safehold and
science data lost, the resulting scramble was an unnecessarily
gut-wrenching experience for all and resulted in a black mark for the
contract from the customer.
As you so often point out in your essays and commentaries, there is no
such
thing as "perfect" security, either from a technical or an
organizational
perspective. Instead, we in the security business, either as engineers,
consultants, or network/system administrators, are left to balance the
various risk factors imposed by operating systems, networks, tools,
applications, users, configuration management processes, etc. Judgment,
experience, and an ability to articulate the tradeoffs/risks to the
responsible manager (whether that manager be a civil servant or a CEO)
are
equally important in maintaining secure systems.
The window of exposure is a useful concept, difficult to meaningfully
quantify. In general, organizations *should* run their operations so
that
the window of exposure is minimized, but it depends on what your
organization's risk aversion is. Here, our customer is more averse to
risks to operational spacecraft and science data production than to
dangers
posed by unknown marauders over the hill. In the real world of missions
and systems, there is no silver bullet, as Mr. Ranum implies in his
letter.
** *** ***** ******* *********** *************
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,
insights, and commentaries on computer security and cryptography.
To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or
send a
blank message to [log in to unmask] To
unsubscribe,
visit <http://www.counterpane.com/unsubform.html>. Back issues are
available on <http://www.counterpane.com>.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who
will
find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long
as
it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO
of
Counterpane Internet Security Inc., the author of "Applied
Cryptography,"
and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He
served
on the board of the International Association for Cryptologic Research,
EPIC, and VTW. He is a frequent writer and lecturer on computer
security
and cryptography.
Counterpane Internet Security, Inc. is a venture-funded company bringing
innovative managed security solutions to the enterprise.
<http://www.counterpane.com/>
Copyright (c) 2001 by Counterpane Internet Security, Inc.
************************************************************************************
Distributed through Cyber-Society-Live [CSL]: CSL is a moderated discussion
list made up of people who are interested in the interdisciplinary academic
study of Cyber Society in all its manifestations.To join the list please visit:
http://www.jiscmail.ac.uk/lists/cyber-society-live.html
*************************************************************************************
|
