CrowdNotifier
Deployment and Implementation Notes
Version April 7, 2021
The CrowdNotifier Team
This document is an addendum to the CrowdNotifier white paper.1 The white
paper focuses on the high level design and the protocol. This document pro-
vides suggestions for implementation and deployment of CrowdNotifier:
• Entry QR codes. We unpack the abstract info string and give concrete
suggestions for what information should appear in the QR code and how
to encode it.
• Multiple location management. We show how to simplify the manage-
ment of tracing information when dealing with many locations. The white
paper assumes that each organizer manages a single location, and can
thus store the single tracing QR code containing the tracing information.
In reality, a single restaurant may consist of several different rooms, or
want to tag individual tables. A large company might want to manage
many (meeting) rooms at the same time. In these cases, storing trac-
ing QR codes for each location becomes cumbersome. Instead, we show
how a single tracing key can be used to manage all rooms and locations
under control of the same entity.
1 Entry QR codes
We revisit the components of the entry QR codes. As per the description in the
white paper, entry QR codes contain the values info, ent, 𝜋ent , notifykey. The
values ent, 𝜋ent and notifykey are internal to the CrowdNotifier protocol. The
goal of the string info is to describe the location.
In practice, the string info should contain structured data. The data contained
in info must be shown to the user, so that the user can verify that they are in-
deed checking in to the location described in info. Adding data in a structured
format helps apps to present it in a readable format.
We recommend that info encodes the following values:
• Name. The name of the location or organizer. For example, “MagiCorp
Lausanne”.
• Location. The geographical location. For example, “Lausanne”, or an ad-
dress. The goal is to uniquely identify a location.
• Room. The name of a specific room, when applicable. For example “Up-
stairs dining room”, “AX 11”, or “Red meeting room”.
1
see [Link] for the latest version
1
• Type. The type of location or event. For example “bar”, “restaurant”, “lec-
ture room”, or “meeting room”.
Other values, such as a longer description for specific events or a suggested
stay time to ease checkout, can be added based on the deployment scenario.
These values should be encoded in a compact structure, for example a proto-
buf. See the QRCodeContent and QRCodeEntry structures in of our reference
implementation as an example.2
2 Managing several locations
The approach described in the white paper produces one pair of QR codes for
each location: QRentry and QRtrace . In this section we explain how to gener-
ate several entry QR codes QRentry for different rooms, from one secret. This
removes the need to manage different values QRtrace per location.
2.1 A recap of the basic scheme
In the basic scheme described in the white paper the QR code generation takes
as input the description of the location info. The generation algorithm then
proceeds as follows:
1. It first computes a master public key mpk and two corresponding secret
keys: the master secret key mskL held by the location, and the encrypted
secret key ctxtHA for the health authority. It sets ent = mpk.
2. Then it picks random nonces nonce1 , nonce2 as well as a notification key
notifykey.3 It sets 𝜋ent = (nonce1 , nonce2 ).
3. Finally, it generates the data for the QR codes. The entry QR code con-
tains info, ent, 𝜋ent , and notifykey. The tracing QR code contains mtr =
(mpk, mskL , info, nonce1 , nonce2 , ctxtHA ) and notifykey.
Note that the tracing QR code largely consists of values that are also available
in the entry QR code. Only the values mskL and ctxtHA are private and specific
to the tracing process.
To initiate tracing, the venue and the health authorities use their respective
master secret keys to compute time-slot and location specific tracing keys.
These tracing keys take the form of identity-based decryption keys for the
identities
idhourctr = 𝐻(𝐻(info ∥ nonce1 ) ∥ hourctr ∥ nonce2 ),
2
Code here: [Link]
main/lib/src/v2/[Link]
3
Recall that the notification key is used to be able to send encrypted messages that only
(notified) visitors can read.
2
where hourctr corresponds to the time slot, for example encoded as hours
since UNIX epoch.
2.2 Managing multiple locations
In the basic scheme, location owners create one master public key (and cor-
responding private keys) per location. In this section we show how the same
master key can be used for all locations managed by a single organizer. Thus
drastically simplifying key management.
In the managed scheme, we perform step 1 of the key generation only once to
compute the master public key mpk and master secret keys mskL and ctxtHA .
We use the master public key mpk for all location managed by the same man-
ager. A local database stores other location/room specific data such as info,
nonce1 , nonce2 , and the notification key notifykey.
Given the local database, and the master secret keys, the manager can recover
all information needed for tracing, and compute the per location tracing keys.
In the following, we describe these steps in more detail below.
The security of tracing information hinges on keeping the master secret mskL
secure. In the following, we describe how this key can be derived from a
passphrase. As a result, no security-critical information needs to be stored
in the local database. The passphrase itself can be stored in a password man-
agement system.
Organization Setup. When creating an organization that manages several lo-
cations, the system will generate a strong passphrase of at least 256 bits of
entropy. The operator will store the passphrase securely, for example in a
password management system. The passphrase is the only security-critical
component and is only needed to initiate tracing of rooms. It is not needed to
add new rooms to the system.
First, setup now computes the organization’s master secret key4 as
mskL ← 𝐻(passphrase) mod 𝑝,
mskL
where 𝑝 is the group order and mpkL = 𝑔2 the corresponding owner’s public
key. In this case the output of 𝐻 should be much longer than the bit length of 𝑝.
For example, using SHA512 for 𝑝 of 256 bits. Alternatively, mskL can be directly
computed by an appropriate method for hashing to the field ℤ𝑝 if provided by
the cryptographic library.
It then proceeds as in the original QR code generation process to compute the
health authority key-pair mpkHA , mskHA ; the encrypted master secret key ctxtHA
4
For consistency of notation, we will keep writing mskL and mpkL subscripted with “L”.
3
for the health authority; and the master public key mpk = mpkL ⋅ mpkHA . See
the white paper for the details.
The system then stores mpk and ctxtHA in the local database. It does not store
any of the other generated values.
Adding a room. To add a room, the operator supplies the information describ-
ing the room so that the string info can be computed. See also section 1. The
system then proceeds as in the basic scheme, except that it uses the master
public key mpk from the database:
1. Retrieve mpk from the local database.
2. Pick random nonce nonce1 , nonce2 and a notification key notifykey. Let
𝜋ent = (nonce1 , nonce2 ).
3. Generate the entry QR code containing info, ent = mpk, 𝜋ent , notifykey.
4. Store a new record in the database for this room containing info, nonce1 ,
nonce2 , and notifykey.
The entry QR code can be regenerated from the data stored in the database if
needed.
Tracing/notifying a room. To initiate tracing, the health authority contacts the
operator and specifies the room for which it wants to notify the visitors. The
operator uses the passphrase generated initially to recover the information
that would normally be in the tracing QR code as follows:
1. Use the provided passphrase passphrase to recompute the organization’s
master secret key mskL .
2. Retrieve the master public key mpk and the encrypted master secret key
ctxtHA of the health authority from the database.
3. For the room specified by the health authority, retrieve the values nonce1 ,
nonce2 , and notifykey from the local database.
4. Reconstruct the room-specific master trace record mtr = (mpk, mskL , info,
nonce1 , nonce2 , ctxtHA ) and proceed as in the white paper to generate
time-slot specific pre-tracing keys.