Chapter 11 Message Authentication and Hash Functions Authentication

Chapter 11 Message Authentication and Hash Functions Authentication Hash Function Digital Signature Kerberos More about authentication CNLab/University of Ulsan 1

Message Authentication Message v v allows receivers of a messages to identify its origin. makes it difficult for third parties to masquerade as someone else. Methods v v v authentication is a service that to provide authentication of a message. Encryption: only the holder of a secret key could have generated the message. Hash functions: generating another message that matches the hash is difficult. Message Authentication Codes (MAC): encrypted hash value using a secret key. CNLab/University of Ulsan 2

Authentication Using Encryption CNLab/University of Ulsan 3

Authentication Using Encryption All things decrypt! -> even garbage text sent by a malicious foe will decrypt to something. We need to reduce the chances of garbage decrypting to something useful. Before encrypting, compute a frame-check sequence. (CRC codes, …) Encrypt both the plaintext and its FCS. Garbage has little chance of decrypting to a correct FCS. It’s costly for both Alice and Bob when authenticating a large message: the whole message must be encrypted !!! CNLab/University of Ulsan 4

Hash Functions A hash H is a one-way function that operates on arbitrary-length message m, and returns a fixed-length value h. h = H(m) Given a message m, it is easy to compute H(m) Given h, it is impossible to compute m such that H(m)=h. Given specific m, it is impossible to find another message m’, such that H(m) = H(m’). => weak collision resistance Given a large set M, it’s difficult to find any pair (m i, mj) that hash to the same value. => strong collision resistance Hashes provide a fingerprint of m. CNLab/University of Ulsan 5

Digital Signatures Real signatures provide a number of features v Signature provides authenticity for a documents v Signatures are “hard” to forge v Signatures, as parts of the document, aren’t reusable. v Signatures are unalterable or erasable. v Signatures can’t be repudiated. In reality, there are ways around all of these for real signatures. CNLab/University of Ulsan 6

Signing with Hash Functions 1. Alice produces a one-way has of the document. A: h = H(D) 2. Alice encrypts the hash A: {h}KA- ; KA- : private key of Alice 3. Alice sends the document and the signed hash to Bob. A->B: D, {h}KA 4. Bob verifies by producing the same hash and decrypting the hash Alice sent. CNLab/University of Ulsan 7

Signing Documents with Private Keys 1. Alice encrypts the hash of the document with her private key. 2. Alice sends the document plus signed hash to Bob. 3. Bob hashes the document and compares the result to what he decrypted, thereby verifying the signature. - The digsig is authentic (the hashes match) - The digsig is unforgeable (as long as no one has the private key but Alice) - The digsig is not reusable (it’s a function of the document) - The signed doc is unalterable (the hashes wouldn’t match) - The document can’t be repudiated. CNLab/University of Ulsan 8

Bob attacks the notary Given a specific m, it is hard to find another message m’, such that H(m) = H(m’). Alice is a notary for Bob’s documents. For $5, Alice will sign anything Bob sends her. Bob has one “valid” document. Bob spends all day looking for another version of the document (with fraudulent info) that hashes to the same value. Bob places Alice’s encryption of the hash for the valid document with the fraudulent one. Bob has to search through 2 n messages. (2 n-1 on average); n is the length of H(m) CNLab/University of Ulsan 9

Birthday Attack Given a large set M, it’s difficult to find any pair (m i, mj) that hash to the same value. Alice is a notary for Bob’s documents. For $5, Alice will sign anything Bob sends her. Bob has many versions of the same “valid” document. Creates many versions of the fraudulent doc. There is a good chance that one pair will match up. Bob places Alice’s encryption of the hash for the valid document with the fraudulent one. Bob has to search through 2 n/2 messages on the average. CNLab/University of Ulsan 10

Birthday Paradox What is the min value of k such that the prob. is greater than 0. 5 that at least 2 people in a group of k people have the same birthday? Pr(365, k): the probability that there are duplicates in the group Pr(365, k) = 1 – Q(365, k), where Q(365, k) is the probability that there are no duplicates in the group N: the # of different ways that can have k values without duplicates v N = 365 x 364 x … x (365 -k+1) = Q(365, k) = N / (365)k Pr(365, k) = 1 – N / (365)k > 0. 5 n CNLab/University of Ulsan 365! (365 -k)! 1/2 -> k = 23 11

MD 5 Produces a 128 -bit message digest from a variable length message Processing steps - Process message in 512 -bit (32 16 -bit words) blocks - Append padding bits to be multiples of 512 -bit - Append length - Initialize MD buffer - Output: 128 bits CNLab/University of Ulsan 12

Authentication Password based authentication v The password file could be stolen! v An eavesdropper can sniff the password off the network. Authentication based on the source address is not good v IP spoofing is possible. Authentication based on biometrics : thumb prints, retinal scans Authentication using symmetric keys : Kerberos Authentication using asymmetric cryptosystem CNLab/University of Ulsan 13

