Die Verschlüsselung ist eine wirksame Maßnahme zur Sicherstellung von Vertraulichkeit von Daten. Insbesondere dient diese Maßnahme der Umsetzung der Anforderungen aus Art. 32 Abs. 1 lit. a DSGVO zum Schutz personenbezogener Daten.

Im IT-Betrieb wird heute oft auf Dienstleister in der Cloud zurückgegriffen, um Arbeitslasten auszuführen und die verarbeiteten Daten remote zu speichern, insbesondere gilt dies auch für personenbezogene Daten. Der Cloud Dienstleister wird dadurch zum Auftragsverarbeiter gemäß Art. 28 DSGVO und muss seinerseits „hinreichend Garantien dafür bieten, dass geeignete technische und organisatorische Maßnahmen so durchgeführt werden, dass die Verarbeitung im Einklang mit den Anforderungen dieser Verordnung erfolgt und den Schutz der Rechte der betroffenen Person gewährleistet.“ (Art. 28 Abs. 1 DSGVO).

Typische Cloud Dienstleister bieten deshalb als Teil ihres Leistungsumfangs die Verschlüsselung von gespeicherten Daten durch deren eigene Infrastruktur an. Die Effektivität einer Verschlüsselung hängt aber auch entscheidend davon ab, wie die für die Verschlüsselung verwendeten Schlüssel erzeugt und verwendet werden. Am Beispiel des Amazon AWS Key Management Service [1] soll hier exemplarisch betrachtet werden, wie „sicher“ diese Verschlüsselung ist. Microsoft bietet mit Azure Key Vault [2] ein vergleichbares Produkt, welches in diesem Artikel aber nicht betrachtet werden soll.

Eine mathematische Verifikation des beschriebenen Verfahrens durchzuführen ist dabei nicht Ziel dieses Beitrags. Nach einer groben Plausibilitätsprüfung wird angenommen, dass das beschriebene Verfahren solide ist und das technisch gewünschte Ergebnis erzeugt. Solange davon ausgegangen wird, dass die Spezifikation korrekt umgesetzt ist und keine nicht dokumentierten, invasiven Operationen ausgeführt werden, bietet die beschriebene Datenspeicherung einen guten Schutz der Vertraulichkeit gegenüber unbefugten Dritten.

Stattdessen steht im Raum, dass der Gerichtshof der Europäischen Union (EuGH) durch sein Urteil vom 16.07.2020 das „Privacy Shield“ Abkommen zwischen der EU und den USA für ungültig erklärt hat, [3] (vgl. hier [4]). Unter dieser Prämisse ist zu prüfen, wie „sicher“ die Speicherung (ggf. personenbezogener) Daten in Rechenzentren ist, die – in diesem konkreten Fall – der US-amerikanischen Rechtslage und somit Zugriffen von US-Behörden unterliegen.

Dafür wird im Rahmen eines kreativen Gedankenspiels überlegt, welche technischen Angriffsvektoren auf das in [1] beschriebene Verfahren bestehen, wenn der Betreiber der Infrastruktur kooperierender Angreifer ist. Die rechtliche Basis für eine solche Kooperation ist dabei der PATRIOT Act [5] in Verbindung mit dem CLOUD Act [6]. Dabei sei erwähnt, dass dem kooperierenden Unternehmen zur Auflage gemacht wird, dass eine Anfrage der Sicherheitsbehörden dem Kunden nicht konkret mitgeteilt werden darf.

Angriffsszenarien

Zum einen ist die für die Schlüsselverwaltung verwendete Hardware, sogenannte „hardware security modules“ (HSM) zu betrachten. Das HSM kann die für das Verfahren notwendigen Hauptschlüssel („customer master key“, CMK) intern selbst erzeugen. Wie die Operation Rubikon [7] gezeigt hat, ist es für Regierungsorganisationen möglich, manipulierte Hardware in Umlauf zu bringen. Die erzeugten Schlüssel könnten also manipuliert oder ausgeleitet werden.

Stattdessen bietet Amazon die Möglichkeit, kundeneigene Schlüssel in das HSM zu importieren. In offensichtlich gleicher Manier könnten auch diese Schlüssel in der Hardware kompromittiert werden. Darüber hinaus kann sich der Kunde nicht sicher sein, mit dem HSM zu kommunizieren – ein Man-in-the-Middle Angriff auf die Datenkommunikation durch den Dienstleister wäre möglich.

Der im HSM gespeicherte CMK wird nicht direkt benutzt, sondern aus ihm werden Schlüssel abgeleitet, die verwendet werden, um wiederum andere Schlüssel zu verschlüsseln, wie in [1] detailliert beschrieben. Um Schlüssel zu erzeugen und Entschlüsselung von Schlüsseln vorzunehmen, muss die Software des Kunden den Zugriff auf Operationen des HSM ausdrücklich erlauben.

