© Dave Broberg, 123RF

Mit viel medialem Tamtam hat Google angekündigt, Android L werde um einiges sicherer sein als seine Vorgänger – das wäre auch schon lange notwendig. Erreichen will der Hersteller das über eine Vielzahl neuer Funktionen. Hilft’s oder ist hier vor allem die PR Mutter des Gedankens?

Smartphones haben in den vergangenen Jahren einen atemberaubenden Siegeszug hingelegt, die Zahl der aktiven Geräte stieg deutlich. Längst haben die großen Hersteller Schwierigkeiten, neue Geräte am Markt tatsächlich auch erfolgreich zu positionieren, was nicht zuletzt an den kürzer gewordenen Lebenszyklen einzelner Modelle liegt – das gilt natürlich insbesondere für die mit Android laufenden Geräte, also für alles, was Googles mobiles OS einsetzt.

So versuchen die Gerätehersteller sich ihre Nischen zu schaffen – sei es durch im ersten Augenblick unsinnig wirkende Features wie 4K-Displays oder durch gute Ausstattung zum kleinen Preis. Längst ist Android kein Bastelsystem mehr, und der schlechte Ruf, der dem System in seiner Anfangszeit anhaftete, ist nunmehr insgesamt positver PR gewichen. Auch Unternehmen setzen vermehrt auf digitale Helferlein, weil sie den Alltag effizienter gestalten.

Sicherheit ohne Priorität

Ganz gleich ob privat oder im Unternehmen: Bei aller Euphorie drückt ein Thema auf die Android-Stimmung, das auch Medien zunehmend negativ auffächern: Die mangelhafte Sicherheit der Android-Devices ([1], [2]). Denn wenn Smartphones sensible Informationen von Unternehmen enthalten, ist beim Verlust der Geräte der materielle Schaden häufig das geringste Problem, viel schlimmer wiegt es, wichtige Details nicht länger im alleinigen Besitz des Unternehmens zu wissen.

Während mittlerweile fast alle Business-Notebooks mit komfortablen Funktionen zur Verschlüsselung der Festplatte daherkommen, sind vergleichbare Features bei Android-Smartphones Mangelware. Auch sonst ist es um die Sicherheit von Smartphones im Allgemeinen und Android-Telefonen im Besonderen nicht immer gut bestellt, glaubt man Medienberichten und Hackern [3].

Für Android L hat Google kaum weniger als den Totalumbau der Sicherheitsfunktionen geplant, um künftig Anwendern die Gewissheit zu bieten: Bei unserem System sind eure Daten in guten Händen. Abbildung 1 zeigt den neuen Desktop, Abbildung 2 ein bootendes Android L in der virtuellen Maschine des SDK, das auch auf der DVD dieses Magazins liegt – bereits mit Android L vorbereitet.

Abbildung 1: Der Desktop von Android L. Das neue System bringt aber auch einige Änderungen unter der Haube, doch in Sachen Sicherheit bleibt vieles eher Stückwerk.

Abbildung 2: Heute schon zum Testen bereit, auch ohne Gerät: Android L startet im SDK.

Im Hinblick auf technische Details entscheidet allerdings eben nicht die PR-Abteilung über Wohl und Wehe, sondern der harte Alltag von Admins und Informationsmanagern (in deren Bereich das Thema Sicherheit meistens fällt). Und obwohl es bisher von Android L weder einen finalen Namen noch eine fertige Version gibt, sind viele Details zur neuen Sicherheitsarchitektur bereits jetzt ans Licht der Öffentlichkeit gedrungen.

Malware satt

Die Firma Kaspersky Lab hatte bereits Ende Januar 2014 die 10-millionste Android-App schädlichen Inhalts entdeckt. Dabei listet Google Play kaum mehr als eine Million Apps. Die astronomisch hohe Zahl erklärt sich durch die Google-inoffiziellen App-Stores.

Für Sicherheitsfirmen mögen solche Zählungen ein Grund sein, die Korken knallen zu lassen, für Anwender ist die Allgegenwart übler Apps verdrießlich. Von den 350 000 einzigartigen mobilen Schädlingen und über 840 Schädlingsfamilien haben es zwischen 98 und 99 Prozent auf Android abgesehen.

Vom Linux-Magazin nach Gründen befragt, antwortet Christian Funk, Senior Virus Analyst bei Kaspersky. Er hat an der FH Ingolstadt Informatik und Informationsmanagement studiert:

