Was Sie beim Entwickeln sicherer Apps beachten müssen

Windows Phone und die Sicherheit (Teil 2)
Kommentare

Windows Developer

Der Artikel „Windows Phone und die Sicherheit“ von Carsten Eilers ist erstmalig erschienen im Windows Developer 9.2012
Neben dem Sandkasten eine Aufsicht
Um einem möglichen Angreifer

Windows Developer

Der Artikel „Windows Phone und die Sicherheit“ von Carsten Eilers ist erstmalig erschienen im Windows Developer 9.2012

Neben dem Sandkasten eine Aufsicht

Um einem möglichen Angreifer die Arbeit möglichst zu vermiesen, laufen die Apps in einer abgeschotteten Sandbox – eben einer Least Privileged Chamber. Daten oder Konfigurationsparameter werden im individuellen Isolated Storage gespeichert, und die Kommunikation mit anderen Apps ist nur über die Cloud möglich. Jede Sandbox hat an die jeweilige App angepasste Fähigkeiten; die erwähnten Capabilities. Die Windows Phone Application Platform sorgt für eine Minimierung der Angriffsfläche, indem den Apps nur die jeweils benötigten Ressourcen bereitgestellt werden. Wird z. B. die Media Library nicht benötigt, läuft die App in einer Sandbox, die nicht darauf zugreifen kann. Capabilities, die Auswirkungen auf den Zugriff auf Daten oder das Erzeugen von Kosten haben, werden den Benutzern vom Windows Phone Marketplace vor dem Kauf der App angezeigt. Eine Grundmenge an Capabilities einschließlich des Zugriffs auf den Isolated Storage wird jeder App automatisch zugewiesen. Gelingt es einem Angreifer, über eine Schwachstelle in einer App eigenen Code einzuschleusen, ist er in der Sandbox eingesperrt und kann nur auf die Daten der betroffenen App zugreifen und deren Capabilities nutzen.

Alle Apps laufen unter der Kontrolle eines Execution Managers, der darauf achtet, dass sich die Apps wie erwartet verhalten. Der Execution Manager überwacht z. B. den Ressourcenverbrauch von Apps im Hintergrund und beendet sie ggf., um der App im Vordergrund mehr Ressourcen zur Verfügung zu stellen. Nicht von Microsoft stammende Apps dürfen gar nicht im Hintergrund aktiv bleiben. In dem Moment, in dem der Benutzer zu einer anderen App wechselt, wird die bisher benutzte App beendet und ihr Status gespeichert. Wird sie wieder aufgerufen, wird der bisherige Status wiederhergestellt. Um trotzdem Aktionen im Hintergrund durchzuführen, gibt es die Background Agents [5]. Deren Funktionsumfang ist im Vergleich zu den Apps eingeschränkt, z. B. ist die Nutzung einiger APIs nicht zulässig und die Laufzeit ist begrenzt.

Windows Phone 8 und die Sandbox

Da Windows 8 ebenfalls eine Sandbox für Anwendungen implementiert, sind an dieser Stelle nur wenige Änderungen zu erwarten. Anders als Windows Phone 7 erlaubt Windows 8 den Apps aber die Kommunikation mit anderen Apps auf dem Rechner. Dafür dienen die Contracts, die mit Windows Phone 8 vermutlich auch auf dem Smartphone Einzug halten.

Der Isolated Storage

Die I/O-Operationen einer App sind auf den individuellen Isolated Storage (Abb. 2) der App beschränkt [6]. Ein Zugriff auf das darunter liegende Dateisystem des Betriebssystems oder den Isolated Storage anderer Apps ist nicht möglich. Den Apps stehen drei Speichermöglichkeiten zur Verfügung:

  1. Einstellungen (Settings) werden über die Klasse IsolatedStorageSettings als Schlüssel-Wert-Paare gespeichert. Wird die App beendet, wird automatisch die Methode Save aufgerufen, Änderungen an den Einstellungen werden also ggf. automatisch gespeichert.
  2. Dateien und Ordner werden über die Klasse IsolatedStorageFile gespeichert.
  3. Relationale Daten werden mithilfe von LINQ to SQL in einer lokalen Datenbank gespeichert [7].

Die Klassen IsolatedStorageSettings und IsolatedStorageFile finden Sie im Namespace System.IO.IsolatedStorage [8], die für die Nutzung von LINQ to SQL benötigten Klassen sind über mehrere Namespaces verteilt [9].

