CMSC 414 Computer and Network Security Lecture 10

1
CMSC 414Computer and Network SecurityLecture 10

• Jonathan Katz

2
Crypto pitfalls?

1. Bad cryptography, bad implementations, bad design
2. Even good cryptography can be circumvented by
   adversaries operating outside the model
3. Systems are complex, and your model may not
   exactly match reality
4. Side channel attacks
5. Even the best cryptography only shifts the
   weakest point of failure elsewhere

3
Recommendations and warnings
4
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

5
Random number generation

• Do not use standard PRNGs use cryptographic
  PRNGs instead
• E.g., srand/rand in C
• srand(seed) sets stateseed (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

6
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?

7
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

8
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?

9
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??

10
Implementation flaws

• Must implement crypto exactly as specified!
• PKCS1 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

11
Delimiting tokens

• E.g., Amazon Web Services v1
• Split query at and concatenate and apply
  MAC
• The following are then equivalent?GoodKey1Good
  Value1BadKey2BadValue2?GoodKey1GoodValue1BadKe
  y2BadValue2
• Wordpress cookie flaw
• token HMAC(username.expirytime)
• Create account for usernameadmin0 and go
• Using timestamps to prevent replay
• Is MAC(withdraw 101.1/23/09) MAC(withdraw
  10.11/23/09)?

12
Case studies
13
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

14
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

15
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

16
Desired security

• If an attacker does not have a users ATM card,
  should be infeasible to withdraw money from that
  users account (even if the PIN is guessed)
• If an attacker does not have a users PIN, the
  best an adversary can do is guess it repeatedly
• 1/10000 chance each time
• Prevent unlimited guessing

17
One system
ATM
Bank
, PIN
Account
ok
PIN
If FK() PIN return ok
This is similar, but not identical, to how ATMs
work today
18
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?)

19
Another system
Account cEncK(PIN)
ATM
Bank
, c, PIN
ok
PIN
If DK(c) PIN debit account , return ok
No binding between account and PIN!
20
Another system
encrypted
Account
ATM
Bank
PIN

balance
withdraw amt
If amt balance, dispense cash
If FK() PIN authenticated
Do you see an attack?