Untitled
Dieses Dokument ist Teil der Anfrage „ID Wallet des Bundeskanzleramts, ein Projekt der Bundesregierung: Datenschutzrechtliche Aspekte“
IT-Sicherheitskonzept zu dem Projekt 2080069021 „DIGITALE IDENTITÄTEN: PILOTVORHABEN HOTEL CHECK-IN“ Bundeskanzleramt N FR Bundeskanzleramt Willy-Brandt-Straße 1 10557 Berlin Autoren: ee _ Herausgeber: IBM Deutschland GmbH IBM-Allee 1 71139 Ehningen Datum: 17.03.2021 Version: 1.0
Verzeichnisse Seite 2 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 INHALT Abbildungsverzeichnis............2s0s0n0nenensonnnnsnnnansnnnnonsnsnsnnnnnsnennnnssnsnnnnnsnsnnonsnsnsnnnnnsnsnsnnssnsnnnnnsnssnensnsasannnnnn 2 Tabellenverzeichnis........uuresessonsssnnunsnensnnonsnsnsununnnnonsnsssnnannnnsnonsssssnnnnnsnsnsnnssnsnnnunsnsnsonssssnnnsnnnsensnsnsasannnnnn 2 1 DOKUMENTINFORMATIONEN ......zzzussssssnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnnsnnnsnnnsnnnnnsnnnsnsnnsssnnssnnssnnsnnnnnnn 3 1.1 Verteiler..............222022400nnnnnnrsnnnnennnensnnnonnnnnnnennnonnnnnnnennnennnnenennnnnsennensnnnnnennnentnnnnnnnnnensnnensnnnnnnsnnennnnnn 3 1.2 Versionshistorie..........uursnssoersnnnnsnnnersennonsnnnnnennnonnnnnnnnnnnennnnenennnensnnnonnnnnnnennnentnnnnnnnnnensnnensnnnnnnnnsennnnnn 3 1.3 Abkürzungsverzeichnis ........easeessesessssessnnennnnnnnnennnnnnnnnnnnnnnnnnnnennnnnnnnnnnensnnnnnnnonnnsensnsnsnnsennnnnnnnnnnenn 3 2 Darstellung der Anwendung und des methodischen Ansatzes ...............000000000n0nnnnonnnnnnnnnnnnnnn nn 4 2.1 Zusammenfassende Beschreibung der Anwendung .........uuzusssssssnsnsnnennnnnnnnennnnnnnennnnnnnnnnnennennnnnnnnen 4 2.2 Methodik ...............22..22444444B04nnnnnnennnnnnnnnnennnonsnnnonnnnnnnennnonnnnnnnnnnnnnnnnnnnnnnnonsnnnonsennnntnnnennnnnnernnnensrnnennnnn 5 2.3 Vorgehensweise ...uueeeessesssnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnnnnnnnennnnnnsnnnssnsnnssnnnnennnsensnsssnnsnsnnnnnnnnnsnen 6 3 Lösungsbeschreibung, INFORMATIONSVERBUND UND STRUKTURANALVSE .....zuessssnnnsnnnsnnnennnn 7 3.1 Beschreibung der Lösung ...........usssssenensensnennnnnnnnennennnnnnnnnnnnnnnnnnnnnnonnnnennnnnnsnnnnnnnnnnnnnennnsnnsennnnnnnnnnnen 7 3.2 Beschreibung des Gesamtprozesses .......uuusssssnsennenennennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnsnnsnnnnannnnnnnn 8 3.3 Risikobetrachtung anhand der Prozesskette.......ueesenesessssennnnnnnnnnnennnnnnnnnnnnnnnnennnnnonnnnnnnnnnnnnse seen 17 3.4 Datenfelder ................2200444440444nnnnnnnnnnnnnnennonsnnnnnnnnnnennnonnnnnnnennnnnntnnnennnensnnnensnnnenennsensrnnnnnnnnonsnnnnnn 19 3.5 Informationsverb., Netzplan und Kommunikationsverbindungen.................0sss0rs0rsennennennneenenen 20 3.6 Wesentliche IT-Anwendungen und IT-Systeme ..........uussssessenensnnsennnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnennnnnnnnn 23 4 SCHUTZBEDARFSFESTSTELLUNG ...........uuu000000000000000nnnnnnnnnnnnnnnnnnnnsnnnnnnnnnnsnnnssnnnsnnssnnssnsssnnssnnnsnnn 27 4.1 Datenklassen ..............220u4s242044nnnnennnnnnnnnnennnnnsnnnnnnnnnnsnnnennnnnnnennnnentnnnennnensnnnensnnnensnnsensrnnnnnnnnentnnnnnn 27 4.2 Verarbeitete Daten je Komponente, Schutzbedarfsermittlung ......................02222222200200snnennenneneen 36 5 MODELLIERUNG NACH IT-GRUNDSCHUTZ .......2222ssssssnnnnnnnnnnnnnnunsnunsnunsnunsnennnensnnnsnnsnsnessnessnennnns 42 5.1 Auswahl der relevanten IT-Grundschutz-Bausteine..............20ur222s0essnnnennnonnsnnnnnnnnnennnnnnnnn nennen 42 6 ANFORDERUNGEN - EMPFEHLUNGEN ...........2220020000000000000nnnnnnnnnnnnnnnnnsnnnnsnnssnnssnnssnnssnnssnnssnsnsnnn 45 6.1 Sicherheitsmanagement............22222222ssssnnsnenennnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnsnsnnennonnnnnnsssnssnsnnnn 45 6.2 Betrieb.............2000rs0snnnnnnersnnnnnnnnnnnsnnnnnnnnnnnnnnonsnnnnnnnnenennnonnnnnnnsnnnnentnnntnnnensnnsensnnnensnnsensrnnnntnnnnertnnnnen 46 6.3 Konzeption und Vorgehensweise ....uueeseessesssnnnnnennennennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnsennennennnnnnnnenssnsnse nennen 51 6.4 Anwendungen .....uuuesssssesssnnnnnnnnennennnnnnnnnnnnnnnnnnnnonnnnnnnnnnnsnsnennnnnnnnnnsnnnnsnsnnnsennennensnnsssssnsnnsnnennnnnnnnnn 52 6.5 IT-Systeme ........uessssssessesensnnnnsnnnnnnnnnnnnsnnnnnnnnnensnnnnnnnsnsnsnnnnnnnnnsssnnnnnnnnsssensnnnnsnssssnensnsnssssnnnnsnnnsssssnnnnnnn 56 6.6 Netze und Kommunikation................-220444ns0erssnnnnnnnnenennnonnnnnnnennnnnnnnnnennnonsnnnennnnnenennnonnrnnnnnnnnennnnnnnn 60 Seite 1 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 7 RISIKOANALVSE ...u2cccsssssnnnnsnnnnnsnnssnnnnnnnnnsnnnnnssnnnnnsnnnsnnnnssnnnnnssssssnnnnsnnnnnnsssssnnnnsnnnnnnsssssssssnnnnnnnnen 66 ABBILDUNGSVERZEICHNIS Abbildung 1: IT-Sicherheitskonzeption bei Standard-Absicherung (BSI Standard 200-2) ..............eee 6 Abbildung 2: Onboarding einer öffentlichen DID........................ss00002022002000n0nnnnnennnnnnnnnnnnnnnnnennennnnnnnnennnnse nenn 9 Abbildung 3: Erstellen eines Schemas...............uus20ssssesssneonnnnnnnnnnnnnnonnnnnnnnnnnnnnnnnnnnnnnnnnnnennennnnnnnnnnnnnnnnensnsnnsnsnnn 10 Abbildung 4: Erstellen einer Credential Definition.....................2.0s00s020220020002nnnennnennnnnnnnnnnnnnnn nen nnonnnnnnnnennennnnn 11 Abbildung 5: Erstellung einer Revocation Registry .....ueereesssensennnnennonnnsnnnnnnnnnnnnennnnnnnnnnnennnnnnnnnnnnnnonnnnnnnnennsnnnnn 12 Abbildung 6: Revocation eines VCSs ...ceeseeseesssnnsnnnnnnnennnnnnnnnnnnnnnnnnnnnnnonnnnnnnnnnnnnnnennnnnnnnnnnnnnsnnsnnennnsnnnnnsnnssssssnsnnnn 15 Abbildung 7: Datenfelder .............uusssssenseseesnennnnnnnnnnennnnnnnnnnnennnnnnnnnnnonnnnnnnnnnnnnnnnnnnnnnnnnnnnennsnnsnnnnnnnnnnnnnnnsnsssnnsnnnn 19 Abbildung 8: Gesamtüberblick..............uu2022222022snenenennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnsnsnssnnnnnn 20 Abbildung 9: Netzplan Arbeitgeber....................22200s0@0000200nnnennnnnnnennnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnnnnnnnnnnononnnnnnsnnsnsnnn 20 Abbildung 10: Netzplan Hotels...........uusuereessesssnnnnnennennnnnnnnnnnnnnnnnnnnnnnonnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnsnnennnnnnnnnnnnenenssnnnnnn 21 Abbildung 11: Bundesdruckerei .......ueseseesesssssssnnnnnennennnnnnnnnnnnnnnnnnnnnnnonnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnsnnnnnsnenennnnensnssnnnnn 22 TABELLENVERZEICHNIS Tabelle 1: Verteiler...............0..22200022400444400nnnnnnnennnnnnnnnnnennnonsnnnonnnnnnnennnonnnnnnnnnnnnentnnnnsnnnensnnnensnnnnnsnnnensnnnnennnertnnnnn 3 Tabelle 2: Versionshistorie ...................242044444044nnnennnnnnennnensnnnonnnnnonsnnnonnnnnnnnnnnnentnnenennnonsnnnensnnnnnennnonsnnnnnennnonsrnnnnnn 3 Tabelle 3: Abkürzungsverzeichnis ......ueeessesenseeenennnnnnsnnennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennnnnnnnnnnnnnnnennnnssnsnnennennnnnnsnenssnsnnnn 3 Tabelle 4: IT Systeme und Anwendungen .........uuussssssssennennnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennenssnssensnonnnnnnnnnn 26 Tabelle 5: Datenklassen ..................20r24440442000nnnnnnnnnnnnnennnensnnnennnnnonsnnnonnnnnnnsnnnentnnnnennonsnnsensnnnensnnsonsnnnansnnnnnn nenn 35 Tabelle 6: Schutzbedarf Daten je Komponente ........usnueeessesssssssnennnnnnnennonnnnnnnnnnnnnnnnnnnnnnnnnnnnnnennsnsn nen nnonnnnennnenn 38 Tabelle 7: Kommunikationsverbindungen ..............222ss0ssensnnnnnnnnnnnnnnnnnnnnnonnnnnnennnnnnnnnnnnnnnnnnnnnnnnennsnnn nen nnonnnnennnenn 41 Seite 2 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 1 DOKUMENTINFORMATIONEN 1.1 Verteiler Tabelle 1: Verteiler 1.2 _Versionshistorie 25.02.21 Erstellung des IT-Sicherheitskonzepts 0.21 04.03.21 Überarbeitung 0.3 05.03.21 Fertigstellung erster Entwurf zwecks Übergabe Grundlegende Überarbeitung und erster Vorschlag 1.0 16.03.21 \ zur Übermittlung an den BSI Tabelle 2: Versionshistorie 1.3 Abkürzungsverzeichnis BKAmt Bundeskanzleramt Bundesamt für Sicherheit in der BSI Informationstechnik VC Verifiable Credential Tabelle 3: Abkürzungsverzeichnis Seite 3 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 2 DARSTELLUNG DER ANWENDUNG UND DES METHODISCHEN ANSATZES 2.1 Zusammenfassende Beschreibung der Anwendung Die Bundesrepublik Deutschland wird im Rahmen ihrer Digitalisierungsstrategie ein Ökosystem für Digitale Identitätsnachweise schaffen. Die Grundprämisse hinter diesem neuen Ökosystem ist, dass die Kontrolle digitaler Identitätsnachweise nach dem Ausstellen bei den Nutzer*Innen selbst liegt. Dieses Konzept wird als Self Sovereign Identity (SSI) bezeichnet. Vergleichbar zu haptischen Nachweisen werden Identitätsnachweise als gültig anerkannt, wenn sie nachweislich von einer vertrauenswürdigen Stelle ausgestellt wurden. Die Glaubhaftigkeit von haptischen Nachweisen wird über schwer zu kopierende Materialien und Wasserzeichen sowie Signaturen, Stempel oder Siegel sichergestellt. In der digitalen Welt können digitale Signaturen verwendet werden, um die Authentizität eines Dokuments nachzuweisen. Diese kryptographisch überprüfbaren Zertifikate oder Identitätsnachweise, wie etwa ein digitaler Führerschein, ein digitales Zeugnis oder ein digitales Ticket werden im SSI-Kontext als Verifiable Credentials (VC) bezeichnet. VCs bilden dementsprechend die Grundlage, auf der SSI aufbaut. Sie werden lokal in einer Wallet-App (vergleichbar mit einem Portemonnaie) der Nutzer*Innen gespeichert und können von dort aus auf Nachfrage vorgezeigt und geprüft werden, ohne dass dafür Nutzer*Innen oder Verifizierer mit dem Aussteller oder einer anderen dritten Partei kommunizieren müssen. Das Bundeskanzleramt (BKAmt) hat ein Pilotvorhaben mit diversen Teilnehmern aus der Wirtschaft gestartet, in dem die Potenziale von SSI für sicheres und effizientes Identitätsmanagement demonstriert werden sollen. Zunächst soll der Anwendungsfall „Hotel Check-in“, der in einem Pilotbetrieb in der Praxis erprobt werden soll, umgesetzt werden. Dieser Anwendungsfall soll außerdem die Basis für weitere Anwendungsfälle legen und die Umsetzbarkeit und die Vorteile dezentraler, digitaler Identitätsnachweise sichtbar machen. Mit Beginn des Pilotbetriebs ist geplant, dass ausgewählte Pilot-Mitarbeiter*innen aus vier ausgewählten Unternehmen zwei VCs — die MasterlD als Nachweis über Einträge des Personalausweises und eine CompanylD, welche die Firmenbezeichnung und fiskale Rechnungsadresse des Arbeitgebers enthält -in eine vom Projekt bereitgestellte, aber über das Projekt hinaus nutzbare, Wallet-App mit standardisierten, für SSI spezifizierten Funktionen, laden und diese digital beim Check-in in ausgewählten Hotels übertragen. Hierzu nehmen ausgewählte Hotelstandorte von drei Hotelketten am Projekt teil. Das Ergebnis dieses Projektes bildet die Grundlage für weitere Anwendungsfälle zur Nutzung von SSI in einem perspektivisch europaweit geplanten Ökosystem, welche parallel in sektoralen Arbeitsgruppen erarbeitet werden. Seite 4 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 2.2 Methodik Das Ziel dieses Dokuments ist die Ermittlung von Sicherheitsanforderungen, die Beurteilung des erreichten Sicherheitsniveaus sowie die Festlegung angemessener Sicherheitsmaßnahmen für die SSl-basierte Umsetzung des Projekts. Dies geschieht auf der Basis des IT-Grundschutz-Kompendiums (Edition 2021) des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Das Dokument soll IT-Sicherheitsbeauftragte, Fachverantwortliche und Administratoren der Betreiber bei der Erstellung und Erweiterung der betreiberspezifischen IT-Sicherheitskonzepte unterstützen. Dieses IT-Sicherheitskonzept wurde auf der Basis der Vorgaben des BSI, welche in den BSI-Standards 200-1 bis 200-4 beschrieben sind (Stand Februar 2021), erstellt. Die IT-Grundschutz-Vorgehensweise besteht aus folgenden Elementen: e Lösungsbeschreibung und Definition des Informationsverbundes: Es wird zunächst der Geltungsbereich des Sicherheitskonzepts definiert. e Risikobetrachtung anhand der Prozesskette: Die Authentizität und damit Äquivalenz des SSI- basierten Check-ins für das Ausfüllen der Meldebescheinigung zu bestehenden Prozessen (manuelle Eintragung durch den Gast oder Nutzung der elD) wird begründet. e Strukturanalyse: Als Grundlage eines jeden IT-Sicherheitskonzepts wird beschrieben, welche Daten mit welchen Systemen aufgrund welcher Prozesse verarbeitet werden. «e Schutzbedarfsfeststellung: Hierbei wird ermittelt, welcher Schutz für die Geschäftsprozesse, die dabei verarbeiteten Informationen und die eingesetzte Informationstechnik ausreichend und angemessen ist. e Modellierung: Für den festgelegten Informationsverbund werden die relevanten Bausteine (Maßnahmensammlungen) aus dem IT-Grundschutz-Kompendium ausgewählt, auf deren Basis im weiteren Verlauf mögliche weitere Sicherheitsmaßnahmen definiert werden. e Basis-Sicherheitscheck: An dieser Stelle wird ein Überblick über das vorhandene Sicherheitsniveau erarbeitet, mithilfe von Interviews und Fragebögen wird der Status quo des Informationsverbunds hinsichtlich des Umsetzungsstatus für jede relevante Maßnahme abgefragt und festgestellt. e Ergänzende Sicherheitsanalyse: Die ergänzende Sicherheitsanalyse stellt sicher, dass die nicht vollständig abgedeckten Risiken (zum Beispiel bei höherem Schutzbedarf) ermittelt werden. e Risikoanalyse: Ziel der Risikoanalyse ist, die vorhandenen Risiken durch eine Risikobehandlung auf ein verträgliches bzw. akzeptables Maß (Restrisiko) zu reduzieren. Seite 5 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 Festlegung des Strukturanalyse Geltungsbereichs Analyse des Ist-Zustandes > « Organisation ne u u = 2 « Infrastruktur Schutzbedarfsfeststellung I « drin Anwendungen wg Modellierung ge | 5u « Mitarbeiter (Auswahl der Sicherheitsanforderungen) = u u MM c IT-Grundschutz-Check (Teil 1) 2 (Soll-Ist-Vergleich) zZ =) Risiko- 5 analyse =: u | = Konsolidierung » " = a a a u IT-Grundschutz-Check (Teil 2) 2 od E- u 2 u z Realisierung der Maßnahmen u Fr Abbildung 1: IT-Sicherheitskonzeption bei Standard-Absicherung (BSI Standard 200-2) Das Sicherheitskonzept muss regelmäßig fortgeschrieben und mit dem zuständigen IT- Sicherheitsbeauftragten abgestimmt werden. Die Abbildung 1 veranschaulicht die grundsätzliche Vorgehensweise, die sich in der Struktur dieses Muster-IT-Sicherheitskonzeptes wiederfindet und um eine etwas ausführlichere Darstellung der Lösungsarchitektur erweitert wurde. 2.3 Vorgehensweise Die Erstellung, Umsetzung und Fortschreibung eines IT-Sicherheitskonzeptes sind verpflichtend. Die IT- Sicherheit ist Teil der Informationssicherheit. Dieses Dokument muss regelmäßig überprüft und ergänzt sowie mit dem zuständigen IT- Sicherheitsbeauftragten abgestimmt werden. Es wird davon ausgegangen, dass die beteiligten Organisationen (Bundesdruckerei, Arbeitgeber, Hotelketten, IBM Deutschland GmbH, esatus), die Teile der Infrastruktur dieser Anwendung betreiben werden, bereits über eine sichere IT-Infrastruktur verfügen, die eine sichere Verarbeitung der bisher verarbeiteten, auch personenbezogenen, Daten erlaubt. Dieses Konzept dient dazu, die durch das Projekt neu hinzukommenden Komponenten unter Sicherheitsaspekten zu beschreiben, so dass die organisationsspezifischen Konzepte und letzten Endes auch die Maßnahmen und deren Umsetzung entsprechend angepasst werden können. Seite 6 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 3 LÖSUNGSBESCHREIBUNG, INFORMATIONSVERBUND UND STRUKTURANALYSE 3.1 Beschreibung der Lösung Dieser Abschnitt beschreibt Anforderungen des Anwendungsfalls und der zugrundeliegenden Technologie (SSI) inklusive aller dafür notwendigen IT-Ressourcen und Infrastruktur. Das SSI-basierte Informationsverarbeitungssystem wird derzeit auf Basis von Open-Source-Komponenten für SSI durch die IBM Deutschland GmbH für ein Enterprise-Umfeld entwickelt und auf Servern der beteiligten Unternehmen, der Bundesdruckerei, esatus sowie IBM betrieben. Die verwendeten Komponenten sind - ein öffentliches, zugangsbeschränktes Blockchain-Netzwerk (Hyperledger Indy), - http-Server, die Client-Funktionalitäten für Hyperledger Indy sowie kryptographische Operationen, die im SSI-Kontext standardisiert sind, zur Verfügung stellen und mit der Wallet-App kommunizieren können (Hyperledger Aries), - Tails-Server, welche die für Revocation grundlegenden Tails-Files öffentlich zum Download zur Verfügung stellen (VON Tails-Server), - MongoDB-Datenbanken, - in Java-Spring implementierte REST-Sever (Controller), welche die unterschiedlichen Komponenten und die Frontends koordinieren, sowie - eine von esatus entwickelte Wallet-App. Das Pilotvorhaben Hotel-Check-in wird aktuell von IBM in Zusammenarbeit mit dem Bundeskanzleramt, der Bundesdruckerei, esatus, drei Hotelketten und vier Arbeitgebern entwickelt. Während der Entwicklung laufen die Komponenten überwiegend auf Servern von IBM Deutschland und der Bundesdruckerei; zu Testzwecken aber auch bereits auf Infrastruktur der beteiligten Unternehmen, also der Arbeitgeber und Hotels. Mit zunehmendem Fortschritt werden die Komponenten den am Piloten beteiligten Organisationen, d.h. Hotels und Arbeitgebern zur Verfügung gestellt. Die Organisationen betreiben im Pilot-Betrieb die entsprechenden Komponenten in eigener Verantwortung (Arbeitgeber-Unternehmen und Hotel- Komponenten) bzw. gemeinschaftlich (Blockchain-Netzwerk). Das Blockchain-Backend (Hyperledger Indy Netzwerk) wird zum Start des Piloten auf insgesamt fünf Knoten betrieben, bereitgestellt durch zwei der am Piloten teilnehmenden Unternehmen (BWI und DB), die Bundesdruckerei, IBM und esatus. Damit ist ein kompromittierter Knoten für den fehlerfreien Betrieb des Blockchain-Netzwerks tolerierbar. Seite 7 von 67
IT-Sicherheitskonzept zum Projekt 2080069021 3.2 Beschreibung des Gesamtprozesses Die Testnutzer*Innen erhalten in einem ersten Schritt die erforderlichen VCs (MasterID und CompanylD) und speichern diese in der Wallet-App. Mit den VCs können die Nutzer*Innen sich dann gegenüber dem Hotel während des Check-Ins durch das Scannen eines dort ausliegenden QOR-Codes mit der Wallet-App authentifizieren. Hierdurch entfallen die gesonderte Bereitstellung der Firmenadresse für die Rechnungserstellung sowie das Ausfüllen einer Meldebescheinigung. Der folgende Abschnitt erklärt die einzelnen Vorgänge sowie die dabei ausgetauschten und persistierten Daten für den Anwendungsfall im Detail. Dabei wird zunächst auf das Aufsetzen der Basis-Infrastruktur (Blockchain und Onboarding der Unternehmen) eingegangen, bevor der Informationsfluss der einzelnen Interaktionen von Nutzer*Innen mit Unternehmen bzw. Hotels beschrieben wird. Erstellen des Blockchain-Netzwerks (Onboarding der Knotenbetreiber und der Arbeitgeber-Unternehmen ) Jeder Knotenbetreiber erzeugt zunächst lokal kryptographisches Material (Public und Private Key) aus einem zufälligen oder wegen hoher Entropie nicht erratbarem Seed in Form eines Boneh-Lynn-Shacham- Schlüsselpaars sowie einen daraus abgeleitete Decentralized identifier (DID), bspw. ein Hash des Public Keys. Der Public Key jedes Knotenbetreibers wird gemeinsam mit der IP-Adresse des Servers, auf dem der Knoten laufen soll, und den beiden für das Netzwerken verwendeten Ports (Knoten-zu-Knoten Kommunikation und Knoten-zu-Client-Kommunikation) an alle weiteren Knotenbetreiber weitergegeben, sodass sich die Knoten miteinander verbinden und das Netzwerk starten kann (gemeinsame Erzeugung der Genesis-File, pool_transactions_genesis). Alle Blockchain-Knoten sind damit automatisch sog. “Stewards”, können also Schemata auf die Blockchain schreiben sowie neue Entitäten (Trust Anchors und Endorsers) mit leicht eingeschränkten Schreibrechten hinzufügen. Damit können die Stewards die Arbeitgeber-Unternehmen, die selbst keine Knoten betreiben, über deren Public Key und DID, die sie mit Hilfe des Aries-Agents (oder allgemein wie die Knotenbetreiber mit Client-Libraries für Hyperledger Indy wie der indy-sdk) erzeugen können, als Endorser zum Netzwerk hinzugefügt werden. Dies bedeutet, dass Public Key und DID sowie auf Wunsch auch ein Alias (im untenstehenden Beispiel: Company, aber grundsätzlich beliebige Key-Value-Paare) dieses Unternehmens dann öffentlich auf der Indy-Blockchain festgehalten werden. Diese Informationen entsprechen denen in untenstehender Abbildung (die wesentlichen Inhalte der Transaktion in „txn“) und enthalten nur Informationen über das Unternehmen und damit keine personenbezogenen Daten. Dazu kommen noch Metadaten wie die Signaturen der Indy-Nodes (audit-path, reqSignature) und Informationen über die Platzierung in der Blockchain (ledgerSize, seqNo). Die Blockchain ist public permissioned, d.h., öffentlicher Lesezugriff, aber beschränkter Schreibzugriff. Der Konsensmechanismus der Blockchain ist ein Redundant Byzantine Fault Tolerant; dies ist vergleichbar mit einem Practical BFT Konsensmechanismus, d.h., solange weniger als 1/3 der Nodes bösartig ist, kann die Blockchain nicht kompromittiert werden. Seite 8 von 67
