The new NIST reference for Randomness Beacons Lu s Brand ao Joint - - PowerPoint PPT Presentation

▶
the new nist reference for randomness beacons
SMART_READER_LITE
LIVE PREVIEW

The new NIST reference for Randomness Beacons Lu s Brand ao Joint - - PowerPoint PPT Presentation

Oct 02, 2023 190 likes •1.42k views

The new NIST reference for Randomness Beacons Lu s Brand ao Joint work with: John Kelsey, Ren e Peralta, Harold Booth National Institute of Standards and Technology (Gaithersburg MD, USA) 1 1 1 1 0 1 1 0 1 1 0 1 0 0 0

slide-1
SLIDE 1

The new NIST reference for Randomness Beacons

Lu´ ıs Brand˜ ao Joint work with: John Kelsey, Ren´ e Peralta, Harold Booth

National Institute of Standards and Technology (Gaithersburg MD, USA)

Presentation at International Cryptographic Module Conference May 17, 2019 @ Vancouver, Canada

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

A d a p t e d f r
  • m
c l k e r . c
  • m
/ c l i p a r t
  • 1
9 5 9 3 2 . h t m l
slide-2
SLIDE 2

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

2/30

slide-3
SLIDE 3
  • 1. Introduction

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

3/30

slide-4
SLIDE 4
  • 1. Introduction

A Randomness Beacon

4/30

slide-5
SLIDE 5
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness.

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-6
SLIDE 6
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min)

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-7
SLIDE 7
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-8
SLIDE 8
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-9
SLIDE 9
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed ◮ Any past pulse is publicly accessible

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-10
SLIDE 10
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed ◮ Any past pulse is publicly accessible ◮ The sequence of pulses forms a hash-chain

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

4/30

slide-11
SLIDE 11
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed ◮ Any past pulse is publicly accessible ◮ The sequence of pulses forms a hash-chain

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

What can it be useful for? Not good for:

4/30

slide-12
SLIDE 12
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed ◮ Any past pulse is publicly accessible ◮ The sequence of pulses forms a hash-chain

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

What can it be useful for? Not good for: selecting your secret keys

4/30

slide-13
SLIDE 13
  • 1. Introduction

A Randomness Beacon

A service that produces timed outputs of fresh public randomness. High-level description:

◮ Periodically pulsates randomness (e.g., 1 per min) ◮ Each pulse has a fresh 512-bit random string ◮ Each pulse is indexed, time-stamped and signed ◮ Any past pulse is publicly accessible ◮ The sequence of pulses forms a hash-chain

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

Adapted from clker.com/clipart-195932.html

What can it be useful for?

◮ public auditability of randomized processes ◮ coordination between many parties ◮ prove something happened after a certain time

Not good for: selecting your secret keys

4/30

slide-14
SLIDE 14
  • 1. Introduction

Brief historical note

5/30

slide-15
SLIDE 15
  • 1. Introduction

Brief historical note

Some timeline events:

◮ 2013-Sep till 2018-Dec: NIST Beacon service version 1.0 online ◮ 2018-Jul till present: NIST Beacon service version 2.0 online ◮ 2019-May: “Draft NISTIR 8213” online — specifies the new (draft) Reference for Randomness Beacons (version 2)

5/30

slide-16
SLIDE 16
  • 1. Introduction

Brief historical note

Some timeline events:

◮ 2013-Sep till 2018-Dec: NIST Beacon service version 1.0 online ◮ 2018-Jul till present: NIST Beacon service version 2.0 online ◮ 2019-May: “Draft NISTIR 8213” online — specifies the new (draft) Reference for Randomness Beacons (version 2) The NIST Beacon will progressively implement all aspects of the Reference.

5/30

slide-17
SLIDE 17
  • 1. Introduction

This talk is about the NISTIR 8213 (draft)

“A Reference for Randomness Beacons: Format and Protocol Version 2”

https://doi.org/10.6028/NIST.IR.8213-draft

Draft NISTIR 8213

1 2

A Reference for Randomness Beacons

3

Format and Protocol Version 2

4

John Kelsey

5

Lu´ ıs T. A. N. Brand˜ ao

6

Ren´ e Peralta

7

Harold Booth

8

This publication is available free of charge from:

9

https://doi.org/10.6028/NIST.IR.8213-draft

10 11

6/30

slide-18
SLIDE 18
  • 1. Introduction

This talk is about the NISTIR 8213 (draft)

“A Reference for Randomness Beacons: Format and Protocol Version 2”

https://doi.org/10.6028/NIST.IR.8213-draft

