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 / 0reject)
• 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., T100 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
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

14
(No Transcript)
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
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)