Schützt die vollständige Geräteverschlüsselung meine Daten vor Google und der Regierung?

Apple hat kürzlich innerhalb der Tech-Community Wellen geschlagen, indem es sich weigerte, die Strafverfolgungsbehörden in Bezug auf den Zugriff auf verschlüsselte Benutzerdaten einzuhalten. Ihre Aussage war, dass sie nicht über die technischen Möglichkeiten verfügen, diese Daten zu entschlüsseln.

Gibt es als Android-Benutzer eine ähnliche Möglichkeit (vorzugsweise in das Betriebssystem statt von Drittanbietern integriert), die ich nutzen kann, um einen ähnlichen Schutz sogar vor Google und meinem Gerätehersteller zu erreichen? Ich weiß, dass es in meinen Einstellungen die "Full Device Encryption" gibt, aber verhindert dies, dass Google usw. darauf zugreift?

Als Referenz läuft auf meinem Gerät Android Lollipop und es ist ein OnePlus Two. Wenn andere Versionen wie Marshmallow mir das erlauben würden, ist das in Ordnung.

Antworten (2)

Google hat keine Ahnung, was der Verschlüsselungsschlüssel für Ihr Gerät ist. Der gesamte Vorgang findet auf Ihrem Gerät statt und der Schlüssel wird niemals irgendwohin übertragen. Der Schlüssel selbst wird auch nicht im Klartext auf Ihrem Gerät gespeichert :

Speichern des verschlüsselten Schlüssels

Der verschlüsselte Schlüssel wird in den Krypto-Metadaten gespeichert. Die Hardwareunterstützung wird mithilfe der Signierfunktion von Trusted Execution Environment (TEE) implementiert. Zuvor haben wir den Hauptschlüssel mit einem Schlüssel verschlüsselt, der durch Anwenden von scrypt auf das Kennwort des Benutzers und das gespeicherte Salt generiert wurde. Um den Schlüssel gegen Off-Box-Angriffe widerstandsfähig zu machen, erweitern wir diesen Algorithmus, indem wir den resultierenden Schlüssel mit einem gespeicherten TEE-Schlüssel signieren. Die resultierende Signatur wird dann durch eine weitere Anwendung von Verschlüsselung in einen Schlüssel geeigneter Länge umgewandelt. Dieser Schlüssel wird dann verwendet, um den Hauptschlüssel zu verschlüsseln und zu entschlüsseln.

Selbst wenn also jemand eine Kopie Ihres verschlüsselten Hauptschlüssels hätte, könnte er ihn ohne den TEE-Schlüssel aus dem SoC Ihres Geräts nicht entschlüsseln.

Abgesehen von einem Fehler in der Implementierung verhindert die vollständige Geräteverschlüsselung daher, dass jemand auf Ihre Daten zugreift, es sei denn, er kennt/erhält Ihr Passwort ODER kann Ihr Passwort erraten (z. B. durch Brute-Force oder eine Art von Social-Engineering-Techniken). Auf Geräten, denen die erforderliche Hardwareunterstützung fehlt, versucht FDE, den Schlüssel mit einer reinen Softwaremethode zu verschlüsseln.

@beeshyams Es ist eine Funktion des Prozessors. Die Implementierung von ARM heißt „TrustZone“, aber auch andere Architekturen bieten ähnliche Mechanismen. Die Idee ist, dass Sie einen Geräteschlüssel generieren, ihn an einem Ort speichern können, auf den nur das TEE zugreifen kann, und ihn dann niemals der Außenwelt offenbaren. Wenn Sie etwas verschlüsseln/entschlüsseln müssen, bitten Sie den im TEE ausgeführten Code, dies für Sie zu tun, damit der Schlüssel sicher bleibt. Wikipedia hat einen anständigen (-ish) Artikel .
Wie gut schützt dies vor Brute-Force-Angriffen über modifizierte Firmware? Verhindert es Firmware-Updates ohne Entschlüsselung? Anscheinend ist das der aktuelle potenzielle Angriffsvektor für iOS (vor iPhone 6). Wäre gut, das auch für Android zu beantworten. Das Aufbewahren eines gerätelokalen TEE-Schlüssels ist schön und gut, aber er wird geschwächt, wenn Angreifer die Möglichkeit haben, eine anfällige Firmware-Version zu laden/booten.
@eldarerathis: Danke. IMO erfordert es mehr Verständnis. Verfassen einer Kopfgeldfrage . Sie können gerne antworten, vorausgesetzt, es wird nicht abgeschossen :)
@Bob Die verschlüsselten Daten selbst konnten nicht allein durch ein ROM-Update entschlüsselt werden. Sie würden immer noch den Schlüssel brauchen (ich bin mir nicht sicher, ob Sie das mit Ihrer zweiten Frage gemeint haben?). Was das Flashen eines geschwächten ROM betrifft, so wäre es im Grunde dasselbe wie die iOS-Situation, solange der Bootloader des Geräts gesperrt ist – nur OEM-signierte Updates werden installiert. Außerdem würde das Entsperren des Bootloaders, um zu versuchen, ein unsigniertes Image zu flashen, das Gerät löschen.
@eldarerathis Ich habe gehört, dass iPhone 6 und neuer sogar vor OEM-Updates sicher sind, da die Passwortüberprüfung ( einschließlich der zeitgesteuerten Verzögerung/Sperre) vollständig in Hardware implementiert ist. Ich frage mich, ob Android etwas Ähnliches tut oder ob es sich um eine reine Software-Sperre handelt, die natürlich durch ein Firmware-Update umgangen werden kann. Ich frage auch, ob es Android-basierte Telefone mit Bootloadern gibt, die Updates ablehnen, ohne dass der vom Benutzer angegebene Passcode eingegeben wird - was das Umgehen von Software-Sperrzeiten einfacher machen würde.
Eine weitere Umformulierung ist, ob es eine Möglichkeit gibt, zu verlangen, dass eine Entschlüsselung (mit Benutzerkennwort) erfolgt, bevor Aktualisierungen zugelassen werden. Mit anderen Worten, sind (OEM, signierte) Updates ohne den Entschlüsselungsschlüssel (ohne ein obligatorisches Löschen von Benutzerdaten) installierbar?
@Bob Meines Wissens benötigt Android kein Entschlüsselungskennwort, um den Aktualisierungsvorgang durchzuführen, da es nur die /userdataPartition verschlüsselt, nicht die Partitionen, die das Update tatsächlich ändern würde ( /systemund /bootim Allgemeinen). Es ist so ziemlich im selben Boot wie das iPhone 5 (und niedriger).
Ich würde hinzufügen, ich bin mir nicht sicher, ob die allgemeine Verzögerung pro Versuch etwas ist, das durch ein Update "deaktiviert" werden kann, oder ob Android sie künstlich skaliert. Android verwendet Scrypt-Runden während des Schlüsselgenerierungsprozesses, daher müsste es auch beim Entschlüsseln des Schlüssels verwendet werden, und Scrypt ist speziell darauf ausgelegt, schwer zu beschleunigen, um Brute-Forcing zu vermeiden. So viel würde konsequent bleiben. Eine Sperrung nach X fehlgeschlagenen Versuchen (oder eine skalierte Sperrung, falls vorhanden) würde jedoch in Software implementiert werden, AFAIK.
Danke. Auch relevant: crypto.stackexchange.com/a/32891/11619 Anscheinend ist es unter iOS möglich, die „Secure Enclave“-Firmware zu aktualisieren, ohne den Passcode zu kennen und ohne die Schlüssel zu verlieren. Unter der Annahme, dass dies zutrifft, gilt am Ende des Tages dieselbe Schwachstelle (für OEM-signierte Updates) sowohl für Android als auch für iOS. Vielleicht ist Android sicherer, weil es längere Passwörter zulässt, obwohl das vom Benutzer abhängt und ziemlich unpraktisch wäre.
Bob, ich vermute, dass "in Hardware implementiert" irreführend ist. Was tatsächlich passiert, ist, dass diese Schutzmaßnahmen in Firmware implementiert sind und diese Firmware aktualisiert werden kann. Die Alternative wäre, dass es keine Möglichkeit gibt, Fehler darin zu beheben, wie zum Beispiel das Problem „Error 53“ in iPhones. Bruce Schneier bezeichnet dies als „Sicherheitslücke“, aber das dehnt die Definition von „Sicherheitslücke“ wohl zu weit aus. Offensichtlich kann die Firmware nur aktualisiert werden, wenn Sie die OEM-Schlüssel besitzen. Wir wissen, dass diese Schlüssel für den Stuxnet-Wurm geleakt wurden (wie Schneier betont), und sie könnten auch für Apple- oder Google-Produkte gelten.
Wird das Rooten des Geräts jedem erlauben, ohne die OEM-Schlüssel die Firmware zu aktualisieren?
@JimThio Wahrscheinlich, aber nur, wenn Sie beim Booten Zugriff auf das System oder ADB hatten. Andernfalls hätten Sie keine Möglichkeit, die Root-Berechtigungen tatsächlich zu nutzen. Alternativ können Sie mit einer benutzerdefinierten Wiederherstellung die Firmware aktualisieren.

Die vollständige Geräteverschlüsselung schützt Ihr Gerät, wenn Sie einen Schlüssel zu lange für Brute-Force verwenden, selbst wenn die Angreifer Brute-Force-Techniken anwenden können – vorausgesetzt, es gibt Möglichkeiten, ihnen dies zu ermöglichen. Snowden sagt, dass 64 Zeichen lang genug für eine wirklich unknackbare Verschlüsselung sind. So ist vollständige Sicherheit erreichbar - wenn es Ihnen nichts ausmacht, jedes Mal, wenn Sie das Telefon aufwecken, eine 64-stellige Passphrase einzugeben.

Sind Sie sich der Beschränkung der PIN-Länge für die Bildschirmsperre bewusst? Erwägen Sie, Ihre Antwort entsprechend neu zu starten
Ja, 16 Zeichen sind die Begrenzung, wenn Sie den Quellcode überprüfen .