1 / 27

CMSC 414 Computer and Network Security Lecture 9

Learn about the common pitfalls in cryptography and get recommendations on how to avoid them. Understand the importance of implementing crypto correctly and using standardized algorithms and libraries. Discover the risks of bad implementation and the need for key management and threat modeling.

hleon
Download Presentation

CMSC 414 Computer and Network Security Lecture 9

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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?

More Related