Suche
Neues vom Androiden-Planeten

Ganz im Zeichen der APIs und ein bisschen auch der Sicherheit – unser Planet Android

Carina Schipper

Diese Woche hat das Androiden-Universum vor allem ein Schlagwort beherrscht: API. Mal in Kombination mit Sicherheit, mal mit Missbrauchspotenzial oder mit Google Play, am Thema Schnittstellen ist niemand vorbeigekommen. Zusätzlich haben wir dann auch noch einen Blick auf manipulationssichere Hardware geworfen.

10 Todsünden für Entwickler in Sachen SafetyNet Attestation API

Das SafetyNet Attestation API dient Entwicklern dazu, die Sicherheit und Kompatibilität der Android-Umgebungen, in denen ihre Apps laufen, einzuschätzen. 2015 erblickte das API das Licht der Welt und hat sich seitdem weiterentwickelt. Grundsätzlich ist es nützlich, allerdings lauern wie bei jedem API im Kontext von Sicherheit einige Fallen, in die Entwickler tappen können. Das SafetyNet Attestation API kann Entwickler in Versuchung führen, instabile Systeme oder schlimmstenfalls ein falsches Sicherheitsgefühl zu entwickeln. Oscar Rodriguez hat auf dem Android Developers Blog zehn Todsünden für Programmierer zusammengefasst, die wirklich niemand begehen sollte. Dazu zählt beispielsweise, sich einfach keinen API Key zu besorgen, eine veraltete Version zu benutzen, oder die Ergebnisse nicht auf dem Server zu testen. Auch Nonce (use only once) nicht korrekt zu verwenden oder den Test Attestation Verification Service für die Produktion einzusetzen ist gefährlich. Weder Nonce, noch Zeitstempel, APK-Namen und Hashes zu überprüfen, kann sich ebenfalls als fataler Fehler erweisen.

Neue Play Games Service APIs, wir kommen!

In Version 11.6.0 des Google Play Service SDKs stellt der Konzern aus Mountain View eine grundlegende Änderung in der Struktur der APIs vor. Ab sofort betrachtet Google die GoogleApiClient-Klasse als veraltet. Daneben führten die Entwickler eine entkoppelte Sammlung von Feature-spezifischen API-Clients ein. Das senkt die Zahl der für den Zugriff auf die Play Games Service APIs erforderlichen Textbausteine. Natürlich ändert Google die APIs nicht einfach so, die Ziele lauten beispielsweise mehr Benutzerfreundlichkeit, Thread-Sicherheit und Speichereffizienz. Wie weithin bekannt sein dürfte, liefert die Developer Documentation zuverlässig Informationen zu den neuen APIs.

Auf den ersten Blick wirkt es, als habe Google ganz schön viel umgekrempelt. Der Entwickler sollte aber deshalb keinesfalls sofort in Panik verfallen. Google verspricht, die Verwendung der Play Service API-Clients sei einfach und schaffe mehr Ordnung im Code. Die API-Clients lassen sich auf drei Arten verwenden. Die Authentifizierung funktioniert ab sofort explizit über den Google-Sign-In Client. Daneben konvertiert der Entwickler alle statischen Methodenaufrufe Games.category, um die korrespondierenden API-Client-Methoden zu benutzen. Dazu gehört auch gehört auch PendingResult Usages zu konvertieren, um die Task-Klasse einsetzen zu können. Punkt drei besteht darin, dass die Handhabung von Multiplayer-Einladungen nun explizit über die rundenbasierten und Echtzeit-Multiplayer-API-Clients erfolgt. Da GoogleApiClient nicht mehr verwendet wird, gibt es keinen Zugriff auf das Objekt connection hint, das Multiplayer-Einladungen enthält. Der Zugriff auf die Einladung funktioniert über einen expliziten Methodenaufruf.

Wer mehr über die neuen APIs erfahren möchte, der findet weitere Informationen auf dem Google Developers Blog.

Accessibility Services API: So nicht, Freunde!

