1 / 38

Entity and Message Authentication

Learn about the importance of mutual authentication and message authentication codes (MAC) in secure communication, and the limitations of MAC.

pgene
Download Presentation

Entity and 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. Entity and Message Authentication Last updated: Friday, December 20, 2019 Prof. Amir Herzberg http://AmirHerzberg.com

  2. Shared Key Mutual Authentication • Alice and Bob share secret master key k • Man In The Middle (MITM) adversary • Controls all communication • Goals • Mutual authentication: Alice knows it talked with Bob and vice verse. • Usually, also authenticate messages between parties • Prevent message replay • Allow multiple concurrent connections. • Either party can initiate • Basic problem, appears (and is) easy • …but also easy to do wrong http://AmirHerzberg.com

  3. SNA LU6.2 Mutual Authentication • SNA – IBM’s Secure Network Architecture • Predominant network protocol till late eighties • Mutual authentication of session with key k • Protocol: (Na, Nb- randomly chosen nonces) http://AmirHerzberg.com

  4. Attack on SNA LU6.2 Authentication • Idea: Eve opens two connections with Bob… sending Nb to Bob in 2nd connection to get Ek(Nb) http://AmirHerzberg.com

  5. Observations & Thumb-rules • Prevent re-direction of message to sender • Identify party in challenge • Prevent re-direction of flow i to flow ji • Ensure different flows are easily distinguished • Prevent use of old challenge • Select new random challenge (nonce) or time • Do not compute values from Adversary • Include self-chosen nonce in the protected reply • Encryption does not ensure authenticity • Necessary for messages (and identities, etc.) http://AmirHerzberg.com

  6. Message Authentication Problem • Detect changes by adversary to message • Ancient solution: sign and seal • Even more ancient: break plate to message part and authenticator part (‘tag’) • Send tag to recipient securely (in advance) • Send message over insecure channel (later) • Recipient validates message using tag • How to do this electronically? • Can we use encryption? http://AmirHerzberg.com

  7. Encryption and Integrity • Encryption hides the message from Eve • Question: can Eve change/forge message? • Or: does encryption ensure message integrity? • Not with Public Key Encryption: • Eve can replace EB.e(m) with fake: EB.e(m’) • With Symmetric (Shared) Key Encryption: • Some EDC + Encryption combinations are secure • But not all! • OTP: given c=mk, attacker can send cmask, to invert any bit in decrypted message (use mask) •  Encryption does not always ensure integrity! http://AmirHerzberg.com

  8. Message Authentication Code (MAC) • Shared key k message authentication (integrity) • Validk (Tag , m)=True iff Tag=MACk(m) • Use shared key kto authenticate messages • Very efficient • Alice can deny k = ?? MAC (m ’ ) = ?? k Eve m m ’ + + MAC (m ) Tag ?? k Alice Bob Key k Key k http://AmirHerzberg.com

  9. Defining MAC: Syntax and usage • A Message Authentication Code is an efficient function MACk(m): K× M  {0,1}t (tag) • K is the key space, e.g. {0,1}k • M is the message space • M= {0,1}*VIL-MAC (Variable Input Length) • M= {0,1}nFIL-MAC (Fixed-Input Length) • To authenticate m, send <m, MACk(m)> • Upon receiving <m, a>, validate: a= MACk(m) http://AmirHerzberg.com

  10. MAC authenticates messages • MAC allows two or more mutually trusting parties to authenticate communication between them. Only Alice and me know k. So one of us sent m. Eve Bob Alice m, MACk(m) If I didn’t send m, then Alice must have sent it Key k Key k http://AmirHerzberg.com

  11. Simple MAC functions • Examples of Fixed-Input Length (FIL) MAC: {0,1}16*{0,1}32{0,1}16 • Encode input strings (4 chars) by their ASCII encoding • MACk(x)=int(32768*fraction(x*a+k*b)), where 0<a,b<1 • MACk(x)=int(√x||k) mod 232 • MACk(x)=x*(32567+k) mod 32767 • MACk(x)=(x[0…15]+k) (x[16…31]+k) • Security? http://AmirHerzberg.com

  12. MAC Experiment and Security Alice and Bob use key k … if you tell Bob: pay Eve 1$ Bob: pay Eve 1$ k Bob: pay Eve 10000$ k http://AmirHerzberg.com

  13. MAC authenticates messages • MAC allows two or more mutually trusting parties to authenticate all messages sent between them. Only Alice, Charlie, Don and me know k. So one of us sent m. Charlie Eve Key k Bob Alice m, MACk(m) Don Key k Key k Key k http://AmirHerzberg.com

  14. Limitations of MAC • MACk(m) may expose information about m! • Example: Let MAC be any secure MAC. Define MAC’k(m)=LSb(m)||MACk(m), where LSb is least significant bit. • MAC only shows a key-holder computed it • Could be any key holder (e.g. recipient)…  Specify sender, recipient in message • Could be re-transmission…  Add time/counter/random challenge to identify http://AmirHerzberg.com

  15. MAC Use Secret Key • Random or pseudo-random • Do not reveal to adversary • Do not use for anything except MAC • Easy to demonstrate: • MACk , Encryptkexposing key k • MACk , Encryptk allowing attack • Example: Let E , MACbe secure… • Forge: Let E’k(m)=Ek(m)||MACk(m+1) • Expose m: Let MAC’k(m)=MACk(m)||m http://AmirHerzberg.com

  16. Constructing MAC • How to select/design good (secure) MAC? • Cryptoanalyze candidates against MAC def • Problem: requires much effort to be trusted • Robust combiner of two MAC candidates: • MACk,k’(m)=fk(m)||f’k’(m) is secure, if eitherfor f’is secure [exercise, H05] • Open: is this `optimal`? (cf. for hash [BB06]) • Provable-secure constructions from… • Hash functions (later) • Block ciphers, e.g. CBC-MAC (next) http://AmirHerzberg.com

  17. Fixed Input Length PRF and MAC • Every FIL PRF is also a FIL MAC. • Proof sketch: it is not feasible to find a forgery in a random function. █ • Practical candidates: • Block ciphers • DES, Triple-DES, AES,… • Cryptographic hash/compression functions • MD5, SHA-1, RIPE-MD,… more later • What about VIL? Recall CBC-mode… http://AmirHerzberg.com

  18. Cipher Block Chaining (CBC) MAC Split plaintext mto blocks m[1],… 0 No (zero) Initialization Vector (IV) E E E k Ciphertext c[0],c[1],c[2]… MACk(m) http://AmirHerzberg.com

  19. CBC MAC [BKR94] • Let: CBCk({mi})=Ek(mlEk(…Ek(m1)))) • Widely deployed standard, especially in banking • With DES, vulnerable to key guessing • FIL CBC MAC Theorem: if Eis a 1-block FIL-PRF, then CBCkis an l-block FIL-PRF and an l-block FIL-MAC [Proof: BKR94, BR, KL] • What of variable-length input? MACk(x[1]..x[l]) 0 E E E k http://AmirHerzberg.com

  20. Variable Input Length MAC • CBC MAC is not secure for arbitrary variable-length inputs. • Example: adversary asks to receive b=CBCk(a)=Ek(a); then output <ac,b>where c= ab. This is rightsince CBCk(ac)=Ek(cEk(a))=Ek(cb)= Ek(a)= b. • What if we… • Append Length: ALCBCk=CBCk(a,|a|) ? No! [why?] • Prepend Length:PLCBCk(a)=CBCk(|a|,a) ? Yes, secure!! http://AmirHerzberg.com

  21. Variable Input Length MAC • Theorem [BKR94]:CBCkis a VIL-MAC if inputs are prefix-free • Namely: CBC MAC is secure if no input is a prefix of another • Possible implementation: prepend length • Given a family of secure n×l FIL-MAC for every length n:MACk,n(m) (e.g. CBCk,n(m)) • Let MAC’ k(m)=MACk,n(|m|,m,pad) s.t. • n= (|m|+log2(|m|))/l , pad={0}|m|+log(|m|)-nl • MAC’ is a secure VIL-MAC. http://AmirHerzberg.com

  22. Performance of MAC • Efficiency of MAC is critical • Message authentication necessary even w/o encryption • CBC MAC of nblocks requires n evaluations • Faster MAC? • Parallel or other block-cipher MAC designs • See e.g. [BR02] • MAC based on crypto hash functions • Most well known: HMAC • Later (after we learn crypto-hash…) http://AmirHerzberg.com

  23. Using MAC: Shared Key Mutual Authentication • Model: Alice and Bob share secret master keyk • Goals • Mutual authentication: Alice knows it talked with Bob and vice verse. • Parties may also send a message; prevent replays. • Allow multiple concurrent connections. • Either party can initiate. • Basic problem, appears (and is) easy • …but also easy to do wrong http://AmirHerzberg.com

  24. Mutual Authentication with MAC • Two Party Protocol (2PP) [BGH*93] – fix for SNA… • Use MAC rather than encryption to authenticate • Separate 2nd and 3rd flows – 3 vs. 2 input blocks • Include identities (A,B) to prevent redirections • Security: from MAC properties • See [BR93] for definition and proof http://AmirHerzberg.com

  25. Question: can 2PP authenticate users? • Is 2PP secure using a password for the key k? • Problems: • Passwords are not uniformly distributed • Dictionary attack: try common passwords • Later: Password-based authentication http://AmirHerzberg.com

  26. Authenticating messages • Include messages mA, mBin MAC • Also add flow number (2 or 3) – why? • To authenticate many messages (in order): • Add sequence numbers • Can use same nonces for multiple messages http://AmirHerzberg.com

  27. Request-Response Authentication ? • How to authenticate request-response flows? • To authenticate response: attach MACk(mB,N) • Where N is challenge sent with request • Does not prevent re-play / reordering of requests • Solution 1: use 2PP… • But server (Bob) must save Nb – open to Denial of Service! http://AmirHerzberg.com

  28. Solution 2: Time-Stamp Authentication • To prevent replay, add time: MACk(request,N,time) • Server remembers N for `acceptable time window` • Exercise: details (pseudo-code) • Used e.g. in Kerberos (and windows) • Requires sync clocks; state only for valid requests • What if clocks may be out of sync (e.g. web service)? Request, N, MACk(Request, N, time) Response, MACk(Response, N) Server Client http://AmirHerzberg.com

  29. Sol. 3: Stateless Authenticate with Cookie • Goal: authentication of requests (and responses)… • Without sync clocks and stateless server • Assuming bounded delay • Solution 3: `stateless 2PP`: server calculates nonce • Use server-only key k’ • Cookie nonce: Nb=MACk’(Time||A||Na) A, N a N , MAC (N , N , 2 , A||B ) Alice Bob b k a b ) req , MAC (N , N , 3 , req k a b [add response] http://AmirHerzberg.com

  30. Key Distribution Center (KDC) • KDC: shares keys with all (kA, kB…) • Goal: help parties (A, B) establishkAB • Ticket: encrypted, authenticated kAB • Using kA, kB… • KDC  TGS (Ticket Granting Server) [Kerberos] • Time-based: limit `ticket` time, stateless KDC Client (Alice) KDC/TGS Server (Bob) http://AmirHerzberg.com

  31. Authentication and Encryption • Usually to secure communication we need: • Encryption – for confidentiality • Message authentication – for integrity • Standard solution: use both MAC and encrypt • Some works on combined Authentication (MAC) and Encryption, or on EDC + Encryption, for efficiency • Questions: • Which keys to use for Encryption, MAC? • Can we use same keys for both? • Must we use two independent keys (double key length)? • How to combine MAC, encryption? http://AmirHerzberg.com

  32. Combining MAC and Encryption • Use both Encrypt and MAC to protect confidentiality and integrity • How to combine? • SSHv1 authenticates and encrypts (A&E): • C=Enc(m), A=MAC(m), send(C,A) • Not secure… Why? MAC may expose (some of) m. • SSL authenticates, then encrypts (AtE): • A=MAC(m), C=Enc(m,A), sendC • IPSEC encrypts, then authenticates (EtA): • C=Enc(m), A=MAC(C), send(C,A) • Which is better? • Same key or separate keys? http://AmirHerzberg.com

  33. Example: CBC A&E with same key • CBC-Ek(m;IV) || CBC-MACk(IV||m) • CBC encrypt and MAC, same key  very efficient! • m=m[1]||…||m[l] • Encryption: c = CBC-Ek(m;IV) c[0]||c[1]||…||c[l] = IV||…Ek(c[l-1] m[l] • MAC:a=CBC-MACk(IV||m)=Ek(c[l])=Ek(Ek(c[l-1] m[l])) • MAC will be valid for every c’ s.t.: c’[l]=c[l] •  Insecure! Use different keys for MAC, E… • Also: A&E is not secure…. A secure MAC may still leak information on input http://AmirHerzberg.com

  34. Keys for MAC + Encryption • Conclusion: better not use same key for authentication and MAC • Easy (contrived) examples also for AtE, EtA • Must the two keys be independent? • Some overhead of double key length • Kerberos V5: kmac:=keF0F0…F0 • Exercise: demonstrate E,MAC where this fails • Better: use pseudo-random keys • kmac:= PRFk(`MAC’) • kenc:= PRFk(‘Encrypt’) • Can input time, identities to input of PRF, e.g. to prevent replay http://AmirHerzberg.com

  35. Authentication and Encryption • SSL authenticates, then encrypts (AtE): • A=MAC(m), C=Enc(m,A), sendC • IPSEC encrypts, then authenticates (EtA): • C=Enc(m), A=MAC(C), send(C,A) • Encrypt then Authenticate (EtA) is better: • Provably CCA-Secure [KL, CK01] • Reject unauthenticated messages w/o decryption • To foil `clogging` Denial of Service (DoS) attacks • [K01]: counterexample showing AtE can be insecure, assuming `feedback`: attacker knows if validation failed • AtE is provably secure for some (common) enc, auth pairs http://AmirHerzberg.com

  36. Advanced! Attack on Authenticate-then-Encrypt • Define the following cipher E based on One Time Pad (OTP) (or a pseudo-random generator): • Ek(x)=Transform(x)  k [bit-wise XOR] • Transform each bit of the plaintext to two bits: • Zero bits (0) are transformed to two zeros (00) • One bits (1) are transformed to (01) or (10) randomly • E indistinguishable under chosen plaintext attack • We show an attack on auth-then-encrypt when using E • Attack: flip first two bits of ciphertext. • If authentication is still valid, first plaintext bit is 1 • If authentication fails, first plaintext bit is zero. http://AmirHerzberg.com

  37. Compress, Encrypt, Authenticate, Code Message • Encrypt then Auth(EtA) • Detect malicious as well as accidental changes • Prevent CCA • Other variations: • Combined `AuthEncrypt` • EDC-then-encrypt or MAC-then-encrypt: with appropriate functions • Motivations: efficiency, legacy implementations Compress Plaintext Encrypt Ciphertext MAC Ciphertext tag Code Ciphertext ECC tag http://AmirHerzberg.com

  38. Conclusion • MAC –Message Authentication Code • Sender appends `tag` (MAC) to message, recipient verifies tag using shared secret key • HMAC – standard, fast, hash based MAC • Use MAC to authenticate communication • Add identities, flow #, challenge (or time) • Next: how to use (shared-key) encryption and authentication to make `secure channel/tunnel` across the Internet http://AmirHerzberg.com

More Related