Google Cloud Key Vault-Dienst

Wir beschreiben einen Cloud-Dienst, der kryptografische Schlüssel mithilfe sicherer Hardware speichert, sodass der Zugriff durch einen Wissensfaktor mit niedriger Entropie geschützt ist (z.B. eine PIN für den Sperrbildschirm). Die sichere Hardware wurde entwickelt, um Brute-Force-Angriffe zu verhindern. Dazu werden die gespeicherten kryptografischen Schlüssel nach zu vielen fehlgeschlagenen Versuchen, den richtigen Wissensfaktor anzugeben, dauerhaft unwiederherstellbar.

Autor: Shabsi Walfish
Version: 2018-03-06

Hinweis: Dieses Dokument ist noch in Arbeit und die Details der Implementierung werden noch finalisiert. Sobald sich das System stabilisiert hat und mehr Dokumentation verfügbar ist, werden wir dieses Whitepaper mit detaillierteren Informationen aktualisieren (insbesondere im Zusammenhang mit relevanten Open-Source-Veröffentlichungen).

Übersicht

Traditionell erfordert die Verschlüsselung (die zum Schutz der Daten verwendet wird) die Verwendung von Geheimnissen, die aus Sicht des Angreifers eine hohe Entropie haben. Eine hohe Entropie ist erforderlich, da das Verschlüsselungsschema Brute-Force-Angriffen standhalten muss, bei denen der gesamte Bereich aller wahrscheinlichen Geheimnisse durchsucht wird, bis das richtige gefunden wird. Angesichts der heutigen Rechenleistung liegt eine angemessene Mindestentropieanforderung für kryptografische Geheimnisse bei etwa 70 bis 80 Bit. Leider fällt es Menschen sehr schwer, Passwörter oder andere Geheimnisse mit dieser Entropie¹ auswendig zu lernen und sich zuverlässig daran zu erinnern, insbesondere wenn sie selten verwendet werden. Die häufige Verwendung eines Passworts mit hoher Entropie ist jedoch schwierig und mühsam. Das stellt uns vor eine Herausforderung: Wie können wir private Daten mit Verschlüsselungstechnologie schützen, wenn das Geheimnis ein „Wissensfaktor“ sein soll, den sich der Nutzer mit hoher Wahrscheinlichkeit merken kann? Aus verschiedenen Gründen ist dieses Problem so schwer zu lösen, dass Cloud-Speicherdienste Daten in der Regel nur mit Geheimnissen verschlüsseln, die vom Cloud-Speicheranbieter selbst verwaltet werden, anstatt darauf zu vertrauen, dass sich der Nutzer sein eigenes Geheimnis merkt.

Eine Möglichkeit, die Lücke zwischen den Anforderungen an kryptografische und von Menschen leicht zu merkende Secrets zu schließen, besteht darin, einen Cloud Key Vault-Dienst (CKV) zu verwenden, um einen „Wiederherstellungsschlüssel“ mit hoher Entropie zu speichern, der durch ein von Menschen leicht zu merkendes Secret mit niedriger Entropie geschützt ist. Der CKV-Dienst gibt den Wiederherstellungsschlüssel nur an eine Partei frei, die nachweislich das richtige, für Menschen leicht zu merkende Geheimnis kennt. Brute-Force-Angriffe auf das für Menschen leicht zu merkende Geheimnis können vom CKV-Dienst verhindert werden, der die Anzahl der fehlgeschlagenen Versuche zum Nachweis des Wissens des Geheimnisses absolut begrenzt. 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 sich problemlos große Datenmengen (z. B. eine Laufwerksicherung) verschlüsseln lassen, die überall sicher gespeichert werden können. Solche verschlüsselten Daten sind für alle nutzlos, die nicht den Wiederherstellungsschlüssel erhalten können.

