Was Sie beim Entwickeln sicherer Apps beachten müssen

Windows Phone und die Sicherheit
Kommentare

Smartphones sind kleiner und leistungsschwächer als Desktoprechner, sie gehen leichter verloren und werden öfter gestohlen als ihre großen Brüder. Welche Auswirkungen das auf die Entwicklung sicherer Smartphone-Apps hat, zeigt dieser Artikel.

Windows Developer

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

Worauf soll bzw. muss man aus Sicherheitssicht bei der Entwicklung von Smartphone-Apps achten? Microsoft führt zu den Themen „End User Experience“ und „Sicherheit“ drei Punkte auf [1]: Apps sollen die Nutzung des Smartphones nicht stören und nicht ohne Zustimmung des Benutzers auf sensitive Informationen zugreifen oder Kosten, z. B. durch Anrufe bei Premiumnummern oder den Versand von SMS, verursachen. Diesen Forderungen wird wohl jeder von Ihnen zustimmen. Eine weitere wichtige Forderung hat Microsoft nicht explizit formuliert: Ebenso wenig, wie die App selbst den Benutzer schädigen soll, darf sie zum Einfalltor eines Angreifers werden. Die Apps dürfen also keine Schwachstellen aufweisen, und wenn doch welche entdeckt werden, müssen sie zügig behoben werden. Und zu guter Letzt müssen ggf. anfallende, vertrauliche oder in sonst irgendeiner Weise für Dritte interessante Daten angemessen geschützt werden, damit ein Dieb oder unehrlicher (oder auch nur neugieriger) Finder des Smartphones sie nicht lesen kann.

Vorbemerkungen

Kommen wir zur technischen Umsetzung dieser eher allgemein formulierten Anforderungen. Das Folgende gilt für Windows Phone 7. Microsoft hat am 20. Juni einige allgemeine Informationen zu Windows Phone 8 preisgegeben. Eine Zusammenfassung der sicherheitsrelevanten Neuerungen finden Sie im Kasten „Windows Phone 8 und die Sicherheit“. Mangels brauchbarer Informationen sind das aber nur sehr allgemeine Hinweise.

Windows Phone 8 und die Sicherheit

Am 20. Juni hat Microsoft zur Eröffnung des Windows Phone Summit in San Francisco erste Informationen zu Windows Phone 8 veröffentlicht. Einzelheiten wurden aber noch nicht verraten.

Kernel von Windows 8

Wie zu erwarten war, verwendet Windows Phone 8 den Kernel von Windows 8. Code soll zu großen Teilen auf beiden Plattformen verwendet werden können, insbesondere die APIs für Netzwerkzugriffe, Sicherheitsfunktionen und Multimedia sollen sich sehr ähneln. Vermutlich bedeutet das auch, dass die Apps die mit Windows 8 eingeführten Contracts zur Kommunikation untereinander nutzen können [2].

Neue Hardwareunterstützung

Windows Phone 8 wird Mehrkernprozessoren unterstützen. Außerdem werden drei Bildschirmauslösungen unterstützt: Zur bisherigen Standardauflösung von 800 x 480 Pixel (WVGA) kommen die Auflösungen 1280 x 768 Pixel (WXGA) und 1280 x 720 Pixel (720p) hinzu. Neu ist auch die Möglichkeit, den Speicher durch wechselbare MicroSD-Karten aufzurüsten.

Funkkontakt

Windows 8 wird Near Field Communication (NFC) unterstützen, darunter mehrere Anwendungsfälle: „Tap + Share“ dient dem Datenaustausch zwischen verschiedenen Smartphones und dem Lesen von Visitenkarten, Plakaten oder Speisekarten etc., eine weitere Anwendung ist das mobile Bezahlen über eine Wallet-Applikation. Die für diese Bezahlfunktion benötigten Sicherheitselemente sollen nicht wie sonst üblich im Gerät, sondern auf der SIM-Karte gespeichert werden, setzen also die Nutzung eines entsprechenden Providers voraus. Ob auf der SIM-Karte auch die Daten des neuen „Wallet Hub“ zur Verwaltung von Kreditkarten, Gutscheinen etc. gespeichert werden, ist aus den Ankündigungen nicht ersichtlich geworden.

Webbrowser

