Aufsatz : Private Key als personenbezogenes Datum : aus der RDV 1/2021, Seite 14

Jede auf der Blockchain durchgeführte Transaktion wird von jedem einzelnen Node auf ihre Richtigkeit überprüft. Stuft der einzelne Node die Transaktion als valide ein, sendet er diese an alle Knoten, mit denen er verbunden ist, weiter. Diese Knoten prüfen sodann die Validität der Transaktion in derselben Weise. Eine Transaktion gilt erst dann bestätigt, wenn sämtliche Nodes die Prüfung mit positivem Ergebnis durchgeführt haben. Gilt die Transaktion als bestätigt, wird sie der bisherigen Transaktionenhistorie als sog. Block hinzugefügt.^[3] Anhand der Zugriffsberechtigung wird grundsätzlich zwischen öffentlichen und privaten Blockchain-Netzwerken unterschieden.^[4] Öffentliche Systeme erlauben das Lesen, das Schreiben von Blöcken sowie das Prüfen der Daten bzw. die Vornahme von Transaktionen für jeden Teilnehmer,^[5] bei privaten Netzwerken ist dies hingegen qualifizierten Personen sowie Gruppen vorbehalten.^[6] Dementsprechend setzt die Teilnahme an einer privaten Blockchain die Vergabe von Zugriffsberechtigungen sowie Nutzerkennungen durch einen Administrator voraus. Dies hat wiederum zur Folge, dass die Teilnehmer mithilfe der Kennungen in der Regel ohne weiteres identifiziert werden können.^[7]

2. Begriff und Funktion des Private Key

Bei der Vornahme von Transaktionen auf der Blockchain wird ein kryptographisches Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel, eingesetzt, sog. Public Key-Verfahren oder asymmetrische Kryptographie. Das Schlüsselpaar wird mithilfe eines Algorithmus – beispielsweise des auch bei Bitcoin verwendeten ECDSA- Algorithmus – erzeugt.^[8] Die Schlüssel bestehen je weils aus alphanumerischen Zeichen, bei Anwendung des ECDSA-Algorithmus bspw. aus 27 bis 34, beginnend mit der Ziffer 1 oder 3 (z.B. 3J98t1WpEZ73CNmQviercnyWrnqRhWNLy).^[9] Der Public Key fungiert – vergleichbar mit einer Kontonummer oder E-Mail – als öffentliche Adresse und ist allen Teilnehmern des Netzwerks bekannt.^[10] Der Private Key dient hingegen – vergleichbar mit einem PIN-Code- der Authentifizierung des Transaktionsteilnehmers.^[11] Der Absender „unterzeichnet“ die Nachricht mit seinem privaten Schlüssel und sendet diese an den Empfänger. Der Empfänger entschlüsselt die Nachricht mit dem öffentlichen Schlüssel des Absenders und verifiziert damit zugleich deren Identität.^[12] Da der Private Key die volle Verfügungsgewalt über die mit der Adresse verbundenen Werte gewährt, sollte dieser vom Berechtigten geheim gehalten bzw. sicher aufbewahrt werden.^[13]

3. Arten von Wallets

Die „Aufbewahrung“ des Private Key erfolgt über ein sog. Wallet. Zwar wird der Begriff häufig nur im Sinne einer Applikation bzw. Software genutzt, die die Verwaltung von Token mittels eines Interface ermöglicht,^[14] jedoch lässt sich hierunter im weiteren Sinne praktisch jede Vorrichtung fassen, die zur Verwaltung bzw. die Verwahrung von Keys eingesetzt wird. Letztendlich ist unter Wallet die spezifische kryptografiebasierte Verbindung eines privaten und öffentlichen Schlüssels zu verstehen.^[15] Zwischen den verschiedenen Wallets wird hauptsächlich danach unterschieden, ob der Nutzer den Key mithilfe des Wallets selbst aufbewahrt oder jemandem anvertraut (custodian bzw. non-custodian wallets)^[16] bzw. danach, ob sie mit dem Internet verbunden sind (s. hot oder cold Wallets).^[17] Bei cold Wallets lässt sich eine Vielzahl an technischen Lösungen beobachten. Im Privatgebrauch sind mit externen Festplatten vergleichbare Vorrichtungen sowie mithilfe eines speziellen Verfahrens hergestellte Karten, sog. Card-Wallets (s. bspw. Card Wallet, ein Angebot von Coinfinity und der Österreichischen Staatsdruckerei) am meisten verbreitet. Der Private Key wird dabei direkt auf eine Polycarbonat-Kunststoffkarte gelasert.^[18] Im institutionellen Bereich wird als zusätzliche Sicherheitsmaßnahme mitunter auch die Verwahrung der Karte in einem sicheren Schließfach bzw. Tresor angeboten.^[19]

Besonders bei Angeboten für institutionelle Kunden erfolgt die Speicherung häufig auf sog. Hardware Security Modulen (HSM), d.h. auf einem Computer mit kryptografischen Verarbeitungsfunktionen.^[20] Zu den cold Wallets gehören auch sog. Paper Wallets, bei denen der Nutzer seinen Private Key auf einem Blatt Papier notiert.^[21]

Üblicherweise wird auch zwischen Hardware-Wallets (s. auch Card-Wallets) und digitalen Applikationen differenziert. Im Hinblick auf digitale Applikationen lassen sich auch Desktop, Mobile sowie Web Wallets unterscheiden, wobei der Private Key bei den ersteren auf dem Endgerät, beim letzteren auf dem Server des Webseitenanbieters gespeichert wird.^[22]

Die oben genannten Abgrenzungskriterien sind allerdings nicht als absolut anzusehen, vielmehr lässt sich in der Regel jedes konkrete Wallet- Produkt zugleich unter mehrere Kategorien einordnen. So kann eine gängige mobile Wallet-App beispielsweise als mobile Wallet und zugleich als non-custody-Wallet bezeichnet werden. Ein Hardware-Wallet oder sog. Card-Wallet stellt hingegen in der Regel ein non-custody cold Wallet dar. Wird die Karte von dem Anbieter aufbewahrt, vgl. die Lösung von Daenerys & Co. oder Blockvault,^[23] handelt es sich wiederum um ein custodian cold Wallet. Auch können cold und hot-Wallet-Lösungen miteinander kombiniert werden. In der Praxis erfolgt dies beispielsweise durch den Einsatz von Hardware Approval Terminals (ATs).^[24]

