CMSC 414 Computer and Network Security Lecture 7

1. CMSC 414Computer and Network SecurityLecture 7 Jonathan Katz

2. Malleability/chosen-ciphertext security • All the public-key encryption schemes we have seen so far are malleable • Given a ciphertext c that encrypts an (unknown) message m, it is possible to generate a ciphertext c’ that encrypts a related message m’ • In many scenarios, this is problematic • E.g., auction example; password example • Note: the problem is not integrity (there is no integrity in public-key encryption, anyway), but malleability

3. Malleability/chosen-ciphertext security • In the public-key setting, security against chosen-ciphertext attacks is equivalent to non-malleability • In general, always use a public-key encryption scheme secure against chosen-ciphertext attacks! • E.g., RSA PKCS #1 v2.1 • When using hybrid encryption, if both components are secure against chosen-ciphertext attacks then the combination it also secure against chosen-ciphertext attacks

4. Signature schemes

5. Basic idea • A signer publishes a public key pk • As usual (for now), we assume everyone has a correct copy of pk • To sign a message m, the signer uses its private key to generate a signature  • Anyone can verify that  is a valid signature on m with respect to the signer’s public key pk • Since only the signer knows the corresponding private key, we take this to mean the signer has “certified” m • Security (informally): no one should be able to generate a valid signature other than the legitimate signer

6. Prototypical application • Software company wants to periodically release patches of its software • Doesn’t want a malicious adversary to be able to change even a single bit of the legitimate path • Solution: • Bundle a copy of the company’s public key along with initial copy of the software • Software patches signed (perhaps with a version number) • Do not accept patch unless it comes with a valid signature (and increasing version number)

7. Signatures vs. MACs • Could MACs work in the previous example? • Computing one signature vs. multiple MACs • Public verifiability • Transferability • Non-repudiation Not obtained by MACs!

8. Functional definition • Key generation algorithm: randomized algorithm that outputs (pk, sk) • Signing algorithm: • Takes a private key and a message, and outputs a signature;   Signsk(m) • Verification algorithm: • Takes a public key, a message, and a signature and outputs a decision bit; b = Vrfypk(m, ) • Correctness: for all (pk, sk), Vrfypk(m, Signsk(m)) = 1

9. Security? • Analogous to MACs • Except that adversary is given the signer’s public key • (pk, sk) generated at random; adversary given pk • Adversary given 1 = Signsk(m1), …, n = Signsk(mn) for m1, …, mn of its choice • Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, ) with: • m ≠ mi for all i • Vrfypk(m, ) = 1

10. “Textbook RSA” signatures • Public key (N, e); private key (N, d) • To sign message m  ZN*, compute  = md mod N • To verify signature  on message m, check whether e = m mod N • Correctness holds… • …what about security?

11. Security of textbook RSA sigs? • Textbook RSA signatures are not secure • Easy to forge a signature on a random message • Easy to forge a signature on a chosen message, given two signatures of the adversary’s choice

12. 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 previous attacks?

13. Security of hashed RSA • Can we prove that hashed RSA is secure? • Take CMSC456! • Hashed RSA signatures can be proven secure based on the hardness of the RSA problem, if the hash is modeled as a random function • Variants of hashed RSA are used in practice

14. 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 need to know that it exists

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

16. Crypto pitfalls

17. Cryptography is not a “magic bullet” • Crypto can be difficult to get right • Must be implemented correctly • Need expertise; “a little knowledge can be a dangerous thing…” • Must be integrated from the beginning • Use only standardized algorithms and protocols • No security through obscurity!

18. Cryptography is not a “magic bullet” • Crypto alone cannot solve all security problems • Key management; social engineering; insider attacks • Develop (appropriate) threat/trust models • Need to analyze weak links in the chain… • Adversary may not be able to eavesdrop, but can it: • Access your hard drive? • See CRT emissions? • Go through your trash? • “Side channel attacks” on cryptosystems

19. Cryptography is not a “magic bullet” • Human factors • Crypto needs to be easy to use both for end-users and administrators • Important to educate users about appropriate security practices • Need for review, detection, and recovery • Security as a process, not a product

20. Random number generation • Do not use “standard” RNGs; use cryptographic RNGs instead • E.g., srand/rand in C: • srand(seed) sets state=seed (|state| = 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!

21. More on random number generation • Netscape v1.1: • rv = SHA1(pid, ppid, time) • return rv • Problem: the input to SHA1 has low entropy