This website has been mostly translated automatically from the original version. We apologize for any translation errors.

System concept

This document describes a privacy-friendly protocol & system for mediating appointments between two parties. It will be used, among other things, to arrange privacy-friendly vaccination appointments as part of the Covid-19 pandemic.


There are the following basic players in the system:

  • Users book appointments with providers (e.g. doctors).
  • Providers make appointments available to users.
  • Mediators build trust between actors in the system and perform administrative tasks.
  • Backend operators run the IT infrastructure needed for communication between the players.


The privacy and security of users and providers should be protected as much as possible. Mediators as well as back-end operators should not be able to obtain sensitive information about users or providers. They should also not be able to obtain details of brokered appointments, away from information publicly available on the system. Mediators and back-end operators should nevertheless be able to detect and prevent misuse of the system (if necessary with the support of users and providers).

The system should also be as robust as possible against abuse by users and providers. In particular, it is intended to prevent rogue providers or external attackers from contacting or obtaining data from users through the system, or actors using spamming or other techniques to impair the functionality of the system for legitimate users or providers. Compromise of individual system components or actors should have minimal impact on the privacy or security guarantees of the system. Protected information stored in the system should be able to be independently checked by client applications without having to explicitly trust the backend.

Assets worth protecting are defined as part of the risk analysis. The main objectives for the protection of the assets are to ensure confidentiality, especially for the exchange of data between users and providers, and trustworthiness of data, especially for the published vaccination dates.

System components

The system consists of the following components:

  • User Frontend : A web/desktop/mobile application used by users to register and book or cancel appointments.
  • Provider Front End : A web/desktop/mobile application used by providers to enroll and assign and manage appointments.
  • Mediator Front End : A web/desktop/mobile application used by mediators to verify providers, monitor the system, and curb abuse.
  • Data & Authentication Backends : An API-based backend system that stores encrypted and/or signed data from the above actors, authenticates providers, and cryptographically signs data from users.

Procedure for arranging appointments

Providers publish appointments in the backend.
Users retrieve open appointments from the backend.
Users book open dates.
Providers retrieve appointment bookings from the back end.

Appointments are arranged in several predominantly automated and asynchronous steps:

  • Mediators are registered by the backend operator.
  • Providers register and request verification through mediators.
  • Mediators verify providers and thus grant them access to the system.
  • Providers post appointment listings that are either completely public or can be accessed by authenticated users.
  • Users register and can view appointment listings for a given catchment area.
  • Users select and book an appointment from the offers and transmit encrypted data with a booking code to providers.
  • Providers verify the encrypted user data and confirm the booked appointments.
  • Users and providers may change or cancel booked appointments.

In general, the system already minimises personal data, which would also allow for unencrypted exchange of data between users and providers in the context of the risk analysis. In order to make any necessary adjustments to the system future-proof, however, end-to-end encryption has already been implemented at the application level for data exchange between users and providers.

Authentication & Encryption

All actors have several long-lived EC-key pairs which they use for signing data via ECDSA as well as for the encrypted exchange of data via ECIES (ECDH(E) + AES-GCM) (details below). In addition, they can create short-lived key pairs for data exchange.

Actors are identified in the system by their ECDSA public key. They authenticate all data they send to the backend or other actors by ECDSA signatures 1.

Trust in keys is granted by a certificate chain:

  • Mediator keys and associated data are signed with a root key.
  • Provider keys and associated data are signed with Mediator keys.
  • Appointment data is signed with provider keys.
  • Hashes of user data and user tokens are signed with a token key, associated HMAC values are authenticated with a token secret.

Here, both ECDSA and ECDH keys are signed. With the exception of users, who are anonymous and are not subject to any trust checks in the system, all actors in the system are authenticated by decentralized trust anchors. The root key is provided by the backend as well as in the apps.

Keys are explicitly pinned in the system, only keys that are present in the global key list in the backend are considered valid by the apps, accordingly no key revocation lists are maintained.

In addition to encryption at the application level, transport encryption via TLS standard is consistently used for the transmission of data. Data stored in the backend can also be encrypted during persistence (encryption at rest). However, the implementation of these encryption measures is the responsibility of the system operator and, with the exception of TLS encryption, is not mapped by the Kiebitz core software.


The encryption of data in the system is carried out using symmetrical as well as hybrid encryption methods. AES-GCM is used as the symmetric method because it provides authenticated encryption and is well suited for the given data sizes in the system. ECIES based on the NIST P-256 curve is used as a hybrid method 2. When implementing the procedures, the BSI recommendations for cryptographic mechanisms and key lengths BSI TR-02102-13 were followed, additionally NIST guidelines for areas without BSI recommendations (e.g. entropy/length of the secrets used for key derivation), if applicable. Another selection criterion for the cryptographic methods was the availability of standardized implementations in browser-based Javascript and Golang.

Cryptographic parameters

The following parameters were chosen for the used cryptographic methods according to the BSI recommendations, as well as supporting the NIST recommendations 4

Name Value
Key length (bits) 256
Tag length (bits) 128
IV length (bits) 96
Curve NIST P-256
Key derivation via PBKDF2
Hash method SHA-256
Iterations 100.000
Salt length (bits) 128
Key derivation via HKDF
Hash method SHA-256
Salt length (bits) 128
Random number generation
Procedure (Browser) Crypto.getRandomValues()
Procedure (Backend) crypto/rand
Secret lengths for key derivation
User secret (bits) 80 4
Provider secret (bits) 140
HMAC procedure
Hash function SHA-256