Eine Kategorisierung ist dennoch mitnichten obsolet, insbesondere hat die Frage, ob es sich um ein Custody-Wallet handelt, im Hinblick auf das Datenschutzrecht entscheidende Bedeutung. Da die datenschutzrechtlichen Verpflichtungen der DS-GVO nur die Verarbeitung personenbezogener Daten von anderen natürlichen Personen betreffen als der datenverarbeitenden Stelle und der Betroffene i. S. d. Art. 4 Nr.1 DS-GVO nie zugleich Verantwortlicher oder Dritter sein kann,^[25] vgl. auch die Differenzierung zwischen betroffener Person, Verantwortlichen und Dritten in Art. 4 Nr. 1, Nr. 7 und Nr. 10, sind nur custody- WalletLösungen von datenschutzrechtlicher Relevanz.

In der Praxis spielen neben den „klassischen“ Wallet-Anbietern auch Kryptobörsen eine wichtige Rolle. Während die Leistung der ersteren darin besteht, dem Nutzer eine Software oder sonstiges Speichermedium zur Verfügung zu stellen, wickeln Kryptobörsen vordergründing den Handel mit Kryptowerten ab. Diese führen die Verwahrung der Token in der Regel nur als Nebenleistung aus und verwahren die Token ihrer Kunden in der Regel nur soweit selbst, als dies unmittelbar zur Abwicklung des Handels erforderlich ist.^[26] Kryptobörsen, die auch eigene Wallet-Lösungen anbieten, unterscheiden sich hingegen nicht von reinen Wallet-Anbietern.

II. Private Key: personenbezogenes Datum?

Fraglich ist, ob der Private Key im Hinblick auf seine Verwahrung als personenbezogenes Datum im Sinne der DSGVO anzusehen ist, wobei zwischen zwei wesentlichen Aspekten zu differenzieren ist.

Zunächst ist zu klären, ob ein Private Key überhaupt bzw. allgemein, ohne Rücksicht auf die konkrete Art seiner Verwahrung bzw. Speicherung als personenbezogenes Datum angesehen werden kann. In einem zweiten Stritt ist sodann zu untersuchen, ob der Private Key im Hinblick auf die Art seiner Verwahrung im Einzelfall als personenbezogenes Datum anzusehen ist. Hierbei kommt der Frage, ob und inwieweit der erforderliche Personenbezug im Zusammenhang mit dem Speicher- und Aufbewahrungsvorgang hergestellt wird, wesentliche Bedeutung zu.

1. Private Key als Sachdatum und reine Zahlenkombination

Indes könnten technisch-funktionale Besonderheiten des Private Key dessen Eigenschaft als personenbezogenes Datum per se entgegenstehen.

Zum einen könnte der Private Key als (bloßes) Sachdatum aus dem Anwendungsbereich des Art. 2 DS-GVO von vornherein herausfallen.

Da Sachdaten sich auf eine – analoge oder digitale – Sache^[27] beziehen und diese beschreiben, sind sie zunächst keine personenbezogenen Daten.^[28] Im Hinblick auf das kryptografische Schlüsselpaar der Blockchain-Technologie ließe sich argumentieren, dass der Public Key lediglich die Funktion hat, den Wallet zu kennzeichnen ohne Rückschlüsse auf den Inhaber des Wallets zuzulassen und somit als bloßes Sachdatum anzusehen ist. Da der Private Key aufgrund des technischen Vorgangs der Schlüsselerzeugung lediglich das ergänzende Gegenstück des Public Key darstellt, hätte dies konsequenterweise zur Folge, dass auch der Private Key als bloßes Sachdatum zu behandeln ist.

Allerdings können auch Sachdaten als personenbezogene Daten anzusehen sein, soweit sie in ihrem jeweiligen Kontext Auswirkungen auf rechtliche, wirtschaftliche oder soziale Positionen einer Person haben oder sich zugleich zur Beschreibung ihrer individuellen Verhältnisse eignen.^[29] Somit ist – unabhängig davon, ob sich die Funktion des Public Key tatsächlich auf die Kennzeichnung des Wallets reduzieren lässt und dies auch auf den Private Key „durchschlägt“, allein maßgebend, ob im Hinblick auf den Private Key im Einzelfall ein hinreichender Personenbezug hergestellt werden kann.

Auch der Umstand, dass es sich bei dem Private Key lediglich um eine Zeichenkombination handelt, steht seiner Eigenschaft als personenbezogenes Datum nicht entgegen. Die Definition des personenbezogenen Datums gem. Art. 2 DS-GVO ist sehr weit gefasst und enthält keine Einschränkung dahingehend, dass das Datum in verbalisierter Form ausgedrückt werden soll. Vielmehr können sowohl nach Erwägungsgrund 30 als auch nach der neuesten Rspr. des EuGH auch reine Zahlenkombinationen – wie beispielsweise statische und dynamische IP-Adressen – ohne weiteres als personenbezogene Daten angesehen werden.^[30]

2. Pseudonymisierung

Fraglich ist allerdings, ob und inwieweit eine Pseudonymisierung bei der Qualifizierung des Private Key als personenbezogenes Datum zu berücksichtigen ist. Die Frage stellt sich zum einen im Hinblick auf den Umstand, dass der Private Key in funktioneller Hinsicht selbst als ein Pseudonym anzusehen sein könnte, zum einen wenn dieser aus Sicherheitsgründen zusätzlich verschlüsselt wird.

a) Grundsatz: Pseudonymisierung schließt den Personenbezug nicht aus

Pseudonymisieren steht der Personenbezogenheit eines Datums grundsätzlich nicht entgegen. Vielmehr ergibt sich bereits aus Erwägungsgrund 26 ausdrücklich, dass einer Pseudonymisierung unterzogene personenbezogene Daten, die durch Heranziehung zusätzlicher Informationen einer natürlichen Person zugeordnet werden können, als Informationen über eine identifizierbare Person betrachtet werden sollten. Die Identifizierbarkeit ist erst bei einer Anonymisierung nicht mehr gegeben, d.h. dann, wenn das personenbezogene Datum derart verändert wird, dass die hinter den Einzelangaben über persönliche oder sachliche Verhältnisse stehende betroffene Person nicht bzw. nicht mehr identifiziert werden kann. Soweit die Zuordnung zu einer natürlichen Person – wenn auch durch Hinzuziehung zusätzlicher, ggf. getrennt aufbewahrter Informationen – möglich ist,^[31] liegt lediglich Pseudonymisierung und somit grundsätzlich ein personenbezogenes Datum i. S. d. Art. 2 DS-GVO vor.^[32]