“Die Umsetzung der Rechtevergabe zum Zugriff auf Schnittstellen und Anwenderinformationen ist bei Android im Prinzip gelungen. Wir sehen aber, dass sich App-Programmierer sehr häufig Zugriffsrechte auf Bereiche holen, die nichts mit der Funktion ihrer App zu tun haben. Angreifer nehmen solche freizügigen Apps, pflanzen Schadcode ein und bieten sie abseits von Google Play zum Download an.

Bisher zeigt Google keine Initiative, die Situation zu entschärfen, im Gegenteil: Android kategorisiert mittlerweile die feingranularen Rechte und legt sie dem Anwender in abstrahierter Form zur Abnahme vor. Es ist kein Wunder, dass wir das volle Repertoire an Windows-Schädlingen auch auf Android sehen: Würmer, Adware, Backdoors, Monitor, Risktools, Malicious Remote-Admin, SMS-Flooder, Adware sowie alle Trojaner: Downloader, Dropper, Fake-AV, PSW, SMS, Spy, Clicker, Banker oder Ransom.” (jk)

Samsung und Google: Gemeinsam stark?

Als Google Android L vorstellte, berichtete die Presse vor allen Dingen über die neuen Style-Richtlinien, die die kommende Android-Version auszeichnen (siehe Artikel in diesem Schwerpunkt). Das ist insofern wenig verwunderlich, als dass die Nutzer mit eben jenem Teil des Systems ja tagtäglich direkt in Kontakt kommen.

Eine andere Google-Ankündigung dürfte hingegen Firmenverantwortliche interessiert haben: Samsung hilft Google, um in der L-Version zusätzliche Sicherheit umzusetzen. Dass Google sich in Sachen Sicherheit ausgerechnet auf Samsung verlässt, ist nicht erstaunlich: Anders als die meisten anderen Hersteller von Android-Telefonen bietet Samsung schon seit einiger Zeit ein eigenes Sicherheits-Framework für Android an, das auf den Namen Knox hört ([4], Abbildung 3).

Abbildung 3: Samsungs Sicherheitsframework Knox bringt viel Neues und gute Ansätze, doch bleibt fraglich, ob auch andere Hersteller davon profitieren werden.

Was Knox kann

Knox ist in der Tat bemerkenswert, weil es viele Features bietet, die für Unternehmen von großer Bedeutung sind. Dazu gehört es auch, einen “sicheren Pfad” herzustellen, was das Ausführen von Programmen betrifft. Denn es ist völlig sinnlos, ein System mit Sicherheitsfunktionen zu versehen, wenn sich nicht gewährleisten lässt, dass jene Sicherheitsfunktionen auch tatsächlich zum Einsatz kommen anstatt unbemerkt vor sich hin zu schlummern.

Diese Überlegungen waren der Grund dafür, dass das heute sehr unbeliebte UEFI sich auf Standardcomputern durchgesetzt hat: Solange UEFI aktiviert ist, führt das Bios lediglich Betriebssysteme aus, die ein bekannter Hersteller digital signiert hat. Unbeliebt ist UEFI vorrangig deshalb, weil sich augenscheinlich eine kleine Clique gebildet hat, die digitale Signaturen oder die dafür benötigten Schlüssel herausgeben darf. Auch technisch besitzt das System – wie mittlerweile bekannt – deutliche Schwächen.

Fakt ist aber auch: Wer beweisen will, dass ein Computer so sicher ist wie beworben, muss die Authentizität der genutzten Software irgendwie garantieren. Und offensichtlich ist Samsung auf genau den gleichen Trichter gekommen, denn Knox zieht bei Android eine ähnliche Funktion ein.

Austricksen!

Ganz konkret funktioniert das bei Knox so: Damit ein Gerät einen bestimmten Kernel bootet, muss dieser entsprechend digital signiert sein. Ist er das nicht, verweigert der Bootloader kurzerhand den Start des Systems. Wer mit technischen Tricks diesen Schutz überwindet (umgangssprachlich den Bootloader also “entsperrt”), behält zwar ein funktionierendes Gerät, allerdings sorgt er auch dafür, dass eine so genannte E-Fuse (E-Sicherung) durchbrennt.

Dadurch verändert sich die Hardware des Systems irreversibel. Ein aktuelles Samsung-Handy mit entsperrtem Bootloader zeigt deshalb bei jedem Bootvorgang die Meldung »KNOX WARRANTY STATUS VOID 0x1« an – wer solch ein Handy zu Reparaturzwecken bei Samsung einreicht, braucht sich über Themen wie Garantie also keine Gedanken mehr zu machen.

