IS511 Introduction to Information Security Lecture 4 Cryptography 2 Yongdae Kim

Digital Signature WJ Clinton Integrity Authentication Non-repudiation I did not have intimate relations with that woman,…, Ms. Lewinsky WJ Clinton

Digital Signature with Appendix Schemes with appendix Requires the message as input to verification algorithm Rely on cryptographic hash functions rather than customized redundancy functions DSA, ElGamal, Schnorr etc. More commonly used

Digital Signature with Appendix M Mh S SA,k h m mh s* An entity A should obtain a public and private key. A should select an element k if the algorithm is randomized. Compute h(m) mapping m to the hash value space and apply the signing algorithm using A’s private key on this value to obtain s*. A’s signature for m is s* which are both made available to entities which may wish to verify the signature Verification involves obtaining A’s authentic public key VA, compute h(m) and apply the verification algorithm to h(m) and s*, if this results in true the signature is valid. If it results in false, the signature is invalid. Mh x S u 2{True, False} VA s* = SA,k(mh) u = VA(mh, s*)

Authentication How to prove your identity? Prove that you know a secret information When key K is shared between A and Server A  S: HMACK(M) where M can provide freshness Why freshness? Digital signature? A  S: SigSK(M) where M can provide freshness Comparison?

Encryption and Authentication EK(M) Redundancy-then-Encrypt: EK(M, R(M)) Hash-then-Encrypt: EK(M, h(M)) Hash and Encrypt: EK(M), h(M) MAC and Encrypt: Eh1(K)(M), HMACh2(K)(M) MAC-then-Encrypt: Eh1(K)(M, HMACh2(K)(M))

Challenge-response authentication Alice is identified by a secret she possesses Bob needs to know that Alice does indeed possess this secret Alice provides response to a time-variant challenge Response depends on both secret and challenge Using Symmetric encryption One way functions

Challenge Response using SKE Alice and Bob share a key K Taxonomy Unidirectional authentication using timestamps Unidirectional authentication using random numbers Mutual authentication using random numbers Unilateral authentication using timestamps Alice  Bob: EK(tA, B) Bob decrypts and verified that timestamp is OK Parameter B prevents replay of same message in B  A direction

Challenge Response using SKE Unilateral authentication using random numbers Bob  Alice: rb Alice  Bob: EK(rb, B) Bob checks to see if rb is the one it sent out Also checks “B” - prevents reflection attack rb must be non-repeating Mutual authentication using random numbers Alice  Bob: EK(ra, rb, B) Bob  Alice: EK(ra, rb) Alice checks that ra, rb are the ones used earlier

Challenge-response using OWF Instead of encryption, used keyed MAC hK Check: compute MAC from known quantities, and check with message SKID3 Bob  Alice: rb Alice  Bob: ra, hK(ra, rb, B) Bob  Alice: hK(ra, rb, A)

Key Establishment, Management Process to whereby a shared secret key becomes available to two or more parties Subdivided into key agreement and key transport. Key management The set of processes and mechanisms which support key establishment The maintenance of ongoing keying relationships between parties

Kerberos vs. PKI vs. IBE Still debating  Let’s see one by one!

Kerberos (cnt.) T A B EKBT(k, A, L): Token for B EKAT(k, NA, L, B): Token for A L: Life-time NA? A, B, NA EKBT(k, A, L), EKAT(k, NA, L, B) Ek(A, TA, Asubkey): To prove B that A knows k TA: Time-stamp Ek(B, TA, Bsubkey): To prove A that B knows k EKBT(k, A, L), Ek(A, TA, Asubkey) A B Ek(TA, Bsubkey)

Kerberos (Scalable) T (AS) G (TGS) A B EKGT(kAG, A, L), EKAT(kAG, NA, L, G) A, G, NA EKGT(kAG, A, L), EkAG(A, TA), B, NA’ EKAG(kAB, NA’, L, B), EkGB(kAB, A, L, NA’), B, NA’ EKGB (kAB, A, L, NA’), EkAB(A, TA’, Asubkey) A B Ek(TA’, Bsubkey)

