1. Authentication

2. Goal: Bob wants Alice to “prove” her identity to him Protocol ap1.0: Alice says “I am Alice” Failure scenario?? “I am Alice”

3. Authentication Goal: Bob wants Alice to “prove” her identity to him Protocol ap1.0: Alice says “I am Alice” in a network, Bob can not “see” Alice, so Trudy simply declares herself to be Alice “I am Alice”

4. Authentication: another try Protocol ap2.0: Alice says “I am Alice” in an IP packet containing her source IP address Failure scenario?? “I am Alice” Alice’s IP address

5. Authentication: another try Protocol ap2.0: Alice says “I am Alice” in an IP packet containing her source IP address Trudy can create a packet “spoofing” Alice’s address “I am Alice” Alice’s IP address

6. Authentication: another try Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it. Failure scenario?? “I’m Alice” Alice’s IP addr Alice’s password OK Alice’s IP addr

7. Authentication: another try Protocol ap3.0: Alice says “I am Alice” and sends her secret password to “prove” it. playback attack: Trudy records Alice’s packet and later plays it back to Bob “I’m Alice” Alice’s IP addr Alice’s password OK Alice’s IP addr “I’m Alice” Alice’s IP addr Alice’s password

8. Authentication: yet another try Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it. Failure scenario?? “I’m Alice” Alice’s IP addr encrypted password OK Alice’s IP addr

9. Authentication: another try Protocol ap3.1: Alice says “I am Alice” and sends her encrypted secret password to “prove” it. record and playback still works! “I’m Alice” Alice’s IP addr encrypted password OK Alice’s IP addr “I’m Alice” Alice’s IP addr encrypted password

10. Authentication: yet another try Goal: avoid playback attack Failures, drawbacks? Nonce: number (R) used only once –in-a-lifetime ap4.0: to prove Alice “live”, Bob sends Alice nonce, R. Alice must return R, encrypted with shared secret key “I am Alice” R K (R) A-B Alice is live, and only Alice knows key to encrypt nonce, so it must be Alice!

11. Authentication: ap5.0 ap4.0 requires shared symmetric key can we authenticate using public key techniques? ap5.0: use nonce, public key cryptography “I am Alice” R Bob computes K (R) A - “send me your public key” K A + (K (R)) = R A - K A + and knows only Alice could have the private key, that encrypted R such that (K (R)) = R A - K A +

12. ap5.0: security hole Man (woman) in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice) I am Alice R T K (R) - Send me your public key T K + A K (R) - Send me your public key A K + T K (m) + T m = K (K (m)) + T - Trudy gets sends m to Alice encrypted with Alice’s public key A K (m) + A m = K (K (m)) + A - R

13. ap5.0: security hole Man (woman) in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice) Difficult to detect:  Bob receives everything that Alice sends, and vice versa. (so Bob and Alice can meet one week later and recall conversation)  problem is that Trudy receives all messages as well!

14. Chapter3 Message Authentication seriously

15. OUTLINE Approaches to Message Authentication Secure Hash Functions and HMAC

16. Authentication Requirements - must be able to verify that: 1. Message came from apparent source or author, 2. Contents have not been altered, 3. Sometimes, it was sent at a certain time or sequence. Protection against active attack (falsification of data and transactions)

17. Approaches to Message Authentication Authentication Using Conventional Encryption –Only the sender and receiver should share a key Message Authentication without Message Encryption –An authentication tag is generated and appended to each message Message Authentication Code –Calculate the MAC as a function of the message and the key. MAC = F(K, M)

19. One-way HASH function

20. Secret value is added before the hash and removed before transmission.

21. Secure HASH Functions Purpose of the HASH function is to produce a ”fingerprint. Properties of a HASH function H : 1.H can be applied to a block of data of any size 2.H produces a fixed length output 3.H(x) is easy to compute for any given x. 4.For any given block x, it is computationally infeasible to find x such that H(x) = h 5.For any given block x, it is computationally infeasible to find with H(y) = H(x). 6.It is computationally infeasible to find any pair (x, y) such that H(x) = H(y)

22. Simple Hash Function One-bit circular shift on the hash value after each block is processed would improve

23. Internet checksum: poor crypto hash function Internet checksum has some properties of hash function: üproduces fixed length digest (16-bit sum) of message üis many-to-one But given message with given hash value, it is easy to find another message with same hash value: I O U 1 0 0. 9 9 B O B 49 4F 55 31 30 30 2E 39 39 42 D2 42 message ASCII format B2 C1 D2 AC I O U 9 0 0. 1 9 B O B 49 4F 55 39 30 30 2E 31 39 42 D2 42 message ASCII format B2 C1 D2 AC different messages but identical checksums!

24. Message Digest Generation Using SHA-1

25. SHA-1 Processing of single 512- Bit Block

26. Other Secure HASH functions SHA-1MD5RIPEMD- 160 Digest length160 bits128 bits160 bits Basic unit of processing 512 bits Number of steps80 (4 rounds of 20) 64 (4 rounds of 16) 160 (5 paired rounds of 16) Maximum message size 2 64 -1 bits

27. HMAC Use a MAC derived from a cryptographic hash code, such as SHA-1. Motivations: –Cryptographic hash functions executes faster in software than encryptoin algorithms such as DES –Library code for cryptographic hash functions is widely available –No export restrictions from the US

28. HMAC Design Objectives To use available hash functions To allow for easy replaceability of the embedded hash function in case faster or more secure are found or required To preserve the original performance of the hash function To use and handle keys in a simple way To have a well-understood cryptographic analysis of the strength of the authentication mechanism

29. HMAC Structure