Wenn die Programme des Kunden den Zugriff erlauben können, die auf der Infrastruktur des Dienstleisters betrieben werden, könnten auch andere Programme des Betreibers zum Einsatz kommen, die den Zugriff an Stelle der Kundensoftware erlauben, d. h. der Infrastrukturbetreiber könnte die Autorisierung eigenmächtig veranlassen. Selbst wenn der Betreiber die Zugriffe nicht eigenmächtig erlaubt, kann er durch eine Man-in-the-middle Attacke noch immer die Kommunikation des Ergebnisses vom HSM zurück zum Programm des Kunden ausspähen und die erzeugten Daten kopieren.

Das HSM protokolliert die Zugriffe auf Daten und der Kunde kann die Protokolle einsehen – insofern nicht wie eben beschrieben die Hardware bereits kompromittiert ist und das HSM die Protokolle nicht anfertigt oder nicht kommuniziert –, aber der Zugriff auf diese Daten erfolgt wieder über die Infrastruktur des Betreibers. Auch bei der Kontrolle der Protokolle des HSM ist wieder eine Man-in-the-middle Attacke auf die Datenkommunikation möglich.

Speziell auf “Amazon EBS Volume Encryption” bezogen steht in [1]: “A call to AWS KMS over TLS is made to decrypt the encrypted volume key.” Der für die Verschlüsselung eines gesamten Speichermediums (Volume) verwendete Schlüssel liegt also im Klartext vor und wird an die Laufzeitumgebung des Kunden ausgeliefert.

Speziell auf “Client-side Encryption…” bezogen steht in [1]: “The AWS Encryption SDK […] includes an API operation for performing envelope encryption using a CMK from AWS KMS.“ Der Betreiber stellt also dem Anwender eine Programmbibliothek zur Verfügung, die vom Programm des Kunden genutzt wird, um die kryptografischen Operationen durchzuführen. Diese Bibliothek kann leicht für die Entschlüsselung der gespeicherten Daten verwendet werden oder um die Schlüssel auszuleiten.

Soweit können bereits diverse Angriffsszenarien durch einen kooperierenden Dienstleister auf die ruhenden Daten („data at rest“) skizziert werden. Die Kommunikation der Daten innerhalb des Rechenzentrums des Dienstleisters („data in transit“) erfolgt zwar mittels abgesicherter Verbindungen, aber in diese via Man-in-the-middle-Attacken oder durch Verwendung schwacher Algorithmen unbemerkt Einsicht zu nehmen, ist für den Betreiber des Rechenzentrums z. B. durch Verwendung eines transparenten Proxies trivial.

Zu schlechter Letzt, um die beim Dienstleister gespeicherten Daten zu verarbeiten („data in use“), müssen sie entschlüsselt werden. Die Verarbeitung selbst erfolgt typischerweise ebenfalls unter der Ägide desselben Dienstleisters. Dieser kann im einfachsten Fall Zugriff auf den Speicher der laufenden typischerweise virtuellen Maschine im Rechenzentrum nehmen und dort die Daten oder Schlüssel auslesen, oder eigenen Code einfügen, der die Klardaten abfließen lässt.

An dieser Stelle muss man nicht einmal an kooperierende Betreiber denken: die Applikation, die auf den Servern läuft, hat Zugriff auf die Klardaten, weil sie sonst nicht zweckgemäß verarbeitet werden können. Schon ein ausgenutztes Defizit, vom Programmfehler über eine fehlkonfigurierte Datenbank, die jeden Zugriff aus der ganzen Welt zulässt, bis hin zu Backup-Dateien ohne Zugriffsschutz in öffentlichen Dateibereichen, reicht, die verschlüsselt gespeicherten Daten mit filigranem Schlüsselmanagement zu offenbaren und die Vertraulichkeit zu gefährden.

Fazit

Es bestätigt sich die allgemeine Erkenntnis, dass ein Betreiber einer Plattform Zugriff auf die auf ihr verarbeiteten und gespeicherten Daten nehmen kann, auch ohne Kenntnis des Nutzers. Damit können sie auch an „Befugte“ weitergeben werden.

Die Verwendung von HSM-Modulen zur Schlüsselverwaltung, die implementierten Protokolle zur Schlüsselgenerierung und -verwaltung und verschlüsselte Transportverbindungen innerhalb des Rechenzentrums sind sicherlich geeignete Methoden, um die Daten vor einem unbefugten Dritten einschließlich Innentätern zu schützen. Zur Abwehr gegenüber dem Dienstanbieter selbst, der durch gesetzliche Vorgaben zur Kooperation mit Sicherheitsbehörden gezwungen wird, sind sie letztendlich nicht geeignet.

