A HAcksn Looks AT

CnYTocnAHY
nucs ScHNsisn
Counterpane Systems
101 East Minnehaha Parkvay, Minneapo|is, MN 55419
Phone. (612) 823 1098; Fax. (612) 823-1590
schneier@counterpane.com
http.//vvv.counterpane.com
B|ack Hat 99
Las Vegas, NV7 Ju|y 1999
2
lNTnooucTioN
I Cryptography is a poverIu| too| Ior computers,
especia||y netvorked computers.
I Cryptography a||ovs us to take existing business
and socia| constructs Irom the Iace-to-Iace vor|d
into the vor|d oI computers and netvorks.
I Cryptography has the potentia| Ior transIorming the
Internet Irom a toy to a serious business too|.
I UnIortunate|y, most products and systems that use
cryptography are insecure.
I Most commercia| cryptography does not perIorm as
advertised.
3
OuTLiNs
I What are ve trying to do?
I Can ve do it?
I Why cryptosystems Iai|?
I What can ve |earn Irom this?
4
PnocnAmmiNc SATAN`s ComuTsn
I Security engineering is diIIerent Irom any
other type oI engineering.
I Most products are useIu| Ior vhat they do.
I Security products are useIu| precise|y because
oI vhat they do not a||ov to be done.
I Most engineering invo|ves making things vork.
I Security engineering invo|ves Iiguring out hov
to make things not vork.and then preventing
those Iai|ures.
5
PnocnAmmiNc SATAN`s ComuTsn
(coNT.I
I SaIety engineering invo|ves making sure
things do not Iai| in the presence oI random
Iau|ts.
I Security engineering invo|ves making sure
things do not Iai| in the presence oI an
inte||igent and ma|icious adversary vho
Iorces Iau|ts at precise|y the vrong time and
in precise|y the vrong vay.
6
TssTiNc SATAN`s ComuTsn
I Security is orthogona| to Iunctiona|ity.
Just because a security products Iunctions
proper|y does not mean that its secure.
I No amount oI beta testing can ever uncover
a security I|av.
I Experienced security testing is required to
discover security I|avs.
7
THs FAiLuns or TssTiNc SscuniTY
I Imagine a vendor shipping a product vithout
any Iunctiona| testing.
No in-house testing.
No beta testing.
Just make sure it compi|es and then ship it.
I A product |ike this vi|| have hundreds oI bugs;
the odds oI it vorking proper|y are neg|igib|e.
I Nov imagine a vendor shipping a security
product vithout any security testing.
I The odds oI it being secure are neg|igib|e.
8
How To TssT SscuniTY
I Experienced security testing can discover
security I|avs, but its not easy.
I F|avs can be anyvhere. the threat mode|, the
design, the a|gorithms and protoco|s, the
imp|ementation, the conIiguration, the user
interIace, the usage procedures, and so on.
I "B|ack-box" testing isnt very useIu|.
I There is no comprehensive security check|ist.
Experience in rea|-vor|d Iai|ures is the on|y vay to
be a good tester.
9
WHY CnYTosYsTsms FAiL
I The reasons are as numerous as the number
oI systems.
I There are many common b|unders.
I Vendors make the same mistakes over and
over again.
I This |ist is not exhaustive, but its pretty
good.
I Vendors shou|d Iee| Iree to make nev
mistakes.
10
Uss or PnonisTAnY ALconiTHms
I Designing cryptographic a|gorithms is very
diIIicu|t.
Many pub|ished a|gorithms are insecure.
A|most a|| unpub|ished a|gorithms are insecure.
I Un|ess someone has had considerab|e
experience cryptana|yzing a|gorithms, it is
un|ike|y that his design vi|| be secure.
It is easy Ior someone to create an a|gorithm that
he himse|I cannot break.
11
Uss or PnonisTAnY ALconiTHms
(coNT.I
I Inexperienced cryptana|ysts create insecure
designs (cont.).
II an a|gorithm designer has not proved that he
can break pub|ished a|gorithms (usua||y by
pub|ishing his ovn cryptana|yses), vhy shou|d
anyone trust his designs?
I There is usua||y no reason to use an
unpub|ished a|gorithm.
There are secure methods Ior making a secure,
proprietary, non-interoperab|e a|gorithm out oI a
pub|ished a|gorithm.
12
Uss or PnonisTAnY ALconiTHms
(coNT.I
I There is usua||y no reason to use a nev and
unana|yzed a|gorithm in p|ace oI an o|der and
better ana|yzed one.
I There is no substitute Ior peer reviev.
I Never, ever, trust a proprietary or secret
a|gorithm. (The NSA is the exception to this
ru|e.)
13
Uss or PnonisTAnY PnoTocoLs
I Designing cryptographic protoco|s is very
hard.
I Many pub|ished protoco|s have been broken
years aIter their pub|ication.
I There are severa| protoco|-design tricks that
the academic community has come up vith
over the years.
14
Uss or PnonisTAnY noTocoLs
(coNT.I
I The design process oI pub|ic proposa|,
ana|ysis, revision, repeat seems to vork
pretty ve||.
Compare the security oI the proprietary MicrosoIt
PPTP vith the open IPSec.
I There is no substitute Ior peer reviev.
I A c|osed or proprietary protoco| is most |ike|y
I|aved.
15
Ao HANoomizATioN
I Pandom numbers are critica| Ior most
modern cryptographic app|ications.
Session keys.
Seeds Ior generating pub|ic keys.
Pandom va|ues Ior digita| signatures.
Protoco| nonces.
I An insecure random number generator can
compromise the security oI an entire system.
The security oI many a|gorithms and protoco|s
assumes good random numbers.
16
Ao HANoomizATioN (coNT.I
I There are many vays to abuse PNGs.
Learn the state.
Extend a state compromise Iorvard or backvard
in time.
Learn or contro| inputs to reduce output entropy.
I Poor PNGs are probab|y the most common
security prob|em in products today.
I Counterpane Systems has re|eased Yarrov, a
pub|ic-domain PNG. Use it.
17
CuLT or MATHsmATics
I Mathematics is a science, not a security
yardstick.
I Some peop|e obsess about key |ength; a |ong
key does not equa| a strong system.
18
CuLT or MATHsmATics (coNT.I
I ProoIs oI security on|y vork vithin the
mode| oI security oI the prooI.
The attack on PKCS =1 vent outside the
mathematica| mode| oI PSA to break certain
imp|ementations.
Cne-time pads. the a|gorithm is provab|y secure,
but computer app|ications bui|t vith the cipher
are comp|ete|y insecure or impractica|.
I Mathematics vorks on bits; security invo|ves
peop|e.
19
lNsscuns SorTwAns, ComuTsns,
ANo NsTwonk
I "Buzzvord comp|iant" cryptographic
products are not suIIicient.
I It is diIIicu|t to vrite secure code. overI|ov
bugs, user-interIace errors, diIIicu|ty oI
erasing secret inIormation, etc.
20
lNsscuns SorTwAns, ComuTsns,
ANo NsTwonk (coNT.I
I It can be impossib|e to bui|d a secure
app|ication on top oI an insecure computing
p|atIorm.
Stea|th keyboard recorders
Trojan horses
Viruses
I Insecure computer netvorks can undermine
the security oI computers attached to them.
21
FAiLunss or Sscuns PsnimsTsns
I Some systems re|y on the notion oI a secure
perimeter Ior security.
Smart cards, access tokens, dong|es, etc.
I There is no such thing as tamperprooI
hardvare.
The ease oI deIeating tamperprooIing measures
depends on the budget oI the attacker, and
changes dramatica||y as techno|ogy improves.
22
FAiLunss or Sscuns PsnimsTsns
(coNT.I
I Any system vhere the device is ovned by
one person, and the secrets vithin the
device are ovned by another, is an insecure
system.
I Systems shou|d use tamper-resistance as a
barrier to entry, not as an abso|ute security
measure.
23
Nsw VuLNsnAeiLiTiss lNTnooucso
eY KsY Escnow
I Data backup is vita|; the va|ue oI a key used
to encrypt business data equa|s the va|ue oI
that data.
I There is abso|ute|y no business case Ior
escroving keys used Ior communication;
those keys have no va|ue.
24
Nsw VuLNsnAeiLiTiss lNTnooucso
eY KsY Escnow (coNT.I
I Corporate data backup needs are not the same
as |av-enIorcement key-escrov demands.
24-hour access.
Surreptitious access.
Pea|-time access.
I Lav-enIorcement access requirements I|y in
the Iace oI security requirements so|ved by
cryptography.
PerIect Iorvard secrecy.
Simp|icity oI the trust mode|.
Large targets that are very proIitab|e to attack.
25
Nsw VuLNsnAeiLiTiss lNTnooucso
eY KsY Escnow (coNT.I
I The massive sca|e oI any key-escrov
inIrastructure is beyond the abi|ity oI the
current security community.
I The NSAs ovn ana|ysis conc|uded that key
escrov is too risky, and creates more
security prob|ems than it so|ves.
26
HsLiANcs oN Ussn-Hsmsmesnso
SscnsTs
I Many systems re|y on user-generated and
user-remembered secrets Ior security.
(Examp|e. PGP.)
I Many passvord-protected systems have the
characteristic oI being on|y as secure as the
veakest passvord.
I Users cannot remember good secrets.
Period.
27
HsLiANcs oN Ussn-Hsmsmesnso
SscnsTs (coNT.I
I Eng|ish has 1.3 bits oI entropy per character;
a 30-character Eng|ish passphrase has as
much security as a 40-bit key.
I Pandom passvords have |ess than 4 bits oI
entropy per character; a 12-character
passvord is more secure than a 40-bit key.
28
HsLiANcs oN lNTsLLicsNT Ussns
I Security vorks better vhen it is visib|e to
the user, but users dont vant to see
security measures.
I Users cannot be re|ied on to make inte||igent
security decisions.
Users cannot be asked iI they trust a piece oI
dovn|oaded Java code.
Users cannot be expected to veriIy certiIicates.
29
HsLiANcs oN lNTsLLicsNT Ussns
(coNT.I
I Users cannot be re|ied on to Io||ov security
procedures.
Users vi|| vork around annoying security
measures.
Users vi|| give avay secrets. socia| engineering.
I Cryptography vorks in the digita| vor|d; it is
very diIIicu|t to manage the transition Irom
peop|e into the digita| vor|d and back again.
What you see is not a|vays vhat you get.
What you get is not a|vays vhat you vant.
30
WsAkNsssss iN AuTHsNTicATioN
lNrnAsTnucTuns
I Trust is a comp|ex socia| phenomenon, and
cannot be encapsu|ated in a sing|e
"certiIicate."
There is no g|oba| name space.
There is no sing|e |eve| oI assurance.
I An open, genera| purpose, inIrastructure
means more tempting targets.
The physica| security oI a CA can be enormous.
US Mint|eve| security can be required.
A Trojan horse can drop a phony certiIicate into
your computer, Ioo|ing you into trusting someone.
31
WsAkNsssss iN AuTHsNTicATioN
lNrnAsTnucTuns (coNT.I
I CertiIicates issued by "trusted third parties"
are use|ess vithout some sort oI |iabi|ity
mode| attached.
I Key veriIication is not oIten done.
Hov may peop|e check to see vhose certiIicate
they received vhen setting up an SSL
connection?
Someone can drop a Trojan horse into your
computer and Ioo| you into trusting someone.
32
WsAkNsssss iN AuTHsNTicATioN
lNrnAsTnucTuns (coNT.I
I Key revocation is very diIIicu|t, and is
current|y not being done secure|y.
When you get a key over the Internet, it is vita|
to veriIy that the key has not been revoked or
sto|en.
I Authentication is not the same thing as
authorization.
Authentication is automatic; authorization
requires thought.
33
HsLiANcs oN GLoeAL SscnsTs
I Some systems are created vith g|oba| secrets,
vhose compromise resu|ts in system-vide
Iai|ure.
I These systems are on|y as secure as the most
veak|y protected instance oI that secret.
I These systems are on|y as secure as the |east
trusted person vho is trusted vith that secret.
I It is very hard, sometimes impossib|e, to
recover security aIter a vide|y dep|oyed g|oba|
secret has been compromised.
34
VsnsioN HoLLeAck ATTAcks
I Pea|-|iIe requirements oI the Internet (and o|der
netvorks) require backvards compatibi|ity.
I For security systems, backvards compatibi|ity
is very dangerous.
Do you rea||y vant your secure protoco| to be
backvards compatib|e vith an o|der, insecure,
protoco|?
I It is sometimes possib|e to convince a secure
system to use an insecure version oI itse|I.
Many man-in-the midd|e app|ications oI this attack.
35
"sLow THs HAoAn ATTAcks
I Automation a||ovs Ior attacks that are too
cumbersome against manua| systems to be
proIitab|e.
Margina| proIitabi|ity oI each attack. stea|ing
pennies Irom interest-bearing accounts.
Margina| probabi|ity oI success. spamming the
net vith a Iraudu|ent business proposa|.
S|ov and boring. scanning the entire nevs spoo|
|ooking Ior peop|e vho are both members oI a
Fundamenta|ist Church and active in the S&M
community.
36
AuTomATso ATTAcks
I Many attacks are "dismissed" as requiring
more ski|| than the average attacker has.
I Cn|y the Iirst attacker needs ski||; the rest
can use soItvare.
37
AuTomATso ATTAcks (coNT.I
I SoItvare attacks have diIIerent propagation
characteristics than rea| attacks.
Physica| counterIeiting is diIIicu|t; maximum
damage is restricted due to the physica|
|imitations.
E|ectronic counterIeiting can be automated;
maximum damage is exponentia|.
I "C|ick here to bring dovn the Internet."
38
Poon FAiLuns Mooss
I Many systems have a "deIau|t to insecure"
mode oI operation.
Examp|e. Crash a Iireva||. Wait unti| someone gets
Irustrated and shuts it dovn. Wa|tz right in.
Examp|e. Disrupt the communications |ine that
veriIies a Visa card, and a merchant vi|| just accept
the transaction.
I Cn|y the mi|itary has the discip|ine to not
communicate iI the security measures are not
in p|ace. (And theyre by no means perIect.)
39
Poon Comnomiss HscovsnY
I Systems vi|| Iai|; it is essentia| to be ab|e to
recover Irom a security breach.
Pegeneration and redistribution oI compromised
secrets.
Pep|acement oI Iau|ty a|gorithms and protoco|s.
I Traditiona||y, Iraud prevention has been
reactive. Automated systems can make this
impossib|e.
I Any business p|an that denies the possibi|ity
oI a security compromise is unacceptab|e.
40
lmnosn Hisk MANAcsmsNT
I It is vita| to understand the risks that a
cryptographic system is protecting against.
Crimina| attacks, pub|icity attacks, and |ega|
attacks are a|| diIIerent. As is inIormation
varIare.
Privacy vio|ations. targeted attack vs. data
harvesting.
The characteristicsIunding, expertise, access,
motivationoI an attacker.
41
lmnosn Hisk MANAcsmsNT (coNT.I
I It is vita| to understand the va|ue oI the data
being protected.
Privacy, Iinancia| data, identity inIormation, etc.
I The internationa| nature oI the Internet can
exacerbate this prob|em.
Jurisdiction shopping.
I Strong systems proper|y manage the re|ative
risk oI the diIIerent parties being protected.
Systems that can |everage ongoing re|ationships
have an easier time.
Anonymous systems are inherent|y riskier.
42
Poon FonsNsics
I Preventing crime is much harder than
detecting crime.
I Detecting crime is not enough; you need to
be ab|e to prove it in court.
I Security systems Iai|; audit is essentia| to
both Iigure out vhat happened and
prosecute the gui|ty.
43
CoNcLusioNs: THs LimiTs or
PsncsTioN
I The prob|em vith bad cryptography is that it
|ooks just |ike good cryptography.
I A|most a|| security products on the market
today are insecure.
I Expert security testing is the on|y vay to te||
a secure product Irom an insecure one.
44
CoNcLusioNs: THs LimiTs or
HsouinsmsNTs
I Cryptography doesnt have to be perIect; but
the risks have to be manageab|e.
I Most systems permit some |eve| oI Iraud.
I "A secure computer is one that has been
insured."
45
CoNcLusioNs: THs LimiTs or
TscHNoLocY
I Cryptography is a mathematica| too|. It is
essentia| Ior a secure system, but it does not
automatica||y make a system secure.
I The socia| prob|ems are much harder than
the mathematics.
I II you think cryptography can so|ve your
prob|em, then you dont understand your
prob|em and you dont understand
cryptography.
You Ans ALL iNviTso To
suescnies To mY rnss
moNTHLY s-mAiL NswsLsTTsn:
CHYPTO-GHAM
See http.//vvv.counterpane.com
Ior detai|s.