Google Cloud Key Vault-Dienst

Wir beschreiben einen Cloud-Dienst, der sichere Hardware verwendet, um kryptografische Schlüssel so zu speichern, dass der Zugriff auf diese durch einen geringen Entropie-Wissensfaktor (z.B. eine Sperrbildschirm-PIN) geschützt wird. Die sichere Hardware wurde entwickelt, um Brute-Force-Angriffe zu verhindern. Die gespeicherten kryptografischen Schlüssel werden nach zu vielen fehlgeschlagenen Versuchen, den richtigen Wissensfaktor bereitzustellen, dauerhaft unwiederbringlich unwiederbringlich verloren.

Autor:Shabsi Walfish
Versionsdatum:06.03.2018

Hinweis: Dieses Dokument ist noch in der Entwicklung und die Details der Implementierung sind noch nicht abgeschlossen. Sobald sich das System stabilisiert hat und weitere Dokumentationen möglich sind, werden wir dieses Whitepaper mit ausführlicheren Informationen aktualisieren (insbesondere in Verbindung mit relevanten Open-Source-Releases).

Übersicht

Traditionell erfordert die Verschlüsselung (zur Gewährleistung des Datenschutzes) die Verwendung von Secrets, die aus Sicht des Angreifers eine hohe Entropie haben. Eine hohe Entropie ist erforderlich, da das Verschlüsselungsschema Brute-Force-Angriffe standhalten muss, die das gesamte Spektrum wahrscheinlicher Secrets untersuchen, bis das richtige gefunden wurde. Angesichts der heutigen Verfügbarkeit von Rechenleistung kann eine angemessene Mindestentropieanforderung für kryptografische Secrets bei etwa 70 bis 80 Bit liegen. Leider fällt es Menschen mit dieser Menge an Entropie¹ sehr schwer, sich Passwörter oder andere Geheimnisse zu merken und sie sich zuverlässig zu merken. Das gilt insbesondere, wenn sie nur selten verwendet werden. Die häufige Verwendung eines Passworts mit hoher Entropie ist jedoch schwierig und mühsam. Das stellt uns vor einem schwierigen Problem: Wie können wir private Daten mit Verschlüsselungstechnologie schützen, wenn das Secret ein „Wissensfaktor“ sein soll, an den sich der Nutzer mit hoher Wahrscheinlichkeit erinnert? Dieses Problem ist aus verschiedenen Gründen so schwer zu lösen, dass Cloud-Speicherdienste in der Regel nur Daten mit Secrets verschlüsseln, die vom Cloud Storage-Anbieter selbst verwaltet werden, anstatt darauf angewiesen zu sein, dass sich der Nutzer sein eigenes Secret merkt.

Ein Ansatz, um die Lücke zwischen den Anforderungen für kryptografische Secrets und von Menschen einprägsame Secrets zu schließen, ist die Verwendung eines Cloud Key Vault-Dienstes (CKV), um einen Wiederherstellungsschlüssel mit hoher Entropie zu speichern, der durch ein menschliches, einprägsames Secret mit niedriger Entropie geschützt ist. Der CKV-Dienst gibt den Wiederherstellungsschlüssel nur an eine Partei weiter, die die Kenntnis des korrekten menschlichen einprägsamen Geheimnisses nachweisen kann. Brute-Force-Angriffe auf ein menschliches Geheimnis können vom CKV-Dienst verhindert werden. Dieser erzwingt ein absolutes Limit für die Anzahl der fehlgeschlagenen Versuche, die Kenntnis des Secrets nachzuweisen. Der Wiederherstellungsschlüssel selbst ist ein standardmäßiger kryptografischer symmetrischer Schlüssel, der sich für die Verwendung mit einem (authentifizierten) Verschlüsselungsschema eignet, mit dem große Datenmengen (z. B. eine Laufwerksicherung) einfach verschlüsselt werden können, die überall sicher gespeichert werden können. Solche verschlüsselten Daten sind für alle nutzlos, die den Wiederherstellungsschlüssel nicht erhalten können.