Some topics in the report: ◮ format for pulses ◮ protocol for beacon operations ◮ using Beacon randomness ◮ security considerations

Draft NISTIR 8213

1 2

A Reference for Randomness Beacons

3

Format and Protocol Version 2

4

John Kelsey

5

Lu´ ıs T. A. N. Brand˜ ao

6

Ren´ e Peralta

7

Harold Booth

8

This publication is available free of charge from:

9

https://doi.org/10.6028/NIST.IR.8213-draft

10 11

6/30

slide-19
SLIDE 19
  • 1. Introduction

This talk is about the NISTIR 8213 (draft)

“A Reference for Randomness Beacons: Format and Protocol Version 2”

https://doi.org/10.6028/NIST.IR.8213-draft

Some topics in the report: ◮ format for pulses ◮ protocol for beacon operations ◮ using Beacon randomness ◮ security considerations Public comments till August 05, 2019.

Draft NISTIR 8213

1 2

A Reference for Randomness Beacons

3

Format and Protocol Version 2

4

John Kelsey

5

Lu´ ıs T. A. N. Brand˜ ao

6

Ren´ e Peralta

7

Harold Booth

8

This publication is available free of charge from:

9

https://doi.org/10.6028/NIST.IR.8213-draft

10 11

6/30

slide-20
SLIDE 20
  • 1. Introduction

This talk is about the NISTIR 8213 (draft)

“A Reference for Randomness Beacons: Format and Protocol Version 2”

https://doi.org/10.6028/NIST.IR.8213-draft

Some topics in the report: ◮ format for pulses ◮ protocol for beacon operations ◮ using Beacon randomness ◮ security considerations Public comments till August 05, 2019.

Draft NISTIR 8213

1 2

A Reference for Randomness Beacons

3

Format and Protocol Version 2

4

John Kelsey

5

Lu´ ıs T. A. N. Brand˜ ao

6

Ren´ e Peralta

7

Harold Booth

8

This publication is available free of charge from:

9

https://doi.org/10.6028/NIST.IR.8213-draft

10 11

Two goals in this presentation:

◮ Provide an overview of the new reference ◮ Motivate engagement: NISTIR feedback, new beacons and apps

6/30

slide-21
SLIDE 21
  • 1. Introduction

Components of the Beacon service, at a high level

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

DB

(web frontend)

Web

(users)

Fw

Legend:

  • App: software application
  • DB: database
  • Fw: firewall
  • HSM: hardware security module
  • RNG: random-number generator

queries replies

7/30

slide-22
SLIDE 22
  • 1. Introduction

Components of the Beacon service, at a high level

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

DB

(web frontend)

Web

(users)

Fw

Legend:

  • App: software application
  • DB: database
  • Fw: firewall
  • HSM: hardware security module
  • RNG: random-number generator

queries replies

But what exactly is a pulse, what is its randomness, ...?

7/30

slide-23
SLIDE 23
  • 2. Pulse format

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

8/30

slide-24
SLIDE 24
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

9/30

slide-25
SLIDE 25
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed

9/30

slide-26
SLIDE 26
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed

9/30

slide-27
SLIDE 27
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed

9/30

slide-28
SLIDE 28
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed ◮ Two main random values (“rands”): randLocal and randOut.

9/30

slide-29
SLIDE 29
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed ◮ Two main random values (“rands”): randLocal and randOut. ◮ Other features: signature

9/30

slide-30
SLIDE 30
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed ◮ Two main random values (“rands”): randLocal and randOut. ◮ Other features: signature, precommit randLocal

9/30

slide-31
SLIDE 31
  • 2. Pulse format

A pulse (simplified example)

uri:str="https://beacon.nist.gov/beacon/2.0/chain/1/pulse/220394" version:str="2.0" ... period:dec="60000" ... chainId:dec="1" pulseId:dec="220394" time:str="2018-12-26T16:07:00.000Z" randLocal:hex="5FF1E0C019C42C77FA72D522...(512 bits total)" ...

  • ut.Prev:hex="BA646CC4E7AE195D2C85E9D3...(512 bits total)"

... preCom:hex="269908B840E79BE71CEC4EBA...(512 bits total)" ... sig:hex="17943D886DA8C7C24B9244BE...(4096 bits total)" randOut:hex="0A8863E03E200F6940A009B0...(512 bits total)"

◮ Each pulse is indexed ◮ Two main random values (“rands”): randLocal and randOut. ◮ Other features: signature, precommit randLocal, chain randOut, ...

9/30

slide-32
SLIDE 32
  • 2. Pulse format

The two “rands” in a pulse

10/30

