dtki
play

DTKI A Protocol for Public-Key Validation Jiangshan Yu, Vincent - PowerPoint PPT Presentation

Jul 10, 2023 •413 likes •718 views

DTKI A Protocol for Public-Key Validation Jiangshan Yu, Vincent Cheval, and Mark Ryan School of Computer Science University of Birmingham September 2013 J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 1 / 23 Overview Background

  1. DTKI A Protocol for Public-Key Validation Jiangshan Yu, Vincent Cheval, and Mark Ryan School of Computer Science University of Birmingham September 2013 J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 1 / 23

  2. Overview Background 1 Public-key certificate issues Existing proposals Our work 2 Properties Proposed protocol J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 2 / 23

  3. Background 1 Public-key certificate issues Existing proposals Our work 2 Properties Proposed protocol J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 3 / 23

  4. Certificate A certificate is a signed statement that bind a public key to a subjects details. ( Example ) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 4 / 23

  5. Certificate A certificate is a signed statement that bind a public key to a subjects details. ( Example ) Loosely speaking: Cert Subj = Sign SK Issuer ( ID Subj , PK Subj ) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 4 / 23

  6. Web Certificate Verification CA/B trust model browser defines a set of CAs; browser accepts all certificates issued by any one of them. Mozilla Firefox browser initially trusts 57 root CAs. The EFF SSL Observatory : ∼ 1500 of CAs in total. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 5 / 23

  7. Issues Problems with CA/B Any CA can certify public keys for any domain. (Thus, we have to assume that all CAs are trustworthy.) CA/B has no efficient mechanism to detect mis-issued certificate. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 6 / 23

  8. Issues Problems with CA/B Any CA can certify public keys for any domain. (Thus, we have to assume that all CAs are trustworthy.) CA/B has no efficient mechanism to detect mis-issued certificate. Example of Attacks: Comodo was attacked and fake certificates were issued for popular domains (e.g. Google, Yahoo, Skype, etc.). (2011) DigiNotar issued 531 fake certificates for more than three hundred domains, including most of major Internet communications companies. (2011) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 6 / 23

  9. Does it matter? J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 7 / 23

  10. Does it matter? If you encrypt with the wrong key, the attacker may get your message. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 7 / 23

  11. Existing Proposals Table : Taxonomy of existing solutions Taxonomy Existing Proposals PGP adoption MonkeySphere; DNS extension DANE SSL Observatory; Certificate Patrol; Perspectives; Difference observation DoubleCheck; CertLock; Covergence; TACK. Sovereign Keys; Certificate Transparency; Public log adoption AKI J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 8 / 23

  12. Certificate transparency [Laurie, Kasper, Langley 2012] Basic idea: All certificates issued by a CA should be recorded in a public log. To accept a certificate, browsers must verify the proof such that this certificate is included in the log. Domain owners can detect mis-issued certificates by checking the log. IETF RFC6962 (June 2013). J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 9 / 23

  13. Public Log Desired proofs: Proof of presence proves that a certificate is included in a public log. Proof of extension proves that the current public log is an extension of previous versions. Proof of currency proves that the public key of a subject is the latest one in the public log. proof of absence proves that no certificate in the log is issued for the given subject. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 10 / 23

  14. Append-only public log – Merkle tree h 7 = h ( h 5 , h 6 ) h 5 = h ( h 1 , h 2 ) h 6 = h ( c 3 , c 4 ) h 1 = h ( c 1 , c 2 ) h 2 = h ( c 3 , c 4 ) h 3 = h ( c 5 , c 6 ) h 4 = h ( c 7 , c 8 ) c 1 c 2 c 3 c 4 c 5 c 6 c 7 c 8 Proof of Complexity presence O ( logn ) extension O ( logn ) currency O ( n ) absence O ( n ) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 11 / 23

  15. Append-only public log – Merkle tree h 7 = h ( h 5 , h 6 ) h 5 = h ( h 1 , h 2 ) h 6 = h ( c 3 , c 4 ) h 1 = h ( c 1 , c 2 ) h 2 = h ( c 3 , c 4 ) h 3 = h ( c 5 , c 6 ) h 4 = h ( c 7 , c 8 ) c 1 c 2 c 3 c 4 c 5 c 6 c 7 c 8 Proof of Complexity presence O ( logn ) extension O ( logn ) currency O ( n ) absence O ( n ) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 11 / 23

  16. An improvement Certificate Issuance and Revocation Transparency [Ryan 2013] ChronTree LexTree Dan Bob Kent Lucy Alice Chal Jeff c 1 c 2 c 3 c 4 c 5 c 6 c 7 c 8 Alex Proof of presence O ( logn ) O ( logn ) extension O ( logn ) O ( n ) currency O ( n ) O ( logn ) absence O ( n ) O ( logn ) consistency O ( n ) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 12 / 23

  17. Consistency Proof Public auditor. Random checking by clients. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 13 / 23

  18. Problems Difficulty with absence proof CT allows multiple public logs. Efficiency : to verify currency proof and absence proof, a client/server needs to check all existing logs. Security : hide party attacks could be launched. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 14 / 23

  19. Background 1 Public-key certificate issues Existing proposals Our work 2 Properties Proposed protocol J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 15 / 23

  20. Basic properties In-band verification Built-in key revocation Ability to limit trust scope Domain ownership change protection Scalability Usability J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 16 / 23

  21. Novel properties Country neutrality Infrastructure providers (e.g. root CAs, timeline servers, and log providers) should not be dominated by a single country. e.g. An Irish citizen accessing an Irish bank should be able to use Irish infrastructure. Government agencies who have compelled authorities in their country should not be able to use fake certificates without being readily detected. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 17 / 23

  22. Novel properties Canonical signer For a given domain, anyone should easily identify parties that are authorised to establish key authenticity. No-monopoly No provider should have a uniquely privileged position. (Trust agility) Any entity can freely remove his/her trust anchor without affecting the function of internet services. Resistance to hidden party attack “Hidden party” attack: A party issues certificates/logs/... for a subject that does not know that the party exists. E.g. CT log provider of a small organisation. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 18 / 23

  23. DTKI DNS-based Transparent Key Infrastructure (DTKI) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 19 / 23

  24. DTKI DNS-based Transparent Key Infrastructure (DTKI) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 19 / 23

  25. DTKI DNS-based Transparent Key Infrastructure (DTKI) J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 19 / 23

  26. DTKI DNS-based Transparent Key Infrastructure (DTKI) Basic idea Parent domains certify public keys for their child domains; Parent domains should maintain a public log to record their child domains’ certificates. Each top level domain ( e.g. .com, .net, and .uk) must maintain a log; each second level domain ( e.g. .co.uk and example.com) may or may not maintain a log; e.g. .co.uk does need to maintain a log, but example.com does not. Each log should be distributed to many peers which could be any interested party. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 20 / 23

  27. DTKI The format of the log: The log is organised as a ChronTree and a LexTree. Log . com = [( a . com , EK a . com , VK a . com ) , ... ] J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 21 / 23

  28. On-going work Proof transmission: users query proofs over DNS (similar as DANE); or users query proofs from mirrors in parallel with ServerHello phase, or users cache the certificate obtained from TLS handshake, and check proofs with mirrors later. Formal proof. J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 22 / 23

  29. Thank You! J.Yu, V.Cheval and M.Ryan (Birmingham) DTKI September 2013 23 / 23

Recommend

More recommend