Doch wäre es auch zu kurz, Knox lediglich als Samsung-Werkzeug zur Absicherung gegen unberechtigte Garantieansprüche zu betrachten. De facto könnte in künftigen Samsung-Smartphones die durchgebrannte E-Fuse nämlich auch dafür sorgen, dass aus dem teuren Smartphone ein extravaganter Briefbeschwerer würde – technisch wäre die Umwidmung schnell gemacht.

TIMA, Biometrie und Profile

Hinter Knox verstecken sich noch viel mehr Funktionen, etwa TIMA, die Trust-Zone-based Integrity Measurement Architecture [5]. Die vereint diverse Tools, die den Kernel des Systems auch zur Runtime vor Unbehagen schützen. Biometrische Authentifizierung soll unbefugten Zugriff verhindern, besonders wenn das Gerät in fremde Hände gerät. Ähnliches gilt für die Authentifizierung per Smartcard.

Dann gibt es noch die Managed Profiles: Jene trennen Businessdaten von persönlichen Informationen auf Smartphones. Der Businessbereich lässt sich separat verwalten. Während der Nutzer im privaten Teil des Profils tun und lassen kann, was er will, liegen die Businessdaten in einem abgetrennten Safe desselben Smartphones.

Alleinstellungsmerkmal

Samsung hat also ordentlich vorgelegt. Wenn Google und Samsung nun auf der Hauptentwicklerkonferenz ankündigen, in Sachen Android-Sicherheit gemeinsame Sache zu machen, sorgt das naturgemäß für Aufsehen. Nicht wenige Beobachter meldeten, Samsung helfe Google dabei, Knox direkt in Android zu integrieren. Ganz so leicht ist die Sache aber nicht.

Denn einerseits würde Samsung so ein Alleinstellungsmerkmal im Vorbeigehen allen anderen Android-Herstellern ebenfalls zur Verfügung stellen. Andererseits ist kaum denkbar, dass Google sich so eng an das Produkt von Samsung bindet – schließlich setzt Mountain View auf ein möglichst großes Ecosystem, in dem auch die Geräte anderer Hersteller mit ihren (modifizierten) Android-Systemen eine wichtige Rolle spielen.

So bleibt von der Samsung-Google-Ankündigung letztlich ein kleiner Teil übrig, nämlich die Managed Profiles. Jene sollen Android für Firmen wesentlich attraktiver machen, als es im Augenblick der Fall ist, und dabei das Thema Sicherheit umfassend abhandeln.

Weil neben Samsung nahezu jeder Android-Hersteller über eine Bootloader-Sperre verfügt, soll Android L mit der Kombination aus gesicherten System-Binaries und zentral verwalteten Profilen für Unternehmensdaten ein Maximum an Sicherheit bieten. In den Android-Einstellungen finden sich die Profile und alle anderen wenig überraschenden Sicherheitsfeatures unter »Einstellungen | Sicherheit« beziehungsweise »Settings | Security« (Abbildung 4).

Abbildung 4: Deutlich erweitert präsentieren sich die sicherheitsrelevanten Einstellungen von Android L.

Endlich: SE Linux wird Android SE

Anwendern begegnet in Android L endlich auch SE Linux ([6], [7]) in Form von Android SE [8]. Das Werkzeug, das von Desktop- und Server-Systemen bereits hinlänglich bekannt ist, nimmt eine zentrale Rolle in der Sicherheitsarchitektur von Android L ein und ist Bestandteil der Profile-Funktion, die Google aus Knox übernimmt und somit standardmäßig aktiviert.

SE Linux soll verhindern, dass Programme Funktionen ausführen, die sie nicht ausführen dürfen, und falls ein Programm sich doch mal unberechtigt Zugriff verschafft, soll es wenigstens Schlimmeres verhüten. Ein Nebeneffekt davon ist, dass das Erlangen von Rootrechten wohl deutlich schwieriger wird – was aber kein Effekt von Dauer sein wird, wenn man die Cyanogenmod-Diskussionen verfolgt [9].

Schlangenöl

Überhaupt ist bei genauerem Hinsehen zu hinterfragen, inwiefern sich jene neue Sicherheitsarchitektur bei Android L überhaupt bemerkbar machen wird – denn die elementaren Probleme, die die Sicherheit von Android-Telefonen häufig in Mitleidenschaft ziehen, geht auch Android L nicht überzeugend an.

