lecture 11
play

Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key - PDF document

Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key Distribution Center (KDC) or Trusted Third Party (TTP) K(X) = Encryption of X with key K KDC generates fresh K Alice Bob obtains K and Obtains knows to use as a K Msg3: K B


  1. Lecture 11 Protocols (Continued) Chapters 9 and 11 in KPS 1 Key Distribution Center (KDC) or Trusted Third Party (TTP) K(X) = Encryption of X with key K KDC generates fresh K Alice Bob obtains K and Obtains knows to use as a K Msg3: K B (A,K) key for communicating with Alice • Alice and Bob communicate using K as a short-term ( session) key for encryption and/or data integrity • Note: • Msg2 is not tied to Msg1 • Msg1 is possibly old • Msg2 is possibly old and so is Msg3 • Bob and Alice don’t authenticate each other! 2 1

  2. A Typical Key Distribution Scenario E K [X] = Encryption of X with K KDC (1) Request, B, N 1 (2) E Ka [ K s , Request, N 1 , E Kb (K s ,A) ] (3) E Kb [K s , A] A (4) E Ks [A, N 2 ] B (5) E Ks [f(N 2 )] Notes: •Msg2 is tied to Msg1 •Msg2 is fresh/new •Msg3 is possibly old * •Msg1 is possibly old (KDC doesn’t authenticate Alice) •Bob authenticates Alice •Bob authenticates KDC 3 •Alice DOES NOT authenticate Bob Public Key Distribution General schemes: • Public announcement (e.g., in a newsgroup or email message) • Can be forged • Publicly available directory • Can be tampered with • Public-key certificates (PKCs) issued by trusted off-line Certification Authorities (CAs) 4 2

  3. Certification Authorities • Certification authority (CA): trusted, highly secure (physically and electronically) component • Issues public key certificates; each binds a public key to a specific entity • Each entity (user, host, etc.) registers its public key with CA. • Bob provides “proof of identity” to CA. • CA creates public key certificate binding Bob’s ID/name to this public key. • Certificate containing Bob’s public key is signed by CA: CA says: “this is Bob’s public key” Bob’s digital PK public signature B key PK B certificate for Bob’s CA public key, signed by Bob’s private SK CA key identifying CA information 5 Certification Authority • When Alice wants to get Bob’s public key: • Get Bob’s certificate (from Bob or elsewhere) • Using CA’s public key verify the signature on Bob’s certificate • Check for expiration • Check for revocation (we’ll talk about this later) • Extract Bob’s public key Bob’s PK B digital Public Key signature PK B CA Public PK CA Key 6 3

  4. A Certificate Contains • Serial number (unique to issuer) • Info about certificate owner, including algorithm and key value itself (not shown) • info about certificate issuer • valid dates • digital signature by issuer 7 A Sample Certificate (1/2) 8 4

  5. A Sample Certificate (2/2) 9 Back to Protocols 10 5

  6. Needham-Schroeder Protocol (1978): First Distributed Security Protocol {X} K = Encryption of X with key K 1. A  T: A, B, N A 2. T  A: {N A , B, K, {K, A} KB } KA 3. A  B: {K, A} KB 4. B  A: {N B } K KDC 5. A  B: {N B -1} K 2 1 3 Alice Bob 4 B 5 11 Security? Denning-Sacco Attack: suppose Eve recorded an old protocol session for which she somehow knows the session key K ‘ : A  T: 1. A, B, N A T  A: {N A , B, K ’ , {K ’ , A} KB } K A 2. A  B: {K ’ , A} KB 3. ----------------------------------------------------- At a later time: E  B: {K ’ , A} KB 1. B  E: {N B } K ’ 2. E  B: {N B -1} K ’ 3. 12 6

  7. Fixing the Attack • Bob has no guarantees about freshness of the message in step 3. • Eve exploits this to impersonate Alice to Bob - old session keys are useful. • Can be fixed by adding timestamps: • Limits usefulness of old session keys • Eve ’ s attack becomes: 3: E  B: {K ’ , T ’ , A} KB attack is now thwarted because T ’ is stale 13 PK-based Needham-Schroeder Protocol TTP KDC 3. [N a , A] PKb Alice A Bob B 6. [N a , N b ] PKa 7. [N b ] PKb • CERT B = Message 2, CERT A = Message 5 • PK A : Alice’s public key, PK B : Bob’s public key • SK T : TTP’s secret (private) key used for signing [X] K = Encryption of • Everyone knows TTP’s public key PK T X with key K 14 7

  8. Another Attack • 1, 2, 4, 5: Delivery of public key • Does not guarantee freshness of the public key How to solve it? • Timestamp in messages 2 and 5 or challenges in messages 1&2 and 4&5 • Public Key Certificate: assign expiration time/data to each certificate (messages 2 and 5) 15 PK-based Denning-Sacco Attack TTP TTP Cert A ={PK A ,A} SKT KDC Cert B ={PK B ,B} SKT Cert C ={PK C ,C} SKT 1. A, B 2. Cert A , Cert B 3. Cert A ,Cert B, [ {K AB ,T A } SKA ] PKB Bob A B Alice B 4. Secure communication with K AB Bob impersonates Alice Thinks she is talking to A 3’. Cert A ,Cert C, [ {K AB ,T A } SKA ] PKC Bob B C B 4’. Secure communication with K AB 16 8

  9. Lowe’s Attack (Impersonation by Interleaving) Original Attack: E impersonates A 3. A  B: [N a , A] PKb 1.3. A  E: [N a , A] PKe 6. B  A: [N a , N b ] PKa 2.3. E  B: [N a , A] PKb 7. A  B: [N b ] PKb 2.6. B  E: [N a ,N b ] PKa 1.6. E  A: [N a ,N b ] PKa 1.7. A  E: [N b ] PKe Fix 2.7. E  B: [N b ] PKb 3. A  B: [N a , A] PKb 6. B  A: [B, N a , N b ] PKa 7. A  B: [N b ] PKb 17 Fixed PK-based Needham-Schroeder Protocol TTP KDC 3. [N a , A] PKb Alice A Bob B 6. [B, N a , N b ] PKa 7. [N b ] PKb 18 9

  10. Reflection Attack and a Fix • Original Protocol A  B : 1. r A B  A : 2. { r A , r B } K A  B : 3. r B • Attack A  E : 1. r A E  A : 2. r A : Starting a new session A  E : 3. { r A , r A ’ } K : Reply to (2) E  A : 4. { r A , r A ’ } K : Reply to (1) A  E : 5. r A ’ Solutions? • Use 2 different uni-directional keys k ” (A  B) and k’ (B  A) • Remove symmetry (direction, msg identifiers) 19 Interleaving Attacks • Protocol for Mutual Authentication A  B : 1. A, r A, B  A : 2. r B , { r B , r A , A } SKB A  B : 3. r A ’, { r A ’, r B , B } SKA • Attack E  B : 1. A, r A B  E : 2. r B , { r B , r A , A } SKB E  A : 3. B, r B A  E : 4. r A ’, { r A ’, r B , B } SKA E  B : 5. r A ’, { r A ’, r B , B } SKA • Attack due to symmetric messages (2), (3) 20 10

  11. Lessons learned? • Designing secure protocols is hard. There are many documented failures in the literature. • Good protocols are already standardized (e.g., ISO 9798, X.509, …) – use them! • In other words, don’t invent your own! • The problem of verifying (proving) protocol security gets much harder as protocols get more complex: more parties, messages and rounds. 21 If interested to learn further, read this paper: “ Programming Satan ’ s Computer ” by R. Anderson and R. Needham available at: http://www.cl.cam.ac.uk/~rja14/Papers/satan.pdf 22 11

  12. Secure Protocol Examples 23 Authenticated Public-Key-based Key Exchange (Station-to-Station or STS Protocol) Choose random v = v y a mod p Choose a random w, Compute CERT , y , SIG = w Compute K ( y ) mod p bob b bob ba a = v = K ( y ) mod p w y a mod p ab b b = Bob SIG { y , y } = alice SIG { y , y } bob b a CERT alice SIG , alice a b alice 24 12

  13. x.509 Authentication & Key Distribution Protocols One-msg { 1 , t , r , B , other , [ K ] } A  B a a a ab SK PK A B { 2 , t , r , B , other , [ K ] } a a a ab SK PK A Two-msg B A  B { 2 , t , r , A , r , other , [ K ] } b b a b ba SK PK B A { 3 , t , r , B , other , [ K ] } a a a ab SK PK A B Three-msg { 3 , t , r , A , r , other , [ K ] } A  B b b a b ba SK PK B A { 3 , r } b SK A 25 13

Recommend


More recommend