Ein Konzept für den digitalen Impfnachweis

Sie wissen ja: hinterher sind wir alle schlauer. Daher kann man jetzt leicht mit dem Finger auf andere zeigen und genüsslich breittreten, was die alles versäumt haben. Für den Nachweis, dass die Impfpass-Software aus mehr Löchern als Funktionen besteht, haben wir selbst keine Arbeit leisten müssen, das haben andere erledigt. So sitzen wir mit Popcorn auf der Couch und „amüsieren“ uns. Der Punkt ist aber immer: hätten wir es wirklich von vorneherein besser gewusst?

Wir können zumindest im Fall des Impfnachweises die Frage mit einem klaren Ja beantworten.

Was ist genau passiert

Die Journalisten des Handelsblatts haben einen Sicherheitsexperten hinzugezogen, mit der Aufgabe, die Ausstellung von Impfpässen einmal auf Schwächen zu überprüfen. Hier finden Sie eine gute Beschreibung der Überprüfung. Unter anderem hat man folgendes gefunden:

• Man konnte einen Impfnachweis für eine fiktive Person erstellen, nämlich Robert Koch, geb. am 11.12.1843, geimpft am 04.08.1890.
• Der Impfnachweis wurde unterschrieben von einem Fake-Zertifikat einer fiktiven Apotheke.
• Man konnte sich als Fake-Apotheke auf dem Portal registrieren.

Da stellt sich dann doch die Frage, ob hier überhaupt Plausibilitätsprüfungen vorgenommen wurden. Das ist zumindest in einer Hinsicht der Fall… ;-) Da die angebliche zweite Impfung am 04.08.1890 schon mehr als 14 Tage vorbei ist, zeigt die Corona-Warn-App an, dass die betreffende Person Robert Koch über einen vollständigen Impfschutz verfügt. Das wird ihn sicherlich froh stimmen.

Dass das Geburtsdatum mit 1843 nicht überprüft wurde, halte ich für verzeihlicher, als die Tatsache, dass das Zertifikat der Apotheke nicht überprüft wurde. Interessant ist auch die Tatsache, dass im ausgestellten Impfnachweis nur eine Signatur des Robert-Koch-Instituts zu finden ist, und nicht der ausstellenden Apotheke. Damit lässt sich im Nachhinein ein einmal ausgestellter Impfnachweis nicht mehr ungültig machen. Aber: eine Überprüfung der Zertifikate war nie vorgesehen, wie dieser Kommentar der Entwickler der Corona-Warn-App zeigt.

Was ist ein Zertifikat?

Wenn Sie noch nicht wissen, was ein Zertifikat ist, folgt hier eine kurze Beschreibung. Alle anderen können zum nächsten Abschnitt übergehen.

In der Kryptographie gibt es eine tolle Erfindung: Die asymmetrische Verschlüsselung. Die zeichnet sich dadurch aus, dass man zum Verschlüsseln einen anderen Schlüssel nimmt, also zum Entschlüsseln. Die symmetrische Verschlüsselung verwendet im Gegensatz dazu nur einen Schlüssel sowohl zur Ver- als auch zur Entschlüsselung.

Bei der asymmetrischen Verschlüsselung gibt es einen privaten und einen öffentlichen Schlüssel. Das geniale daran ist nun, dass der öffentliche Schlüssel entschlüsseln kann, was der private Schlüssel verschlüsselt und umgekehrt: Was der öffentliche Schlüssel verschlüsselt, kann der private Schlüssel entschlüsseln. Wir können das gar nicht deutlich genug hervorheben, wie schön das ist, dass das in beide Richtungen funktioniert.

Nehmen wir die Verschlüsselung im Https-Protokoll als Beispiel. Die Website stellt der ganzen Welt einen öffentlichen Schlüssel zur Verfügung. Wenn Sie nun Ihre Kreditkarteninformationen an den Betreiber der Site schicken, dann werden diese mit dem öffentlichen Schlüssel verschlüsselt. Lesen kann das dann nur einer, nämlich der Inhaber des privaten Schlüssels ­– und so soll das sein.

 

Die andere Richtung kann für Signaturen verwendet werden. Ich habe eine Information, die ich öffentlich bekannt mache. Die verschlüssle ich mit meinem privaten Schlüssel und das verschlüsselte Ergebnis veröffentliche ich zusammen mit der Information.

Andere Personen können nun meinen öffentlichen Schlüssel verwenden, um den verschlüsselten Text zu entschlüsseln. Das Ergebnis vergleichen sie mit der bekannten Information. Wenn die Information mit dem entschlüsselten Text übereinstimmt, lässt sich sagen, dass die Information von mir stammt. Und zwar dann, wenn zu 100% klar ist, dass der öffentliche Schlüssel von mir stammt.

Nun ist es so, dass eine Signatur, die auf diese Weise erstellt würde, mindesten genauso lang ist, die die Information, die durch sie bestätigt werden soll. Hier kommt ein weiteres Verfahren ins Spiel: Der Hashcode. Im Grunde genommen ist das eine extrem verkürzte Version der ursprünglichen Information. Sind zwei Informationen A und B identisch, dann sind auch ihre Hashwerte identisch.

Ich nehme eine Information, die ich signieren will. Aus der berechne ich den Hashwert. Den Hashwert verschlüssele ich mit meinem privaten Schlüssel. Das ist dann die Signatur. Nun verteile ich die Information zusammen mit der Signatur. Wer immer meinen öffentlichen Schlüssel hat, kann die Signatur entschlüsseln. Er berechnet den Hashwert des Dokuments, das ich geschickt habe und vergleicht diesen Wert mit der entschlüsselten Signatur.

 

 

Ich kann also nun ein paar Informationen über mich zusammentragen: Name, Adresse, etc. und auch noch meinen öffentlichen Schlüssel dazugeben. Diese Informationen reiche ich bei einer Institution (Certificate Authority, CA) ein, die für die Beglaubigung zuständig ist. Diese Institution hat ihrerseits einen öffentlichen Schlüssel veröffentlicht.

Sie unterzeichnet nun meine Informationen mit ihrem privaten Schlüssel. Damit bestätigt die Institution meine Identität und die Tatsache, dass mein öffentlicher Schlüssel von mir ist. Solche signierten Informationen über die Identität von Personen und Körperschaften nennen sich Zertifikate.

Mit einem Zertifikat kann ich nun meinerseits Dokumente oder weitere Zertifikate signieren. So kann zum Beispiel Institution A ein Zertifikat der Institution B signieren und mit diesem Zertifikat kann Institution B nun mein Zertifikat signieren. Das ergibt eine Kette, an deren Anfang so genannte Root-Zertifikate stehen.

 

 

Tatsächlich beschafft sich z.B. der Browser nicht nur das Zertifikat des Senders, sondern die ganze Zertifikatskette. Und das Root-Zertifikat muss im Browser hinterlegt sein. Der Browser kann nun anhand der öffentlichen Schlüssel der jeweils übergeordneten CA die Unterschrift des untergeordneten Zertifikats überprüfen. Endet die Kette in einem Root-Zertifikat, das im Browser als gültig hinterlegt ist, ist die gesamte Kette gültig. Dabei ist es wichtig, zu verstehen, dass nicht nur die Browser eine solche Überprüfung vornehmen können. Im Prinzip kann das jede Anwendung tun, die Zertifikate überprüfen soll. Und ja, das sollte auch die Corona-Warn-App können.

 

Wie geht man so etwas an?

Ich habe diesen Teil des Artikels bewusst nicht vorbereitet. Ich schreibe den Artikel spontan aus dem Ärmel dahin. Das bedeutet, dass mein Konzept, das ich jetzt vorstelle, lückenhaft sein kann. Aber es ist mir wichtiger, den Denkprozess zu beschreiben, als ein perfektes Ergebnis zu präsentieren. Solche Denkprozesse sind Bestandteil der Software-Architektur, die eigentlich jedem Projekt zugrunde liegen sollte.

Die Überlegungen unterliegen einer Einschränkung: Es gab auf europäischer Ebene Vereinbarungen über die Implementierung von Impfpässen, sodass deutsche Impfnachweise in anderen Ländern überprüfbar sind. Mir ist der Inhalt dieser Vereinbarungen nicht bekannt. Wir versetzen uns daher jetzt fiktiv in die Situation der Konzeptionsphase, und stellen uns vor, wir könnten die Vereinbarungen auf europäischer Ebene noch mitgestalten.

Los geht's! Wir haben folgende Beteiligte:

• Die geimpften Personen
• die Aussteller der Impfzertifikate
• den Betreiber der Infrastruktur der Impfzertifikate
• die Apps, die die Zertifikate anzeigen
• die Überprüfer der Impfzertifikate

Die Aussteller sind Apotheken und Arztpraxen. Der Betreiber ist der Apothekerverband. Der Verband hat zu diesem Zweck ein Zertifikat und einen privaten Schlüssel im Namen des Robert-Koch-Instituts erhalten. Er stellt also im Namen des RKI Impfzertifikate aus. Die Überprüfer sind alle Institutionen, die sicherstellen müssen, ob eine Person geimpft ist.

Das Portal

Zunächst braucht es ein Portal. Dort müssen sich die Apotheken, die Impfpässe ausstellen wollen, registrieren. Dann können die Apotheken die Impfdaten und Informationen über die geimpfte Person erfassen und erhalten als Resultat den Impfnachweis.

Fangen wir beim Registrierungsprozess der Apotheker an. Die Apotheke gibt also eine Handvoll Daten ein, die dann bei der Registrierung überprüft werden. Wie kann sichergestellt werden, dass sich hier keine Fake-Apotheke registriert?

Diese Frage lässt sich aus unserer Sicht gut beantworten. Wir haben nämlich für einen Pharmahersteller ein B2B-Portal entwickelt, auf dem Apotheken ihre Bestellungen hinterlegen können. Das lässt sich nicht handhaben, wie im Portal eines Schuhgeschäfts. Eine Packung Morphium bitte, und das Wochenende ist gerettet… Wir können also nicht darauf vertrauen, dass jemand, der sich dort anmeldet, tatsächlich eine Apotheke ist. Aber woran können wir erkennen, ob jemand eine Apotheke ist?

Apotheker müssen eine Approbation beantragen. Wenn die Voraussetzungen vorliegen, wird eine Approbationsurkunde ausgestellt. Zuständig dafür ist in Bayern zum Beispiel der Regierungsbezirk. Durch die Anträge auf Approbation entsteht nun ein Datenbestand. Dieser Datenbestand wird bundesweit zusammengefasst und steht interessierten Personen und Institutionen zur Verfügung. Wenn ich richtig informiert bin, steht diese Information bei der ABDA zur Verfügung. Daraus ergibt sich ein eleganter Weg zur Überprüfung einer Registrierung.

Wenn eine Apotheke sich registriert, könnte sie eine Kopie der Approbationsurkunde einsenden. Die darauf stehenden Daten werden im Datenbestand gesucht und – voilá – wenn es tatsächlich eine zugelassene Apotheke ist, kann der Datensatz auch gefunden werden.

Denn die Daten haben die gleiche Quelle, nämlich die Approbation. Man verschiebt damit das Problem der Überprüfung auf die zuständigen Behörden, die die Approbationsurkunde ausgestellt haben. Und das ist ja auch sinnvoll. Das ist Digitalisierung.

Die Vorgehensweise hat leider einen Pferdefuß. Nicht alle Apotheken sind beim Verband. Aufgrund der Veröffentlichungen zu dem Thema schätzen wir, dass es in Deutschland 1.500-2.000 Apotheken gibt, die nicht im Verband organisiert sind. Diese tauchen auch nicht im Datenbestand der ABDA auf. Hier muss man auf externe Datenanbieter zurückgreifen, was unser B2B-Kunde auch tut, um seiner Sorgfaltspflicht gerecht zu werden.

Diese Überprüfung ist offensichtlich bei der ABDA nicht geschehen, da sie davon sprach, dass ca. 470 nicht organisierte Apotheken extra überprüft werden müssen, und diese daher nicht so schnell wieder Impfzertifikate ausstellen können.

Allerdings dauerte es auch für den Rest der Apotheken sehr lange, bis sie wieder online waren, sodass der Schluss naheliegt, dass auch die organisierten Apotheken nicht richtig überprüft wurden und das jetzt nachgeholt werden muss. Da hat man dann bei ca. 17.000 Apotheken einiges zu tun.

Ein tragfähiges Konzept für das Portal benötigt also eine Lösung für die Überprüfung der Registrierungen, wie es bei den Portalen der Pharmahersteller gang und gäbe ist.

Die Zertifikatskette

Schritt 1 wäre also gut zu lösen: Die Apotheken registrieren sich mit einer digitalen Kopie ihrer Approbationsurkunde und erhalten ein Zertifikat, mit dessen Hilfe sie nun Impfzertifikate unterzeichnen können. Wenn das jetzt zu viele Zertifikate auf einmal sind, mag diese Grafik hilfreich sein:

Ein Zertifikat ist ein Datensatz mit Identifizierungsinformationen und ggf. einem öffentlichen Schlüssel, und dieser Datensatz wird von einer Autorität signiert. Der Betreiber des Portals benötigt also selbst ein Zertifikat, mit dem er die Zertifikate der Apotheken signiert. Die Apotheken nehmen jetzt den Datensatz der geimpften Person und signieren diesen.

Dafür muss man nichts programmieren, weil es die dafür notwendige Software schon gibt. Frei und Open Source. Und da wir von maximal 20.000 Registrierungen ausgehen, können wir die Software getrost als Konsolenprogramm betreiben und müssen sie nicht aufwändig in eigene Software integrieren.

Um diese Idee zu konkretisieren, sind folgende Überlegungen nützlich:

1. Der Betreiber des Portals ist der Apothekerverband, er unterzeichnet die Zertifikate der Apotheken jedoch gegenwärtig mit dem Zertifikat des RKI. Es ist nicht zu verstehen, warum man hier so sparsam mit Zertifikaten ist. Eigentlich sollte das RKI mit einem privaten Schlüssel ein Zertifikat für die ABDA ausstellen und diese unterzeichnet dann mit seinem eigenen Zertifikat die Zertifikate der Apotheken.
2. Durch die Unterzeichnung von Zertifikaten entsteht eine Kette, die nachvollziehbar ist, im Gegensatz zur heutigen Implementierung: Der Impfnachweis wird gegenwärtig direkt mit dem Zertifikat des RKI unterzeichnet, statt mit einem Zertifikat der Apotheke. Damit wissen wir nicht, welche Apotheke den Impfnachweis ausgestellt hat. Hätten wir eine Zertifikatskette, wie im Bild gezeigt, ließe sich im Fall der Registrierung eines Betrügers das Zertifikat der Fake-Apotheke zurückziehen. Damit werden alle Zertifikate, die von diesem Betrüger ausgestellt worden sind, ungültig.
3. Da das System ein geschlossenes System ist, dessen Institutionen an sich vertrauenswürdig sind, kann an der Wurzel der Zertifikatskette ein selbst signiertes Zertifikat stehen. Solche Zertifikate werden für sogenannte „Root Authorities“ erzeugt. Da das Ganze auf europäischer Ebene funktionieren soll, könnte man nun ein solches Zertifikat für eine europäische Institution erzeugen. Dieses signiert dann Zertifikate für die jeweiligen Institute der Mitgliedsländer, die für die Seuchenbekämpfung zuständig sind – für Deutschland eben das RKI. Hierfür braucht es keine komplizierten Standards, die verabredet werden müssen, weil Zertifikate bereits seit etlichen Jahrzehnten standardisiert sind.
4. Zertifikate können unterzeichnet werden, ohne dass der private Schlüssel an die übergeordnete Institution übergeben werden muss. Dies verhindert Missbrauch. Die privaten Schlüssel liegen immer ausschließlich bei der Institution, der das Zertifikat gehört.

Architektur des Portals

Aus der Lektüre des bisherigen Textes wird möglicherweise hervorgegangen sein, dass der private Schlüssel einer Institution besonders schützenswert ist. Da das Portal im Wesentlichen eine Website ist, halten wir es für eine schlechte Idee, wenn der private Schlüssel direkt auf der Website liegt. Die Website dient nur der Kommunikation mit dem Apotheker, ist also die weltweit sichtbare Oberfläche des Systems. Wenn sich der Apotheker registriert, schickt er seine Kenndaten mit und einen sogenannten Certificate Signing Request. Das Portal speichert diese Informationen und nach Überprüfung der Approbationsdaten erfolgt eine Freigabe.

Dazu wird der Certificate Signing Request an ein anderes System weitergeleitet, das ausschließlich für die Signierung zuständig ist. Dieses System sollte nicht im offenen Internet liegen. Darüber hinaus braucht es eine gewisse Form der Authentifizierung, am besten mit mehreren Faktoren. Einer dieser Faktoren könnte die IP-Adresse des anfragenden Systems sein. Das wäre in diesem Fall möglich, weil man für den Betrieb des Portals mit einer geringen Anzahl an Servern auskommt. Es gibt Möglichkeiten, die IP-Adressen der beteiligten Server zu erfassen und beim Signierungssystem zu hinterlegen, sodass Requests ausschließlich von den angegebenen Adressen erlaubt sind.

Der zweite Faktor könnte auf einem Geheimnis (Shared Secret) basieren, das nur der Portalsoftware und dem Signierungssystem bekannt ist. Basierend darauf lässt sich mit einem Verfahren eine Art TAN erzeugen. Geeignet dafür wäre das TOTP-Verfahren (Time-based One Time Password). Es geht einfach nur darum, ein Passwort zu generieren, das man nicht erraten kann und das sich alle paar Sekunden ändert.

Wenn nun ein Angreifer Kontrolle über das Webportal erhält, braucht er einen gewissen zusätzlichen Aufwand, um an das Signierungssystem heranzukommen. Dazu ist natürlich eins wichtig: Das Geheimnis, aus dem das Passwort generiert wird, darf nie offen in irgendeiner Datei herumliegen. Es muss immer aus anderen Informationen on-the-fly berechnet werden. Dadurch entsteht ein Aufwand, der von einem Angreifer überwunden werden muss.

An der Stelle ist die Anmerkung angebracht, dass es kein System gibt, das nicht gehackt werden kann. Die Frage ist immer, wie hoch der Aufwand dafür ist. Kann man den Aufwand hochhalten, ist das System relativ sicher.

Wir haben bislang nur den Registrierungsprozess behandelt. Nach der Registrierung könnten geschützte Teile des Portals durch das ausgestellte Zertifikat der Apotheke abgesichert werden. Das SSL-Protokoll sieht nämlich eine Authentifizierung durch sogenannte Client-Zertifikate vor. Das Zertifikat, das der Apotheke ausgestellt wird, kann also nicht nur zum Unterzeichnen von Impfpässen verwendet werden, sondern auch für die Authentifizierung beim Portal.

Hier eröffnet sich eine Möglichkeit für eine weitergehende Digitalisierung der Apotheken: Das Zertifikat könnte bei der Zulassung einer Apotheke ausgestellt werden und könnte dann auch für andere Zwecke als Impfpässe genutzt werden.

Signierung durch die Apotheke

Was wir bislang beschrieben haben, ist eine sogenannte Public Key Infrastructure (PKI). Sie beruht auf jahrzehntelang bewährten Verfahren, die allgemein bekannt und standardisiert sind. Die Apotheke erhält als Folge der Registrierung ein Zertifikat nach dem Standard X509. Es gibt nun etliche Wege, wie die Apotheke dieses Zertifikat zur Ausstellung von Impfpässen nutzen kann. Apps für Windows, Mac und die mobilen Plattformen ließen sich sehr leicht erstellen.

Als Nachteil steht zu verbuchen, dass die Apotheke eine solche App installieren muss. Als Vorteil könnte man anführen, dass die App den Registrierungsprozess durch eine Benutzerführung unterstützen könnte. Aber es bleibt eine Schwäche in dem System. Das ist die Tatsache, dass der private Schlüssel der Apotheke zusammen mit dem unterzeichneten Zertifikat die einzige Instanz ist, die die Ausstellung von Impfpässen ermöglicht. Wird der Schlüssel gestohlen, kann der Dieb im Namen der Apotheke Impfpässe ausstellen.

Hier haben wir also ein Problem, bei dem wir verschiedene Risiken abwägen müssen. Wir können vermuten, dass die Entwickler des Portals der ABDA dasselbe Problem gesehen haben, und sich dafür entschieden haben, den Apothekern in dieser Hinsicht nicht zu vertrauen. Darüber hinaus erlaubt es die Lösung der ABDA, die gesamte benötigte Software auf der Serverseite zu halten, sodass die Apotheken keine App installieren müssen.

Das Konzept der ABDA führt aber nun dazu, dass die Impfpässe zentral durch das Portal signiert werden, und das hat wiederum zur Folge, dass Impfpässe von Fake-Apotheken nicht zurückgezogen werden können. Unser Konzept sähe vor, den Apothekern mehr zu vertrauen und lieber die dazu notwendigen Apps entwickeln zu lassen.

Die Apps sind ziemlich simpel und können mit Plattformen wie .NET Core, Xamarin oder Java für alle denkbaren Client-Systeme auf einer gemeinsamen Codebasis entwickelt werden. Die Apps könnten den privaten Schlüssel durch eine weitere Authentifizierungsstufe mit Benutzername/Passwort absichern. Hierbei können Verfahren zur Anwendung kommen, welche die sensiblen Daten (Zertifikat und Schlüssel) basierend auf dem Passwort verschlüsseln und nur für den Betrieb der App im Arbeitsspeicher halten. Das Passwort selbst ist nur im Augenblick des Logins verfügbar und wird in diesem Moment genutzt, um die sensiblen Daten zu entschlüsseln.

Laden des Impfzertifikats

Eigentlich könnte der Apotheker der geimpften Person das Impfzertifikat direkt zukommen lassen, zum Beispiel per E-Mail.

Gegenwärtig wird ein QR-Code ausgedruckt, der die gesamte Information des Impfzertifikats enthält. Der Code kann von der Corona Warn-App bzw. der CovPass-App geladen werden, das Impfzertifikat ist dann in der App sichtbar. Unter Digitalisierung verstehen wir allerdings etwas anderes.

Die Public Key Infrastructure würde ohne großen Aufwand eine andere Verfahrensweise hergeben. Hier würde die geimpfte Person ein Schlüsselpaar anlegen. Sie gibt ihren öffentlichen Schlüssel dem Arzt oder Apotheker, das Impfzertifikat wird damit verschlüsselt und ist dann ausschließlich von der geimpften Person lesbar. Die Erzeugung des Schlüsselpaars und die Übergabe an die Apotheke könnte sehr gut in der Corona-Warn-App oder in CovPass stattfinden.

Die Erstellung eines Zertifikats und die Überprüfung der Identität der geimpften Person sind für die Übermittlung des Impfzertifikats unnötig, ein simples Schlüsselpaar reicht. Die Identitätsinformationen befinden sich ja bereits im Impfnachweis. Folgene Schritte würden also ausgeführt:

• Die CovPass- oder CW-App erzeugt ein Schlüsselpaar.
• Sie übermittelt den öffentlichen Schlüssel an die App des Apothekers.
• Die App des Apothekers stellt das Impfzertifikat aus, verschlüsselt es mit dem öffentlichen Schlüssel und sendet das Zertifikat verschlüsselt an die App der geimpften Person zurück.
• Die App entschlüsselt das Zertifikat mit dem privaten Schlüssel und speichert es für die weitere Verwendung.

Überprüfung der Impfzertifikate

Der Benutzer hat sein Impfzertifikat nun als signierte Information auf seinem Device liegen. Das Zertifikat kann als QR-Code angezeigt werden. Soweit ist das der Stand wie heute. Für die Überprüfung muss der QR-Code gescannt werden und kann nun überprüft werden.

Wenn nun die oberste zuständige Behörde in der EU eine Root Authority betriebe, könnte man damit schon einmal die Zertifikatskette überprüfen, und zwar mit Mechanismen, wie sie seit Jahren in allen Browsern vorliegen. Damit wäre sichergestellt, dass die ausstellende Institution (sprich: die Apotheke oder Praxis) zumindest einmal eine erfolgreiche Registrierung hinter sich hat.

Darüber hinaus würden wir vorschlagen, einen Datenbestand an zurückgezogenen Zertifikaten aufzubauen (Revocation List). Für diesen Datenbestand und die Überprüfung der Zertifikate muss ein Portal geschaffen werden. Das ist jetzt wiederum kein Hexenwerk. Man kann nämlich das gleiche Portal verwenden, das zur Ausstellung der Impfpässe ohnehin nötig ist.

Wurde ein Zertifikat für eine Apotheke zurückgezogen, geschieht dies aufgrund von Vorgängen in den jeweiligen Mitgliedsländern der EU. Innerhalb der EU müsste man sich auf einen Mechanismus zum Austausch der zurückgezogenen Zertifikate einigen. Damit wäre die Überprüfung europaweit lückenlos.

Für die Erstellung und Anwendung von Revocation Lists gibt es bereits Standards und Implementierungen, die man übernehmen kann. Da Revocations ein kompliziertes Unterfangen sind, kann es sein, dass für diesen Anwendungszweck eine eigenständige Entwicklung zielführender ist. Ob das der Fall ist, würde sich aus einer näheren Betrachtung der Anforderungen ergeben.

Als Bonus könnte man auch einem Impfzertifikat einen öffentlichen Schlüssel nach Muster der Zertifikate geben, sodass mit dem gleichen Mechanismus einzelne Impfzertifikate zurückgezogen werden könnten. Aber das wäre die Kür, die in der Praxis wahrscheinlich nicht gebraucht wird.

Fazit

Mit solch einer Ideensammlung, wie sie in diesem Beitrag skizziert ist, würden wir nun zum Meeting mit dem Auftraggeber gehen und das Konzept gegebenenfalls an Rahmenbedingungen anpassen, die uns bislang nicht bekannt waren.

Ich hoffe, den Kern des Konzepts klar gemacht zu haben: Es wird nichts dahingefrickelt, sondern es werden möglichst Verfahren eingesetzt, die auf Standards beruhen und sich über Jahrzehnte hinweg bewährt haben.

Ich sehe auf die Uhr: Das Verfassen des Artikels hat ca. 2 Stunden gedauert. Natürlich wird der noch einmal Korrektur gelesen und es wird noch ein, zwei Gespräche darüber geben. Aber der Aufwand dafür ist ziemlich gering. Und dennoch zeigen sich bereits Lösungsansätze, welche die offensichtlichsten Schwächen der heutigen Implementierung erst gar nicht aufkommen lassen.

Es bleibt die Frage, warum bei den üblicherweise recht hohen Budgets für solche Projekte dieser geringe Aufwand an Software-Architektur nicht geleistet wurde.

Epilog zum Datenschutz

Stattdessen wird die Energie in die Verteufelung des Datenschutzes gegeben. Ein besonders schönes Beispiel von SABVA in diesem Bereich ist in diesem Interview mit einer Frau Schenk vom Bitcom-Verband zu lesen:

Am Ende ist das auch eine Mentalitätsfrage. Bevor bei uns etwas technisch entwickelt wird, führen wir oft endlose Debatten, anstatt einfach mal loszulegen.

NEIN!!!, HALT!!!, möchte man hier rufen. Was herauskommt, wenn man einfach mal loslegt, sieht man bei Projekten wie Luca und nicht zuletzt beim digitalen Impfnachweis selbst. Diese Anwendungen sind nicht zu reparieren, weil sie von Grund auf schlecht konzipiert sind. Kommt eine Anwendung erst einmal in den Einsatz, werden Fakten geschaffen, die nicht so leicht wieder zu verändern sind.

Seit Jahren läuft hierzulande schon eine Kampagne, die dazu aufruft, es mit dem Datenschutz nicht zu übertreiben und stattdessen die Chancen zu sehen, die man durch „zu viel“ Datenschutz angeblich verpasst:

Um das Ganze abzurunden, müssen wir auch beim Datenschutz eine gesamtgesellschaftliche Diskussion führen: Wir brauchen sicherlich Datensicherheit, gleichzeitig müssen wir aber auch die Möglichkeiten der Datennutzung aufzeigen. 

Die angesprochenen „Möglichkeiten der Datennutzung“ ergeben sich vor allem für Unternehmen, die endlich den rechtlichen Rahmen dafür haben wollen, soviel Informationen wie möglich über Bürger zu sammeln, um ihnen irgendwelche Angebote aufzudrängen, die sie nicht brauchen. Darauf können wir alle gerne verzichten.

Bei Projekten, die im Bereich des Gesundheitssystems anstehen, müssen endlich tatsächliche Experten gehört werden, und nicht immer nur die Schaumschläger der Branchenverbände. Das würde zu einem entscheidenden Fortschritt in der Digitalisierung und im Datenschutz führen.

Ansonsten lässt sich sagen: Datenschutz ist möglich, wenn man sich Kenntnisse darüber aneignet und diese dann intelligent kombiniert. Und es gilt natürlich immer: Daten, die wir nicht erfassen, müssen auch nicht geschützt werden. Das wären nun unsere 2ct, die wir zum Thema beitragen können.