In diesem Whitepaper wird unser Ansatz für den Aufbau eines Cloud Key Vault-Dienstes mithilfe von Trusted Hardware Modules (THMs) beschrieben. Unsere erste Implementierung des CKV-Dienstes wurde entwickelt, um Wiederherstellungsschlüssel mit dem Sperrbildschirm-Wissensfaktor (LSKF) des Nutzers zu schützen – der geheime PIN, das Passwort oder das Wischmuster zum Entsperren von Smartphones. Menschen können sich zuverlässig an ihr LSKF erinnern. Gleichzeitig haben solche LSKF-Secrets in der Regel gerade genug Entropie, um einem Angreifer mit einer sehr begrenzten Anzahl von Versuchen zu widerstehen. Dadurch sind sie gut für den CKV-Dienst geeignet.

Die erste Anwendung unseres Cloud Key Vault-Dienstes ist die Aktivierung clientseitig verschlüsselter Android-Sicherungen. Bisher wurde für lokal auf dem Android-Gerät verschlüsselte Dateien ein Schlüssel verwendet, der mit dem LSKF des Nutzers geschützt war. Die Sicherungen dieser in der Cloud gespeicherten (und verschlüsselten) Dateien wurden jedoch nicht durch das LSKF geschützt. Cloud Key Vault ermöglicht erstmals auch den Sperrbildschirmschutz für Android-Sicherungen, die in der Cloud gespeichert sind. Das bedeutet, dass die Google-Server nicht auf die Inhalte der verschlüsselten Sicherungen zugreifen oder diese wiederherstellen können. Nur ein Gerät mit dem LSKF des Nutzers kann die Sicherungen entschlüsseln.

Kernkonzepte

Zu Beginn ist die einzige unterstützte Clientplattform für den Cloud Key Vault-Dienst das Betriebssystem Android 9 Pie. Wenn wir in diesem Whitepaper auf den Client verweisen, beziehen wir uns auf ein Gerät, auf dem das Betriebssystem Android 9 Pie mit Google Play-Diensten ausgeführt wird. Unsere serverseitige Implementierung wird auf speziellen Google-Servern ausgeführt, auf denen ein zusätzlicher Titan-Chip² installiert ist. Der von Google entwickelte Titan-Chip dient als Hardwarekomponente in unserem vertrauenswürdigen Hardwaremodul. Wir stellen ihn speziell mit einem benutzerdefinierten Bootloader und einer benutzerdefinierten Firmware bereit, die unsere Protokolle und Sicherheitskontrollmechanismen (wie hier beschrieben) implementieren. Wir verwenden Hardwareattestierungstechniken, um zu versichern, dass unser Protokoll wirklich auf der Titan-Hardware ausgeführt wird.

Der CKV-Dienst muss skaliert werden, um den Traffic von Milliarden³ von Android-Geräten zu bewältigen, ohne dass eine erhebliche Menge an Nutzerdaten aufgrund von Hardwareausfällen (z.B. ausgebrannte Chips) oder längeren Ausfällen aufgrund von Wartungsarbeiten am Rechenzentrum verloren geht. Aus diesem Grund sind die Server mit den Titan-Chips in Kohorten organisiert, wobei jede Kohorte aus mehreren unabhängigen THMs besteht, die jeweils eine Kopie desselben Schlüsselmaterials enthalten. Eine bestimmte Kohorte wird auf physisch unterschiedliche Rechenzentren in verschiedenen Wartungszonen verteilt, damit das System seine Ziele bezüglich Verfügbarkeit und Zuverlässigkeit erreichen kann. Aus Gründen der Skalierbarkeit werden Clients in eine Reihe verschiedener Kohorten aufgeteilt. So können wir die Kapazität des Dienstes anpassen, indem wir einfach weitere Server hinzufügen, um die Anzahl der verfügbaren Kohorten zu erhöhen.

Wir können nun die wichtigsten Komponenten der Cloud Key Vault-Dienstarchitektur aufzählen.

Architekturkomponenten / Glossar