Somit ist davon auszugehen, dass eine Pseudonymisierung im Zusammenhang mit dem Wallet grundsätzlich keine Auswirkung auf die Eigenschaft des Private Key als personenbezogenes Datum hat.

b) Private Key als Pseudonym

Einer differenzierten Betrachtung bedarf es allerdings, wenn der Private Key selbst als eine Art Pseudonym fungieren soll. Dies liegt nahe, da der Private Key im Zuge des Übertragungsvorgangs ähnlich wie ein Pseudonym ebenfalls der Authentifizierung des Walletinhabers dient, ohne die Identität der dahinterstehenden Person offenzulegen. Da der Public Key in funktioneller Hinsicht grundsätzlich als Pseudonym angesehen wird^[33] könnte dies konsequenterweise auf den Private Key als dessen „Gegenstück“ zu übertragen sein. In diesem Zusammenhang stellt sich allerdings auch die Frage, ob und inwieweit das spezielle kryptografische Verfahren bei der Erzeugung des Private Key zu berücksichtigen ist. Fraglich ist insbesondere, wie diese Art der „Vergabe“ von Pseudonymen mit den herkömmlichen Methoden der Vergabe bzw. mit den in der Literatur herausgearbeiteten Fallgruppen vergleichbar ist.

In der Literatur wird zwischen drei Arten von Pseudonymen unterschieden,^[34] wobei diese Unterscheidung grundliegende Auswirkungen auf die Identifizierbarkeit bzw. Bestimmbarkeit der dahinterstehenden natürlichen Person hat. Vergibt der Betroffene das Pseudonym ausschließlich selbst und nutzt diesen nicht gleichzeitig mit seinen Identitätsdaten, kann der Personenbezug grundsätzlich nur von ihm selbst hergestellt werden. Dies ist bspw. bei frei gewählten Benutzer-ID der Fall, die vor der Inanspruchnahme eines Internetangebots angegeben werden müssen.^[35] Die Literatur verneint hier eine Identifizierbarkeit, was allerdings nur unter der Prämisse gelten kann, dass der Personenbezug auch unter Hinzuziehung weiterer dem Datenverarbeitenden grundsätzlich verfügbaren Informationen hergestellt werden kann.

Wird das Pseudonym hingegen von einem vertrauenswürdigen Dritten^[36] oder von der datenverarbeitenden Stelle selbst vergeben,^[37] ist der Personenbezug grundsätzlich zu bejahen, selbst, wenn die den Pseudonym vergebende Stelle allein über die Zuordnungsregel verfügt.^[38]

Sieht man in dem Private Key ein Pseudonym, ist es naheliegend, in dem kryptografischen Verfahren der Erzeugung des Schlüsselpaares eine Parallele zu der oben geschilderten Vergabe eines Pseudonyms zu erblicken. Allerdings hat die Schlüsselgenerierung mithilfe eines kryptografischen Verfahrens zur Folge, dass – anders als bei den in der Literatur aufgeführten Fallgruppen – keine festgelegte und irgendjemandem zugängliche Zuordnungsregel vorhanden ist. Es ist somit weder dem Datenverarbeiter noch Dritten möglich, aus dem Private Key – selbst mit Verbindung mit dem Public Key – Rückschlüsse auf den ursprünglichen Datensatz zu ziehen und die Pseudonymisierung aufzuheben. Dies mag zwar gegen die Vergleichbarkeit mit den bereits erörterten Fallgruppen sprechen, wirkt sich jedoch im Hinblick auf die Identifizierbarkeit im Ergebnis kaum aus. Bei der Erzeugung des kryptografischen Schlüsselpaares werden nämlich nicht die Identitätsdaten des Inhabers verschlüsselt, sondern wird ein hiervon unabhängiger Datensatz erzeugt. Demnach kann die Identifizierung des Inhabers ohnehin nur mithilfe von zusätzlichen Daten erfolgen, die im Zuge der Begründung des Vertragsverhältnisses erhoben werden. Somit ist stets entscheidend, wie dieser Prozess im Einzelfall ausgestaltet ist, insbesondere ob und welche personenbezogenen Daten erfasst werden bzw. welche technischen Sicherheitsvorkehrungen der Nutzer hiergegen trifft.

c) Verschlüsselung des Private Key

Die Verschlüsselung des Private Key selbst hingegen wirft kaum Fragen auf. Diese bei zahlreichen Anbietern gängige Sicherheitsvorkehrung ändert grundsätzlich nichts an der Eigenschaft des Private Key als personenbezogenes Datum. Der wesentliche Unterschied zu dem unter Punkt 2b) erörterten Aspekt besteht darin, dass hierbei eine Zuordnungsregel zur Identifizierung des Betroffenen ohne weiteres vorliegen dürfte.

Die Verschlüsselung bewirkt nämlich lediglich, dass die Daten nur mithilfe eines Schlüssels (Passwort) wieder lesbar gemacht werden können. Ob die Entschlüsselung durch den berechtigten Passwortinhaber oder durch einen unberechtigten Dritten erfolgt, spielt indes keine Rolle. Da der Personenbezug der Daten nicht aufgehoben wird, hat die Verschlüsselung allenfalls die Pseudonymisierung der Daten zur Folge.^[39]

3. Im Allgemeinen / Identifizierbarkeit einer natürlichen Person

Somit kommt es entscheidend darauf an, ob der Private Key unter Berücksichtigung seiner funktionell-technischen Merkmale einer natürlichen Person unmittelbar oder mittelbar zugeordnet werden kann. Als solche Person kommt in der Regel der Inhaber des Wallets in Betracht bzw. derjenige, der das Wallet für sich oder für einen anderen einrichtet.

Nach der Legaldefinition der Art. 4 Nr. 1 DS-GVO sind personenbezogene Daten alle Informationen, die sich auf eine identifizierte oder identifizierbare Person beziehen, vgl. auch Satz 1 Erwägungsgrund 26. Als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.^[40]