slide-33
SLIDE 33
  • 2. Pulse format

The two “rands” in a pulse

randLocal (a.k.a. local random value): randOut (a.k.a. output value):

10/30

slide-34
SLIDE 34
  • 2. Pulse format

The two “rands” in a pulse

randLocal (a.k.a. local random value):

◮ Hash (SHA512) of randomness output by ≥ 2 RNGs ◮ Pre-committed 1 minute in advance of release ◮ Useful for combining beacons

randOut (a.k.a. output value):

10/30

slide-35
SLIDE 35
  • 2. Pulse format

The two “rands” in a pulse

randLocal (a.k.a. local random value):

◮ Hash (SHA512) of randomness output by ≥ 2 RNGs ◮ Pre-committed 1 minute in advance of release ◮ Useful for combining beacons

randOut (a.k.a. output value):

◮ Hash of all other fields ◮ Fresh at the time of release ◮ The actual randomness to be used by applications

10/30

slide-36
SLIDE 36
  • 2. Pulse format

The two “rands” in a pulse

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110...

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011...

11/30

slide-37
SLIDE 37
  • 2. Pulse format

The two “rands” in a pulse

randLocal: ri+1 = Hash(ρ1,i || ρ2,i [|| ρ3,i]), with random ρj,i from ith RNG

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110...

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011...

11/30

slide-38
SLIDE 38
  • 2. Pulse format

The two “rands” in a pulse

randLocal: ri+1 = Hash(ρ1,i || ρ2,i [|| ρ3,i]), with random ρj,i from ith RNG preCom: Ci = Hash(ri+1), released 1 min before ri+1

Hash

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110...

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011...

11/30

slide-39
SLIDE 39
  • 2. Pulse format

The two “rands” in a pulse

randLocal: ri+1 = Hash(ρ1,i || ρ2,i [|| ρ3,i]), with random ρj,i from ith RNG preCom: Ci = Hash(ri+1), released 1 min before ri+1

Hash

Mi

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110...

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011... Mi

Hash

randOut: Ri = Hash(Mi), with Mi being the serialization of all previous fields

11/30

slide-40
SLIDE 40
  • 2. Pulse format

The two “rands” in a pulse

randLocal: ri+1 = Hash(ρ1,i || ρ2,i [|| ρ3,i]), with random ρj,i from ith RNG preCom: Ci = Hash(ri+1), released 1 min before ri+1

Hash

Mi

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110... =

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011... Mi

Hash

randOut: Ri = Hash(Mi), with Mi being the serialization of all previous fields

  • ut.Prev has the output value (Ri) of the previous pulse

11/30

slide-41
SLIDE 41
  • 2. Pulse format

The two “rands” in a pulse

randLocal: ri+1 = Hash(ρ1,i || ρ2,i [|| ρ3,i]), with random ρj,i from ith RNG preCom: Ci = Hash(ri+1), released 1 min before ri+1

Hash Hash

Mi

Pulse i

Ti=2019-05-17T16:13:00.000Z

...

  • ut.Prev: Ri-1=0110...

... randLocal: ri = 1001... preCom: Ci = 0101... ... sig: Si = 1010... randOut: Ri = 1110... =

Pulse i+1

Ti=2019-05-17T16:14:00.000Z

...

  • ut.Prev: Ri = 1110...

... randLocal: ri+1 = 1101... preCom: Ci+1 = 0010... ... sig: Si+1 = 0111... randOut: Ri+1 = 1011... Mi

Hash

randOut: Ri = Hash(Mi), with Mi being the serialization of all previous fields

  • ut.Prev has the output value (Ri) of the previous pulse

11/30

slide-42
SLIDE 42
  • 3. Beacon Protocol

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

12/30

slide-43
SLIDE 43
  • 3. Beacon Protocol

Beacon proper operation

◮ Timing and entropy requirements ◮ Beacon interface: getting pulses and skiplists ◮ Others (not here): external values, status fields, ...

13/30

slide-44
SLIDE 44
  • 3. Beacon Protocol

Timing requirements for generation and release

Time

π: intended pulsation period Ti Ti+1

14/30

slide-45
SLIDE 45
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)

Time

release Pi π: intended pulsation period release Pi+1 δ Ti δ Ti+1

14/30

slide-46
SLIDE 46
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability

Time

release Pi π: intended pulsation period release Pi+1 δ Ti δ Ti+1

14/30

slide-47
SLIDE 47
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆)

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-48
SLIDE 48
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-49
SLIDE 49
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ)

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-50
SLIDE 50
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ) ⇒ Timeliness

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-51
SLIDE 51
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ) ⇒ Timeliness
  • 5. Timestamp (non-repeating) indexation

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-52
SLIDE 52
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ) ⇒ Timeliness
  • 5. Timestamp (non-repeating) indexation ⇒ Unambiguity

