In Android 17 wird ein eingebauter kryptografischer Verifizierungsmechanismus für das Betriebssystem erscheinen, der es dem Benutzer ermöglicht, die offizielle Zertifizierung der Google-Plattform zu bestätigen und nicht autorisierte Firmware zu erkennen.
Google hat für das Betriebssystem Android 17 eine neue Sicherheitskomponente angekündigt: ein Modul zur tiefgehenden Integritätsprüfung des Systemabbilds. Das Werkzeug dient der Erkennung gefälschter Builds, die äußerlich legitimes Android imitieren, aber tatsächlich nicht die Zertifizierung der Google Compatibility Test Suite (CTS) durchlaufen haben. Solche Modifikationen können im Hintergrund Daten abfangen, Systemaufrufe ersetzen und das Anwendungsisolationsmodell verletzen.
Auf dem Verifizierungsbildschirm werden mindestens drei technische Parameter angezeigt: der Status des Play Protect-Dienstes (letzte Überprüfung von Apps und Kernel), der Zustand des Bootloaders mit Angabe seiner Entsperrung sowie die genaue Build-Nummer des Betriebssystems mit der Prüfsumme des Zertifikats. Zusätzlich erwähnt Google eine Funktion zur Kreuzverifizierung über ein anderes vertrauenswürdiges Gerät, jedoch sind die Methode zur Übertragung der Anfrage und der kryptografische Vergleich der Ergebnisse noch nicht im Detail beschrieben.
Die Funktion wird auf Smartphones der Pixel 10-Reihe gleichzeitig mit der Veröffentlichung der stabilen Version von Android 17 verfügbar sein. Hersteller wie Samsung, Xiaomi und OnePlus werden diesen Mechanismus in ihre offizielle Firmware integrieren können, unter der Bedingung, dass das Root of Trust im hardwarebasierten Schlüsselspeicher des Geräts erhalten bleibt. Die Anforderung an die Anbieter ist die Einhaltung der Google Mobile Services (GMS)-Richtlinien. Der Preis von Geräten mit Android 17 bleibt im marktüblichen Bereich (zwischen 400 und 1400 Dollar), wobei die Zertifizierung keine zusätzlichen Lizenzgebühren für diese Funktion mit sich bringt.
Beim Start von Android 17 ruft das System ein isoliertes Modul in TrustZone (oder in einem separaten Sicherheits-Coprozessor) auf, das einen unveränderlichen, in den Efuse des Boot-ROMs eingebrannten Schlüssel ausliest. Anschließend fordert das Modul von einem entfernten Google-Server eine signierte, aktuelle Liste erlaubter Hashes der Systempartitionen an. Der Bootloader überprüft die Signatur der Zertifikatskette, beginnend mit der Google-Wurzel im UEFI. Wenn die aktuelle Firmware nicht in der verifizierten Liste enthalten ist, gibt die Benachrichtigungsschnittstelle eine Warnung aus und kann die Arbeit mit Zahlungs-APIs (Sensitive Transaction API) einschränken. Die Kreuzprüfung mit einem anderen Gerät wird wahrscheinlich eine sichere Bluetooth-Verbindung mit Austausch signierter Integritätstickets verwenden.
Diese Lösung verwandelt die OS-Überprüfung von einem passiven Indikator in ein aktives Element der Vertrauenskette auf Runtime-Ebene. Die wichtigste technische Erschwerung ist die Bindung der Attestation an eine bestimmte Geräteinstanz über eine eindeutige Kennung, die aus den PUFs (physikalisch nicht klonbare Funktion) des Chips generiert wird. Dies ermöglicht es dem Google-Server nicht nur, die Authentizität des Builds zu bestätigen, sondern auch geklonte Schlüssel zu erkennen. Sollte ein Angreifer jedoch in der Produktionsphase die Kontrolle über das Boot-ROM erlangen (Hardware-Hintertür), kann keine Softwareprüfung mehr helfen, was den Wert der Funktion für Geräte aus nicht vertrauenswürdigen Lieferketten mindert.