Sperrbildschirm-Wissensfaktor (LSKF): Ein menschenlesbares Geheimnis, z. B. eine kurze PIN, ein Wischmuster über ein Raster mit drei Punkten mit drei Punkten oder ein Passwort. Mit diesem Secret soll verhindert werden, dass das Gerät lokal entsperrt werden kann. Es gilt als primärer (oder „starker“) Authentifizierungsfaktor für die Displaysperre des lokalen Geräts des Nutzers.

Client:Ein Endnutzergerät, auf dem das Betriebssystem Android 9 Pie und Google Play-Dienste ausgeführt werden, oder eine entsprechende unterstützte Software.

Android-Framework:Wir verwenden diesen Oberbegriff (oder einfach das Framework) für die APIs in Android 9 Pie oder höher und nicht für frühere Releases.

Google Play-Dienste:Eine Sammlung von Diensten und Apps, die auf dem Gerät des Endnutzers ausgeführt werden und mit den Kontensystem-APIs und benutzerdefinierten Server-APIs von Google zusammen funktionieren.

Wiederherstellungs-Agent:Eine Systemanwendung, die als Teil der Google Play-Dienste im Nutzerbereich auf einem Android 9 Pie-Gerät (oder einem ähnlichen Gerät) ausgeführt wird. Der Wiederherstellungs-Agent ist für die clientseitige Ausführung der verschiedenen Protokolle sowie für die Schnittstelle zwischen Android-Betriebssystem und -Protokoll verantwortlich, um Protokollnachrichten zu erstellen, die den LSKF betreffen.

Wiederherstellungsanspruch:Wenn der Nutzer den Wiederherstellungsschlüssel abrufen möchte, muss er einen Wiederherstellungsanspruch erstellen. Dieser muss eine verschlüsselte Kopie des LSKF enthalten, die der Nutzer zu kennen angibt. Normalerweise wird der Nutzer aufgefordert, den LSKF-Wert seines alten Geräts auf einem neuen Gerät einzugeben, das versucht, auf den Wiederherstellungsschlüssel des alten Geräts zuzugreifen.

Wiederherstellungsschlüssel: Ein kryptografischer geheimer Schlüssel, der durch den Cloud Key Vault-Dienst geschützt wird und zum Verschlüsseln (und Authentifizieren) von Daten auf dem Clientgerät verwendet wird. Nachdem der Wiederherstellungsschlüssel in Vault abgelegt wurde (siehe unten), kann die lokale Kopie gelöscht werden, sobald der Client ihn zum Verschlüsseln von Daten verwendet hat.

Cloud Key Vault-Dienst (CKV):Ein Internetdienst, der es Clientgeräten ermöglicht, kryptografische Schlüssel zu speichern, die durch einen menschenlesbaren LSKF geschützt sind.

Kohorte: Eine Sammlung von Vault-Servern/THMs, die als redundante Replikate voneinander dienen können.

Öffentlicher Schlüssel der Kohorte: Der öffentliche Schlüssel aus einem Schlüsselpaar, das von einer bestimmten Kohorte von THMs generiert wurde. Der entsprechende private Schlüssel ist nur in den THMs verfügbar, die zum Zeitpunkt der Schlüsselgenerierung in der Kohorte waren.

Trusted Hardware Module (THM): Ein dediziertes Sicherheitsmodul (Mikrocontroller), das eine minimale und vertrauenswürdige Computing-Umgebung bietet. Das Secure Element muss mindestens in der Lage sein, geheime Schlüssel zu generieren und/oder zu speichern und einen sich ständig weiterentwickelnden Zustand beizubehalten (damit es Angriffe verhindern kann, die das Zurücksetzen auf einen früheren Zustand erfordern).

Vault:Ein bestimmter Eintrag in der Datenbank des CKV-Dienstes, der den LSKF-geschützten Wiederherstellungsschlüssel eines einzelnen Geräts enthält. Ein Endnutzer kann mehrere Vaults hinterlegt haben, die jeweils einem anderen Gerät oder LSKF entsprechen. Nur der THM in einem Vault-Server kann den Inhalt von Vault untersuchen oder extrahieren.

Vault-Server:Eine Maschine für allgemeine Zwecke, die in einem Google-Rechenzentrum ausgeführt wird und speziell nachgerüstet wurde, um ein Trusted Hardware Module (THM) hinzuzufügen.