start gen. Pi

Time

release Pi π: intended pulsation period start gen. Pi+1 release Pi+1 ∆ δ Ti ∆ δ Ti+1

14/30

slide-53
SLIDE 53
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ) ⇒ Timeliness
  • 5. Timestamp (non-repeating) indexation ⇒ Unambiguity

Ri: randOut ri: randLocal

start gen. Pi

Time

release Pi π: intended pulsation period

  • btain

Pi start gen. Pi+1

  • btain

Pi+1 release Pi+1 ri+1 Ri ∆ δ γ Ti ∆ δ γ ri+1 Ri Ti+1

14/30

slide-54
SLIDE 54
  • 3. Beacon Protocol

Timing requirements for generation and release

  • 1. No advanced release of pulse (δ ≥ 0)
  • 2. Generate with entropy (≥ 2 RNGs)
  • ⇒ Unpredictability
  • 3. Generate not too in advance (small ∆) ⇒ Freshness
  • 4. Release soon (small δ) ⇒ Timeliness
  • 5. Timestamp (non-repeating) indexation ⇒ Unambiguity

Ri: randOut ri: randLocal

start gen. Pi

Time

release Pi π: intended pulsation period

  • btain

Pi start gen. Pi+1

  • btain

Pi+1 release Pi+1 ri+1 Ri ∆ δ γ Ti ∆ δ γ ri+1 Ri Ti+1 (The reference document specifies allowed intervals for δ and ∆, relative to π)

14/30

slide-55
SLIDE 55
  • 3. Beacon Protocol

Fetching pulses

15/30

slide-56
SLIDE 56
  • 3. Beacon Protocol

Fetching pulses

Beacon App: a pulse release means sending the pulse to the database

Beacon App

Pulse

DB

(web frontend)

Web

(users)

Fw

queries replies

15/30

slide-57
SLIDE 57
  • 3. Beacon Protocol

Fetching pulses

Beacon App: a pulse release means sending the pulse to the database

Beacon App

Pulse

DB

(web frontend)

Web

(users)

Fw

queries replies

How do users request pulses from the database?

15/30

slide-58
SLIDE 58
  • 3. Beacon Protocol

Fetching pulses

Beacon App: a pulse release means sending the pulse to the database

Beacon App

Pulse

DB

(web frontend)

Web

(users)

Fw

queries replies

How do users request pulses from the database? uri/url

15/30

slide-59
SLIDE 59
  • 3. Beacon Protocol

Fetching pulses

Beacon App: a pulse release means sending the pulse to the database

Beacon App

Pulse

DB

(web frontend)

Web

(users)

Fw

queries replies

How do users request pulses from the database? uri/url

https://beacon.nist.gov/beacon/2.0/chain/last/pulse/last

Example: URI for the latest pulse in chain 1 of the NIST randomness Beacon (version 2)

15/30

slide-60
SLIDE 60
  • 3. Beacon Protocol

Skiplists — efficient chain verification

16/30

slide-61
SLIDE 61
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

16/30

slide-62
SLIDE 62
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

16/30

slide-63
SLIDE 63
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them

16/30

slide-64
SLIDE 64
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses Efficient: check the hash-chaining in a skiplist (< 125 pulses).

16/30

slide-65
SLIDE 65
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses).

16/30

slide-66
SLIDE 66
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

16/30

slide-67
SLIDE 67
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

2019-05-17 14:12 → 2019-01-01 00:00 → 2018-01-01 00:00 → 2017-01-01 00:00 →

16/30

slide-68
SLIDE 68
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

2019-05-17 14:12 → 2019-01-01 00:00 → 2018-01-01 00:00 → 2017-01-01 00:00 → 2016-12-01 00:00 → (1 per month) → 2016-03-01 00:00

16/30

slide-69
SLIDE 69
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

2019-05-17 14:12 → 2019-01-01 00:00 → 2018-01-01 00:00 → 2017-01-01 00:00 → 2016-12-01 00:00 → (1 per month) → 2016-03-01 00:00 → 2016-02-29 00:00 → (1 per day) → 2016-02-15 00:00

16/30

slide-70
SLIDE 70
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

2019-05-17 14:12 → 2019-01-01 00:00 → 2018-01-01 00:00 → 2017-01-01 00:00 → 2016-12-01 00:00 → (1 per month) → 2016-03-01 00:00 → 2016-02-29 00:00 → (1 per day) → 2016-02-15 00:00 → 2016-02-14 23:00 → (1 per hour) → 2016-02-14 18:00

