Systemkonzept

Dieses Dokument beschreibt ein datenschutzfreundliches Protokoll & System für die Vermittlung von Terminen zwischen zwei Parteien. Es soll u.a. für die privatsphäre-freundliche Vermittlung von Impfterminen im Rahmen der Covid-19 Pandemie eingesetzt werden.

Akteure

Es gibt folgende grundlegenden Akteure im System:

  • Nutzer buchen Termine bei Anbietern (z.B. Ärzten).
  • Anbieter stellen Nutzern Termine zur Verfügung.
  • Vermittler schaffen Vertrauen zwischen den Akteuren im System und üben administrative Aufgaben aus.
  • Backend-Betreiber betreiben die zur Kommunikation zwischen den Akteuren benötigte IT-Infrastruktur.

Anforderungen

Die Privatsphäre und Sicherheit von Nutzern und Anbietern soll möglichst gut geschützt werden. Vermittler sowie Backend-Betreiber sollen nicht in der Lage sein, sensible Informationen über Nutzer oder Anbieter zu erlangen. Sie sollen auch nicht in der Lage sein, Details über vermittelte Termine zu erlangen, abseits von öffentlich im System verfügbaren Informationen. Vermittler und Backend-Betreiber sollen nichtsdestotrotz in der Lage sein, eine missbräuchliche Nutzung des Systems zu erkennen und zu unterbinden (ggf. mit Unterstützung von Nutzern und Anbietern).

Das System soll zudem möglichst robust gegenüber Missbrauch durch Nutzer und Anbieter sein. Es soll insbesondere verhindert werden, dass unseriöse Anbieter oder externe Angreifer über das System Kontakt mit Nutzern aufnehmen oder Daten von diesen erlangen können, oder dass Akteure durch Spamming oder andere Techniken die Funktionalität des Systems für legitime Nutzer oder Anbieter beeinträchtigen können. Eine Kompromittierung einzelner Systemkomponenten oder Akteure soll die Privatsphäre- oder Sicherheitsgarantien des Systems möglichst wenig beeinträchtigen. Im System gespeicherte schützenswerte Informationen sollen durch Client-Anwendungen unabhängig überprüft werden können ohne hierfür explizit dem Backend zu vertrauen.

Schützenswerte Assets werden im Rahmen der Risikoanalyse definiert. Hauptziele für den Schutz der Assets sind die Gewährleistung von Vertraulichkeit, inbsesondere für den Datenaustausch zwischen Nutzern und Anbietern, sowie Vertauenswürdigkeit von Daten, insbesondere für die veröffentlichten Impftermine.

Systemkomponenten

Das System besteht aus folgenden Komponenten:

  • Nutzer-Frontend: Eine Web-/Desktop-/Mobil-Anwendung, die von Nutzern eingesetzt wird um sich zu registrieren und Termine zu buchen oder zu stornieren.
  • Anbieter-Frontend: Eine Web-/Desktop-/Mobil-Anwendung, die von Anbietern eingesetzt wird um sich zu registrieren und Termine zu vergeben und zu verwalten.
  • Vermittler-Frontend: Eine Web-/Desktop-/Mobil-Anwendung, die von Vermittlern eingesetzt wird um Anbieter zu verifizieren, das System zu überwachen und Missbrauch einzudämmen.
  • Daten- & Authentifizierungs-Backends: Ein API-basiertes Backend-System, welches verschlüsselte und/oder signierte Daten der obigen Akteure speichert, Anbieter authentifiziert sowie Daten von Nutzern kryptographisch signiert.

Ablauf der Terminvermittlung

Nutzer
Backend
Anbieter
Anbieter veröffentlichen Termine im Backend.
Nutzer rufen offene Termine vom Backend ab.
Nutzer buchen offene Termine.
Anbieter rufen Terminbuchungen vom Backend ab.

Die Terminvermittlung erfolgt in mehreren überwiegend automatisiert und asynchron ablaufenden Schritten:

  • Vermittler werden vom Backend-Betreiber registriert.
  • Anbieter registrieren sich und erbitten eine Verifikation durch Vermittler.
  • Vermittler verifizieren Anbieter und gewähren diesen somit Zugang zum System.
  • Anbieter stellen Terminangebote ein, die entweder komplett öffentlich oder von authentifizierten Nutzern abgerufen werden können.
  • Nutzer registrieren sich und können Terminangebote für ein gegebenes Einzugsgebiet anzeigen.
  • Nutzer wählen aus den Angeboten einen Termin aus und buchen diesen und übermitteln Anbietern verschlüsselte Daten mit einem Buchungscode.
  • Anbieter verifizieren die verschlüsselten Nutzerdaten und bestätigen die gebuchten Termine.
  • Nutzer und Anbieter ändern oder stornieren ggf. die gebuchten Termine.

