CMSC 414
Computer and Network Security
Lecture 10
Jonathan Katz
Crypto pitfalls?
1. Bad cryptography, bad implementations, bad
design
2. Even good cryptography can be ‘circumvented’
by adversaries operating ‘outside the model’
1. Systems are complex, and your model may not exactly
match reality
2. Side channel attacks
3. Even the best cryptography only shifts the
weakest point of failure elsewhere
Recommendations
and warnings
Crypto libraries
 Use existing, high-level crypto libraries
– cryptlib
– GPGME
– Keyczar
– These provide an appropriate interface to crypto
algorithms
 Avoid low-level libraries (like JCE) – too much
possibility of mis-use
 Avoid writing your own low-level crypto
Random number generation
 Do not use “standard” PRNGs; use cryptographic
PRNGs instead
 E.g., srand/rand in C:
– srand(seed) sets state=seed (where |seed| = 32 bits)
– rand():
• state = f(state), where f is some linear function
• return state
– Generating a 128-bit key using 4 calls to rand() results
in a key with only 32 bits of entropy!
 Related issues led to exploit in Netscape v1.1
More on PRNGs
 Crypto PRNGs have different requirements
– Indistinguishable from random by any efficient
algorithm
– Constantly re-seeded with new entropy to ensure
forward security
– Should be impossible to guess or perturb internal state
• E.g., if entropy comes from file timestamps
 “Cold boot” issues
– Server just rebooted and needs randomness….is there
enough entropy after being up just a few seconds?
Integrity protection
 Encryption does not provide integrity!
 Use authenticated encryption (e.g., encrypt-then-
MAC) in the symmetric-key setting when
confidentiality and integrity are required
– …and even if you only want confidentiality…
 Use public-key encryption secure against chosen-
ciphertext attacks
Avoid weak algorithms
 Be careful allowing too much flexibility in
negotiation of crypto algorithms
– Leads to a ‘parameter selection’ attack
 Difficult to adjust if fatal flaw found in weak
algorithm
– E.g., Upgrading encryption to add integrity protection:
• Old: CBC-encrypted
• New: Add integrity protection using a MAC
• Bright idea: get old credential; decrypt; re-encrypt with new
key + MAC
• Do you see the flaw?
Implementation flaws
 (These are crypto-specific; and do not include
general issues such as preventing buffer
overflows, etc. that we will cover later)
 Must implement crypto exactly as specified!
 if (0 == strncmp(userHash, myHash, 20)) allow;
– strncmp compares up to the first null character
– What if my hash starts with a 0 byte??
Implementation flaws
 Must implement crypto exactly as specified!
 PKCS#1 pads data as follows:
00 01 FF … FF 00 H(m)
 Bad implementation of signature verification?
– Exponentiate, strip off padding, and compare to H(m)
 Makes forgery easier!
 Every bit of padding must be checked
Delimiting tokens
 E.g., Amazon Web Services v1
– Split query at & and = ; concatenate and apply MAC
– The following are then equivalent:
…?GoodKey1=GoodValue1BadKey2BadValue2
…?GoodKey1=GoodValue1&BadKey2=BadValue2
 Wordpress cookie flaw
– token: HMAC(username.expirytime)
– Create account for username=‘admin0’ and go…
 Using timestamps to prevent replay
– Is MAC(withdraw $101.1/23/09) = MAC(withdraw
$10.11/23/09)?
Case studies
“Why Cryptosystems Fail”
 Limited disclosure of crypto failures…
 Insider attacks
– By bank clerks, maintenance engineers, …
– Poor prevention/detection/auditing mechanisms
– Poor key management
– Insecure delivery of ATM cards/PINs
 Reduced entropy of PINs
 Use of “home-brewed” encryption schemes
System goals and assumptions
 A user should need both their ATM card and their
PIN in order to withdraw money
– “Two-factor authentication”
 Assumptions:
– PIN must be short
– ATM card cannot perform cryptographic operations
Threat model
 Attacker can
– Read discarded receipts…
– Eavesdrop on channel from ATM to bank
– Inject messages on channel from ATM to bank
– Impersonate the ATM to a user
Desired security
 If an attacker does not have a user’s ATM card,
should be infeasible to withdraw money from that
user’s account (even if the PIN is guessed)
 If an attacker does not have a user’s PIN, the best
an adversary can do is guess it repeatedly
– 1/10000 chance each time
– Prevent unlimited guessing
One system
#, PIN
Account #
ATM
PIN
Bank
ok
If FK(#) = PIN:
return “ok”
This is similar, but not identical, to how ATMs work today
Attacks
 Eavesdrop on PIN and account # ; manufacture
rogue ATM card
 Replay “ok” message!
– Solution: use authentication with replay protection
 Impersonate an ATM to a customer
– Can this be prevented without implementing crypto on
the ATM card? (Hint: how could the bank authenticate
directly to the user?)
Another system
Account #
c=EncK(PIN)
#, c, PIN
ATM
PIN
Bank
ok
If DK(c) = PIN:
debit account #,
return “ok”
No binding between account # and PIN!
Another system
encrypted
Account #
PIN
ATM
#
balance
withdraw amt
IfIfamt
≤ balance,
FK(#)
= PIN:
dispense cash
“authenticated”
Do you see an attack?
Bank