Googles Remote Key Provisioning wird in Android 13 obligatorisch sein, aber es ist ein kompliziertes Thema. Hier erfahren Sie, was das für Sie bedeuten wird.
Der Schlüsselnachweis von Android ist das Rückgrat vieler vertrauenswürdiger Dienste auf unseren Smartphones, darunter SafetyNet, Digital Car Key und die Identity Credential API. Es ist seit Android 8 Oreo als Teil von Android erforderlich und erforderte einen Root-Schlüssel, der werkseitig auf einem Gerät installiert wurde. Die Bereitstellung dieser Schlüssel erforderte höchste Geheimhaltung seitens des Herstellers, und wenn ein Schlüssel durchgesickert wäre, würde das bedeuten, dass der Schlüssel widerrufen werden müsste. Dies würde dazu führen, dass ein Verbraucher keinen dieser vertrauenswürdigen Dienste nutzen kann, was bedauerlich wäre, wenn es jemals eine Schwachstelle geben sollte, die ihn offenlegen könnte. Remote Key Provisioning, das in vorgeschrieben wird Android 13zielt darauf ab, dieses Problem zu lösen.
Die Komponenten, aus denen die aktuelle Vertrauenskette auf Android besteht
Bevor erklärt wird, wie das neue System funktioniert, ist es wichtig, einen Kontext dazu bereitzustellen, wie das alt (und für viele Geräte immer noch vorhanden) System funktioniert. Heutzutage verwenden viele Telefone eine hardwaregestützte Schlüsselbescheinigung, die Ihnen vielleicht als Sargnagel für jede Art von SafetyNet-Umgehung bekannt ist. Es gibt mehrere Konzepte, deren Verständnis für den aktuellen Stand der Schlüsselbescheinigung wichtig ist.
Es ist eine Kombination dieser Konzepte, die sicherstellt, dass ein Entwickler darauf vertrauen kann, dass ein Gerät nicht manipuliert wurde, und vertrauliche Informationen im TEE verarbeiten kann.
Vertrauenswürdige Ausführungsumgebung
Eine Trusted Execution Environment (TEE) ist eine sichere Region auf dem SoC, die für die Verarbeitung kritischer Daten verwendet wird. TEE ist auf Geräten mit Android 8 Oreo und höher obligatorisch, d. h. jedes aktuelle Smartphone verfügt über TEE. Alles, was nicht im TEE enthalten ist, gilt als „nicht vertrauenswürdig“ und kann nur verschlüsselte Inhalte sehen. Beispielsweise werden DRM-geschützte Inhalte mit Schlüsseln verschlüsselt, auf die nur Software zugreifen kann, die auf dem TEE ausgeführt wird. Der Hauptprozessor kann nur einen Stream verschlüsselter Inhalte sehen, wohingegen der Inhalt vom TEE entschlüsselt und dann dem Benutzer angezeigt werden kann.
ARM Trustzone
Trusty ist ein sicheres Betriebssystem, das ein TEE auf Android bereitstellt und auf ARM-Systemen die Trustzone von ARM nutzt. Trusty wird auf demselben Prozessor wie das primäre Betriebssystem ausgeführt und hat Zugriff auf die volle Leistung des Geräts, ist jedoch vollständig vom Rest des Telefons isoliert. Trusty besteht aus Folgendem:
- Ein kleiner Betriebssystemkernel, abgeleitet von Kleiner Kernel
- Ein Linux-Kernel-Treiber zum Übertragen von Daten zwischen der sicheren Umgebung und Android
- Eine Android-Userspace-Bibliothek zur Kommunikation mit vertrauenswürdigen Anwendungen (d. h. sicheren Aufgaben/Diensten) über den Kernel-Treiber
Der Vorteil gegenüber proprietären TEE-Systemen besteht darin, dass diese TEE-Systeme kostspielig sein können und außerdem zu Instabilität im Android-Ökosystem führen. Trusty wird Partner-OEMs von Google kostenlos zur Verfügung gestellt und ist Open Source. Android unterstützt andere TEE-Systeme, aber Trusty ist dasjenige, das Google am meisten vorantreibt.
Geldschrank
StrongBox-Geräte sind vollständig separate, speziell entwickelte und zertifizierte sichere CPUs. Dazu können eingebettete Secure Elements (eSE) oder eine On-SoC Secure Processing Unit (SPU) gehören. Google sagt, dass StrongBox derzeit „dringend empfohlen“ wird, mit Geräten zu starten, die damit ausgestattet sind Android 12 (gemäß Kompatibilitätsdefinitionsdokument), da dies wahrscheinlich in einer zukünftigen Android-Version eine Anforderung wird. Es handelt sich im Wesentlichen um eine strengere Implementierung eines hardwaregestützten Schlüsselspeichers und kann zusammen mit TrustZone implementiert werden. Ein Beispiel für eine Implementierung von StrongBox ist der Titan M-Chip in Pixel-Smartphones. Nicht viele Telefone nutzen StrongBox und die meisten nutzen die Trustzone von ARM.
Schlüsselmeister TA
Keymaster Trusted Application (TA) ist der sichere Keymaster, der alle Keystore-Vorgänge verwaltet und ausführt. Es kann beispielsweise auf der TrustZone von ARM ausgeführt werden.
Wie sich die Schlüsselbescheinigung mit Android 12 und Android 13 ändert
Wird ein Schlüssel auf einem Android-Smartphone offengelegt, ist Google verpflichtet, ihn zu widerrufen. Dies stellt ein Problem für jedes Gerät dar, in das werkseitig ein Schlüssel eingefügt wurde. Jede Art von Leck, das den Schlüssel preisgibt, würde bedeuten, dass Benutzer nicht auf bestimmte geschützte Inhalte zugreifen könnten. Dazu kann sogar der Entzug des Zugangs zu Diensten wie Google Pay gehören, auf den sich viele Menschen verlassen. Dies ist für Verbraucher bedauerlich, denn ohne die Reparatur Ihres Telefons durch einen Hersteller hätten Sie keine Möglichkeit, es selbst zu reparieren.
Geben Sie Remote Key Provisioning ein. Ab Android 12 ersetzt Google die werksseitige Bereitstellung privater Schlüssel durch eine Kombination aus Extraktion öffentlicher Schlüssel im Werk und Bereitstellung von Over-the-Air-Zertifikaten mit kurzer Lebensdauer Zertifikate. Dieses Schema wird in Android 13 erforderlich sein und bietet einige Vorteile. Erstens wird dadurch verhindert, dass OEMs und ODMs die Schlüsselgeheimhaltung in einer Fabrik verwalten müssen. Zweitens ermöglicht es die Wiederherstellung von Geräten, falls ihre Schlüssel kompromittiert werden, was bedeutet, dass Verbraucher den Zugriff auf geschützte Dienste nicht für immer verlieren. Anstatt nun ein Zertifikat zu verwenden, das mithilfe eines Schlüssels berechnet wird, der sich auf dem Gerät befindet und durch ein Leck durchgesickert sein könnte Sicherheitslücke wird bei jedem Dienst, der eine Bescheinigung erfordert, ein temporäres Zertifikat von Google angefordert gebraucht.
Die Funktionsweise ist ganz einfach. Von jedem Gerät wird ein eindeutiges, statisches Schlüsselpaar generiert. Der öffentliche Teil dieses Schlüsselpaars wird vom OEM in seiner Fabrik extrahiert und an die Server von Google übermittelt. Dort dienen sie als Vertrauensbasis für die spätere Bereitstellung. Der private Schlüssel verlässt niemals die sichere Umgebung, in der er generiert wird.
Wenn ein Gerät zum ersten Mal eine Verbindung zum Internet herstellt, generiert es eine Zertifikatsignierungsanforderung für Schlüssel, die es generiert hat, und signieren es mit dem privaten Schlüssel, der dem im gesammelten öffentlichen Schlüssel entspricht Fabrik. Die Back-End-Server von Google überprüfen die Authentizität der Anfrage, signieren dann die öffentlichen Schlüssel und geben die Zertifikatsketten zurück. Der Keystore auf dem Gerät speichert diese Zertifikatsketten dann und weist sie Apps zu, wenn eine Bescheinigung angefordert wird. Dies kann alles sein, von Google Pay bis Pokemon Go.
Diese genaue Zertifikatsanforderungskette wird regelmäßig nach Ablauf der Zertifikate oder Erschöpfung des aktuellen Schlüsselvorrats stattfinden. Jede Anwendung erhält einen anderen Attestierungsschlüssel und die Schlüssel selbst werden regelmäßig rotiert, wodurch die Privatsphäre gewährleistet ist. Darüber hinaus sind die Back-End-Server von Google so segmentiert, dass der Server, der den öffentlichen Schlüssel des Geräts überprüft, die angehängten Nachweisschlüssel nicht sieht. Dies bedeutet, dass es Google nicht möglich ist, Attestierungsschlüssel dem jeweiligen Gerät zuzuordnen, das sie angefordert hat.
Endnutzer werden keine Änderungen bemerken, Entwickler müssen laut Google jedoch auf Folgendes achten.
- Struktur der Zertifikatskette
- Aufgrund der Art unserer neuen Online-Bereitstellungsinfrastruktur ist die Kettenlänge länger als zuvor und kann sich ändern.
- Wurzel des Vertrauens
- Der Vertrauensstamm wird schließlich vom aktuellen RSA-Schlüssel auf einen ECDSA-Schlüssel aktualisiert.
- Einstellung der RSA-Bescheinigung
- Alle von KeyMint generierten und attestierten Schlüssel werden mit einem ECDSA-Schlüssel und der entsprechenden Zertifikatskette signiert. Zuvor wurden asymmetrische Schlüssel durch ihren entsprechenden Algorithmus signiert.
- Kurzlebige Zertifikate und Attestierungsschlüssel
- Für Geräte bereitgestellte Zertifikate sind im Allgemeinen bis zu zwei Monate gültig, bevor sie ablaufen und rotiert werden.
Wir haben Google kontaktiert und gefragt, ob dies für Widevine DRM relevant ist und wie einige Pixel-Benutzer gemeldet haben, dass ihr DRM-Level durch einen gesperrten Bootloader herabgestuft wurde. Wir haben auch gefragt, ob dies jetzt als OTA-Upgrade über Google Play Services an Benutzer verteilt werden kann. Wir werden diesen Artikel auf jeden Fall aktualisieren, wenn wir etwas hören. Es ist nicht klar, welche Komponenten der aktuellen Vertrauenskette betroffen sein werden und in welcher Weise.
Quelle: Google