Generell minimiert das System bereits personenbezogene Daten, was im Rahmen der Risikoanalyse auch einen unverschlüsselten Austausch von Daten zwischen Nutzern und Anbietern ermöglichen würde. Um etwaig nötige Anpassungen des Systems zukunftssicher zu gestalten wurde für den Datenaustausch zwischen Nutzern und Anbietern jedoch bereits Ende-zu-Ende Verschlüsselung auf Anwendungebene implementiert.

Authentifizierung & Verschlüsselung

Alle Akteure besitzen mehrere langlebige EC-Schlüsselpaare die sie für das Signieren von Daten per ECDSA sowie den verschlüsselte Austausch von Daten per ECIES (ECDH(E) + AES-GCM) nutzen (Details unten). Zusätzlich können sie kurzlebige Schlüsselpaare für den Datenaustausch erstellen.

Akteure werden im System durch ihren öffentlichen ECDSA-Schlüssel identifiziert. Sie authentifizieren alle Daten die sie an das Backend oder andere Akteure schicken durch ECDSA-Signaturen 1.

Vertrauen in Schlüssel wird durch eine Zertifikatskette gewährt:

  • Mediator-Schlüssel und zugehörige Daten werden mit einen Root-Schlüssel signiert.
  • Anbieter-Schlüssel und zugehörige Daten werden mit Mediator-Schlüsseln signiert.
  • Termindaten werden mit Anbieter-Schlüsseln signiert.
  • Hashes von Nutzerdaten und Nutzer-Token werden mit einem Token-Schlüssel signiert, zugehörige HMAC-Werte werden mit einem Token-Geheimnis authentisiert.

Hierbei werden sowohl ECDSA- als auch ECDH-Schlüssel signiert. Mit Ausnahme der Nutzer, die anonym sind und im System keiner Vertrauensprüfung unterliegen werden somit alle Akteure im System durch dezentral vorliegende Vertrauensanker authentifiziert. Der Root-Schlüssel wird hierbei sowohl vom Backend als auch in den Apps zur Verfügung gestellt.

Schlüssel werden im System explizit gepinnt, nur Schlüssel die in der globalen Schlüsselliste im Backend vorliegen werden von den Apps als gültig betrachtet, dementsprechend werden keine Schlüsselwiderrufslisten gepflegt.

Zusätzlich zur Verschlüsselung auf Anwendungsebene wird für die Übermittlung von Daten konsequent Transportverschlüsselung per TLS-Standard genutzt. Im Backend gespeicherte Daten können zusätzlich bei der Persistierung verschlüsselt werden (encryption at rest). Die Umsetzung dieser Verschlüsselungsmaßnahmen obliegen jedoch dem Betreiber des Systems und werden mit Ausnahme von TLS-Verschlüsselung nicht von der Kiebitz-Kernsoftware abgebildet.

Verschlüsselung

Die Verschlüsselung von Daten im System erfolgt über symmetrische sowie hybride Verschlüsselungsverfahren. Als symmetrisches Verfahren wird AES-GCM genutzt, da es authentisierte Verschlüsselung bietet und für die gegebene Datengrößen im System gut geeignet ist. Als hybrides Verfahren wird ECIES basierend auf der NIST P-256 Kurve genutzt 2. Bei der Implementierung der Verfahren wurde den BSI-Empfehlungen für kryptographische Mechanismen und Schlüssellängen BSI TR-02102-13 gefolgt, zusätzlich ggf. NIST-Richtlinien für Bereiche ohne BSI-Empfehlungen (bspw. Entropie/Länge der zur Schlüsselableitung eingesetzten Geheimnisse). Auswahlkriterium für die kryptographischen Verfahren war zudem die Verfügbarkeit standardisierter Implementierungen in browserbasiertem Javascript sowie Golang.

Kryptographische Parameter

Die folgenden Parameter wurden für die eingesetzten kryptographischen Verfahren gemäß den BSI-Empfehlungen, sowie unterstütztend den NIST-Empfehlungen 4, gewählt.

Name Wert
AES-GCM
Schlüssellänge (Bits) 256
Tag-Länge (Bits) 128
IV-Länge (Bits) 96
ECDH / ECDSA
Kurve NIST P-256
Schlüsselableitung via PBKDF2
Hashverfahren SHA-256
Iterationen 100.000
Salt-Länge (Bits) 128
Schlüsselableitung via HKDF
Hashverfahren SHA-256
Salt-Länge (Bits) 128
Zufallszahlengenerierung
Verfahren (Browser) Crypto.getRandomValues()
Verfahren (Backend) crypto/rand
Geheimnislängen für die Schlüsselableitung
Nutzergeheimnis (Bits) 80 4
Anbietergeheimnis (Bits) 140
HMAC-Verfahren
Hashfunktion SHA-256

