CONIKS (KEY TRANSPARENCY) Slides adapted from Marcela Melara
Any scriber for today? • Sign up for presentations or scribers
The problem of the PKI (Public key infrastructure) • A long standing problem has been to distribute public keys securely in the presence of attackers • Use cases: • Secure messaging: Alice needs to send an encrypted message to Bob and needs Bob’s public key to encrypt the message • Web surfing and https: when Alice’s browser contacts amazon.com over https, we need Amazon’s PK • Man in the middle attacker can intercept PK and return incorrect PK
“Secure” Communication Today SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
Attack: Hackers SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
Attack: Disgruntled Employees SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
Attack: Provider Coercion SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
CAs are Vulnerable SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
CAs are Vulnerable SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP “hey, I’m + + foo.com ” SSL/TLS SSL/TLS Hacker foo.com User User Alice Bob
CAs are Vulnerable SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP Certificate: + + ( foo.com , PK evil ) SSL/TLS SSL/TLS Hacker foo.com User User Alice Bob
Attack: Fraudulent Certificates SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority HTTP HTTP + + SSL/TLS SSL/TLS User User Alice Bob
Attack: Fraudulent Certificates SSL/TLS Certificate: ( foo.com , PK f ) Certificate Email Provider foo.com Authority Certificate: ( foo.com , PK evil ) Hacker HTTP foo.com + SSL/TLS HTTP User User + Alice Bob SSL/TLS
Need End-to- End Encryption… Email Provider foo.com E2E Encryption E2E Encryption User User Alice Bob … But Key Management is Hard
Decentralized Key Management PK Alice : DEF456 PK Bob : 123ABC User User Alice Bob Manual key exchange
Decentralized Key Management Alice trusts PK Bob User User Alice Bob Bob trusts PK Alice Mutual Endorsement
Decentralized KM: Pitfalls PK Alice : DEF456 PK Bob : 123ABC User User Alice Bob Lost keys
Decentralized KM: Pitfalls Should be PK Alice : DEF456 AB PK Bob : 123BAC User User Alice Bob Mistakes transferring keys
PGP Key Servers Email Provider foo.com E2E Encryption E2E Encryption User User Alice Bob PGP Key PK Bob PK Alice Server X
PGP Key Servers
Key Signing Parties
Trusting the Web of Trust XKCD, Responsible Behavior
Crux of WoT Issues • Decentralized model: people reason about encryption. • Studies: • Unintuitive and error-prone. • Users don’t understand encryption. • Leak private information. [1] A. Whitten and J. D. Tygar. Why Johnny can’t encrypt : a usability evaluation of PGP 5.0. USENIX Security, Aug. 1999 [2] S. Gaw, E. W. Felten, and P. Fernandez-Kelly. Secrecy, flagging, and paranoia: Adoption criteria in encrypted email . CHI, Apr 2006.
Better: Centralized Key Management Email + Key Provider foo.com Register Register 1 1 (alice → PK A ) (bob → PK B ) User User Alice Bob
Better: Centralized Key Management Email + Key Provider foo.com Register Look up Alice’s 1 2 3 3 (alice → PK A ) public key: PK A Send message encrypted to PK A , signed by SK B User User Alice Bob
Insider Attacks, still. Email + Key This isn’t Alice’s Provider real key! foo.com Register Look up Alice’s 1 2 (alice → PK A ) public key: PK’ A User User Alice Bob
Insider Attacks, still. Email + Key Provider Read message foo.com 4 encrypted to PK’ A Send message encrypted to PK’ A , 3 signed by SK B User User Alice Bob
Old Approach: Correct Identities Bob’s real-world friend Alice? Certificate Name: alice@foo.com PK A : 456DEF Alice Owner: Alice Signed by: CA alice@foo.com
New Approach: Consistent Identities • Users expect consistency of online identities. • Separate real-world identity from online identity. • Certificates make no statement about correctness.
Consistency No unexpected key changes Non-Equivocation Alice’s key today = Alice’s key yesterday Key seen by Alice = Key seen by Bob
Solution: a promising new generation • CONIKS • An alternative Public Key Infrastructure (PKI) • Embedded in Google’s project called Key Transparency or Trillian • The key data structure is the Log-backed Verified Map • Certificate Transparency • Similar technology to Key Transparency but aimed at certificates • Currently mandated by Chrome, other browser support coming up
CONIKS [Melara et al. 2014] • End-User Key Management Service. • Consistent name-to-key bindings. • Verifiable key directories → Untrusted identity providers. • Clients verify consistency in-band. → automated key management
CONIKS Overview Untrusted Identity Provider foo.com Register Register 1 1 (alice → PK A ) (bob → PK Bs ) Client Client A B User User Alice Bob
CONIKS Overview Untrusted Identity Provider foo.com Look up the public key 4 Look up public key for bob: 2 for alice: PK A PK B , verify signature, decrypt using SK A Client Client A B User User 3 Alice Bob Send message encrypted to PK A , signed by SK B
Strawman Design Untrusted Identity Provider foo.com Validity Checks O(N) storage per client N = 4 Client Client Client Client A C B D Non-equivocation Checks O(N 2 ) downloads per client
CONIKS Design • Divide time into epochs. • Providers generate snapshots of directory. → Clients do not check individual bindings. • Providers distribute snapshots to other providers. → Build publicly verifiable history • Non-repudiation: Snapshots are digitally signed.
Efficient Snapshots root foo.com H(sub L ) H(sub R ) H(sub L ) H(sub R ) H(sub L ) H(sub R ) i george : i charlie : i emily : i alice : PK George PK Charlie PK Emily PK Alice
Efficient Snapshots root foo.com H(sub L ) H(sub R ) 0 1 H(sub L ) H(sub R ) H(sub L ) H(sub R ) 0 1 0 1 i george : i charlie : i emily : i alice : PK George PK Charlie PK Emily PK Alice
Checking Consistency • Use snapshots to check for consistency. • Clients need to ensure bindings are included in snapshots. • Lookups: prove inclusion of bindings in directory. • Clients check validity, non-equivocation. • Providers cross-verify each other for non-equivocation.
Proving Inclusion: Authentication Paths root foo.com H(sub L ) H(sub R ) 0 1 H(sub L ) H(sub R ) H(sub L ) H(sub R ) 0 1 i charlie : i alice : PK Charlie PK Alice
Proving Inclusion: Authentication Paths root foo.com H(sub L ) H(sub R ) 0 H(sub L ) H(sub R ) 0 i alice : PK Alice
Checking Non-Equivocation: Snapshot History Snapshot 0 Snapshot prev Snapshot t 0 -1 t prev t prev-1 t t prev … H(seed) root 0 H(root prev-1 ) root prev H(root prev ) root t Trillian calls this: Log-backed Verified Map
Checking Non-Equivocation: Snapshot History Snapshot prev Snapshot t t prev t prev-1 t t prev Snapshot 0 H(root prev-1 ) root prev H(root prev ) root t 0 -1 … H(seed) root 0 Snapshot’ prev Snapshot’ t t prev t prev-1 t t prev H (root’ prev-1 ) r oot’ prev H( root’ prev ) r oot’ t The server can try a fork attack, but after fork the provider must maintain these forked hash chains for the rest of time, and not allow clients seeing one branch of the hash chain to communicate with anyone seeing the other branch.
CONIKS Protocols • Registration: New bindings/updated keys. • Lookups: Clients check bindings are included in directory. • Monitoring: Clients check for validity of bindings. • Auditing: Clients & providers check for non-equivocation.
CONIKS Protocols • Registration: New bindings/updated keys. • Lookups: Clients check bindings are included in directory. • Monitoring: Clients check for validity of bindings. • Auditing: Clients & providers check for non-equivocation.
Registration Protocol Untrusted Identity Provider foo.com Temporary binding = Register 2 3 (alice → PK A ) [(alice → PK A ) + next epoch], Sig(TB) Client Client A B 1 User User Generate key pair Alice (PK A , SK A ) Bob
CONIKS Protocols • Registration: new bindings/updated keys. • Lookups: Clients check bindings are included in directory. • Monitoring: Clients check for validity of bindings. • Auditing: Clients & providers check for non-equivocation.
Recommend
More recommend