16/30

slide-71
SLIDE 71
  • 3. Beacon Protocol

Skiplists — efficient chain verification

How to prove that an old pulse is consistent with a recent pulse?

Example: Anchor = 2019-05-17 14:12 → Target = 2016-02-14 17:45

Solution: check that there is a hash-chain linking them Inefficient: check the hash-chain of (>1M) consecutive pulses

2019-05-17 14:12 → 2019-05-17 14:11 → (1 per minute) → 2016-02-14 17:45

Efficient: check the hash-chaining in a skiplist (< 125 pulses). Use the 5 past output fields in the pulse format:

◮ out.Prev: the previous pulse ◮ out.H, out.D, out.M, out.Y: the first of the hour/day/month/year

2019-05-17 14:12 → 2019-01-01 00:00 → 2018-01-01 00:00 → 2017-01-01 00:00 → 2016-12-01 00:00 → (1 per month) → 2016-03-01 00:00 → 2016-02-29 00:00 → (1 per day) → 2016-02-15 00:00 → 2016-02-14 23:00 → (1 per hour) → 2016-02-14 18:00 → 2016-02-14 17:59 → (1 per minute) → 2016-02-14 17:45

16/30

slide-72
SLIDE 72
  • 3. Beacon Protocol

A possible diagram of pulse generation

HSM

Legend: - DB: database

  • : release not before timestamp
  • HSM: hardware security module
  • RNG: random-number generator
  • NTP: network time protocol

DB

  • ||: concatenation

Ei: external (srcId, status, value) (all-zeros when not available) NTP MDi: some metadata (uri, version, cipher, period, certId, chainId) Pasti = (Ri-1, RH[i-1], RD[i-1], RM[i-1], RY[i-1]): previous (i-1)

and 1st of {hour (H), day (D), month (M) and year (Y)} of previous Mi = MDi || i || Ti || ri || Ei || Pasti || Ci || zi

i: pulse index (integer, incremented by 1 for each released pulse) Ti: time (UTC string, ms precision, e.g., "2018-07-23T19:26:00.000Z") Time Server

(remote)

Clock

(on chip)

Hash of

external value Ri Ri

Pi (pulse) pulsify Pi = Mi || Ri || Si

RNG #1

(on chip)

Ci: preCom (512 bits)

RNG #2 Hash Hash

(randLocal of next pulse)

i,2 ri+1

(512 bits) (512 bits)

ri: randLocal (512 bits)

i,1 || i,2 [|| i,3]

RNG #3

(Quantum) i,3

(512 bits)

Local cache

Hash Hash ri+1 i,1

zi: status (32 bits)

Hash Hash* Ri: randOut Hi Si Mi || Si Hash Hash Mi Si: sig Signing* module Mi Si For simplicity, the diagram omits serialization details (e.g., field lengths and padding) and some metadata fields. 17/30

slide-73
SLIDE 73
  • 4. Using a Beacon

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

18/30

slide-74
SLIDE 74
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

19/30

slide-75
SLIDE 75
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]:

19/30

slide-76
SLIDE 76
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384

19/30

slide-77
SLIDE 77
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

19/30

slide-78
SLIDE 78
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

  • 1. Commit upfront:
  • 2. Derive a seed:
  • 3. Perform the operation:

19/30

slide-79
SLIDE 79
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

  • 1. Commit upfront: publish a statement S that explains my

deterministic operation that will use the Beacon randomness (the output value randOut) from future time t;

  • 2. Derive a seed:
  • 3. Perform the operation:

19/30

slide-80
SLIDE 80
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

  • 1. Commit upfront: publish a statement S that explains my

deterministic operation that will use the Beacon randomness (the output value randOut) from future time t;

  • 2. Derive a seed:

Get R = randOut[t] (from the pulse with timestamp t), and set the seed as Z = SHA512(S||R)

  • 3. Perform the operation:

19/30

slide-81
SLIDE 81
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

  • 1. Commit upfront: publish a statement S that explains my

deterministic operation that will use the Beacon randomness (the output value randOut) from future time t;

  • 2. Derive a seed:

Get R = randOut[t] (from the pulse with timestamp t), and set the seed as Z = SHA512(S||R)

  • 3. Perform the operation:

Do what the statement S promised, using Z as the seed for all needed pseudo-randomness.

19/30

slide-82
SLIDE 82
  • 4. Using a Beacon

Using Beacon randomness (if I trust the beacon)

(some simplifications for presentation purpose)

