| Bruce Schneier on Tue, 16 Nov 1999 20:29:32 +0100 (CET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| <nettime> CRYPTO-GRAM, November 15, 1999 |
November 15, 1999
by Bruce Schneier
Founder and CTO
Counterpane Internet Security, Inc.
[email protected]
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) 1999 by Bruce Schneier
Crypto-Gram now has over 25,000 readers!
** *** ***** ******* *********** *************
In this issue:
Why Computers are Insecure
Counterpane -- Featured Research
News
DVD Encryption Broken
The Doghouse: Microsoft Windows CE
U.S. Legislation Update
Elliptic Curve Public-Key Cryptography
Comments from Readers
** *** ***** ******* *********** *************
Why Computers are Insecure
Almost every week the computer press covers another security flaw: a
virus that exploits Microsoft Office, a vulnerability in Windows or UNIX,
a Java problem, a security hole in a major Web site, an attack against a
popular firewall. Why can't vendors get this right, we wonder? When will
it get better?
I don't believe it ever will. Here's why:
Security engineering is different from any other type of engineering.
Most products, such as word processors or cellular phones, are useful for
what they do. Security products, or security features within products,
are useful precisely because of what they don't allow to be done. Most
engineering involves making things work. Think of the original definition
of a hacker: someone who figured things out and made something cool
happen. Security engineering involves making things not happen. It
involves figuring out how things fail, and then preventing those failures.
In many ways this is similar to safety engineering. Safety is another
engineering requirement that isn't simply a "feature." But safety
engineering involves making sure things do not fail in the presence of
random faults: it's about programming Murphy's computer, if you will.
Security engineering involves making sure things do not fail in the
presence of an intelligent and malicious adversary who forces faults at
precisely the worst time and in precisely the worst way. Security
engineering involves programming Satan's computer.
And Satan's computer is hard to test.
Virtually all software is developed using a "try-and-fix" methodology.
Small pieces are implemented, tested, fixed, and tested again. Several of
these small pieces are combined into a module, and this module is then
tested, fixed, and tested again. Small modules are then combined into
larger modules, and so on. The end result is software that more or less
functions as expected, although in complex systems bugs always slip
through.
This try-and-fix methodology just doesn't work for testing security. No
amount of functional testing can ever uncover a security flaw, so the
testing process won't catch anything. Remember that security has nothing
to do with functionality. If you have an encrypted phone, you can test
it.
You can make and receive calls. You can try, and fail, to eavesdrop.
But you have no idea if the phone is secure or not.
The only reasonable way to "test" security is to perform security reviews.
This is an expensive, time-consuming, manual process. It's not enough to
look at the security protocols and the encryption algorithms. A review
must cover specification, design, implementation, source code, operations,
and so forth. And just as functional testing cannot prove the absence of
bugs, a security review cannot show that the product is in fact secure.
It gets worse. A security review of version 1.0 says little about the
security of version 1.1. A security review of a software product in
isolation does not necessarily apply to the same product in an operational
environment. And the more complex the system is, the harder a security
evaluation becomes and the more security bugs there will be.
Suppose a software product is developed without any functional testing at
all. No alpha or beta testing. Write the code, compile it, and ship.
The odds of this program working at all -- let alone being bug-free -- are
zero. As the complexity of the product increases, so will the number of
bugs. Everyone knows testing is essential.
Unfortunately, this is the current state of practice in security.
Products are being shipped without any, or with minimal, security testing.
I am not surprised that security bugs show up again and again. I can't
believe anyone expects otherwise.
Even worse, products are getting more complex every year: larger
operating systems, more features, more interactions between different
programs on the Internet. Windows NT has been around for a few years, and
security bugs are still being discovered. Expect many times more bugs in
Windows 2000; the code is significantly larger. Expect the same thing to
hold true for every other piece of software.
This won't change. Computer usage, the Internet, convergence, are all
happening at an ever-increasing pace. Systems are getting more complex,
and necessarily more insecure, faster than we can fix them -- and faster
than we can learn how to fix them.
Acknowledgements: The phrase "programming Satan's computer" was
originally Ross Anderson's. It's just too good not to use, though. A
shortened version of this essay originally appeared in the November 15
issue of _Computerworld_.
** *** ***** ******* *********** *************
Counterpane -- Featured Research
"Authenticating Secure Tokens Using Slow Memory Access"
John Kelsey and Bruce Schneier, First USENIX Symposium on Smart Cards,
USENIX Press, to appear.
We present an authentication protocol that allows a token, such as a smart
card, to authenticate itself to a back-end trusted computer system through
an untrusted reader. This protocol relies on the fact that the token will
only respond to queries slowly, and that the token owner will not sit
patiently while the reader seems not to be working. This protocol can be
used alone, with "dumb" memory tokens, or with processor-based tokens.
http://www.counterpane.com/slow-memory.html
** *** ***** ******* *********** *************
News
A company has developed an e-mail encryption package that allows the
sender to choose how long the decryption key will be available, making all
copies of the encrypted e-mail unreadable after a chosen date. This is a
good system to prevent people from accidentally forgetting to delete their
e-mail (in light of the Microsoft trial, many companies have policies of
deleting all e-mail older than a certain time.) It does no good, however,
as a security measure to *prevent* someone from saving e-mail past that
date. Someone can always save the decrypted e-mail to a file, embed the
e-mail in an outgoing e-mail without the restriction, or even do a screen
capture and save a copy of the e-mail that way. This might be a good
product, but don't fool yourself into thinking it acts as a security
measure.
http://www.technologypost.com/internet/DAILY/19991011102015158.asp?Section=Main
Language as cryptography. These stories talk about a secret language used
in China. The second story mentions that the Imperial Chinese punishment
for inventing a secret language was death.
http://www.smh.com.au:80/news/9910/12/text/world5.html
http://www.foxnews.com/scitech/101899/chinese_lingo.sml
Arjen Lenstra and Eric Verheul have written an excellent paper on key
lengths: symmetric, public key (including elliptic curve), etc. They
compare key lengths from different systems, and make predictions about the
future. Download this. http://www.cryptosavvy.com
The Los Angeles Police Department has been accused of conducting hundreds
of illegal wiretaps over the course of several years. Keep this story
handy the next time someone tells you that police wiretaps are a good
thing, and of course the police can be trusted.
http://www.zdnet.com/zdnn/stories/news/0,4586,2378149,00.html?chkpt=hpqsnewst
Snake-oil alert: Jaws Technologies is taking advantage of a window of
opportunity for acquisitions.
http://www.nationalpost.com/network.asp?f=991103/117402
Bad ideas department: The Internet Engineering Task Force (IETF) was
considering building wiretapping capabilities into future incarnations of
the Internet. Anyone who has any voice should stand up at the IETF
meetings in opposition to this.
http://www.wired.com/news/print/1,1294,31895,00.html
Congressman Bob Barr speaks out against this idea.
http://www.wired.com/news/print/1,1294,32100,00.html
Common sense prevailed, and at the recent IETF meeting in D.C., they
decided not to do this.
http://www.wired.com/news/politics/0,1283,32455,00.html
A company called SecureLogix is building a firewall for PBXs. Now that's
a good idea: http://www.securelogix.com
The Clinton administration is looking into relaxing export controls of
cryptographic source code.
http://www.wired.com/news/print/1,1294,32006,00.html
http://www.computerworld.com/home/news.nsf/all/9910225source
The Gartner Group analysts are making a lot of noise about Y2K viruses.
http://www.computerworld.com/home/news.nsf/all/9910122gartner2 And the FBI
says it has collected 30,000 Y2K-related virus threats. While this feels
a bit like McCarthy's list of 500 known Communists, it makes sense to be
extra careful about opening e-mail attachments and downloading new
software around the new year.
http://www.zdnet.com/zdnn/stories/news/0,4586,2386686,00.html?chkpt=zdnnstop
Microsoft has responded by offering free anti-virus software, apparently
forgetting that software downloaded today won't help against viruses that
don't make themselves known until the new year.
http://www.computerworld.com/home/news.nsf/all/9911011msy2k
http://www.infoworld.com/cgi-bin/displayStory.pl?99111.hnmsy2k.htm
The National Security Agency will now assess network security for defense
and civilian agencies. They will even try to break into agencies' systems
to point out vulnerabilities.
http://www.fcw.com/pubs/fcw/1999/1101/fcw-agnsa-11-01-99.html
Excellent interview with Ross Anderson from the New Scientist magazine:
http://www.newscientist.com/ns/19991106/confidenti.html
TEMPEST is the NSA code name for the ability to eavesdrop on electronic
equipment by intercepting and decoding their electromagnetic signals. An
archivist intends to publish on his Web site documents, obtained from the
NSA via the Freedom of Information Act, which provide more details.
http://www.wired.com/news/print/0,1294,32097,00.html See also:
http://www.newscientist.com/ns/19991106/newsstory6.html
Information about Echelon slowly leaks out:
http://www.wired.com/news/print/0,1294,32302,00.html
http://washingtonpost.com/wp-srv/WPcap/1999-11/14/019r-111499-idx.html
http://www.independent.co.uk/news/Digital/Features/spies151199.shtml
The inevitable has finally happened. Someone invented an e-mail virus
that can infect your system when you read the e-mail; you don't have to
execute anything. The Bubbleboy virus requires a user to be running
Microsoft's Outlook or Outlook Express e-mail programs; Windows 95, 98, or
2000; and Internet Explorer 5.0 or higher. It targets a security hole for
which Microsoft has already created a fix, but which many users still have
yet to update. http://www.wired.com/news/story/0,1240,32434,00.html
http://www.wired.com/news/technology/0,1282,32529,00.html The Microsoft
patch: http://www.microsoft.com/security/Bulletins/ms99-032.asp
My commentary in Communications of the ACM on the future of malicious
software: http://www.counterpane.com/insiderisks2.html
** *** ***** ******* *********** *************
DVD Encryption Broken
The scheme to protect DVDs has been broken. There are now freeware
programs on the net that remove the copy protection on DVDs, allowing them
to be played, edited, and copied without restriction.
This should be no surprise to anyone, least of all to the entertainment
industry.
The protection scheme is seriously flawed in several ways. Each DVD is
encrypted with something called Content Scrambling System (CCS). It has a
40-bit key. (I have no idea why. The NSA and the FBI shouldn't care
about DVD encryption. There aren't any encrypted terrorist movies they
need to watch.) It's not even a very good algorithm. But even if the
encryption were triple-DES, this scheme would be flawed.
Every DVD player, including hardware consoles that plug into your
television and software players that you can download to your computer,
has its own unique unlock key. (Actually, each has several. I don't know
why.) This key is used to unlock the decryption key on each DVD. A DVD
has 400 copies of the same unique decryption key, each encrypted with
every unlock code. Note the global secret: if you manage to get one
unlock key for one player, you can decrypt every DVD.
But even if this were all perfect, the scheme could never work.
The flaw is in the security model. The software player eventually gets
the decryption key, decrypts the DVD, and displays it on the screen. That
decrypted DVD data is on the computer. It has to be; there's no other way
to display it on the screen. No matter how good the encryption scheme is,
the DVD data is available in plaintext to anyone who can write a computer
program to take it.
And so is the decryption key. The computer has to decrypt the DVD. The
decryption key has to be in the computer. So the decryption key is
available, in the clear, to anyone who knows where to look. It's
protected by an unlock key, but the reader has to unlock it.
The DVD software manufacturers were supposed to disguise the decryption
program, and possibly the playing program, using some sort of software
obfuscation techniques. These techniques have never worked for very long;
they only seem to force hackers to spend a couple of extra weeks figuring
out how the software works. I've written about this previously in
relation to software copy protection; you can't obfuscate software.
It might be a bitter pill for the entertainment industry to swallow, but
software content protection does not work. It cannot work. You can
distribute encrypted content, but in order for it to be read, viewed, or
listened to, it must be turned into plaintext. If it must be turned into
plaintext, the computer must have a copy of the key and the algorithm to
turn it into plaintext. A clever enough hacker with good enough debugging
tools will always be able to reverse-engineer the algorithm, get the key,
or just capture the plaintext after decryption. And he can write a
software program that allows others to do it automatically. This cannot
be stopped.
If you assume secure hardware, the scheme works. (In fact, the industry
wants to extend the system all the way to the monitor, and eventually do
the decryption there.) The attack works because the hacker can run a
debugger and other programming tools. If the decryption device and the
viewing device (it must be both) is inside a tamperproof piece of
hardware, the hacker is stuck. He can't reverse-engineer anything. But
tamperproof hardware is largely a myth, so in reality this would just be
another barrier that someone will eventually overcome. Digital content
protection just doesn't work; ask anyone who tried software copy
protection.
One more lesson and an observation.
The lesson: This is yet another example of an industry meeting in secret
and designing a proprietary encryption algorithm and protocol that ends up
being embarrassingly weak. I never understand why people don't use open,
published, trusted encryption algorithms and protocols. They're always
better.
The observation: The "solution" that the entertainment industry has been
pushing for is to make reverse-engineering illegal. They managed in the
United States: the Digital Millennium Copyright Act includes provisions
to this effect, despite the protests of the scientific and civil rights
communities. (Yes, you can go to jail for possessing a debugger.) They
got a similar law passed in the UK. They're working on the EU. This
"solution" does not work and makes no sense.
First, unless reverse-engineering is illegal everywhere on the planet,
someone will be able to do it somewhere. And one person is all you need;
he can write software that everyone else uses. Second, the
reverse-engineer can -- as in this case -- work anonymously. Laws
wouldn't have helped in this case. And third, laws can't put the cat back
into the bag. Even if you could catch and prosecute the hackers who did
this, it wouldn't affect the hacker tools that have already been, and
continue to be, written.
What the entertainment industry can do, and what they have done in this
case, is use legal threats to slow the spread of these tools. So far the
industry has threatened legal actions against people who have put these
software tools on their Web sites. The result will be that these tools
will exist on hacker Web sites, but will never be in public-domain
software -- Linux, for example.
The fatal flaw is that the entertainment industry is lazy, and is
attempting to find a technological solution to what is a legal problem.
It is illegal to steal copyrights and trademarks, whether it is a DVD
movie, a magazine image, a Ralph Lauren shirt, or a Louis Vitton handbag.
This legal protection still exists, and is still strong. For some reason
the entertainment industry has decided that it has a legal right to the
protection of its technology, and that makes no sense.
Moreover, they are badgering legislatures into passing laws that prop up
this flawed technological protection. In the US and UK (and possibly soon
in the EU), it is illegal to circumvent their technology, even when you
never use it to violate a copyright. It is illegal to engage in
scientific research about the encryption used in these systems. It is
illegal to peek under the hood of this thing you have legally bought. So
not only does this system not work, it creates a black market where there
was none before, while doing no social good in the process.
This DVD break is a good thing. It served no one's interests for the
entertainment industry to put their faith in a bad security system. It is
good research, illustrating how bad the encryption algorithm is and how
poorly thought out the security model is. What is learned here can be
applied to making future systems stronger.
http://www.wired.com/news/technology/0,1282,32263,00.html
http://www.ntk.net/index.cgi?back=archive99/now1029.txt
Summary of the DVD encryption scheme:
http://crypto.gq.nu
Geek stuff:
http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000548.html
http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000589.html
http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000609.html
http://livid.on.openprojects.net/pipermail/livid-dev/1999-October/000671.html
My essay on software copy protection:
http://www.counterpane.com/crypto-gram-9811.html#copy
My comments on the Digital Millennium Copyright Act:
http://www.zdnet.com/pcweek/news/0622/22wipo.html
New Intel software obfuscation techniques that, I predict, will be broken soon:
http://www.intel.com/pressroom/archive/releases/in110999.htm
** *** ***** ******* *********** *************
The Doghouse: Microsoft Windows CE
Microsoft encrypts your Windows NT password when stored on a Windows CE
device. But if you look carefully at their encryption algorithm, they
simply XOR the password with "susageP", Pegasus spelled backwards. Pegasus
is the code name of Windows CE. This is so pathetic it's staggering.
http://www.cegadgets.com/artsusageP.htm
** *** ***** ******* *********** *************
U.S. Legislation Update
Sometimes it feels like nothing ever changes. Bills to relax export
controls on cryptography are crawling through both the House and Senate.
But nothing ever comes to a vote.
In the House, over 250 members of Congress have co-sponsored H.R. 850, the
Security and Freedom through Encryption (SAFE) Act introduced by Rep. Bob
Goodlatte (R-VA) and Rep. Zoe Lofgren (D-CA). The bills allows for the
export of off-the-shelf cryptographic devices (hardware and software) if a
comparable product is available from a foreign company, and bans mandatory
key escrow. On the other hand, it also includes a controversial provision
that creates a new federal crime for using crypto to "further a criminal
act." This bill has been approved by five committees, so you'd think that
would be enough to get the issue decided. However, in two of the
Committees -- the House Intelligence Committee and the House Armed
Services Committee -- the bills were amended to effectively retain export
controls. The House Rules Committee will have to decide which version
will be voted on.
On the Senate side, Commerce Committee chair and presidential candidate
John McCain (R-AZ) reversed his previous positions opposing cryptography
and introduced S. 798, the Promote Reliable On-Line Transactions to
Encourage Commerce and Trade (PROTECT) Act of 1999. The bill allows for
the free export of products that have 64 bits or less. Stronger
encryption can be exported to online merchants, major corporations that
are publicly traded companies, government regulated industries,
subsidiaries or affiliates of United States corporations, and to
governments in NATO, OECD and ASEAN. (Go figure that last one; they want
to sell strong crypto to Vietnam and Burma but not Brazil or Argentina?)
An Encryption Export Advisory Board can recommend relaxing restrictions.
Finally, by January 2002, products that adopt the AES or its equivalent
will be freely exportable. The bill was approved by the Commerce
Committee in June and is now awaiting a vote by the Senate.
More info: http://www.epic.org/privacy/bill_track.html
** *** ***** ******* *********** *************
Elliptic Curve Public-Key Cryptography
In September of this year, nearly 200 people using 740 computers managed
to crack a message encrypted with 97-bit elliptic curve cryptography. The
process took 16,000 MIPS-years of computing, about twice as much as used
by the team that recently cracked a 512-bit RSA encryption key. Certicom,
the company who sponsored this challenge, has offered this result as
evidence that elliptic curve cryptography is stronger than RSA.
Let's take a look at this claim a little more closely.
All public-key algorithms, whether for key exchange, encryption, or
digital signatures, are based on one of two problems: the factoring
problem or the discrete logarithm problem. (There are other algorithms in
academic circles, but they're too unwieldy to use in the real world.) The
security of RSA comes from the difficulty of factoring large numbers.
Strong RSA-based systems use 1024-bit numbers, or even larger.
The security of most other public-key algorithms -- ElGamal, DSA, etc. --
is based on the discrete logarithm problem. The two problems are very
similar, and all of the modern factoring algorithms can be used to
calculate discrete logarithms in the multiplicative group of a finite
field. To a rough approximation, factoring a number of a certain size and
calculating the discrete logarithm of numbers the same size takes the same
amount of work. This means that for a given key size, RSA, ElGamal, DSA,
etc. are approximately equally secure. (This isn't strictly true, but
it's a good enough approximation for this essay.)
All of these algorithms require the use of something called an "algebraic
group." When public-key cryptography was invented, the algorithms were
all implemented in the simplest algebraic group: the numbers modulo n.
For example, RSA encryption is m^e mod n, and a Diffie-Hellman public key
is g^y mod n. As it turns out, any algebraic group will do. Elliptic
curves are simply another algebraic group.
In elliptic curve cryptography, public keys and private keys are defined
as points along a mathematical object called an elliptic curve. (Don't
worry; it doesn't really matter what that means.) Addition is an
operation that combines two points and produces a third point. The
algorithms look the same, but the detailed math is very different.
But if any algebraic group will do, why is anyone bothering with elliptic
curves? It turns out that for discrete-logarithm elliptic curve
algorithms, perhaps we can get by with smaller keys. (This is not true
for RSA, which is why you never see elliptic curve RSA variants).
All of the fastest algorithms for calculating discrete logs -- the number
field sieve and the quadratic sieve -- make use of something called index
calculus and a property of the numbers mod n called smoothness. In the
elliptic curve group, there is no definition of smoothness, and hence in
order to break elliptic curve algorithms you have to use older methods:
Pollard's rho, for example. So we only have to use keys long enough to be
secure against these older, slower, methods. Therefor, our keys can be
shorter.
And they can be significantly shorter. In the wake of the recent break,
Certicom recommends 163-bit keys. Compare this to the recommended key
lengths for conventional discrete-logarithm algorithms, which are at least
1024 bits.
Whether this recommendation makes sense depends on whether the faster
algorithms can ever be made to work with elliptic curves. The question to
ask is: "Is this lack of smoothness a fundamental property of elliptic
curves, or is it a hole in our knowledge about elliptic curves?" Or, more
generally: "Are elliptic curves inherently harder to calculate discrete
logs in, or will we eventually figure out a way to do it as efficiently as
we can in the numbers mod n?"
If you believe the former, elliptic curves will always be more secure --
for the same key lengths -- than the numbers mod n. If you believe the
latter, it's only a matter of time before they are broken.
Certicom very much wants you to believe the former. They say things like:
"Elliptic curves as algebraic/geometric entities have been studied
extensively for the past 150 years, and from these studies has emerged a
rich and deep theory." They conclude that because of this, we can gain
good confidence that new algorithmic advances won't be too devastating.
To me, this is a lot of wishful thinking. It would be nice if we had 150
years of work on the cryptographic properties of elliptic curves. But we
don't; instead, we have 150 years of work on the properties of elliptic
curves that mathematicians care about, almost all of it only incidentally
touching on what cryptographers care about. Elliptic curve cryptography
was invented only in 1985, and has only been really studied seriously for
a few years.
Even today, most of the work on elliptic curves in the typical university
math department is pretty irrelevant to us cryptographers. Sure, some of
their results might occasionally help us understand the strength of
elliptic curve algorithms; but that's almost never been the goal of the
mathematicians' research studies. This is changing now, but slowly.
Furthermore, work on efficient algorithms for elliptic curves is very new.
The whole notion of efficient algorithms didn't even appear until about
the 1960s or 1970s, and algorithmic number theory has only become popular
in the past two decades. It just wasn't relevant before computers.
The real answer to the question is "we don't know." We don't know if
there are efficient ways to calculate discrete logarithms in elliptic
curve groups. We don't know if there is a definition of smoothness that
will allow us to apply the number field sieve to elliptic curves. We
don't know if, in the long run, you can use shorter keys with elliptic
curve algorithms.
In the short run, Certicom's recommendations are reasonable. Today, we
can't calculate discrete logs in elliptic curves as efficiently as we can
in the numbers mod n. Systems can use shorter keys with elliptic curves.
But in the long run, we don't know.
There are other differences to consider, too. Checking elliptic curve
signatures is still a big pain compared to checking RSA signatures. And
all users of an elliptic curve system have to share the same curve. (If
you don't do this, you lose most of the size benefits of the elliptic
curve keys.) This has security implications: it is easier to break a key
of a random user on a system than it is to break a specific user's key.
I'd like to see more analysis of this aspect of elliptic curve systems.
My recommendation is that if you're working in a constrained environment
where longer keys just won't fit -- smart cards, some cellphones or
pagers, etc. -- consider elliptic curves. If the choice is elliptic
curves or no public-key algorithm at all, use elliptic curves. If you
don't have performance constraints, use RSA. If you are concerned about
security over the decades (almost no systems are), use RSA.
Realize, though, that someday -- next year, in ten years, in a century --
someone may figure out how to define smoothness, or something even more
useful, in elliptic curves. If that happens, you will have to use the
same key lengths as you would with conventional discrete logarithm
algorithms, and there will be no reason to ever use elliptic curves.
Postscript: This same analysis applies to factoring, too. RSA Security,
Inc. likes to talk about the long mathematical history of the factoring
problem, and how that gives us confidence about the security of RSA. Yes,
it has been studied for centuries, but only recently has that study been
even remotely related to cryptography. Moreover, working on factoring
hasn't been a respectable area of study until very recently; before that,
it was considered an eccentric hobby. And efficient algorithms for
factoring have only been studied for the past couple of decades. We
really have no idea how hard factoring truly is.
The truth is that companies have a tendency to advertise their products.
Before making a decision about cryptographic algorithms, customers should
try to get a variety of independent opinions (from parties not financially
involved in the outcome of the decision) about what they are buying.
News on the recent elliptic curve cracking effort:
http://www.computerworld.com/home/news.nsf/all/9909282ellip
http://www.certicom.com/press/99/sept2899.htm
An excellent mathematical introduction to elliptic curves:
http://www.certicom.com/ecc/enter/index.htm
An excellent discussion on comparative key lengths, including RSA and
elliptic curves: http://www.cryptosavvy.com
** *** ***** ******* *********** *************
Comments from Readers
Reinhard Wobst <[email protected]>
Subject: The open-source problem
Today during the congress ISSE in Berlin, we had a panel discussion about
the problem "Does open source help to increase security?" Of course, we
spoke about general IT-security, not only about cryptography.
What you wrote in Cryptogram about open source of crypto algorithms is
absolutely right. The example of Crypto AG machines, where the secret key
was enciphered by an NSA key and then probably put into the message
header, is a illustrative example. In contrast to this field, we agreed
that open source of operating systems or applications does not generally
increase security, it only makes the process of bug finding and bug fixing
faster. In commercial environments it is not possible to make patches so
often as security holes are found and closed. Sometimes users note such
problems and write a workaround for their application which would crash
with the next release. Your theory of finding most important errors in
shorter time sounds good. However, people from organizations like
DFN-CERT claim that the chain is endless, and even "unimportant errors"
can easily be used for automated attacks.
So we agreed to say: Open source not necessarily increases security
considerably, but it increases TRUST. And this is -- of course -- very
important for cryptography implementations.
From: Larry Nathanson <[email protected]>
Subject: Re: E*Trade
Dwight Arthur <[email protected]> said:
"I like E*Trade, I trade there. E*Trade has never asked me to agree that
I will be responsible for any trades done with my password, so my opinion
is that they are putting their own assets (not mine) at risk with weak
security."
I would reconsider that stance.
>From E*TRADE Customer Agreement (labeled ET100/0798 on last page): "This
document contains the terms and conditions which govern your E*TRADE
account. Please read it carefully and keep it for your records."
"Customer Agreement", Item 28, paragraph 2 (page 6): You shall be the
only authorized user of the Service under this Agreement. You shall be
responsible for the confidentiality and use of your User ID, sign-on
password, trading password, and PIN. You understand that you shall be
solely responsible for all orders entered through the Service using your
User ID, sign-on password, trading password, and PIN.... You agree that
E*TRADE and its affiliates will not be liable for any losses resulting
from a cause over which E*TRADE or its affiliates does not have direct
control, including but not limited to ... unauthorized access...."
Also online at
https://trading.etrade.com/cgi-bin/gx.cgi/AppLogic+AcctDefault?gxml=etrade_i
nfo/customer_agreement.html -- requires login.
From: "Estes, Danal" <[email protected]>
Subject: AMD's "Magic Packet"
The latest Crypto-Gram contained a reference to AMD's "Magic Packet" that
could power up a PC via the network. Your expression of security concern
is right on target; associating this concern with a single vendor or
technology is not.
This affects anyone that supports Wake-On-Lan on his motherboard/network
card, and not only AMD:
http://www.microsoft.com/hwdev/specs/PMref/PMnetwork.htm#details
For some time now, motherboard manufacturers and Network Interface Card
manufacturers have been supporting a standard known as "Wake on Lan".
This initially required a special cable from the NIC to a two pin header
on the motherboard. In conjunction with the ATX power supply standards
that keep a small portion of the motherboard powered up (thus enabling
"Hit the spacebar to power on", etc.), the NIC could also stay powered up
and send the 'power fully up' signal to the motherboard via this cable...!
I seem to recall seeing a reference to enabling this same idea via the PCI
bus (no special cable required) at some rev level.
IBM, Compaq, Dell, etc. having been touting this technology in
presentations to me for at least two years. So, it's not just AMD, it's a
whole variety of component and finished system manufacturers.
Again, the security concerns are real. The packet format to cause a
"wake" is standardized and well published. You do have to know the
hardware (MAC layer) address of the NIC, but this is easily obtained
anytime the computer is up and communicating. Etc., etc.
Wake on Lan does need some configuration to work; it's generally not the
default behavior of the motherboard/NIC combination. Who's most likely to
enable this? Large companies that have "Enterprise Systems Management"
initiatives. As this standard gains momentum, as it becomes part of
bus(es) instead of special cables, if/when it becomes enabled by
default...
enough said. Keep sounding the alert.
From: Gary Ellison <[email protected]>
Subject: New U.S. Crypto Policy
A few comments on the Clinton Administration's new crypto policy that I
think are worth noting.
First, the new rules do not change anything for so called 'crypto with a
hole'. In other words toolkits, such as the BSafe or Java Cryptographic
Extensions, will still be under the same export restrictions in existence
today. It is also not clear what the fate of hardware cryptographic
accelerators (ASIC or other components) will be. In the case of software
toolkits the NSA will not allow strong crypto to be exported unless the
toolkit is closed (along the lines of CAPI or CDSA). According to the new
policy, "retail" crypto products will go through "one time review". I
presume the NSA review will be a bit more detailed in the future than it
has been in the past. Given that what is to prevent the NSA from claiming
that these so called "retail" products are 'crypto with a hole' and deny
the export license? For example, Eudora may no longer meet the NSA's
export criteria given the architecture of their plugin api.
Another point is that the Clinton Administration's plan addresses about
80% of the SAFE Act and that it is unlikely that there will ever be the
kind of support to remove the restrictions for the missing 20%.
Finally, the Clinton Administration's new rules are not codified in law
and could just as easily be whisked away by this or any subsequent
administration.
Perhaps CESA should be referred to as the Black Bag Job Act of 1999.
From: Greg Weiss <[email protected]>
Subject: Are e-votes more prone to voter coercion?
>With all the talk about electronic voting, it's nice that someone
>recognizes that there are some serious security problems. The most
>severe, at least to me, is voter coercion. ...
I used to agree with you on this. But when talking with someone about
absentee balloting this last week, it seems to me this problem is equally
present in today's non-virtual scenario. How? Well, absentee ballots
enable voter coercion in the privacy of non-public polling places.
E-votes are not particularly more subvertible than absentee ballot votes
at least from the voter coercion threat.
Now with absentee ballots, there is one further protection. One can
apparently still vote in person at the polling place, and their
polling-place vote takes precedence over their absentee ballot. But this
same approach would work for electronic votes, right? People coerced or
bought could still vote at the public polls with that vote taking
precedent. So voter coercion looks like a wash to me, electronic vote or
no.
** *** ***** ******* *********** *************
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 [email protected]. 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) 1999 by Bruce Schneier
# distributed via <nettime>: no commercial use without permission
# <nettime> is a moderated mailing list for net criticism,
# collaborative text filtering and cultural politics of the nets
# more info: [email protected] and "info nettime-l" in the msg body
# archive: http://www.nettime.org contact: [email protected]