Download
1 / 21
210 likes | 220 Vues
This lecture discusses the importance of message integrity in encryption, the use of Message Authentication Codes (MACs) for achieving integrity, and the security definitions and goals for MACs. It also covers replay attacks, hash functions, and MACs in practice. Moreover, it explores the combination of encryption and integrity, as well as the sharing of keys using key exchange protocols like Diffie-Hellman.
E N D
CMSC 414Computer and Network SecurityLecture 5 Jonathan Katz
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
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
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?
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
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?!
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.
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
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…
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
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)
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
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…)
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
prime p, element g Zp* hA = gx mod p hB = gy mod p The Diffie-Hellman protocol KAB = (hB)x KBA = (hA)y
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
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!
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)
