Angriffe gegen Android können unterschiedlichste Formen annehmen.

Foto: Andreas Proschofsky / STANDARD

Viel wurde in den letzten Monaten über die Effektivität der iPhone-Verschlüsselung diskutiert. Das Wissen über den Aufbau der Android-Verschlüsselung – und dessen Effektivität – hielt sich bisher hingegen in engen Grenzen. Der israelische Sicherheitsforscher Gal Beniamini bringt nun etwas Licht in die Angelegenheit, und übt dabei auch Kritik an der aktuellen Implementierung.

Aufbau

Wie Apple beim iPhone verlässt sich auch Google nicht alleine auf die Qualität des Nutzerpassworts zur Verschlüsselung der Daten. Doch wo Apple einen fix in der Hardware gespeicherten Schlüssel heranzieht, um die Verschlüsselung zu stärken, hat Google einen anderen Weg gewählt. Zwar gibt es hier unter dem Namen "SHK" ebenfalls einen gerätespezifischen Schlüssel, da dieser aber auch für andere Aufgaben genutzt wird – etwa das Prüfen von Signaturen – haben viele Programme darauf Zugriff, für eine effektive Datenverschlüsselung wäre die direkte Nutzung des SHK also nutzlos. Also wird bei Android basierend auf dem SHK noch einmal ein eigener Schlüssel erstellt, der in einem eigens isolierten Bereich aktueller ARM-Prozessoren – der TrustZone – gespeichert wird. Dabei handelt es sich um eine Art Computer im Computer, der extra für solche sensiblen Aufgaben entwickelt wurde, und mit einem eigenen Betriebssystem isoliert von Android läuft.

Unterwanderung

Das Problem dabei: Findet ein Angreifer einen Weg in die TrustZone einzubrechen, hat er natürlich auch Zugriff auf diesen Softwareschlüssel. Genau dies war auch der Anlass für den Blogeintrag von Beniamini, sind doch in den letzten Monaten gleich zwei solcher Bugs bekannt geworden, mit denen die Qualcomm-Implementation der TrustZone unterwandert werden kann. Einen davon hat Google im Jänner bereinigt, einen anderen mit dem Mai-Sicherheits-Update. Bei aktuellen Nexus-Geräten ist diese Gefahr also derzeit nicht mehr akut, bei den Geräten anderer Hersteller sieht es natürlich oft weniger erfreulich mit der Auslieferung von Sicherheitsupdates aus.

Downgrade?

Beniamini spekuliert in seinem Beitrag aber noch mit einer anderen Angriffsvariante, nämlich mit der Möglichkeit, dass der Angreifer ein Downgrade der Systemsoftware durchführt. Dies ist allerdings im Auslieferungszustand aktuelle Android-Geräte nicht so ohne weiteres möglich. Muss davor doch zuerst (so überhaupt möglich) der Bootloader entsperrt werden, und so etwas wird etwa bei Nexus-Geräten nur zugelassen, wenn es der Gerätebesitzer in den Entwicklereinstellungen explizit aktiviert. Zumindest ist dies aber eine weitere Erinnerung daran, warum von der dauerhaften Entsperrung des Bootloaders aus einer Sicherheitsperspektive dringend abzuraten ist.

Alle relativ

Erwähnt sei, dass ein solcher Angriff nicht umgehend eine Entschlüsselung der Daten zur Folge hat, viel mehr wird hier eben "nur" der zusätzliche Schutz durch den TrustZone-Schlüssel entfernt. Ist diese Hürde genommen, steht und fällt also auch bei so einem Angriff dann wieder alles mit der Qualität der eigenen Passphrase, die als letzte Ebene der Verteidigung aufrecht bleibt. Wer hier aber nur einen vierstelligen Zahlencode gewählt hat, sollte sich keine großen Illusionen über die verbliebene Sicherheit machen, so etwas lässt sich mit der nötigen Rechenpower innerhalb weniger Minuten knacken. (Andreas Proschofsky, 3.7.2016)