Simply getting a practically uniform number in [0, N − 1]: ◮ Just calculate randOut (mod N), if N < 2384 If I want future auditability of a randomized operation:

  • 1. Commit upfront: publish a statement S that explains my

deterministic operation that will use the Beacon randomness (the output value randOut) from future time t;

  • 2. Derive a seed:

Get R = randOut[t] (from the pulse with timestamp t), and set the seed as Z = SHA512(S||R)

  • 3. Perform the operation:

Do what the statement S promised, using Z as the seed for all needed pseudo-randomness. We defer reference guidance to complementary future documentation

19/30

slide-83
SLIDE 83
  • 4. Using a Beacon

Combining Beacons

20/30

slide-84
SLIDE 84
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation?

20/30

slide-85
SLIDE 85
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude?

20/30

slide-86
SLIDE 86
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

20/30

slide-87
SLIDE 87
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut)

20/30

slide-88
SLIDE 88
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value)

20/30

slide-89
SLIDE 89
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value) ◮ R[t] = Hash(A[t].randLocal||B[t].randLocal)

20/30

slide-90
SLIDE 90
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value) ◮ R[t] = Hash(A[t].randLocal||B[t].randLocal)

(A & B could force repeating R[t])

20/30

slide-91
SLIDE 91
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value) ◮ R[t] = Hash(A[t].randLocal||B[t].randLocal)

(A & B could force repeating R[t])

Solution: get R[t] from two randLocal[t] and two randOut[t − π] values:

20/30

slide-92
SLIDE 92
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value) ◮ R[t] = Hash(A[t].randLocal||B[t].randLocal)

(A & B could force repeating R[t])

Solution: get R[t] from two randLocal[t] and two randOut[t − π] values:

R[t] = Hash(A[t − π].randOut||B[t − π].randOut||A[t].randLocal||B[t].randLocal)

20/30

slide-93
SLIDE 93
  • 4. Using a Beacon

Combining Beacons

What Beacon randomness R[t] to use if I do not trust any Beacon in isolation? ... but trust that two Beacons (A and B) will not collude? Desired properties:

◮ A single Beacon cannot bias the output; ◮ Even two colluding beacons cannot fully control the output.

Not good: ◮ R[t] = Hash(A[t].randOut||B[t].randOut) (A could wait to know B’s value) ◮ R[t] = Hash(A[t].randLocal||B[t].randLocal)

(A & B could force repeating R[t])

Solution: get R[t] from two randLocal[t] and two randOut[t − π] values:

R[t] = Hash(A[t − π].randOut||B[t − π].randOut||A[t].randLocal||B[t].randLocal)

Also need to check: ◮ reception of A[t − π].randOut and B[t − π].randOut before time T ◮ correctness of standalone pulses: A[t − π], B[t − π], A[t], B[t] ◮ hash-chaining (e.g., A[t].out.Prev = A[t − π].randOut) ◮ pre-commitments (e.g., Hash(A[t].randLocal) = A[t − π].preCom)

20/30

slide-94
SLIDE 94
  • 4. Using a Beacon

Some Beacons in development

Three countries are developing Beacons to match the current reference:

United States Brazil Chile

◮ (United States) NIST Randomness Beacon https://beacon.nist.gov/home ◮ (Chile) CLCERT Randomness Beacon https://beacon.clcert.cl/ ◮ (Brazil) Brazilian Randomness Beacon https://beacon.inmetro.gov.br/

21/30

slide-95
SLIDE 95
  • 4. Using a Beacon

Some Beacons in development

Three countries are developing Beacons to match the current reference:

United States Brazil Chile

◮ (United States) NIST Randomness Beacon https://beacon.nist.gov/home ◮ (Chile) CLCERT Randomness Beacon https://beacon.clcert.cl/ ◮ (Brazil) Brazilian Randomness Beacon https://beacon.inmetro.gov.br/

We would like others to join

21/30

slide-96
SLIDE 96
  • 4. Using a Beacon

Some conceivable applications

“You have been randomly selected for additional screening”

22/30

slide-97
SLIDE 97
  • 4. Using a Beacon

Some conceivable applications

“You have been randomly selected for additional screening” Example applications: ◮ Select test and control groups for clinical trials ◮ Select random government officials for financial audits ◮ Assign court cases to random judges ◮ Sample random lots for quality-measuring procedures ◮ Provide entropy to digital lotteries

22/30

slide-98
SLIDE 98
  • 4. Using a Beacon

Some conceivable applications

