Page 124 - Kaleidoscope Academic Conference Proceedings 2021

2021 ITU Kaleidoscope Academic Conference

4.2 Beacon usecase

4.2.1 Contract signing

Contract signing is an important use case for stochastic
beacon services [30]. Consider a commodity provider, Alice,
who wants to sell a commodity to Bob at a certain price. If
Bob accepts the quoted price, then Alice and Bob commit to
a contract and execute the transaction. A common situation is
that Alice and Bob cannot get together and wish to negotiate
over the Internet. If, in the absence of special protection,
they communicate directly with each other, a situation may
arise in which Alice signs a contract denoted by and sends
it to Bob, but Bob delays signing it. This leads to an unfair
Figure 2 – The schematic demonstration of a complete chain
of trust. situation where Bob can use this delay to find other providers.
Compared to Bob, Alice become a passive one.
4.1 Architecture of randomness beacon To overcome this dilemma, a trusted third party can be
involved. A usual third party is an intermediary who plays
the role of a trusted notary, and this is done primarily by the
post office. Alice and Bob should first send the contract they
The output of a random beacon to the public is often referred signed to the third party. Only when he gets the two copies,
to as a pulse, and it consists of randomness with a timestamp. he sends them to Alice and Bob, who then commit to the
In the last decade, much progress has been made in beacon contract. However, this approach is highly centralized. In
formats and methods for extracting randomness from entropy addition, since the transaction would be handed over directly
sources [32, 33]. According to the NIST beacon format and to an intermediary, its liability could be problematic, as errors
protocol, a random beacon outputs a pulse containing 512 could occur.
random bits, timestamp, signature, and hash link every 60 In the field of block chain, the atomic swap protocol [31] is
seconds. It contains several components: the beacon pulse also proposed to address such problems. The random beacon
engine, the DIQRNG source, the time server, the security service based on DIQRNG provides an alternative solution,
module, and the web server. The beacon pulse engine as shown in Figure 3. Alice and Bob should communicate
generates the corresponding signed beacon pulses based on directly with each other and start communication at an initial
the timestamp and random value. In order to achieve a time 0 . Alice and Bob should each choose a random
complete random distribution system, security must be also number 0 and 0 . They should agree on a random number
implemented in randomness distribution. It needs to use 0 = ( 0 + 0 ) and send each other a signature of
RSA and Post Quantum Cryptography (PQC) algorithm to ( , 0 , 0 ) and each sign with their own signature that can
provide the signature in security module. Each pulse has a be verified by the other party. After this, before the time
timestamp and digital signature, and contains the hash value 0 + Δ , s/he exchange signed contracts including 0 . For an
of the previous random number block to prevent tampering honest party, he/she stops if the other party does not send
of the generated data. the required information in the corresponding period, or if
the random number they agree on during 0 + Δ starting
at 0 + Δ matches the random number generated by the
As shown in Figure 2, the PQC signature algorithm and the randomness beacon at 0 + Δ . Alice is considered to be
RSA signature algorithm can be used for dual authentication committed to the contract at 0 + Δ time only if Bob can
during the beacon signaling from the server to the user. The provide the following three items:
local DIQRNG source can provide the random numbers for 1) Produce Alice’s signed contract.
the public and private keys required for RSA and PQC. The 2) Produce Alice’s signed message ( , 0 + Δ ).
public key is open to all and the message is signed with 3) Produce the beacon-signed message ( , 0 + Δ ).
the private key. So that a complete chain of trust from the The requirements for Bob to be committed to contract are
entropy source to the user is achieved. This trust chain is the same in the case that the names of "Alice" and "Bob" are
built on a number of foundations. The trustworthiness of interchanged. In addition, the randomness beacon service
the entropy source comes from the correctness of quantum will always generate a signed random number at 0 + Δ ( =
mechanics, and the security of the beacon signal transmission 0, 1, 2, · · · ) time. If the range of the random number is [0, −
comes from the identity authentication based on PQC and 1], then the expected time for honest parties to commit to the
RSA. Even different randomness beacon servers owned by contract will be Δ . On the other hand, if one party (Bob)
different countries or institutions can build a randomness intends to cheat Alice, he will not send Alice the contract
beacon together. Users do not need to trust a particular he signed during [ , + Δ ]. The only scenario in which
country or institution, we only need to trust that different he might succeed (he generates the information in the claim
countries or institutions will not join together to deceive the presented above, which convinces the adjudicator that Alice
public. should commit to the contract) is that the random number

– 62 –