eﬃcientasynchronous(...

Efficient Asynchronous Accumulators for Distributed PKI

Sophia Yakoubov

Joint work with Leo Reyzin

1

Outline

•  MoGvaGon: Distributed PKI •  Background: Accumulators •  Our ContribuGons: Asynchronous Accumulators – DefiniGon: verificaGon works even if the accumulator and witness are out of synch

– ConstrucGon

2

ApplicaGon: PKI

3

“I’m Bob” PKB

SKB

PKB

PKCA

SKCA

PKCA

PKCA

PKB Bob, CA

PKI goals: Enable Alice to associate Bob’s idenGty with Bob’s

public key

PKI goals: •  Accurate RegistraGon •  IdenGty RetenGon (We do not consider

revocaGon here.)

ApplicaGon: PKI

4

“I’m Bob” PKE

SKE

PKE

PKCA

SKCA

PKCA

PKCA

PKE Bob, CA

Eve

Problem: CerGficate AuthoriGes are a

single point of failure!

Problem: CerGficate AuthoriGes are a Single Point of Failure!

TrusGng central authoriGes is a risk. •  Verisign

–  (2010) Was repeatedly infiltrated, potenGal compromised informaGon includes secret signing keys

•  Comodo –  (2011) Issued erroneous cerGficates

•  DigiNotar –  (2011) Issued cerGficate for Google to someone who wasn’t Google

•  TrustWave –  (2012) Issued root cerGficate to customers, enabling them to issue

other cerGficates •  Symantec

–  (2015) Issued cerGficates for Google without it’s knowledge

5

Ensuring IdenGty RetenGon: DecentralizaGon via a Public BulleGn Board

6

•  Append-‐only •  Consensus protocol ensures that posts are “valid” •  Implemented via blockchains –  formalized by [PSs16, GKL16] –  Validity check performed by miners

Problem: expensive lookup! Alice needs to search through the enGre bulleGn board.

Problem: expensive storage / access! Alice needs to maintain online access to the enGre bulleGn board.

Decentralized PKI

7

“I’m Bob” PKB

SKB

Valida2on: the idenGty “Bob” has not already

been registered (ensures idenGty

retenGon)

locaGonB

Outline

•  MoGvaGon: Distributed PKI •  Background: Accumulators

–  [BdM94,CL02,LLX07,Ngu05,DT08,ATSM09,CHKO08…]

•  Our ContribuGons: Asynchronous Accumulators – DefiniGons – ConstrucGon

8

SoluGon: accumulators

•  Accumulator: compact commitment to set S

9

(Bob, PKB)

T = S + {(Bob, PKB)}

membership witness wB

can be used together with wB to verify that (Bob, PKB)

is in set T

Accumulator Example: Merkle Hash Tree

10

h(�)

h(�,�)

h(�) h(�) h(�)

h(�,�)

h(�,�)

(Frank, PKF) (Charlie, PKC) (Daniela, PKD) (Bob, PKB)


11

h(�)

h(�,�)

h(�) h(�) h(�)

h(�,�)

h(�,�)



12

h(�)

h(�,�)

h(�) h(�) h(�)

h(�,�)

h(�,�)


Using Accumulators in the BulleGn Board

•  Charlie, ,

•  Daniela, ,

•  Frank, ,

•  Bob, ,

13

PKB

PKC

PKD

PKF

Maintain an accumulator containing all (Name, PK) pairs

Accumulators in Decentralized PKI

14

“I’m Bob”, , wB

(Bob, PKB) wB

PKB

SKB PKB

Valida2on (e.g. by miners): (1)  Check that the idenGty “Bob” has not already

been registered (2)  Compute the new accumulator value

wB


15

h(�)

h(�,�)

h(�)

h(�,�)

h(�)

(Charlie, PKC) (Daniela, PKD)

(Frank, PKF)


16

h(�)

h(�,�)

h(�) h(�)

h(�,�)

h(�,�)


Charlie’s witness changed!

Problem: Synchrony

17

Gme

wB

Using exisGng noGon of accumulators… •  Bob needs to update his membership witness with every key registraGon!

•  Alice needs to download a new accumulator value with every key registraGon!

wB wB wB wB wB wB wB wB wB

Outline

•  MoGvaGon: Distributed PKI •  Background: Accumulators •  Our ContribuGons: Asynchronous Accumulators – DefiniGons •  Low witness update frequency •  Old-‐accumulator compaGbility

– ConstrucGon: Merkle Hash Forrest

18

SoluGon: Asynchronous Accumulators -‐ Low Witness Update Frequency

19

Gme

Low witness update frequency

Gme

wB wB wB wB wB wB wB wB wB wB

wB wB wB wB

20

Gme

Gme

wB wB wB wB wB wB wB wB wB wB

wB wB wB wB

SoluGon: Asynchronous Accumulators -‐ Old Accumulator CompaGbility

Old-‐accumulator compaGbility

wB wB wB wB wB wB

Outline

•  MoGvaGon: Distributed PKI •  Background: Accumulators •  Our ContribuGons: Asynchronous Accumulators – DefiniGons •  Low witness update frequency (helping Bob) •  Old-‐accumulator compaGbility (helping Alice)

– ConstrucGon: Merkle Hash Forrest

21

Asynchronous Accumulator: Merkle Hash Forest

22

•  At most log(n) complete Merkle trees •  Each element is a leaf in one of the trees •  As new elements get added, older elements move to bigger trees


23

D = 1

This is similar to a binary counter… 1 element

1


24

0

D = 2

1

This is similar to a binary counter… 2 elements


26

1

D = 2

1

D = 1



27

0 0

D = 3

1



28

1 0 1

D = 1 D

= 3



29

0 1 1

D = 3

D = 2



30

1 1 1

D = 3

D = 2

D = 1



31

0 0 0 1



32

D = 1

1 0 0 1



33

0

D = 2

1 1 0



34

1

D = 2

1

D = 1

1 0



35

0 0

D = 3

1 1



36

1 0 1

D = 1 D

= 3

1



37

0 1 1

D = 3

D = 2

1



38

1 1 1

D = 3

D = 2

D = 1

1



39

0 1 0 0 0


•  Low update frequency •  A witness only needs to be updated when the tree in

quesGon is “carried”!

•  Old-‐accumulator compaGbility •  A witness is append-‐only; it contains all prior states

Merkle Hash Forest Asynchrony

40

D = 3

D = 2

D = 1

Conclusion •  BulleGn boards are good for distributed dicGonaries – Namecoin –  PKI

•  Accumulators improve efficiency –  no need to have access to the whole board

•  Asynchronous accumulators reduce the witness maintenance cost

•  A forest is beser than a tree! – More flexibility

41

eﬃcientasynchronous(...

Documents