Zur unmittelbaren Identifizierung des Betroffenen ist grundsätzlich dessen Name erforderlich.^[41] Da sich der Klarnamen des Nutzers weder dem Public noch dem Private Key entnehmen lässt, muss dieser entweder bei der Begründung des Vertragsverhältnisses – insbesondere im Rahmen der Durchführung von KYC-Maßnahmen – ausdrücklich abgefragt worden sein oder muss sich anderweitig aus den Registrierungsdaten des Nutzers, bspw. aus seiner E-Mail-Adresse, eindeutig und ohne Zweifel ergeben.

a) Mittelbare Identifizierbarkeit/Berücksichtigung zusätzlicher Informationen

Die fehlende Erfassung des Klarnamens des Nutzers ist jedoch unschädlich, da laut Erwägungsgrund 26 zur Herstellung des Personenbezugs auch die Möglichkeit der Identifizierung des Betroffenen mithilfe zusätzlicher Daten ausreichend ist, s. auch mittelbare Identifizierbarkeit.

Bei der Identifizierung sind alle Daten zu berücksichtigen, die ein Wiedererkennen ermöglichen, selbst wenn diese auf Anhieb keinen Schluss auf eine bestimmte Person erlauben.^[42] Es ist ausreichend, wenn die Information in Verbindung mit anderen Informationen eine Unterscheidung bzw. Zuordnung ermöglicht.^[43] Maßgebend sind stets die zum Zeitpunkt der Verarbeitung verfügbaren Technologien und technologischen Entwicklungen.^[44] Da die aktuellen technischen Möglichkeiten eine beinahe unbegrenzte Substrahierung bzw. Verknüpfung von Daten ermöglichen, dürfte letztendlich kein Datum per se belanglos sein^[45] Dies gilt insbesondere im Hinblick auf den Umstand, dass als zusätzliche Informationen auch Standortdaten sowie Online-Kennungen,^[46] somit auch statische und dynamische IP-Adressen in Betracht kommen.^[47] Im Hinblick auf den Private Key ist darüber hinaus zu berücksichtigen, dass durch Analyse der auf der Blockchain verzeichneten und öffentlich einsehbaren Transaktionen mittels Netzwerkanalysetechniken die Adressen (d.h. die Public Keys) zumindest einer Nutzergruppe, wenn nicht dem einzelnen Nutzer, zugeordnet werden können.^[48] Dies liegt den Schluss nahe, dass auch die Zuordnung der dazugehörigen Private Keys technisch jedenfalls nicht ausgeschlossen ist. Allerdings zeichnet sich bei neueren Blockchain-Netzwerken eine Tendenz zu vollständiger Anonymisierung ab. So verwenden Blockchains wie Monero oder Zcash alternative kryptografische Verfahren wie Ring-Signaturen oder Zero Knowledge Proof-Verfahren, bei denen die Identität einer Adresse vollständig anonymisiert ist.^[49] Ob in solchen Netzwerken die Identifizierung der Walletinhaber alleine mithilfe sonstiger Daten möglich ist, ist zweifelhaft.

b) Zusatzwissen – Kreis der Informationsträger

Fraglich ist darüber hinaus, wer als Träger dieser zusätzlichen Informationen in Betracht kommt, mit anderen Worten, wessen Zusatzwissen bei der Identifizierung berücksichtigt werden muss. Unstreitig zu berücksichtigen ist Zusatzwissen, das jedermann ohne weiteres erreichbar ist. Hierzu gehören frei zugängliche Angaben, auch wenn der Betroffene diese – auch wenn in einem anderen Zusammenhang – selbst, bspw. online, mitteilt. Zu einer Bestimmbarkeit genügt, dass die betreffende Information zugänglich und erreichbar ist, auch wenn hierfür ein gewisser Aufwand betrieben werden muss.^[50] In Betracht kommen unter anderem Daten aus öffentlichen zugänglichen Profilen oder Einträgen (Telefonbuch?) der Betroffenen, die im Internet mithilfe von Suchmaschinen und ggf. durch weitere Recherche auffindbar sind.

Anders stellt es sich hingegen im Hinblick auf Zusatzwissen dar, das nicht jedermann ohne weiteres erreichbar ist. Hierbei ist zunächst zu klären, ob auf die Perspektive des Datenverarbeiters abzustellen ist (sog. relativer Ansatz) oder ob es ausreichend ist, dass die Informationen abstrakt irgendjemandem zugänglich sind (sog. objektiver Ansatz). Nach dem objektiven Ansatz soll bereits die theoretische Möglichkeit der Bestimmbarkeit einer Person genügen, auch wenn diese Person nur durch zusätzliche Informationen eines Dritten bestimmt werden kann und dieser das notwendige Zusatzwissen nicht an die verarbeitende Stelle weitergibt.^[51] Auf die konkreten Möglichkeiten der datenverarbeitenden Stelle soll es nicht ankommen.^[52] Nach dem relativen Ansatz sind hingegen allein die konkreten Möglichkeiten der datenverarbeitenden Stelle, d.h. deren Kenntnisse und Mittel, maßgebend.^[53]

Dem Verordnungstext lassen sich diesbezüglich zwar keine ausdrücklichen Anhaltspunkte entnehmen, allerdings legt Erwägungsgrund 26 eine eher objektive Auslegung nahe. Hiernach sollen alle Mittel berücksichtigt werden, die von einem Verantwortlichen oder von einer anderen Person nach allgemeinem Ermessen wahrscheinlich genutzt werden, um die natürliche Person direkt oder indirekt zu identifizieren. Bei der Feststellung, ob Mittel nach allgemeinem Ermessen wahrscheinlich zur Identifizierung der natürlichen Person genutzt werden, sollen alle objektiven Faktoren, wie die Kosten der Identifizierung und der dafür erforderliche Zeitaufwand, herangezogen werden. [Hervorhebung durch die Autorin].