In diesem Whitepaper wird unser Ansatz zur Erstellung eines Cloud Key Vault-Dienstes mit vertrauenswürdigen Hardwaremodulen (Trusted Hardware Modules, THMs) beschrieben. Unsere erste Implementierung des CKV-Dienstes soll Wiederherstellungsschlüssel mit dem Lock Screen Knowledge Factor (LSKF) des Nutzers schützen – der geheimen PIN, dem Passwort oder dem Wischmuster, mit dem Smartphones entsperrt werden. Menschen können sich ihre LSKF zuverlässig merken. Gleichzeitig haben solche LSKF-Geheimnisse in der Regel gerade genug Entropie, um einem Angreifer mit einer sehr begrenzten Anzahl von Versuchen zu widerstehen. Sie eignen sich daher gut für den CKV-Dienst.

Die erste Anwendung unseres Cloud Key Vault-Dienstes wird die clientseitige Verschlüsselung von Android-Sicherungen sein. Bisher wurden lokal auf dem Android-Gerät verschlüsselte Dateien mit einem Schlüssel geschützt, der mit dem LSKF des Nutzers geschützt war. Die in der Cloud gespeicherten (und verschlüsselten) Sicherungen dieser Dateien wurden jedoch nicht durch den LSKF geschützt. Zum ersten Mal ermöglicht Cloud Key Vault den Sperrbildschirmschutz auch für in der Cloud gespeicherte Android-Sicherungen. Das bedeutet, dass die Server von Google nicht auf den Inhalt der verschlüsselten Sicherungen zugreifen oder diese wiederherstellen können. Nur ein Gerät mit dem LSKF des Nutzers kann die Sicherungen entschlüsseln.

Wichtige Konzepte

Derzeit ist Android 9 Pie die einzige unterstützte Clientplattform für den Cloud Key Vault-Dienst. Wenn in diesem Whitepaper von einem Client die Rede ist, bezieht sich das auf ein Gerät mit dem Betriebssystem Android 9 Pie und Google Play-Diensten. Unsere serverseitige Implementierung wird auf speziell dafür vorgesehenen Google-Servern ausgeführt, die mit einem zusätzlichen Titan-Chip² ausgestattet sind. Der von Google entwickelte Titan-Chip dient als Hardwarekomponente in unserem Trusted Hardware Module. Wir stellen ihn speziell mit einem benutzerdefinierten Bootloader und einer Firmware bereit, die unsere Protokolle und Sicherheitsmechanismen (wie hier beschrieben) implementiert. Wir verwenden Hardwareattestierungsmethoden, um sicherzustellen, dass unser Protokoll tatsächlich auf der Titan-Hardware ausgeführt wird.

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

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

Architekturkomponenten / Glossar

Wissensfaktor für den Sperrbildschirm (Lock Screen Knowledge Factor, LSKF): Ein für Menschen leicht zu merkendes Geheimnis, z. B. eine kurze PIN, ein Wischmuster über ein 3 × 3 Punktraster oder ein Passwort. Dieses Geheimnis wird verwendet, um die Möglichkeit zu schützen, das Gerät lokal zu entsperren. Es gilt als primärer (oder „starker“) Authentifizierungsfaktor für die lokale Displaysperre des Nutzers.

Client: Ein Endnutzergerät mit dem Betriebssystem Android 9 Pie und den Google Play-Diensten oder einer gleichwertigen unterstützten Software.

Android-Framework:Dieser generische Begriff (oder einfach das Framework) bezieht sich auf die APIs in Android 9 Pie oder höher und nicht auf frühere Releases.

Google Play-Dienste: Eine Sammlung von Diensten und Apps, die auf dem Endnutzergerät ausgeführt werden und die die Verwendung des Kontosystems von Google und benutzerdefinierter Server-APIs ermöglichen.

Wiederherstellungs-Agent: Eine Systemanwendung, die im Rahmen der Google Play-Dienste im Userspace auf einem Gerät mit Android 9 Pie (oder ähnlich) ausgeführt wird. Der Wiederherstellungsagent ist dafür verantwortlich, die Clientseite der verschiedenen Protokolle auszuführen und bei Bedarf mit dem Android-Betriebssystem zu kommunizieren, um Protokollnachrichten zu erstellen, die die LSKF betreffen.

