1 / 19

Lecture 2: Message Authentication

Lecture 2: Message Authentication. Anish Arora CSE5473 Introduction to Network Security. Message authentication. message authentication is concerned with: protecting the integrity of a message validating identity of originator protecting the order or timeliness of a message

lanza
Télécharger la présentation

Lecture 2: Message Authentication

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. Lecture 2: Message Authentication Anish Arora CSE5473 Introduction to Network Security

  2. Message authentication • message authentication is concerned with: • protecting the integrity of a message • validating identity of originator • protecting the order or timeliness of a message • message authentication deals with these attacks: • masquerade • content modification • sequence modification • timing modification • In this lecture, we consider three alternative functions used for msg. auth.: • message encryption • message authentication code (MAC) • hash function • and some requirements for designing MAC codes

  3. Message encryption provides some authentication if symmetric encryption is used: • receiver knows sender must have created msg, since only sender&receiver know key • know content has not been altered if public-key encryption is used: • encryption provides no confidence of sender identity, since potentially every one knows public-key • however, if • sender signs message using their private-key • then encrypts with recipients public key • we have both secrecy and authentication • again need to recognize corrupted messages, but at cost of two public-key uses on message

  4. Rejecting gibberish when using symmetric encryption • If every ciphertext value corresponds to some plaintext value, adversary can fool receiver into accepting gibberish • An automatic means to detect whether an incoming ciphertext decrypts to some meaningful plaintext is desirable, but difficult • Solution is to give some structure to the plaintext: • example: • use checksums to separate meaningful text from gibberish • but checksum must be internal to ciphertext (why?) • particular choice of structure does not matter: • e.g. use with TCP headers

  5. Checksums • Internal versus External • IP packets: encrypt entire TCP packet; TCP header contains checksum

  6. Message authentication code (MAC)

  7. MAC • generated by an algorithm that creates a small fixed-sized block • depending on both the message and the key • like encryption, but need not be reversible though • appended to message • receiver performs same computation on message & checks it matches MAC • provides assurance that message is unaltered & comes from sender, per se does not provide encryption or signature • so, why use a MAC? • sometimes only authentication is needed • authentication may be needed longer than encryption (e.g. archival use) • broadcast: only one needs to check, or optional check: now or later

  8. MAC properties • a MAC is a cryptographic checksum MAC = CK(M) • condenses a variable-length message M • using a secret key K • to a fixed-sized authenticator • is a many-to-one function • potentially many messages have same MAC • but finding these needs to be very difficult

  9. A brute force attack on MAC • On average, brute-force attack on k-bit key is O(2k-1 ) • With m-bit MAC, say m < k, • given plaintext P and ciphertext C brute-force search of all 2k keys, will still yield 2k /2m plausible keys • this can be iterated with more plaintexts until the key if found, but remains an expensive process

  10. Requirements for MACs • taking into account other types of attacks, we need the MAC to satisfy the following: • knowing a message and MAC, is infeasible to find another message with same MAC • MACs should be uniformly distributed • MAC should depend equally on all bits/parts of the message

  11. Using symmetric ciphers for MACs • can use any block cipher chaining mode and use final block as a MAC • Data Authentication Algorithm (DAA) is a widely used MAC based on DES-Cipher Block Chaining • using IV=0 and zero-pad of final block • encrypt message using DES in CBC mode • and send just the final block as the MAC • or the leftmost M bits (16≤M≤64) of final block • but final MAC is now too small for security

  12. More recent symmetric cipher options • Use AES instead of DES • CBC mode requires final encryption with a second, independent key to avoid extension attacks • Digression: NMAC (nested MAC) alternative • Output in key space, unlike CBC output in message space • Cascade function, but not well suited for AES • Needs padding with fixed pad, and encryption with second, independent key • How padding works • CMAC: NIST standard, CCM mode, uses two keys wrt pad/not

  13. Message authentication via hash functions + digital signature also

  14. Message authentication via hash functions (contd.) • Secret value is added before hashing and then removed before transmission

  15. Message authentication via hash functions • Note: In scheme (c) hashing M || S is more secure than hashing S || M • given the iterative structure of hash functions, adversary could extend M with M||X and generate new hash • Diffusing S in the hash of M and S can be achieved by using HMAC

  16. Keyed hash functions as MACs • desirable to create a MAC using a hash function rather than a block cipher • because hash functions are generally faster • not limited by export controls unlike block ciphers • hash includes a key along with the message • original proposal: KeyedHash = Hash(Key|Message) • some weaknesses were found with this • eventually led to development of HMAC

  17. HMAC • specified as Internet standard RFC2104 • uses hash function on the message: HMACK = Hash[(K+ XOR opad) || Hash[(K+ XOR ipad)||M)]] • where K+ is the key padded out to size • and opad, ipad are specified padding constants • overhead is just 3 more hash calculations than the message needs alone • can use MD-5 or SHA-1

  18. HMAC overview

  19. HMAC security • security of HMAC relates to that of the underlying hash algorithm • attacking HMAC requires either: • brute force attack on key used • birthday attack (but since keyed would need to observe a very large number of messages) • choose hash function based on speed vs. security constraints

More Related