Stimmen in der Literatur wollen auch durch Hacking erlangte Informationen berücksichtigt wissen.^[54] Berücksichtigt man auch die Kenntniserlangung von völlig unbefugten Personen, wäre nach dieser Ansicht der Personenkreis, dessen Zusatzwissen von Bedeutung sein könnte, faktisch unbegrenzt. Aber selbst bei einer einschränkenden Handhabung des objektiven Ansatzes ist zu berücksichtigen, dass aufgrund der gegenwärtigen technischen Möglichkeiten beinahe jede mit technischen Mitteln beschaffbare Information zumindest abstrakt für irgendjemanden zugänglich ist bzw. zugänglich gemacht werden kann. Die konsequente Anwendung des objektiven Ansatzes birgt somit die Gefahr, dass beinahe jedes Datum, das im Zusammenhang mit der Nutzung des Internets erhoben bzw. zugänglich gemacht wird, zugleich als personenbezogenes Datum anzusehen wäre.

Für eine solche uferlose Ausweitung des Begriffs der personenbezogenen Daten bieten allerdings Wortlaut und Erwägungsgründe der Verordnung keine Handhabe. Auch die Rechtsprechung des EuGH lässt eine relative Tendenz erkennen.^[55]

Der EuGH nahm in der Breyer-Entscheidung^[56] im Kontext der Personenbezogenheit von IP-Adressen unter anderem zu der Bedeutung und Tragweite des Merkmals Identifizierbarkeit Stellung. Das Gericht führt aus, es genüge zur Identifizierbarkeit, dass der Internetzugangsanbieter über das betreffende Zusatzwissen verfügt, allerdings nur, soweit er über die rechtlichen Mittel verfügt, die ihm den Zugriff auf das Zusatzwissen Dritter erlauben.^[57] Dies lässt den Schluss zu, dass jedenfalls dann, wenn dem Zugriff auf dieses Zusatzwissen kein explizites gesetzliches Verbot entgegensteht, von der grundsätzlichen Bestimmbarkeit auszugehen ist. Allerdings erscheint dies in der Praxis problematisch, zumal für eine tatsächliche Zugriffsmöglichkeit entweder ein Anspruch des Verarbeiters gegen den Dritten oder dessen Bereitschaft zur Herausgabe erforderlich sein dürfte. Andernfalls wäre die Bestimmbarkeit – jedenfalls aus der maßgeblichen Sicht des Verarbeiters – als lediglich abstrakt anzusehen. Eine rein fiktive Möglichkeit der Bestimmbarkeit reicht jedoch nicht aus.^[58] Wie dies in der Praxis zu handhaben ist, wird verbindlich durch den EuGH zu entscheiden sein. Allerdings kann anhand der Rechtsprechung des EuGH – selbst bei Zugrundelegung eines grundsätzlich subjektiven Ansatzes – mit guten Gründen von einer weiten Auslegung des Begriffs der Bestimmbarkeit ausgegangen werden.

Hieran ändert grundsätzlich auch der Umstand nichts, dass bei der Bestimmbarkeit auch die Kosten sowie der Aufwand der Identifizierung zu berücksichtigen sind.^[59] Die Kosten der Identifizierung können zwar eine Rolle spielen, sind jedoch bei der Beurteilung, ob diese überhaupt möglich ist, nicht ausschlaggebend. Auch muss der Aufwand zur Identifizierung lediglich „im Verhältnis“ zum Informationswert stehen. Ein Personenbezug soll daher erst dann zu verneinen sein, wenn der Aufwand den Informationswert so wesentlich übertrifft, dass vernünftigerweise davon auszugehen ist, dass niemand den Versuch der Bestimmung der Person unter Verwendung der vorhandenen Daten unternehmen wird.^[60] Dementsprechend wird für die weitere Untersuchung auf die Perspektive des Verarbeiters,^[61] vorliegend die des Anbieters, abgestellt. Entscheidend ist demnach, ob die im Zuge der Begründung des Vertragsverhältnisses erhobenen Daten ggf. in Verbindung mit dem Private Key selbst geeignet sind, einen Personenbezug herzustellen.

Die Frage dürfte bei Verwahrungsmodellen, bei denen die Begründung des Vertragsverhältnisses schwerpunktmäßig ohne Nutzung des Internets und unter direkter Identifizierung des Nutzers erfolgt, kaum Probleme aufwerfen. Dies gilt jedenfalls, wenn und soweit die Daten direkt vom Anbieter oder durch einen Dritten auf seine Veranlassung erhoben werden und an sich ausreichend sind, einen Personenbezug herzustellen. In der Regel dürfte hierbei bereits eine Bestimmtheit der Person des Nutzers gegeben sein und es deshalb auf die Frage der Bestimmbarkeit nicht mehr ankommen.

Durchaus relevant wird die Frage jedoch in Konstellationen, in denen die Begründung des Vertragsverhältnisses vollständig im Internet erfolgt und bei denen – wie im Regelfall – keine Klardaten des Nutzers erfasst werden. Hierbei kommt es zum einen darauf an, wie der Registrierungsprozess im konkreten Einzelfall ausgestaltet ist, insbesondere welche zusätzlichen Daten (personenbezogenen aber auch Sachdaten) erhoben werden und inwieweit der Verarbeiter auf diese Daten zugreifen kann. Zu berücksichtigen ist indes auch, ob und welche technischen Vorkehrungen der Nutzer seinerseits gegen die Erfassung seiner Daten trifft. Zum anderen ist entscheidend, ob diese zusätzlichen Daten – ggf. in Verbindung mit dem Private Key selbst – geeignet sind, Rückschlüsse auf die Person des Betroffenen zuzulassen. Wird bspw. während des Registrierungsprozesses die IP-Adresse des Betroffenen ungekürzt erfasst, dürfte von einer grundsätzlichen Identifizierbarkeit auszugehen sein.^[62] Dies gilt allerdings nicht uneingeschränkt bei IP-Adressen, die innerhalb eines lokalen Netzwerks einer Organisation vergeben werden,^[63] da eine Zuordnung zu dem Arbeitsplatz eines konkreten Mitarbeiters oftmals nur mit Hilfe der Protokollierung durch den NAT-Router (Network Address Translation) möglich ist.^[64] Die Identifizierbarkeit dürfte allerdings gegeben sein, wenn der Betroffene zusätzlich eine E-Mail-Adresse verwendet, die Rückschlüsse auf seine Identität zulässt, bspw. weil diese auch seinen Klarnamen oder Firmennamen enthält.