Antrag auf Wiederherstellung:Wenn der Nutzer den Wiederherstellungsschlüssel abrufen möchte, muss er einen Antrag auf Wiederherstellung erstellen, der eine verschlüsselte Kopie des LSKF enthält, den der Nutzer angeblich kennt. Normalerweise wird der Nutzer aufgefordert, den LSKF 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 vom Cloud Key Vault-Dienst geschützt wird und zum Verschlüsseln (und Authentifizieren) von Daten auf dem Clientgerät verwendet wird. Sobald der Wiederherstellungsschlüssel in einem Vault gespeichert wurde (siehe unten), kann die lokale Kopie gelöscht werden, sobald der Client ihn nicht mehr zum Verschlüsseln von Daten verwendet.

Cloud Key Vault (CKV)-Dienst: Ein Internetdienst, mit dem Clientgeräte kryptografische Schlüssel speichern können, die durch einen leicht zu merkenden LSKF geschützt sind.

Kohorte: Eine Gruppe von Vault-Servern/-Speicherorten, 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 sich zum Zeitpunkt der Schlüsselgenerierung in der Kohorte befanden.

Trusted Hardware Module (THM): Ein spezielles 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 nichtflüchtigen, sich entwickelnden Status aufrechtzuerhalten, damit Angriffe, die einen Zurücksetzen auf einen früheren Zustand beinhalten, verhindert werden können.

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

Vault-Server: Ein Allzweckcomputer in einem Google-Rechenzentrum, der speziell für die Installation eines Trusted Hardware Modules (THM) umgerüstet wurde.

Protokolldesign

Das CKV-Protokoll besteht aus mehreren Phasen:

Initialisierung

Zur Initialisierung des Systems stellt Google einen öffentlichen Schlüssel für einen „Root of Trust“ bereit, mit dem das Framework die Hardwareattestierungen von Google überprüft. Der Signaturschlüssel für diesen vertrauenswürdigen Stamm wird offline gespeichert und sorgfältig gesichert, sodass mehrere Mitarbeiter erforderlich sind, um damit zu signieren. Der öffentliche Schlüssel für diesen Stamm der Vertrauenskette ist in das Android-Betriebssystem eingebettet und kann nur über ein Betriebssystemupdate geändert werden.

Außerdem veröffentlicht Google regelmäßig eine Liste mit öffentlichen Schlüsseln für jeden Cohort von THMs zusammen mit einer Attestierung auf der Liste. Die Attestierung in der Liste verwendet eine Signatur, die bis zum Root of Trust zurückverfolgt werden kann. Jede Aktualisierung der veröffentlichten Liste enthält außerdem eine Sequenznummer, damit Rollbacks verhindert werden können. Der Wiederherstellungsagent ruft die aktuellste veröffentlichte Liste der öffentlichen Schlüssel der Kohorte ab und stellt sie dem Framework zur Verfügung. Das Framework überprüft dann die Attestierung und wählt einen öffentlichen Schlüssel der Kohorte aus der Liste aus, der in der Phase der Tresorerstellung verwendet werden soll.

Vault erstellen

Nachdem der Recovery Agent dem Framework geholfen hat, die Initialisierung abzuschließen, indem er die Liste der öffentlichen Schlüssel der Kohorte abgerufen hat, fordert er das Framework auf, einen neuen Tresor zu erstellen. Wenn der LSKF vom Nutzer das nächste Mal eingegeben wird, generiert das Framework einen neuen Wiederherstellungsschlüssel und verschlüsselt ihn zuerst mit einem Schlüssel, der aus einem Hash des LSKF abgeleitet wurde, und dann mit dem öffentlichen Kohortenschlüssel, der vom Framework während der Initialisierung ausgewählt wurde. Das resultierende verschlüsselte Blob ist der Vault, der vom Framework an den Recovery Agent zurückgegeben wird, der ihn dann in den CKV-Dienst von Google hochlädt.

Tresoröffnung

Wenn der Wiederherstellungsagent auf dem neuen Gerät Zugriff auf den Wiederherstellungsschlüssel benötigt, der in einem bestimmten Tresor gespeichert ist, wird der Nutzer zuerst aufgefordert, den LSKF des ursprünglichen Geräts einzugeben, mit dem der Tresor erstellt wurde. Der Recovery Agent bittet dann das Framework, mit diesem LSKF einen Recovery Claim zu erstellen. Das Framework generiert einen neuen Anspruchsberechtigtenschlüssel und verschlüsselt diesen Anspruchsberechtigtenschlüssel sowie den Hash des beanspruchten LSKF mit demselben Cohort Public Key, mit dem der Tresor ursprünglich verschlüsselt wurde. Der resultierende verschlüsselte Blob wird als Recovery Claim bezeichnet und vom Framework an den Recovery Agent übergeben, der ihn dann dem CKV-Dienst vorlegt.

