[92736] in Cypherpunks
Bruce Schneier, Sandia, FBI and the REAL WORLD
daemon@ATHENA.MIT.EDU (bill payne)
Thu Jan 8 00:25:32 1998
Date: Wed, 07 Jan 1998 13:05:42 -0700
From: bill payne <billp@nmol.com>
To: cypherpunks@toad.com
Reply-To: bill payne <billp@nmol.com>
This is a multi-part message in MIME format.
--------------5713295A6FBD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Wednesday 1/7/98 12:57 PM
Bruce Schneier wrote
and a burglar willing to try all 10,000 is guaranteed to break
into your house.
This is posted at jya.com.
Sandia employees Jack Hudson and Jack Menako, both in my division
when Sandia transferred me to break electronic locks for the FBI/ERF
[Engineering Research Facility, Quantico, VA], were TRYING to
defeat combination locks on file cabinets.
Menako built a frame to connect a stepper-motor to the combination
dial.
The stepper motor was wried to a PC.
Hudson wrote the software to try all possible combinations.
What happened, IN FACT, was that the combination lock wore-out
before the combination which opened the lock was reached.
Combinations locks are NOT ENGINEERED for such heavy use.
The file safe had to be destroyed to open it!
So Schneier's statement may be incorrect. No guarantee.
Guys, this is the REAL WORLD.
bill
--------------5713295A6FBD
Content-Type: text/html; charset=iso-8859-1; name="pitfalls.html"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline; filename="pitfalls.html"
Content-Base: "http://www.counterpane.com/pitfalls.ht
ml"
<BASE HREF=3D"http://www.counterpane.com/pitfalls.html">
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<title>Security Pitfalls in Cryptography</title>
</head>
<body bgcolor=3D"#E1E1E1" text=3D"#0000A0" stylesrc=3D"index.html">
<H1 ALIGN=3DCENTER>Security Pitfalls in Cryptography</H1>
<P ALIGN=3DCENTER>by <a href=3D"schneier.html">Bruce Schneier</a></P>
<P ALIGN=3DCENTER><font size=3D"-1">Cryptography Consultant<BR>
<a href=3D"http://www.counterpane.com">Counterpane Systems</a><BR>
e-mail: <a href=3D"mailto:schneier@counterpane.com">schneier@counterpane.=
com</a></font></P>
<P>Magazine articles like to describe cryptography products in terms of a=
lgorithms and key length. Algorithms make good sound bites: they can be e=
xplained in a few words and they're easy to compare with one another. &qu=
ot;128-bit keys mean good security." "Triple-DES means good sec=
urity." "40-bit keys mean weak security." "2048-bit R=
SA is better than 1024-bit RSA." </P>
<P>But reality isn't that simple. Longer keys don't always mean more sec=
urity. Compare the cryptographic algorithm to the lock on your front door=
=2E Most door locks have four metal pins, each of which can be in one of =
ten positions. A key sets the pins in a particular configuration. If the =
key aligns them all correctly, then the lock opens. So there are only 10,=
000 possible keys, and a burglar willing to try all 10,000 is guaranteed =
to break into your house. But an improved lock with ten pins, making 10 b=
illion possible keys, probably won't make your house more secure. Burglar=
s don't try every possible key (a brute-force attack); most aren't even c=
lever enough to pick the lock (a cryptographic attack against the algorit=
hm). They smash windows, kick in doors, disguise themselves as policemen,=
or rob keyholders at gunpoint. One ring of art thieves in California def=
eated home security systems by taking a chainsaw to the house walls. Bett=
er locks don't help against these attacks.</P>
<P>Strong cryptography is very powerful when it is done right, but it is =
not a panacea. Focusing on the cryptographic algorithms while ignoring ot=
her aspects of security is like defending your house not by building a fe=
nce around it, but by putting an immense stake into the ground and hoping=
that the adversary runs right into it. Smart attackers will just go arou=
nd the algorithms.</P>
<P>Counterpane Systems has spent years designing, analyzing, and breaking=
cryptographic systems. While we do research on published algorithms and =
protocols, most of our work examines actual products. We've designed and =
analyzed systems that protect privacy, ensure confidentiality, provide fa=
irness, and facilitate commerce. We've worked with software, stand-alone =
hardware, and everything in between. We've broken our share of algorithms=
, but we can almost always find attacks that bypass the algorithms altoge=
ther. We don't have to try every possible key, or even find flaws in the =
algorithms. We exploit errors in design, errors in implementation, and er=
rors in installation. Sometimes we invent a new trick to break a system, =
but most of the time we exploit the same old mistakes that designers make=
over and over again.</P>
<H2>Attacks Against Cryptographic Designs</H2>
<P>A cryptographic system can only be as strong as the encryption algorit=
hms, digital signature algorithms, one-way hash functions, and message au=
thentication codes it relies on. Break any of them, and you've broken the=
system. And just as it's possible to build a weak structure using strong=
materials, it's possible to build a weak cryptographic system using stro=
ng algorithms and protocols.</P>
<P>We often find systems that "void the warranty" of their cryp=
tography by not using it properly: failing to check the size of values, r=
eusing random parameters that should never be reused, and so on. Encrypti=
on algorithms don't necessarily provide data integrity. Key exchange prot=
ocols don't necessarily ensure that both parties receive the same key. In=
a recent research project, we found that some--not all--systems using re=
lated cryptographic keys could be broken, even though each individual key=
was secure. Security is a lot more than plugging in an algorithm and exp=
ecting the system to work. Even good engineers, well-known companies, and=
lots of effort are no guarantee of robust implementation; our work on th=
e U.S. digital cellular encryption algorithm illustrated that.</P>
<P>Random-number generators are another place where cryptographic systems=
often break. Good random-number generators are hard to design, because t=
heir security often depends on the particulars of the hardware and softwa=
re. Many products we examine use bad ones. The cryptography may be strong=
, but if the random-number generator produces weak keys, the system is mu=
ch easier to break. Other products use secure random-number generators, b=
ut they don't use enough randomness to make the cryptography secure.</P>
<P>Recently Counterpane Systems has published new classes of attacks agai=
nst random-number generators, based on our work with commercial designs. =
One of the most surprising things we've found is that specific random-num=
ber generators may be secure for one purpose but insecure for another; ge=
neralizing security analyses is dangerous.</P>
<P>In another research result, we looked at interactions between individu=
ally secure cryptographic protocols. Given a secure protocol, we show how=
to build another secure protocol that will break the first if both are u=
sed with the same keys on the same device.</P>
<H2>Attacks Against Implementations</H2>
<P>Many systems fail because of mistakes in implementation. Some systems =
don't ensure that plaintext is destroyed after it's encrypted. Other syst=
ems use temporary files to protect against data loss during a system cras=
h, or virtual memory to increase the available memory; these features can=
accidentally leave plaintext lying around on the hard drive. In extreme =
cases, the operating system can leave the keys on the hard drive. One pro=
duct we've seen used a special window for password input. The password re=
mained in the window's memory even after it was closed. It didn't matter =
how good that product's cryptography was; it was broken by the user inter=
face. </P>
<P>Other systems fall to more subtle problems. Sometimes the same data is=
encrypted with two different keys, one strong and one weak. Other system=
s use master keys and then one-time session keys. We've broken systems us=
ing partial information about the different keys. We've also seen systems=
that use inadequate protection mechanisms for the master keys, mistakenl=
y relying on the security of the session keys. It's vital to secure all p=
ossible ways to learn a key, not just the most obvious ones.</P>
<P>Electronic commerce systems often make implementation trade-offs to en=
hance usability. We've found subtle vulnerabilities here, when designers =
don't think through the security implications of their trade-offs. Doing =
account reconciliation only once per day might be easier, but what kind o=
f damage can an attacker do in a few hours? Can audit mechanisms be flood=
ed to hide the identity of an attacker? Some systems record compromised k=
eys on "hotlists"; attacks against these hotlists can be very f=
ruitful. Other systems can be broken through replay attacks: reusing old =
messages, or parts of old messages, to fool various parties.</P>
<P>Systems that allow old keys to be recovered in an emergency provide an=
other area to attack. Good cryptographic systems are designed so that the=
keys exist for as short a period of time as possible; key recovery often=
negates any security benefit by forcing keys to exist long after they ar=
e useful. Furthermore, key recovery databases become sources of vulnerabi=
lity in themselves, and have to be designed and implemented securely. In =
one product we evaluated, flaws in the key recovery database allowed crim=
inals to commit fraud and then frame legitimate users.</P>
<H2>Attacks Against Passwords</H2>
<P>Many systems break because they rely on user-generated passwords. Left=
to themselves, people don't choose strong passwords. If they're forced t=
o use strong passwords, they can't remember them. If the password becomes=
a key, it's usually much easier--and faster--to guess the password than =
it is to brute-force the key; we've seen elaborate security systems fail =
in this way. Some user interfaces make the problem even worse: limiting t=
he passwords to eight characters, converting everything to lower case, et=
c. Even passphrases can be weak: searching through 40-character phrases i=
s often much easier than searching through 64-bit random keys. We've also=
seen key-recovery systems that circumvent strong session keys by using w=
eak passwords for key-recovery.</P>
<H2>Attacks Against Hardware</H2>
<P>Some systems, particularly commerce systems, rely on tamper-resistant =
hardware for security: smart cards, electronic wallets, dongles, etc. The=
se systems may assume public terminals never fall into the wrong hands, o=
r that those "wrong hands" lack the expertise and equipment to =
attack the hardware. While hardware security is an important component in=
many secure systems, we distrust systems whose security rests solely on =
assumptions about tamper resistance. We've rarely seen tamper resistance =
techniques that work, and tools for defeating tamper resistance are getti=
ng better all the time. When we design systems that use tamper resistance=
, we always build in complementary security mechanisms just in case the t=
amper resistance fails.</P>
<P>The "timing attack" made a big press splash in 1995: RSA pri=
vate keys could be recovered by measuring the relative times cryptographi=
c operations took. The attack has been successfully implemented against s=
mart cards and other security tokens, and against electronic commerce ser=
vers across the Internet. Counterpane Systems and others have generalized=
these methods to include attacks on a system by measuring power consumpt=
ion, radiation emissions, and other "side channels," and have i=
mplemented them against a variety of public-key and symmetric algorithms =
in "secure" tokens. We've yet to find a smart card that we can'=
t pull the secret keys out of by looking at side channels. Related resear=
ch has looked at fault analysis: deliberately introducing faults into cry=
ptographic processors in order to determine the secret keys. The effects =
of this attack can be devastating.</P>
<H2>Attacks Against Trust Models</H2>
<P>Many of our more interesting attacks are against the underlying trust =
model of the system: who or what in the system is trusted, in what way, a=
nd to what extent. Simple systems, like hard-drive encryption programs or=
telephone privacy products, have simple trust models. Complex systems, l=
ike electronic commerce systems or multi-user e-mail security programs, h=
ave complex (and subtle) trust models. An e-mail program might use uncrac=
kable cryptography for the messages, but unless the keys are certified by=
a trusted source (and unless that certification can be verified), the sy=
stem is still vulnerable. Some commerce systems can be broken by a mercha=
nt and a customer colluding, or by two different customers colluding. Oth=
er systems make implicit assumptions about security infrastructures, but =
don't bother to check that those assumptions are actually true. If the tr=
ust model isn't documented, then an engineer can unknowingly change it in=
product development, and compromise security.</P>
<P>Many software systems make poor trust assumptions about the computers =
they run on; they assume the desktop is secure. These programs can often =
be broken by Trojan horse software that sniffs passwords, reads plaintext=
, or otherwise circumvents security measures. Systems working across comp=
uter networks have to worry about security flaws resulting from the netwo=
rk protocols. Computers that are attached to the Internet can also be vul=
nerable. Again, the cryptography may be irrelevant if it can be circumven=
ted through network insecurity. And no software is secure against reverse=
-engineering.</P>
<P>Often, a system will be designed with one trust model in mind, and imp=
lemented with another. Decisions made in the design process might be comp=
letely ignored when it comes time to sell it to customers. A system that =
is secure when the operators are trusted and the computers are completely=
under the control of the company using the system may not be secure when=
the operators are temps hired at just over minimum wage and the computer=
s are untrusted. Good trust models work even if some of the trust assumpt=
ions turn out to be wrong.</P>
<H2>Attacks on the Users</H2>
<P>Even when a system is secure if used properly, its users can subvert i=
ts security by accident--especially if the system isn't designed very wel=
l. The classic example of this is the user who gives his password to his =
co-workers so they can fix some problem when he's out of the office. User=
s may not report missing smart cards for a few days, in case they are jus=
t misplaced. They may not carefully check the name on a digital certifica=
te. They may reuse their secure passwords on other, insecure systems. The=
y may not change their software's default weak security settings. Good sy=
stem design can't fix all these social problems, but it can help avoid ma=
ny of them.</P>
<H2>Attacks Against Failure Recovery</H2>
<P>Strong systems are designed to keep small security breaks from becomin=
g big ones. Recovering the key to one file should not allow the attacker =
to read every file on the hard drive. A hacker who reverse-engineers a sm=
art card should only learn the secrets in that smart card, not informatio=
n that will help him break other smart cards in the system. In a multi-us=
er system, knowing one person's secrets shouldn't compromise everyone els=
e's.</P>
<P>Many systems have a "default to insecure mode." If the secur=
ity feature doesn't work, most people just turn it off and finish their b=
usiness. If the on-line credit card verification system is down, merchant=
s will default to the less-secure paper system. Similarly, it is sometime=
s possible to mount a "version rollback attack" against a syste=
m after it has been revised to fix a security problem: the need for backw=
ards compatibility allows an attacker to force the protocol into an older=
, insecure, version.</P>
<P>Other systems have no ability to recover from disaster. If the securit=
y breaks, there's no way to fix it. For electronic commerce systems, whic=
h could have millions of users, this can be particularly damaging. Such s=
ystems should plan to respond to attacks, and to upgrade security without=
having to shut the system down. The phrase "and then the company is=
screwed" is never something you want to put in your business plan. =
Good system design considers what will happen when an attack occurs, and =
works out ways to contain the damage and recover from the attack.</P>
<H2>Attacks Against the Cryptography</H2>
<P>Sometimes, products even get the cryptography wrong. Some rely on prop=
rietary encryption algorithms. Invariably, these are very weak. Counterpa=
ne Systems has had considerable success breaking published encryption alg=
orithms; our track record against proprietary ones is even better. Keepin=
g the algorithm secret isn't much of an impediment to analysis, anyway--i=
t only takes a couple of days to reverse-engineer the cryptographic algor=
ithm from executable code. One system we analyzed, the S/MIME 2 electroni=
c-mail standard, took a relatively strong design and implemented it with =
a weak cryptographic algorithm. The system for DVD encryption took a weak=
algorithm and made it weaker.</P>
<P>We've seen many other cryptographic mistakes: implementations that rep=
eat "unique" random values, digital signature algorithms that d=
on't properly verify parameters, hash functions altered to defeat the ver=
y properties they're being used for. We've seen cryptographic protocols u=
sed in ways that were not intended by the protocols' designers, and proto=
cols "optimized" in seemingly trivial ways that completely brea=
k their security.</P>
<H2>Attack Prevention vs. Attack Detection</H2>
<P>Most cryptographic systems rely on prevention as their sole means of d=
efense: the cryptography keeps people from cheating, lying, abusing, or w=
hatever. Defense should never be that narrow. A strong system also tries =
to detect abuse and to contain the effects of any attack. One of our fund=
amental design principles is that sooner or later, every system will be s=
uccessfully attacked, probably in a completely unexpected way and with un=
expected consequences. It is important to be able to detect such an attac=
k, and then to contain the attack to ensure it does minimal damage.</P>
<P>More importantly, once the attack is detected, the system needs to rec=
over: generate and promulgate a new key pair, update the protocol and inv=
alidate the old one, remove an untrusted node from the system, etc. Unfor=
tunately, many systems don't collect enough data to provide an audit trai=
l, or fail to protect the data against modification. Counterpane Systems =
has done considerable work in securing audit logs in electronic commerce =
systems, mostly in response to system designs that could fail completely =
in the event of a successful attack. These systems have to do more than d=
etect an attack: they must also be able to produce evidence that can conv=
ince a judge and jury of guilt.</P>
<H2>Building Secure Cryptographic Systems</H2>
<P>Security designers occupy what Prussian general Carl von Clausewitz ca=
lls "the position of the interior." A good security product mus=
t defend against every possible attack, even attacks that haven't been in=
vented yet. Attackers, on the other hand, only need to find one security =
flaw in order to defeat the system. And they can cheat. They can collude,=
conspire, and wait for technology to give them additional tools. They ca=
n attack the system in ways the system designer never thought of.</P>
<P>Building a secure cryptographic system is easy to do badly, and very d=
ifficult to do well. Unfortunately, most people can't tell the difference=
=2E In other areas of computer science, functionality serves to different=
iate the good from the bad: a good compression algorithm will work better=
than a bad one; a bad compression program will look worse in feature-com=
parison charts. Cryptography is different. Just because an encryption pro=
gram works doesn't mean it is secure. What happens with most products is =
that someone reads <CITE>Applied Cryptography</CITE>, chooses an algorith=
m and protocol, tests it to make sure it works, and thinks he's done. He'=
s not. Functionality does not equal quality, and no amount of beta testin=
g will ever reveal a security flaw. Too many products are merely "bu=
zzword compliant"; they use secure cryptography, but they are not se=
cure.</P>
<p align=3D"center"><a href=3D"index.html"><font size=3D"2"><cite>Home
page</cite></font></a><font size=3D"2"><cite> - </cite></font><a
href=3D"cpaneinfo.html"><font size=3D"2"><cite>Counterpane</cite></font><=
/a><font
size=3D"2"><cite> - </cite></font><a href=3D"applied.html"><font
size=3D"2"><cite>Applied Cryptography</cite></font></a><font
size=3D"2"><cite> - </cite></font><a href=3D"email.html"><font
size=3D"2"><cite>E-Mail Security</cite></font></a><font size=3D"2"><cite>=
- </cite></font><a href=3D"hotlist.html"><font size=3D"2"><cite>Crypto Li=
nks</cite></font></a><font
size=3D"2"><cite><br>
</cite></font><a href=3D"schneier.html"><font size=3D"2"><cite>Bruce
Schneier Bio</cite></font></a><font size=3D"2"><cite> - </cite></font><a
href=3D"blowfish.html"><font size=3D"2"><cite>Blowfish</cite></font></a><=
font
size=3D"2"><cite> - </cite></font><a href=3D"publish.html"><font
size=3D"2"><cite>Publications</cite></font></a><font size=3D"2"><cite>
- </cite></font><a href=3D"contact.html"><font
size=3D"2"><cite>Contact Counterpane</cite></font></a></p>
<HR>
<FONT SIZE=3D"-1"><STRONG>Bruce Schneier<br>
Copyright 1998 Counterpane Systems.</STRONG></FONT></body>
</html>
--------------5713295A6FBD--