Protokolldesign

Das CKV-Protokoll besteht aus mehreren Phasen:

Initialisierung

Zum Initialisieren des Systems stellt Google einen öffentlichen Schlüssel für eine „Root of Trust“ bereit, mit dem das Framework die Hardwareattestierungen von Google überprüft. Der Signaturschlüssel für diese Root of Trust wird offline gespeichert und sorgfältig gesichert, sodass mehrere Mitarbeiter beteiligt sein müssen, um damit zu signieren. Der öffentliche Schlüssel für diese Root of Trust ist im Android-Betriebssystem verankert und kann nur über ein Betriebssystemupdate geändert werden.

Google veröffentlicht außerdem regelmäßig eine Liste der öffentlichen Schlüssel für jede Kohorte von THMs sowie eine Attestierung auf der Liste. Die Attestierung auf der Liste verwendet eine Signatur, die zurück zur Root of Trust führt. Jede Aktualisierung der veröffentlichten Liste enthält auch eine Sequenznummer, sodass Rollbacks verhindert werden können. Der Wiederherstellungs-Agent ruft die zuletzt veröffentlichte Liste der öffentlichen Kohortenschlüssel ab und stellt sie dem Framework bereit. Das Framework verifiziert dann die Attestierung und wählt nach dem Zufallsprinzip einen öffentlichen Kohortenschlüssel aus der Liste aus, der in der Vault-Erstellungsphase verwendet werden soll.

Vault-Erstellung

Nachdem das Framework durch Abrufen der Liste der öffentlichen Kohortenschlüssel die Initialisierung abgeschlossen hat, fordert der Wiederherstellungs-Agent das Framework an, ein neues Vault zu erstellen. Bei jeder Eingabe des LSKF durch den Nutzer generiert das Framework einen neuen Wiederherstellungsschlüssel und verschlüsselt ihn zuerst mit einem Schlüssel, der aus einem Hash des LSKF abgeleitet ist, und danach mit dem öffentlichen Kohortenschlüssel, den das Framework während der Initialisierung ausgewählt hat. Das resultierende verschlüsselte Blob ist der Vault, der vom Framework an den Wiederherstellungs-Agent zurückgegeben wird, der ihn dann in den CKV-Dienst von Google hochlädt.

Vault-Öffnung

Wenn der Wiederherstellungs-Agent auf einem neuen Gerät Zugriff auf den Wiederherstellungsschlüssel benötigt, der in einem bestimmten Vault gespeichert ist, wird der Nutzer zuerst aufgefordert, den LSKF des ursprünglichen Geräts einzugeben, auf dem der Vault erstellt wurde. Der Wiederherstellungs-Agent fordert dann das Framework auf, einen Wiederherstellungsantrag mit diesem LSKF zu erstellen. Das Framework generiert einen neuen Anspruchsschlüssel und verschlüsselt diesen Anspruchsschlüssel sowie den Hash des beanspruchten LSKF mit demselben öffentlichen Kohortenschlüssel, mit dem Vault ursprünglich verschlüsselt wurde. Das resultierende verschlüsselte Blob wird als Wiederherstellungsanforderung bezeichnet und vom Framework an den Wiederherstellungs-Agent übergeben, der ihn dann dem CKV-Dienst präsentiert.

Der CKV leitet den Wiederherstellungsantrag und den zugehörigen Vault an die Vault-Server weiter, die zur richtigen Kohorte gehören. Das THM in den Vault-Servern entschlüsselt dann den Wiederherstellungsantrag und versucht, den Wiederherstellungsschlüssel aus dem ursprünglichen Vault zu extrahieren. Dazu wird der beanspruchte LSKF-Hash verwendet, um den inneren Verschlüsselungsschlüssel abzuleiten. Wenn der ursprüngliche LSKF-Hash und der beanspruchte LSKF-Hash übereinstimmen, extrahiert das THM den Wiederherstellungsschlüssel aus Vault und verschlüsselt ihn mit dem Anspruchsschlüssel aus dem Wiederherstellungsantrag neu. Andernfalls wird der Zähler für fehlgeschlagene Versuche vom THM ausgelöst. Wenn die Zähler für fehlgeschlagene Versuche das Limit erreicht, lehnt das THM die Bearbeitung von Wiederherstellungsanfragen für diesen Vault ab.

