1 / 35

Recent developments in group key exchange

Recent developments in group key exchange. Mike Burmester Information Security Summer School 2005 Florida State University. Outline. 1 . Secure Communication 2. Key Distribution the Diffie-Hellman protocol variants, attacks authentication conference protocols

summer
Download Presentation

Recent developments in group key exchange

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Recent developments in group key exchange Mike Burmester Information Security Summer School 2005 Florida State University

  2. Outline • 1.Secure Communication • 2.Key Distribution • the Diffie-Hellman protocol • variants, attacks • authentication • conference protocols • 3. Public Key Certificates • trust-graphs • hierarchical vs horizontal structures • security • 4. Conclusion

  3. 1. Secure Communication message Sender (Alice) Receiver (Bob) Adversary Security issues • authenticity • privacy • denial of service, etc.

  4. Symmetric keys (privacy) Bob Alice plaintext ciphertext plaintext private channel E D SK SK • Security issue • How to distribute the secret key SK

  5. Public Keys (privacy) Alice Bob ciphertext plaintext plaintext E D SKB PKB Authentication channel f Security issues • It should be hard to compute SKB from PKB • How do we distribute PKB

  6. Public Keys (digital signatures) Bob Alice a m, sigSKAm m or r V S SKA PKA Authentication channel f Security issues • It should be hard to compute SKA from PKA • How to distribute PKA

  7. 2. Key Exchange protocols the Diffie-Hellman protocol Zp = {0,1,…,p-1}, p prime, g a generator of Zp* Alice’s Public Keygsa:0 <sa< p-1, private key sa Bob’s Public Keygsb:0 <sa< p-1, private key sb gsa mod p Alice Bob gsb mod p Key Exchanged:SK =gsasb mod p

  8. Security It should be hard to compute SK from PK. Freshness of keys If the same key is used many times then the security of the system may be undermined.

  9. What if 3 or more parties want to share a common secret key? A • Use DH to get: SKAB , SKBD , • SKBE , SKAC , SKCF . K/SKAC K/SKAB B C • .A selects the secret key K • at random from Zp*. K/SKBD • .A sends K/SKABto • B and K/SKAC to C. D E F 4. B gets K from K/SKABand sends K/SKACto D, etc.

  10. Group Key Exchange – contributory schemes U2 U3 U1 Round 1: Use DH Ui broadcasts zi= gri Un Un-1

  11. Group Key Exchange U2 U3 K23 Round 1: Each Ui computes the DH key: Ki= gri ri+1 Ki2 … U1 Kn-1n Un Knn-1 … Un-1

  12. Group Key Exchange U2 U3 K23 Ki2 … Round 1: end Group Key K = K1K2 … Kn Where Ki = Ki,i+1 But how???? U1 Kn-1n Un Knn-1 … Un-1

  13. Group Key Exchange U2 U3 K2 Ki … Round 2: Ui broadcasts xi = Ki/Ki-1 U1 Kn Un Kn-1 … Un-1

  14. Group Key Exchange U2 U3 K2 Ki … U1 Kn Round 2: Each Ui computes the key: K = Ki-1n zin-1 zi+1n-2 … zi-2 = Ki-1n(Ki/Ki-1)n-1(Ki+1/Ki)n-2… (Ki-1/Ki-2) Un Kn-1 … Un-1

  15. Authentication 1 How does Alice know that the “shared” secret key has been distributed to all the parties in the conference?

  16. Group Key Exchange – authentication • Each Ui authenticates (digitally signs) its • randomness ri • its zi and xi • and after checking them authenticates • the string: • {Ui}|| {ri} || {zi} || {xi}

  17. Authentication 2 How can Alice be certain which key is Bob’s public key? 1. They may have met earlier and exchanged public keys. 2. They may have mutual friends who know their public keys: Alice Carol Bob, or Alice Carol . . . Bob Case 1 establishes an a prioritrustrelationship Case 2 establishes an induced trust relationship

  18. 3. Public Key Certificates Who is who? PK CERTIFICATE The public key of Bob is: 010010010 ….. Signed by a Certifying Authority A PK Certificate establishes authenticity and provides a means by which a public key can be stored in partially insecure repositories, or transmitted over insecure channels.

  19. Trust-graphs A Certificates can be used to Model the confidence of a network in its public keys by a directed trust-graph, with vertices the entities and edges the certificates. CAB CAC C B CBE CCF CBD D F E

  20. Trust-graphs A priori confidence: This is corroborated by the certificates. Induced confidence: This is established by trust-paths that link the entities in the trust-graph.

  21. A hierarchical infrastructure RCA CA2 CA1 U4 U3 U1 U2 The public key of U4 is certified by the trust-path: RCACA2 U4

  22. Security issues A hacker can penetrate a CA or its computer system and forge certificates or get certificates for unauthorized users.

  23. Threats 1. Whom should we trust (and for what)? 2. Which Bob is it? 3. Organizational (insider) attacks 4. Computer system threats: How secure is the computer system of the Certifying Authority? How secure is the computer system of Bob?

  24. PGP: an unstructured approach Pretty Good Privacy is a freeware electronic mail system that uses an unstructured authentication framework. Users are free to decide whom they trust. PGP does not specify any specific structure for the trust-graph and for this reason is quite vulnerable. A A1. . .AnB

  25. A horizontal approach: multiple connectivity If the trust-graph is (2k+1)-connected then there are 2k+1 vertex disjoint trust-paths which connect any two of its vertices

  26. A 3-connected trust-graph A B

  27. Combining horizontal and hierarchical structures U1 U2 U3 U4

  28. Security A secure authentication infrastructure must be, reliable, robust and survivable. Reliability deals with faults that occur in a random manner, and is achieved by replication. Robustness deals with maliciously induced faults.

  29. Survivabilitydeals with the destruction of parts of the infrastructure. The destruction may affect the entities (e.g. the CA’s) as well as stored data, and may be malicious. For survivability, the remaining entities should be able to recover enough of the infrastructure to guarantee secure communication.

  30. Survivability Reconstruction of a corrupted trust-graph Adversary faulty U1 U2 U3 . . . . . . . . . . . . Un A Entity A asks all its neighbors for a list of their neighbors, the neighbors of their neighbors, etc

  31. Survivability Problem Some of the neighbors are under the control of the Adversary and may send fake certificates, relating to other entities, real or bogus. Is it possible to reconstruct a sufficiently good approximation of the trust-graph?

  32. Survivability Answer Yes, provided that there is a bound on the number of penetrated or destroyed cites, and that the trust-graph is sufficiently connected.

  33. Reconstructing a corrupted trust-graph The reconstruction involves several stages. • Round Robin flooding • a Halting routine • a Clean-up routine

  34. Conclusion Secure key exchange can be achieved in several ways by using cryptographic mechanisms. Clearly there is a trade off between the security requirements and the complexity.

  35. Conclusion If the public keys are authenticated via single trust paths then the system is vulnerable to any penetration. By having several vertex disjoint authentication paths linking the entities we get robustness against penetration and survivability.

More Related