Decentralizing Authorities into Scalable Strongest-Link ... › dissent › pres ›...

Decentralizing Authorities into Scalable Strongest-Link Cothorities

Ewa Syta, Iulia Tamas, Dylan Visher, David Wolinsky, Bryan Ford

Yale UniversityComputer Science Department

National Institute of Standards and Technology – June 10, 2015

“Authorities” are EverywhereConceptually simple but security-critical services

• Logging, Time-stamping Authorities

• Naming Authorites

• Certificate Authorities

• Randomness Authorities (e.g., Lotteries)

• Digital Notaries

Talk Outline

• Troubles with Authorities

• Cothorities: Large-scale Collective Authorities

• A Basic Tool: Scalable Collective ElGamal Log-Signing

• The Availability Problem, and Two Solutions

• Prototype and Preliminary Results

• Future Work: Potential Applications

Authorities Make Statements● Often recorded in tamper-evident public logs

– Each log entry signed by the authority

– Hash chains for consistency verification

● But hashes don't solve the forking problem…

● Or the freshness problem…

record1 record2 record3

Head

record1 record2record3

record3

Head 1

Head 2

record1 record2 record3

“Head”

When authorities go bad...Compromised authority services can:● Tamper with history: e.g., forge log entries● Pre-date or post-date a timestamp● Equivocate: customize history for each user● Impersonate names and MITM attack● Look into the future: e.g., win the lottery

And usually you're trusting one entity to be good

Example: Bad Randomness

If we trust many authorities…Attacker gets to choose which authority to attack

→ Weakest-link security overall

Example: Certificate AuthoritiesEFF SSL Observatory:● ~650 CAs trusted by

Mozilla or Microsof● Any CA can issue certs

for any domain name● Prime key thef target

– MITM attack power

● Breaches do happen– DigiNotar, Comodo,

CNNIC/MCS

Certificate Authorities

Alice (Victim)

CAs

DigiNotarStolen CAPrivate Key

Fake Google.com(MITM Attacker)

Pwned!

Certificate Transparency

Alice (Victim)

CAs


FakeGoogle.com(Attacker)

Public Log Servers

Monitor Servers

Real

!!!

CT's Weakness

Alice (Victim)

CAs


DictatorDaveFake

Google.com(Attacker)

Public Log Servers

Monitor Servers

Pwned!

Talk Outline







Splitting Trust in AuthoritiesWe know how to:

● Split trust across a few servers, typically <10– “Anytrust”: only 1-of-k servers need be honest,

but all k servers need to remain live

– Byzantine Fault Tolerance (BFT): 2/3 of k servers need to be honest, 2/3 need to be live

● Split cryptographic keys, operations– Threshold cryptography, multisignatures

Example: Tor directory authority (8 servers)

Small-Scale Trust-SplittingIs splitting trust across 5-10 replicas “enough”?

● Who owns/controls these replicas?– Truly independent operators (decentralized),

or within one organization (merely distributed)?

– All in same country? All in “five-eyes” territory?

● What is the real cost of targeted attacks?– 5 Tor directory server private keys might be

well worth the cost of a 0-day exploit or two

● Who chooses the 5-10 replicas?– Why should “everyone” trust them?

Large-Scale Trust Splitting

Main proposition:

We can and should build authority services to split trust across large-scale collectives

● e.g., thousands of replicas/monitors or more

Result:

Collective Authorities or Cothorities

Why Large-Scale Trust SplittingBasic goals:

● Transform authorities from “weakest-link” to “strongest-link” security model– Remain secure unless many nodes compromised

● Split trust across broad diversity of servers, operators, organizations, countries, interests, alternative sofware implementations, …– Every user can find someone they really do trust

● Make adding participants cheap and always beneficial → can only increase security

Why Large-Scale Trust Splitting

From thismodel…

Why Large-Scale Trust Splitting

To this model

Talk Outline







CoSi: Collective SigningBasic primitive: a tamper-evident logging cothority

Simple operation model (for now):● Leader server generates log entries, timeline● Follower servers (e.g., thousands) collectively