Wird die IP-Adresse hingegen lediglich gekürzt erfasst, dürfte die Identifizierbarkeit – jedenfalls ohne Hinzuziehung weiterer Daten – zu verneinen sein. Dies gilt allerdings nur, wenn mit technischen Mitteln sichergestellt ist, dass die IP-Adresse entweder bereits gekürzt erfasst wird oder jedenfalls zeitgleich mit der Erfassung irreversibel gekürzt wird.^[65]

c) Zusatzwissen im Kontext des konkreten Vertragsverhältnisses

Im Hinblick auf den Private Key ist demnach entscheidend, ob während der Begründung des Vertragsverhältnisses Sachdaten oder personenbezogene Daten erfasst wurden, die für sich alleine oder in Verbindung mit dem Private Key Rückschlüsse auf die Person des Betroffenen ermöglichen können und ob der Verwahrer auf diese Daten – auch während der Durchführung des Vertragsverhältnisses – mit vertretbarem Aufwand zugreifen kann. Hierbei ist zunächst danach zu differenzieren, ob zur Durchführung des Vertragsverhältnisses die Mitwirkung des Vertragspartners oder eines Dritten erforderlich ist. Ein weiteres Kriterium ist darüber hinaus, ob die Begründung des Vertragsverhältnisses – jedenfalls schwerpunktmäßig – mithilfe des Internets erfolgt.

Erfordert die Durchführung des Vertragsverhältnisses, insbesondere die Abwicklung der einzelnen Transaktionen die Mitwirkung des Verwahrers oder eines Dritten, ist davon auszugehen, dass die Identifizierbarkeit des Betroffenen im Laufe der gesamten Vertragsdurchführung gewährleistet sein muss. Als Beispiel lassen sich Konstellationen anführen, in denen zur Durchführung einer einzelnen Transaktion die Authentifizierung des Verfügenden vorgesehen ist. Dies kann entweder durch den Anbieter selbst oder durch einen Dritten erfolgen. Die Einschaltung eines Dritten – sog. Handling-Partners – soll als zusätzliche Sicherheitsmaßnahme verhindern, dass der Anbieter die volle Autorität über den Auszahlungsprozess hat.^[66] Die Authentifizierung kann in verschiedener Weise, unter anderem im Rahmen einer Videokonferenz erfolgen, wobei noch zusätzliche Identifizierungsmaßnahmen wie Vorzeigen eines Ausweisdokuments verlangt werden können.^[67] Auch wenn es hierbei nicht entscheidend auf die Zuordnung als cold oder hot wallet ankommt, sind solche Konstellationen vermehrt bei bestimmten custodian cold wallet-Angeboten anzutreffen. Dies folgt bereits aus dem Umstand, dass bei einer physischen Verwahrung von fremden Gegenständen der Zugriff dem Berechtigten in der Regel nicht auf andere Weise gewährleistet werden kann. Zwar werden am Markt auch cold Wallet-Lösungen angeboten, bei denen zwar die Begründung des Vertragsverhältnisses – insbesondere die Herstellung des Speichermediums – der Mitwirkung des Anbieters bedarf, nicht jedoch dessen Durchführung.^[68] Da es sich hierbei in der Regel um non-custody-Lösungen handelt, in denen der Inhaber das Speichermedium samt Private Key selbst aufbewahrt, sind diese nicht Gegenstand vorliegender Untersuchung.

Erfordert die Durchführung des Vertragsverhältnisses keine Mitwirkung des Anbieters, kommt es entscheidend darauf an, ob und welche Daten des Betroffenen im Zuge der Begründung des Vertragsverhältnisses erhoben werden. Hierbei ist davon auszugehen, dass derartige Verwahrungsverhältnisse weit überwiegend unter Nutzung des Internets zustande kommen. Das Gegenteil – etwa vergleichbar mit der Gepäckaufbewahrung an Bahnhöfen – ist mangels Datenverarbeitung i. S. d. DS-GVO für den Gegenstand vorliegender Arbeit nicht von Relevanz und ist auch im Übrigen kaum praktikabel.

Erfolgt die Begründung des Vertragsverhältnisses im Internet, dürfte zur Identifizierung des Nutzers grundsätzlich die Erfassung der IP-Adresse und/oder der MAC-Adresse des verwendeten Geräts bzw. Netzwerkadapters^[69] ausreichend sein, eine gezielte Abfrage von Klardaten wie Name – geschweige denn die ordnungsgemäße Durchführung von KYCMaßnahmen – ist indes nicht erforderlich. Dies hat zur Folge, dass – soweit der Nutzer selbst keine Maßnahmen zur Verschleierung seiner Identität ergreift – jedenfalls von der grundsätzlichen technischen Identifizierbarkeit auszugehen sein dürfte.

III. Fazit

Wie oben ausgeführt, ist die unmittelbare oder mittelbare Zuordnung des Private Key zu einer natürlichen Person grundsätzlich auch bei einer Fremdverwahrung möglich. Hierbei kommt es allerdings stets auf den jeweiligen Einzelfall an. Diese Einzelfallbetrachtung hat auf Seiten des Anbieters eine gewisse Rechtsunsicherheit zur Folge, zumal ihm möglicherweise nicht ohne weiteres erkennbar ist, ob er die Pflichten des Verantwortlichen aus Art. 13, 14 sowie Art. 24 DS-GVO ff. erfüllen muss. Da diesbezügliche Rechtsirrtümer nicht nur zivilrechtliche Ansprüche des Betroffenen gem. Art 82 DS-GVO, sondern auch behördliche Sanktionen – unter anderem Bußgelder in empfindlicher Höhe – nach sich ziehen können, stellt dies für den Anbieter ein gewisses Risiko dar. Auf der anderen Seite hat er es selbst in der Hand, durch die technisch-organisatorische Ausgestaltung seines Angebots die Anwendbarkeit der DS-GVO faktisch auszuschließen. Da die Erfüllung der Pflichten des Verantwortlichen in der Regel mit nicht unerheblichem technischen, personellen und finanziellen Aufwand verbunden ist, hat die gebotene Einzelfallbetrachtung für den Anbieter somit durchaus auch Vorteile.

_{[1] 1 Schlatt/Schweizer/Urbach/Fridgen, Blockchain: Grundlagen, Anwendungen und Potenziale, 2016, Projektgruppe Wirtschaftsinformatik des Fraunhofer-Instituts für Angewandte Informationstechnik FIT, S. 7.}

