1. CMSC 414Computer and Network SecurityLecture 9 Jonathan Katz

2. HW2 • Read “Why Cryptosystems Fail”

3. Hashed RSA • Public key (N, e); private key (N, d) • To sign message m, compute  = H(m)d mod N • To verify signature  on a message m, check whether e = H(m) mod N • Why does this prevent the previous attacks? • Note: has the added advantage of handling long messages “for free”

4. Security of hashed RSA • Hashed RSA signatures can be proven secure based on the hardness of the RSA problem, if the hash is modeled as a random function • Proof in CMSC456 • Variants of hashed RSA have been standardized, and are used in practice

5. DSA/DSS signatures • Another popular signature scheme, based on the hardness of the discrete logarithm problem • Introduced by NIST in 1992 • US government standard • I will not cover the details, but you should know that it exists

6. sk H H(M) Sign  M Hash-and-sign • Say we have a secure signature scheme for “short” messages (e.g., hashed RSA, DSS, …) • How to extend it for longer messages? • Hash and sign • Hash message to short “digest”; sign the digest • Used extensively in practice

7. Crypto review, recommendations • Secrecy vs. integrity • Different definitions of secrecy • Private-key setting • CPA-secure encryption: CBC mode, CTR mode • Secure MAC: CBC-MAC, HMAC • Authenticated encryption: e.g., CPA-secure encryption + MAC over the ciphertext • Public-key setting • CPA-secure encryption: El Gamal, Padded RSA • Non-malleable encryption: RSA-OAEP • Signatures: Hashed RSA, DSS

8. Crypto pitfalls and recommendations

9. Crypto pitfalls? • Crypto deceptively simple • Why does it so often fail? • Important to distinguish various issues: • Bad cryptography, bad implementations, bad design, etc. • Even good cryptography can often be ‘circumvented’ by adversaries operating ‘outside the model’ • Even the best cryptography only shifts the weakest point of failure to elsewhere in your system • Systems are complex • Avoid the first; be aware of 2-4

10. Systems are complex • Crypto alone cannot solve all security problems • Key management; social engineering; insider attacks • Need to develop an appropriate threat model for the system as a whole • Defense in depth • Need for review, detection, and recovery • Security as a process, not a product

11. Cryptography is not a “magic bullet” • Crypto is difficult to get right • Must be implemented correctly • Must be integrated from the beginning, not added on “after the fact” • Need expertise; “a little knowledge can be a dangerous thing…” • Can’t be secured by Q/A, only (at best) through penetration testing and dedicated review of the code by security experts

12. General recommendations • Use only standardized algorithms and protocols • No security through obscurity! • Use primitives for their intended purpose • Don’t implement your own crypto • If your system cannot use “off-the-shelf” crypto components, re-think your system • If you really need something new, have it designed and/or evaluated by an expert • Don’t use the same key for multiple purposes • E.g., encryption/MAC, or RSA encryption/signatures • Use good random-number generation

13. Crypto libraries • Use existing, high-level crypto libraries • cryptlib • NaCl • 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

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

15. 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?

16. 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 userHash starts with a 0 byte??

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

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

19. Case studies

20. “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

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

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

23. 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 known) • If an attacker has a user’s ATM card, but not their PIN, the best it can do is guess the PIN repeatedly • 1/10000 chance each time • Prevent unlimited guessing

24. One system ATM Bank #, PIN Account # ok PIN If FK(#) = PIN: return “ok” This is similar, but not identical, to how ATMs work today

25. 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? (How could the bank authenticate directly to the user?)

26. 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!

27. Another system encrypted Account # ATM Bank PIN # balance withdraw amt If FK(#) = PIN: “authenticated” If amt ≤ balance, dispense cash Do you see an attack?