CRYPTO-GRAM, September 15, 2000

[InfoSec News <isn () C4I ORG>]

Forwarded By: Bruce Schneier <schneier () counterpane 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
commentaries on computer security and cryptography.

Back issues are available at <http://www.counterpane.com>.  
To subscribe or 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, new vulnerabilities, new products.  But this season has
also given us a crop of stories about computer security philosophy.  
There has been a resurgence in opposition to the full disclosure
movement: the theory that states that publishing vulnerabilities is
the best way to fix them.  In response, defenders of the movement have
published their rebuttals.  And even more experts have weighed in with
opinions on the DeCSS case, where a New York judge ruled that
distributing an attack tool is illegal.

What's interesting is that everybody wants the same thing; they're
just disagreeing about the best way to get there.

When a security vulnerability exists in a product, it creates what I
call a window of exposure.  This window exists until the vulnerability
is patched, and that patch is installed.  The shape of this window
depends on how many people can exploit this vulnerability, and how
fast it is patched.  What everyone wants is to make this window as
small as possible.

A window of exposure has five distinct phases.  Phase 1 is before the
vulnerability is discovered.  The vulnerability exists, but no one can
exploit it.  Phase 2 is after the vulnerability is discovered, but
before it is announced.  At that point only a few people know about
the vulnerability, but no one knows to defend against it.  Depending
on who knows what, this could either be an enormous risk or no risk at
all.  During this phase, news about the vulnerability spreads --
either slowly, quickly, or not at all -- depending on who discovered
the vulnerability.  Of course, multiple people can make the same
discovery at different times, so this can get very complicated.

Phase 3 is after the vulnerability is announced.  Maybe the
announcement is made by the person who discovered the vulnerability in
Phase 2, or maybe it is made by someone else who independently
discovered the vulnerability later.  At that point more people learn
about the vulnerability, and the risk increases.  In Phase 4, an
automatic attack tool to exploit the vulnerability is published.  Now
the number of people who can exploit the vulnerability grows
exponentially.  Finally, the vendor issues a patch that closes the
vulnerability, starting Phase 5.  As people install the patch and
re-secure their systems, the risk of exploit shrinks.  Some people
never install the patch, so there is always some risk.  But it decays
over time as systems are naturally upgraded.

In some instances the phases are long, and sometimes they're short.  
Sometimes Phase 5 happens so fast that Phases 3 and 4 never occur.  
Sometimes Phase 5 never occurs, either because the vendor doesn't 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 of exposure -- the area under the curve -- as much as possible.  
There are two basic approaches to this.

The first is to reduce the window in the space dimension by limiting
the amount of vulnerability information available to the public.  The
idea is that the less attackers know about attack methodologies, and
the harder it is for them to get their hands on attack tools, the
safer networks become.  The extreme position in this camp holds that
attack tools should be made illegal.

This might work in theory, but unfortunately it is impossible to
enforce in practice.  There is a continuous stream of research in
security vulnerabilities, and most of this research results in public
announcements.  Hackers write new attack exploits all the time, and
the exploits quickly end up in the hands of malicious attackers.  Any
one country could make some of these actions illegal, but it would
make little difference on the international Internet.  There have been
some isolated incidences of a researcher deliberately not publishing a
vulnerability he discovered, but public dissemination of vulnerability
information is the norm...because it is the best way to improve
security.

The second approach is to reduce the window of exposure in time.  
Since a window remains open until the vendor patches the vulnerability
and the network administrator installs the patches, the faster the
vendor can issue the patch the faster the window starts closing.  To
spur the vendors to patch faster, full-disclosure proponents publish
vulnerabilities far and wide.  Ideally, the vendor will distribute the
patch before any automatic 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 instances of security-conscious vendors publishing patches in a
timely fashion.  But there are just as many examples of security
vendors ignoring problems, and of network administrators not bothering
to install existing patches.  A series of credit card thefts in early
2000 was facilitated by a vulnerability in Microsoft IIS that was
discovered, and a patch released for, a year and a half earlier.

The problem is that for the most part, the size and shape of the
window of exposure is not under the control of any central authority.  
Not publishing a vulnerability is no guarantee that someone else won't
publish it.  Publishing a vulnerability is no guarantee that someone
else won't write an exploit tool, and no guarantee that the vendor
will fix it.  Releasing a patch is no guarantee that a network
administrator will actually install it.  Trying to impose rules on
such a chaotic system just doesn't work.

And to make matters worse, it's never one single vulnerability.  
There are dozens and hundreds of vulnerabilities, all with overlapping
windows.  One vulnerability might be shrinking while another ten are
growing.  We're like the little Dutch boy, plugging leaks in the dike
with our fingers while others spring up nearby.  It doesn't matter if
we believe that full disclosure is the best way to reduce the window's
size or if quietly alerting the vendor does better...we're going to
lose the war fighting it either way.