Wie schon erwähnt sind gesperrte Bootloader nichts Neues, und wer gemein sein will, wird auch in den Managed Profiles viel von dem erkennen, was bereits existiert: Wer ein Handy per Geräterichtlinien-App einer Google-Apps-Organisation zuweist, hat aus der Ferne über das Gerät die volle Kontrolle und kann es bei Bedarf per Knopfdruck sogar ausschalten oder vollständig löschen. Einziger Unterschied scheint nach allen Berichten die Tatsache zu sein, dass die Daten innerhalb des Business-Profils separat gesichert sind. Wie zuverlässig dieser Schutz ist und wie gut er hält, wenn sich das Handy in den Händen Dritter befindet, ist momentan kaum abschätzbar.

Kaum abschätzbar ist allerdings auch, wie viele Android-Nutzer überhaupt in den Genuss der neuen Android-L-Funktionen kommen werden. Durch den sehr hohen Marktdruck hat sich bei den Herstellern der Smartphones in der Vergangenheit nämlich ein äußerst hässliches Verfahren eingebürgert: Sie versuchen sich Alleinstellungsmerkmale zu erarbeiten, indem sie ihre Android-Versionen durch besonders pfiffige Modifikationen aufpeppen.

Allerdings kostet es viel Geld, diese Modifikationen dann auf neue Android-Versionen zu portieren. Weil obendrein ständig neue Android-Smartphones auf den Markt kommen, gibt es regelmäßig für Geräte keine Updates mehr, selbst wenn diese noch nicht mal ein Jahr alt sind. Selbst Wartungsupdates zum Flicken allseits bekannter Sicherheitslücken finden den Weg zu den Nutzern nicht mehr regelmäßig. Die daraus resultierenden Probleme sind höchst kritisch, weil sie Malware überhaupt erst ein großes Einfallstor bieten.

Zwar haben Nutzer die Möglichkeit, auf Aftermarket-Firmware zu setzen; dann führen Cyanogenmod [10], Paranoid Android [11] oder Mokee [12] aus der Update-Falle. Auch diese Lösungen kommen aber bekanntlich mit unschönen Nebenwirkungen daher: Wer eine der Aftermarket-Firmwares aufspielt, führt damit jede Form von App-Verifikation ad absurdum, weil er vorher den Bootloader entsperren muss.

Außerdem ist die Installation eines entsprechenden Systems stets Bastelarbeit. Es ist kaum vorstellbar, dass sich dieser Vorgang für ein mittelgroßes oder großes Unternehmen reibungslos durchführen lässt. Das liegt auch daran, dass viele Integrationswerkzeuge der Hersteller nicht vorhanden sind, weil es sich um proprietäre Software handelt.

Echte Lösungen

Um die Sicherheit innerhalb des Android-Ökosystems zu erhöhen, wird Google mehr brauchen als ein paar Bestandteile von Knox. Ein Teil in Googles künftigem Handeln wird vermutlich sein, die Hersteller von Handys mit Android enger an die Kandare zu nehmen – oder gleich ganz zu übergehen.

Die im Juni ausgerollte Version 5.0 des Play Store beispielsweise bringt eine Funktion mit, die das Ausliefern von Sicherheitspatches ermöglicht (Dynamic Security Provider, Abbildung 5). Ganz offenbar hat man in Mountain View verstanden, dem Android-Wildwuchs Einhalt gebieten zu müssen, um das Problem langfristig zu lösen.

Abbildung 5: Vielleicht hat Google doch endlich verstanden, dass es das fundamentale Sicherheitsproblem nur langfristig lösen kann – mit zentralen Patches und Updates, wie auf Linux eigentlich üblich. Derlei soll der Dynamic Security Provider bringen, den das Unternehmen aktiv bewirbt.

Möglicherweise wird Google weitere Schritte unternehmen, um sich und das eigene System künftig noch stärker von den Smartphoneherstellern unabhängig zu machen, also ein Streamlining durchführen. Den Preis dafür müssten einerseits freie Android-Varianten wie Cyanogenmod zahlen, die weitere Einschränkungen bei Android-Smartphones zu fürchten haben.

Andererseits könnten Hersteller unter weggefallenen Möglichkeiten leiden, ihr Systeme zu individualisieren. Fest steht nur, dass deutlich mehr passieren muss, als Google für Android L vorgesehen hat – der große Wurf gelingt mit dem erneuerten Konzept für Sicherheit in Android L sicherlich nicht.

Der Autor

Martin Gerhard Loschwitz arbeitet als Cloud Architect bei Sys Eleven. Er beschäftigt sich dort intensiv mit den Themen Open Stack, Distributed Storage und Puppet. In seiner Freizeit pflegt er Pacemaker für Debian.