The implementation of the essential cryptographic functionality is open source and publicly available for the backend and frontend. In the browser the Web Cryptography API 5 was used for implementation, in the backend the crypto module of the Golang standard library 6.

Key Management

Keys are generated and stored in different places in the system. Root & token keys as well as the token secret are created locally using the kiebitz software. The root public key as well as the public and private token keys and the token secret are provided to the backend in the form of key files and settings files, respectively. The private root key is provided as a file and must be kept securely by administrators. Intermediary keys are also created locally using the kiebitz software, signed locally by the software and then stored in the backend. The creation and signing of keys can be done separately, so administrators do not need to know about private mediator keys.

Long-lived provider and user keys are generated in the browser as part of the registration process. User keys are then stored encrypted in the storage backend, while provider keys are stored locally in an encrypted file. Short-lived keys are created on demand for both providers and users and stored locally or encrypted in the storage backend, as appropriate.

In general, long-lived keys should only be used for signing data, since the long-term use of static ECDH keys and the keys derived from them entails security risks (e.g. IV repetition in the case of identical keys, no "perfect forward secrecy", etc.).

Key exchange

ECDSA & ECDH keys can be exchanged on the fly, with the effort varying depending on the key exchanged:

  • If the root ECDSA key is replaced, all signed Mediator keys and data must be signed with the new root key.
  • If a Mediator ECDSA key is replaced, all provider keys & data signed with this key must be signed with another or the new Mediator key.
  • If a provider ECDSA key is replaced, all appointment invitations signed with this key must be signed with the new key. For this purpose, a change management process may be necessary in which the old key is first marked as inactive and then replaced in a second step.

ECDH keys can also be exchanged; in this case, data encrypted with these keys may have to be re-encrypted. This applies in particular to data that users transmit to providers.

Embedding in the web browser

Implementing secure end-to-end encryption at the application level for browser-based applications is not easy, since web browsers provide basic cryptographic functionality but leave aspects such as key management to the application and do not provide mechanisms for independent integrity checking of the running web application. Accordingly, the backend that provides the Web application must be implicitly trusted, as must the browser environment in which the application is executed. The web application should therefore be made available as independently as possible from the backend. Alternatively, the use of a desktop application can be considered, which offers additional control mechanisms for checking the application code. Likewise, a locally installed browser extension may provide additional protection against tampered application code.

Securing the key material necessary for encryption in the browser is also difficult. When stored in local browser storage (localStorage or sessionStorage), simple extraction by application code running on the same origin is possible. Accordingly, no other code (e.g. third-party scripts) should be executed on the application domain. If stored in application memory, key material must be re-imported each time the page is reloaded.

Deletion concept

Generally, all data with personal reference is deleted automatically. All appointment booking data is deleted one day after the appointment date has expired. By default, encrypted user data is deleted after 30 days of inactivity, but the period is configurable in the system. Apart from this, no personal data is stored in the system. If necessary, hashed IP addresses are stored for the purpose of limiting requests (rate limiting), which may also constitute personal data; these are deleted at the latest after expiry of the underlying limitation period (maximum one hour). Database backups are kept for a maximum of 30 days.

Opportunities for improvement

Currently, static or at least long-lived cryptographic keys are used in several places in the system. For better security and to ensure "perfect forward secrecy", only short-lived key pairs should be used for any data exchange in the system.

The security of the crytographic key material in the system also needs to be improved. User key pairs are stored encrypted in the storage backend, the associated key may not provide enough security with 80 bits and should be protected with additional information (e.g. zip code) 7. Long-lived provider keys, on the other hand, are stored locally and are currently protected with a 140-bit random value. However, local storage in an encrypted file also involves risks, since this file must be kept on every terminal with which the provider logs on to the system. The use of hardware tokens would therefore be preferable for storing the key material, but cannot realistically be afforded by all providers in view of the short-term rollout. Nevertheless, the use of such procedures for the storage of key material should be investigated and, if necessary, implemented, even if not all actors have access to them. If necessary, TPM 2.0 modules, which are available on many modern systems, can be used to perform cryptographic operations. However, this requires the installation of browser extensions and possibly special desktop software, as TPM functions cannot currently be used from the browser.

Root key files as well as key files required for the backend are also currently not explicitly password protected and must be kept secure by administrators. If necessary, explicit encryption should be provided for this purpose in order to reduce the risk of insecure storage due to negligence.

  1. In general, BSI TR 02102-1 advises against using keys used for signing data for instance authentication as well. However, Kiebitz does not perform instance authentication in the narrower sense, so in our view the use of the signature key for communication with the backend is acceptable. 

  2. EC methods based on Curve25519 would certainly be preferable, but are currently not available natively implemented in browser environments. 

  3. BSI TR 02102-1 - version of January 2021 

  4. NIST Special Publication 800-131A - Revision 2 

  5. Web Cryptography API 

  6. Golang crypto pacakge 

  7. To strengthen the effective key length, the integration of further data, e.g. the user postcode, into the key derivation is foreseen.