Abb. 2: Datenspeicherung im Isolated Storage
Abb. 2: Datenspeicherung im Isolated Storage
Spezielle Ordner

Der Isolated Storage enthält außer den eigenen Daten der App eine spezielle Ordnerhierarchie unter Shared:

  • Shared/Media enthält die „Album Art“, also die Albencover, die beim Abspielen von Musik im Hintergrund im Universal Volume Control (UVC) angezeigt werden können.
  • Shared/ShellContent enthält die Hintergrundbilder für die Application Tiles.
  • Shared/Transfers ist für den Dateitransfer im Hintergrund bestimmt. Apps können eine oder mehrere Dateien zum Up- oder Download über HTTP queuen. Der Dateitransfer wird auch dann fortgesetzt, wenn die App nicht mehr im Vordergrund ist.

Die speziellen Verzeichnisse werden automatisch angelegt, wenn die App installiert wird, und können jederzeit gelöscht werden.

Der Umgang mit den Daten

Wenn Sie Daten im Isolated Storage speichern, müssen Sie einige Punkte beachten. Bei einem Update der App wird der Isolated Storage nicht verändert. Sind Änderungen nötig, muss die App sie selbst durchführen. Anders sieht es beim Löschen einer App aus, dann wird der gesamte Isolated Storage gelöscht. Werden darin gespeicherte Daten später noch benötigt, müssen sie zuvor anderswo, z. B. in der Cloud, gespeichert werden. Unter Windows Phone gibt es für den Isolated Storage keine Größenbeschränkungen. Es liegt also in Ihrer Verantwortung, mit dem auf den Smartphones meist knappen Massenspeicher sparsam umzugehen. Sind nur noch 10 Prozent des Massenspeichers verfügbar, wird der Benutzer vom System gewarnt, damit er nicht benötigte Daten löschen kann. Sie sollten dafür sorgen, dass Ihre App möglichst keine unnötigen Daten anhäuft, sondern nur die beim nächsten Start benötigten Daten auf dem Smartphone gespeichert werden. Das bedeutet insbesondere, dass nicht mehr benötigte temporäre Dateien möglichst automatisch gelöscht werden. Um dem Benutzer ggf. das manuelle Löschen solcher Dateien zu erleichtern, sollten Sie alle temporären Dateien in einem speziellen Ordner speichern. Der kann dann auch gleich regelmäßig gelöscht werden. Von der App benötigte Daten wie z. B. Wörterbücher können ggf. mit einem Server synchronisiert werden, sodass auf dem Smartphone nur die relevanten Daten gespeichert werden müssen. Dass vom Benutzer erzeugte Daten vom Benutzer nicht nur gespeichert, sondern auch gelöscht und archiviert werden können, sollte selbstverständlich sein.

Windows Phone 8 und Massenspeicher

In Hinsicht auf den Massenspeicher bringt Windows Phone 8 zwei sicherheitsrelevante Neuerungen: Eine wechselbare MicroSD-Karte zur Erweiterung des Speichers und die BitLocker-Verschlüsselung. Da bisher außer der Information, dass es diese Neuerungen gibt, rein gar nichts darüber bekannt ist, folgen seitens des Autors nur allgemeine Ratschläge.