Die Implementierung der wesentlichen kryptographischen Funktionalität ist quelloffen und für das Backend sowie Frontend öffentlich einsehbar. Im Browser wurde zur Implementierung die Web Cryptography API 5 genutzt, im Backend das crypto Modul der Golang-Standardbibliothek 6.

Schlüsselmanagement

Schlüssel werden an unterschiedlichen Stellen im System generiert und vorgehalten. Root- & Token-Schlüssel sowie das Token-Geheimnis werden lokal mithilfe der kiebitz Software erstellt. Der öffentliche Root-Schlüssel sowie der öffentliche und private Token-Schlüssel und das Token-Geheimnis werden dem Backend in Form von Schlüsseldateien bzw. Einstellungsdateien zur Verfügung gestellt. Der private Root-Schlüssel wird als Datei bereitgestellt und muss von Administratoren sicher verwahrt werden. Vermittler-Schlüssel werden ebenfalls lokal mithilfe der kiebitz Software erstellt sowie von dieser lokal signiert und anschließend im Backend hinterlegt. Die Erstellung und das Signieren der Schlüssel kann getrennt erfolgen, Administratoren müssen somit keine Kenntnis von privaten Vermittlerschlüsseln erhalten.

Langlebige Anbieter- und Nutzer-Schlüssel werden im Rahmen des Registrierungsprozesses im Browser generiert. Nutzer-Schlüssel werden anschließend verschlüsselt im Storage-Backend abgelegt, Anbieter-Schlüssel lokal in einer verschlüsselten Datei gespeichert. Kurzlebige Schlüssel werden sowohl für Anbieter als auch Nutzer nach Bedarf erstellt und ggf. lokal oder verschlüsselt im Storage-Backend gespeichert.

Generell sollten langlebige Schlüssel lediglich für das Signieren von Daten genutzt werden, da die Langzeitnutzung von statischen ECDH-Schlüsseln und den daraus abgeleiteten Schlüsseln Sicherheitsrisiken birgt (z.B. IV-Wiederholung bei identischen Schlüsseln, keine "perfect forward secrecy" etc.).

Schlüsselaustausch

ECDSA- & ECDH-Schlüssel können im laufenden Betrieb ausgetauscht werden, wobei der Aufwand je nach ausgetauschtem Schlüssel variiert:

  • Wird der Root-ECDSA-Schlüssel ausgetauscht müssen alle signierten Mediator-Schlüssel und Daten mit dem neuen Root-Schlüssel signiert werden.
  • Wird ein Mediator-ECDSA-Schlüssel ausgetauscht müssen alle mit diesem Schlüssel signierten Anbieter-Schlüssel & Daten mit einem anderen oder dem neuen Mediator-Schlüssel signiert werden.
  • Wird ein Anbieter-ECDSA-Schlüssel ausgetauscht müssen alle mit diesem Schlüssel signierten Termineinladungen mit dem neuen Schlüssel signiert werden. Hierzu ist ggf. ein Change-Management Prozess notwendig über den der alte Schlüssel zunächst als inaktiv markiert wird und in einem zweiten Schritt ausgetauscht wird.

ECDH-Schlüssel können ebenso ausgetauscht werden, hierbei müssen ggf. mit diesen verschlüsselte Daten neu verschlüsselt werden. Dies betrifft insbesondere Daten die Nutzer an Anbieter übermitteln.

Einbettung im Web-Browser

Die Implementierung einer sicheren Ende-zu-Ende Verschlüsselung auf Anwendungsebene für browser-basierte Anwendungen ist nicht einfach, da Web-Browser zwar grundlegend benötigte kryptographische Funktionalität bereitstellen aber Aspekte wie das Schlüsselmanagement der Anwendung überlassen und zudem keine Mechanismen zur unabhängigen Integritätsprüfung der ausgeführten Web-Anwendung bieten. Dementsprechend muss dem Backend, das die Web-Anwendung bereitstellt implizit vertraut werden, ebenso der Browser-Umgebung in der die Anwendung ausgeführt wird. Die Web-Anwendung sollte daher möglichst unabhängig vom Backend zur Verfügung gestellt werden. Alternativ kann die Nutzung einer Desktop-Anwendung erworgen werden, welche zusätzliche Kontrollmechanismen zur Überprüfung des Anwendungscodes bietet. Ebenso kann eine lokal installierte Browser-Erweiterung ggf. zusätzlichen Schutz vor manipuliertem Anwendungscode bieten.