_{[2] Drescher, Blockchain-Grundlagen, 2017, S. 30, 34, 211.}

_{[3] Sixt, Bitcoins und andere dezentrale Transaktionssysteme, 2017 S. 39.}

_{[4] Blockchain und Datenschutz, https://www.bitkom.org/sites/default/files/file/import/180502-Faktenpapier-Blockchain-und-Datenschutz.pdf, Seite 10}

_{[5] Blockchain und Datenschutz, S. 10; Drescher, S. 226; Braegelman/Kaulartz, Rechtshandbuch Smart Contracts, 2019, Kap. 2 Rn. 28, 29.}

_{[6] Blockchain und Datenschutz, S. 10, 11; Braegelman/Kaulartz, Kap. 2 Rn. 30.}

_{[7] Blockchain und Datenschutz, S. 16, 21; Martini/Weinzierl, NVwZ 2017, 1253.}

_{[8] Drescher, S. 116; Sixt, S.37.}

_{[9] Sixt, S. 37.}

_{[10] Braegelman/Kaulartz, Kap. 2 Rn. 33.}

_{[11] Braegelman/Kaulartz, Kap. 2 Rn. 33.}

_{[12] Sixt, S. 37; Drescher, S. 116, 118.}

_{[13] Annuzzi, Verwahrungslösungen für Kryptowährungen, https://www.resource-capital.ch/fileadmin/reports/2019/Crypto-Research-Report-Januar_2019_DE-1.pdf-1.pdf, S. 25; Drescher, S. 116; Braegelman/Kaulartz, Kap. 2 Rn. 33.}

_{[14] National Risk Assessment (NRA): Risiko der Geldwäscherei und Terrorismusfinanzierung durch Krypto-Assets und Crowdfunding, https://www.newsd.admin.ch/newsd/message/attachments/56167.pdf, S. 17.}

_{[15] Sixt, S. 36; Annuzzi, S. 25.}

_{[16] National Risk Assessment (NRA): Risiko der Geldwäscherei und Terrorismusfinanzierung durch Krypto-Assets und Crowdfunding, S. 17}

_{[17] Aydar et alii: Private Key Encryption and Recovery in Blockckchain, https://arxiv.org/pdf/1907.04156.pdf, S. 2; National Risk Assessment (NRA): Risiko der Geldwäscherei und Terrorismusfinanzierung durch Krypto-Assets und Crowdfunding, S. 17.}

_{[18] Annuzzi, S. 29.}

_{[19] Vgl. bspw. das Wallet von Daenerys & Co, Annuzzi, S. 29, 30.}

_{[20] Vgl. bspw. Crypto Storage AG sowie Swiss Crypto Vault AG, Annuzzi, S. 27 bzw. 33.}

_{[21] Annuzzi, S. 29.}

_{[22] 2 Pal at alii: Key management for blockchain technology, https://e-tarjome.com/storage/panel/fileuploads/2019-08-31/1567231084_E13261-e-tarjome.pdf, S. 3.}

_{[23] Annuzzi, S. 32.}

_{[24] Eine solche Lösung bietet bspw. die Crypto Storage AG an. „Die ATs, die mit dem HSMs und mit den Backend-Servern kryptografisch verschlüsselt kommunizieren, werden beim Kunden installiert und ermöglichen diesem, (Auszahlungs)Transaktionen aus dem cold storage zu veranlassen. Diese Handhabung ist mit denen eines hot wallet vergleichbar, während der Kunde auf der anderen Seite auch die Vorteile einer sicheren cold-wallet-Vorrichtung genießt“, vgl. Annuzzi, S. 27, 28.}

_{[25] Simitis, 8. Aufl., 2014, Art. 4 Rn. 28; BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 28.}

_{[26] National Risk Assessment (NRA): Risiko der Geldwäscherei und Terrorismusfinanzierung durch Krypto-Assets und Crowdfunding, S. 17.}

_{[27] Dass es sich beim Wallet nicht um eine Sache i. S. d. § 90 BGB, sondern nur um eine „virtuelle“ Sache handelt, dürfte unter Berücksichtigung der technischen Entwicklung unschädlich sein}

_{[28] BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 25.}

_{[29] Simitis/Dammann, Rn. 60; BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 22-27.}

_{[30] Erwägungsgrund 30; EuGH ZD 2017, 24 Rn. 37 ff.; BGH WM 2017, 1320 Rn. 14 ff.; Paal/Pauly/Ernst, 2. Aufl. 2018, DS-GVO Art. 4 Rn. 18.}

_{[31] BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 68.}

_{[32] Paal/Pauly/Ernst, 2. Aufl. 2018, DS-GVO Art. 4 Rn. 51.}

_{[33] Blockchain und Datenschutz, https://www.bitkom.org/sites/default/files/file/import/180502-Faktenpapier-Blockchain-und-Datenschutz.pdf, Seite 24.}

_{[34] Roßnagel/Scholz, MMR 2000, 721 (724 ff.); s. auch Simitis/Scholz, BDSG § 3 Rn. 220 ff.; BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 74.}

_{[35] BeckOK DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 74; Simitis/Scholz, BDSG § 3 Rn. 220a.}

_{[36] BeckOK, DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 75.}

_{[37] BeckOK, DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 76.}

_{[38] BeckOK, DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 76.}

_{[39] BeckOK, DatenschutzR/Schild, 30. Ed. 01.11.2019, DS-GVO Art. 4 Rn. 80; ebenso Gola/Schomerus BDSG § 3 Rn. 45.}

_{[40] EuGH, NJW 2015, 463 Rn. 22; BeckOK, DS-GVO Art. 4 Rn. 14; Paal/ Pauly/Ernst, 2. Aufl. 2018, DS-GVO Art. 4 Rn. 3.}

_{[41] BeckOK, DS-GVO Art. 4 Rn. 16.}

_{[42] BeckOK, DS-GVO Art. 4 Rn. 16.}

_{[43] BeckOK, DS-GVO Art. 4 Rn. 17}

_{[44] Erwägungsgrund 26; Pauly Art. 4 Rn. 13; BeckOK, DS-GVO Art. 4 Rn. 15}

_{[45] So bereits BVerfGE 65, 1 Rn. 176; Paal/Pauly/Ernst, 2. Aufl. 2018, DSGVO Art. 4 Rn. 13; Schneider/Forgo/Helfrich, in: Betrieblicher Datenschutz, Kap. 1. Teil I. Rn. 65.}

_{[46] BeckOK, DS-GVO Art. 4 Rn. 17.}

_{[47] LG Berlin, MMR 2007, 799; AG Offenburg, Beschl. v. 20.07.2007 – 4 Gs 442/07; AG Berlin Mitte, Urt. v. 27.03.2007 – 5 C 314/06, EuGH BeckRS 2012, 80744 Rn. 51; BeckRS 2011, 81685 Rn. 51 „wobei es sich bei diesen (IP-) Adressen um geschützte personenbezogene Daten handelt, da sie die genaue Identifizierung der Nutzer ermöglichen.“; a.A., OLG Hmb BeckRS 2010, 28964; AG München, Urt. v. 30.09.2008 – 133 C 5677/08, BeckRS 2008, 23037; s. auch Vorlage-Beschl., BGH, Beschl. v. 28.10.2014 – VI ZR 135/13, BeckRS 2014, 20158, Beck OK Art. 4 Rn. 21.}

_{[48] Sixt, S. 33; Reid/Harrigan: An Analysis of Anonymity in the Bitcoin System, https://users.encs.concordia.ca/~clark/biblio/bitcoin/Reid%202011.pdf S. 42. Eine entsprechend Zuordnung ist wohl auch schon Ermittlungsbehörden gelungen, vgl. Braegelman/Kaulartz, Kap.2 Rn. 34.}

_{[49] Braegelman/Kaulartz, Kap. 2 Rn. 34.}

_{[50] Simitis/Dammann, Rn. 25.}

_{[51] Heidrich, in: Betrieblicher Datenschutz, 3. Aufl. 2019, Kap. 4 Teil V. Rn. 9; Bieresborn, in: Betrieblicher Datenschutz, Kap. 4 Teil V. Rn. 33; Breyer, NJW Aktuell 11/2010, 18; VG Wiesbaden, Beschl. v. 27.02.2009 – 6 K 1045/08.WI, MMR 2009, 428; KG Berlin, Beschl. v. 29.04.2011 – 5 W 88/11; Breyer, NJW Aktuell, 2010, Nr. 11, 18; LG Düsseldorf, Urt. v. 09.03.2016 – 12 O 151/15, MMR 2016, 328.}

_{[52] Heidrich, in: Betrieblicher Datenschutz, Kap. 4 Teil V. Rn. 9; KG Berlin, Beschl. v. 29.04.2011 – 5 W 88/11.}

_{[53] Heidrich, in: Betrieblicher Datenschutz, Kap. 4 Teil V. Rn. 11; Bieresborn, in: Betrieblicher Datenschutz, Kap. 4 Teil V. Rn. 33; Simitis/Dammann, BSDG, § 3 Rn. 33; LG Frankenthal, Beschl. v. 21.05.2008 – 6 O 156/08, MMR 2008, 687; Nink/Pohle, MMR 2015, 563; Gola/Schomerus, BSDG, § 3 Rn. 10, 44; OLG Hamburg, Beschl. v. 03.11.2020 – 5 W 126/10.}

_{[54] Bieresborn, in: Betrieblicher Datenschutz, Kap. 4 Teil V. Rn. 33; Breyer, NJW Aktuell 11/2010, 18; VG Wiesbaden, Beschl. v. 27.02.2009 – 6 K 1045/08.WI, MMR 2009, 428.}

_{[55] Spindler/Schuster/Spindler/Dalby, 4. Aufl. 2019, DS-GVO Art. 4 Rn. 9.}

_{[56] Breyer, vs. Bundesrepublik Deutschland, Az. C 582/14.}

_{[57] EuGH, BeckRS 2016, 82520 Rn. 49; dem nun folgend, BGH, BeckRS 2017, 114664; BeckOK, Art. 4 Rn. 20.}

_{[58] Simitis/Dammann, Rn. 25.}

_{[59] Vgl. Erwg. 26}

_{[60] Simitis/Dammann, Rn. 25; BeckOK, Art.4 Rn. 20.}

_{[61] Spindler/Schuster/Spindler/Dalby, 4. Aufl. 2019, DS-GVO Art. 4 Rn. 9.}

_{[62] Heidrich/Forgo/Moos, in: Betrieblicher Datenschutz, 1. Kap. Teil VIII Rn. 21; Moos/Rothkegel, MMR 2016, 842(847).}

_{[63] Heidrich/Forgo/Moos, in: Betrieblicher Datenschutz, 1. Kap. Teil VIII Rn. 17; Heidrich/Wegener, MMR 2015, 487.}

_{[64] Heidrich/Forgo/Moos, in: Betrieblicher Datenschutz, 1. Kap./Teil VIII Rn. 18. Zwar ist es auch bei lokalen Netzwerken möglich, allen Rechnern eine individuelle IP-Adresse zuzuordnen, über die auf das Internet zugegriffen werden kann. Allerdings werden in internen Netzwerken häufig private IP-Adressen vergeben, mit denen die Rechner nur innerhalb des eigenen Netzwerks kommunizieren können. Zur Kommunikation mit öffentlichen Netzwerken ist dann die Nutzung eines NAT-Routers erforderlich. Da dieser in allen ausgehenden Datenpaketen die IP-Adressen der lokalen Stationen durch seine eigene, öffentliche IPAdresse ersetzt, können sich hinter einer ausgehenden IP-Adresse zahlreiche interne Rechner verbergen.}

_{[65] Vgl. https://www.david-scherfgen.de/dsgvo-gdpr-speichern-von-ip-adressendurch-php-anwendungen-und-in-server-logdateien-verhindern/.}

_{[66] Crypto Concepts: Verwahrlösungen für Kryptowährungen, S. 34, am Beispiel der Swiss Crypto Vault AG.}

_{[67] Vgl. https://www.daenerys.co/physical-cryptocurrency-storage-whitepaper, S. 30-31.}

_{[68] Vgl. sog. Card-Wallets}

_{[69] Lenhard, Datensicherheit 2017, S. 7, 85; Die MAC-Adresse ist im Übrigen nach h. M. wie eine statische IP-Adresse zu behandeln, vgl. auch Heidrich/Forgo/Moos, in: Betrieblicher Datenschutz, 1.Kap./Teil VIII Rn. 20.}