Vulnerabilities are inevitable.  As our networks get more complex and
more pervasive, the vulnerabilities will become more frequent, not
less.  We're already seeing this; every year brings more security
holes than the previous one.  The only way to close the window of
exposure is to make it not matter.  And the only way to do that is to
build security systems that are resilient to vulnerabilities.

In _Secrets and Lies_, I talk about security processes that make
systems resilient to vulnerabilities.  The most relevant one to this
debate is detection and response.  Most computer-security products are
sold as prophylactics: firewalls prevent network intrusions, PKI
prevents impersonation, encryption prevents eavesdropping, etc.  The
problem with this model is that the product can either succeed or
fail: either the window of exposure is closed or it is open.  Good
security includes not only protection, but also detection and
response.  An Internet alarm system that detects attacks in progress,
regardless of the vulnerability that was exploited, has the ability to
close the window of exposure completely.

The key to Internet detection and response is vigilance.  Attacks can
happen at all times of the day and night, and any day of the year.  
New attack tools appear all the time; new vulnerabilities become
public all the time.  I built Counterpane Internet Security, Inc. as a
managed security monitoring company because I saw this as the only way
to bring security to computer networks.  Without outsourced detection
and monitoring, we're at the mercy of all the hackers and product
vendors and security professionals.

Those advocating secrecy are right that full disclosure causes damage,
in some cases more damage than good.  They are also right that those
who build attack tools should be held liable for their actions; the
defense of "I just built the bomb; I didn't place it or set the fuse"
rings hollow.  But they are wrong to think they can enforce secrecy.  
Information naturally disseminates, and strategies that go against
that are doomed.  Those advocating full disclosure are right that
rapid dissemination of the information benefits everyone, even though
some people make ill use of that information.  We would be in a much
worse position today if vulnerability information were only in the
hands of a privileged few.

Neither full disclosure nor secrecy "solve" computer security; the
debate has no solution because there is no one solution.  Both sides
are missing the point.  The real issue, how to close the window of
exposure, is more subtle.  We have to stop thinking of software
security as an end state, that fixing the bugs will somehow make the
software perfect.  Security vulnerabilities are inevitable and there
will always be a window of exposure; smart security solutions will
work regardless.

Marcus Ranum started this debate at BlackHat.  A transcript of his talk 
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 
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 into a bookstore and buy it.  Last month, when I announced the
book, it was printed and in the Wiley warehouse but not in bookstores.

Initial feedback has been great.  There are already reviews on the
Amazon.com Web site.  The Economist published a review of the book, as
did Business Week, Industry Standard, New Scientist, and Salon.  
Other reviews 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 
include San Francisco, San Jose, Seattle, Portland, New York, Boston, and 
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 
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 
security risks, a bank shares its experiences of having its systems 
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 
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 
reading.
<http://www.2600.com/news/2000/0821.html>

Now that CSS is broken, the DVD manufacturers have another dumb idea: 
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 
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=zdhpnew 
s01>

Two good articles on encryption algorithms, the first on DES and the second 
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 
denial-of-service attacks.  One survey found over 100,000 computers still 
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 
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 
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 
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=st.ne.1002.tgif.ni>

Password crackers:  This site lists all sorts of password crackers
that run dictionary attacks against a variety of encryption products.  
My own Password Safe is on the list; there's a password cracker for
that, too.  The moral is not to choose a guessable password, and that
more and 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 someone because he's a reformed (but once convicted) hacker.  I
understand the reluctance to hire criminals, but it seems hypocritical
to make a hiring decision based on whether someone was caught hacking
ten years ago 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 
criminals.  According to the company: "It is armed with a pistol that can 
be programmed to shoot automatically or wait for a fire order delivered 
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 
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 
about cookies, not web bugs.  It's sort of like they missed the point 
completely.
<http://www.microsoft.com/technet/security/cookie.asp>

RSA Inc. executes a clever publicity move.  Many events and parties are 
planned to commemorate the expiration of the RSA algorithm patent on 20 
September 2000.  So what does RSA Inc. do?  They put the algorithm in the 
public domain two weeks early and pre-empt the publicity.  Meaningless, but 
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, 
98, NT, and 2000.  The really odd piece of this story is that Microsoft 
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 
which of their content protection schemes are better.  I've already written 
about why hacking contests make no sense, and don't do anything to show 
which scheme is better.  I've also already written about why the whole 
concept of content protection is flawed, and that it doesn't matter how 
good the scheme is.
<http://www.hacksdmi.org/>

