Chapter 3 Basic Protocols 3 1 Key

Chapter 3 Basic Protocols

3. 1 Key Exchange n n Session Key - Why? Key Exchange with Symmetric Cryp. KDC request EKA(KAB), EKB(KAB) KDC : Trust? , Bottleneck, Security of KDC

n Key Exchange with Public-Key Cypt. u Public keys from KDC KBP EK (KAB) BP

n Man-in-the-Middle Attack u u Public keys by communication Attack by Mallory since there is no verification of each other. Mallory 2. KMP 4. KMP Alice 1. KAP 5. EKMP(m) 3. KBP 6. EKMP(m) Bob

n Interlock Protocol(Rivest and Shamir)-I u Half of the message is useless without the other half! that half of (EKBP(m)) = half of (EKBP(DKMR (EKMP(m))) u Note 1. KAP 3. First half of (EKBP(m)) 5. Last half of (EKBP(m)) Alice 2. KBP Bob 4. First half of (EKAP(m)) 6. Last half of (EKAP(m))

n Interlock Protocol(Rivest and Shamir)-II 1. KAP KMP 3. First half of (EKMP(m)) EKBP( DKMR( First half of (EKMP(m)) ) Alice 2. KMP KBP 4. First half of (EKMP(m)) the first half of EKBP(m) Bob

n Key Exchange with Digital Signatures u Certificate of one’s public key u Hard to impersonate someone (DB attack) n Key and Message Transmission 1. EKAB(m), EKBP(KAB) Alice n Bob Key and Message Broadcasting

3. 2 Authentication n Using One-way Functions Server Username , Ik =“I’m Alice” Request for Password Pk Client Ik Attack on Password Pk Username = Ik h p wiretapping p guessing on password - online / offline guessing - short password, no password, username=password p attack on password file Ik : h( Pk )

q UNIX Password SYSTEM q Password verification Password file A : h( password. A ) B : h( password. B ) C : h( password. C ) B, password. B h ( password. B ) h ? =

u SKEY(One-Time Password) q F Use hi(r), and host check h(hi(r))=hi+1(r) Identity x. K Server Request for Password x. K-1 Client q No shared secret between Client and Server q Using One-way Function h( ) q Select x 0 and xi = h(xi-1) for i = 1, 2, 3, . . k q password xk is a user identity for next access { k access tickets }

n Using Public-key Crypt u Eve may listen to Alice’s login sequence, or have access to the memory of the processor 1. R : Challenge 2. EKAR(R) : Response Alice u HOST Step 2 may be generated automatically, so anyone can get the signature of Alice on m F Both may generate random numbers

n Mutual Authentication Using the Interlock Protocol u Shared secret PA and PB 1. EKAB(PA) Alice 2. EKAB(PB) u Man-in-the-middle public keys) Bob Attack (in trading

n SKID u Using MAC 1. RA 3. MACKAB(RB, A) Alice n 2. RB, MACKAB(RA, RB, B) Bob Message Authentication Use a Signature u With symmetric cryp. , need TTP to prove it to the third party u

3. 3 Authentication and Key Exchange n Confidentiality and timeliness u u Confidentiality : To prevent masquerade and compromise of session keys Timeliness : to protect replay attack F F F Sequences – overhead to keep track of numbers Timestamps – accepted with allowable time windows, should not be used for connectionoriented applications because of sync. Overhead Challenge/Response – nonce, should not be used for connectionless applications because of “handshake” overhead

3. 3 Authentication and Key Exchange n Wide-Mouth Frog (1) Alice --> Trent : A, EA(TA, B, K) (2) Trent --> Bob : EB(TB, A, K) u User generates K? n Yahalom (1) Alice --> Bob : A, RA (2) Bob --> Trent : B, EB(A, RB) (3) Trent --> Alice : EA(B, K, RA, RB), EB(A, K) (4) Alice --> Bob : EB(A, K), EK(RB) (5) Bob confirms RB u Receiver Bob first contacts Trent!

n Needham-Schroeder (1) Alice --> Trent : A, B, RA (2) Trent --> Alice : EA(RA, B, K, EB(K, A)) (3) Alice --> Bob : EB(K, A) Handshake, or (4) Bob --> Alice : EK(RB) Key confirmation (5) Alice --> Bob : EK(RB- 1) u All nonce are used to prevent replay attack in the form of challenge: but vulnerable Mallory with old session key K (3) Mallory --> Bob : EB(K, A) (4) Bob --> Alice(Mallory) : EK(RB) (5) Mallory --> Bob : EK(RB- 1) u To prevent this, use EB(K, A, T) in (2) u F Even with knowledge of K, Step 3 detected as untimely

n Newman-Stubblebine To prevent suppress-replay attack (1) Alice --> Bob : A, RA (2) Bob --> Trent : B, RB, EB(A, RA, TB) (3) Trent --> Alice : EA(B , RA, K, TB), EB(A, K, TB), RB (4) Alice --> Bob : EB(A, K, TB), EK(RB ) Ticket u F F RA(RB ): assuring Alice(Bob) of timeliness EB(A, RA, TB) : request for issuing credentials to Alice. TB : Time limit on key’s use No sync. is needed (why? ) Re-authentication without Trent (3) Alice --> Bob : EB(A, K, TB), R’A (4) Bob --> Alice : R’B, EK( R’A) (5) Alice --> Bob : EK(R’B) u

n Kerberos q Trusted Third-Party stores all the passwords KERBEROS q Kerberos System from MIT gon User Lo Ticket ranting et G Tick Client Tick Se et G rant ing T ic icke ice G rv e t rant ic Gr ing T e an fo icke tin rt t he g Ti Cl c ie nt ket Se rv Serv Application Server Authentication Server (AS) Ticket Granting Server (TG)

Kerberos Alice’s Password K{Alice} Ticket-granting Ticket = EK 1(‘Alice’, K{Alice-TG}) EK{Alice}(K{Alice-TG}, Ticket-granting Ticket) Alice, Password Client ID = ‘Alice’ Authentication Server Ticket-granting Ticket EK {Alice-TG} ( Timestamp ) Service-granting Ticket EK{Alice-AS} ( Timestamp ) Service-granting Ticket = EK 2(‘Alice’, K{Alice-AS}) EK{Alice-TG}(K{Alice-AS}, Service-granting Ticket) Application Server (AS) Ticket Granting Server (TG)

n Denning-Sacco using public-key cryptography (1) Alice --> Trent : A, B (2) Trent --> Alice : ST(B, KB), ST(A, KA) (3) Alice --> Bob : EB(SA(K, TA)), ST(B, KB), ST(A, KA) u Bob can masquerade as Alice (1) Bob --> Trent : B, C (2) Trent --> Bob : ST(B, KB), ST(C, KA) (3) Bob --> Carol : EC(SA(K, TA)), ST(A, KA), ST(C, KC) u Use the following in (3) Alice --> Bob : EB(SA(A, B, K, TA)), ST(A, KA), ST(B, KB) u

3. 4 Formal Analysis n Method 1 : Use general spec. language and verification tools u n Method 2 : Use expert system u u n Check if a protocol reaches an undesirable state. What about unknown flaws? Method 3 : Logic Model for Knowledge and Belief u n Proving correctness is not equal to proving security BAN logic Method 4 : View the protocol as an algebraic system

3. 5 Multiple-Key PKC n Multiple-Key Distribution u u n Let S be the set of keys and let S 1, S 2 be a partition of S To encrypt, use S 1, and to decrypt, use S 2 (See Table 3. 2 in pp. 68) Broadcasting u u One key for each - Too many M’s (communication overhead!) One key for every combinations - Too many keys (huge user storage!) Use Multiple-key - need to know which subset? Various schemes proposed

3. 6 Secret Splitting n Split M into shares m 1, m 2, …. u u n Each share has no information of M M can be reconstructed using all shares Example (1) Trent generates One-Time Pad R and compute S = M XOR R. (2) Trent --> Alice : R (3) Trent --> Bob : S (4) Bob and Alice reconstruct M = S XOR R. u What if any share is lost?

3. 7 Secret Sharing n n (m, n)-threshold scheme u It is possible to construct a sharing scheme you can imagine With Cheaters u Valid member with invalid share F u Fail to reconstruct Reconstructing with Cheater F Cheater gets all m shares needed to reconstruct

n without Trent u n without Revealing the Shares u n n n reuse the shares Verifiable Secret Sharing Publicly Verifiable Secret Sharing with Prevention u n All members together create a secret without knowing the secret Use two share “yes” and “no” with Disenrollment u When one member is dispelled, activate a new scheme (? )

3. 8 Cryptographic Protection of DB n One Scheme Field 1 : Index h(last name) Field 2 : Elast(Information) u without last name, hard to find information u easy attack to construct whole DB