CMSC 414 Computer and Network Security Lecture 10

1. CMSC 414Computer and Network SecurityLecture 10 Jonathan Katz

2. Crypto pitfalls? • Bad cryptography, bad implementations, bad design • Even good cryptography can be ‘circumvented’ by adversaries operating ‘outside the model’ • Systems are complex, and your model may not exactly match reality • Side channel attacks • 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 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

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! • 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

11. 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)?

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

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 # c=EncK(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?