Protecting the Password File Actual password is not stored -> one-way hashes of passwords are kept and are used for comparison. Other users can only read /etc/passwd. Only the “root” user can read the password hashes in the /etc/shadow password file. CNLab/University of Ulsan 14

Dictionary Attacks Finding a password for a specific account is hard. Instead, get the password file (even if it’s hashed passwords); Compute the one-way hashes of all the words in the dictionary, including common names for pets, and compare You won’t get every password, but you’ll get some, probably about 40%. CNLab/University of Ulsan 15

Protecting Passwords over the network If Alice just sends the password, anyone can read it. In promiscuous mode, ethernet cards will pass to the operating system all received IP packets. Attackers can use a “packet-sniffer”, like sniff-it or tcpdump on Unix, to read all packets across your network. Such programs require root privileges. CNLab/University of Ulsan 16

Authentication Using OTPs Challenge-response method Ahead of time, Alice and Bob agree upon a secret, shared key (or a secret function). Alice requests a log-in challenge from Bob (the remote computer) : A->B: request Bob v sends Alice a nonce N (challenge): B->A: N A nonce is a random string used only once ever. Alice responds (response) : A->B: {N}KAB (or A->B: f(N)) Changing nonces for each access prevents replay attack. CNLab/University of Ulsan 17

Authentication Using OTPs S/Key method Ahead of time, Alice and Bob generate a list of passwords from a chosen pass-phrase, and share the list. When accessing Bob, Alice uses each password in the list only once one-by-one. Bob checks the password using the password list. Changing passwords for each access prevents replay attack. CNLab/University of Ulsan 18

Key Exchange Protocols: Needham-Schroeder T is the Key Distribution Center (KDC) A is Alice, B is Bob, M is Mallony. KTB (KTA) : session key between KDC and B (A). N 1 and N 2 are nonces. KAB is the session key the KDC generates. A->T: A, B, N 1 T->A: {KAB, B, N 1, {KAB, A}KKB}KTA A->B: {KAB, A}KKB B->A: {N 2}KAB A->B: {N 2+1}KAB CNLab/University of Ulsan M stores the entire session and works on the key, and catches KAB. Later. . . M->B: {KAB, A}KKB B->A: {N 3}KAB M->B: {N 3+1}KAB 19

Using Timestamp t is a timestamp(current time), everyone has synchronized clocks. A-> T: A, B T->A: {KAB, B, t, { KAB, A, t }KTB}KTA A->B: { KAB, A, t }KKB B->A: {N 2}KAB A->B: {N 2+1}KAB CNLab/University of Ulsan M stores the entire session and works on the key, and catches KAB. Later. . . M->B: {KAB, A, t}KKB B->A: ticket is old !!! 20

Authentication using Kerberos 1. C -> AS: C, TGS, time 1, N AS 1 TGS 2 C 2. AS -> C: {KC, TGS, lifetime 1, N, …}KC, {TC, TGS}KTGS -- C : compute KC , and recover KC, TGS 3. C -> TGS: S, {TC, TGS}KTGS, {C, time 2}KC, TGS 3 4. TGS -> C: {S, KC, S, lifetime 2, {TC, S}KS}KC, TGS 4 5 6 S AS: authentication server TGS: ticket granting server S: application server CNLab/University of Ulsan -- C : recover KC, S and {TC, S}KS 5. C -> S: {TC, S}KS, {C, time 3}KC, S -- S : recover KC, S from {TC, S}KS 6. S -> C: {time 3+1}KC, S KC : f(passwd. C) {TC, TGS}KTGS : {C, TGS, KC, TGS, lifetime 1}KTGS {TC, S}KS : {C, S, KC, S, lifetime 2}KS 21

Key Exchange with Public-Keys 1. Alice gets Bob’s public key from a Key Distribution Center (KDC), T. T->A: KKUb 2. Alice generates a random session key, encrypts it using Bob’s public key, and sends it to Bob. A->B: {KAB}KKUb 3. Bob decrypts the message using his private key. B: KAB 4. The session begin, both Alice and Bob using the same session key. => this has serious replay attack problems CNLab/University of Ulsan 22

Man-in-the-Middle Attack 1. Alice sends Bob her public Key; Mallory intercepts and sends Bob his own public key. 2. Mallory also intercepts when Bob sends his key to Alice. 3. When Alice sends a message encrypted with “Bob’s” key, Mallory intercepts, decrypts, alters, and re-encrypts with the correct key. -> needs a secure way of obtaining other’s public keys CNLab/University of Ulsan 23

