coniks
play

CONIKS BRINGING KEY TRANSPARENCY TO END USERS Marcela Melara - PowerPoint PPT Presentation

Dec 16, 2022 •246 likes •516 views

CONIKS BRINGING KEY TRANSPARENCY TO END USERS Marcela Melara Aaron Blankstein, Joseph Bonneau*, Edward W. Felten, Michael J. Freedman Princeton University, *Stanford University/EFF E2E Encrypted Communication Today Users growing demand

  1. CONIKS BRINGING KEY TRANSPARENCY TO END USERS Marcela Melara Aaron Blankstein, Joseph Bonneau*, Edward W. Felten, Michael J. Freedman Princeton University, *Stanford University/EFF

  2. E2E Encrypted Communication Today • Users’ growing demand for E2E secure communication • Known problem: Key management is difficult for users

  3. Unsolved: How do users establish trust? • Trust establishment = Learn & verify the other party’s key • Goal: Establish secure communication channel

  4. Out-of-Band Trust Est. = Unintuitive Bob, is DEF123 your public key? Alice, what’s a public key? Alice ¡ Bob ¡ Requires users to reason about encryption/keys à unintuitive, error-prone!

  5. Trust Est. by the Provider – Better? • Clients query provider for others’ keys • Users don’t worry about or see keys • Caveat: Users must trust provider unconditionally

  6. Malicious Provider can Equivocate Secure ¡ Messaging ¡ Provider ¡ This isn’t alice’s alice’s Register 1 ¡ 2 ¡ real key! key: PK’ A (alice à PK A ) Client ¡ Client ¡ A ¡ B ¡ Alice ¡ Bob ¡ Equivocation = Presenting diverging views to different clients.

  7. Pros/Cons of Existing Trust Establishment Users verify keys Providers establish trust out of band for users ✔ ✖ Security ✖ ✔ Usability Challenge: How can we get the best of both worlds?

  8. Ideal Trust Establishment Properties 1. Security against equivocation attacks 2. Automation: Users don’t worry about trust establishment

  9. Existing Approach: Verifying Correctness • Correctness = Expected real-world person controls online name- to-public key binding • Problem: Requires out-of-band communication

  10. Our Approach: Verifying Consistency • Consistency = Alice’s key today = Alice’s key yesterday 1. Alice’s key seen by Alice = Alice’s key seen by everyone else 2. • Benefit: Can be enforced via crypto à Providers manage consistent keys à Automation

  11. Solution: CONIKS • Automated trust establishment with untrusted providers • Clients verify consistency of bindings • Goal: Make provider equivocation easily detectable

  12. CONIKS – Registering a Key Iden:ty ¡Provider ¡ ¡ Register (alice à PK A ) Client ¡ Client ¡ A ¡ B ¡ Alice ¡ Bob ¡

  13. CONIKS – Learning a User’s Key Iden:ty ¡Provider ¡ Public key for 2 ¡ alice: PK A 1 ¡ Verify consistency of PK A Client ¡ Client ¡ A ¡ B ¡ 3 ¡ Alice ¡ Bob ¡ Encrypt msg using PK A

  14. Strawman Consistency Checks: Verify All Bindings Iden:ty ¡Provider ¡ Unexpected ¡Changes ¡Checks ¡ O(N) ¡storage ¡per ¡client ¡ Client ¡ ¡ Client ¡ ¡ Client ¡ ¡ Client ¡ N ¡= ¡4 ¡ A ¡ C ¡ B ¡ D ¡ Consistent ¡View ¡Checks ¡ ¡ O(N 2 ) ¡downloads ¡per ¡client ¡

  15. CONIKS: Efficient Checks thru “Summaries” root t ¡ • Providers generate directory “summaries” H(child 0 ) ¡ H(child 1 ) ¡ à Clients don’t verify all bindings H(child 0 ) ¡ H(child 1 ) ¡ H(child 0 ) ¡ H(child 1 ) ¡ • Bindings stored in Merkle prefix trees à Tree root = Summary of all bindings emily’s john’s bob’s alice’s ¡ à Tamper-evident directory binding ¡ binding ¡ binding binding ¡ • Non-repudiation: Signed tree root (STR) à Undeniable statement about tree contents

  16. CONIKS – Main Security Properties No Unexpected Key Changes: Expected Bindings 1. included in Signed tree root Non-equivocation = All clients see the same STR 2.

  17. 1. Expected Bindings incl. in STR – Auth Paths • Why? Evidence for fake keys root t ¡ H(child 0 ) ¡ H(child 1 ) ¡ • How? Authentication path = proof of inclusion à Pruned Merkle tree from binding to root H(child 0 ) ¡ H(child 1 ) ¡ • Verification: recomputed root = STR à O(log n) for tree with n bindings alice’s ¡ binding ¡

  18. 1. Checking Inclusion – Verify Auth Path Iden:ty ¡Provider ¡ ¡ PK A + Auth Signed + 2 ¡ Important: Clients also regularly Path Tree Root monitor their own user’s binding. Lookup PK 1 ¡ for alice Client ¡ Client ¡ A ¡ B ¡ 3 ¡ Compare PKA to previous version, Bob ¡ verify auth path, Alice ¡ Verify STR signature

  19. 2. Non-Equivocation – STR History S 0 ¡ S t-­‑1 ¡ S t ¡ Sig(S 0 ) ¡ Sig(S t-­‑1 ) ¡ Sig(S t ) ¡ … ¡ H(seed) ¡ root 0 ¡ H(S t-­‑2 ) ¡ root t-­‑1 ¡ H(S t-­‑1 ) ¡ root t ¡ root t ¡ • Why? Detect provider attempt to MITM H(child 0 ) ¡ H(child 1 ) ¡ • How? Building verifiable STR history H(child 0 ) ¡ H(child 1 ) ¡ H(child 0 ) ¡ H(child 1 ) ¡ • Hash chain à commitment to all STRs i john : ¡john’s ¡ i bob : ¡bob’s ¡ i emily : ¡emily’s ¡ ¡ i alice : ¡alice’s ¡ binding ¡ binding ¡ binding ¡ binding ¡ • Verification: previous STR is incl. in next STR

  20. 2. Non-Equivocation – Clients see same STRs • Checking hash chain not enough: S t-­‑1 ¡ S t ¡ Sig(S t-­‑1 ) ¡ Sig(S t ) ¡ Client ¡ A ¡ H(S t-­‑2 ) ¡ root t-­‑1 ¡ H(S t-­‑1 ) ¡ root t ¡ S 0 ¡ Sig(S 0 ) ¡ … ¡ S’ t-­‑1 ¡ S’ t ¡ H(seed) ¡ root 0 ¡ Sig(S’ t-­‑1 ) ¡ Sig(S’ t ) ¡ Client ¡ B ¡ H(S t-­‑2 ) ¡ root’ t-­‑1 ¡ H(S’ t-­‑1 ) ¡ root’ t ¡

  21. 2. Checking Non-Equivocation – Cross-Verification 1 ¡ Verify hash chain Verify hash chain 1 ¡ S t ¡ S t ¡ Sig(S t ) ¡ Sig(S t ) ¡ H(S t-­‑1 ) ¡ root t ¡ H(S t-­‑1 ) ¡ root t ¡ Iden:ty ¡Provider ¡ ¡ Iden:ty ¡Provider ¡ ¡ Iden:ty ¡Provider ¡ ¡ S t ¡ S t ¡ Sig(S t ) ¡ 3 ¡ S t ¡ H(S t-­‑1 ) ¡ root t ¡ Sig(S t ) ¡ 2 ¡ Sig(S t ) ¡ H(S t-­‑1 ) ¡ root t ¡ 2 ¡ H(S t-­‑1 ) ¡ root t ¡ Client ¡ Client ¡ A ¡ B ¡ 3 ¡ Verify hash chain Alice ¡ Bob ¡ Compare different views 4 ¡

  22. Privacy Challenges in CONIKS Don’t want to publish list of usernames 1. Don’t want to publish PKs associated with names 2. Don’t want to expose total # of users 3. à Addressed through practical crypto tricks!

  23. Main Performance Questions • Does our server design scale to the size of a typical user base (thousands – billions)? • Are CONIKS consistency checks efficient enough to run on today’s mobile devices? • Does CONIKS integrate well with existing E2E services?

  24. CONIKS’ Performance is Practical! • Server scales to tens of millions of users on single machine Inserting 1K new bindings into 10M-user tree: 2.6ms • • Client consistency checks need little bandwidth/storage Max. bandwidth requirements < 20kB per day • Proof of concept: Integration with Pidgin OTR plug-in •

  25. Conclusion • Main idea: Users should not have to manage keys, but service providers should not be trusted either. • CONIKS: Security through consistency à more practical • Yahoo & Google adopting CONIKS in their E2E systems

  26. Q&A More Info: Website: www.coniks.org Ref. Implementation: github.com/coniks-sys We thank: Yan Zhu (Yahoo) Gary Belvin (Google) Trevor Perrin (TextSecure) David Gil (formerly Yahoo)

More recommend