Abrufen eines Festplattenschutz-Dongles in Qualcomm-Android-Handys

Exploit auf Github veröffentlicht




Google hat mit der Einführung der Standard-FDE (Full Disk Encryption) mit Android 5.0 Lollipop begonnen. Als die Verschlüsselung in Nexus 6-Geräten implementiert wurde, beklagten sich viele Benutzer zunächst über den Leistungsabfall beim Lesen und Schreiben von Daten auf das Laufwerk. Ab der Version von Android 6.0 scheint dieses Problem jedoch gelöst zu sein.

Die vollständige Festplattenverschlüsselung schützt alle Informationen auf dem Telefon, auch wenn das Gerät in die Hände von Strafverfolgungsbehörden oder anderen Eindringlingen gelangt ist.

Wenn die Verschlüsselung aktiviert ist, werden alle Informationen auf dem Telefon automatisch im laufenden Betrieb mit dem AES-Schlüssel verschlüsselt, bevor auf das Medium geschrieben wird. Und umgekehrt, wenn Informationen gelesen werden, werden sie automatisch mit diesem Schlüssel entschlüsselt.

Auf iOS 9-Geräten ist dieser Schlüssel eine Ableitung des Benutzerkennworts und eines eindeutigen 256-Bit-Hardwareschlüssels, der werkseitig mit dem Smartphone verbunden ist. Selbst das FBI kann diese Verschlüsselungsstufe nicht mit brutaler Gewalt knacken, wie aus der jüngeren Geschichte mit dem Smartphone des Schützen aus San Bernardino bekannt ist, weshalb das FBI und Apple vor Gericht kamen . Infolgedessen gelang es dem FBI immer noch, das Telefon mit einer unbekannten 0-Tage-Sicherheitslücke zu knacken. Wie aus den Worten des Staatsoberhauptes hervorgeht, mussten Hacker mehr als eine Million Dollar zahlen , um den Schutz des FBI zu umgehen .


Vollständige Festplattenverschlüsselung in iOS

Daher ist FDE Brute Force nur mit einem bestimmten Hardwaregerät möglich. Dies erschwert den Angriff erheblich. Im Normalfall können Sie eine Million Kopien erstellen und die Bruteforce im Cloud-Dienst parallelisieren, sodass Sie 99% der echten Passwörter sehr schnell finden können. In diesem Fall müssen wir uns jedoch auf das einzige Gerät beschränken, auf dem Apple zusätzliche Interferenzen hinzufügt - Verzögerungen zwischen Kennwortversuchen, Begrenzung der maximalen Anzahl von Versuchen usw. Aus diesem Grund ist es für spezielle Dienste äußerst wichtig, einen Weg zu finden, um die Hardware-UID abzurufen. Dann wird das Brute-Force-Passwort zu einer banalen technischen Aufgabe.

Die vollständige Festplattenverschlüsselung in Android 5.0+ ist etwas anders implementiert als in iOS 9 und wird ausführlich in beschriebenNikolay Elenkovs Blog und offizielle Android-Dokumentation .

Hier ist der Verschlüsselungsschlüssel auch eine Ableitung des normalerweise schwachen Benutzerkennworts, aber auch des zufällig generierten 128-Bit-Hauptschlüssels (Device Encryption Key - DEK) und des zufällig generierten 128-Bit-Salt. Das DEK-Generierungsfeld wird durch ein sorgfältig durchdachtes Schema geschützt, das die vom Benutzer eingegebenen Werte verwendet - PIN-Code / Passwort / Muster (Grafikschlüssel) für die Eingabe. Anschließend wird das verschlüsselte DEK in einem speziellen verschlüsselten Speicher abgelegt, der als Kryptofußzeile bezeichnet wird . Alle diese Verschlüsselungsstufen müssen überwunden werden, bevor DEK entschlüsselt und anschließend alle auf dem Laufwerk aufgezeichneten Informationen gespeichert werden.



Wie im Fall von iOS 9 implementiert das Android-Betriebssystem die Bindung des Verschlüsselungsschemas an bestimmte Hardware, um Brute Force auf Kopien des Betriebssystems zu verhindern. Die Hardwarebindungsfunktion wird von einem speziellen Hardwarespeicher ausgeführt - KeyMaster, der in einer speziellen Trusted Execution Environment (TEE) arbeitet, die völlig unabhängig vom Android-Betriebssystem ist. Die Schlüsselsicherheit in der KeyMaster-Umgebung ist von entscheidender Bedeutung. Nur so schützt das System der vollständigen Festplattenverschlüsselung vor der Durchführung effektiver Brute Force in parallelen Streams auf Kopien des Betriebssystems.

Auf Android-Geräten gibt eine isolierte Umgebung niemals ihren eigenen Schlüssel an eine „unsichere“ Umgebung aus. Im Gegenteil, das KeyMaster-Modul empfängt einen „Key Blob“ aus einer unsicheren Umgebung, entschlüsselt den dort gespeicherten Schlüssel und gibt ihn zurück. Mit anderen Worten, der Betrieb des Verschlüsselungssystems ist nur direkt auf dem Hardwaregerät möglich, nicht jedoch in einer virtuellen Umgebung auf einem anderen Computer.

Im Allgemeinen kann der gesamte Prozess in einem solchen Diagramm, das Nikolai Elenkov angibt , schematisch dargestellt werden .



Der Schutz der KeyMaster-Umgebung und die Ausführung von Befehlen auf einem dedizierten sicheren Prozessor werden durch die vom Gerätehersteller bereitgestellte geschützte Umgebung gewährleistet. Im Fall von Qualcomm ist dies die QSEE (Qualcomm Secure Execution Environment). Es können nur separate kleine Anwendungen, sogenannte Trustlets, auf einem dedizierten Prozessor ausgeführt werden. Eines dieser Trustlets ist KeyMaster. Der Android-Quellcode enthält Anweisungen für den Zugriff auf die KeyMaster-Anwendung. Tatsächlich unterstützt das Trustlet nur vier Anweisungen:

 * Commands supported
 */
enum  keymaster_cmd_t {
    /*
     * List the commands supportedin by the hardware.
     */
    KEYMASTER_GENERATE_KEYPAIR = 0x00000001,
    KEYMASTER_IMPORT_KEYPAIR = 0x00000002,
    KEYMASTER_SIGN_DATA = 0x00000003,
    KEYMASTER_VERIFY_DATA = 0x00000004,
};

KeyMaster funktioniert genau wie oben beschrieben: Es empfängt den Key Blob, berechnet die Signatur und legt sie im Puffer ab.

Und jetzt sind wir genau an dem Punkt angelangt, an dem der neue Exploit ausgeführt wird, der am 30. Juni öffentlich zugänglich war ( Repository auf Github ). Der Exploit nutzt die kürzlich entdeckten Sicherheitslücken CVE-2015-6639 und CVE-2016-2431 aus .

Der Autor des Exploits, der Sicherheitsspezialist Gal Beniamini, hat eine gefälschte Version der QSEE-Anwendung geschrieben und es unter Verwendung der oben genannten Sicherheitslücken geschafft, sie in eine sichere Umgebung zu laden, wodurch die Berechtigungen erhöht und der Schutz der QSEE-Umgebung aufgehoben wurde, die beim Generieren eines Schlüssels zum Verschlüsseln der Festplatte beteiligt ist.

Somit kann ein hypothetischer Angreifer die Hardwarekomponente des Verschlüsselungsschlüssels "fälschen" und die Brute Force der verbleibenden Komponenten implementieren, wobei der Android-Schutz durch die Anzahl der Wiederholungsversuche umgangen wird. Es bleibt nur, die Benutzer-PIN / das Passwort mit brutaler Gewalt auszuwählen.

Übrigens gibt es für den seltenen Fall, in dem der Benutzer ein wirklich komplexes Kennwort mit hoher Entropie für die Verschlüsselung festgelegt hat und für eine akzeptable Zeit nicht mit brutaler Gewalt abgerufen werden kann, einen Sicherungsplan. Wenn eine Aufhebung der Verschlüsselung wirklich erforderlich ist, können Sie genau dasselbe Telefon desselben Modells mit denselben Kratzern und einer Schutzhülle finden - und so programmieren, dass ein Passwort gesendet wird, sobald das Opfer es eingibt. Dieses gefälschte Gerät ist anstelle des Originals am Opfer angebracht. Um eine Offenlegung zu vermeiden und gleichzeitig das Risiko auszuschließen, dass das Opfer beim ersten Versuch das falsche Passwort eingibt, muss das Telefon so programmiert werden, dass kein Passwort als das richtige akzeptiert wird.

Aber das ist natürlich ein Extremfall. Es ist eigentlich recht einfach, normale PIN-Codes und Passwörter abzurufen, wenn es keine Hardware-Einschränkungen für Brute Force gibt.

Es gibt einen interessanten Punkt. Die sichere Umgebung auf Mobilgeräten wird nicht von Qualcomm selbst festgelegt, sondern von OEMs. Sie können mit den Strafverfolgungsbehörden des Landes zusammenarbeiten, in dem sie sich befinden, und die Anforderungen von Gerichtsanträgen erfüllen. Wenn ein solches kryptografisches Schema von einem russischen Hersteller implementiert wird, werden die Informationen auf dem Smartphone auf Ersuchen des russischen Gerichts freigegeben.

Und noch ein interessanter Moment. Trotz der Tatsache, dass Gal Benyamini diese Sicherheitslücken seit mehreren Monaten mit Qualcomm und Google diskutiert, ist es nicht so einfach, sie zu beheben - es gibt nicht genügend Software-Upgrades (für zwei Sicherheitslücken wurden Patches für Android im Januar und Mai veröffentlicht ) und möglicherweise ist ein Hardware-Upgrade erforderlich. Tatsache ist, dass ein Angreifer, der ein Gerät empfängt, theoretisch ein Software-Upgrade rückgängig machen, das Gerät auf eine anfällige Version zurücksetzen und einen Angriff ausführen kann.

Wie oben erwähnt, wird der Exploit-Code auf Github veröffentlicht . Hier ist ein Diagramm seiner Arbeit.



Gal Benyamini hat mehrere Python-Skripte geschrieben , die Bruteforce vereinfachen, nachdem ein Exploit ausgelöst wurde. In den Kommentaren zum Blogbeitrag seines Kollegenäußerte den Wunsch, das Skript auf die leistungsstärkste Hashcat / oclHashcat- Bruteforce- Plattform zu portieren .

Benjamini schlägt vor, dass Google zusammen mit OEM-Herstellern ein neues absolut zuverlässiges Hardware-Software-Verschlüsselungsschema entwickeln wird, das selbst theoretisch nicht geknackt werden kann.

Hoffen wir, dass ein solches Schema auf einer neuen Generation von Android-Geräten implementiert ist.

Source: https://habr.com/ru/post/de395643/


All Articles