Wenn alles gut gelaufen ist, wird der neu verschlüsselte Wiederherstellungsschlüssel, der jetzt unter dem Claimant Key verschlüsselt ist, vom Vault-Server bis an das Framework zurückgesendet. Das Framework verwendet seine Kopie des Claimant Key, um den Recovery Key (Wiederherstellungsschlüssel) zu entschlüsseln, und das Protokoll ist jetzt vollständig.

Sicherheitsmaßnahmen

Das Cloud Key Vault-System bietet gestaffelte Sicherheitsebenen, indem es Sicherheitsvorkehrungen auf mehreren Ebenen unseres Stacks einbindet. Um ein Gefühl für die Funktionsweise dieser Schutzmaßnahmen zu vermitteln, beschreiben wir zuerst den Client und arbeiten sich dann bis zum Cloud Key Vault-Dienst vor.

Clientsicherheit

Je nach OEM und Gerät wird der Sperrbildschirm-Wissensfaktor (LSKF) normalerweise mit verschiedenen Methoden, die sich je nach OEM unterscheiden, auf dem Gerät gespeichert und geschützt. Beispielsweise nutzen die Pixel 2-Geräte von Google ein manipulationssicheres Hardware-Sicherheitsmodul, um das LSKF inaktive Daten zu speichern und hardwarebasierte Ratenbegrenzungen für die LSKF-Validierung zu erzwingen. Die neuen Framework APIs, die für die Nutzung von Cloud Key Vault eingeführt werden, sind darauf ausgelegt, bestehende Sicherheitsgarantien so weit wie möglich aufrechtzuerhalten, selbst wenn das Gerät ein solches Hardwaresicherheitsmodul zum Schutz der Speicherung des LSKF verwendet.

In diesem Abschnitt konzentrieren wir uns speziell auf die relevanten Sicherheitsprobleme und Schutzmaßnahmen, die die neue Cloud Key Vault-Funktion betreffen, und nicht versuchen, ein vollständiges Bild aller Sicherheitsmechanismen im Zusammenhang mit dem LSKF zu geben.

Framework-APIs schützen

Die neuen Framework APIs, die zur Unterstützung des CKV-Dienstes hinzugefügt wurden, sind als @SystemApi gekennzeichnet und erfordern spezielle Berechtigungen, die dafür sorgen, dass sie nur für vom OEM genehmigte System-Apps wie Google Play-Dienste verfügbar sind. Dadurch wird weitgehend jede direkte Angriffsfläche entfernt, die für Apps, die der Nutzer auf dem Gerät installiert, ausgesetzt sein könnte.

Die Framework APIs sorgen außerdem dafür, dass Vaults nur für öffentliche Kohortenschlüssel erstellt werden, die von einer Root of Trust bestätigt wurden. Der Root of Trust ist vom OEM in das Framework verankert, wenn es versendet wird, und kann ohne ein Betriebssystemupdate nicht geändert werden. So wird sichergestellt, dass das LSKF nur zum Erstellen von Vaults verwendet wird, die hardwarebasierte Brute-Force-Schutzmaßnahmen ordnungsgemäß erzwingen. Durch den Einsatz der THMs im Cloud Key Vault-Dienst zum Brute-Force-Schutz für das LSKF können wir eine Sicherheit erreichen, die mit der Verwendung sicherer Hardware auf dem Gerät für dasselbe Ziel vergleichbar ist (wie bei Google Pixel 2-Geräten).

Da wir nicht davon ausgehen, dass der LSKF irgendwo auf dem Gerät außerhalb der sicheren Hardware gespeichert wird, kann ein neuer Vault nur sofort nach der Entsperrung des Geräts erstellt werden. Wenn der Nutzer den LSKF eingibt, um das Gerät zu entsperren, wird er dem Framework kurz im RAM zur Verfügung gestellt. Das ist der Moment, in dem die neue API zum Erstellen von Vault sie verwendet. Es ist nicht möglich, einen neuen LSKF-geschützten Vault-Dienst zu erstellen, während das Gerät gesperrt ist, da der LSKF-Dienst nicht verfügbar ist.

