TrustZone: Design-Problem in Androids Verschlüsselung

Grundsätzlich wird für die Verschlüsselung der Daten auf Smartphones erst einmal der Zugangscode des Nutzers verwendet. Dieser ist aber typischerweise recht kurz, meisten vier oder sechs Ziffern, die man auch schnell eingeben kann. So oft, wie man täglich sein Smartphone entsperrt, möchte man nur ungern kryptische – aber sichere – Passwörter eingeben. Nachteil dieser kurzen Codes: sie sind für etwas leistungsfähigere Hardware recht schnell über eine Brute-Force-Attacke zu knacken: Es werden einfach der Reihe nach alle möglichen Kombinationen durchprobiert.

Um die Verschlüsselung also weiter zu verbessern, wird dieser Passcode sowohl bei iOS als auch bei Android mit einem eindeutigen Hardware-Schlüssel kombiniert. Dieser Hardware-Key ist für jedes Gerät eindeutig und entsprechend lang, so dass die Verschlüsselung als sicher gelten kann. Und so lange dieser Hardware-Key sicher in der jeweiligen Hardware steckt, kann man auch keine externe Hardware, wie zum Beispiel einen PC oder sogar spezialisierte Cracking-Systeme verwenden, um den Passcode zu knacken. Schließlich muss man in diesem Fall jede mögliche Kombination noch selbst auf dem Gerät eingeben.

Das führt dann zu Verzögerungen bei jeder Falscheingabe und unter Umständen auch nach einer bestimmten Zahl an Falscheingaben zur Löschung des ganzen Geräts. Übrigens: Diese Sperren waren bei iPhones – wie dem berühmten iPhone 5C – ohne Touch ID noch in der Software umgesetzt und kann daher unter bestimmten Voraussetzungen umgangen werden.

Die Sicherheit der Verschlüsselung steht und fällt also am Ende mit der Sicherheit des Hardware-Keys. Während dieser bei iOS-Geräten fest in der Hardware verankert und nicht auszulesen ist, wird dieser bei Android-Geräten in der sog. „TrustZone“ gespeichert und kann auch von dort ausgelesen werden. Dafür gibt es zwei Möglichkeiten: Entweder durch entsprechend signierte Software des Herstellers dieser TrustZone oder eben durch Sicherheitslücken in der Software.

Sicherheitslücken sind natürlich immer möglich, das steht außer Frage. Und natürlich wäre es auch möglich, dass es irgendwo bei Apple eine Lücke gibt, durch die die Hardware-UUID (der Key) ausgelesen werden könnte, auch wenn eine solche Lücke natürlich nicht ganz so wahrscheinlich ist, wenn es gar nicht erst per Software möglich ist, diesen Key auszulesen. Es ist statistisch wahrscheinlicher eine Lücke in einem System zu finden, das einen Zugriff unter bestimmten Bedingungen erlaubt, als in einem System, das gar nicht erst einen Zugriff ermöglicht.

Und das ist das Design-Problem in der Verschlüsselung unter Android: Der Hersteller kann auf den verwendeten Hardware-Key mit entsprechender Software zugreifen und ihn auslesen, damit kann man den Vorgang der Entschlüsselung eines Geräts vom Gerät selber trennen und zum Beispiel auf eine spezialisierte Hardware auslagern. Gal Beniamini zeigt in seinem Posting sehr detailliert wie das funktionieren kann. Die technischen Infos sind durchaus spannend – wenn man sich dafür interessiert.

Dabei ist natürlich eine Sache, dass ein Angreifer über eine Sicherheitslücke – von denen es schon welche gab – Zugriff auf den Hardware-Keys bekommt, eine ganz andere Sache ist es aber, wenn ein staatlich legitimierter Angreifer per richterlicher Verfügung o. ä. über den Hersteller der Hardware an den Key gelangt oder sogar eine Software bekommt, um die Keys selbst auszulesen. Und das ist das Design-Problem an der Verschlüsselung – zumindest aus Sicht eines Nutzers, der die maximale Sicherheit für die Verschlüsselung will: Der Hardware-Key ist unter bestimmten Voraussetzungen nicht an die Hardware gebunden, sondern kann ausgelesen und auf anderer Hardware für einen Angriff auf die Verschlüsselung verwendet werden.

Gal Beniamini fasst die Probleme in vier Punkten zusammen:

• The key derivation is not hardware bound
• OEMs can comply with law enforcement to break Full Disk Encryption
• Patching TrustZone vulnerabilities does not necessarily protect you from this issue
• Android FDE is only as strong as the TrustZone kernel or KeyMaster

Aus Sicht von Behörden mit einem Interesse am Zugriff auf solche Daten, handelt es sich dabei natürlich nicht um eine Design-Schwäche der Verschlüsselung, sondern um einen Vorteil gegenüber einem Hardware-Key, der nicht extrahiert werden kann. Ohne darüber diskutieren zu wollen, ob es sich ggf. um ein legitimes Interesse an den Daten auf solchen Geräten handelt, sagt uns die Erfahrung, dass solche Hintertüren – und nichts anderes ist die Möglichkeit über eine passende Software des OEM an den Hardware-Key zu kommen – mit sehr großer Wahrscheinlichkeit früher oder später auch von Menschen benutzt werden, für die diese nicht gedacht waren.

Damit ist jetzt die Android-Verschlüsselung nicht wirkungslos, das ist sicher nicht der Fall, aber für jemanden, der Zugriff auf das jeweilige Gerät hat, ist es ein Stück leichter, die Verschlüsselung zu knacken, als es das bei einem iPhone ist. Wenn es nur um Strafverfolger und Geheimdienste ginge, dann könnten sich mehr als 99% aller Smartphone-Benutzer entspannt zurücklehnen, da sich aus der Richtung kaum einer für die Inhalte ihrer Geräte interessieren dürften. Aber die Daten, die wir täglich mit uns rumtragen, sind natürlich auch für andere Menschen von Interesse und diese Menschen werden sich bestimmt bereits intensiv mit dieser Möglichkeit eines Angriffs auf die Verschlüsselung beschäftigen.

via Heise Security