Self-propagating security patch...in rabbits!
<http://www.newscientist.com/news/news.jsp?id=ns225354>

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 
of encryption algorithms public:
<http://www.etsi.org/dvbandca/>

A just-released GAO report gives the government bad marks when it comes to 
security.  Collectively, the agencies averaged D-, with more than a quarter 
of them flunking, and only two out of twenty-four agencies getting better 
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 
4 October.
<http://www.aliconferences.com/conferences/bsecurity_oct2k.htm>


** *** ***** ******* *********** *************

             Carnivore Disinformation



This bit, from Newsweek's Periscope, sounds very much like government 
propaganda:

Tracking bin Laden's E-Mail

American counter-terrorism experts are aghast that the FBI has gone
public with Carnivore, its new Internet-wiretap system.  The reason
for their dismay: Osama bin Laden uses e-mail to communicate with his
terrorist network.  The intelligence community's ability to track his
messages has been, according to one intelligence source, "the biggest
single factor in shutting down several planned operations," including
some in the United States.  "Bin Laden thought his communications were
secure," says the source.  "They weren't.  Now we've told him."

FBI officials acknowledge that Carnivore has been used about 25 times,
primarily in terrorism investigations.  But they decline to comment on
its use against bin Laden.  "Everyone knows we can wiretap phones,"
says a bureau spokesman.  "There's no reason why an ability to
intercept e-mails 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 is that the FBI be able to record all passwords, copy all
sent email, and divert sent email for administrative decisions on
whether it should be delivered."

If it is true, it is the most intrusive power grab we've seen so far.  
Would there even be warning notices on the kiosks?  Would they demand
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
decrypt emails.  They don't say what happens if someone else steals
your 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
vulnerability, an attacker can create a modified version of someone's
public key that will force a sender to encrypt messages to that person
AND to the attacker.

Let me explain.

Starting with PGP version 5.5, the software supported something called
an Additional Decryption Key (ADK).  Normally, when a PGP user creates
a PGP certificate, it contains a single public key (as well as
identifying information as to who the key belongs to).  PGP version
5.5 and 6.x allow the user to add additional ADKs to the certificate.  
When a sender encrypts a message to that user, PGP will automatically
encrypt the message in both the user's public key and the ADK.  The
idea is that the ADK belongs to the secret police, or the user's
employer, or some organization, and that organization can intercept
the encrypted message and read it.

(On Slashdot I said that Network Associates did this when they joined
the Key Recovery Alliance, but PGP Inc. added the feature before then.  
They needed it to get certain corporate contracts.)

The flaw is that some version of PGP don't require the ADKs to be in
the signed portion of the PGP certificate.  What this means is that an
organization can take a PGP certificate, append his ADK, and spread it
out to the world.  This tampered version of the certificate will
remain unnoticed by anyone who doesn't manually examine the bytes, and
anyone using that tampered version will automatically and invisibly
encrypt all messages to the organization as well as the certificate
owner.

Colleague Greg Guerin likened the lesson of this vulnerability to
something he learned in kindergarten: "Don't put something in your
mouth unless you know where it's been."

The reaction from Network Associates has been pretty good: they fixed
the problem.  Unfortunately, the president of the PGP Security unit
demonstrated a high degree of cluelessness when he said: "This a
fairly esoteric attack.  It's not likely that anybody without
specialized knowledge could use it."  Certainly it is an esoteric
attack but, as we all know, that person with specialized knowledge
could easily encapsulate the 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
vulnerability.  Network Associates inspected all 1.2 million PGP keys
on 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 escrow would make system design harder, and would result in even
more 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 I use being circumvented.  Bruce's description of this
vulnerability is clearly a circumvention technology that will be used
to pirate my work and is thereby illegal under the DMCA.

I'm going to file a lawsuit against Bruce and Slashdot and anyone who
links to Slashdot and anyone who reads the article and anyone who
points at or otherwise refers to a person who reads the article.  In
fact, Bruce himself is circumvention technology, so I'm suing his
parents, too, along with the 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 job at verifying that a protocol they are forwarding meets its
specification, and you could certainly be creative and attempt to find
ways to detect and stop covert channels, as long as the firewalls
allows some traffic through, any traffic, a covert channel will be
possible.