Ein Schutz der gespeicherten Daten („data at rest“) vor dem Dienstanbieter ließe sich nur bewerkstelligen, wenn die Daten vor der Übermittlung zu ihm bereits verschlüsselt würden. Damit würde sich die Dienstleistung aber auf die reine Speicherung der Daten beschränken, eine Verarbeitung vor Ort, also das Cloud Computing („data in use“), würde dadurch unmöglich.

Abschließend sei angemerkt, dass das Urteil zur Aufhebung des Privacy Shield [3] nicht per se den Zugriff von US-amerikanischen Sicherheitsbehörden für intolerabel erklärt. Zur Erinnerung: auch in Deutschland haben Sicherheitsbehörden und Nachrichtendienste Zugang zu gespeicherten oder übertragenen Daten. Stattdessen wird durch den EuGH kritisiert, dass die Eingriffe nicht eingeschränkt sind und den dadurch betroffenen Personen keine dem EU-Recht vergleichbaren Rechtsmittel zur Verfügung stehen. Die Pressemitteilung [8] gibt eine gut verständliche Zusammenfassung des Urteils.

Für personenbezogene Daten ist „ein dem Risiko angemessenes Schutzniveau“ (Art. 32 Abs. 1 DSGVO) gefordert. Die Bewertung der beschriebenen Angriffsszenarien im postulierten legislativen Kontext, das sich daraus ergebende Risiko für die Rechte und Freiheiten natürlicher Personen, ob die durch die Infrastruktur-Betreiber getroffenen Maßnahmen auch nach dem Ende des Privacy Shield noch geeignet sind, um damit ein angemessenes, der EU vergleichbares Schutzniveau zu erreichen, oder welche Maßnahmen nun zu treffen sind, um ein angemessene Schutzniveau herzustellen, muss in einem multilateralen juristischen, politischen und gesamtgesellschaftlichen Diskurs erörtert werden.

Referenzen

[1]          „Amazon AWS Key Management Service – Cryptographic Details“, Amazon Web Services, August 2018, abgerufen am 30.07.2020 von https://d0.awsstatic.com/whitepapers/KMS-Cryptographic-Details.pdf

[2]          “Microsoft Azure Key Vault”, abgerufen am 30.07.2020 von https://azure.microsoft.com/en-us/services/key-vault/

[3]          JUDGMENT OF THE COURT (Grand Chamber), 16 July 2020, Case C‑311/18, Court of Justice of the European Union, ECLI:EU:C:2020:559, abgerufen am 30.07.2020 von http://curia.europa.eu/juris/document/document.jsf?docid=228677&doclang=en

[4]          „The CJEU rules in favour of Schrems and invalidates Privacy Shield Decision”, Prekshi Gulia, Carolin Cornely, Datenschutz Notizen, abgerufen am 30.07.2020 von https://www.datenschutz-notizen.de/the-cjeu-rules-in-favour-of-schrems-and-invalidates-privacy-shield-decision-3526597/

[5]          “UNITING AND STRENGTHENING AMERICA BY PROVIDING APPROPRIATE TOOLS REQUIRED TO INTERCEPT AND OBSTRUCT TERRORISM (USA PATRIOT ACT) ACT OF 2001”, PUBLIC LAW 107–56—OCT. 26, 2001, USA, abgerufen am 30.07.2020 von https://www.congress.gov/107/plaws/publ56/PLAW-107publ56.pdf

[6]          “Clarifying Lawful Overseas Use of Data Act” or the “CLOUD Act”, H. R. 1625—866, DIVISION V, USA, abgerufen am 30.07.2020 von https://epic.org/privacy/cloud-act/cloud-act-text.pdf

[7]          „Operation ‚Rubikon‘ #Cryptoleaks: Wie BND und CIA alle täuschten“, Elmar Theveßen, Peter F. Müller und Ulrich Stoll, ZDF, 11.02.2020, abgerufen am 30.07.2020 von https://www.zdf.de/nachrichten/politik/cryptoleaks-bnd-cia-operation-rubikon-100.html

[8]          „Der Gerichtshof erklärt den Beschluss 2016/1250 über die Angemessenheit des vom EU-US-Datenschutzschild gebotenen Schutzes für ungültig“, PRESSEMITTEILUNG Nr. 91/20, Gerichtshof der Europäischen Union, 16.07.2020, abgerufen am 31.07.2020 von https://curia.europa.eu/jcms/upload/docs/application/pdf/2020-07/cp200091de.pdf

| | | , , , , , ,