Network Security
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
FWD: CRYPTO-GRAM, September 15, 2000
- From: Paul Howell
- Date: Fri Sep 15 07:34:13 2000
- ------- Forwarded Message
Date: Fri, 15 Sep 2000 00:39:26 -0500
To: crypto-gram@chaparraltree.com
From: Bruce Schneier <schneier@counterpane.com>
Subject: CRYPTO-GRAM, September 15, 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
Sender: crypto-gram-return-30-grue=merit.edu@chaparraltree.com
CRYPTO-GRAM
September 15, 2000
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
schneier@counterpane.com
<http://www.counterpane.com>
A free monthly newsletter providing summaries, analyses, insights, and=20
commentaries on computer security and cryptography.
Back issues are available at <http://www.counterpane.com>. To subscribe or=
=20
unsubscribe, see below.
Copyright (c) 2000 by Counterpane Internet Security, Inc.
** *** ***** ******* *********** *************
In this issue:
Full Disclosure and the Window of Exposure
_Secrets and Lies_ News
Crypto-Gram Reprints
News
Counterpane Internet Security News
Carnivore Disinformation
FBI Requires Constitutional Changes
The Doghouse: FaceMail
PGP Vulnerability
Comments from Readers
** *** ***** ******* *********** *************
Full Disclosure and the Window of Exposure
To read this essay with the nifty graphs, see:
<http://www.counterpane.com/crypto-gram-0009.html#1>
Every season yields a bumper crop of computer security stories: break-ins,=
=20
new vulnerabilities, new products. But this season has also given us a=20
crop of stories about computer security philosophy. There has been a=20
resurgence in opposition to the full disclosure movement: the theory that=20
states that publishing vulnerabilities is the best way to fix them. In=20
response, defenders of the movement have published their rebuttals. And=20
even more experts have weighed in with opinions on the DeCSS case, where a=
=20
New York judge ruled that distributing an attack tool is illegal.
What's interesting is that everybody wants the same thing; they're just=20
disagreeing about the best way to get there.
When a security vulnerability exists in a product, it creates what I call a=
=20
window of exposure. This window exists until the vulnerability is patched,=
=20
and that patch is installed. The shape of this window depends on how many=
=20
people can exploit this vulnerability, and how fast it is patched. What=20
everyone wants is to make this window as small as possible.
A window of exposure has five distinct phases. Phase 1 is before the=20
vulnerability is discovered. The vulnerability exists, but no one can=20
exploit it. Phase 2 is after the vulnerability is discovered, but before=20
it is announced. At that point only a few people know about the=20
vulnerability, but no one knows to defend against it. Depending on who=20
knows what, this could either be an enormous risk or no risk at=20
all. During this phase, news about the vulnerability spreads -- either=20
slowly, quickly, or not at all -- depending on who discovered the=20
vulnerability. Of course, multiple people can make the same discovery at=20
different times, so this can get very complicated.
Phase 3 is after the vulnerability is announced. Maybe the announcement is=
=20
made by the person who discovered the vulnerability in Phase 2, or maybe it=
=20
is made by someone else who independently discovered the vulnerability=20
later. At that point more people learn about the vulnerability, and the=20
risk increases. In Phase 4, an automatic attack tool to exploit the=20
vulnerability is published. Now the number of people who can exploit the=20
vulnerability grows exponentially. Finally, the vendor issues a patch that=
=20
closes the vulnerability, starting Phase 5. As people install the patch=20
and re-secure their systems, the risk of exploit shrinks. Some people=20
never install the patch, so there is always some risk. But it decays over=
=20
time as systems are naturally upgraded.
In some instances the phases are long, and sometimes they're=20
short. Sometimes Phase 5 happens so fast that Phases 3 and 4 never=20
occur. Sometimes Phase 5 never occurs, either because the vendor doesn't=20
care or no fix is possible. But this is basically the way things work.
The goal of any responsible security professional is to reduce the window=20
of exposure -- the area under the curve -- as much as possible. There are=
=20
two basic approaches to this.
The first is to reduce the window in the space dimension by limiting the=20
amount of vulnerability information available to the public. The idea is=20
that the less attackers know about attack methodologies, and the harder it=
=20
is for them to get their hands on attack tools, the safer networks=20
become. The extreme position in this camp holds that attack tools should=20
be made illegal.
This might work in theory, but unfortunately it is impossible to enforce in=
=20
practice. There is a continuous stream of research in security=20
vulnerabilities, and most of this research results in public=20
announcements. Hackers write new attack exploits all the time, and the=20
exploits quickly end up in the hands of malicious attackers. Any one=20
country could make some of these actions illegal, but it would make little=
=20
difference on the international Internet. There have been some isolated=20
incidences of a researcher deliberately not publishing a vulnerability he=20
discovered, but public dissemination of vulnerability information is the=20
norm...because it is the best way to improve security.
The second approach is to reduce the window of exposure in time. Since a=20
window remains open until the vendor patches the vulnerability and the=20
network administrator installs the patches, the faster the vendor can issue=
=20
the patch the faster the window starts closing. To spur the vendors to=20
patch faster, full-disclosure proponents publish vulnerabilities far and=20
wide. Ideally, the vendor will distribute the patch before any automatic=20
attack tools are written. But writing such tools can only hasten the=
patches.
This also works a lot better in theory than in practice. There are many=20
instances of security-conscious vendors publishing patches in a timely=20
fashion. But there are just as many examples of security vendors ignoring=
=20
problems, and of network administrators not bothering to install existing=20
patches. A series of credit card thefts in early 2000 was facilitated by a=
=20
vulnerability in Microsoft IIS that was discovered, and a patch released=20
for, a year and a half earlier.
The problem is that for the most part, the size and shape of the window of=
=20
exposure is not under the control of any central authority. Not publishing=
=20
a vulnerability is no guarantee that someone else won't publish=20
it. Publishing a vulnerability is no guarantee that someone else won't=20
write an exploit tool, and no guarantee that the vendor will fix=20
it. Releasing a patch is no guarantee that a network administrator will=20
actually install it. Trying to impose rules on such a chaotic system just=
=20
doesn't work.
And to make matters worse, it's never one single vulnerability. There are=
=20
dozens and hundreds of vulnerabilities, all with overlapping windows. One=
=20
vulnerability might be shrinking while another ten are growing. We're like=
=20
the little Dutch boy, plugging leaks in the dike with our fingers while=20
others spring up nearby. It doesn't matter if we believe that full=20
disclosure is the best way to reduce the window's size or if quietly=20
alerting the vendor does better...we're going to lose the war fighting it=20
either way.
Vulnerabilities are inevitable. As our networks get more complex and more=
=20
pervasive, the vulnerabilities will become more frequent, not less. We're=
=20
already seeing this; every year brings more security holes than the=20
previous one. The only way to close the window of exposure is to make it=20
not matter. And the only way to do that is to build security systems that=
=20
are resilient to vulnerabilities.
In _Secrets and Lies_, I talk about security processes that make systems=20
resilient to vulnerabilities. The most relevant one to this debate is=20
detection and response. Most computer-security products are sold as=20
prophylactics: firewalls prevent network intrusions, PKI prevents=20
impersonation, encryption prevents eavesdropping, etc. The problem with=20
this model is that the product can either succeed or fail: either the=20
window of exposure is closed or it is open. Good security includes not=20
only protection, but also detection and response. An Internet alarm system=
=20
that detects attacks in progress, regardless of the vulnerability that was=
=20
exploited, has the ability to close the window of exposure completely.
The key to Internet detection and response is vigilance. Attacks can=20
happen at all times of the day and night, and any day of the year. New=20
attack tools appear all the time; new vulnerabilities become public all the=
=20
time. I built Counterpane Internet Security, Inc. as a managed security=20
monitoring company because I saw this as the only way to bring security to=
=20
computer networks. Without outsourced detection and monitoring, we're at=20
the mercy of all the hackers and product vendors and security professionals.
Those advocating secrecy are right that full disclosure causes damage, in=20
some cases more damage than good. They are also right that those who build=
=20
attack tools should be held liable for their actions; the defense of "I=20
just built the bomb; I didn't place it or set the fuse" rings hollow. But=
=20
they are wrong to think they can enforce secrecy. Information naturally=20
disseminates, and strategies that go against that are doomed. Those=20
advocating full disclosure are right that rapid dissemination of the=20
information benefits everyone, even though some people make ill use of that=
=20
information. We would be in a much worse position today if vulnerability=20
information were only in the hands of a privileged few.
Neither full disclosure nor secrecy "solve" computer security; the debate=20
has no solution because there is no one solution. Both sides are missing=20
the point. The real issue, how to close the window of exposure, is more=20
subtle. We have to stop thinking of software security as an end state,=20
that fixing the bugs will somehow make the software perfect. Security=20
vulnerabilities are inevitable and there will always be a window of=20
exposure; smart security solutions will work regardless.
Marcus Ranum started this debate at BlackHat. A transcript of his talk=20
isn't available on-line, but these two essays are:
<http://pubweb.nfr.net/~mjr/usenix/ranum_5.pdf>
<http://pubweb.nfr.net/~mjr/usenix/ranum_elx_cocktail.pdf>
Weld Pond's rebuttal:
<http://www.zdnet.com/zdnn/stories/comment/0,5859,2615973,00.html>
Stuart McClure and Joel Scambray's rebuttal:
<http://www.infoworld.com/articles/op/xml/00/08/14/000814opswatch.xml>
Another view:
<http://news.cnet.com/news/0-1005-200-2634067.html>
News article:
<http://www.zdnet.com/zdnn/stories/news/0,4586,2608077,00.html>
My older writings on this topic:
<http://www.counterpane.com/crypto-gram-0001.html#KeyFindingAttacksandPublic=
=20
ityAttacks>
<http://www.counterpane.com/crypto-gram-0002.html#PublicizingVulnerabilities=
>
** *** ***** ******* *********** *************
_Secrets and Lies_ News
_Secrets and Lies_ is officially published. This means that you can walk=20
into a bookstore and buy it. Last month, when I announced the book, it was=
=20
printed and in the Wiley warehouse but not in bookstores.
Initial feedback has been great. There are already reviews on the=20
Amazon.com Web site. The Economist published a review of the book, as did=
=20
Business Week, Industry Standard, New Scientist, and Salon. Other reviews=
=20
are coming in the next few weeks.
Here's the publishing information:
Secrets and Lies: Digital Security in a Networked World
Bruce Schneier
John Wiley & Sons, 2000
ISBN: 0-471-25311-1
$29.99
Book Web site:
<http://www.counterpane.com/sandl.html>
See the Table of Contents:
<http://www.counterpane.com/sandlcont.html>
Read the Preface:
<http://www.counterpane.com/sandlpref.html>
Amazon.com has posted Chapter 3:
<http://www.amazon.com/exec/obidos/ts/book-excerpt/0471253111>
Buy the book here:
<http://www.amazon.com/exec/obidos/ASIN/0471253111/counterpane/>
Reviews:
<http://www.salon.com/tech/review/2000/08/31/schneier/index.html>
<http://www.businessweek.com/2000/00_38/b3699176.htm>
<http://www.thestandard.com/subject/book/display/0,4294,182,00.html>
All reviews:
<http://www.counterpane.com/sandlrev.html>
Bruce Schneier is planning a book tour for October. Planned locations=20
include San Francisco, San Jose, Seattle, Portland, New York, Boston, and=20
Washington, DC. Tour dates and locations can be found here:
<http://www.counterpane.com/sandltour.html>
** *** ***** ******* *********** *************
Crypto-Gram Reprints
Open-source and security:
<http://www.counterpane.com/crypto-gram-9909.html#OpenSourceandSecurity>
Factoring a 512-bit number:
<http://www.counterpane.com/crypto-gram-9909.html#Factoringa512-bitNumber>
** *** ***** ******* *********** *************
News
Another massive net attack coming?
http://www.zdnet.com/zdnn/stories/news/0,4586,2614854,00.html
Analytic Thinking and Presentation for Intelligence Producers, Analysis=20
Training Handbook. By the CIA's Office of Training and Education.
<http://216.167.120.50/cia-ath-pt1.htm>
How one bank survived a security audit: In an effort to identify potential=
=20
security risks, a bank shares its experiences of having its systems=20
scrutinized.
<http://www.eweek.com/a/pcwt0008141/2613074/>
Software Risk Management Conference:
<http://www.isacc.com/>
Why Microsoft doesn't have to improve security.
<http://news.cnet.com/news/0-1005-200-2528362.html>
Cheaper technologies than PKI:
<http://www.zdnet.com/eweek/stories/general/0,11011,2617314,00.html>
There's a lot of snake-oil in this article, but some of the ideas are good.
A good article on the difficulty of normal people actually using security=20
technology.
<http://www.zdnet.com/eweek/stories/general/0,11011,2617318,00.html>
Hacking insurance (a good article).
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO48721,00.html>
An excellent analysis of the DeCSS decision by Emmanuel Goldstein. Worth=20
reading.
<http://www.2600.com/news/2000/0821.html>
Now that CSS is broken, the DVD manufacturers have another dumb idea:=20
watermarking.
<http://www.wired.com/news/technology/0,1282,38279,00.html>
Internet bank robbery:
<http://www.independent.co.uk/news/Digital/Update/2000-08/first230800.shtml>
The bank is claiming that no money was stolen, and the truth seems very=20
mundane.
<http://www.theregister.co.uk/content/1/12822.html>
And the culprits have been apprehended.
<http://www.zdnet.com/zdnn/stories/news/0,4586,2618631,00.html?chkpt=3Dzdhpn=
ew=20
s01>
Two good articles on encryption algorithms, the first on DES and the second=
=20
on AES.
<http://www.ams.org/notices/200003/fea-landau.pdf>
<http://www.ams.org/notices/200004/fea-landau.pdf>
It's over six months since last February's massive distributed=20
denial-of-service attacks. One survey found over 100,000 computers still=20
vulnerable. What does it take to get through to some people?
<http://www.internetnews.com/bus-news/article/0,2171,3_436031,00.html>
New trend: breaking into networks and extorting money out of the owners:
<http://www.businessweek.com/bwdaily/dnflash/aug2000/nf20000822_308.htm>
New computer virus (similar to the Love Bug, but with a much nastier=20
payload) targets children:
<http://www.wired.com/news/technology/0,1282,38412,00.html>
<http://vnunet.com/News/1109520>
The safety of open source operating systems:
<http://securityportal.com/topnews/opensourcesafe20000825.html>
TRUSTe violating its own security policy? Weren't they the ones who told=20
us that self-regulation would work?
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO49059,00.html>
<http://www.cnn.com/2000/TECH/computing/08/24/online.privacy.ap/index.html>
JAVA emulators of WWII crypto devices: Purple, Sigaba, Enigma, Russian=20
Espionage Cipher, and a public domain Bombe. Good descriptions, too.
<http://dev.thinkquest.org/C004911/>
First malware for the Palm Pilot (a Trojan horse):
<http://www.zdnet.com/zdhelp/stories/main/0,5594,2621711,00.html>
And a response from anti-virus companies:
<http://news.cnet.com/news/0-1006-200-2720432.html?tag=3Dst.ne.1002.tgif.ni>
Password crackers: This site lists all sorts of password crackers that run=
=20
dictionary attacks against a variety of encryption products. My own=20
Password Safe is on the list; there's a password cracker for that,=20
too. The moral is not to choose a guessable password, and that more and=20
more passwords become guessable every year.
<http://members.aol.com/jpeschel/crack.htm#ktools>
Schneier and security:
<http://www.zdnet.com/enterprise/stories/main/0,10228,2615692,00.html>
In a bizarre twist, @Stake (a company filled with hackers) refuses to hire=
=20
someone because he's a reformed (but once convicted) hacker. I understand=
=20
the reluctance to hire criminals, but it seems hypocritical to make a=20
hiring decision based on whether someone was caught hacking ten years ago=20
or whether he got away with it.
<http://www.securityfocus.com/news/79>
A good essay on the risks of Carnivore:
<http://www.crypto.com/papers/carnivore-risks.html>
A Thai company has developed a security robot that can shoot=20
criminals. According to the company: "It is armed with a pistol that can=20
be programmed to shoot automatically or wait for a fire order delivered=20
with a password from anywhere through the Internet."
<http://catless.ncl.ac.uk/Risks/21.02.html#subj8>
<http://news.bbc.co.uk/hi/english/sci/tech/newsid_904000/904619.stm>
Words fail me on this one.
More web bugs. Someone can add a web bug to a Microsoft Word document and=
=20
track who opens it. Nasty side effect of being online all the time.
<http://www.privacyfoundation.org/advisories/advWordBugs.html>
A demonstration bugged document:
<http://www.privacycenter.du.edu/demos/bugged.doc>
News articles:
<http://news.cnet.com/news/0-1005-200-2652562.html>
<http://www.computerworld.com/cwi/story/0,1199,NAV47_STO49331,00.html>
<http://www.wired.com/news/technology/0,1282,38516,00.html>
Microsoft's response to the web bugs is pretty weird. They make a big deal=
=20
about cookies, not web bugs. It's sort of like they missed the point=20
completely.
<http://www.microsoft.com/technet/security/cookie.asp>
RSA Inc. executes a clever publicity move. Many events and parties are=20
planned to commemorate the expiration of the RSA algorithm patent on 20=20
September 2000. So what does RSA Inc. do? They put the algorithm in the=20
public domain two weeks early and pre-empt the publicity. Meaningless, but=
=20
pretty clever.
<http://www.rsasecurity.com/news/pr/000906-1.html>
<http://www.zdnet.com/zdnn/stories/news/0,4586,2624678,00.html>
DDOS tools get even easier to use:
<http://www.nwfusion.com/news/2000/0906ddos.html>
Another Microsoft bug (this one in NetBIOS). This one affects Windows 95,=
=20
98, NT, and 2000. The really odd piece of this story is that Microsoft=20
doesn't plan on releasing a patch for this one.)
<http://www.pgp.com/research/covert/advisories/045.asp>
Global tracking and MSN GUID. Nasty privacy violation.
<http://www.pc-help.org/privacy/ms_guid.htm>
Internet Explorer persistence. Yet another Microsoft security problem:
<http://news.cnet.com/news/0-1005-200-2751843.html>
Amazon.com leaks customer e-mail addresses:
<http://computerworld.com/cwi/story/0,1199,NAV47_STO49648,00.html>
The Secure Digital Music Initiative is having a hacking contest to see=20
which of their content protection schemes are better. I've already written=
=20
about why hacking contests make no sense, and don't do anything to show=20
which scheme is better. I've also already written about why the whole=20
concept of content protection is flawed, and that it doesn't matter how=20
good the scheme is.
<http://www.hacksdmi.org/>
Self-propagating security patch...in rabbits!
<http://www.newscientist.com/news/news.jsp?id=3Dns225354>
The story of the stolen Bletchley Park Enigma machine gets wierder:
<http://www.guardianunlimited.co.uk/Archive/Article/0,4273,4063014,00.html>
<http://www.thetimes.co.uk/news/pages/tim/2000/09/13/timnwsnws02044.html>
The European Telecommunication Standards Institute (ETSI) has made a bunch=
=20
of encryption algorithms public:
<http://www.etsi.org/dvbandca/>
A just-released GAO report gives the government bad marks when it comes to=
=20
security. Collectively, the agencies averaged D-, with more than a quarter=
=20
of them flunking, and only two out of twenty-four agencies getting better=20
than a C rating.
<http://washingtonpost.com/wp-dyn/articles/A52756-2000Sep11.html>
<http://www.foxnews.com/national/091100/govsecurity.sml>
<http://www.cnn.com/2000/TECH/computing/09/11/security.report/index.html>
** *** ***** ******* *********** *************
Counterpane Internet Security News
Bruce Schneier is speaking at the eCFO Conference in Atlanta, on 19=
September.
<http://www.e-cfoexpo.com/>
Bruce Schneier is speaking at the E-Business Security Summit in Chicago, on=
=20
4 October.
<http://www.aliconferences.com/conferences/bsecurity_oct2k.htm>
** *** ***** ******* *********** *************
Carnivore Disinformation
This bit, from Newsweek's Periscope, sounds very much like government=20
propaganda:
Tracking bin Laden's E-Mail
American counter-terrorism experts are aghast that the FBI has gone public=
=20
with Carnivore, its new Internet-wiretap system. The reason for their=20
dismay: Osama bin Laden uses e-mail to communicate with his terrorist=20
network. The intelligence community's ability to track his messages has=20
been, according to one intelligence source, "the biggest single factor in=20
shutting down several planned operations," including some in the United=20
States. "Bin Laden thought his communications were secure," says the=20
source. "They weren't. Now we've told him."
FBI officials acknowledge that Carnivore has been used about 25 times,=20
primarily in terrorism investigations. But they decline to comment on its=
=20
use against bin Laden. "Everyone knows we can wiretap phones," says a=20
bureau spokesman. "There's no reason why an ability to intercept e-mails=20
must necessarily be covert."
** *** ***** ******* *********** *************
FBI Requires Constitutional Changes
It's hard to know what to think of this:
"One of the FBI requirements for the Internet kiosks at the 2002 Olympics=20
is that the FBI be able to record all passwords, copy all sent email, and=20
divert sent email for administrative decisions on whether it should be=20
delivered."
If it is true, it is the most intrusive power grab we've seen so=20
far. Would there even be warning notices on the kiosks? Would they demand=
=20
eavesdropping rights on all direct computer hookups as well? The mind=
boggles.
<http://www.pbs.org/cringely/pulpit/pulpit20000803.html>
** *** ***** ******* *********** *************
The Doghouse: FaceMail
FaceMail uses your "personal biometric facial template" to encrypt and=20
decrypt emails. They don't say what happens if someone else steals your=20
key or if you have surgery.
Zero technical details can be found at:
<http://www.identalink.de/>
** *** ***** ******* *********** *************
PGP Vulnerability
A very serious PGP vulnerability was just discovered. Using this=20
vulnerability, an attacker can create a modified version of someone's=20
public key that will force a sender to encrypt messages to that person AND=
=20
to the attacker.
Let me explain.
Starting with PGP version 5.5, the software supported something called an=20
Additional Decryption Key (ADK). Normally, when a PGP user creates a PGP=20
certificate, it contains a single public key (as well as identifying=20
information as to who the key belongs to). PGP version 5.5 and 6.x allow=20
the user to add additional ADKs to the certificate. When a sender encrypts=
=20
a message to that user, PGP will automatically encrypt the message in both=
=20
the user's public key and the ADK. The idea is that the ADK belongs to the=
=20
secret police, or the user's employer, or some organization, and that=20
organization can intercept the encrypted message and read it.
(On Slashdot I said that Network Associates did this when they joined the=20
Key Recovery Alliance, but PGP Inc. added the feature before then. They=20
needed it to get certain corporate contracts.)
The flaw is that some version of PGP don't require the ADKs to be in the=20
signed portion of the PGP certificate. What this means is that an=20
organization can take a PGP certificate, append his ADK, and spread it out=
=20
to the world. This tampered version of the certificate will remain=20
unnoticed by anyone who doesn't manually examine the bytes, and anyone=20
using that tampered version will automatically and invisibly encrypt all=20
messages to the organization as well as the certificate owner.
Colleague Greg Guerin likened the lesson of this vulnerability to something=
=20
he learned in kindergarten: "Don't put something in your mouth unless you=20
know where it's been."
The reaction from Network Associates has been pretty good: they fixed the=20
problem. Unfortunately, the president of the PGP Security unit=20
demonstrated a high degree of cluelessness when he said: "This a fairly=20
esoteric attack. It's not likely that anybody without specialized=20
knowledge could use it." Certainly it is an esoteric attack but, as we all=
=20
know, that person with specialized knowledge could easily encapsulate the=20
attack in a point-and-click program that any script kiddie could use.
On the plus side, it doesn't seem like anyone took advantage of this=20
vulnerability. Network Associates inspected all 1.2 million PGP keys on=20
its keyserver, and found none of them were tampered with in this way.
Way back in 1997 a bunch of us cryptographers predicted that adding key=20
escrow would make system design harder, and would result in even more=20
security problems. This is an example of that prediction coming true.
Research paper on the vulnerability:
<http://senderek.de/security/key-experiments.html>
CERT Advisory:
<http://www.cert.org/advisories/CA-2000-18.html>
Slashdot article:
<http://slashdot.org/articles/00/08/24/155214.shtml>
News reports:
<http://www.thestandard.com/article/display/0,1151,17978,00.html>
Nice summary article:
<http://www.digitalmass.com/columns/software/0828.html>
Network Associates reaction:
<http://www.pgp.com/other/advisories/adk.asp>
1997 Risks of Key Escrow Paper:
<http://www.counterpane.com/key-escrow.html>
** *** ***** ******* *********** *************
Comments from Readers
From: Brian Taylor
Subject: PGP Vulnerability and the DMCA
I have copyrighted works protected with PGP. I did not consent to the TPM=
=20
I use being circumvented. Bruce's description of this vulnerability is=20
clearly a circumvention technology that will be used to pirate my work and=
=20
is thereby illegal under the DMCA.
I'm going to file a lawsuit against Bruce and Slashdot and anyone who links=
=20
to Slashdot and anyone who reads the article and anyone who points at or=20
otherwise refers to a person who reads the article. In fact, Bruce himself=
=20
is circumvention technology, so I'm suing his parents, too, along with the=
=20
major airlines, both of which have distributed Bruce.
From: Aleph One <aleph1@underground.org>
Subject: Firewalls and tunnelling protocols
Firewalls were never meant to stop covert channels.
While it's all too true that current firewalls performs a rather lacking=20
job at verifying that a protocol they are forwarding meets its=20
specification, and you could certainly be creative and attempt to find ways=
=20
to detect and stop covert channels, as long as the firewalls allows some=20
traffic through, any traffic, a covert channel will be possible.
So the real problems are in your expectation of a firewalls capabilities,=20
something all too common, and in vendors exploiting overly generic and=20
complex protocols to bypass what they see as nothing more that an annoyance=
=20
to the ease of use and deployment of their application.
From: "Scott Tousley" <stousley@genuity.net>
Subject: SANS
I think you let SANS wriggle off the hook in your article from two weeks=20
ago, and I think their fingerprints from the MSNBC article runs the same=20
direction. While I'm not convinced that Genuity, UUNet, AT&T, C&W, Sprint,=
=20
PSINet and others are doing all that our business motivation demand, I also=
=20
do not think that the answer is found in a loose confederation of SANS,=20
CERT CC, OMB/FEDCIRC, and WH/NSC/CIAO staff designing private-sector=20
requirements. SANS now and CERT CC in the past have contributed to some=20
good work for network security, but I do not think this means they should=20
take an operational role and drive the private sector on behalf of the=20
government. The SANS stumbling over the Microsoft problem is a reflection=
=20
of this inappropriate role.
From: "Gary Hinson" <gary.hinson@cccl.net>
Subject: SANS
I completely agree with your editorial about the SANS news flash thing. It=
=20
has done their credibility no good at all, which is such a shame because=20
(until then) I had been very impressed with the SANS services and their=20
(usually) tempered tone. It seems quite out of character, in fact I=20
wondered if someone had hacked the SANS emailer and sent out a spoof! The=
=20
'virus to catch a virus' was really over the top!
From: "Mikolaj J. Habryn" <dichro-mail-2d77bd17@rcpt.to>
Subject: Bluetooth
If you visit www.bluetooth.com, you will find that the full specifications=
=20
(1400 pages long and amusingly captioned 'Wireless Connections Made Easy')=
=20
are available and include information on link encryption and key generation=
=20
and exchange mechanisms.
The specifications do explicitly leave some security issues up to the=20
applications to deal with. If the security of something is terribly=20
important to you, you will need to provide heftier application level=20
security mechanisms than Bluetooth provides, *and* ensure that the hardware=
=20
platform that you are running on has the computational resources required=20
to service the application. Remember that Bluetooth is, to some degree, a=
=20
lowest common denominator.
From: Lasse Leskel=E4 <lasse.leskela@iki.fi>
Subject: a paper on Bluetooth security
There is a paper about Bluetooth security at:
<http://www.hut.fi/~mhermeli/julkaisut/icisc99s.ps.gz>
From: "Reynolds,Martin" <martin.reynolds@gartner.com>
Subj: Bluetooth Security
The Bluetooth security system is well documented in the Bluetooth specs.
Hold tight for this one: it exchanges secret keys using SAFER+. No, this=20
is not my error. They are serious. You are supposed to use sideband=20
information -- a PIN or a serial number -- to enhance the key that you must=
=20
exchange to use SAFER+ in the first place. The only "good" news is that=20
the keys are persistent and the devices only need to do this on first=20
introduction.
In a cellphone (the cellphone guys wrote the spec) there is a smart card to=
=20
help this process along.
Worse, there is no security requirement.
Bottom line: it could be worse but, in most hands, Bluetooth security is=20
going to be a mess.
From: John Savard <jsavard@ecn.ab.ca>
Subject: M-134-A
Take my word for it: the Friedman patent issued last month is definitely=20
the M-134-A, and not the M-229. This is indicated unambiguously in the=20
abstract of the patent, and in the wording of claim 6, but I'll admit it is=
=20
hard even to read the claims.
The diagram on page 1 (shown enlarged on page 2) also makes it clear that=20
the keyboard is connected through the rotors to a lamp-board in=20
conventional Hebern (or Enigma) fashion, but the 5-level signal goes to the=
=20
5 rotors individually.
Starting near the bottom of page 4, the first text page of the patent, we=
read:
"Now, in all cryptographs based upon the use of rotatable cipher wheels of=
=20
the type referred to above, and arranged as indicated, means are embodied=20
within the cryptograph for automatically changing the rotatory portions of
the cipher wheels during the course of enciphering or deciphering a=20
message; these means are always of such a nature as to make these changes=20
of a definite and predetermined character...."
"The basic feature of my invention of this predictable factor and the=20
provision of a mechanism for displacing the cipher wheels in an entirely=20
irregular, aperiodic manner. This is accomplished by means of the=20
wheel-stepping mechanisms shown as at 4, and operated in the present=20
embodiment by individual magnets which are controlled by the single tape=20
transmitter 5..."
(Incidentally, all information in the following is based on openly=20
published sources, including, admittedly, material released in the National=
=20
Archives, and hence may be freely used and disseminated. I have not at any=
=20
time had exposure to any information covered by security restrictions of a=
=20
military or intelligence nature by the government of the United States or=20
any other country.)
The distinguishing feature of the M-134-A is that it took the bits of a=20
paper tape as input, and used that input to control the movement of rotors,=
=20
and these rotors then encrypted a character in the basic fashion of a=20
Hebern machine. This is mentioned explicitly in the patent.
The M-229 and M-228, for different purposes, did exactly the reverse of=20
this. Rotors moved (still with the use of an electrical circuit)=20
conventionally, in the way usually produced by gears, but the rotors were=20
wired to a fixed set of live inputs to produce what were essentially binary=
=20
bits as output.
In the M-228, these bits were XORed with a teleprinter character, and in=20
the M-229 they were used to control rotor movement in an M-134 (the M-134,=
=20
M-134-A, and M-134-T2 were essentially the same machine; the M-134-T1 was=20
the subject of a patent granted on January 28, 1936 (U.S. patent 2,028,772,=
=20
as referenced in a Cryptologia article on Friedman's patents). And, of=20
course, the M-134-C is one U.S. Army designation for the famous ECM Mark=20
II, or SIGABA.
It should be clear, from the quotes given from the patent, why I am=20
definite about this being the M-134, since the patent clearly refers to the=
=20
distinguishing feature of that machine: paper tape as input, a permutation=
=20
of the alphabet as output.
From: Lance Urbas <lurbas@authentica.com>
Subject: Re: Authentica in the Dog House
Authentica recognizes that a Frequently Asked Question (FAQ) on its Web=20
site, which correlated the strength of encryption with the security of our=
=20
products, was misleading. This FAQ has been removed and we thank Mr.=20
Schneier for pointing this out as well as apologize for using his name=20
without his permission. We recognize that no security products are=20
unbreakable and protecting information after it's been delivered to another=
=20
user's computer is not foolproof. However, our goal is not to ensure=20
"absolute" security, but to provide organizations with tools that better=20
manage the risk in sharing digital information.
** *** ***** ******* *********** *************
CRYPTO-GRAM is a free monthly newsletter providing summaries, analyses,=20
insights, and commentaries on computer security and cryptography.
To subscribe, visit <http://www.counterpane.com/crypto-gram.html> or send a=
=20
blank message to crypto-gram-subscribe@chaparraltree.com. To unsubscribe,=
=20
visit <http://www.counterpane.com/unsubform.html>. Back issues are=20
available on <http://www.counterpane.com>.
Please feel free to forward CRYPTO-GRAM to colleagues and friends who will=
=20
find it valuable. Permission is granted to reprint CRYPTO-GRAM, as long as=
=20
it is reprinted in its entirety.
CRYPTO-GRAM is written by Bruce Schneier. Schneier is founder and CTO of=20
Counterpane Internet Security Inc., the author of "Applied Cryptography,"=20
and an inventor of the Blowfish, Twofish, and Yarrow algorithms. He served=
=20
on the board of the International Association for Cryptologic Research,=20
EPIC, and VTW. He is a frequent writer and lecturer on computer security=20
and cryptography.
Counterpane Internet Security, Inc. is a venture-funded company bringing=20
innovative managed security solutions to the enterprise.
<http://www.counterpane.com/>
Copyright (c) 2000 by Counterpane Internet Security, Inc.
------- End of Forwarded Message
|
