CRYPTO-GRAM

                January 15, 2001

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier@counterpane.com
          <https://www.counterpane.com>


A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on computer security and cryptography.

Back issues are available at <https://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:
<https://www.zdnet.com/zdnn/stories/news/0,4586,2667644,00.html>
<https://www.cisecurity.org/>

Underwriters Laboratory history:
<https://www.bergen.com/biz/safe2219970921o1.htm>
<https://www.ul.com/about/otm/otmv2n4/fire.html>

Early discussions of a cyber-UL:
<https://www.l0pht.com/cyberul.html>

Complexity and security:
<https://www.counterpane.com/crypto-gram-0003.html#SoftwareComplexityandSecur 
ity>

A version of this article appeared on ZDNet:
<https://www.zdnet.com/zdnn/stories/comment/0,5859,2669708,00.html>


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

             Crypto-Gram Reprints



Publicity attacks:
<https://www.counterpane.com/crypto-gram-0001.html#KeyFindingAttacksandPublic 
ityAttacks>

Block and stream ciphers:
<https://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.
<https://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.
<https://www.whitehouse.gov/WH/EOP/NSC/html/documents/pub45270/pub45270chap1. 
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.
<https://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?
<https://www.internetnews.com/intra-news/article/0,,7_529661,00.html>

Clever steganography application: turn a message into innocuous spam:
<https://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.
<https://www.mistraldetection.com/seethrough.htm>
<https://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.
<https://cgi.zdnet.com/slink?70609:8469234>
<https://www.theregister.co.uk/content/6/15533.html>
BugTraq fights back:
<https://www.theregister.co.uk/content/4/15491.html>

Good analysis of the European CyberCrime Treaty.  Short summary: it's still 
horrible.
<https://www.securityfocus.com/commentary/124>

Interesting interview on (among other topics) encryption with Eben Moglen, 
general counsel of the Free Software Foundation:
<https://www.immaterial.net/page.php3?id=44>
<https://www.immaterial.net/page.php3?id=45>

Nasty story of what an insider can do to your network:
<https://www.businessweek.com/bwdaily/dnflash/dec2000/nf20001213_253.htm>

Clever things to do with Internet bugs:
<https://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:
<https://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:
<https://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:
<https://www.washingtonpost.com/wp-dyn/articles/A13455-2000Dec15.html>

And a very strange story about a group impersonating the World Trade 
Organization:
<https://www.nytimes.com/2001/01/07/weekinreview/07WORD.html?pagewanted=all>

Along a similar line, a non-computer story about social engineering and 
industrial espionage:
<https://www.nytimes.com/library/magazine/home/20001203mag-penenberg.html>

Ireland is rushing into electronic voting:
<https://www.ireland.com/newspaper/ireland/2000/1218/hom18.htm>

MIT and CalTech announce a voting technology initiative:
<https://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):
<https://www.securityportal.com/cover/coverstory20001218.html>
<https://www.monkey.org/~dugsong/dsniff/>
A rebuttal:
<https://sysadmin.oreilly.com/news/silverman_1200.html>
And a follow-up by the original article's author:
<https://www.securityportal.com/seifried/sslssh-followup20001222.html>

Good information on various security resources on the WWW:
<https://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.
<https://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."
<https://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.
<https://computerworld.com/cwi/story/0,1199,NAV65-663_STO55656_NLTs,00.html>

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.
<https://cryptome.org/nacsim-5000.htm>
<https://cryptome.org/nstissi-7000.htm>
<https://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.
<https://www.webreview.com/pi/2000/12_29_00.shtml>

Excellent ActiveX security document from CERT:
<https://www.cert.org/reports/activeX_report.pdf>

Weird story about an abandoned NSA facility:
<https://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:
<https://www.securityfocus.com/frames/?focus=ids&content=/focus/ids/articles/ 
utf8.html>

The FBI tries to get industry to tell it about security incidents:
<https://washingtonpost.com/wp-dyn/articles/A25955-2001Jan5.html>

New security threats:
<https://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."
<https://www.cybercrime.gov/searchmanual.htm>
<https://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.
<https://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:
<https://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.
<https://www.cyclonecafe3.com/isawards/>

The biometrics article from the August 98 Crypto-Gram has been republished 
on the TechTV Web site:
<https://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.

<https://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:
<https://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.

<https://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.
<https://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.  <https://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. 
<https://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.

<https://cgi.zdnet.com/slink?66540:8469234>
<https://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:
<https://inq.philly.com/content/inquirer/2000/12/04/front_page/JMOB04.htm>
<https://www.wirednews.com/news/politics/0,1283,40541,00.html>
<https://www.theregister.co.uk/content/4/15268.html>
<https://www.usatoday.com/life/cyber/tech/cti881.htm>
<https://slashdot.org/yro/00/12/06/0255234.shtml>

The FBI application to the court is at:
<https://www.epic.org/crypto/breakin/application.pdf>

The resulting court order is at:
<https://www.epic.org/crypto/breakin/order.pdf>

My PGP attack paper:
<https://www.counterpane.com/chotext.html>


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

             Comments from Readers



From: Nicolas.Graner@cri.u-psud.fr
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 <louis@bertrandtech.on.ca>
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 <daniel@atan.com.br>
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: phil@ipal.net (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" <ccrossno@swbell.net>
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, <marks@jural.com>
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: <https://www.ecommerce.gov/ecomnews/ElectronicSignatures_s761.pdf>


From: "Bluefish (P.Magnusson)" <11a@gmx.net>
Subject: Retaliation

 > And the question of retaliation: should you strike back
 > against hackers if the police can't do anything?
 > <https://computerworld.com/cwi/story/0,1199,NAV65-663_STO53869_NLTs,00.html>

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" <Cathy.Penafiel@csoconline.com>
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 <https://www.counterpane.com/crypto-gram.html> or send a 
blank message to crypto-gram-subscribe@chaparraltree.com.  To unsubscribe, 
visit <https://www.counterpane.com/unsubform.html>.  Back issues are 
available on <https://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.

<https://www.counterpane.com/>

Copyright (c) 2001 by Counterpane Internet Security, Inc.