“You have been randomly selected for additional screening” Example applications: ◮ Select test and control groups for clinical trials ◮ Select random government officials for financial audits ◮ Assign court cases to random judges ◮ Sample random lots for quality-measuring procedures ◮ Provide entropy to digital lotteries Some generic goals: ◮ Prevent auditors from biasing selections (or being accused of it) ◮ Prevent auditees from addressing only the items to-be sampled ◮ Enable public verifiability of correct sampling

22/30

slide-99
SLIDE 99
  • 5. Brief security considerations

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

23/30

slide-100
SLIDE 100
  • 5. Brief security considerations

Security against intrusions

Security is “easy” in uncompromised scenario!

24/30

slide-101
SLIDE 101
  • 5. Brief security considerations

Security against intrusions

Security is “easy” in uncompromised scenario! But how to withstand compromised system components?

– Semi-honest (SH), aka honest-but-curious or passive: can exfiltrate internal state, but does not deviate from protocol – Malicious (Mal), aka byzantine or active: arbitrary behavior

24/30

slide-102
SLIDE 102
  • 5. Brief security considerations

Security against intrusions

Security is “easy” in uncompromised scenario! But how to withstand compromised system components?

– Semi-honest (SH), aka honest-but-curious or passive: can exfiltrate internal state, but does not deviate from protocol – Malicious (Mal), aka byzantine or active: arbitrary behavior

Why considering intrusions?

  • 1. We want trust to be leveled with trustworthiness — a security

analysis enables reflecting on meaningful security claims.

24/30

slide-103
SLIDE 103
  • 5. Brief security considerations

Security against intrusions

Security is “easy” in uncompromised scenario! But how to withstand compromised system components?

– Semi-honest (SH), aka honest-but-curious or passive: can exfiltrate internal state, but does not deviate from protocol – Malicious (Mal), aka byzantine or active: arbitrary behavior

Why considering intrusions?

  • 1. We want trust to be leveled with trustworthiness — a security

analysis enables reflecting on meaningful security claims.

  • 2. Even if operators believe in uncompromised

components at launch day, we want security in the long run, against conceivable adversarial threats (goals and capabilities).

24/30

slide-104
SLIDE 104
  • 5. Brief security considerations

Types of security properties (informal)

◮ Relational: correct hash chain, signatures, timestamps, consistent record (immutable past), ... ◮ Availability: timely pulse releases; accessible past pulses; automatic

  • peration (reduced human operator intervention); ...

◮ “Rands” quality: unpredictable; unbiaseable; fresh and independent;

25/30

slide-105
SLIDE 105
  • 5. Brief security considerations

Types of security properties (informal)

◮ Relational: correct hash chain, signatures, timestamps, consistent record (immutable past), ... ◮ Availability: timely pulse releases; accessible past pulses; automatic

  • peration (reduced human operator intervention); ...

◮ “Rands” quality: unpredictable; unbiaseable; fresh and independent; Attack consequences: ◮ breaking relational or availability properties typically leads to detectable errors, e.g., incorrect signatures or hash-chaining, delayed releases, ... ◮ next slides mention a few examples of attacks to the “rands” quality

25/30

slide-106
SLIDE 106
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components

26/30

slide-107
SLIDE 107
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components:

◮ I1. Mal Beacon App → randLocal control attack

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw

Legend: Mal=malicious

The red dancing devil clipart is from clker.com/clipart-13643.html

26/30

slide-108
SLIDE 108
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components:

◮ I1. Mal Beacon App → randLocal control attack ◮ I2. Mal Beacon App → randOut bias attack

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw

Legend: Mal=malicious

The red dancing devil clipart is from clker.com/clipart-13643.html

26/30

slide-109
SLIDE 109
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components:

◮ I1. Mal Beacon App → randLocal control attack ◮ I2. Mal Beacon App → randOut bias attack ◮ I3. Mal local-clock + SH DB → “rands” predict attack

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw DB Web Fw

Legend: Mal=malicious; SH=semi-honest; DB=database

The red dancing devil clipart is from clker.com/clipart-13643.html

26/30

slide-110
SLIDE 110
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components:

◮ I1. Mal Beacon App → randLocal control attack ◮ I2. Mal Beacon App → randOut bias attack ◮ I3. Mal local-clock + SH DB → “rands” predict attack ◮ I4. SH Beacon App → “rands” prediction attack

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw DB Web Fw

Legend: Mal=malicious; SH=semi-honest; DB=database

The red dancing devil clipart is from clker.com/clipart-13643.html

26/30

slide-111
SLIDE 111
  • 5. Brief security considerations

Intrusion scenarios

NISTIR 8213 considers several scenarios with intruded components:

◮ I1. Mal Beacon App → randLocal control attack ◮ I2. Mal Beacon App → randOut bias attack ◮ I3. Mal local-clock + SH DB → “rands” predict attack ◮ I4. SH Beacon App → “rands” prediction attack ◮ I5. Mal DB with HSM sign key → change-history attack

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw DB Web Fw

HSM

Clock RNG Beacon App RNG #3

Beacon Engine

Time server

Pulse RNG Sign

external entropy

Fw DB Web Fw

Legend: Mal=malicious; SH=semi-honest; DB=database

The red dancing devil clipart is from clker.com/clipart-13643.html

26/30

slide-112
SLIDE 112
  • 5. Brief security considerations

Conceivable mitigations

The NISTIR mentions some mitigations (either possible now or conceivable for the future)

27/30

slide-113
SLIDE 113
  • 5. Brief security considerations

Conceivable mitigations

The NISTIR mentions some mitigations (either possible now or conceivable for the future) For example, some could be based on the use of:

◮ publicly-verifiable external entropy (to reduce pre-computation window) ◮ verifiable delay functions ◮ secure time synchronization ◮ a different randLocal computation, with non controllable value ◮ different signature (e.g., > bit-strength, post-quantum, or/and threshold) ◮ a forward-chaining mechanism

27/30

slide-114
SLIDE 114
  • 6. Conclusion

Outline

  • 1. Introduction
  • 2. Pulse format
  • 3. Beacon Protocol
  • 4. Using a Beacon
  • 5. Brief security considerations
  • 6. Conclusion

28/30

slide-115
SLIDE 115
  • 6. Conclusion

Final Remarks

29/30

slide-116
SLIDE 116
  • 6. Conclusion

Final Remarks

◮ Randomness Beacons have a great potential to serve as a public utility, e.g., to promote public auditability of randomized processes

29/30

slide-117
SLIDE 117
  • 6. Conclusion

Final Remarks

◮ Randomness Beacons have a great potential to serve as a public utility, e.g., to promote public auditability of randomized processes ◮ The reference (NISTIR 8213) version 2 introduces new features for better interoperability, security and efficiency

29/30

slide-118
SLIDE 118
  • 6. Conclusion

Final Remarks

◮ Randomness Beacons have a great potential to serve as a public utility, e.g., to promote public auditability of randomized processes ◮ The reference (NISTIR 8213) version 2 introduces new features for better interoperability, security and efficiency ◮ Possible developments to be made: ◮ Complementary analysis and guidance ◮ Improvements based on feedback

29/30

slide-119
SLIDE 119
  • 6. Conclusion

Final Remarks

◮ Randomness Beacons have a great potential to serve as a public utility, e.g., to promote public auditability of randomized processes ◮ The reference (NISTIR 8213) version 2 introduces new features for better interoperability, security and efficiency ◮ Possible developments to be made: ◮ Complementary analysis and guidance ◮ Improvements based on feedback ◮ We would like to have your collaboration: ◮ public feedback on the NISTIR 8213 ◮ more deployed beacons ◮ external apps using Beacon randomness

29/30

slide-120
SLIDE 120
  • 6. Conclusion

◮ Draft NISTIR 8213: https://doi.org/10.6028/NIST.IR.8213-draft ◮ Email for feedback on the NISTIR 8213: beacon-nistir@nist.gov ◮ Beacon project: https://www.nist.gov/programs-projects/nist-randomness-beacon

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

A d a p t e d f r
  • m
c l k e r . c
  • m
/ c l i p a r t
  • 1
9 5 9 3 2 . h t m l

30/30

slide-121
SLIDE 121
  • 6. Conclusion

Thank you for your attention

◮ Draft NISTIR 8213: https://doi.org/10.6028/NIST.IR.8213-draft ◮ Email for feedback on the NISTIR 8213: beacon-nistir@nist.gov ◮ Beacon project: https://www.nist.gov/programs-projects/nist-randomness-beacon

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

A d a p t e d f r
  • m
c l k e r . c
  • m
/ c l i p a r t
  • 1
9 5 9 3 2 . h t m l

Presentation at the International Cryptographic Module Conference May 17, 2019 @ Vancouver, Canada

  • Disclaimer. Opinions expressed in this presentation are from the author(s) and are not to be construed as official or as views of the U.S.

Department of Commerce. The identification of any commercial product or trade names in this presentation does not imply endorsement of recommendation by NIST, nor is it intended to imply that the material or equipment identified are necessarily the best available for the purpose.

  • Disclaimer. Some external-source images and cliparts were included/adapted in this presentation with the expectation of such use constituting

licensed and/or fair use.

30/30