More : One Way Authentication Designing security protocols is hard Suspicious One party should generate a challenge way authentication using a shared secret I’m Alice v v f(KAB, R) Bob Alice v R KAB : shared secret b/w Alice and Bob <Proto 11 -1> Authentication is not mutual An eavesdropper can mount an off-line password guessing attack Someone who reads the database at Bob can impersonate Alice CNLab/University of Ulsan 24

One Way Authentication Variant of <Proto 11 -1> I’m Alice v R Bob Alice v E(KAB, R) <Proto 11 -2> The cryptography must be reversible If R is a recognizable quantity (e. g. includes timestamp), Alice can authenticate Bob; Bob knows a shared secret CNLab/University of Ulsan 25

One Way Authentication Variant of <Proto 11 -1> v v Bob Alice v I’m Alice, E(KAB, timestamp) <Proto 11 -3> More efficient: needs short messages and Bob does not need to keep any volatile state Bob and Alice must have reasonably synchronized clocks An eavesdropper can use E(KAB, timestamp) to impersonate Alice, if done within the acceptable clock skew CNLab/University of Ulsan 26

Mutual Authentication Mutual authentication based on a shared secret I’m Alice R 1 R 2 Bob Alice E(KAB, R 1) <Proto 11 -7> E(KAB, R 2) v The initiator should be the first to prove its identity v Inefficient: 5 messages fro authentication CNLab/University of Ulsan 27

Mutual Authentication Variant of <Proto 11 -7> I’m Alice, R 2 Bob Alice R 1, E(KAB, R 2) E(KAB, R 1) <Proto 11 -8> Reflection attack: Trudy initiates a first session (<Fig 1>), and initiates a new second session using R 1 (<Fig 2>) -> uses the reply from the second session and completes the first session I’m Alice, R 1 I’m Alice, R 2 R 3, E(KAB, R 1) <Fig 2> Bob <Fig 1> Trudy CNLab/University of Ulsan Bob Trudy R 1, E(KAB, R 2) 28

Mutual Authentication Fixing v v the problem of reflection attack Using different keys hardens the attack: (e. g. ) Alice -> Bob: KAB and Bob -> Alice: (KAB F 0 F 0 F 0 F 0) Using different types of challenges between from Bob to Alice and from Alice to Bob makes the attack difficult: (e. g. ) odd number from Bob to Alice and even number from Alice to Bob CNLab/University of Ulsan 29

Mutual Authentication Mutual authentication using public keys I’m Alice, E(KUBob, R 2) v v R 1 Bob Alice v R 2, E(KUAlice, R 1), <Proto 11 -12> How does each one obtain the other’s public key securely? Trudy can intervene the public key exchange: man-in-the-middle attack Needs a secure way of obtaining peer’s public key: PKI (public key infrastructure) CNLab/University of Ulsan 30

Mutual Authentication Mutual authentication using timestamps I’m Alice, E(KAB, timestamp) v Bob Alice v E(KAB, timestamp+1) <Proto 11 -13> Efficient: needs short messages and easy to add to existing protocols (request/response paradigm) Trudy impersonate Alice by eavesdropping E(KAB, timestamp+1) CNLab/University of Ulsan 31

Session Key Generation During mutual authentication, we establish a shared secret per-conversation key (session key) Messages are encrypted using the session key -> this limits the use of the master shared secret I’m Alice E(KAB, R) Bob Alice R <Proto 11 -14> Alice and Bob independently generates the session key CNLab/University of Ulsan 32

Session Key Generation Session key generation using a shared secret E(KAB, R) : it is transmitted during the authentication cannot be used !!! E(KAB, R+1) : Trudy record the entire communication after the authentication, and Trudy later can obtain the session key by impersonating Bob can decrypt the previous messages !!! R+1 E(KAB, R+1) Trudy as Bob CNLab/University of Ulsan Alice session key must not be E(KAB, X), where X can be guessed easily I’m Alice <Fig 1> 33

Session Key Generation Session key generation using a shared secret In general, the session key KS is generated by encrypting the challenge R using a key modified from KAB : (e. g. ) KAB+1, KAB F 0 F 0 F 0 F 0, … KS = E(KAB+1, R) CNLab/University of Ulsan 34

Session Key Generation Session key generation in the two-way public key based authentication One-side (say, Alice) chooses a session key KS randomly, encrypt it with the other’s (Bob) public key, and sends to Bob: KS = R => Trudy can hijack the conversation (impersonating Alice), and sends Bob by picking her own random R’: E(KUBob, R’) CNLab/University of Ulsan 35

Session Key Generation Session key generation in the two-way public key based authentication Alice choose a random R, encrypt it with Bob’s public key and signs the result, and sends to Bob: E(KRAlice, (E(KUBob, R)) KS = R Alice chooses R 1 and sends E(KUBob, R 1) to Bob, also Bob chooses R 2 and sends E(KUAlice, R 2) to Alice: => KS = R 1 R 2 CNLab/University of Ulsan 36