Meines Erachtens gibt es zwei Möglichkeiten, den Zugriff auf die MicroSD-Karte zu realisieren: Entweder eine App bekommt bei Bedarf einen eigenen, ausschließlich mit ihrem Isolated Storage verknüpften Ordner auf der Karte zugewiesen, oder die Karte wird als zusätzliches Laufwerk eingebunden, auf das alle Apps zugreifen können. Im zweiten Fall gibt es ein paar Punkte zu beachten: Unabhängig davon, ob Microsoft den Zugriff auf die MicroSD-Karte über einen weiteren speziellen Ordner im Isolated Storage oder zusätzliche API-Aufrufe realisiert, sollten Sie bei der Verwendung dieses externen Speichers die üblichen Vorsichtsmaßnahmen für „von außen“ kommende bzw. „nach außen“ gehende Daten beachten: Rechnen Sie damit, dass die Daten auf der MicroSD-Karte manipuliert und/oder ausgespäht werden können. Bei der Übernahme dieser Daten müssen Sie also deren Korrektheit prüfen, beim Speichern auf der MicroSD-Karte ggf. selbst für eine Verschlüsselung sorgen (dazu später mehr). Ob die MicroSD-Karte mit BitLocker verschlüsselt wird oder nicht, ist dabei aus Sicht Ihrer App irrelevant. Die Daten befinden sich außerhalb Ihres Isolated Storage, sodass z. B. eine bösartige App die von Ihrer App einwandfrei gespeicherten Daten manipulieren könnte. Und woher die von der MicroSD-Karte geladenen Dateien stammen, wissen Sie sowieso nicht. Sollte Microsoft den Isolated Storage auf den Speicherbereich der MicroSD-Karte ausweiten, ändert sich im Vergleich zum internen Speicher nichts. Ein solcher Ansatz erscheint mir aber unwahrscheinlich, da man damit im Grunde den aktuellen Zustand erhält. Auch jetzt schon können Speicherkarten verwendet werden, nur werden sie über eine individuelle Verschlüsselung an das jeweilige Smartphone gebunden, ein Austausch von Daten ist also nicht möglich. Die Karte wechselbar zu machen, würde dann ja darauf hinauslaufen, das Anlegen von mehreren, mit dem Smartphone verknüpften Backups zu ermöglichen. Und das kann man über Backups in der Cloud oder auf einem Desktoprechner einfacher realisieren.

Verschlüsselung von Daten

Die Daten im Isolated Storage sind vor dem Zugriff durch andere Apps geschützt. Fällt das ungeschützte Smartphone aber in unbefugte Hände, kann auf die von den Apps gespeicherten Daten zugegriffen werden. Die Daten müssen also ggf. verschlüsselt gespeichert werden, damit ein Angreifer nichts mit ihnen anfangen kann. Windows Phone stellt folgende kryptografische Algorithmen bereit: Den asymmetrischen RSA-Algorithmus zum Verschlüsseln und Signieren, den symmetrischen AES-Algorithmus zum Verschlüsseln, die Hash-Algorithmen HMACSHA1, HMACSHA256, SHA1 und SHA256 sowie zur Ableitung von Schlüsseln aus Passwörtern Rfc2898DeriveBytes. Alle benötigten Klassen finden Sie im Namespace System.Security.Cryptography [10], [2].

Wohin mit dem Schlüssel?

Die Verschlüsselung erhöht die Sicherheit nicht, wenn der Schlüssel ebenfalls auf dem Smartphone gespeichert wird. Hier kommt das Data Protection API (DPAPI) [11] ins Spiel, auf das über die Klasse ProtectedData zugegriffen werden kann [12]. Das API stellt zwei Methoden bereit: Protect zum Verschlüsseln der Daten, Unprotect zum Entschlüsseln. Die für die Ver- und Entschlüsselung verwendeten Schlüssel werden aus den Benutzer- und Smartphone-Zugangsdaten (Credentials) abgeleitet, vom DPAPI verwaltet und im Benutzerprofil gespeichert. Jede App verwendet einen eigenen Schlüssel, der beim ersten Start der App automatisch erzeugt wird und bei Updates unverändert bleibt. Müssen Sie größere Datenmengen in der lokalen Datenbank verschlüsseln, ist es besser, die gesamte Datenbank durch Angabe eines Passwortparameters zu verschlüsseln. Sollen nur einzelne Felder verschlüsselt werden, kann dafür das DPAPI genutzt werden.

DPAPI ist eine lokale Lösung!

Wenn Sie mit dem DPAPI verschlüsselte Daten in der Cloud speichern, denken Sie daran, dass diese Daten nur auf dem Smartphone entschlüsselt werden können, auf dem sie verschlüsselt wurden. Nur hier liegt der dazu benötigte Schlüssel vor. Sollen verschlüsselte Daten auch auf anderen Geräten, egal, ob Smartphone oder Desktop, entschlüsselt werden, müssen sie mit einem herkömmlichen Verschlüsselungssystem verschlüsselt werden. Der für die Entschlüsselung benötigte Key, entweder der öffentliche Schlüssel eines asymmetrischen Systems oder der einzige Schlüssel eines symmetrischen Systems, kann dann auf das andere Gerät übertragen werden. Auf dem Smartphone können Sie den Schlüssel dann, geschützt über das DPAPI, im Isolated Storage speichern.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -