Jusletter IT

Viele Autoren haben sich bereits mit der Thematik Blockchain¹ befasst, meist mit dem Augenmerk auf Anwendungen im Finanzsektor. Gegenstand dieses Beitrages ist das Spannungsfeld zwischen der Blockchain-Technologie und den Anforderungen des Datenschutzes, dargestellt an einem konkreten Fallbeispiel, das nicht im Finanzbereich angesiedelt ist.

Vorliegend soll gezeigt werden, wie sich die fachlichen Qualifikationen unter Verwendung einer Blockchain-basierten Lösung nachweisen lassen. Ob dies die beste technische Umsetzung darstellt, wird nachfolgend nicht bewertet. Vorab ist ebenfalls zu erwähnen, dass über die gängigen Denkweisen hinausgegangen werden soll. Namentlich wird versucht, die rechtlichen Aspekte auch etwas aus einer technischeren Sichtweise zu beleuchten sowie neue bzw. andere Wege aufzuzeigen, wie die Problemstellungen gerade im Zusammenhang mit dem Datenschutz betrachtet werden könnten.

In gewissen Bereichen, namentlich in sicherheitssensitiven Arbeitsumgebungen, müssen Mitarbeiter über entsprechende Ausbildungen, Zeugnisse und Zertifizierungen verfügen, die sie vorweisen und auf deren Gültigkeit überprüfen lassen müssen. Gerade auf gesicherten Baustellen, welche spezielle Zertifizierungen erfordern, gestaltet sich heute die Überprüfung sowie die Dokumentation bei der üblichen Durchmischung von internen und externen Mitarbeitern aufwändig. Periodisch zu erneuernde Zertifizierungen verursachen dabei zusätzlichen Aufwand im bereits aufwändigen Umgang mit den meist in Papierform bestehenden Legitimationen.

Unnötige Prozesse entstehen jedoch nicht nur bei der Zulassung zu einem gesicherten Bereich, sondern auch beim vorgelagerten und allenfalls periodischen (Neu-) Erwerb sowie bei der Verwaltung der Zertifikate, Ausbildungen und medizinischen Untersuchungen. Ebenso sind auch diejenigen Aufwände nicht zu vernachlässigen, die im Zusammenhang mit Nachweispflichten entstehen.

Folgende Lösung wird für die Vereinfachung der genannten Prozesse in casu näher diskutiert und beleuchtet: Mit Hilfe einer Applikation soll ein Mitarbeiter seine Zulassung basierend auf entsprechenden Zertifikaten direkt beim Zutritt zum gesicherten Bereich belegen können. Hierzu ist eine Kommunikation zwischen seinem Gerät und dem Gerät der Kontrollperson erforderlich, welche beispielsweise mittels QR Code initiiert und über die Internetverbindung der Geräte abgewickelt wird. Der von der Anwendung der Kontrollperson generierte Code erfragt dabei die notwendigen Informationen für den Eintritt und gibt gleichzeitig an, wohin die Informationen geliefert werden sollen. Nach dem Scannen des Codes durch den Mitarbeiter mittels Smartphone-App wird auf der Applikation des Mitarbeiters ersichtlich, welche Informationen konkret verlangt werden und wer die Informationen wünscht. Er hat sodann die Möglichkeit, den Zugriff auf die angeforderten Informationen freizugeben oder zu verweigern. Die Bestätigung löst den Datenfluss in Richtung einer Datenbank (Logbuch) aus, in der sämtliche relevante Ereignisse zur späteren Nachvollziehbarkeit gespeichert werden.

Grundsätzlich handelt es sich bei der beispielhaft in einem Proof of Concept umgesetzten Lösung um eine Kombination von Self Sovereign Identity (nachfolgend SSI) bzw. Distributed Identity (DID und Distributed Claims). Was bedeutet dies konkret? Vereinfacht dargestellt ist dieser Prozess mit der Betrachtung der eigenen Brieftasche und der Verwendung deren Inhaltes gleichzusetzen – nur ist in diesem Falle alles digital und basierend auf Smartphone, Kryptografie und Distributed Ledger.²

An erster Stelle steht eine digitale Identität für alle Beteiligten (Mitarbeiter, Zertifizierer, Prüfer usw.) in Form eines Public/Private Key Paares³, das erstellt wird, sobald einer der Beteiligten am System teilnehmen will. Die Public Keys werden bei diesem Lösungsansatz unveränderlich auf einem Distributed Ledger (z.B. Ethereum Blockchain) abgelegt. Das Public/Private Schlüsselpaar, welches gleichzeitig die Grundlage der digitalen Brieftasche (Wallet) auf dem Smartphone darstellt, muss als nächstes mit einer realen Person verknüpft werden. Dies sollte analog der heutigen Passstellen, durch eine staatlich autorisierte Instanz erfolgen. Jedoch wäre auch eine andere Stelle denkbar, sofern sie das entsprechende Vertrauen innehat. Die Passstelle, welche ebenfalls über entsprechende Private/Public Keys verfügt, verifiziert die Identität anhand von biometrischen Merkmalen und dem Einwohnerregister und bestätigt die Identität durch Signatur der Eigenschaften mittels Private Key. Die so signierte Identität wird im Wallet der identifizierbaren Person gespeichert. Ausbildungsbestätigungen, Tests und Zertifizierungen wiederum würden von den entsprechenden Ausbildungsstellen, Veranstaltern und medizinischen Zentren/Ärzten durch ihre eigenen Signaturen bestätigt und auch im Wallet des Mitarbeiters gespeichert. Weil nicht eine zentrale Stelle die Zertifizierungen bestätigt, spricht man hier vom «Distributed Claims» Verfahren. Mit der gleichzeitig fehlenden zentralen Stelle ist nun der Mitarbeiter auch selbst für die Speicherung der signierten Identität und der Bestätigungen auf seinem Gerät verantwortlich (SSI), wie das auch mit der Brieftasche der Fall ist, die bspw. Zahlkarten, Identitätskarte oder Führerausweis enthält.

Eine Überprüfung läuft technisch wie folgt ab: Der Überprüfende verlangt vom Überprüften die Bestätigung bestimmter «Claims» (Anspruch, Behauptung), wie beispielsweise, dass eine Zertifizierung absolviert wurde. Falls der Überprüfte einwilligt, dem Prüfenden die angeforderten Informationsansprüche zu bestätigen, übermittelt er die entsprechenden Informationen, welche durch die Zertifizierungsstelle signiert wurden. Der Prüfende kann mit Hilfe des im Distributed Ledger gespeicherten Public Keys der Zertifizierungsstelle prüfen, ob der übermittelte Claim gültig ist. Dieses Verfahren entspricht dem «analogen» bei dem ein Autofahrer einem Polizisten auf Verlangen den eigenen Führerausweis aushändigt, welcher durch die autorisierte Stelle (Strassenverkehrsamt) ausgestellt wurde und sich (normalerweise) in der Brieftasche des Autofahrers befindet. Der Polizist ist in der Lage, an Ort und Stelle die Behauptung «Führerprüfung bestanden» des Autofahrers zu prüfen, in dem einerseits der Ausweis selbst geprüft wird (= prüfen der Signatur) und andererseits der Eintrag «Führen von Personenfahrzeugen» (= Claim) eingesehen werden kann, ohne die autorisierte Stelle anrufen zu müssen.

Die Prüfung der Signatur erfolgt mit einem kryptografischen Verfahren mit Hilfe des zur jeweiligen Zertifizierungsstelle gehörendem Public Keys. Der Überprüfer muss/kann jederzeit entscheiden, welche Zertifikatsaussteller akzeptiert werden. Zu diesem Zweck können Zertifizierungen, welche durch andere als den vom Überprüfer akzeptierten Stellen signiert wurden, abgelehnt werden.

Da in sicherheitsrelevanten Bereichen, in welchen nur Spezialisten oder bestimmte Personen Zugang erhalten dürfen, der Verantwortliche jederzeit die Einhaltung der Vorschriften nachweisen können muss, besteht die Möglichkeit aus den Protokollen periodisch einen Hash⁴ zu generieren (Hash = Prüfwert, mit welchem Veränderungen am Originalinhalt festgestellt werden können). Dieser Hash kann sodann auf einer Blockchain unveränderbar hinterlegt werden. Damit wird ein Nachweis bezüglich der Einhaltung der Sicherheitsvorschriften basierend auf den Protokollen des Verantwortlichen möglich, da durch die Verifikation gegen den in der Blockchain abgelegten Prüfwert sichergestellt wird, dass nachträgliche Manipulationen des Protokolls entdeckt werden können.

Datenschutz ist nunmehr ein allgegenwärtiges Thema. Vom erstmaligen Auftauchen von Regelungen zwischen 460 und 360 v.Chr. bis hin zur ersten Kodifizierung 1970 hat er sich von Vorschriften betreffend ärztlicher Schweigepflicht hin zu einer allgegenwärtigen Normierung entwickelt. Er dient dem Kontrollbedürfnis über die eigenen Daten, über die Informationen hinsichtlich seiner eigenen Person. Eine Verletzung dieses Bedürfnisses hat nicht nur die Verletzung gegen die Prämisse des Datenschutzes an sich zur Folge, sondern stellt jeweils auch eine Verletzung der freien Persönlichkeitsentwicklung dar. Ursprünglich wurden die Vorgaben zum Schutz der Personendaten auf der Prämisse festgelegt, dass etwaige Verletzungen unmittelbar festgestellt und die verantwortlichen Personen auch ohne weitere Mühen zur Rechenschaft gezogen werden können. Dieses Konzept wurde jedoch durch die Globalisierung, des hohen und auch automatisierten Informationsaustausches schlicht vom technischen Fortschritt überholt.⁵ Die Fortentwicklung der Kodifizierungen wurde nötig und in diesem Zuge fanden offenere Formulierungen Eingang in die Gesetzgebung, um die Entwicklungen und Neuerungen zu berücksichtigen. In jüngster Zeit bildeten jedoch gerade diese offenen Formulierungen dem technischen Fortschritt und den damit einhergehenden Möglichkeiten einige Probleme.

Im Folgenden werden die für den Use Case und die Einordnung der technischen Aspekte relevanten Normen des Schweizerischen Datenschutzes und der DSGVO kurz beleuchtet.

Das Datenschutzgesetz kommt gemäss Art. 2 DSG immer dann zum Tragen, wenn Daten von natürlichen und juristischen Personen bearbeitet werden. Dabei sind die dem Datenschutz inhärenten Grundsätze, welche in Art. 4 DSG verankert wurden, zu beachten. Diese sind namentlich das Verhältnismässigkeitsprinzip, das Prinzip von Treu und Glauben, die Rechtmässigkeit und Erkennbarkeit der Bearbeitung, die Zweckbestimmung sowie die Richtigkeit der Daten.⁶

Nach Art. 3 lit. a DSG sind Personendaten alle Angaben, die sich auf eine bestimmte oder bestimmbare Person beziehen.⁷ Die Begrifflichkeit ist sehr weit gefasst, da lediglich ein Informationsgehalt vorliegen muss, der sich auf eine Person bezieht (direkt)⁸ oder beziehen lässt (indirekt)⁹. Angaben stellen jedoch erst Personendaten dar, wenn dadurch unmittelbar oder aus dem Kontext der Information bzw. durch Kombination mit anderen Daten, die Identität der Person bestimmt werden kann. Der Bezug ist dabei nur solange gegeben, wie die Identifizierung ohne unverhältnismässigen¹⁰ Aufwand möglich ist.¹¹

Die Bestimmbarkeit besteht, solange Personendaten nicht anonymisiert¹² werden. Sobald eine Reversibilität gegeben ist, handelt es sich um eine Pseudonymisierung. Die pseudonymisierten Daten bleiben für jene, die Zugang zum Schlüssel haben, weiterhin Personendaten. Für Aussenstehende jedoch, die weder einen Schlüssel besitzen noch Zugang zu ebendiesem haben, sind es analog der anonymisierten Daten keine Personendaten mehr.¹³

Eine Verletzung der eingangs erwähnten Grundsätze nach Art. 4 DSG stellt eine Verletzung der Persönlichkeit der betroffenen Person dar. Die Rechtswidrigkeit entfällt jedoch bei Vorliegen eines Rechtfertigungsgrundes nach Art. 13 DSG, d.h. durch die Einwilligung des Verletzten, ein überwiegendes privates oder öffentliches Interesse oder eine Gesetzesvorschrift.

Die Legaldefinition der personenbezogenen Daten in Art. 4 DSGVO entspricht – mit Ausnahme, dass die Bestimmbarkeit hier nun ausdrücklich definiert ist – jener des DSG. Gleiches gilt für die Verarbeitung und Pseudonymisierung der Daten und es kann an dieser Stelle auf die obigen Ausführungen verwiesen werden.

Es sind nach Art. 5 lit. d DSGVO alle angemessenen Massnahmen zu treffen, damit Daten, die im Hinblick auf die Zwecke ihrer Verarbeitung unrichtig sind, unverzüglich gelöscht oder berichtigt werden.¹⁴ Dieser Anspruch an die Richtigkeit wurde denn auch in den Art. 16 und 17 DSGVO kodifiziert, wonach die Betroffenen einerseits ein Recht auf Berichtigung und andererseits auf Löschung ihrer Daten haben. Jedoch ist dabei der Erwägungsgrund 65 zu beachten, wonach diese Rechte nur bestehen, wenn die Speicherung der Daten der DSGVO oder einem anderen Recht der Mitgliedstaaten nicht entgegenläuft. Ist etwa die Speicherung von fehlerhaften Daten gesetzlich vorgeschrieben, so besteht kein Anspruch nach Art. 16 DSGVO.¹⁵

Die Speicherung hat in einer Form zu erfolgen, die die Identifizierung der betroffenen Personen nur so lange ermöglicht, wie es für die Zwecke, für die sie verarbeitet werden, erforderlich ist (Art. 5 lit. e DSGVO); personenbezogene Daten dürfen länger gespeichert werden, soweit sie ausschliesslich für im öffentlichen Interesse liegende Archivzwecke oder für wissenschaftliche und historische Forschungszwecke oder für statistische Zwecke gemäss Artikel 89 Absatz 1 verarbeitet werden.

Anders als unter dem DSG verlangt die DSGVO für jede Datenbearbeitung eine Rechtsgrundlage ähnlich der Rechtfertigungsgründe von Art. 13 DSG. Die Verarbeitung ist gemäss Art. 6 DSGVO nur rechtmässig, wenn die betroffene Person ihre Einwilligung gibt oder sie für die Erfüllung eines Vertrags oder einer rechtlichen Verpflichtung erforderlich ist. Ebenfalls ist eine Rechtmässigkeit gegeben, wenn die Verarbeitung notwendig ist, um lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person zu schützen. Darüber hinaus auch, wenn die Verarbeitung für die Wahrnehmung einer Aufgabe erforderlich ist, die im öffentlichen Interesse liegt oder in Ausübung öffentlicher Gewalt erfolgt. Schliesslich ist die Verarbeitung zulässig, soweit sie zur Wahrung der berechtigten Interessen des Verantwortlichen oder eines Dritten erforderlich ist, sofern nicht die Interessen oder Grundrechte und Grundfreiheiten der betroffenen Person überwiegen.¹⁶

Das Modell der sog. SSI gibt dem Nutzer die Kontrolle über die eigene digitale Identität.¹⁷ Der Benutzer hat mit anderen Worten die Herrschaft über die Gesamtheit seiner eigenen Identitäts-Daten, wodurch er selbst bestimmen kann, welche Informationen bei einem Authentifizierungsvorgang übermittelt werden. Die Bestätigung der Identität ist heute bereits mit den bestehenden Identitätsprovidern wie Google-Login oder Facebook-Login durch «Consent-Screen» möglich. Der Unterschied zu den bestehenden IDP (Identity Providern) ist, dass die «Identifiers» nun dezentral, ohne Zuhilfenahme der IDPs möglich ist, weil diese mit Hilfe der DLT dezentral gespeichert werden können.

Authentifizierung und Autorisierungen werden in der Regel durch Überprüfung von durch den Prüfer gewünschten Attributen abgewickelt. Man spricht hier von Attributsnachweis bzw. verifiable claims. Die verifiable claims sind Eigenschaften über ein Subjekt (wie bspw. Alter, Geburtsdatum, Diplome etc.). Mit Hilfe von digitalen Signaturen werden diese digital verifizierbar. Dritte können mit Hilfe eines Public Keys die Signatur überprüfen. Vorausgesetzt wird somit, dass eine entsprechend anerkannte Autorität durch Signatur den claim bestätigt hat und der Prüfer über den (nachweislich) zur anerkannten Autorität gehörenden Public Key verfügt oder diesen beschaffen kann.¹⁸

Wie oben bereits erwähnt, hat der Nutzer die vollständige Kontrolle über seine digitalen Daten und ist zu jeder Zeit grundsätzlich in der Lage über deren Löschung, Änderung und Freigabe zu entscheiden. Eine Ausnahme davon besteht betreffend dem Public Key, wenn die Blockchain als Speicherungsmedium für diesen fungieren soll. Das gleiche gilt für in der Blockchain gespeicherte Claims, wie es DID vorsieht (vgl. ERC 780 und ERC 1056 bzw. uPort «Claims Registry»)¹⁹.

Je nach Ausgestaltung kann die SSI weitergehen, als die Gesetzgebung dies durch den Datenschutz nach DSG sowie DSGVO verlangt, da der Nutzer auch über Daten wie Mailadressen verfügen könnte, welche nach wie vor im Rahmen des Marketings genutzt werden. Datenschutzrechtlich bietet diese technische Lösung somit gewisse Vorteile, denn die Datenhaltung liegt nunmehr beim Nutzer und Fragestellungen hinsichtlich Recht zur Bearbeitung, Speicherung und Herausgabe erübrigen sich dahingehend zu einem gewissen Teil.²⁰ Jedoch darf nicht vergessen werden, dass obwohl im Prozess der Authentifizierung bestimmt werden kann, ob bestimmte Informationen preisgegeben werden, kaum eine Kontrollmöglichkeit darüber besteht, was danach mit den freigegebenen Daten geschieht. Der Empfangende kann diese immer noch missbrauchen, ungenügend sichern oder gegen Vereinbarungen bzw. die jeweils getroffene Datenschutzerklärung verstossen. Auch diese Lösung bietet dahingehend keine absolute Sicherheit.

Gemäss Zanol, Czadilek, Lebloch zeichnen sich zwei Ansätze ab, wie die Nutzung der SSI mitunter vornehmlich erfolgen wird: Einerseits würde sich die Speicherung von Hashwerten der jeweiligen Identitätsattribute auf der Blockchain einiger Beliebtheit erfreuen. Auf der anderen Seite sei die entsprechende Speicherung der Metadaten (Public Keys und sogenannte Service-Endpoints, an welchen mit Services des Identitätseigentümers in Kontakt getreten werden kann)²¹, welche ausschliesslich die Kommunikation mit dem Agent²² ermöglichen sollen, eine gängige Variante. ²³

Auch im vorliegenden Use Case hat die Person selbst die Hoheit über die Herausgabe der Daten. Sie hat somit auch die Verantwortung betreffend ihrer persönlicher Informationen. Darüber hinaus soll in dieser Lösung sowohl der Public Key als auch der Hash des An- und Abwesenheitsprotokolls auf der Blockchain abgelegt werden. Diese beiden technischen Aspekte werfen datenschutzrechtliche Fragen auf, die in der Folge beleuchtet werden.

Das Design der Blockchain sieht vor, dass durch die Verkettung von Blöcken mittels Hash jegliche Manipulation sofort ersichtlich ist. Es kann somit keine Änderung oder Löschung erfolgen, ohne dass der Originalitätswert der Blockchain verloren geht. Im Lichte des DSG und der DSGVO bedarf somit die Verwendung dieser Technologie im Bereich von Personendaten einer vertieften Prüfung.

Primär ist die Ausgestaltung der Blockchain zu beachten: Man unterscheidet im Allgemeinen zwischen public und private Blockchain. Public Blockchains stehen jedem, der über die notwendige Software verfügt, offen und sind somit öffentlich einsehbar.²⁴ Aufgrund des allgemeinen Zugangs der öffenlichen Blockchain und der damit einhergehenden generellen Sichtbarkeit der Daten, die weder gelöscht noch verändert werden können, stehen diese in einem besonderen Spannungsverhältnis mit dem DSG und der DSGVO. Demgegenüber hat bei einer private Blockchain nur ein konkret bestimmter Kreis Zugang zu den Daten. Dieser Einschränkung zufolge weist die private Blockchain weniger Problemfelder auf.

Eine weitere Unterscheidung liegt in der Regulation der Schreib- und Validierungsberechtigung. Es gibt die Möglichkeit, diese Kompetenzen nur einem beschränkten Kreis von Teilnehmern zu erlauben; in diesen Fällen spricht man von einer permissioned Blockchain. Wenn keine Beschränkung besteht, so liegt eine permissionless Blockchain vor. Der Vorteil bei der private permissioned Blockchain ist, dass aufgrund der Notwendigkeit einer zentralen Instanz eine Verantwortlichkeit klar definiert werden kann. Ebenfalls kann im Zuge der Registrierung den datenschutzrechtlichen Vorgaben entsprochen, bzw. die Informationspflichten erfüllt sowie die erforderlichen Einwilligungen eingeholt werden. Je nach Ausgestaltung birgt die Blockchain somit in Hinblick auf den Datenschutz unterschiedlich ausgeprägte Fragestellungen.²⁵

Im Folgenden wird die public Blockchain und die damit verbundenen Fragen diskutiert. Die Unterscheidung permissioned/permissionless wird jeweils (sofern relevant) nur kurz beleuchtet.

Wie oben dargestellt, ist der Begriff «Personendaten» sowohl im Rahmen des DSG als auch der DSGVO weit gefasst. Da im vorliegenden Use Case der Public Key auf der Blockchain gespeichert werden soll, stellt sich die Frage nach dessen rechtlicher Qualifikation. Um diese Einordnung vorzunehmen, ist zunächst die Funktion des Schlüsselpaares (Public und Private Key), bzw. die dadurch ermöglichte asymmetrische Verschlüsselung zu betrachten.

Dieses sog. asymmetrische Kryptosystem ist ein Verschlüsselungsverfahren, bei dem die Parteien keinen gemeinsameen Schlüssel zur Dechiffrierung benötigen. Jeder Nutzer erzeugt ein eigenes Schlüsselpaar, der private und der öffentliche Schlüssel, die mathematisch miteinander verbunden sind. Mit dem Private Key können Dokumente, die mit dem öffentlichen Schlüssel verschlüsselt wurden, entschlüsselt werden und umgekehrt. Der private Schlüssel ist geheim zu halten. Der öffentliche Schlüssel hingegen muss notwendigerweise veröffentlicht oder zumindest bestimmten Dritten bekannt gemacht werden. Dabei ist zu beachten, dass keine Möglichkeit besteht, den privaten aus dem öffentlichen Schlüssel herzuleiten.²⁶

Das Schlüsselpaar Private und Public Key soll somit den Aussteller der Dokumente oder der jeweiligen Transaktion mit einer gewissen Sicherheit ausweisen. Durch diese Zurechenbarkeiten kann mithin eine gewisse Sicherheit im Geschäftsverkehr geschaffen werden.

Bei dieser gesamthaften Betrachtungsweise könnte man beim Schlüsselpaar als solches von personenbezogenen Daten ausgehen. Betrachtet man die asymmetrische Verschlüsselung differenzierter, kommt man nicht umhin zu fragen, ob der tatsächliche Bezug nicht lediglich durch den Private Key gegeben ist und der Public Key demgegenüber nur das Werkzeug darstellt, um die Funktion des Private Keys zu ermöglichen. Gerade mit Blick auf Bitcoin ist erkennbar, inwiefern diese Frage berechtigt ist: Mittels Private Key kann eine digitale Signatur erstellt werden, die die Bitcoins weiter transferiert. Der damit verbundene Public Key kann von jedermann zur Überprüfung der Transaktion genutzt werden. Durch diesen können keine Rückschlüsse auf den Private Key gemacht werden und somit auch nicht auf die Person (oder das Unternehmen), wenn nicht die Umstände dazu führen, dass eine Identifikation möglich wird. Im Falle von Bitcoin hat die Forschung jedoch gezeigt, dass öffentliche Schlüssel oft über Zusatzinformationen mit natürlichen Personen verbunden werden können. In diesen Fällen wird somit vertreten, dass von einem personenbezogenen Datum gesprochen werden muss.²⁷ Dies zeigt auf, dass für eine korrekte Einordnung eine Einzelfallbetrachtung notwendig und jeweils darauf abzustellen ist, ob aufgrund der Umstände der Public Key einer bestimmten Person zugeordnet werden kann.

Vorliegend wird sowohl der Public Key der Einzelperson im Rahmen der SSI auf einer Blockchain gespeichert als auch jener der anerkannten Zertifizierungsstelle.

Wenn der öffentliche Schlüssel nur mit einem Unternehmen verbunden werden kann, hat dieser nicht als personenbezogene Daten nach DSGVO zu gelten.²⁸ Im Rahmen der kommenden Revision des DSG sollen im Sinne der Harmonisierung mit der DSGVO juristische Personen vom Schutzbereich ausgeschlossen werden. Bis zur allfälligen Gesetzesänderung ist jedoch von der juristischen Person als Subjekt des Datenschutzes auszugehen.

Der Key wird – auf den vorliegenden Fall reduziert – lediglich auf der Blockchain abgespeichert. Es finden demnach in diesem Zusammenhang keine weiteren Transaktionen statt. Folglich ist fraglich, ob von dem Public Key auf das Zertifizierungsunternehmen geschlossen werden kann. Gemäss dem heutigen Stand der Technik ist dies nicht möglich und auch künftig wäre dies ein grösserer technischer Aufwand. Bei dieser Betrachtung ist somit nicht von einem Personendatum auszugehen. Es ist jedoch durchaus möglich, dass eine Zertifizierungsstelle sein Schlüsselpaar nicht nur für diesen Case einsetzt, sondern es sich auch noch weiter zu Nutze macht. Ebenfalls muss eingeräumt werden, dass bei einem kleinen Kreis von Zertifizierungsunternehmen nicht ausgeschlossen werden kann, dass in Verbindung mit weiteren Informationen der Public Key schlussendlich doch einem Unternehmen zugeordnet werden könnte. Der Personenbezug bleibt jedoch nach wie vor sehr schwach. Selbst bei öffentlicher Bekanntgabe ist wohl kaum von einer Persönlichkeitsverletzung auszugehen.

Darüber hinaus wird im vorliegenden Use Case das Zertifizierungsunternehmen ein Interesse daran haben, dass der Public Key öffentlich ist und gespeichert wird, da ansonsten das System und die vereinfachte Handhabung der Prüfung nicht funktionieren würde. Dennoch ist darauf hinzuweisen, dass der Inhaber des Public Keys entscheidet, ob und wenn ja, wo er diesen veröffentlicht. Daher ist auch bei diesem Use Case die Zertifizierungsstelle vorgängig über Art und Ort der Speicherung in Kenntnis zu setzen. Um allfälligen Streitigkeiten entgegen zu wirken, wird im Zuge der Informierung der einzubindenden Unternehmen direkt eine Einwilligung im Sinne von Art. 13 DSG eingeholt.

Hinsichtlich dem Recht auf Löschung kann Folgendes festgehalten werden: Einerseits besteht die Möglichkeit, dass der Private Key vernichtet wird und so auch der Public Key keine Verwendung mehr findet, bzw. seines Sinnes und Zweckes entleert ist. Auf der anderen Seite wäre ein Löschungsbegehren, nachdem die Funktionsweise der Blockchain bekannt ist und auch welche Gesetze diesem inhärent sind, als Verletzung gegen den Grundsatz von Treu und Glauben gemäss Art. 2 ZGB zu werten.

Das Gesagte hat ebenfalls für die öffentlichen Schlüssel der Privatperson, in casu den Mitarbeiter, zu gelten. Die Ablage der Public Keys dient lediglich der Erfassung und es können keine Rückschlüsse auf die Person gemacht werden. Aufgrund dessen liegt keine datenschutzrechtliche Problematik vor.²⁹ Im Rahmen der Identifizierung der Mitarbeitenden ist, aus den oben genannten Gründen, über die Speicherung des Public Keys zu informieren und allenfalls das Einverständnis nach Art. 13 DSG und Art. 6 DSGVO zu verlangen. Auch hier kann dies im Zuge der Einbindung in das System erfolgen.

Hashes (sog. Verschlüsselungswerte) werden mittels Hash-Algorithmen erstellt. Ein Hashwert kann als Prüfsumme bezeichnet werden, die aus dem zu prüfenden Inhalt selbst errechnet werden kann. Der Hash ist mit dem Fingerabdruck vergleichbar, der die ursprünglichen Daten charakterisiert. Aus dem Hashwert kann nicht auf das ursprüngliche Objekt geschlossen werden, es könnte höchstens durch Ausprobieren gefunden werden (sog. Nichtreproduzierbarkeit).³⁰ Zu erwähnen ist jedoch, dass je mehr Informationen über die Generierung des Hashes vorliegen, desto eher kann der Lösungsraum einer Brute-Force-Attacke³¹ eingeschränkt werden, was die Herleitbarkeit des Hashes erhöht.

Sind neben den Hashwerten keine weiteren Merkmale oder Transaktionen auf der Blockchain, werden lediglich die ausserhalb des Systems abgelegten Daten nachgewiesen. Erst wenn der Hashwert als ID fungiert und mit weiteren Daten oder mit Transaktionen verknüpft wird, kann ein Personenbezug hergeleitet werden. Dies nicht aufgrund des Hashwertes selbst, sondern vielmehr aus dem Netz von Informationen, welche die Vorgänge erzeugen.

Stengel/Aus der Au wollen gehashte Daten immer als Personendaten nach DSGVO gelten lassen. Sie berufen sich dabei auf die Artikel-29-Datenschutzgruppe, gemäss welcher Hashfunktionen als Technik zur Pseudonymisierung – statt Anonymisierung – gelten sollen.³²

Die Artikel-29-Datenschutzgruppe hat sich in ihrer Stellungnahme 0829/14/EN, WP216 wie folgt geäussert: « […] Wenn jedoch der Bereich der Eingabewerte der Hash-Funktion bekannt ist, können diese über die Hash-Funktion wiedergegeben werden, um den richtigen Wert für einen bestimmten Datensatz abzuleiten. Wurde beispielsweise ein Datensatz durch Hashing der nationalen Identifikationsnummer pseudonymisiert, so kann dies einfach durch Hashing aller möglichen Eingabewerte und Vergleich des Ergebnisses mit den Werten im Datensatz abgeleitet werden. Hash-Funktionen sind in der Regel so konzipiert, dass sie relativ schnell zu berechnen sind und Brute-Force-Angriffen ausgesetzt sind. Die Verwendung einer salted-hash-Funktion (bei der ein Zufallswert, das so genannte ‹Salz› zu dem zu hashenden Attribut hinzugefügt wird) kann die Wahrscheinlichkeit der Ableitung des Eingabewerts verringern, aber dennoch kann die Berechnung des ursprünglichen Attributwerts, der sich hinter dem Ergebnis einer salted Hash-Funktion verbirgt, mit angemessenen Mitteln noch möglich sein.»

Andere Autoren wählen für die Einordnung eine differenzierte Betrachtungsweise. So beispielsweise Erbguth: «Werden kryptografische Hashwerte auf einer öffentlichen Blockchain abgelegt, so beweist der Hashwert selbst zunächst nur, dass das digitale Objekt zum Zeitpunkt des Erstellens des Blocks existierte. Sind auf der Blockchain keine weiteren Merkmale oder Transaktionen neben dem Hashwert aufgeführt, so validiert der Hashwert damit lediglich ausserhalb der Blockchain befindliche Daten. Werden diese ausserhalb der Blockchain abgelegten Daten gelöscht, ist damit auch der Hashwert auf der Blockchain ohne jede Aussagekraft. Anders sieht es aus, wenn der Hashwert als eine Art pseudonyme ID mit weiteren Daten, wie z.B. Transaktionen, verknüpft wird. Dann allerdings ergibt sich der Personenbezug nicht aus dem Hashwert selbst, sondern aus dem Netz der darüber verknüpften weiteren Informationen.»³³ Mittlerweile hat ebenfalls EU Blockchain Observatory festgehalten, dass die Einordnung des Hashes anspruchsvoll sei und nicht ohne Weiteres erfolgen könne, da es sich hierbei um eine Grauzone handle.³⁴

Im vorliegenden Use Case wird aus den Protokollen periodisch ein Hash generiert, der zu Zwecken des Nachweises und zur Sicherstellung der Unveränderbarkeit auf der Blockchain gespeichert wird. Diese Hashes basieren auf den Informationen betreffend Ein- und Austritt der zertifizierten Personen. Aufgrund des oben Erwähnten stellt sich die Frage, ob ein Personenbezug gegeben ist, da nicht nur hinsichtlich einzelner Personen, sondern auch bei Personengruppen ein Schutz besteht.

Der Hash wäre als Personendatum zu qualifizieren, wenn im Sinne von Art. 4 DSG und Art. 5 DGVO aufgrund der Umstände auf den Inhalt bzw. die Personen geschlossen werden könnte (indirekte Bestimmbarkeit). Da in casu weder Transaktionen noch andere Handlungen vorgenommen werden, die zu weiteren Informationen führen könnten, ist dahingehend ein Rückschluss nicht möglich. Dem steht die obige Stellungnahme der Artikel-29-Datenschutzgruppe gegenüber, wonach ein Hash allgemein als pseudonymisiertes Personendatum zu betrachten ist, da es möglich sein könnte dieses zu erraten, wenn man gewisse Parameter weiss. Diesen Ausführungen ist entgegenzuhalten, dass mit Blick auf den technischen Aspekt des Hashings je nach Grösse des Bereiches der Eingabewerte zu differenzieren ist. Hierzu folgende Erklärung anhand des Beispiels von Passwörtern, die gehasht werden: Wenn der Bereich der Eingabewerte aus einem 8-stelligen Passwort besteht, dessen Stellen die Zahlen 0–9 enthalten können, ergibt sich eine mögliche Kombination von 8^10 Werten (= 1’073’741’824). Diese zu hashen dauert aufgrund ihrer Einfachheit entsprechend kurz. In der Folge gestaltet sich der Vergleich und somit die Ableitung des ursprünglichen Eingabewertes ebenfalls einfach, sofern die Struktur des Wertes (8-stellig und Zahlen von 0–9) bekannt ist. Wenn nun die Kombination 24 Stellen hat und neben den Zahlen auch Buchstaben möglich sind, dann ergibt dies bereits 24^36 = 4.87e+49 mögliche Werte. In diesem Falle dauert die Ermittlung, selbst wenn man pro Sekunde zwei Millionen Hashes berechnen könnte, 7.5e+35 Jahre. Die Bitcoin Hashrate³⁵ beträgt aktuell 70’000’000 Terra Hashes/s – selbst wenn man diese Leistung für die Eruierung verwenden würde, bedürfte es 22’064’803’018’079’654’732’689.4 Jahre, um eine Entschlüsselung vorzunehmen. Im Übrigen besteht zur Verhinderung der Ermittlung die Möglichkeit, ausser dem Hash selbst noch einen geheimen Schlüssel einzufügen, der lediglich zwischen den Knoten der Blockchain geteilt wird. Dies kann selbst bei «einfachen» Hashes (insbesondere Daten mit geringer Entropie³⁶) verhindern, dass die Ermittlung möglich ist, wodurch eine höhere Sicherheit gewährleistet wird.

Mit Blick auf die obigen Ausführungen, wonach ein Bezug gemäss Datenschutz nur solange als gegeben erachtet wird, als die Identifizierung ohne unverhältnismässigen Aufwand möglich ist, wird ersichtlich, dass je nach Entropie nicht mehr von Personendaten gesprochen werden kann. Ebenfalls kann nicht per se auf eine Pseudonymisierung geschlossen werden. Bei jener besteht – wie unter III, A. 2 dargestellt – ein Schlüssel, der es dem Inhaber erlaubt, die Pseudonymisierung aufzuheben. Da der Hash wie oben dargestellt nicht reversibel ist, somit kein Schlüssel besteht, um die verhashten Informationen festzustellen, hat er auch nicht als Pseudonym zu gelten. Die Sachlage ist eher mit jener der anonymisierten öffentlichen Urteile zu vergleichen. Das Gericht und die beteiligten Personen kennen die Identitäten der Parteien, die in der öffentlichen Version als Person A, Unternehmen X oder ähnlich bezeichnet werden. Nichtsdestotrotz wird von einer Anonymisierung gesprochen, da kein Schlüssel existiert, der aus dem Terminus «Person Y» die darunter liegende tatsächliche Identität eruieren kann. Es ist jedoch aufgrund des heutigen umfassenden Informationsflusses immer möglich mit genügend Recherche die jeweiligen Beteiligten ausfindig zu machen. Gemäss dem Entscheid der Eidgenössischen Rekurskommission für Staatshaftung vom 15. Februar 2006, ist die Anonymisierung genügend, wenn der Aufwand zur Feststellung der Identität des Beschwerdeführers so gross erscheint, dass ihn ein Dritter, der an den Angaben interessiert ist, vernünftigerweise nicht auf sich nehmen wird (E. 5b, c). Es liegt überdies keine Verletzung des Anonymisierungsgrundsatzes vor, wenn Personen, welche mit den Einzelheiten des Falles vertraut sind, gegebenenfalls erkennen können, um wen es sich handelt.³⁷ Folglich ist die generelle Annahme, dass ein Hash per se nicht als Anonymisierung, sondern als Pseudonymisierung und als Personendatum zu qualifizieren sei, verfehlt. Vielmehr sollte im Einzelfall geprüft werden, ob ein Rückbezug mit verhältnismässigem Aufwand möglich ist.

Im vorliegenden Use Case stellt sich daher die Hauptfrage, wie gross der Bereich der Eingabewerte ist. Das Log erfasst Ein- und Ausgänge im Bereich von Millisekunden, welche ebenfalls zu den verhashten Daten gehört. Dies mit allen anderen Eingaben zu erraten bzw. zu berechnen, ist vergleichbar mit dem oben aufgeführten Beispiel zu 24-stelligen Passwörtern. Folglich kann kein Rückbezug angenommen werden und der Hash gilt nicht als personenbezogenes Datum.

Selbst wenn bei den Hashes von einem Personenbezug ausgegangen werden müsste, würde dies den vorliegenden Use Case nicht verunmöglichen. Die Erfassung der Daten wäre über die Notwendigkeit im sicherheitsrelevanten Bereich meist über eine gesetzliche Grundlage gerechtfertigt. Das gilt etwa für die Protokollierung, welche im Interesse der Sicherheit und somit ebenfalls in jenem der Allgemeinheit erfolgt. Die Speicherung dient in diesen Fällen somit einem übergeordneten Interesse und ist aufgrund dessen nach Art. 13 DSG sowie Art. 6 DSGVO gerechtfertigt. Zudem darf Folgendes nicht vergessen werden: werden die externen Daten gelöscht, aufgrund deren der Hash entstanden ist, so ist Letzterer seines Inhaltes entleert und dadurch ohne jede Aussagekraft. Folglich könnte dem im DSG und insbesondere in der DSGVO geforderten Recht auf Berichtigung und Löschung gerecht werden.

Die aktuelle AHV-Nummer der Schweiz hat 13 Stellen und enthält im Gegensatz zu den früheren Nummern keinerlei Personenkennzeichen mehr.³⁸ Aufgrund dessen wird diese Sozialversicherungsnummer als sog. Nichtsprechende Nummer ausgewiesen und ist im Sinne von Art. 3 lit. a DSG 1. Teilsatz betreffend Bezug auf eine bestimmte Person nicht als geschütztes Personendatum zu qualifizieren. Wie erwähnt, hängt die Qualifikation im Sinne des zweiten Teilsatzes von Art. 3 lit. a DSG betreffend die bestimmbare Person davon ab, ob mit vernünftigem Aufwand mit zusätzlichen Informationen eine Individualisierung möglich ist.³⁹ Aufgrund des oftmals kontrovers diskutierten⁴⁰ exzessiven Gebrauchs der AHV-Nummer und der jeweiligen Verknüpfung und Ablage mit weiteren Angaben zur Person, hat die Nummer – trotz der Unmöglichkeit des Rückschlusses und der eigentlichen völligen Anonymität – nunmehr in weiten Bereichen grundsätzlich als Personendatum zu gelten.⁴¹

Mit Blick auf die obigen Ausführungen fällt somit Folgendes auf: Einerseits hat dieses Praxisbeispiel gezeigt, dass eine absolut nicht rückverfolgbare Nummer in Verbindung mit weiteren Informationen doch verhältnismässig leicht zu einem Personendatum werden kann, wobei auch hier wieder eine Einzelfallbetrachtung gemacht werden muss. Dabei darf nicht vergessen werden, dass jede Person Inhaber nur einer einzelnen Nummer sein kann, wodurch bei entsprechender Nutzung eine grössere Möglichkeit der Informationssammlung besteht. Dies ist bei Public/Private Keys oder auch generierten Hashes nicht der Fall. Jede Person kann so viele Keys besitzen wie er will und sie auch nach seinem Willen einsetzen. Dies zeigt, dass hier umso mehr eine Betrachtung des Einzelfalls notwendig ist, da ansonsten nicht adäquate Einordnungen und Rechtsfolgen entstehen.

Bestehende Regelungen zur Haftung wie OR 41, das Produktehaftpflichtgesetz, die Kodifizierungen zur Haftung des Gemeinwesens usw. stellen ausreichende Rechtsgrundlagen dar. Im vorliegenden dezentralen System ist vielmehr fraglich, wie und wo die Verantwortlichkeit zu liegen kommt und wer schlussendlich für was und gestützt auf welche Rechtsgrundlage haftet.⁴² Bei der Bitcoin-Blockchain wurde dafür plädiert, dass die Entwickler die Verantwortlichen sind. Dabei müsste mit Blick auf die Produktehaftpflicht die Frage gestellt werden, ob ein Defekt oder ein unerwünschtes Resultat aufgrund der Nutzung entstand oder so gar nicht hätte existieren dürfen. Nur Nutzung, die vernünftigerweise hätte erwartet werden müssen, wäre somit bei Defekten der Technologie selbst zu beachten. Wäre somit erstellt, dass eine fehlerhafte Architektur vorliegt, so könnte man allenfalls eine Verantwortlichkeit der Entwickler annehmen. Jedoch ist eine Durchsetzung der Haftung nur bei den privaten Blockchains möglich, da bei diesen bekannt ist, wer sie aufgebaut hat und betreibt. Bei den öffentlichen Blockchains haben die jeweiligen Entwickler meist unter Pseudonymen gearbeitet, wodurch ihre Identitäten unbekannt geblieben sind.⁴³

Auch hinsichtlich der Netzwerkbetreiber ist es schwierig, einen Anknüpfungspunkt für eine Verantwortlichkeit zu erhalten. Lediglich bei einer permissioned Blockchain ist klar, wer genau die Blockchain betreibt bzw. Bewilligungen vergibt etc. und somit für die Nutzung bzw. für die Datenproduktion/-erstellung verantwortlich ist. Bei einer öffentlichen Blockchain ist die Eruierung unmöglich, da das Kollektiv⁴⁴, das bekannt ist, bereits viel zu gross ist, um eine Zurechnung zu machen. Darüber hinaus besteht in Ermangelung einer Meldepflicht betreffend die Betreiber ebenfalls eine grosse Dunkelziffer.

Hinsichtlich der Transaktionen wurde dafür plädiert, dass derjenige, der eine Transaktion erstellt, signiert und in das Bitcoin-Netzwerk gibt, der Verantwortliche i.S.v. Art. 4 Nr. 7 DSGVO ist. Eine Transaktion unter die Verantwortlichkeit im Rahmen des DSG/DSGVO zu subsumieren erscheint etwas fragwürdig. Dies nicht zuletzt, weil gemäss Definition von Art. 4 Nr. 7 DSGVO «Verantwortlicher» die Person oder Stelle ist, die über die Zwecke und Mittel der Verarbeitung der Personendaten entscheidet. Diesen Versuch der Subsumtion ist nicht zuletzt die Folge der extensiven Zuordnung von Informationen als Personendaten.

In Fällen, bei welchen man nicht umhinkommt, von Personendaten in Zusammenhang mit Blockchain zu sprechen, hat folgendes zu gelten: Jeder hat sich an die Bearbeitungsgrundsätze gemäss Art. 4 DSG zu halten bzw. dafür besorgt zu sein, dass die Personendaten korrekt und genügend gesichert sind. Demgegenüber wurden im Rahmen der DSGVO die Verantwortung auf vier verschiedene beteiligte Instanzen aufgeteilt: Die betroffene Person (Art. 4 Nr. 1 DSGVO), den Verantwortlichen (Art. 4 Nr. 7 DSGVO), den Auftragsverarbeiter (Art. 4 Nr. 8 DSGVO) und Dritte (Art. 4 Nr. 10 DSGVO). Dieser Aufteilung liegt die Konzeption zu Grunde, dass jeweils einer dieser Akteure festlegt, zu welchem Zweck mittels welcher Instrumentarien die Personendaten bearbeitet werden sollen und immer auch jener somit – und nie nur der Verarbeiter – die Verantwortung tragen soll. Dass dieses System mit einer klaren Zuordnung im Rahmen der öffentlichen Blockchain nicht greifen kann, ist augenfällig. Aber auch hinsichtlich der Konzeption des DSG dürfte sich, je nach Ausgestaltung der Blockchain (public/privat oder permissioned/permissionless), die Suche und schlussendlich Inpflichtnahme des Verantwortungsträgers als schwierig gestalten.

Für den vorliegenden Fall gilt somit, dass sofern es sich entgegen der obigen Ausführungen um Personendaten handeln sollte, einerseits die Akteure selbst, welche die Blockchain als Ablage nutzen, entsprechend verantwortlich sind.

Da allenfalls ein Interesse daran besteht, dass nur bestimmte Informationen, z.B. die anerkannten Ausbildungsstätten, auf der Blockchain gespeichert sind, könnte dahingehend eine permissioned Blockchain geschaffen werden. Insofern hätte man hier auch eine verantwortliche Instanz, namentlich die Stelle, welche die permission vergibt. In diesem Fall würde sich somit auch die Suche nach einem Verantwortlichen erübrigen.

Im Rahmen der Ablage des Hashes hat man dafür besorgt zu sein, dass dieser so konzipiert ist, dass tatsächlich kein Rückbezug stattfinden kann. Sei es, dass die Informationen eine so hohe Entropie aufweisen, dass sie in absehbarer Zeit nicht zurückbezogen werden können oder aber, dass ein geheimer Key eingefügt wird, der nur den entsprechenden Parteien bekannt ist.

Wie oben dargestellt, kann die Blockchain mehr als eine Transaktionsplattform für Bitcoin und Co. darstellen. Jedoch ist die Handhabung und Ausgestaltung noch immer mit vielen Unklarheiten verbunden. In diesem Ökosystem der Trustlessness und gleichzeitigen teilweisen Anonymität stellen sich auf rechtlicher Seite etliche Herausforderungen. Dies nicht zuletzt, da sich die technische Seite sehr komplex präsentiert und diese bereits auch nur zu erfassen und zu verstehen eine Sache für sich ist. Eine juristisch korrekte Lösung zu finden, die angemessen ist und die Technologie nicht verunmöglicht, stellt eine nicht unerhebliche Herausforderung dar.

Vielerorts wird ebenfalls aufgrund der Fortentwicklung der Technik und der allfälligen Möglichkeit künftig mittels Quantencomputern davor gewarnt, mittels Kryptographie etc. zu arbeiten, da man irgendwann in der Lage sein könnte, jedwede Information zu entschlüsseln. Dazu sei Folgendes erwähnt: die Entwicklung der Technologien wird voranschreiten, ob man diese nun einsetzt oder nicht. Sobald Quantencomputer und die dazugehörenden Möglichkeiten Realität sein werden, muss ohnehin der Umgang mit Daten neu überdacht werden und der Datenschutz anders als bisher stattfinden. Man sollte sich somit nicht bereits vorgängig vor den Technologien verschliessen, sondern durch sie lernen, um auf die Änderungen vorbereitet zu sein oder zumindest schnellstmöglich auf sie reagieren zu können.

Die Technologie bietet, wie aufgezeigt, viele Möglichkeiten für Lösungen von bislang aufwändigen Prozessen, es wäre daher verfehlt, aufgrund von Ängsten und Unsicherheiten das Potenzial nicht auszuschöpfen und den Einsatz der Blockchain im nicht finanziellen Sektor frühzeitig zu verwerfen.

Barbara A. Möri, MLaw Rechtsanwältin, SBB AG, Bern.