Biometrische Daten von Android-Geräten extrahieren

Immer häufiger werden Mobile Trusted Execution Environments (ARM TrustZone) für mobile Zahlungsdienste, Geräteintegrität, Mobile Device Management und alle anderen Anforderungsprofile eingesetzt, die einen vertrauenswürdigen Client erfordern.

Im Rahmen einer Analyse des CyRC zur Sicherheit von Trusted Execution Environments, hat das Research-Team einen Bug identifiziert, der Informationen zu registrierten Fingerabdrücken von OnePlus 7 Pro Advanced-Benutzern offenlegt. Bei der Fingerabdruckerkennung auf TrustZone wirken bekannte und unbekannte Softwarekomponenten zusammen, um die Erkennung überhaupt erst zu ermöglichen. Die Analyse zeigt, wie diese Elemente im Einzelnen zusammenarbeiten und wo sie angreifbar sind. 

Eine kurze Geschichte der Fingerabdruckauthentifizierung auf Android

Vor Android 6

Vor dieser Version existierte kein Implementierungsstandard zur Authentifizierung per Fingerabdruck. Sicherheitsexperten fanden dann sehr schnell Mittel und Wege, um Images von Fingerabdrücken zu extrahieren. Damit waren die Forscher in der Lage, die auf den Geräten gespeicherten Referenzen zu manipulieren. Diese dienen zur Überprüfung der Authentifizierung. Ein Beispiel ist die inzwischen berühmt gewordene Black Hat-Diskussion zu den unsicheren Authentifizierungsmechanismen für Fingerabdrücke bei den führenden Android-Smartphone-Anbieter. Diese Art der Implementierung gefährdete persönliche biometrische Daten und schadete potenziell Millionen von Benutzern. 

Nach Android 6

Ab Android 6 griff Google ein und legte in seinem „Compatibility Definition Document“ eine Reihe von Anforderungen für die Authentifizierung per Fingerabdruck fest. Diese Anforderungen wurden seitdem ständig erweitert und erfassen inzwischen eine breite Gruppe von biometrischen Sensoren.

Dabei besteht der standardisierte Ansatz darin, alle sensiblen Vorgänge mit biometrischem Material in einem sogenannten Trusted Execution Environment auszuführen. Gemäß dieser Spezifikation darf die Kommunikation mit der Fingerabdruck-Hardware (Sensor) nur von einer CPU aus erfolgen, die im sicheren Modus läuft. Dies würde gewährleisten, dass man über das Android-Betriebssystem (Rich Execution Environment, REE) nicht auf den Sensor selbst zugreifen kann, selbst auf einem gerooteten Gerät nicht. 

Aber wie kann überhaupt etwas sicher sein, wenn es sich um ein gerootetes Gerät handelt?

Wenn Sie ein Android-Gerät „rooten“, bedeutet das normalerweise, dass Sie den Bootloader entsperren und Änderungen an einer oder mehreren Partitionen im Flash-Speicher vornehmen. Mit diesen Änderungen erweitern Sie Ihre Laufzeit-Berechtigungen auf „Root“. 

„Entsperren des Bootloaders“ ist jedoch kein ganz präziser Begriff. Das Booten eines Android-Geräts folgt vergleichsweise lose dem ARM Trusted Firmware-Modell, das sich aus einer Reihe von Boot-Stufen zusammensetzt. Der Begriff „Entsperren des Bootloaders“ bezieht sich normalerweise auf die allerletzte Stufe in diesem Prozess, bei dem die Trusted World des Geräts vor dem Booten des Android-OS-Images überprüft wird (obwohl der Ausdruck selbst auf jede Bootloader-Stufe auf jedem System angewendet werden kann). Die TEE (Trusted Execution Environment (TEE) wird vor dieser Stufe gebootet.

Die Sicherheitsgrenze liegt in den ARM-CPUs, die auf verschiedenen Exception Levels (ELs) und in unterschiedlichen Sicherheitszuständen laufen. Es handelt sich dabei um eine Erweiterung desselben Mechanismus, der den Kernelraum vom Benutzerraum trennt. Die TEE läuft dabei gegenüber dem Kernel des Android-Betriebssystems auf einer privilegierten Ebene. REE kann nicht auf den TEE-Speicher zugreifen, die gesamte Kommunikation erfolgt über Secure Monitor Calls des Android OS Kernel. 

Wenn man den Late-Stage-Bootloader entsperrt (der das Android-Betriebssystem startet), heißt das nicht, dass automatisch auch der Early-Stage-Bootloader, der das TEE startet, entsperrt wird. Dadurch bleibt das TEE selbst dann sicher, wenn das Android-Betriebssystem durch „Rooting“ kompromittiert wird. Eine Tatsache, die sich Content-Protection-Lösungen (DRMs), mobile Zahlungssysteme, biometrische Authentifizierung und hardwaregestützte Krypto-APIs zunutze machen.

In seinem CDD legt Google fest, welche Daten mit TEE geschützt und welche Aktionen durchgeführt werden sollten, wenn es um biometrische Authentifizierung geht. Es ist folglich das TEE, das Ihre Fingerabdrücke sicher speichern sollte, unabhängig davon, ob Sie Ihr Gerät „gerootet“ haben.

Fixing 

Das implementierte Fixing war vergleichsweise simpel: Der Befehlshandler für ID 17 wurde aus dem Produktions-Trustlet entfernt. Das bedeutet, alle REE-Aufrufe an goodix :: SZCustomizedProductTest :: factoryCaptureImage schlagen zukünftig fehl.

Der Aufbau sensibler Funktionen mit TEEs ist ein ausgeklügelter Prozess, an dem verschiedene Anbieter beteiligt sind und der ein umfangreiches Wissen sowohl auf Hardware- wie Softwareseite voraussetzt. Die Integration mehrerer SDKs ist immer eine Herausforderung. SDKs können Komponenten auf der REE- undder TEE-Seite enthalten. Diese Tatsache macht es ausgesprochen schwierig solche Nischenfehler aufzudecken und zu beheben. OnePlus hat hier vorbildlich gehandelt. 

Im kompletten Beitrag finden Sie weitere technische Detailinfos zum Innenleben von Trustlets, dazu, wie die verschiedenen Komponenten im Sinne einer vertrauenswürdigen Umgebung zusammenwirken und wie diese Umgebungen potenziell angreifbar ist. 

Zeitleiste

• 10. Juli 2019: Berater von Synopsys decken das Problem auf
• 14. August 2019 Synopsys schaltete US-CERT ein
• 7. Oktober 2019: Synopsys schaltete OnePlus ein
• 13. November 2019: Berater von Synopsys testen einen Hersteller-Patch und bestätigen die Problemlösung
• 7. Januar 2020: OnePlus veröffentlicht das Firmware Update
• 12. April 2020: Synopsys veröffentlicht Advisory

www.synopsys.com