Public Key Certificate Public-key certificates are a vehicle public keys may be stored, distributed or forwarded over unsecured media The objective make one entity’s public key available to others such that its authenticity and validity are verifiable. A public-key certificate is a data structure data part cleartext data including a public key and a string identifying the party (subject entity) to be associated therewith. signature part digital signature of a certification authority over the data part binding the subject entity’s identity to the specified public key.

CA a trusted third party whose signature on the certificate vouches for the authenticity of the public key bound to the subject entity The significance of this binding must be provided by additional means, such as an attribute certificate or policy statement. the subject entity must be a unique name within the system (distinguished name) The CA requires its own signature key pair, the authentic public key. Can be off-line!

ID-based Cryptography No public key Public key = ID (email, name, etc.) PKG Private key generation center SKID = PKGS(ID) PKG’s public key is public. distributes private key associated with the ID Encryption: C= EID(M) Decryption: DSK(C) = M

Discussion (PKI vs. Kerberos vs. IBE) On-line vs. off-line TTP Implication? Non-reputation? Revocation? Scalability? Trust issue?

Point-to-Point Key Update Key Transport with one pass A  B: EK(rA) Implicit key authentication Additional field timestamp, sequence number: freshness redundancy: explicit key authentication, message modification target identifier: prevent undetectable message replay Hence A  B: EK(rA, tA, B) Mutual authentication: B  A: EK(rB, tB, A): K = f(rA, rB) Key Transport with challenge-response B  A: nB : for freshness A  B: EK(rA, nA, nB, B) B  A: EK(rB, nB, nA, A) Cannot provide PFS Authenticated Key Update Protocol A  B: rA B  A: (B, A, rA, rB), hK(B, A, rA, rB) A  B: (A, rB), hK(A, rB) W = h’K’(rB)

Key Transport using PKC Needham-Schroeder Algorithm A  B: PB(k1, A) B  A: PA(k2, B) A  B: PB(k2) Properties: Mutual authentication, mutual key transport Modified NS A  B: PB(k1, A, r1) B  A: PA(k2, r1, r2) A  B: r2 Removing third encryption

Key Transport using PKC Needham-Schroeder Algorithm A  B: PB(k1, A) B  A: PA(k1, k2, B) A  B: PB(k2) Modified NS A  B: PB(k1, A, r1) B  A: PA(k2, r1, r2) A  B: r2 Removing third encryption Encrypting signed keys A  B: PB(k, tA, SA(B, k, tA)) Data for encryption is too large Encrypting and signing separately A  B: PB(k, tA), SA(B, k, tA) Acceptable only if no information regarding plaintext data can be deduced from the signature Signing encrypted keys A  B: tA, PB(A, k), SA(B, tA, PB(A, k)) Prevent the above problem Can provide mutual authentication

Combining PKE and DS Assurances of X.509 strong authentication identity of A, and the token received by B was constructed by A the token received by B was specifically intended for B; the token received by B has “freshness” the mutual secrecy of the transferred key. X.509 strong authentication DA=(tA, rA, B, data1, PB(k1)), DB=(tB, rB, A, rA, data2, PA(k2)), A  B: certA, DA, SA(DA) B  A: certB, DB, SB(DB) Comments Since protocol does not specify inclusion of an identifier within the scope of the encryption PB within DA, one cannot guarantee that the signing party actually knows (or was the source of) plaintext key

Attack strategies and classic flaws “man-in-the-middle” attack on unauthenticated DH Reflection attack Original protocol A  B : rA B  A : Ek(rA, rB) A  B : rB Attack A  E : rA E  A : rA : Starting a new session A  E : Ek(rA, rA’) : Reply of (2) E  A : Ek(rA, rA’) : Reply of (1) A  E : rA’ prevented by using different keys for different sessions

Attack strategies and classic flaws Interleaving attacks To provide freshness and entity authentication Flawed protocol A  B : rA B  A : rB, SB(rB, rA, A) A  B : rA’, SA(rA’, rB, B) Attack E  B : rA B  E : rB, SB(rB, rA, A) E  A : rB A  E : rA’, SA(rA’, rB, B) E  B : rA’, SA(rA’, rB, B) Due to symmetric messages (2), (3)