Wiederherstellungs-Agent sichern

Der primäre Sicherheitsschutz, den wir für den Wiederherstellungs-Agent bieten, besteht darin, dass der Wiederherstellungs-Agent nie den LSKF des aktuellen Geräts oder Wiederherstellungsschlüssel sehen kann. Nur das Framework sollte diese Informationen auf Clientseite sehen, was es viel schwieriger macht, potenzielle Programmfehler oder Sicherheitslücken im Wiederherstellungs-Agent auszunutzen. Der Wiederherstellungs-Agent wird hauptsächlich zum Verwalten von Lebenszyklusereignissen und der Übergabe von Daten zwischen der Cloud und dem Framework verwendet. Die einzige Ausnahme gilt während einer Wiederherstellung kurz vor dem Vault-Eröffnungsprotokoll, wenn der Nutzer den LSKF des alten Geräts eingeben muss. Die UI, über die der beanspruchte LSKF für das alte Gerät abgerufen wird, wird im Wiederherstellungs-Agent⁴ implementiert. Der beanspruchte LSKF wird jedoch durch die Implementierung des Wiederherstellungs-Agents „entfernt“, sobald das Framework den Aufbau des Wiederherstellungsantrags übernimmt.

Sicherheitsfunktionen des Protokolls

Während eine vollständige Analyse des Protokolls über den Rahmen dieses Dokuments hinausgeht, möchten wir einige der integrierten Schutzmaßnahmen hervorheben. Insbesondere wird vom Protokoll durchgehend nur der Hash des LSKF verwendet. Das bedeutet: Wenn der LSKF eine hohe Entropie hat (z. B. ein gutes Passwort mit hoher Entropie), ist das Speichern von Vault grundsätzlich besser als das Speichern eines Passwort-Hash. In diesem Fall kann der Passwort-Hash ein von der Sicherheit der THMs unabhängiges Maß sein. Aus diesem Grund unterstützen wir als Teil des Protokolls das sogenannte Salted-Arbeitsspeicher-Hashing des LSKF. Außerdem binden wir Vault kryptografisch an eine Kennung des Geräts, von dem es erstellt wurde, und den Wiederherstellungsanspruch an eine Nonce, die während des Vault-Eröffnungsprotokolls als Identitätsbestätigung verwendet wird, um sicherzustellen, dass der Wiederherstellungsanspruch aktuell ist.

Da der Wiederherstellungsschlüssel bei jeder Vault-Erstellung neu generiert wird, implementieren wir die Schlüsselrotation, indem wir einen vorhandenen Vault-Eintrag mit einem neu erstellten Vault-Eintrag überschreiben. Die Adresse für den von Vault verwendeten Zähler für fehlgeschlagene Versuche wird während der Vault-Erstellung ausgewählt. Das Framework sorgt dafür, dass sich die für alle nachfolgenden Vaults verwendete Zähleradresse nur ändert, wenn entweder das LSKF geändert wurde oder es eine neue attestierte Liste öffentlicher Kohortenschlüssel gibt. Auf diese Weise kann die Drehung des Wiederherstellungsschlüssels erfolgen, ohne den Brute-Force-Schutz für den LSKF zu beeinträchtigen.

Serversicherheit für den Cloud Key Vault-Dienst

Der Server wird mithilfe einer Kombination aus Software implementiert, die auf gewöhnlicher Serverhardware ausgeführt wird, und Firmware, die auf spezieller Hardware (dem Titan-Chip) ausgeführt wird. Im Folgenden werden die Schutzmaßnahmen auf den einzelnen Ebenen beschrieben.

Hardwareschutz