Die Absicherung des zur Verschlüsselung nötigen Schlüsselmaterials im Browser ist ebenfalls schwierig. Bei Speicherung im lokalen Browser-Storage (localStorage oder sessionStorage) ist eine einfache Extraktion durch Anwendungscode der auf dem gleichen Ursprung (Origin) ausgeführt wird möglich. Dementsprechend sollte auf der Anwendungsdomain kein weiterer Code (z.B. Drittanbieter-Skripte) ausgführt werden. Bei Speicherung im Anwendungsspeicher muss Schlüsselmaterial bei jedem Neuladen der Seite neu importiert werden.

Löschkonzept

Generell werden alle Daten mit Personenbezug automatisiert gelöscht. Alle Daten zu Terminbuchungen werden einen Tag nach Ablauf des Termindatums gelöscht. Verschlüsselte Nutzerdaten werden standardmäßig nach 30 Tagen Inaktivität gelöscht, der Zeitraum ist im System jedoch konfiguierbar. Abseits hiervon werden keine personenbezogenen Daten im System gespeichert. Gegebenenfalls werden zum Zweck der Anfragelimitierung (Rate Limiting) gehashte IP-Adressen gespeichert die ebenfalls personenbezogene Daten darstellen können, diese werden spätestens nach Ablauf des zugrunde liegenden Limitierungszeitraums (maximal eine Stunde) gelöscht. Datenbank-Backups werden maximal 30 Tage vorgehalten.

Verbesserungsmöglichkeiten

Aktuell werden an mehreren Stellen im System statische oder zumindest langlebige kryptographische Schlüssel verwendet. Zur besseren Absicherung und Gewährleistung von "perfect forward secrecy" sollte für jeglichen Datenaustausch im System nur kurzlebige Schlüsselpaare genutzt werden.

Die Absicherung des krytographischen Schlüsselmaterials im System ist ebenfalls noch verbesserungswürdig. Nutzer-Schlüsselpaare werden verschlüsselt im Storage-Backend abgelegt, der zugehörige Schlüssel bietet mit 80 Bit ggf. nicht genug Sicherheit und sollte mit einer zusätzlichen Information (z.B. Postleitzahl) geschützt werden 7. Langlebige Anbieter-Schlüssel werden hingegen lokal gespeichert und werden aktuell mit einem 140 Bit Zufallswert geschützt. Die lokale Speicherung in einer verschlüsselten Datei birgt aber ebenfalls Risiken, da diese Datei auf jedem Endgerät mit dem sich der Anbieter am System anmeldet vorgehalten werden muss. Die Nutzung von Hardware-Token wäre für die Speicherung des Schlüsselmaterials daher vorzuziehen, kann aber realistisch nicht von allen Anbietern geleistet werden in Anbetracht des kurzfristigen Rollouts. Trotzdem sollte eine Nutzung solcher Verfahren für die Speicherung des Schlüsselmaterials untersucht und ggf. implementiert werden, auch wenn nicht alle Akteure auf diese zurückgreifen können. Ggf. können für die Durchführung kryptographischer Operationen TPM 2.0 Module genutzt werden, welche auf vielen modernen Systemen vorhanden sind. Hierzu ist jedoch die Installation von Browser-Erweiterungen und ggf. spezielle Desktop-Software nötig, da aktuell TPM-Funktionen nicht aus dem Browser genutzt werden können.

Root-Schlüsseldateien sowie für das Backend benötigte Schlüsseldateien sind zudem aktuell nicht explizit passwortgeschützt und müssen von Administratoren sicher verwahrt werden. Hierfür sollte ggf. eine explizite Verschlüsselung vorgesehen werden um das Risiko der unsicheren Verwahrung durch Nachlässigkeit zu reduzieren.


  1. Generell wird in BSI TR 02102-1 davon abgeraten, für das Signieren von Daten eingesetzte Schlüssel auch für die Instanzauthentisierung zu nutzen. Kiebitz führt jedoch keine Instanzauthentisierung im engeren Sinne durch, dementsprechend ist aus unserer Sicht die Nutzung des Signaturschlüssels für die Kommunikation mit dem Backend akzeptabel. 

  2. EC-Verfahren basierend auf Curve25519 wären sicherlich zu bevorzugen, sind aktuell jedoch nicht nativ implementiert in Browser-Umgebungen verfügbar. 

  3. BSI TR 02102-1 - Fassung vom Januar 2021 

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

  5. Web Cryptography API 

  6. Golang crypto pacakge 

  7. Zur Stärkung der effektiven Schlüssellänge ist die Einbindung weiterer Daten, z.B. der Nutzer-Postleitzahl, in die Schlüsselableitung vorgesehen.