Als Webbrowser wird der Internet Explorer 10 enthalten sein, damit soll JavaScript 4x schneller als unter Windows Phone 7.5 ausgeführt werden. Außerdem werden doppelt so viele HTML5-Features unterstützt. Wie auch unter Windows 8, enthält der Internet Explorer Sicherheitsfunktionen wie SmartScreen und den Phishing-Schutz, um vor möglicherweise gefährlichen Websites zu warnen.

Angebote für Unternehmen

Besonders an Unternehmen richten sich zwei Neuerungen: Apps können auch außerhalb des Marketplace auf die Smartphones verteilt werden (wie das implementiert wird und ob es evtl. auch allgemein möglich ist, wurde natürlich noch nicht verraten), und die zentrale Geräteverwaltung wurde verbessert.

Sicherheit

Zusätzlich zu den oben bereits enthaltenen Sicherheitsfunktionen etc. wurden SecureBoot und die BitLocker-Verschlüsselung explizit aufgeführt.

Die Entwicklung, allgemein

Dass Sie bei der Entwicklung einer Smartphone-App genauso wie bei einer Desktop- oder Serveranwendung sorgfältig arbeiten müssen, ist wohl selbstverständlich. Auch bei der App-Entwicklung lässt sich der Security Development Lifecycle [3] einsetzen. In der Releasephase gibt es dann aber eine entscheidende Abweichung: Sie müssen Ihre ausschließlich unter Verwendung von .NET-Managed-Language-Development-Technologien und -Tools entwickelte Anwendung für die Veröffentlichung auf dem Windows Phone Marketplace anmelden. Nach dem Bestehen einiger Zertifizierungstests wird die Anwendung dann durch Microsoft in Ihrem Namen signiert und auf dem Marketplace angeboten [4]. Eine nicht signierte App lässt sich außer auf speziell dafür angemeldeten Entwicklungsgeräten nicht installieren. Der Zertifizierungsprozess soll Apps mit möglicherweise schädlichem Verhalten aus dem Marketplace fernhalten. Die ausschließliche Verwendung von .NET-Managed-Code soll durch die damit verbundene strenge Typisierung, Größenprüfungen und Speicherverwaltung dafür sorgen, dass die Programmierfehler, die zu den häufigsten Schwachstellen und zum unbeabsichtigten Ressourcenverbrauch führen, vermieden werden.

Das Sicherheitsmodell von Windows Phone

Das Sicherheitsmodell von Windows Phone 7 basiert auf den Prinzipien der Isolation und des „Least Privilege“ und setzt dazu das so genannte „Chamber“-Konzept ein. Jede Chamber stellt einen Sicherheitsbereich dar, in dem ein Prozess in einem isolierten Bereich läuft. Die Chambers werden mit einem Policy-System definiert und implementiert. Die Security Policy jeder spezifischen Chamber definiert, auf welche Fähigkeiten des Betriebssystems der Prozess in der jeweiligen Chamber zugreifen darf.

Die Chamber-Typen

Es gibt insgesamt vier Chamber-Typen, von denen drei feste Rechtemengen (Fixed Permissions) umfassen, während die Fähigkeiten der vierten Chamber über die so genannten „Capabilities“ gesteuert werden:

  • Die Trusted Computing Base (TCB) Chamber hat die meisten Privilegien. Prozesse in dieser Chamber haben uneingeschränkten Zugriff auf die meisten Ressourcen des Systems. Die TCB-Chamber kann Policies ändern und das Sicherheitsmodell erzwingen. Der Kernel und die Kernel-Mode-Treiber laufen in dieser Chamber.
  • Die Elevated Rights Chamber (ERC) kann auf alle Ressourcen mit Ausnahme der Security Policies zugreifen. In dieser Chamber laufen die Services und User-Mode-Treiber, die Funktionen für alle Apps bereitstellen.
  • Die Standard Rights Chamber (SRC) ist die Default Chamber für alle vorinstallierten Anwendungen. Alle Anwendungen, die keine geräteweiten Dienste anbieten, laufen in dieser Chamber. Als Beispiel nennt Microsoft Outlook Mobile 2010.
  • Die Least Privileged Chamber (LPC) ist die Default Chamber für alle nicht von Microsoft stammenden Apps. Diese Chambers werden über die Capabilities konfiguriert.

Den Aufbau der Chambers zeigt Abbildung 1.

Abb. 1: Die Chambers
Abb. 1: Die Chambers
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -