Collective Authorities – Transparency and Decentralized Trust at Scale

Talk given at https://www.dotsecurity.io/.

Abstract
The secret keys of critical network authorities–such as time, name, certificate, and software update services–represent high-value targets for hackers, criminals, and spy agencies wishing to use these keys secretly to compromise other hosts. In this talk, we present the concept of collective authorities (cothorities) which enable to decentralize authoritative systems thereby strengthening the overall robustness of such systems and providing a proactive approach to transparency that can either replace or complement existing (centralized) methodologies. Our talk also highlights various applications of cothorities to areas like software updates, distributed randomness, and cryptocurrencies.

Transcript

1. Collective Authorities Transparency and Decentralized Trust at Scale Philipp Jovanovic @Daeinar
2. Deep Dependence on Internet Authorities Time Service Certificate Provider Software Update Center Naming Authority Current time? IP address of dotsecurity.io? TLS certificate of dotsecurity.io? New updates? 2 Client
3. Authorities Make and Sign Statements Time Service Certificate Provider Software Update Center Naming Authority It is 17:05. IP address is 104.24.103.23. TLS certificate is xyz. 3 New security update 1.0.1.2 available. Client
4. Time Service Certificate Provider Software Update Center Naming Authority It is 10:00. IP address is 104.24.103.23. TLS certificate is xyz. 4 New security update 1.0.1.2 available. Client Authority Compromise
5. Time Service Certificate Provider Software Update Center Naming Authority It is 10:00. IP address is 95.123.101.20. TLS certificate is xyz. 5 New security update 1.0.1.2 available. Client Authority Compromise
6. Time Service Certificate Provider Software Update Center Naming Authority It is 10:00. IP address is 95.123.101.20. TLS certificate is zyx. 6 New security update 1.0.1.2 available. Client Authority Compromise
7. Authority Compromise Time Service Certificate Provider Software Update Center Naming Authority 7 IP address is 95.123.101.20. TLS certificate is zyx. New security update 1.0.1.1 available. It is 10:00. Client
8. 8 Technical Threats
9. 9 Legal Threats vs. “Hey Lavabit, give us your crypto keys. 
 Ah and you can’t tell anybody about it.” Lavabit shutdown to avoid being complicit in crimes against customers. “Grml, here. To save space they are printed in 4pt font. You’re welcome.“
10. Legal Threats vs. 10 “Hey Apple, create and sign a backdoored iOS.” “Hahaha. No.” Public debate this time, but what about the next round?
11. 11 Fact: 
 No Individual Entity is Immune to Compromise or Coercion
12. The FBI has not been here [watch very closely for removal of this sign] 12 A warrant canary An actual canary Legal Self-Defense
13. 13 Ulysses Pacts* for Internet authorities? *Thanks to Cory Doctorow for pointing out to this analogy
14. Towards Ulysses Pacts for Internet Authorities 14 “There’s a new version of iOS.” Clients only accept an update if Apple and enough public witnesses signed it off. Public witnesses (“Ulysses’ crew”) (“Ulysses”)
15. 15 Weakest link T = 1 Stronger link T = 2 … 10 Collective authorities T = 100++ Towards Ulysses Pacts for Internet Authorities Trust splitting has to scale and increase security, diversity, and independence.
16. Decentralized Witness Cosigning 16 It is 17:05. IP address is 104.24.103.23. TLS certificate is xyz. New security update 1.0.1.2 available. Witnesses Authority Verification: Signed by authority and at least T witnesses? Client Public logs
17. Regular Versus Collective Signing 17 Collective signature Regular signatures Excerpt of a public petition from 1866 Signatures in superposition
18. Collective (Schnorr) signature: (c,r) Collective Signing (CoSi) 18 1. Announcement Send statement S now or later 2. Commitment Aggregate commits
 V = ∑i(viG) 3. Challenge Send challenge
 c = H(V, S) 4. Response Aggregate responses
 r = ∑i(vi-cxi)
19. CoSi Features 19 Security • Strongest-link robustness • Proactive guarantees • Discourages misbehavior Scalability • Aggregation • Communication trees • Sign: O(log n) (8000 nodes, ~2 sec) • Verify: O(1) Transparency • Multi-eye-principle 
 sanity checks • Public logs
20. Security / Transparency Levels 20 Weakest Strongest Level 1 • Witness co-signing • Public log(s) • Check nothing • Generic • Easy to upgrade 
 existing authorities Level 2 • Witness co-signing • Public log(s) • Check authority
 statements • E.g., reproducible 
 builds for software
 updates Level 3 • Witness co-signing
 BFT consensus • Public log(s) • Check consistency of
 distributed processes • E.g., blockchain 
 extension in crypto-
 currencies Level 0 • Traditional authorities • No witness co-signing • No public log(s)
21. Scalable Strongly Consistent Blockchains 21 Mining cothority = Consensus group Mining-blockchain (co-signed) TX-blockchain (co-signed) Miners Leader co-sign ByzCoin • Non-probabilistic BFT consensus • Scalable (1000+ nodes) • Low latency (< 20 sec) • High throughput (700+ TPS) • Permissioned and permissionless
22. Scalable Bias-Resistant Distributed Randomness 22 Secret sharing group 1 Secret sharing group 2 Requester Servers Servers RandHound Rand{Hound, Herd} • Randomness beacons • Distributed • Bias-resistant • 3rd-party verifiable • Scalable (1000+ nodes) • Low latency randomness & proof
23. Software Update Transparency 23 Chainiac • Software update system • Decentralized • Co-signed update timeline • Efficient source-to-binary verification Update cothority Update timeline (co-signed) co-signed release Verified builds Client pull & check Developers Pre-release
24. Further details https://github.com/dedis/cothority 24 Thanks @Daeinar