k e e p i n g a u t h o r i t i e s honest or bust with
play

K e e p i n g A u t h o r i t i e s Honest or Bust with - PowerPoint PPT Presentation

K e e p i n g A u t h o r i t i e s Honest or Bust with Decentralized Witness Cosigning Ewa Syta, Iulia Tamas, Dylan Visher, David Isaac Wolinsky Yale University Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ismail Khofg, Bryan Ford


  1. K e e p i n g A u t h o r i t i e s “Honest or Bust” with Decentralized Witness Cosigning Ewa Syta, Iulia Tamas, Dylan Visher, David Isaac Wolinsky – Yale University Philipp Jovanovic, Linus Gasser, Nicolas Gailly, Ismail Khofg, Bryan Ford – Swiss Federal Instjtute of Technology Lausanne (EPFL) I E E E S e c u r i t y & P r i v a c y – M a y 2 4 , 2 0 1 6

  2. We depend on many authorities Conceptually simple but security-critjcal services • Time Services (NTP) • Digital Notaries • Naming Authorites • Certjfjcate Authoritjes • Randomness Authoritjes (e.g., Lotueries) • Sofuware Update Services

  3. But are authorities trustworthy?

  4. But are authorities trustworthy?

  5. But are authorities trustworthy?

  6. But are authorities trustworthy?

  7. Talk Outline • The trouble with trustjng authoritjes • Grand challenge: decentralize the authoritjes! • Baby step: decentralized witness cosigning • CoSi: scalable collectjve Schnorr/Ed25519 signatures • Experimental evaluatjon: scalability, signature size • Comparison with prior transparency approaches • Status, future work, and conclusions

  8. Deep Dependence on Authorities How does an Internet client name and authenticate sites, services, users, software? Get Time Browse Web Send Text-Message Alice Bob Software download, update

  9. Deep Dependence on Authorities Respect my Authoritah! ? What is: ● The current time? ● Amazon's SSL public key? Alice ● Bob's IM public key? Bob ● Latest version of App?

  10. Authorities Make & Sign Statements “The time is 3PM.” “Amazon’s public key is X.” “Bob's public key is Y.” Alice Bob “The hash of latest iOS is Z.”

  11. Problem #1: Authority Compromise ● MITM attack websites ● Impersonate users ● Send malicious Fake updates Fake Fake Bob Alice Bob Fake

  12. Problem #2: Weak Links Clients ofuen depend on many authoritjes: e.g., hundreds of CAs trusted by web browsers ● Any CA can issue cert for any domain name Atuacker ofuen needs to compromise only one ● Weakest-link security ● @#$% happens – DigiNotar, Comodo, CNNIC/MCS

  13. Problem #3: Secret Key Portability ● A tu a c k e r n e e d n o t Freetopia compromise authority “in-place” ● Instead steal the authority's s e c r e t k e y – U s e i t t o c r e a t e an “evil twin” on atuacker's turf Tyrannia – Avoid detectjon Fake by confjning use Fake to specifjc targets Fake Bob – Block targets from Fake reportjng to real authority

  14. Problem #4: Everybody Wants In Hackers, organized crime, governments…

  15. Problem #4: Everybody Wants In Hackers, organized crime, governments…

  16. Talk Outline • The trouble with trustjng authoritjes • Grand challenge: decentralize the authoritjes! • Baby step: decentralized witness cosigning • CoSi: scalable collectjve Schnorr/Ed25519 signatures • Experimental evaluatjon: scalability, signature size • Comparison with prior transparency approaches • Status, future work, and conclusions

  17. What To Do? We have to assume that no individual… ● Hardware platgorm ● Sofuware system ● System/network administrator ● Authoritatjve organizatjon …is invulnerable to compromise (or coercion)

  18. Decentralize the Authorities! Split trust across independent partjes ● So system resists compromise by individuals ● From weakest-link to strongest-link security ● Decentralized resistance to failure, coercion

  19. Example: Tor Directory Authority Split across ~10 servers – but is this enough? ● Could atuacker hack or coerce ~5 operators? ( i m a g e c r e d i t : Jordan Wright)

  20. Trust-splitting needs to scale Collective Weakest-link: Strongest-link: authorities: T = 1 T = 2-10 T = 100s,1000s

  21. Trust-splitting needs to scale Must incorporate all diversity that makes sense ● Not just ~10 partjes “picked by someone” Could we decentralize… ● TLS certjfjcate validatjon and signing across the hundreds of certjfjcate authoritjes? ● DNSSEC root zone maintenance and signing across the 1000+ worldwide TLD operators? ● A natjonal cryptocurrency across the thousands of US natjonal banks? Make overall security grow as scale increase?

  22. Talk Outline • The trouble with trustjng authoritjes • Grand challenge: decentralize the authoritjes! • Baby step: decentralized witness cosigning • CoSi: scalable collectjve Schnorr/Ed25519 signatures • Experimental evaluatjon: scalability, signature size • Comparison with prior transparency approaches • Status, future work, and conclusions

  23. Not Gonna Happen Overnight…

  24. A First Step: Transparency More readily achievable near-term ● Who watches the watchers? Public witnesses ! Respect my Authoritah! Ensure that any authoritatjve statement: ● Is exposed to public scrutjny ● Conforms to checkable standards Witnesses before clients will accept statement Key: practjcal to “retrofjt” existjng authoritjes

  25. Decentralized Witness Cosigning “The time is 3PM.” Authority “Amazon’s public key is X.” “Bob's public key is Y.” “The hash of latest iOS is Z.” Witnesses Verification: signed by authority and ≥ T witnesses? Alice Public Logs

  26. Is the Signed Statement “Good”? In general, witnesses don’t (and can’t) know for sure ● Does public key X really belong to Bob? ● Does sofuware image Y have a secret backdoor? But witnesses can stjll ensure all signatures are public ● If authority coerced or its keys used to produce bad statement, atuacker can’t ensure its secrecy – Backdoors possible but must “hide in plain sight” ● Creates “Ulysses Pact” deterrent against coercion – “the point…is to keep governments from even trying to put secret pressure on tech companies, because the system is set up so that the secret immediately gets out” - Cory Doctorow, 10-March-2016

  27. Talk Outline • The trouble with trustjng authoritjes • Grand challenge: decentralize the authoritjes! • Baby step: decentralized witness cosigning • CoSi: scalable collectjve Schnorr/Ed25519 signatures • Experimental evaluatjon: scalability, signature size • Comparison with prior transparency approaches • Status, future work, and conclusions

  28. Setup: Keypairs and CoSi Groups Individual Keypairs: CoSi group: Standard Schnorr List of public keys (Ed25519) ● K 1 , K 2 , …, K N • Private key: k • Public key: K = g k Assumptjons: ● Verifjer has full list – (nonessentjal) ● All keys self-signed – (important to avoid related-key atuacks)

  29. Schnorr Signature • Generator g of prime order q group • Public/private key pair: (K=g k , k) Signer Verifjer Commitment V=g v V Challenge c c = H(M|V) Response r = (v – kc) r Signature on M: (c, r) Commitment recovery V' = g r K c = g v-kc g kc = g v = V Challenge recovery c’ = H(M|V’) Decision c’ = c ?

  30. Schnorr Multisignature • Key pairs: (K 1 =g k 1 , k 1 ) and (K 2 =g k 2 , k 2 ) Signer 1 Signer 2 Verifjer Commitment V 1 =g v 1 V 2 =g v 2 V 1 V 2 V=V 1 *V 2 Challenge c c c = H(M|V 1 ) c = H(M|V) Response r 1 = (v 1 – k 1 c) r 2 = (v 2 – k 2 c) r 1 r 2 r=r 1 +r 2 Signature on M: (c, r) Signature on M: (c, r 1 ) Same signature! Commitment recovery Same verifjcatjon! V' = g r K c K=K 1 *K 2 Challenge recovery Done once! c’ = H(M|V’) Decision c’ = c ?

  31. CoSi Protocol Signing Rounds 1. Announcement Phase 2. Commitment Phase 3. Challenge Phase 4. Response Phase

  32. CoSi Commit Phase V 1 = g v1 , Challenge c = H( ) V 1 = V 1 V 2 ...V N T r e e c o m p u t a tj o n o f : ● Commits V i V 2 = g v2 , V 2 = V 2 V 3 V 4 ● Aggregate commits V i Collectjve challenge c is hash of aggregate commit V 3 = g v3 , V 4 = g v4 , V 3 = V 3 V 4 = V 4

  33. CoSi Response Phase r 1 = v 1 - k 1 c, r 1 = r 1 +r 2 +...+r N Compute ● Responses r i r 2 = v 2 - k 2 c, r 2 = r 2 +r 3 +r 4 ● Aggregate responses r i Each (c,r i ) forms valid partjal signature (c,r 1 ) forms complete signature r 3 = v 3 - k 3 c, r 4 = v 4 - k 4 c, r 3 = r 3 r 4 = r 4

  34. Unavailable Witness Servers A s s u m e s e r v e r f a i l u r e s a r e r a r e but non-negligible ● P e r s i s t e n t l y b a d s e r v e r s g e t a d m i n i s t r a tj v e l y b o o t e d Exceptjons: If a server A is down, proceed anyway ● Modifjed collectjve key: K’= K * K - 1 A ● Modifjed commitment: V’= V * V -1A ● Modifjed response: r’= r – r A Verifjcatjon: CoSi signature includes roll-call bit-vector ● Enables verifjer to recompute modifjed public key K’ ● Can use a n y criteria to decide if “too many” missing

  35. Variations (see paper for details) ● Complex/contextual verifjcatjon predicates – Witness subgroups, weights, expressions, … ● Minimizing cothority certjfjcate size – Via Merkle key-trees ● Toleratjng network churn – Via binomial swap forests (Cappos, San Fermin) ● Toleratjng cosigner churn – Avoiding restarts via commit trees ● Single-pass CoSi for asynchronous networks – Via BLS signatures, opportunistjc signature combining

  36. Talk Outline • The trouble with trustjng authoritjes • Grand challenge: decentralize the authoritjes! • Baby step: decentralized witness cosigning • CoSi: scalable collectjve Schnorr/Ed25519 signatures • Experimental evaluatjon: scalability, signature size • Comparison with prior transparency approaches • Status, future work, and conclusions

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend