IS511 Introduction to Information Security Lecture 4 Cryptography 2

1. IS511Introduction to Information Security Lecture 4Cryptography 2 Yongdae Kim

2. Recap • http://syssec.kaist.ac.kr/~yongdaek/courses/is511/ • E-mail policy • Include [is511] • Profs + TA: IS511-prof@gsis.kaist.ac.kr • Profs + TA + Students: IS511@gsis.kaist.ac.kr • Text only posting, email! • Proposal: English only • Homework 1due

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

4. 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 Bprevents replay of same message in B  A direction

5. 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 • Bob  Alice: rb • Alice  Bob: EK(ra, rb, B) • Bob  Alice: EK(ra, rb) • Alice checks that ra, rb are the ones used earlier

6. 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)

7. Key Establishment, Management • Key establishment • 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

8. Kerberos vs. PKIvs. IBE • Still debating  • Let’s see one by one!

9. A, B, NA EKBT(k, A, L), EKAT(k, NA, L, B) EKBT(k, A, L), Ek(A, TA, Asubkey) Ek(TA, Bsubkey) Kerberos (cnt.) T • EKBT(k, A, L): Token for B • EKAT(k, NA, L, B): Token for A • L: Life-time • NA? • 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 B A

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

11. 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.

12. 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!

13. 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

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

15. 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)

16. 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 • Algorithm • A  B: PB(k1, A, r1) • B  A: PA(k2, r1, r2) • A  B: r2 • Removing third encryption

17. Needham-Schroeder Algorithm A  B: PB(k1, A) B  A: PA(k1, k2, B) A  B: PB(k2) Modified NS Algorithm 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 Key Transport using PKC

18. 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

19. 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

20. 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)