Der primäre Sicherheitsschutz auf der Serverseite des CKV-Dienstes sind die vertrauenswürdigen Hardwaremodule (THMs), die mit den eigens entwickelten Titan-Chips von Google erstellt werden. Auf den Chips wird eine Firmware ausgeführt, die die erforderlichen APIs zur Implementierung der CKV-Protokolle bereitstellt. Insbesondere können sie ein Schlüsselpaar generieren und sicher mit anderen Mitgliedern ihrer Kohorte teilen, sodass die Firmware-Logik den privaten Schlüssel vor der Offenlegung der Titan-Chips in der Kohorte schützt. Sie können auch den Vault-Öffnenvorgang durchführen und einen strikt inkrementellen Zähler für fehlgeschlagene Versuche pro Vault pflegen (bei dem der Zähler durch den im Titan-Chip gespeicherten Status gesichert wird). Eine ausführlichere Beschreibung des von der CKV-Titan-Chip-Firmware ausgeführten Protokolls wird in einer zukünftigen Version dieses Dokuments bereitgestellt.

Da die Serversicherheit von der Firmwarelogik in den Titan-Chips abgeleitet wird, müssen wir dafür sorgen, dass sich die Logik nicht so ändert, dass die Chips Geheimnisse preisgeben oder die Zählerlimits ignorieren können. Um dieses Ziel zu erreichen, ändern wir auch den Titan-Bootloader, damit die im Chip gespeicherten Daten (z. B. der private Schlüssel für die Kohorte) vollständig gelöscht werden, bevor ein Update angewendet wird. Der Nachteil dieses Schutzes ist, dass wir Fehler in der Firmware nicht ohne Datenverlust beheben können. Das Aktualisieren der Firmware entspricht funktional der Zerstörung der vorhandenen Hardware und dem Ersetzen durch neue Chips. Falls ein wichtiger Firmware-Patch erforderlich ist, muss Google eine völlig neue Liste der attestierten öffentlichen Kohortenschlüssel erstellen und veröffentlichen und alle Nutzer schrittweise zur neuen Liste migrieren. Um dieses Risiko zu minimieren, versuchen wir, die Firmware-Codebasis möglichst minimal zu halten und sie sorgfältig auf mögliche Sicherheitsprobleme zu prüfen.

Softwareschutz

Zusätzlich zu den von den THMs vorgegebenen harten Ausfallgrenzen pro Vault implementiert der CKV-Dienst auch eine softwarebasierte Ratenbegrenzung. Die Ratenbegrenzung soll verhindern, dass ein Hacker in ein Nutzerkonto eindringt und das Limit für fehlgeschlagene Wiederherstellungsversuche schnell ausschöpft. So wird der Zugriff des echten Nutzers auf seine Wiederherstellungsschlüssel gesperrt. Ähnlich wie bei der Zeitverzögerung, die das Gerät des Nutzers nach zu vielen fehlgeschlagenen Versuchen, den Bildschirm zu entsperren, erzwingt der CKV-Dienst eine zunehmende Zeitverzögerung nach jeder nachfolgenden fehlgeschlagenen Vault-Öffnungsanfrage.

Darüber hinaus implementieren wir Standardsicherheitsmaßnahmen für Cloud-Dienste, die Nutzerdaten hosten, einschließlich strenger Zugriffssteuerungen, Monitoring und Auditing.

Detaillierte Protokollspezifikation

Die detaillierte Protokollspezifikation ist noch in Arbeit und dieses Dokument wird im Laufe des Jahres mit diesen Details sowie der Veröffentlichung des Clientcodes im Android Open Source-Projekt aktualisiert.

Hinweise

1. „Towards Zuverlässige Speicherung von 56-Bit-Secrets in Human Memory | USENIX.“ 1. August 2014, https://www.usenix.org/node/184458 ↩
2. Google Cloud Platform-Blog: Titan in depth: Security in plaintext. 24. August 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html. ↩
3. „Google kündigt über 2 Milliarden monatlich aktive Geräte auf Android an...“ 17. Mai 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users. ↩
4. Dadurch können wir flexible UIs für die Eingabe des LSKF eines anderen Geräts bereitstellen. Das Framework des aktuellen Geräts hat möglicherweise keine geeignete UI für die Eingabe des LSKF des alten Geräts.↩