Unterschiedliche Passwörter für Geräteverschlüsselung und Bildschirmsperre möglich?

Ich möchte, dass mein Passwort für die Geräteverschlüsselung sehr lang und kompliziert ist, aber der Einfachheit halber ein kurzes Passwort für die Bildschirmsperre. Ist das möglich?

Antworten (1)

Auf alten Geräten mit Full Disc Encryption (FDE) war dies für gerootete Geräte möglich. Aber auf modernen Geräten, die File Based Encryption (FBE) verwenden, ist dies nicht mehr möglich und notwendig:

In den alten Zeiten von FDE wurde das Benutzerpasswort direkt verwendet, um den kryptografischen Schlüssel abzuleiten, der die verschlüsselte Benutzerdatenpartition schützte.

Auf modernen Geräten wird die Benutzerauthentifizierung und Verschlüsselungs-Root-Key-Verwaltung in der Trusted Execution Engine (TEE) Ihrer CPU ausgeführt. Dort läuft der Android-Gatekeeper- Code, der das Login-/Bildschirmsperrpasswort prüft und zB Anti-Brute-Force-Maßnahmen anwenden kann, wie das Erzwingen von längeren Wartezeiten, wenn mehrere falsche Passwörter eingegeben wurden. Solange das TEE sicher ist, ist das Gerät sicherer als ein langes Passwort.

Der detaillierte Prozess der Schlüsselableitung für die dateibasierte Verschlüsselung ist gemäß den AOSP-Dokumentationen :

Dateibasierte Verschlüsselungsschlüssel, bei denen es sich um 512-Bit-Schlüssel handelt, werden verschlüsselt von einem anderen Schlüssel (einem 256-Bit-AES-GCM-Schlüssel) gespeichert, der im TEE gespeichert ist. Um diesen TEE-Schlüssel verwenden zu können, müssen drei Voraussetzungen erfüllt sein:

  • Das Authentifizierungstoken
  • Der gestreckte Berechtigungsnachweis
  • Der „secdiscardable hash“ Das Auth-Token ist ein kryptografisch authentifiziertes Token, das von Gatekeeper generiert wird, wenn sich ein Benutzer erfolgreich anmeldet. Das TEE wird die Verwendung des Schlüssels verweigern, wenn nicht das richtige Auth-Token bereitgestellt wird. Wenn der Benutzer keine Anmeldeinformationen hat, wird kein Authentifizierungstoken verwendet oder benötigt.

Der gestreckte Berechtigungsnachweis ist der Benutzer-Berechtigungsnachweis nach dem Salzen und Strecken mit dem Verschlüsselungsalgorithmus. Die Anmeldeinformationen werden tatsächlich einmal im Sperreinstellungsdienst gehasht, bevor sie an vold zur Weitergabe an scrypt übergeben werden. Diese ist mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten, kryptografisch an den Schlüssel im TEE gebunden. Wenn der Benutzer keinen Berechtigungsnachweis hat, werden keine erweiterten Berechtigungsnachweise verwendet oder benötigt.

Der secdiscardable-Hash ist ein 512-Bit-Hash einer zufälligen 16-KB-Datei, die zusammen mit anderen Informationen gespeichert wird, die zum Rekonstruieren des Schlüssels verwendet werden, z. B. dem Seed. Diese Datei wird beim Löschen des Schlüssels sicher gelöscht oder neu verschlüsselt; Dieser zusätzliche Schutz stellt sicher, dass ein Angreifer jedes Bit dieser sicher gelöschten Datei wiederherstellen muss, um den Schlüssel wiederherzustellen. Diese ist mit allen Garantien, die für KM_TAG_APPLICATION_ID gelten, kryptografisch an den Schlüssel im TEE gebunden.

"Noch notwendig"? Soweit ich weiß, möchte OP ein längeres Verschlüsselungskennwort, falls das praktische kurze Kennwort für die Bildschirmsperre durch das Surfen auf der Schulter beeinträchtigt wird. Warum sollte das nicht mehr nötig sein?
@AndreKR Im Falle möglicher Schulter-Surfen-Angriffe wäre der bequeme Weg die Verwendung des Fingerabdrucklesers. Ich schrieb "nicht notwendig", da für die ursprüngliche FDE ein längeres Passwort unvermeidlich war, da das Passwort direkt verwendet wurde, um den Verschlüsselungsschlüssel daraus abzuleiten. So konnte ein Angreifer innerhalb weniger Tage ein kurzes Passwort durch einen Brute-Force-Angriff auf die verschlüsselte Partition knacken.