CMSC 414 Computer and Network Security Lecture 5

1. CMSC 414Computer and Network SecurityLecture 5 Jonathan Katz

2. Administrative announcements • Midterm I • March 6 • GRACE accounts set up • Need to have a glue account • HW submission done using GRACE submit script • Finding a partner • Email TA with “partner-414” in subject line

3. Message integrity

4. Encryption does not provide integrity • “Since encryption garbles the message, decryption of a ciphertext generated by an adversary must be unpredictable” • WRONG • E.g., one-time pad, CBC-/CTR-mode encryption • Why is this a concern? • Lack of integrity can lead to lack of secrecy • Almost always, integrity is needed in addition to secrecy

5. Message authentication codes (MACs) • In the private-key setting, the correct tool for achieving message integrity is a MAC • Functionality: • MACK(m) = t (“tag”) • VrfyK(m, t) = 0/1 (“1” = “accept” / ”0”=“reject”) • Correctness… • Security?

6. Defining security • Attack model: • A random key K is chosen • Attacker is allowed to obtain t1 = MACK(m1), …, tn = MACK(mn) for any messages m1, …, mn of its choice • “Break” of security Attacker “breaks” the scheme if it outputs a forgery; i.e., (m, t) with: • m ≠ mi for all i • VrfyK(m, t) = 1

7. Defining security • A MAC is secure if for all attackers running for some time T (e.g., T=100 years), the probability that the attacker “breaks” the scheme is at most  (e.g.,  = 2-80) • Note that length of the tag lower bounds  • Is the definition too strong? • When would an attacker be able to obtain tags on any messages of its choice?! • Why do we count it as a break if the adversary outputs a forgery on a meaningless message?!

8. Replay attacks • A MAC inherently cannot prevent replay attacks • These must be prevented at a higher level of the protocol! (Note that whether a replay is ok is application-dependent.) • Can be prevented using nonces, timestamps, etc.

9. Hash functions • A (cryptographic) hash function H maps arbitrary length inputs to a fixed-length output • Main goal is collision resistance: • Hard to find distinct x, x’ such that H(x) = H(x’) • Birthday attacks show that output length of H is critical • Other goals • Second pre-image resistance: given x, hard to find x’ ≠ x with H(x) = H(x’) • Weaker than collision resistance • “Random-looking output”: I.e., “acts like a random oracle” • Controversial

10. Hash functions in practice • MD5 • 128-bit output • No longer collision resistant (as of 2004) • Still second pre-image resistant (for now…) • Still widely deployed… • SHA-1 • 160-bit output • No collisions known (yet), but theoretical attacks exist • SHA-2 • 256-/512-bit outputs • Competition to design new hash standard has just begun…

11. K H H(M) MAC M t Hash-and-MAC • Say we have a secure MAC for “short” messages • How to extend it for longer messages? • Hash and MAC • Hash message to short “digest” • MAC the digest • Not used in practice for MACs • But used extensively for signatures (see later) • Similar ideas used in practical MAC constructions

12. MACs in practice • CBC-MAC • Can be constructed from any block cipher • Directly handles long messages (without hashing) • “Standard” variant is insecure if used on messages of different lengths • Known fixes for variable-length messages – make sure to use! • HMAC • Constructed from a hash function • Directly handles long messages (hashing done as part of construction)

13. Encryption + integrity • In most settings, confidentiality and integrity are both needed • How to obtain both? • Three “natural” possibilities: • Encrypt-and-authenticate • Authenticate-then-encrypt • Encrypt-then-authenticate • Only the latter is problem-free… • Can also use dedicated mode of encryption

15. Toward public-key crypto…

16. Sharing keys? • Secure sharing of a key is necessary for private-key crypto • How do parties share a key in the first place? • One possibility is a secure physical channel • E.g., in-person meeting • Dedicated (un-tappable) phone line • USB stick via courier service • Another possibility: key exchange protocols • Parties can agree on a key over a public channel • This is amazing! (And marked a revolution in crypto…)

17. Diffie-Hellman key exchange • Modular arithmetic, ZN, ZN* • Diffie-Hellman protocol • Security? • Secure against passive eavesdropping only • We will cover stronger notions of security for key exchange in much more detail later in the semester

18. prime p, element g Zp* hA = gx mod p hB = gy mod p The Diffie-Hellman protocol KAB = (hB)x KBA = (hA)y

19. Security? • Consider security against a passive eavesdropper • Under the computational Diffie-Hellman (CDH) assumption, hard for an eavesdropper to compute KAB = KBA • Not enough for security! • Can hash the key before using • Under the decisional Diffie-Hellman (DDH) assumption, the key KAB looks random to an eavesdropper

20. Technical notes • p and g must be chosen so that the CDH/DDH assumptions hold • Need to be chosen with care • Details in CMSC456 • Can also use other groups • Elliptic curves are also popular • Modular exponentiation can be done quickly (in particular, in polynomial time) • But the naïve algorithm does not work!

21. Security against active attacks? • The basic Diffie-Hellman protocol we have shown is not secure against a ‘man-in-the-middle’ attack • In fact, impossible to achieve security against such an attacker unless some information is shared in advance • E.g., private-key setting • Or public-key setting (next)