witness and “sign off” on log entries● Each log entry gets single collective signature:

small, quick and easy for anyone to verify

→ Leader cannot roll back or rewrite history, or equivocate, without many colluding followers

– Can't sign valid log entries without followers!

CoSi: Collective Signing

leader

followersCollectiveAuthority(cothority)

record1

public log

record2 record3

each record collectively signed

CoSi Crypto Primitives

Builds on well-known primitives:• Merkle Trees• Schnorr Signature and Multisignatures

CoSi builds upon existing primitives but makes it possible to scale to thousands of nodes• Using communication trees and aggregation,

as in scalable multicast protocols

Merkle Trees• Every non-leaf node labeled with the hash of the

labels of its children. • Efficient verification of items added into the tree• Authentication path - top hash and siblings hashes

A B C D

E=H(H(A)|H(B))

top hash

H(A) H(B) H(C) H(D)

F=H(H(C)|H(D))

?

G=H(H(E)|H(F))

Schnorr Signature• Generator g of prime order q group• Public/private key pair: (K=gk, k)

Signer Verifier

Commitment

Challenge

Response

V=gv

r = (v – kc)

c = H(M|V)

Commitment recovery

Challenge recovery

Decision

V' = grKc

c’ = H(M|V’)

c’ = c ?

Signature on M: (c, r)

= gv-kcgkc = gv = V

V

c

r

Collective Signing• Our goal is collective signing with N signers• Everyone produces a signature• N signers-> N signatures -> N verifications!• Bad for thousands of signers!

• Better choice – a multisignature

Schnorr Multisignature• Key pairs: (K1=gk1, k1) and (K2=gk2, k2)

Signer 1 Verifier

Commitment

Challenge

Response

V1=gv1

r1 = (v1 – k1c)

c = H(M|V1)

Commitment recovery

Challenge recovery

Decision

V' = grKc

c’ = H(M|V’)

c’ = c ?

Signature on M: (c, r)

V1

c

r1

c = H(M|V)

V2

r2

Signer 2

r2 = (v2 – k2c)

V2=gv2

c

Signature on M: (c, r1)

K=K1*K2

V=V1*V2

r=r1+r2

Same signature!

Same verification!Done once!

K3, PK{k3 | K3=gk3}K3 = K3

CoSi Protocol Setup

Merkle tree containing:

● Public keys Ki(discrete-log)

● Self-signed Certificates

● Aggregate keys Ki

