Source: https://rewis.io/blog/hashing-encryption-und-anonymisierung/
Timestamp: 2020-04-03 10:48:51+00:00

Document:
Hashing, Encryption und Anonymisierung
Hashing, Encryption und Anonymisierung werden häufig durcheinander geworfen. Welche Rolle kommt welchem Begriff zu und ist Hashing eine Form der Anonymisierung?
Welche Stellung kommt Hash-Funktionen in der datenschutzkonformen Verarbeitung personenbezogener Daten zu?
Sind Hashfunktionen taugliche Brücken zwischen dem gesetzlich gestützten Bedürfnis nach Privatsphäre und dem berechtigten Interesse der Verwender an komplexer Datenauswertung?
Die Digitalisierung nahezu aller Bereiche der modernen Lebensführung stellt Recht und Gesellschaft fortwährend vor große Herausforderungen. Insbesondere müssen immer neue Möglichkeiten der Datenerfassung- und Auswertung mit alten, teils neu interpretierten Bedürfnissen der Rechtssubjekte auf einen höchstpersönlichen Lebensraum[1], einer eigenverantwortlichen Lebensführung, sowie der selbstbestimmten Persönlichkeitsbildung- und Darstellung in Abwägung gebracht werden.[2]
Hierzu hat jüngst die Europäische Datenschutz Grundverordnung (DSGVO) einen ersten, bedeutenden Schritt unternommen.
Während grundsätzliche Prinzipien größtenteils ohne weiteres einleuchtend sind, stellt sich in der Praxis bezüglich der Umsetzung durch bestimmte Technologien das Problem erheblicher Rechtsunsicherheit.
Dieser Aufsatz setzt sich mit der Frage auseinander, inwiefern durch sog. Hashfunktionen eine situativ reversible, datenschutzkonforme Anonymisierung von personenbezogenen Daten für Scoring-Systeme möglich sein kann. Dabei soll insbesondere die Frage geklärt werden, ob Hashwerte von personenbezogenen Daten ebenfalls unter den Anwendungsbereich der DSGVO fallen und wie weit sie deren Zielen zu dienen vermögen.
Bevor eine fundierte rechtliche Auseinandersetzung mit der Thematik erfolgen kann, ist es freilich erforderlich, sich über die entsprechenden Begrifflichkeiten im Klaren zu sein. Bedauerlicherweise werden in technischen Abwandlungen immer wieder juristische und in juristischen Abwandlungen immer wieder technische Begriffe grob miteinander verwechselt. Das ist angesichts zweier hochkomplexer Materien verständlich, steht einer Lösungsfindung jedoch im Wege. Im Folgenden soll daher der Versuch einer verständlichen Erklärung der verwendeten Begriffe erfolgen.
Technische Begrifflichkeiten
Bei den technischen Begrifflichkeiten sollte zunächst der Begriff des „Hashings“ klar sein. Er wird häufig mit „Encryption“ also Verschlüsselung gleichgesetzt, was so allerdings keinesfalls stimmt.
Durch eine Hash-Funktion wird aus einem vorgegebenen Wert mit variabler Länge eine Zeichenkette gebildet, die eine feste Länge hat. Bewusst spreche ich nicht von „umgewandelt“, da dies den Schluss nahelegt, dass dieser Vorgang rückgängig zu machen wäre, was nicht (mehr) der Fall ist.
Hierfür sorgen sichere Hash-Funktionen wie SHA-3 (Secure Hash Algorithm 3).[3] Die Funktionsweise lässt sich schematisch wie folgend darstellen:[4]
Funktion Hashlib
text = 'Hallo Welt'
hash = sha3_512(text.encode('utf-8')).hexdigest()
'''output: 5aadcaf394961eecc2f4e65c2d82ff7cf0f6fa4574f351d0053574886ac77c961958cef64bc2bb483b4e7430964b55893a7c28a5c6efab7e24e2b7994bba5eb9'''
Der durch die Hash-Funktion erstellte Wert hat in diesem Fall eine Größe von 512 Bits, das entspricht 64 Bytes.[5] Stellen wir diesen Wert als hexadezimale[6] Zeichenkette dar erhalten wir stets einen Wert von 128 Zeichen. Der ursprüngliche Wert hatte lediglich 10 Byte.
Ersetzen wir nunmehr „Hallo Welt“ durch eine beliebige Zeichenkette mit der Länge von 500 Zeichen (entspricht 500 Byte) und führen mit diesem neuen Wert erneut die Hash-Funktion aus, erhalten wir dennoch einen Hash-Digest von 64 Byte und 128 Zeichen in hexadezimaler Schreibweise.
Dabei ergibt der gleiche Wert immer den gleichen Hash.
Genauer auf die dem zugrundeliegende Logik einzugehen, würde den Rahmen dieser Abhandlung sicherlich ebenso sprengen, wie das durchschnittliche Leserinteresse.[7] Es genügt jedoch vorerst die Erkenntnis, dass ein Hash-Digest keine inhaltliche Repräsentation seines ursprünglichen Wertes darstellt und aus diesem Grunde auch keine Rückentschlüsselung möglich ist. Man spricht daher auch von einer kryptographischen Einwegfunktion.
Ebenfalls kryptographisch sind Verschlüsselungsfunktionen. Diese sind jedoch in ihrer Funktion und Zielrichtung Wesensverschieden.
Hierbei wird mittels eines kryptographischen Algorithmus und einem Schlüssel aus einem Klartext-Wert ein verschlüsselter Wert gebildet. Dabei lässt sich der ursprüngliche Text mithilfe des Schlüssels und der entsprechenden kryptographischen Funktion wieder vollständig rekonstruieren.
Aus den verschiedenen Zielsetzungen ergeben sich denklogisch verschiedene Verwendungsmöglichkeiten.
Während Verschlüsselungen beispielsweise verwendet werden, um Nachrichten zu Ver- und Entschlüsseln, zum Beispiel als Ende-zu-Ende-Verschlüsselung in vielen Messengern, werden Hashfunktionen beispielsweise verwendet, um Passwörter in Datenbanken zu sichern.
Dabei werden Passwörter in der Datenbank nicht mehr wie früher im Klartext hinterlegt, sondern lediglich deren Hash-Digest.
Loggt sich der Nutzer ein, wird aus der von ihm getätigte Passworteingabe durch eine Hashfunktion ein Hash-Digest gebildet, der nunmehr ganz einfach mit der in der Datenbank hinterlegten Zeichenkette verglichen werden kann.
Erlangt nunmehr ein Angreifer Zugriff auf die Datenbank einer Webseite, erfährt er so aber nicht die Passwörter der Nutzer, sondern vielmehr nur deren Hash-Digest, der für ihr freilich wertlos ist.
Es ist technisch nicht möglich, aus einem Hash den ursprünglichen Wert wiederherzustellen. Dies ist, wie oben geschildert, darauf zurückzuführen, dass in dem Hash-Digest nicht die nötigen Informationen hierzu enthalten sind.
Wesentliches Merkmal eines Hashs ist es, dass ein Wert immer den gleichen Hash erhält. Genau hierinnen liegt daraus folgend auch die einzige Möglichkeit den Inhalt des Hashs zu erlangen: Der Angreifer müsste aus allen in Frage kommenden Werten einen Hash-Wert bilden und diesen mit dem vorhandenen Hash-Digest vergleichen.[8]
Um dies zu schaffen benötigt ein Angreifer nach dem momentanen Stand der Technik etwa 3,17 * 1064 Jahre. Es wäre beinahe verwegen hier noch von Millionen von Jahren zu sprechen.
Soweit keine kryptographische Schwäche an der Hash-Funktion zugrunde liegenden Algorithmus bekannt wird, ist ein Rückschluss auf den Inhalt folglich faktisch ausgeschlossen.
Bei einer solchen Dauer noch von millionen von Jarhen zu sprechen, wäre verwegen.
Juristische Begrifflichkeiten
Personenbezogene Daten sind nach Art. 4 Abs. 1 DSGVO solche Informationen, die sich auf identifizierte oder identifizierbare natürliche Personen beziehen. Eine Person gilt dabei bereits dann als identifizierbar, wenn sie mittels einer Kennung, einer Kennnummer oder anderen Merkmalen, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind, identifiziert werden kann.[9]
Der Begriff ist weit definiert und ist Ausdruck des weitreichenden Geltungsanspruchs des neuen Datenschutzrechts, dessen Anwendungsbereich nach Art. 3 I, II DSGVO über den Begriff des personenbezogenen Datums eröffnet wird.
Nicht minderweit gefasst ist der Begriff der „Verarbeitung“, der in Art. 4 IIDSGVO definiert wird als jeden Vorgang mit oder ohne Hilfe automatisierter Verfahren ausgeführt […] wie das Erheben, das Erfassen, die Organisation, […] die Speicherung, […] das Abfragen, die Verarbeitung […] von personenbezogenen Daten.
Während das alte nationale Datenschutzrecht in § 3 VI BDSG a.F. die Anonymisierung noch ausdrücklich definierte als das Verändern personenbezogener Arten derart, dass die Einzelangaben über persönliche oder sachliche Verhältnisse nicht mehr oder nur mit einem unverhältnismäßig großen Aufwand an Zeit, Kosten und Arbeitskraft einer bestimmten oder bestimmbaren natürlichen Person zugeordnet werden können, findet sich eine solche ausdrückliche Definition in den Begriffsbestimmungen des Art. 4 DSGVO nicht, auch wenn sie Erwähnung in den Erwägungsgründen zur DS-GVO findet.[10]
Dem folgt, dass das neue Datenschutzrecht anonymisierte Daten schlicht als Antipole zu den personenbezogenen Daten auffasst. Ein Datum wäre folglich dann anonym, wenn sich ein Personenbezug im Sinne des Art. 4 I DSGVO mit vertretbarem technischem und wirtschaftlichem Aufwand nicht mehr herstellen lässt.[11]
Sind Hash-Werte personenbezogen?
Nunmehr stellt sich die Frage, ob personenbezogene Daten, die durch eine Hash-Funktion zu einem Hash-Digest verarbeitet wurden, nach wie vor ein personenbezogenes Datum darstellen.
Der Grundfall
Es bietet sich an, diese Frage an einem Beispiel zu diskutieren. Als solches soll eine einfache Scoring-Funktion dienen, bei der dem Verwender einer bestimmten E-Mailadresse ein bestimmter Wert zugeordnet werden soll.
Gehen wir also davon aus, dass der Adresse [email protected] der Wert i zugeordnet wird, um seine Verlässlichkeit in Hinsicht auf ein bestimmtes Verhalten zu definieren. Ein solches Verfahren stellt nach DSGVO offensichtlich die Erhebung personenbezogener Daten zum Zwecke eines Profilings zu verwenden.[12]
Nach Anwendung einer Hash-Funktion
Anders könnte sich dies jedoch beurteilen, wenn statt einer E-Mailadresse lediglich ein Hash-Digest verarbeitet und gesichert wird.
Dem Hash-Digest kann die E-Mailadresse nicht mehr entnommen werden. Probleme ergeben sich jedoch anderweitig in mannigfaltiger Weise.
Führen wir nunmehr die Erkenntnisse über die Rekonstruktion von Hash-Digests und personenbezogene Daten zusammen, könnten wir uns zunächst fragen, ob der veranschlagte Aufwand für das schlichte Durchprobieren der Hash-Werte aller möglichen E-Mailadressen denjenigen Aufwand überschreitet, um nach DS-GVO Erwägung als nicht-personenbezogen, also anonym zu gelten. Hierbei sind insbesondere Faktoren, wie die Kosten der Identifizierung und der dafür erforderliche Zeitaufwand miteinzustellen.[13]
Wie bereits erkannt, führte das stupide probieren in keiner menschlich akzeptablen Zeitspanne zum Ziel.[14] Signifikant verkürzen könnte diesen Vorgang jedoch eine sog. Rainbow-Table. In einer solchen Tabelle werden für alle bekannten, möglichen oder wahrscheinlichen Zieldaten (E-Mailadressen) bereits die Hashwerte vorgespeichert, um dann einfach die Hashwerte miteinander vergleichen zu können.[15] Über ein solches Verfahren kann der Aufwand für die Rückwandlung des Digest in ein personenbezogenes Datum auf ein vertretbares Maß reduziert werden.
Der Weg über eine puristische Hash-Funktion wäre folglich nicht geeignet, um den impliziten Anforderungen an eine Anonymisierung zu genügen.
Der technischen Entwicklung ist dieser Umstand jedoch seit geraumer Zeit gewusst, weswegen Hashwerte mit einem dynamischen „Salt“ versehen werden. Dem Wert (hier E-Mailadresse) wird dann eine zufällige Zahlenfolge vorangestellt (a27szhw + [email protected]), was Rainbow-Tables ein effektives Hindernis in den Weg stellt.[16] Die vorberechneten Werte sind dann nämlich wertlos und ein Rückschluss auf die Person wieder nur mit einem nicht vernünftigen zeitlichen Aufwand möglich.
Dennoch taugen Hash-Funktionen nicht zur Anonymisierung im Sinne der DS-GVO. Zu unterscheiden sind hier Funktionen, die dem Schutz der gespeicherten Daten vor dem Zugriff eines unbefugten Dritten dienen (relative Verschleierung), und solchen Funktionen, die tatsächlich einen Personenbezug gegenüber jedermann ausschließen (absolute Anonymisierung).
Würde ein Unternehmen Scoring-Daten nicht einer Person mit Klarnamen, sondern einem Hash-Digest zuordnen, könnte dieser zwar durch den bloßen Blick auf die Tabelle keine Aussage darüber treffen, wessen Daten hier abgebildet sind (ebenso wenig wie jeder Dritte).
Doch könnte selbstverständlich durch Vorgabe eines bestimmten Namens oder einer bestimmten E-Mailadresse durch die Bildung des Hash-Wertes eine Nachschau durchgeführt werden, wodurch ohne weiteres klar würde ob und welche Daten zu dieser Person vorhanden sind.
Sein einziger Vorteil besteht in der Einseitigkeit des „Look-Ups“ – es braucht immer zunächst ein Klardatum, das dann umgewandelt und nachgeschlagen werden kann. Das Vorgehen stellt insofern einen Schutz des dem Digest zugrundeliegenden Datums dar, und wird von der DSGVO in Art. 32 auch ausdrücklich gefordert, es ist jedoch nach wie vor möglich die Daten einer bekannten Person zuzuordnen, was selbstverständlich gerade der Sinn und Zweck eines Scoring-Systems ist. Dann aber kann nicht von anonymisierten Daten gesprochen werden, wodurch der Anwendungsbereich der DSGVO eröffnet ist.
Auch wenn die Scorings ohne Klardaten nichts über eine Person aussagen, tun sie es eben doch, sobald implizit nach einer Person gefragt wird.
Entwickler sollten sich daher davor hüten, gehashte Daten als „anonymisiert“ zu bezeichnen oder in ihrer Arbeit als solche anzusehen. Ein Personenbezug ist, wie zu zeigen war, jederzeit in herstellbar, wenn auch nicht unmittelbar vorhanden. Dies jedoch reicht wohl vollkommen aus, um auch diese Werte unter die DS-GVO fallen zu lassen.
[1] Zuletzt durch das Urteil des BGH zur Zulässigkeit von sog. „Dashcams“ vor der Entstehung eines Überwachungsdrucks im öffentlichen Bereich ausdrücklich gewarnt, vgl. BGH …
[2] Solche ergeben sich insbesondere aus dem vom Bundesverfassungsgericht aus Art. 2 I und 1 I entwickelten Grundrecht auf informationelle Selbstbestimmung, …
[3] Derzeit sind keine Schwachstellen im Algorithmus der SHA-3 Familie bekannt!
[4] Die in diesem Aufsatz verwendeten Code-Teile sind in Python3 geschrieben.
[5] Ein Byte entspricht 8 Bit
[6] von griech. hexa „sechs“ und lat. decem „zehn“, also die ersten sechs Buchstaben des Alphabets, sowie alle Zahlen von 0 – 9.
[7] Weitere Informationen können hier eingesehen werden: https://keccak.team/papers.html
[8] Dabei ist zu beachten, dass eine minimale Änderung an einem Klartext eine vollständige Änderung des Hash-Wertes herbeiführt, sog. kryptographischer Lawineneffekt. Es kann folglich nicht auf eine „Nähe zum richtigen Wert“ geschlossen werden.
[9] Bereits zum BDSG hat der BGH entschieden, dass dynamische IP-Adressen ein personenbezogenes Datum des Betroffenen darstellen, vgl. BGH VI ZR 135/13
[10] Erwägungsgrund 26 S. 3 f. DS-GVO
[11] s.o.
[12] Zum Begriff des Profilings siehe Art. 4 IV DS-GVO
[13] Erwägungsgrund 26, DS-GVO
[14] Man spräche hierbei von einer sog. Brute-Force-Attack.
[15] Ein solches Vorgehen würde vergleichsweise wenig Ressourcen benötigen und ein deutlich effizienteres Vorgehen ermöglichen.
[16] Der vorgerechnete Hashwert für die mögliche E-Mailadresse passt nunmehr nicht mehr mit dem Wert in der Tabelle des Angreifers überein, der Verwender speichert den „Salt“ separat ab.

References: Art. 4
 Art. 3
 Art. 4
 § 3
 Art. 4
 Art. 4
 Art. 32
 BGH 
 BGH 
 Art. 2
 BGH 
 BGH 
 Art. 4