Der CKV leitet den Wiederherstellungsanspruch (und den zugehörigen Vault) an die Vault-Server weiter, die zur richtigen Kohorte gehören. Der THM auf den Vault-Servern entschlüsselt dann den Wiederherstellungsanspruch und versucht, den Wiederherstellungsschlüssel aus dem ursprünglichen Vault zu extrahieren, indem er den angegebenen LSKF-Hash verwendet, um den inneren Verschlüsselungsschlüssel abzuleiten. Wenn der ursprüngliche LSKF-Hash mit dem angegebenen LSKF-Hash übereinstimmt, extrahiert der THM den Wiederherstellungsschlüssel aus dem Tresor und verschlüsselt ihn noch einmal mit dem Antragstellerschlüssel, der im Wiederherstellungsanspruch enthalten war. Andernfalls erhöht der THM den Zähler für fehlgeschlagene Versuche. Sobald der Zähler für fehlgeschlagene Versuche das Limit erreicht hat, lehnt der THM die Verarbeitung nachfolgender Wiederherstellungsanträge für diesen Tresor ab.

Wenn alles reibungslos funktioniert hat, wird der neu verschlüsselte Wiederherstellungsschlüssel (der jetzt mit dem Claimant Key verschlüsselt ist) vom Vault-Server an das Framework zurückgesendet. Das Framework verwendet seine Kopie des Claimant Key, um den Recovery Key zu entschlüsseln. Das Protokoll ist jetzt abgeschlossen.

Sicherheitsmaßnahmen

Das Cloud Key Vault-System soll durch Sicherheitsmaßnahmen auf mehreren Ebenen unseres Stacks einen umfassenden Schutz bieten. Um einen Eindruck davon zu vermitteln, wie diese Schutzmaßnahmen funktionieren, beginnen wir mit der Beschreibung des Clients und arbeiten uns dann den Stack hinauf zum Cloud Key Vault-Dienst vor.

Clientsicherheit

Je nach OEM und Gerät wird der Knowledge Factor für den Sperrbildschirm (Lock Screen Knowledge Factor, LSKF) normalerweise mithilfe verschiedener Methoden auf dem Gerät gespeichert und geschützt. So verwenden Google Pixel 2-Geräte beispielsweise ein manipulationssicheres Hardware-Sicherheitsmodul, um den LSKF im Ruhezustand zu speichern und hardwarebasierte Ratenlimits für die LSKF-Bestätigung durchzusetzen. Die neuen Framework APIs, die zur Verwendung des Cloud Key Vault eingeführt werden, sollen die bestehenden Sicherheitsgarantien so weit wie möglich erhalten, auch wenn das Gerät ein solches Hardware-Sicherheitsmodul zum Schutz des Speichers des LSKF verwendet.

In diesem Abschnitt konzentrieren wir uns auf die relevanten Sicherheitsprobleme und ‑maßnahmen, die sich auf die neue Cloud Key Vault-Funktion auswirken, anstatt ein vollständiges Bild aller Sicherheitsmechanismen zu liefern, die mit dem LSKF verbunden sind.

Framework-APIs sichern

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

Die Framework APIs sorgen außerdem dafür, dass Tresore nur für öffentliche Schlüssel von Kohorten erstellt werden, die von einem Root of Trust attestiert wurden. Die Root of Trust wird vom OEM beim Versand in das Framework eingebettet und kann nur durch ein Betriebssystemupdate geändert werden. So können Sie sicher sein, dass der LSKF nur zum Erstellen von Tresoren verwendet wird, die hardwarebasierten Schutz vor Brute-Force-Angriffen ordnungsgemäß erzwingen. Durch die Verwendung der THMs im Cloud Key Vault-Dienst für den Brute-Force-Schutz des LSKF können wir eine Sicherheit erreichen, die mit der Verwendung sicherer Hardware auf dem Gerät für denselben Zweck vergleichbar ist (wie bei Google Pixel 2).

Da wir nicht davon ausgehen, dass der LSKF außerhalb der sicheren Hardware auf dem Gerät gespeichert wird, kann ein neuer Tresor nur direkt nach dem Entsperren des Geräts erstellt werden. Wenn der Nutzer den LSKF zum Entsperren des Geräts eingibt, wird er dem Framework kurzzeitig im RAM zur Verfügung gestellt. In diesem Moment wird es von der neuen API zum Erstellen des Vaults verwendet. Es ist nicht möglich, einen neuen LSKF-geschützten Vault zu erstellen, während das Gerät gesperrt ist, da der LSKF nicht verfügbar ist.

Wiederherstellungs-Agent schützen

Der primäre Sicherheitsschutz, den wir für den Wiederherstellungsagenten bieten, besteht darin, dass das Protokoll so konzipiert ist, dass der Wiederherstellungsagent niemals den LSKF des aktuellen Geräts oder andere Wiederherstellungsschlüssel sehen kann. Nur das Framework sollte diese Dinge auf der Clientseite sehen, was das Ausnutzen potenzieller Fehler oder Sicherheitslücken im Recovery Agent erschwert. Der Wiederherstellungsagent wird hauptsächlich verwendet, um Lebenszyklusereignisse und den Datenaustausch zwischen der Cloud und dem Framework zu verwalten. Die einzige Ausnahme ist während einer Wiederherstellung kurz vor dem Vault-Öffnungsprotokoll, wenn der Nutzer den LSKF des alten Geräts eingeben muss. Die Benutzeroberfläche, auf der der angegebene LSKF für das alte Gerät erfasst wird, ist im Recovery Agent implementiert⁴. Die Implementierung des Wiederherstellungs-Agenten „vergisst“ jedoch die angegebene LSKF, sobald das Framework die Erstellung des Wiederherstellungsanspruchs übernimmt.

Sicherheitsfunktionen des Protokolls

Eine vollständige Analyse des Protokolls würde den Rahmen dieses Dokuments sprengen. Wir möchten jedoch einige der im Protokoll integrierten Schutzmaßnahmen hervorheben. Insbesondere wird im Protokoll durchgängig nur der Hashwert der LSKF verwendet. Wenn der LSKF also eine hohe Entropie hat (z. B. ein gutes Passwort mit hoher Entropie), ist das Speichern des Tresors eindeutig besser als das Speichern eines Passwort-Hashes. In diesem Fall kann der Passwort-Hash ein Maß an Sicherheit bieten, das unabhängig von der Sicherheit der THMs ist. Aus diesem Grund unterstützen wir im Rahmen des Protokolls die salzbasierte „speicherintensive“ Hash-Technologie für den LSKF. Außerdem binden wir den Tresor kryptografisch an eine Kennung für das Gerät, auf dem er erstellt wurde, und binden den Wiederherstellungsanspruch an eine Nonce, die während des Protokolls zum Öffnen des Tresors als Herausforderung 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 überschreiben. Die Adresse für den Zähler für fehlgeschlagene Versuche, die vom Tresor verwendet wird, wird beim Erstellen des Tresors ausgewählt. Das Framework sorgt dafür, dass sich die Zähleradresse, die für nachfolgende Tresore verwendet wird, nicht ändert, es sei denn, der LSKF wurde geändert oder es gibt eine neue attestierte Liste der öffentlichen Schlüssel der Kohorte. So kann der Wiederherstellungsschlüssel rotiert werden, ohne den Brute-Force-Schutz für den LSKF zu beeinträchtigen.

Serversicherheit für den Cloud Key Vault-Dienst

Der Server wird mit einer Kombination aus Software, die auf gewöhnlicher Serverhardware ausgeführt wird, und Firmware, die auf spezieller Hardware (dem Titan-Chip) ausgeführt wird, implementiert. Wir beschreiben die Schutzmaßnahmen auf jeder Ebene.

Hardwareschutz

Der primäre Sicherheitsschutz, der auf der Serverseite des CKV-Dienstes implementiert ist, sind die Trusted Hardware Modules (THMs), die mit den benutzerdefinierten Titan-Chips von Google gebaut werden. Auf den Chips wird eine Firmware ausgeführt, die die erforderlichen APIs für die Implementierung der CKV-Protokolle bereitstellt. Insbesondere können sie ein Schlüsselpaar generieren und sicher mit anderen Mitgliedern ihrer Kohorte teilen, sodass die Firmwarelogik den privaten Schlüssel vor dem Austreten außerhalb der Titan-Chips in der Kohorte schützt. Sie können auch den Vorgang zum Öffnen des Safes ausführen und einen streng inkrementellen Zähler für fehlgeschlagene Versuche pro Safe verwalten. Der Zähler wird durch den im Titan-Chip gespeicherten Status unterstützt. Eine ausführlichere Beschreibung des Protokolls, das von der CKV Titan-Chip-Firmware ausgeführt wird, wird in einer zukünftigen Version dieses Dokuments bereitgestellt.

Da die Serversicherheit von der Firmwarelogik in den Titan-Chips abhängt, müssen wir dafür sorgen, dass sich die Logik nicht so ändert, dass die Chips Geheimnisse weitergeben oder die Zählerlimits ignorieren können. Dazu ändern wir auch den Titan-Bootloader, damit die gespeicherten Daten des Chips (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 dem Zerstören der vorhandenen Hardware und dem Ersetzen durch neue Chips. Falls ein kritischer Firmware-Patch erforderlich ist, muss Google eine völlig neue Liste mit attestierten öffentlichen Cohort-Schlüsseln erstellen und veröffentlichen und alle Nutzer nach und nach auf die neue Liste umstellen. Um dieses Risiko zu minimieren, versuchen wir, die Firmware-Codebasis möglichst klein zu halten und sie sorgfältig auf potenzielle Sicherheitsprobleme zu prüfen.

Softwareschutz

Zusätzlich zu den harten Fehlerlimits pro Vault, die von den THMs auferlegt werden, implementiert der CKV-Dienst auch eine softwarebasierte Ratenbegrenzung. Die Ratenbegrenzung soll verhindern, dass ein Hacker in das Konto eines Nutzers eindringt und schnell das Limit der fehlgeschlagenen Wiederherstellungsversuche erreicht, wodurch der Zugriff des echten Nutzers auf seine Wiederherstellungsschlüssel effektiv gesperrt wird. Ähnlich wie bei den Zeitverzögerungen, die vom Gerät des Nutzers nach zu vielen fehlgeschlagenen Versuchen zum Entsperren des Bildschirms erzwungen werden, erzwingt der CKV-Dienst nach jeder nachfolgenden fehlgeschlagenen Anfrage zum Öffnen des Tresors eine zunehmende Zeitverzögerung.

Außerdem setzen wir standardmäßige Sicherheitsmaßnahmen für Cloud-Dienste ein, in denen Nutzerdaten gehostet werden, einschließlich strenger Zugriffskontrollen, Überwachung und Prüfungen.

Detaillierte Protokollspezifikation

Die detaillierte Protokollspezifikation ist noch in Arbeit. Dieses Dokument wird zusammen mit der Veröffentlichung des Clientcodes im Android Open Source Project noch in diesem Jahr aktualisiert.

Hinweise

1. „Towards Reliable Storage of 56-bit Secrets in Human Memory | USENIX“ 1. August 2014, https://www.usenix.org/node/184458.  ↩
2. „Google Cloud Platform Blog: Titan im Detail: Sicherheit im Klartext“ 24. August 2017, https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html.  ↩
3. „Google announces over 2 billion monthly active devices on Android ....“, 17. Mai 2017, https://www.theverge.com/2017/5/17/15654454/android-reaches-2-billion-monthly-active-users.  ↩
4. So können wir flexible Benutzeroberflächen für die Eingabe des LSKF eines anderen Geräts bereitstellen. Das Framework des aktuellen Geräts hat möglicherweise keine geeignete Benutzeroberfläche für die Eingabe des LSKF des alten Geräts. ↩