So the real problems are in your expectation of a firewalls
capabilities, something all too common, and in vendors exploiting
overly generic and complex protocols to bypass what they see as
nothing more that an annoyance 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 ago, and I think their fingerprints from the MSNBC article runs
the same direction.  While I'm not convinced that Genuity, UUNet,
AT&T, C&W, Sprint, PSINet and others are doing all that our business
motivation demand, I also do not think that the answer is found in a
loose confederation of SANS, CERT CC, OMB/FEDCIRC, and WH/NSC/CIAO
staff designing private-sector requirements.  SANS now and CERT CC in
the past have contributed to some good work for network security, but
I do not think this means they should take an operational role and
drive the private sector on behalf of the government.  The SANS
stumbling over the Microsoft problem is a reflection 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 has done their credibility no good at all, which is such a
shame because (until then) I had been very impressed with the SANS
services and their (usually) tempered tone.  It seems quite out of
character, in fact I wondered if someone had hacked the SANS emailer
and sent out a spoof!  The '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 (1400 pages long and amusingly captioned 'Wireless
Connections Made Easy')  are available and include information on link
encryption and key generation and exchange mechanisms.

The specifications do explicitly leave some security issues up to the
applications to deal with.  If the security of something is terribly
important to you, you will need to provide heftier application level
security mechanisms than Bluetooth provides, *and* ensure that the
hardware platform that you are running on has the computational
resources required to service the application.  Remember that
Bluetooth is, to some degree, a lowest common denominator.


From: Lasse Leskel? <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 is not my error.  They are serious.  You are supposed to use
sideband information -- a PIN or a serial number -- to enhance the key
that you must exchange to use SAFER+ in the first place.  The only
"good" news is that the keys are persistent and the devices only need
to do this on first introduction.

In a cellphone (the cellphone guys wrote the spec) there is a smart
card to help this process along.

Worse, there is no security requirement.

Bottom line: it could be worse but, in most hands, Bluetooth security
is 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 the M-134-A, and not the M-229.  This is indicated
unambiguously in the abstract of the patent, and in the wording of
claim 6, but I'll admit it is hard even to read the claims.

The diagram on page 1 (shown enlarged on page 2) also makes it clear
that the keyboard is connected through the rotors to a lamp-board in
conventional Hebern (or Enigma) fashion, but the 5-level signal goes
to the 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 the type referred to above, and arranged as indicated, means
are embodied within the cryptograph for automatically changing the
rotatory portions of the cipher wheels during the course of
enciphering or deciphering a message; these means are always of such a
nature as to make these changes of a definite and predetermined
character...."

"The basic feature of my invention of this predictable factor and the
provision of a mechanism for displacing the cipher wheels in an
entirely irregular, aperiodic manner.  This is accomplished by means
of the wheel-stepping mechanisms shown as at 4, and operated in the
present embodiment by individual magnets which are controlled by the
single tape transmitter 5..."

(Incidentally, all information in the following is based on openly
published sources, including, admittedly, material released in the
National Archives, and hence may be freely used and disseminated.  I
have not at any time had exposure to any information covered by
security restrictions of a military or intelligence nature by the
government of the United States or any other country.)

The distinguishing feature of the M-134-A is that it took the bits of
a paper tape as input, and used that input to control the movement of
rotors, and these rotors then encrypted a character in the basic
fashion of a Hebern machine.  This is mentioned explicitly in the
patent.

The M-229 and M-228, for different purposes, did exactly the reverse
of this.  Rotors moved (still with the use of an electrical circuit)  
conventionally, in the way usually produced by gears, but the rotors
were wired to a fixed set of live inputs to produce what were
essentially binary bits as output.

In the M-228, these bits were XORed with a teleprinter character, and
in the M-229 they were used to control rotor movement in an M-134 (the
M-134, M-134-A, and M-134-T2 were essentially the same machine; the
M-134-T1 was the subject of a patent granted on January 28, 1936 (U.S.
patent 2,028,772, as referenced in a Cryptologia article on Friedman's
patents).  And, of course, the M-134-C is one U.S. Army designation
for the famous ECM Mark II, or SIGABA.

It should be clear, from the quotes given from the patent, why I am
definite about this being the M-134, since the patent clearly refers
to the distinguishing feature of that machine: paper tape as input, a
permutation 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 site, which correlated the strength of encryption with the
security of our products, was misleading.  This FAQ has been removed
and we thank Mr.  Schneier for pointing this out as well as apologize
for using his name without his permission.  We recognize that no
security products are unbreakable and protecting information after
it's been delivered to another user's computer is not foolproof.  
However, our goal is not to ensure "absolute" security, but to provide
organizations with tools that better manage the risk in sharing
digital information.


** *** ***** ******* *********** *************

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 crypto-gram-subscribe () chaparraltree com.  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) 2000 by Counterpane Internet Security, Inc.

ISN is hosted by SecurityFocus.com
---
To unsubscribe email LISTSERV () SecurityFocus com with a message body of
"SIGNOFF ISN".