O(n) one-time verify costO(|n'-n|) group change

K4, PK{k4 | K4=gk4}K4 = K4

K2, PK{k2 | K2=gk2}K2 = K2K3K4

K1, PK{k1 | K1=gk1}K1 = K1K2...KN

CoSi Protocol Rounds1. Announcement Phase

2. Commitment Phase

3. Challenge Phase

4. Response Phase

V3 = gv3,V3 = V3

CoSi Commit Phase

Merkle tree containing:

● Commits Vi

● Aggregatecommits Vi

Collective challenge cis root hash ofper-roundMerkle tree

V4 = gv4,V4 = V4

V2 = gv2,V2 = V2V3V4

V1 = gv1,V1 = V1V2...VN

Challengec = H( )

r3 = v3 - k3c,r3 = r3

CoSi Response Phase

Compute

● Responses ri

● Aggregateresponses ri

Each (c,ri) formsvalid partial signature

(c,r1) formscompletesignature r4 = v4 - k4c,

r4 = r4

r2 = v2 - k2c,r2 = r2+r3+r4

r1 = v1 - k1c,r1 = r1+r2+...+rN

(c,r1)

Collective Public Randomness

Any/all servers in tree contribute (ideally true) randomness via secrets vi and commitments Vi

Collective random outputis final response r1

● Unpredictableto all participants

● Tamper-resistant

● Bias-resistant(with caveat)

v1

v3

Talk Outline







The Availability Problem

Assume server failures are rare but non-negligible● Availability loss, DoS vulnerability if not addressed

● But persistently bad servers administratively booted

Two approaches:

● Exceptions – currently implemented, working

● Life Insurance – partially implemented, in-progress

Approach 1: Exceptions• If node A fails, the remaining nodes can provide a

valid signature but• For a modified collective key: K’= K * K-1A

• Using a modified commitment: V’= V * V-1A

• And response: r’= r – rA

• Client gets a signature under K’ along with an exception eA

• eA also lists conditions under which it was issued

• Client accepts only if a quorum of nodes maintained

Public Randomness: The Caveat

Current version with exceptions for availability:

● Protects from anyone predicting the future

● Protects from anyone rigging the outcome

● Not fully bias-protected if leader is malicious

Attack: assume leader colludes with k followers

● Followers pretend to be offline in 2k configs

● Leader picks “best” of 2k possible outcomes

Approach 2: Life insurance• Node "insures" its private key by depositing the key

shares with other servers (insurers)• If node fails, others recover the key and continue• Use Shamir verifiable secret sharing (VSS)

s1

s2

s3

Unbiasable Public Randomness

Life insurance approach can fix bias vulnerability

● Collective commits to single unknown value– Aggregate secret v1 combines every secret vi

– Fully unpredictable if any server is honest

● Collective response can be only one value– Response r1 depends only on k1, v1, c

– Fully unbiasable if protocol completes at all

Leader could still “self-DoS-attack”…but such failures are rather noticeable

Talk Outline







Implementation● Implemented in Go with dedis crypto library

– https://github.com/DeDiS/crypto

● Schnorr multisignatures on Ed25519 curve– AGL's Go port of DJB's optimized code

● Run experiments on DeterLab– Up to 4096 virtual CoSi nodes

– Multiplexed atop up 32 physical machines

– Latency: 100ms roundtrip between two servers

https://github.com/DeDiS/crypto

Preliminary Results

Preliminary Results

Preliminary Results

Talk Outline







Logging and Timestamping

Already (or close to) usable for:

● Tamper-evident logging– History rewriting protection

– Equivocation protection

● Secure timestamping– Pre/post-dating protection

● Large-scale Byzantine Consensus– Propose/commit, view changes implemented

– Still need validation, evaluation, optimization

Secure Randomness/Lotteries

Current version with exceptions for availability:

● Protects from anyone predicting the future

● Protects from anyone rigging the outcome

● Not yet fully bias-protected if leader malicious

Shamir secret-sharing version can fix bias risk

● Collective commits to single unknown value

● Ensures exactly that value as ultimate output

Certificate Cothorities

Alice (Victim)

CAs

DigiNotarStolen CA Private Key

AttackFails

Real

Witnesses, MonitorsSTOP!Can't ForgeCertificate

withoutactive checking

Certificate Cothorities

Proactive protection against fake certs, MITM

● Ideal: browser vendor leads a cothority– CAs join, check and collectively sign all certs

– Any CA can block signature if cert violates policy● e.g., only Google CA can sign 'google.com' cert

● Alternative: root CA leads a cothority– Migrates sub-CAs into cothority membership,

phases out availability of delegated authority

● Alternative: based on Certificate Transparency– Log servers as cothorities, collectively signed SCTs

A Better Blockchain?Decentralized consensus, secure ledgers

● Without proof-of-work, massive power waste

● Without risk of temporary forks

● Without 51% attack vulnerability

● Stronger protection for clients, “light” nodes– Just check one log-head signature for correctness

● Efficient: with FawkesCoin hash-based ledger,just one public-key crypto operation per round

● Scalable: every server need not store, verifyevery record throughout blockchain history

Conclusion

Cothorities build on old ideas● Distributed/Byzantine consensus protocols● Threshold cryptography, multisignatures

Show that they can scale to thousands of servers● Strongest-link security among many witnesses● Practical: demonstrated for 4000+ servers● Efficient: 1.5-second signing latency at scale

More details: http://arxiv.org/abs/1503.08768

http://arxiv.org/abs/1503.08768

Date post:	25-Jun-2020
Category:	Documents
Upload:	others
View:	2 times
Download:	0 times

Decentralizing Authorities into Scalable Strongest-Link ... › dissent › pres ›...

Documents