Eigentlich ist die Accessibility Services API in Googles Play Store dazu gedacht, Barrieren für Menschen mit Behinderung aus dem Weg zu räumen. Leider schützt das das API nur nicht vor Missbrauch. Viele Apps betreiben bei der Schnittstelle kurzerhand ein bisschen Zweckentfremdung, um den Horizont ihrer Möglichkeiten zu erweitern. Ohne die Accessibility Services könnte der Passwort-Verwalter LastPass seine Dienste beispielsweise gar nicht erst umsetzen. Andere Entwickler nutzen die Schnittstelle, um mit fremden Apps zu interagieren. Hier ist das Missbrauchspotenzial ziemlich offensichtlich. Nutzereingaben lassen sich beispielsweise aufzeichnen oder fälschen. So viele zum Teil schon wirklich kriminelle Möglichkeiten sind Google jetzt eindeutig zu viel. Der Konzern kündigt für die nächsten 30 Tage eine großangelegte Aufräumaktion im Play Store an. Wer nicht absolut unmissverständlich in der App-Beschreibung erklären kann, wie Menschen mit Behinderung von dem Einsatz der Accessibility Services in der jeweiligen App profitieren, bekommt Ärger. Entwickler, die sich nicht an diese Richtlinie halten, müssen sich darauf gefasst machen, mitsamt ihrer App nach der 30-Tage-Frist einfach aus dem Play Store zu fliegen. Das klingt, als zöge Google in Sachen Accessibility Services wirklich harte Saiten auf. Eigentlich existiert nämlich bereits eine Regelung für den verantwortlichen Einsatz der Schnittstelle. Man könnte Google natürlich an dieser Stelle vorwerfen, sie bisher nicht rigoros genug bzw. kaum durchgesetzt zu haben. Ein klein wenig Wahrheit steckt in diesem Vorwurf, allerdings sollte die Tatsache, dass Missbrauch wenig geahndet wird, nie eine Einladung sein, ihn zu begehen.

Achtung, könnte Vorbildfunktion übernehmen

Googles Pixel 2 setzt in Sachen Sicherheit nicht allein auf Software-seitigen Schutz. Das Android-Smartphone wird mit einem dezidierten Hardware-Sicherheitsmodul ausgeliefert. Es soll physische Angriffe abwehren. Das Hardware-Modul kümmert sich um die Überprüfung des Sperrbildschirmcodes und verteidigt den Sperrbildschirm besser als nur Software. In Sachen Sicherheit spielt der Sperrbildschirm eine gar nicht mal so profane Rolle. Seine Aktivierung lässt nicht nur neugierige Blicke ins Leere laufen, er verhindert neben Gelegenheitsdiebstahl von Daten auch raffiniertere Angriffe.

Eine ganze Reihe von Android-Phones und so auch die Pixel-Modelle verwenden den Entsperrcode ihres Besitzers, um aus ihm den Schlüssel abzuleiten, der zum Einsatz kommt, um dessen Daten zu verschlüsseln. Bevor ein Nutzer sein Handy nach einem Neustart zum ersten Mal entsperrt, kann ein Angreifer den Schlüssel (und damit auch seine Daten) nicht wiederherstellen, ohne vorher dessen Passwort zu kennen. Zum Schutz vor Brute-Force-Angriffen auf das Passwort überprüfen Geräte mit Android 7.0+ die Eingabeversuche in einer sicheren Umgebung. Das begrenzt die Anzahl der möglichen Rätselrateversuche. Erst wenn die sichere Umgebung das Passwort des Smartphonebesitzers erfolgreich verifiziert hat, enthüllt sie sein Gerät und ein benutzerspezifisches Geheimnis, das zur Ableitung des Schlüssels zur Festplattenverschlüsselung verwendet wird.

Manipulationsversuche von außen erkennen und abwehren

 

Manipulationssichere Hardware ist vom Rest des Systems getrennt. Quelle: Android Developers Blog

Manipulationssichere Hardware besteht aus einem Chip, der vom System on a Chip (SoC) getrennt ist. Er enthält seinen eigenen Flash, RAM und andere Ressourcen in einem Paket. Er kann seine eigene Ausführung völlig kontrollieren. Der Chip kann Angriffe von außen aufspüren und sie abwehren. Er ist in allen Pixel-Phones der zweiten Generation verbaut.

Der Planet Android ist bunt, dreht sich schnell, entwickelt sich ständig weiter. Wir bleiben neugierig und beobachten ihn weiter – bis bald!

Geschrieben von
Carina Schipper
Carina Schipper
Carina Schipper ist seit 2017 Redakteurin beim Java Magazin, Business Technology und JAXenter. Sie hat Germanistik und Europäische Ethnologie / Volkskunde an der Julius-Maximilians-Universität Würzburg studiert.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.