Sicherheitsaspekte mobiler Endgeräte

Inhaltsverzeichnis

Abkürzungsverzeichnis

1 Einleitung

2 Plattformen für mobile Endgeräte
2.1 Java 2 Platform Micro Editon
2.1.1 Systemarchitektur
2.2 Symbian OS
2.2.1 Systemarchitektur
2.2.2 Sicherheit
2.3 Windows Mobile
2.3.1 Systemarchitektur
2.3.2 Sicherheit

3 Sicherheitskonzepte von J2ME
3.1 CLDC
3.1.1 Low-level Security
3.1.2 Application-level Security
3.1.3 End-to-End Security
3.2 MIDP 2.0 - Sicherheit
3.2.1 Autorisierungsmodell
3.2.2 Vertrauenswürdige Midlet-Suites
3.2.3 Nichtvertrauenswürdige Midlet-Suites
3.3 Code-Signing
3.3.1 Ausstellung von Zertifikaten
3.3.2 Das Konzept hinter den Zertifikaten
3.3.3 Zertifikate im Bereich mobiler Endgeräte
3.3.4 Gefahren des Code-Signing-Verfahrens

4 Allgemeine Sicherheitsprobleme in Mobiltelefonen
4.1 Existenz von Sicherheitsproblemen in Mobiltelefonen
4.2 Potentielle Angriffsziele bei einem Mobiltelefon
4.2.1 Angriffe auf Plattformen am Beispiel der J2ME
4.2.2 Angriffe auf die Firmware am Beispiel Sony Ericsson
4.3 Umgang mit Sicherheitsproblemen
4.3.1 Keine Ausnutzung
4.3.2 Eigener Vorteil
4.3.3 Proof-of-Concept
4.3.4 Böswillige Absicht
4.4 Verbreitung von Schadprogrammen
4.4.1 Bluetooth
4.4.2 Infrarot
4.4.3 E-Mail
4.4.4 Internet
4.4.5 MMS
4.4.6 Speicherkarte

5 Konkrete Sicherheitsprobleme in Mobiltelefonen von Sony Ericsson
5.1 Auswahl der Telefonmodelle für Sicherheitsanalysen
5.2 Vorstellung der ausgewählten Geräte
5.3 Sicherheitsanalysen
5.3.1 Form Reboot
5.3.2 AMS-Jad DoS
5.3.3 Kopierschutz von Anwendungen
5.3.4 Zugriff auf das interne Dateisystem
5.4 Trojanisches Pferd
5.4.1 Möglichkeiten für eine Infektion
5.4.2 Aufbau des Trojanischen Pferdes
5.4.3 Von der Kompilierung bis zur Installation
5.4.4 Illustrierter Testdurchlauf

6 Konzept: Reduzierung von Sicherheitslücken durch Einsatz gezielter Black-Box-Tests
6.1 Vorstellung allgemeiner Testverfahren
6.1.1 Komponententest
6.1.2 Integrationstest
6.1.3 Funktions- und Systemtest
6.1.4 Akzeptanztest
6.1.5 Regressionstest
6.2 Einsatz gezielter Black-Box-Tests
6.2.1 Vor- und Nachteile von Black-Box-Tests
6.2.2 Strategien bei der Durchführung von Black-Box Tests
6.2.3 Konzept der Software „Black-Box-Tool“
6.3 Fazit

7 Zusammenfassung und Ausblick

Anhang: Quellcode des Trojanischen Pferdes

Literaturverzeichnis

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

1 Einleitung

Am Anfang seiner Einführung war das Mobiltelefon meist den Behörden, wie der Polizei oder der Feuerwehr vorbehalten, damit diese in Notfällen Hilfe herbeirufen konnten. Heute besitzt fast jeder ein solches Gerät: “Im dritten Quartal 2006 wurde im Mobilfunkbereich erstmals eine Penetrationsrate von über 100 Prozent erreicht. Somit kommt im statistischen Durschnitt auf jeden Einwohner ein Mobilfunkvertrag” [BNAgent 2006].

Die früh in Behörden eingesetzten Modelle waren jedoch nicht nur sehr unhandlich und teuer, sondern auch vom Funktionsumfang her nicht mit den heutigen Model­len vergleichbar. Im Laufe der Zeit sind die Anforderungen an Mobiltelefone stetig gewachsen, so dass immer mehr Funktionen integriert wurden, die das Mobiltelefon von seiner ursprünglichen Bestimmung, nur damit zu telefonieren, zunehmend distan­zierten. Inzwischen ermöglicht ein solches Gerät die Verwaltung von Terminen, das Verschicken von E-Mails, das Anhören von Musik, das Ansehen von Filmen, das Er­stellen von Fotos und das Surfen im Internet. Diese Auflistung von Funktionen ist längst nicht vollständig und soll dem Leser nur einen Eindruck über die Möglichkeiten eines solchen Gerätes bieten.

In der heutigen Zeit gewinnen Mobiltelefone zunehmend an Bedeutung und nähern sich mit ihrer stark zunehmenden Funktionsvielfalt den Fähigkeiten eines Personal Computers an. Geräte der neuesten Generation (viertes Quartal 2007) sollen sogar Bezahlvorgänge mit dem Mobiltelefon ermöglichen und den genauen Aufenthaltsort eines Benutzers bestimmen können. Ein solcher Funktionsumfang setzt hohe Ansprü­che an die Hard- und Software eines modernen Gerätes. Werden vom Gerätehersteller bei der Programmierung substantielle Fehler begangen, so wächst die Gefahr einer Ausnutzung der gesamten Funktionsvielfalt eines Gerätes durch potentielle Angreifer.

Die Gefahr des Abhörens, Ausraubens und Ausspionierens von Mobiltelefonbenutzern mit Hilfe von Viren und Trojanischen Pferden ist heute so real wie nie zuvor. Ein Einbruch in ein Mobiltelefon und die Entwendung von Firmendaten kann sich für 1 Einleitung einen Geschäftsmann als besonders kritisch erweisen, denn solche Informationen sind der Motor der Informationsgesellschaft und der in ihr agierenden Akteure [vgl. Sury 2006]. Infolgedessen kann das Einbüßen solcher Informationen für ein Unternehmen zu unvorteilhaften Konsequenzen führen oder sogar den Verlust eines Wettbewerbsvorteils bedeuten.

Diese Diplomarbeit befasst sich mit der Sicherheit mobiler Endgeräte. Hierfür werden zu Beginn Plattformen für mobile Endgeräte vorgestellt und allgemeine Sicherheitsmo­delle sowie Sicherheitsprobleme beschrieben. Der Schwerpunkt der vorliegenden Arbeit besteht jedoch in der Analyse von Mobiltelefonen eines ausgewählten Geräteherstellers. Die durchgeführten Sicherheitsanalysen zeichnen sich durch die Verwendung neuarti­ger Geräte aus, für die bislang keine ernsthaften Schwachstellen veröffentlicht wurden. Das Ziel hierbei, war es zu untersuchen, ob die Implementierung der oben erwähn­ten Sicherheitsmodelle, auf Mobiltelefonen der neusten Generation ordnungsgemäß durchgeführt worden ist. Da infolge der Untersuchung diverse Schwachstellen entdeckt wurden, erfolgt im Nachhinein die Einschätzung der Konsequenzen, die aus diesen Schwachstellen für die Benutzer, andere Unternehmen und den Gerätehersteller resul­tieren können. Ferner führen diese Untersuchungen zur Entwicklung eines Konzeptes, das zur Reduzierung von Sicherheitslücken beitragen soll und somit eine mögliche Lösung der identifizierten Sicherheitsprobleme aufzeigt.

Die Arbeit ist wie folgt gegliedert:

- Das nächste Kapitel gibt eine Einführung in die Sicherheit und die Systemar­chitektur von Plattformen mobiler Endgeräte und bildet damit die Basis für das Verständnis der nachfolgenden Kapitel.
- In Kapitel 3 werden die wesentlichen Sicherheitsmodelle der J2ME-Plattform detailliert behandelt.
- Kapitel 4 stellt einige allgemeine Sicherheitsprobleme im Bereich mobiler End­geräte vor. Dabei behandelt es die Themengebiete: „Existenz von Sicherheits­problemen in Mobiltelefonen“, „Potentielle Angriffsziele bei einem Mobiltelefon“, „Umgang mit Sicherheitsproblemen“ und „Verbreitung von Schadprogrammen“.
- Kapitel 5 macht den wesentlichen Teil der Arbeit aus. Hier werden Sicherheits­analysen einzelner Mobiltelefone durchgeführt und die Konsequenzen, die aus den gefundenen Schwachstellen resultieren, eingeschätzt. Am Ende des Kapitels erfolgt die Vorstellung eines Trojanischen Pferdes, welches praktisch zeigt, wie eine Schwachstelle in einem Mobiltelefon ausgenutzt werden kann.
- In Kapitel 6 erfolgt die systematische Entwicklung eines Konzeptes zur Reduzie­rung von Schwachstellen bei Mobiltelefonen.
- Kapitel 7 schließt die Arbeit zusammenfassend ab.

2 Plattformen für mobile Endgeräte

In diesem Kapitel erfolgt die Vorstellung einiger Plattformen für mobile Endgeräte. Die Beschreibung einer Plattform beginnt mit einer kurzen Übersicht über ihre Entstehung und setzt sich mit der Vorstellung ihrer primären Einsatzgebiete fort. Im nächsten Schritt erfolgt dann die Beschreibung der Systemarchitektur, in der alle wichtigen Komponenten dieser Plattform vorgestellt und dann erläutert werden. Zum Schluss wird das Sicherheitsmodell der Plattform beschrieben. Bei der Vorstellung von J2ME wurde dieser Abschnitt ausgelassen, da eine ausführliche Auseinandersetzung mit dem Thema J2ME-Sicherheit in Kapitel 3 erfolgt.

2.1 Java 2 Platform Micro Editon

Die Java 2 Platform, Micro Edition oder kurz J2ME wurde von Sun Microsystems ent­wickelt und im Juni 1999 bei der alljährlichen JavaOne Convention vorgestellt. J2ME stellt eine Umsetzung der Programmiersprache Java dar, die speziell für mobile Endge­räte entwickelt wurde. Als mobile Endgeräte werden heutzutage Pager (kleine Geräte zur Nachrichtenübermittlung per Funk), Mobiltelefone sowie PDAs (kleine Computer, die hauptsächlich für Kalender-, Adress- und Aufgabenverwaltung benutzt werden) bezeichnet. Aber nicht nur dort findet man J2ME vor. Auch in größeren Geräten, wie beispielsweise in Autonavigationssystemen oder stationären Geräten wie Set-Top Boxen findet das „Java für kleine Geräte“ Anwendung.

2.1.1 Systemarchitektur

Bei der Entwicklung von J2ME, bei der die Devise: „write once, run everywhere“ gel­ten sollte, sind die Entwickler von Sun Microsystems schnell auf Probleme gestoßen.

Die Vielfalt der Geräte sowie ihrer Einsatzmöglichkeiten ist einfach zu groß. Einige Geräte haben nicht einmal ein Display, eine Maus oder Tastatur und müssen mit ein paar Hundert Kilobyte Speicher auskommen. Andere hingegen haben ein großes far­biges Display, eine Netzwerkanbindung, eine Festplatte, können Musik abspielen und haben mehrere Megabyte Arbeitsspeicher zur Verfügung. Die Herausforderung war es nun, alle diese Geräte einheitlich behandeln zu können und trotzdem die Bedürfnisse der Konsumenten nach bedienungsfreundlichen und funktionsreichen Anwendungen, wie sie diese vom Computer her kennen, zu erfüllen. Es musste also eine Architektur entwickelt werden, die so flexibel ist, dass sie sich an die einzigartigen Eigenschaf­ten kleinerer Geräte anpassen kann, und sie gleichzeitig keine größeren Geräte in ihrer Funktionsweise einschränkt. Hierfür wurde das Konzept von Konfigurationen (configu­rations), Profilen (profiles) und deren optionalen APIs entwickelt, die je nach Bedarf angepasst werden können. Die Abkürzung API steht für Application Programming Interface und heißt übersetzt Schnittstelle zur Anwendungsprogrammierung. Hierbei stellt ein Softwaresystem dem Programmierer eine Bibliothek mit Funktionsaufrufen zur Verfügung und ermöglicht ihm somit die Nutzung von bereits entwickelten Pro­grammteilen.

Eine Konfiguration hat die Aufgabe, eine Java Virtual Machine (JVM) festzulegen und einen Satz von Kern-APIs für eine spezifische Gerätefamilie zur Verfügung zu stellen. Momentan gibt es zwei Konfigurationen: die Connected Device Configuration (CDC), die für größere Geräte, ab Pocket PCs aufwärts gedacht ist, und die Connected Limited Device Configuration (CLDC), die nur einen Teil der Funktionen der CDC zur Ver­fügung stellt und sich somit auch in kleineren Geräten wie PDAs und Mobiltelefonen einsetzen lässt (siehe Abbildung 2.1).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.1: Einsatzgebiete der CDC und der CLDC Das Java-Konzept sieht vor, dass die Software auf einem beliebigen Gerät funktionie-

2.1 Java 2 Platform Micro Editon

ren soll, wenn dieses Gerät der Spezifikation entspricht. Um sicher zu stellen, dass ein beliebiges Gerät mit einer bestimmten Konfiguration arbeiten kann, wurden Minima­lanforderungen für den Speicher festgelegt, die ein Gerät erfüllen muss. Die CLDC- Spezifikation setzt 160 Kilobyte (KB) nicht-flüchtigen Speichers voraus, der von der JVM sowie den CLDC-Bibliotheken genutzt werden kann. Ferner braucht das Ge­rät mindestens 32 KB flüchtigen Speichers, der zur Laufzeit für die JVM benötigt wird. In der CLDC-Spezifikation kann jedoch keine vollständige JVM genutzt wer­den, da diese zu viele Ressourcen benötigen würde, die den kleinen Geräten nicht zur Verfügung stehen. Diese in der Referenzimplementierung KVM genannte Virtuel­le Machine (VM) muss beispielsweise Abstriche bei dem Bytecode-Verifizierer (siehe Kapitel 3.1.1.1) machen, weil dieser Prozess sehr rechenintensiv ist. Die CDC 1.0 Spe­zifikation setzt für seine Geräte mindestens 512 KB nicht-flüchtigen Speichers sowie 256 KB flüchtigen Speichers voraus. „Mit der Einführung des Personal Profile in der CDC Version 1.0.1 wird der minimale nicht-flüchtige Speicher auf 2,5 Megabyte (MB) und der flüchtige Speicher auf 1 MB angehoben“ [vgl. Knudsen 2005]. Ferner ist in der CDC-Spezifikation festgelegt, dass die vollständige JVM unterstützt werden muss. Auf den Konfigurationen liegen nun die Profile auf und erweitern deren APIs. Dieses ermöglicht es den Geräteherstellern, im Laufe der Entwicklung eines Gerätes immer mehr Profile und somit mehr Funktionen anbieten zu können. Eines der wichtigsten Profile der CLDC-Konfiguration ist das Mobile Information Device Profile (MIDP), welches speziell auf Mobiltelefone ausgerichtet ist. Es spezifiziert das Anwendungs­modell sowie neue Klassen für die Gestaltung der Benutzeroberfläche (GUI) und der Speicherung von Daten in Form von Records. Eines der wichtigsten Profile der CDC ist das Foundation Profile (FP). Es baut direkt auf der CDC auf und erweitert die bereits vorhandenen J2SE APIs (siehe Abbildung 2.2).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.2: Architektur von J2ME

Heutzutage wird die Weiterentwicklung von J2ME vom Java Community Process^[1] (JCP), einer Expertengruppe, die mehr als 700 Mitglieder zählt, sichergestellt. Hier­zu zählen neben Sun Microsystems Unternehmen wie America Online, Apple, Fujit­su, Google, Nokia, Siemens und Sony Ericsson [JcpMem 2007]. Soll eine neue Java­Spezifikation erstellt oder eine bestehende erweitert werden, so wird ein Java Specifi­cation Request (JSR) angelegt und an das von Sun Microsystems betriebene Process Management Office (PMO) geleitet. Die Umsetzung der neuen Spezifikation wird von einer Expertengruppe auf dem jeweiligen Gebiet geleitet. Viele der spezifizierten JSRs sind inzwischen auch auf Mobiltelefonen zu finden. Dazu zählt, z.B. das JSR-75 für den Zugriff auf das Dateisystem und das Personal Information Management (PIM) des Mobiltelefons. Das PIM ist zuständig für die Verwaltung des Adressbuches, der Ereignisliste und der Aufgabenliste. Ferner sind da noch zu erwähnen: das JSR-82 für Bluetooth-Verbindungen, das jsr-205 für den Versand und Empfang von Nachrichten (z.B. SMS) und das jsr-234 für den Zugriff auf das Mikrofon und die Kamera des Mobiltelefons. Mobiltelefone der allerneusten Generation (viertes Quartal 2007) wer­den dem Benutzer noch mehr Möglichkeiten bieten. „Dort werden u. A. noch folgende APIs unterstützt: das JSR-177 für den Zugriff auf die SIM-Karte des Mobiltelefons, das JSR-179 zur Bestimmung des Aufenthaltsortes einer Person und das JSR-229 für die Durchführung von Bezahlvorgängen mit dem Mobiltelefon“ [vgl. J2MeSE 2007]. Spätestens in diesem Augenblick wird deutlich, wie vielfältig die heutigen Einsatzmög­lichkeiten eines Mobiltelefons sind, und wie gefährlich es wäre, wenn diese Möglichkei­ten von Angreifern ausgenutzt werden könnten.

2.2 Symbian OS

Symbian OS heißt das proprietäre Betriebssystem des Symbian-Konsortiums, welches aus folgenden Firmen besteht: Ericsson, Nokia, Panasonic, Samsung, Siemens und Sony Ericsson. Es stellt die Weiterentwicklung des Betriebssystems EPOC dar, welches früher auf Psion-Geräten eingesetzt wurde. Seit der ersten Version im Jahr 2001 wur­den bis heute mehr als 120 verschiedene Gerätemodelle^[2] mit Symbian OS ausgestattet, was für den hohen Verbreitungsrad und somit den großen Erfolg des Betriebssystems spricht. Die neuste Version von Symbian OS wurde im März 2007 vorgestellt und trägt die Versionsnummer 9.5. Sie enthält neben vielen Neuerungen das neue Digital- TV Handy-System (DVB-H, ISDB-T), ein integriertes SQL-Datenbankinterface sowie eine POSIX-Applikationsschnittstelle. Letztere soll es den Entwicklern ermöglichen, schneller und einfacher Inhalte für das neue System zu schreiben; denn zurzeit sind noch Mobiltelefone der zweiten und dritten Generation mit den Symbian-Versionen 7.0 und 8.0 weit verbreitet. Das Ziel bei der Entwicklung von Symbian OS war es, ein Betriebssystem speziell für kleine Geräte, wie Smartphones und PDAs, zu schaf­fen und gleichzeitig das Modell einer offenen Plattform zu wahren. Diese stellt einer­seits sicher, dass Lizenzabnehmer den kompletten Betriebssystemquellcode erhalten, und ermöglicht andererseits unabhängigen Drittherstellern selbst Anwendungen oder Dienstleistungen für Symbian-Geräte zu entwickeln.

2.2.1 Systemarchitektur

Die Systemarchitektur von Symbian OS ist hierarchisch, als eine Reihe von aufeinander aufbauenden Schichten, gegliedert (siehe Abbildung 2.3). Die „Application Services“, das „UI Framework“ sowie „J2ME“ stellen die obersten Schichten der Architektur dar. Die „Base Services“ sowie das „Kernel Services & Hardware Interface“ bilden die un­tersten Abstraktionsschichten. Als Mittelteil zwischen den fünf Schichten dienen die „OS Services“. Die Beschreibung der Systemarchitektur basiert auf dem Symbian OS- Architekturbuch von Ben Morris [Morris 2007] und erfolgt schichtenweise, wobei mit der obersten Schicht, dem „UI Framework“, angefangen wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.3: Architektur von Symbian OS

2.2.1.1 UI Framework

Das „UI Framework“ stellt die oberste Schicht der Symbian OS Architektur dar und bil­det die unmittelbare Schnittstelle zu einer vom Hersteller angepassten Benutzerober­fläche. Als Framework wird ein Programmiergerüst bezeichnet, welches den Rahmen für einen Programmierer vorgibt, innerhalb dessen er eine Anwendung erstellt. Man kann somit sagen, dass ein Framework in der Regel die Anwendungsarchitektur vorgibt. Symbian OS wird an die Lizenznehmer mit einer minimalen Test-Benutzeroberfläche, die weder vollständig noch besonders ansprechend ist, ausgeliefert. Dieses Framework ermöglicht es den Mobiltelefon-Herstellern, eine eigene Benutzeroberfläche zu erstellen und diese auf Symbian OS aufzusetzen. Das Framework dient dann als Schnittstelle zwischen dem neuen User-Interface (UI) und dem Betriebssystem.

Zu den drei wichtigsten Kompontenten des „UI Frameworks“ zählen das Uikon Frame­work, das Control Environment (CONE) sowie das Front-End Processor Framework. Diese drei Komponenten werden im Folgenden beschrieben:

Uikon: Das Uikon Framework bietet die vollständige Kontrolle über das Aussehen und die Bedienung der gesamten GUI. Hier finden sich Funktionen für die Erstellung von Knöpfen, Dialogfenstern oder Scrollbalken. Weitere Funktionen dienen zum Star­ten von Anwendungen, zur Tastenbelegung und Befehlsverarbeitung sowie für Alarme, Meldungen und andere grafische Dienste.

CONE: Das Control Environment dient als abstrakte mittlere Schicht zwischen der systemnahen Fensterverarbeitung des „Window Servers“ und den konkreten UI-Klassen von Uikon. Tritt beispielsweise auf dem Bildschirm des Benutzers ein neues Ereignis auf, sodass der Bildschirm neu gezeichnet werden muss, so gibt der „Window Server“ diese Informationen an das CONE weiter, welches dafür sorgt, dass die UI die Ände­rungen auf dem Bildschirm umsetzt.

FEP: Das Front-End Processor Framework enthält Funktionen zum Erfassen von Be­nutzereingaben und deren Vorverarbeitung. Eingesetzt wird es beispielsweise bei einer handschriftlichen Eingabe zur Erkennung der Zeichen.

2.2.1.2 Application Services

Die „Application Services“ bauen auf den „OS Services“ auf und bieten Dienste an, die primär von Anwendungen genutzt werden. „Aus der Sicht von Symbian OS standen Anwendungen immer schon im Mittelpunkt“ [Morris 2007]. Aufgrund dessen wurde die Architektur der „Application Services“ in ein objekt-orientiertes Design mit einer spezifischen Anwendungslogik eingebettet. Ermöglicht wurde damit die Erstellung ei­ner Vielzahl von Diensten sowohl auf System- als auch auf tiefergehenden Ebenen.

Zu den fünf wichtigsten „Application Services“ gehören das „Personal Identity Module“ (PIM), der „Messaging Application Support“, das „Content Handling“, das „Applicati- on Framework“, sowie der „Internet & Web Application Support“. Nachfolgend werden diese Services näher beschrieben:

PIM: Die „PIM Application Services“ sowie der „PIM Application Support“ bieten anderen Anwendungen unter anderem Dienste für den Zugriff auf das Adressbuch, den Kalender, sowie den Alarm-Server an. Mit Hilfe unterschiedlicher APIs können Daten dort abgefragt, eingetragen und gelöscht werden.

Messaging Application Support: Der „Messaging Application Support“ stellt ein Framework für den Versand und Empfang von Nachrichten verschiedenster Art zur Verfügung. Unter anderem werden SMS und MMS, sowie E-Mails mit POP3, IMAP4 sowie SMTP und OBEX Nachrichten unterstützt. Spezielle Komponenten für Benach­richtigungen beim Eingang einer Nachricht sind ebenso vorhanden, wie die Möglichkeit zum zukünftigen Versand von Nachrichten.

Content Handling: Das „Content Handling“ bietet Frameworks, Handler, Parser und Erkennungswerkzeuge für Daten und Dokumente sowie DRM-Inhalte an. Das Framework ermöglicht beispielsweise die Erkennung verschiedener MIME Typen oder von Inhalten, die mit Digital Rights Management (DRM) versehen sind. Die Web Erkennungswerkzeuge unterstützen sowohl URLs als auch Bookmarks und der SMIL- Parser parsiert SMIL Inhalte (SMIL ermöglicht die Einbindung und Steuerung von Multimedia-Elementen wie Audio, Video, Text und Grafik in Webseiten) und kann z.B. Syntaxfehler anhand einer einfachen Document Type Definition (DTD) erkennen. Eine DTD ist ein Satz an Regeln, der benutzt wird, um Dokumente eines bestimmten Typs zu repräsentieren.

Application Framework: Das „Application Framework“ ist zuständig für alle wich­tigen Ereignissen und Interaktionen, die im Zusammenhang mit Anwendungen stehen. Hierzu zählen beispielsweise die sichere Installation der Software, die Umwandlung von Dateien in andere Dateiformate sowie das Suchen, Laden, Verarbeiten und Anzeigen von Dateien im Auftrag anderer Anwendungen.

Internet & Web Application Support: Der Internet & Web Application Support bietet Dienste zum Zugriff auf das Internet, das Web sowie WAP an. Hierfür werden Frameworks für HTTP und WAP sowie Engines für Telnet und FTP zur Verfügung gestellt. Weiterhin stehen auch eine Bookmark-Verwaltung sowie die Möglichkeit zur Erstellung von HTTP Plug-ins zur Verfügung.

2.2.1.3 J2ME

Seit Symbian OS v7.0 wird J2ME mit den Spezifikationen für MIDP und CLDC so­wie einigen optionalen APIs unterstützt. Die Architektur von J2ME wurde bereits in Kapitel 2.1.1 ausführlich beschrieben und soll hier nicht mehr behandelt werden.

2.2.1.4 OS Services

Die „OS Services“ stellen Server, Frameworks und Bibliotheken zur Verfügung, die den Kern des Betriebssystem in den Bereichen Grafik, Kommunikation, Konnektivität und Multimedia unterstützen sollen. Als Server werden unter Symbian OS spezielle Programme ohne grafische Benutzeroberfläche bezeichnet, die einen Dienst für andere Anwendungen zur Verfügung stellen. Dieser Dienst kann dann mit Hilfe eines API in Anspruch genommen werden. Die „OS Services“ bestehen aus den vier Komponenten: „Generic OS Services“, „Comms Services“, „Multimedia and Graphics Services“ und „Connectivity Services“. Diese werden im Folgenden näher beschrieben:

Generic OS Services: Die „Generic OS Services“ stellen eine kleine Anzahl von Diensten und Bibliotheken für das Betriebssystem sowie für Anwendungen höherer Schichten zur Verfügung. Hierzu zählen Dienste zur Datenerfassung und Aufgaben­planung sowie Bibliotheken und Frameworks zur Verschlüsselung und Verwaltung von Zertifikaten. Ferner stellen die „Generic OS Services“ die C Standard-Bibliothek zur Verfügung, die eine POSIX-Umgebung für andere Systemkomponenten (z.B. Java) be­reitstellt.

Comms Services: Die „Comms Services“ stellen die Kommunikationsdienste zur Ver­fügung, über die Verbindungen zu anderen Geräten aufgebaut werden können. Unter­stützt werden hierbei unter Anderem die serielle Kommunikation (z.B. über RS232 oder USB), Verbindungen über Bluetooth, Netzwerkprotokolle wie TCP/IP, Telefo­niestandards wie GSM und UMTS, der Nachrichtenversand (z.B. SMS) und auch der WAP-Zugriff.

Multimedia and Graphics Services: Die „Multimedia and Graphics Services“ stel­len alle Grafikdienste zur Verfügung, die über der Schicht der Gerätetreiber liegen, und bieten alle benötigten Frameworks an, die für die Ansteuerung von Multimediadi­ensten benötigt werden. Dazu zählen die Steuerung von Fenstern, die Behandlung von Ereignissen, die Verarbeitung von Bitmap- und Vektorgrafiken sowie alle Funktionen zum Zeichnen und zur Manipulation von Bildern. Ferner werden APIs zur Steuerung der Kamera, Aufnahme und Wiedergabe von Ton und Video sowie zur Konvertierung und Manipulation dieser Daten bereitgestellt.

Connectivity Services: In den „Connectivity Services“ werden Dienste für die Kon­nektivität auf Geräteseite angeboten. Hierzu zählen beispielsweise die Sicherung und Wiederherstellung von Daten, Datentransfers sowie die Installation von Anwendungen.

2.2.1.5 Base Services

Die „Base Services“ bilden die vorletzte Abstraktionsschicht der Symbian OS Architek­tur. Zu dieser Schicht zählen die Server auf der Benutzerseite, Frameworks, Bibliothe­ken und andere Hilfsmittel, die auf der Kernelschicht aufbauen und die elementarsten Funktionen des Betriebssystems anbieten. Als Server werden unter Symbian OS spezi­elle Programme bezeichnet, die einen Dienst für andere Anwendungen zur Verfügung stellen, der mit Hilfe eines API in Anspruch genommen werden kann. Nachfolgend werden die wichtigsten Komponenten der „Base Services“ beschrieben:

User Library: Die „User Library“ bietet die elementarsten APIs, die zum Program­mieren benötigt werden, an. Diese Bibliothek hat die höchste Privilegstufe im Benut­zermodus und bietet unter anderem auch Funktionen zum kontrollierten Zugriff auf den Kernel.

File Server: Der „File Server“ ermöglicht den Zugriff auf das Dateisystem. Dieses lässt sich in Form eines Plug-Ins implementieren und nach Bedarf verändern oder ersetzen. Standardmäßig werden die beiden Dateisysteme Virtual File Allocation Table (VFAT) und Logging Flash File System (LFFS) unterstützt [vgl. Eren 2006].

Essential System Frameworks: Zu den „Base Services“ zählen noch eine Reihe von essentiellen Frameworks, die für das System unabdingbar sind. Zu diesen gehören: ein Framework zur Verwaltung von nicht-flüchtigem Speicher, ein Plug-In-Framework, Verschlüsselungsbibliotheken und Server-Komponenten für Textfenster.

2.2.1.6 Kernel Services & Hardware Interface

„Der Kernel von Symbian OS basiert auf einem Microkernel, der jedoch auch einige Eigenschaften eines monolithischen Kernels aufweist“ [vgl. Eren 2006]. Das bedeu­tet, dass einerseits nur die nötigsten Funktionen, wie Prozess-, Speicherverwaltung und Power-Management in einem privilegierten Modus (kernel mode) ausgeführt wer­den, jedoch Gerätetreiber, die nicht im Kernel integriert sind, dynamisch nachgela­den werden können. Dieses Konzept ähnelt der Umsetzung von Kernel-Modulen in der Linux-Welt. Alle anderen Funktionen, Kommunikationsschnittstellen und Server­Komponenten laufen in einem nicht privilegierten Modus (user mode). Möchten diese auf die Hardware zugreifen, können sie dies nur mit Hilfe eines Kernel-API tun. Ein direkter Hardware-Zugriff ist somit ausgeschlossen. Zudem läuft jeder Prozess in sei­nem eigenen Speicherbereich, der vollkommen von den Adressräumen anderer Prozesse getrennt ist. Hierzu wird einem Prozess ein virtueller Adressraum zur Verfügung gestellt, der vom Kernel mit Hilfe der Memory Management Unit (MMU) verwaltet wird. Die MMU übernimmt dabei die Umrechnung (mapping) von virtuellen Adressen in physikalische Adressen. Hierbei galt es zu verhindern, dass Prozesse, die in einem nicht privilegierten Modus ausgeführt werden in Adressräume von Kernel-Prozessen reinschreiben können, um eine höhere Privilegstufe zu erreichen. Neben der bereits be­schriebenen Prozess- und Speicherverwaltung, übernimmt der Kernel auch das Power­Management. Er hat dabei die Aufgabe, den Energieverbrauch des Gerätes möglichst gering zu halten. Das wird dadurch realisiert, dass er beispielsweise nach einer be­stimmten Zeit, wenn der Benutzer keine Taste betätigt, automatisch den Ruhezustand aktiviert.

2.2.2 Sicherheit

Die noch weit verbreiteten Mobiltelefone der zweiten und dritten Generation mit den Symbian-Versionen 7.0 und 8.0 bieten nur wenig Sicherheit vor Angriffen. Das liegt daran, dass Programme für Symbian OS in C++ entwickelt werden können, und es dort kein Rechtemanagement für Zugriffe auf sicherheitskritische Funktionen gibt. Zu diesen Funktionen gehören bestimmte APIs, die beispielsweise Kosten verursachen oder die Datenintegrität gefährden können. Eine Anwendung kann solche Funktionen direkt aufrufen, ohne dass der Benutzer benachrichtigt wird. Oft nutzen Schadpro­gramme diese Möglichkeit aus, um über unterschiedliche APIs auf Systemfunktionen zuzugreifen und diese für eigene Zwecke zu missbrauchen. Ein Beispiel dafür ist „[e]in Trojaner namens „MetalGear.A“ [. Er] kombiniert mehrere schädliche Programme und ist darauf ausgerichtet, sich über Symbian-Geräte zu verbreiten. Er tarnt sich als eine Version des Spiels „Metal Gear Solid“. Beim Öffnen des Spiels werden alle installierten Programme deaktiviert und zudem eine neue Version des Cabir-Virus installiert, der anschließend [...] versucht, andere Smartphones via Bluetooth zu erreichen“ [Eren 2006].

Erst in der Symbian-Version 9.1 wurde ein neues Sicherheitsmodell mit dem Namen „Symbian Platform Security“ eingeführt. Dieses besteht aus den drei Konzepten: „Capabilities“, „Codesigning“ und „Data-Caging“, die jetzt kurz beschrieben werden: Capabilities: Als sicherheitskritisch eingestufte APIs werden von Capabilities geschützt. Wenn eine Anwendung solch ein API aufrufen möchte, dann muss sie dafür das Recht besitzen. Die Rechteverwaltung wird hier über Zertifikate gesteuert. Die sicherheitskritischen APIs selbst werden dabei noch in drei Gefahrenklassen eingeordnet.

Codesigning: Je nachdem welches API aus welcher Gefahrenklasse benutzt wird, muss die Signierung der Anwendung entweder vom Benutzer, von Symbian Signed selbst oder von Symbian Signed, jedoch mit einer Genehmigung des Geräteherstellers, durchgeführt werden. Die detaillierte Beschreibung eines allgemeinen Signiervorgangs findet sich in Kapitel 3.3.

Data-Caging: Das Sicherheitsmodell beinhaltet auch ein rechtegesteuertes Dateisy­stem, in dem Anwendungen ihren eigenen Bereich des Dateisystems nicht verlassen können. Dieses Konzept soll sicherstellen, dass sowohl System- als auch private Daten effektiv geschützt werden.

2.3 Windows Mobile

Windows Compact Edition (CE), später auch Windows Mobile genannt, wurde in Version 1.0 im Jahr 1996 von Microsoft vorgestellt. Es stellte ein modulares 32-Bit- Betriebssystem dar, das speziell für mobile und eingebettete Endgeräte entwickelt wurde. Bereits zwei Jahre später wurde Windows CE 2.0 vorgestellt. Dieses verfüg­te über eine Internationalisierung, eine Farbdarstellung mit 24-Bit, ActiveSync zur Synchronisation mit einem Desktop-PC und war vollständig modular aufgebaut. Das ermöglichte den Endgeräteherstellern eine selbstständige Konfiguration des Betriebssy­stems. Mit Windows PocketPC, welches auf Windows CE 3.0 basierte, stellte Microsoft im Jahr 2000 ein Betriebssystem vor, welches sowohl über ein vereinfachtes Nutzerin­terface verfügte als auch eine optimierte Performance aufwies. Neue und verbesserte Anwendungen sowie Multimediafähigkeiten rundeten die neue Version ab. Hier mus­sten jedoch noch die Netzwerkkonnektivität sowie das Speichermanagement verbessert werden. Das erfolgte dann im Jahr 2002 bei der Einführung von Windows CE.NET. Dieses neue Betriebssystem fügte sich nahtlos in das .NET-Konzept ein und stellte zudem Adhoc-Networking, die Unterstützung von vier Architekturen und zahlreichen Plattformen sowie eine nochmals verbesserte Benutzeroberfläche zur Verfügung. Be­reits ein Jahr später wurde Windows Mobile 2003 veröffentlicht, welches auf Windows CE 4.20 basierte. Dieses bot eine verbesserte Bluetooth-Schnittstelle, bei der die Un­terstützung für Headsets und den Dateiversand eingeführt wurde. Ferner enthielt es überarbeitete Versionen der Standard-Programme Pocket Outlook, Pocket Internet Explorer und Windows Mediaplayer und unterstützte den Anschluss von zusätzlichen Tastaturen. Bereits ein knappes Jahr später folgte dann Windows Mobile 2003 Se- cond Edition. Dieses Betriebssystem bot nur wenig Neues. Die Bildschirmauflösung von 640x480 Bildpunkten, der Wechsel der Ansicht von Vertikal auf Horizontal und die Unterstützung von WPA waren die einzigen Neuerungen. Mit Windows Mobile 5.0 kam ein Jahr später dann der Nachfolger von Windows Mobile 2003 heraus, der viele Neuerungen mit sich brachte. Dieses Betriebssystem basierte auf Windows CE 5.0 und nutzte das .NET Compact Framework in Version 1.0 SP2. Eine Vielzahl an neuen An­wendungen sowie die Unterstützung für GPS und vollständige Tastaturen waren nur einige der Neuerungen. Mit Windows Mobile 6 wurde im Februar 2007 dann das neue­ste Windows für mobile Endgeräte veröffentlicht. Dieses basiert auf Windows CE 5.2, welches in großen Teilen dem Kern von Windows Mobile 5.0 gleicht. Die Benutzerober­fläche wurde noch einmal überarbeitet und das Design wurde an Windows Vista an­gelehnt. Zu den wichtigsten Neuerungen zählen hier: die Einführung der IP-Telefonie, eine Speicherkarten-Verschlüsselung, die vereinfachte Verwaltung von Zertifikaten und die Einführung eines „Information Rights Management“ zum Schutz sensibler Daten.

2.3.1 Systemarchitektur

Windows CE.NET unterstützt die Prozessorarchitekturen Intel x86, MIPS, ARM und Hitachi SuperH. Trotz der Ähnlichkeiten von Windows CE zu Microsofts PC- Betriebssystem Windows XP und der großen Anzahl gleicher API-Befehle können auf Windows CE keine Windows-Programme ausgeführt werden.

Das Betriebssystem lässt sich in die vier Hauptmodule bzw. Hauptmodulgruppen Ker­nel, Object Store, Graphics, Windowing and Events Subsystem (GWES) und „Com­munication“ unterteilen. Neben diesen gibt es auch noch zusätzliche Module, z.B. zur Verwaltung von installierbaren Gerätetreibern. Im Folgenden werden die einzelnen Modulgruppen näher beschrieben:

Kernel: Der Kernel stellt die grundlegenden Dienste, wie Prozess- und Threadbehand- lung, Speicher-Management sowie Ausnahmebehandlung, zur Verfügung. Zudem kann die Funktionalität des Kernels durch optionale Komponenten ergänzt werden. Hierzu kann man beispielsweise das von Desktop-PCs bekannte DirectX zählen, welches zur Handhabung und Unterstützung von Multimedia-Inhalten benötigt wird. Der Kernel bietet viele Vorzüge moderner Betriebssysteme. Er arbeitet mit präemptiven Multi­tasking, d.h. er unterteilt einen Zeitraum in Zeitscheiben definierter Länge und weist diesen den einzelnen Prozessen zu und unterstützt Multithreading, d.h. die gleichzei­tige Abarbeitung mehrerer Threads, wobei diese jedoch eine feste Priorität besitzen.

Object Store: Der Object Store bietet eine Schnittstelle zum Lesen und Speichern von Daten auf unterschiedlichen Dateisystemen. Er kann sowohl als Ablagespeicher als auch als Programmspeicher genutzt werden und verfügt dafür vorwiegend über ein bis zu 256 MB großen RAM-(Random Access Memory) Speicher. Im Betriebssystem selbst gibt es drei Möglichkeiten, Daten zu speichern. Beabsichtigt man Benutzerdaten und Einstellungen des Betriebssystems zu speichern, so benutzt man dafür, ähnlich wie bei Windows XP, die System Registry. Sollen strukturierte Daten, wie z.B. Adres­sen und Kalender, gesichert werden, gibt es hierfür eine Art Datenbank, in der auch einfache Datenbankoperationen ausgeführt werden können. Als letztes gibt es noch das Dateisystem für beliebige andere Dateien. Sollte der Platz hier nicht ausreichen, hat man zudem auch die Möglichkeit, auf externe Medien mit unterschiedlichen FAT- Dateisystemen zuzugreifen.

Graphics, Windowing and Events Substem (GWES): Das GWES stellt die Schnittstelle zwischen dem Benutzer, dem Betriebssystem und den Applikationen dar. Es steuert die Grafik, alle fensterbezogenen Features und reagiert auf die Eingaben des Benutzers, die über die Tastatur oder einen Touchscreen erfolgen können. Hierfür werden die aus Windows XP bekannten User- und GDI-(Graphics Device Interface) Subsysteme sowie der Event- und Window-Manager eingesetzt.

Communikation: Das Kommunikationssubsystem ist für den Informationsaustausch mit anderen Geräten zuständig. Hierbei werden zwei unterschiedliche Kommunikati­onsmodelle unterstützt: zum Einen die serielle Kommunikation mit Hilfe einer seriellen Schnittstelle, USB oder Infrarot und zum Anderen die Netzwerk-Kommunikation über Netzwerk-Protokolle wie das Transmission Control Protocol über IP (TCP/IP), das Hypertext Transfer Protocol (HTTP), das File Transfer Protocol (FTP), das Point-to- Point Protocol (PPP) sowie das Serial Line Internet Protcol (SLIP), welches zur IP- Netzwerkverbindung zwischen zwei Computern über eine serielle Schnittstelle genutzt wird. Die große Anzahl an unterstützten Protokollen bringt mit sich, dass Windows CE auch bereits einige Server-Technologien integriert hat. Hierzu zählen File-Server, FTP-Server, Print-Server, Telnet-Server, Web-Proxy und Web-Server. Die Sicherheit bei der Übertragung der Daten wird durch den Einsatz der SSL-(Secure Socket Layer) Technologie gewährleistet.

2.3.2 Sicherheit

Das Sicherheitsmodell von Windows Mobile besteht aus den drei wesentlichen Kompo­nenten: „Security Roles“, „Security Policies“ und „Codesigning“. Im Folgenden werden diese kurz beschrieben:

Security Roles: Als „Security Roles“ werden Benutzer mit bestimmten Rechten be­zeichnet. Das bedeutet, dass nur ein Benutzer mit den entsprechenden Rechten die Einstellungen der jeweiligen Gerätefunktion ändern kann. Die drei häufigsten Rollen von Benutzern sind: Manager, mit einem unbeschränkten Zugriff auf alle Systemre- sourcen; Authenticated User, mit dem Recht Einstellungen zu ändern, die nur authen­tifizierte Nutzer ändern können und Operator, mit Rechten des Netzbetreibers. Security Policies: Die Security Policies sorgen für eine Regelung der grundsätzlichen Sicherheitseinstellungen in einem Gerät. Eine Security Policy kann dabei entweder „er­lauben“ (allow) oder „verbieten“ (deny) sein. Ein Beispiel für eine Security Policy wäre: „Erlaube oder verbiete die Ausführung unsignierter Anwendungen“. Insgesamt gibt es mehr als ein Dutzend verschiedene Security Policies, über die die Sicherheit im Gerät sehr detailliert geregelt werden kann.

Codesigning: Wie auch bei J2ME und Symbian OS gibt es bei Windows Mobile die Möglichkeit, eine Anwendung signieren zu lassen. Die Signierung übernimmt Mobi- le2Market, Microsofts Gegenstück zu Symbian Signed. Bei der Signierung ist es wich­tig, ob eine Anwendung nur normale Rechte oder auch Zugriff auf sicherheitskritische APIs benötigt. Im ersten Fall erfolgt die Signierung über eine Certificate Authority (CA). Benötigt die Anwendung jedoch auch Zugriff auf privilegierte APIs, so muss zuerst die Genehmigung von Microsoft über Mobile2Market eingeholt werden.

Wie auch bei Symbian OS gibt es für Windows Mobile ebenso Schadprogramme, die versuchen, die Kontrolle über das Gerät zu erlangen und Daten auszuspionieren. Das erste Backdoor-Programm „Backdoor.WinCE.Brador.a“ für Pocket PCs, die auf Win­dows Mobile und Windows CE basieren, hat Kaspersky Labs im Jahr 2004 gefunden. Die Experten im Bereich der IT-Sicherheit schreiben darüber: „WinCE.Brador.a ist das erste Programm (Größe: 5632 Byte), das per Fernzugriff auf mobile Endgeräte mit den Betriebssystemen Windows Mobile und Windows CE zugreifen kann. Nach dem Start erstellt das Backdoor-Programm seine eigene Verknüpfung mit dem Na­men svchost.exe im Autostart-Ordner von Windows und erhält damit beim Starten des PDAs die Kontrolle über das System. Das Backdoor-Programm ermittelt die IP- Adresse des infizierten Gerätes und sendet sie per E-Mail an den Virus-Autor mit dem Hinweis, dass das Programm aktiv und am Netz ist. Danach öffnet er Port 2989 zum Empfang verschiedenster Befehle. Die Hauptfunktion von WinCE.Brador.a besteht im Öffnen von Ports infizierter PDAs mit dem Ziel, dem Autor die maximale Kontrolle über das Gerät zu verschaffen. Der Virus kann sich nicht selbst vermehren, kann aber als scheinbar harmloses Programm mit der für Trojaner üblichen Vorgehensweise auf andere PDAs gelangen. Es verbreitet sich entweder als infizierte Anlage einer E-Mail- Nachricht, über das Internet oder über eine ActiveSync-Verbindung mit einem PC. [Kaspersky 2004]“

3 Sicherheitskonzepte von J2ME

In diesem Kapitel werden die Sicherheitskonzepte von J2ME im Detail behandelt. Das ist an dieser Stelle erforderlich, da die späteren Sicherheitsanalysen auf dem Wissen aus diesem Teil der Arbeit aufbauen werden. Zu den hier vorgestellten Si­cherheitskonzepten zählen die die Low-level Security mit der Bytecode Verifikation und die Application-level-Security mit dem Sandkasten-Modell. Ferner wird bei der Beschreibung von MIDlets zwischen vertrauenswürdigen Midlet-Suites, denen ein Au- torisierungsmodell zu Grunde liegt und nichtvertrauenswürdigen Midlet-Suites, unter­schieden. Am Ende des Kapitels wird die Verifikation sowie die Signierung von Code (Code-Signing) vorgestellt. Die hier aufgezählten Konzepte werden nun ausführlicher beschrieben.

3.1 CLDC

In diesem Abschnitt erfolgt die Beschreibung der in der CLDC-implementierten Sicher­heitsmodelle. Hierzu zählen vor allem die Bytecode-Verifikation und das Sandkasten­Modell. Diese werden nun im Folgenden näher beschrieben.

3.1.1 Low-level Security

„Die systemnahe (low-level) Sicherheit wird auch als VM-Sicherheit bezeichnet und stellt sicher, dass eine Anwendung, die in der VM ausgeführt wird, sich auch an die Semantik der Java-Programmiersprache hält. Class-Dateien, die schlecht programmiert oder manipuliert worden sind, dürfen weder die VM zum Absturz bringen, noch das Gerät auf der sie ausgeführt wird in irgendeiner Form schädigen“ [vgl. JSR0139 2003].

3.1.1.1 Bytecode Verifikation

Es lässt sich durchaus sagen, dass der Java-Compiler von Sun Microsystems sicheren Bytecode erzeugt. Er stellt sicher, dass Typsicherheit des Codes gewährleistet wird, und sorgt für die Einhaltung aller statischen und strukturellen Einschränkungen, die für den Code gelten sollen. Regeln wie: „Keine Rücksprungadresse darf von einer lo­kalen Variable geladen werden“, „Kein Array darf mehr als 255 Dimensionen haben“ oder „Keine lokale Variable darf gelesen werden, bevor ihr ein Wert zugeordnet wur­de“, die in der Spezifikation der virtuellen Maschine festgelegt sind [Lindholm 1999], sollen dafür sorgen, dass diese niemals in einen illegalen Zustand versetzt werden kann. Würde das dennoch passieren, dann könnte das dazu führen, dass Anwendungen auf Speicherbereiche anderer Anwendungen zugreifen könnten und die Möglichkeit hätten, Kernbibliotheken von Java zu überladen. Das hätte zur Folge, dass Programmteile erhöhte Rechte erlangen könnten und so die Maßnahmen zur Anwendungssicherheit umgehen würden. Obwohl der Java-Compiler von Sun als relativ sicher gilt, ist es trotzdem möglich, Bytecode zu erzeugen, der die Regeln der VM nicht beachtet [vgl. Felten 1999]. Mit Hilfe eines Assemblers für die JVM, wie beispielsweise Jasmin^[3] ihn darstellt, oder durch das einfache Ändern eines bereits kompilierten Codestücks, ist es möglich, fehlerhaften Bytecode zu erzeugen, der bei Ausführung, die VM durchein­ander bringen könnte. Aus diesem Grund musste eine zusätzliche Instanz geschaffen werden, die jedes Java Programm vor der Ausführung nochmals verifiziert. Das dafür zuständige Modul der virtuellen Maschine, welches Verifizierer genannt wird, stellt sicher, dass Class Dateien keine illegalen Anweisungen enthalten, dass diese nicht in einer illegalen Reihenfolge ausgeführt werden und diese keine Referenzen auf illegale Speicherorte oder Speicherbereiche, die außerhalb des Heaps der VM liegen, enthalten [JSR0139 2003].

Mobile Geräte, die mit sehr beschränkten Ressourcen zurechtkommen müssen, benö­tigen einen Verifizierer, der möglichst effizient arbeitet und den Prozessor nur wenig belastet. Der speziell für die Kilobyte Virtual Machine (KVM) entwickelte Verifizierer erfüllt genau diese Anforderungen. Er benötigt nur ca. 10 Kilobyte Binärcode und weniger als 100 Bytes dynamischen Speichers zur Verrichtung seiner Arbeit. „Im Ver­gleich dazu braucht die konventionelle Verifikation von Class Dateien, wie sie bei Java SE zu finden ist, mehr als 50 Kilobyte Binärcode und mindestens 30 bis 100 Kilobyte dynamischen Speichers zur Laufzeit“ [JSR0139 2003]. Zudem wurde der konventio­nelle iterative Verifikationsalgorithmus durch einen schnelleren Algorithmus ersetzt, der nur einen einzigen linearen Durchlauf des Bytecodes machen muss. Möglich wur­den die Anpassungen durch die Verlagerung der rechenintensivsten Verifikationsarbeit vom mobilen Endgerät auf den Entwickler-PC [vgl. Sohr 2001]. Die Verifikation erfolgt dabei in zwei Schritten. Im ersten Schritt führt der Anwendungsentwickler eine Pre- Verifikation der Klassen auf seiner Entwicklungsplattform durch. Im zweiten Schritt muss nur noch eine Validierung der bereits geprüften Klassen auf dem mobilen End­gerät erfolgen. Im Folgenden werden die beiden Vorgänge näher beschrieben.

Pre-Verifikation auf der Entwicklungsplattform Die Pre-Verifikation auf der Ent­wicklungsplattform optimiert die Ausführungsströme, entfernt nicht benötigten By­tecode und fügt den Klassen zusätzliche Stack-Map-Attribute zur Erleichterung der Laufzeit-Verifikation hinzu. „Diese stellen eine Art Fingerabdruck der Anwendung dar und definieren verschiedene Werte für jede Instruktion“ [Gowdiak 2004]:

- Die Anzahl der Register.
- Den Systemstatus nach der Abarbeitung (durch Simulation).
- Die Größe des genutzten Stacks.
- Den Typ des verbundenen Datenobjekts.

Durch das Hinzufügen dieser Stack-Map-Attribute vergrößern sich die Class-Dateien in der Regel um etwa 5 bis 15 Prozent. Trotz dieser Veränderungen können sie weiterhin von herkömmlichen Verifizierern verarbeitet werden, da diese die zusätzlichen Daten einfach ignorieren können.

Mit dem Ziel den Verifizierungsprozess auf dem mobilen Endgerät noch mehr zu be­schleunigen und die Laufzeit-Verifikation signifikant einfacher zu machen, werden „Sub­routinenaufrufe, die die speziellen Bytecode-Sequenzen jsr, jsr_w, ret und wide ret enthalten, durch semantisch äquivalenten Bytecode ersetzt“ [JSR0139 2003].

Verifikation auf dem Gerät Auf dem Gerät überprüft der Verifizierer die Class- Dateien mit Hilfe der Stack-Map-Attribute, die beim Pre-Verifikationsprozess erzeugt wurden. Dank dieser Attribute reicht ein einziger linearer Durchlauf über den By­tecode. Dabei wird jede gültige Anweisung mit dem dazugehörigen Eintrag in der Stack-Map verglichen. Der Verifikationsprozess setzt sich im Wesentlichen aus diesen Schritten zusammen [JSR0139 2003]:

- Für jede Methode reserviert der Verifizierer genug Speicher, um die Typen, die
lokalen Variablen und die Elemente des „Operand Stacks“ (auf diesem werden die Befehle zur Methodenausführung abgearbeitet) aufzunehmen.
- Für jede Methode initialisiert der Verifizierer die Typen der Methodenzeiger (this), die Argumente der Methode und den leeren „Operand Stack“.
- Der Verifizierer führt eine Bytecodeverifikation mit Hilfe einer linearen Iteration aller Instruktionen einer Methode durch.
- Der Verifizierer überprüft, ob die letzte Instruktion einer Methode ein unbeding­ter Sprungbefehl, ein return-Befehl, ein athrow-Befehl, ein tableswitch-Befehl oder ein lookupswitch-Befehl ist. Würde diese Überprüfung nicht erfolgen, so könnte ein Programm über die Code-Grenze hinaus ausgeführt werden.

Da MIDP nicht das vollständige Sicherheitsmodell von Java umfasst, wurden eini­ge J2SE-Merkmale in MIDP gesperrt, um potentielle Sicherheitsrisiken zu minimie­ren. Um beispielweise zu verhindern, dass Kernklassen von Java unzulässig überla­den werden können, wurden in der VM des MIDP keine benutzerdefinierten Klassen­Ladeprogramme (loader) zugelassen. Auch gibt es in MIDP keine Unterstützung des Java Native Inferfaces (JNI) bzw. des Reflection APIs. „Bei J2SE bietet JNI die Mög­lichkeit mit Java native Methoden aufzurufen, die nicht in Java implementiert sind“ [vgl. Ullenboom 2004].

Selbst mit der Durchsetzung dieser strengen Sicherheitsmaßnahmen darf nicht der gan­ze Code, der die Bytecode Verifikation passiert, ausgeführt werden. Eine ganze Reihe an sicherheitskritischen APIs dürfen im Regelfall nur mit vorheriger Bestätigung des Benutzers aufgerufen werden dürfen. Hier spielt das Code-Signing-Konzept, bei der ein MIDlet (das ist eine MIDP-Anwendungen) digital unterschrieben werden kann, die entscheidende Rolle (siehe Abschnitt 3.3).

3.1.2 Application-level Security

„Die Sicherheit der Anwendungsschicht sorgt dafür, dass Java-Anwendungen nur auf APIs, Systemresourcen und andere Komponenten zugreifen dürfen, wenn das Gerät oder die Java-Anwendungsumgebung diesen Vorgang genehmigt“ [vgl. JSR0139 2003]. Für die Durchsetzung dieser Maßnahmen, sorgt das sogenannte Sandkasten (sandbox)- Modell, welches im Folgenden beschrieben wird.

3.1.2.1 Das Sandkasten-Modell

Java-Sicherheit basiert auf dem sogenannten Sandkasten-Modell, welches ein Schlüs­selkonzept in der J2ME-CLDC-Sicherheit darstellt. Dieser Sandkasten stellt eine ge­schlossene Umgebung dar, in dem nicht-vertrauenswürdiger Code ausgeführt werden kann, ohne das Risiko eingehen zu müssen, dass dieser gefährliche Aktionen durchfüh­ren könnte. Eingeführt wurde das Sandkasten-Modell auf der Ebene der Konfiguratio­nen (CLDC) und der ersten Version des Profils (MIDP 1.0). In MIDP 1.0 kann die Herkunft von heruntergeladenen MIDlets nicht verifiziert werden. Deswegen werden dort alle heruntergeladenen MIDlets automatisch als nicht vertrauenswürdig eingestuft und einer nicht-vertrauenswürdigen Domäne zugeordnet [vgl. Debbabi 2007]. Diese erlaubt es dem MIDlet nicht auf sicherheitskritische APIs zuzugreifen. Eine genauere Beschreibung von nicht-vertrauenswürdigen Domänen erfolgt im nächsten Abschnitt. Im CLDC-Sandkasten-Modell muss eine Anwendung in einer geschlossenen Umgebung ausgeführt werden, in der die Anwendung nur Zugriff auf die Bibliotheken enthält, die von der Konfiguration, den Profilen und anderen von dem Gerät unterstützten Klassen definiert wurden [vgl. JSR0139 2003]. Alle MIDlets werden gezwungenermaßen inner­halb des Sandkasten ausgeführt und haben nur beschränkten Zugriff auf die Systemre- sourcen. Das CLDC-Sandkasten-Modell kann hauptsächlich durch vier Anforderungen charakterisiert werden. Diese werden im Folgenden aufgeführt [vgl. JSR0139 2003]:

- Java-Klassen müssen korrekt verifiziert werden und ihre Gültigkeit muss nach­gewiesen werden können.
- Der Vorgang des Herunterladens, des Installierens und der Verwaltung von MID- lets muss in die VM eingebaut sein, um zu gewährleisten, dass das Klassen­Ladeprogramm der VM nicht von Anwendungsentwicklern überschrieben, aus­getauscht oder umkonfiguriert werden kann.
- Dem Anwendungsentwickler darf nur eine geschlossene und vorgegebene Anzahl an Java-APIs zur Verfügung stehen.
- Für eine Anwendung darf es nicht möglich sein, neue Bibliotheken herunterla­den zu können, die native Funktionen enthalten würden oder Zugriff auf native Funktionen zu erhalten, die nicht Teil der von CLDC, MIDP oder dem Hersteller zur Verfügung gestellten Java-APIs sind.

3.1.3 End-to-End Security

Die Ende-zu-Ende-Sicherheitslösung basiert auf einem Modell, welches garantiert, dass jeder Vorgang der auf einem Gerät durchgeführt wird entlang des gesamten Weges bis zu einem anderen Gerät (beispielsweise einem Server im Internet) geschützt ist. Verschlüsselung wäre beispielsweise eine Möglichkeit, mit der man dieses Vorhaben realisieren könnte.

Dieses Modell fällt jedoch außerhalb des Zuständigkeitsbereichs der CLDC- Spezifikation, so dass APIs aus J2ME-Profilen diese Aufgabe übernehmen müssen. Eines davon ist beispielsweise das Security and Trust Services API (SATSA), welches im JSR 177 spezifiziert wurde.

3.2 MIDP 2.0 - Sicherheit

Um die MIDP-Sicherheitskonzepte besser verstehen zu können, erfolgt deren Beschrei­bung anhand der Applet-Sicherheit, die bereits im Java Development Kit (JDK) 1.1 eingeführt worden ist. Mit der Veröffentlichung des JDKs wurde die Unterstützung für digitale Signaturen eingeführt, die es ermöglichten eine Klassendatei eines Applets nach ihrer Entwicklung zu signieren, und sie dann zusammen mit der Signatur in der JAR (Java Archive)-Datei zu speichern. Bei jeder Installation des JDKs kann angege­ben werden, welchen öffentlichen Schlüsseln vertraut werden soll. Wenn dann ein digi­tal signiertes Applet heruntergeladen wurde und sein öffentlicher Schlüssel verifiziert und als vertrauenswürdig anerkannt wurde, dann hat man das Applet so behandelt, als ob es sich um vertrauenswürdigen lokalen Code handeln würde, der volle Systemrechte besitzt [vgl. Gong 2003].

Betrachtet man die Funktionsweise der Applet-Sicherheit detaillierter, so werden se­quentiell folgende Schritte ausgeführt:

- Bevor die Übertragung des Applets beginnt, signiert der Applet Server die JAR- Datei des Applets mit Hilfe seines digitalen Zertifikats.
- Nach dem Empfang verifiziert der Sicherheitsmanager von Java auf der Brow­serseite die Signatur und entscheidet, ob der Herkunft und der Integrität der Anwendung vertraut werden kann.
- Wenn die digitale Signatur nicht verifiziert werden kann, wird der Vorgang mit einer Fehlermeldung abgebrochen. Kann die Signatur verifiziert werden, dann benutzt der Sicherheitsmanager das digitale Zertifikat, um die „Protection Do- mainfür dieses Applet zu ermitteln. Diese Domänen definieren die Zugriffsrechte, die einem Applet erteilt werden können.
- Sobald die Verifikation erfolgreich abgeschlossen wurde, wird die Anwendung beim Client ausgeführt.

Hierbei muss beachtet werden, dass jede „Protection Domain“ einen Satz von Regeln enthält, um den Zugriff auf einzelne APIs gewähren zu können. Beispielsweise erhalten Anwendungen von nicht vertrauenswürdigen Quellen keine Erlaubnis, Speichermedien zu lesen und zu schreiben oder Netzwerkverbindungen aufzubauen.

CDLC-basierter Code kann genauso wie ein Java Applet signiert und distributiert werden. Dieses Verfahren wurde jedoch aufgrund der geringen Rechenleistung und des kleinen Speichers mobiler Endgeräte noch nicht in der MIDP 1.0 Spezifikation eingeführt. Allerdings unterstützt die überarbeitete MIDP Spezifikation, die nun in Version 2.1 vorliegt, das vorgestelle Sicherheitsmodell mit einem domainbasierten Si­cherheitsmanager. Die neue Version unterstützt also sowohl die Signierung von Code, als auch die Verifizierung von digitalen Zertifikaten. Um auch das Herunterladen von sicherem Code zu ermöglichen, stellt MIDP ab Version 2.0 auch eine OTA (Over the Air)-Spezifikation zur Verfügung. Diese beschreibt im Detail [JSR0118 2006]:

- wer die Befugnis hat, drahtlose Anwendungen zu installieren und zu löschen
- welche Arbeitsvorgänge von Benutzern bestätigt werden müssen und welche au­tomatisch durchgeführt werden können
- welche Sicherheitswarnungen dem Benutzer angezeigt werden
- welche Daten zur Verfügung gestellt werden müssen, wenn Anwendungen durch eine neue Version ersetzt werden sollen

3.2.1 Autorisierungsmodell

Wie bereits zuvor beschrieben, werden in der ersten Spezifikation von MIDP (Versi­on 1.0) alle MIDlets in einem Sandkasten ausgeführt. Dieser führt den Code in einer geschützten Umgebung aus und verhindert den Zugriff auf sicherheitskritische Funktio­nen und APIs des Gerätes, da das Konzept der digitalen Signaturen noch nicht einge­führt ist. Dieses Sandkasten-Modell wird bei nicht vertrauenswürdigen MIDlet-Suites auch in der neusten MIDP-Spezifikation (Version 2.1) noch genauso angewendet. Hin­zugekommen ist hier nun das Konzept von vertrauenswürdigen MIDlet-Suites, welches vertrauenswürdigen Applikationen den Zugriff auf sicherheitskritische APIs gewährt. Ob und wann ein Gerät bestimmt, dass einer MIDlet Suite vertraut werden kann und ihr somit der Zugriff gewährt wird, entscheidet die sogenannte „Domain Policy“. In die­ser Richtlinie wird für jede spezifizierte Domäne, ein Satz von APIs definiert, die aufge­rufen werden dürfen. Jedem MIDlet, dem nicht vom Gerät vertraut werden kann, wird als nicht vertrauenswürdig eingestuft und auch in diesem Modus ausgeführt. Sollten bei der Verifizierung des Vertrauensverhältnisses eines MIDlets ein Fehler auftreten, so wird dieses sofort zurückgewiesen. Im nächsten Abschnitt erfolgt die Beschreibung der Konzepte, die hinter vertrauenswürdigen und nichtvertrauenswürdigen „MIDlet- Suites“ stecken.

3.2.2 Vertrauenswürdige Midlet-Suites

Die Sicherheit von vertrauenswürdigen MIDlet-Suites basiert auf sogenannten „Pro­tection Domains“. Jede dieser Domänen definiert die Zugriffsrechte, die einer MIDlet- Suite innerhalb dieser Domäne erteilt werden können. Der Eigentümer der „Protection Domain“ legt fest, wie das Gerät erkennt und sicherstellt, dass es einer MIDlet-Suite vertrauen kann, und bindet diese an eine „Protection Domain“ mit den Zugriffsrechten für die geschützten APIs. Die Mechanismen, die das Gerät benutzt, um MIDlet-Suites zu identifizieren und ihnen zu vertrauen sind separat definiert. So kann gewährlei­stet werden, dass diese korrekt auf das Gerät und das Netzwerk zugeschnitten werden können [vgl. JSR0118 2006].

Vertrauenswürdige MIDlet-Suites nutzen die X.509 Public Key Infrastructure (PKI), um die digital signierten Zertifikate zu verteilen und zu authentisieren [Debbabi 2007]. Das Konzept hinter dem X.509-PKI-Standard wird in Abschnitt 3.3.2 beschrieben.

3.2.3 Nichtvertrauenswürdige Midlet-Suites

Eine MIDlet-Suite wird als nicht vertrauenswürdig bezeichnet, wenn das Gerät dem Ursprung und der Integrität der JAR-Datei nicht vertrauen kann. Nicht vertrauens­würdige MIDlet-Suites müssen in der Domäne nicht vertrauenswürdiger Anwendungen ausgeführt werden, in der ein Zugriff auf geschützte APIs entweder gar nicht gewährt wird oder dieser explizit durch den Benutzer bestätigt werden muss. Jede MIDP 1.0 konforme MIDlet-Suite ist auch in der neuen MIDP-Spezifikation lauffähig, in der sie aber als nicht vertrauenswürdig eingestuft wird. Hier kann sie alle APIs und Funktio­nen nutzen, die nicht als sicherheitskritisch gelten und die keine gesonderten Rechte zur Ausführung benötigen.

Die Domäne für nicht vertrauenswürdige MIDlet-Suites gewährt Zugriff auf die fol­genden APIs, ohne eine explizite Bestätigung des Benutzers einzuholen:

- javax.microedition.rms (Record Managment System APIs)
- javax.microedition.midlet (MIDlet APIs)
- javax.microedition.lcdui (User Interface APIs)
- javax.microedition.lcdui.game (Game APIs)
- javax.microedition.media (Multi-media APIs for ...)
- javax.microedition.media.control (... playback of sound)
Ferner gewährt die o.g. Domäne den Zugriff auf die folgenden geschützten APIs mit einer expliziten Bestätigung des Benutzers:
- javax.microedition.io.HttpConnection (Http Protocol APIs)
- javax.microedition.io.HttpsConnection (Https Protocol APIs)

3.3 Code-Signing

Im Bereich der mobilen Endgeräte spricht man von Code-Signing, wenn man Java Midlets mit einer digitalen Signatur versieht. Kauft man in einem Geschäft eine An­wendung oder ein Spiel, dann sieht man auf den ersten Blick, wer der Hersteller der Software ist und ob diese noch originalverpackt ist. Wenn das der Fall ist, dann kann man sicher sein, dass keine unerlaubten Veränderungen an der Software vorgenommen wurden. Sollte sich die gekaufte Ware trotzdem negativ auf dem System des Käufers verhalten, hat er die Möglichkeit, den Hersteller ausfindig zu machen und zur Re­chenschaft zu ziehen. Im Internet gestaltet sich der Vertrieb von Software schwieriger. Man kann nicht immer nachvollziehen, wer der Hersteller einer Software ist und ob diese nicht inzwischen von einer dritten Person manipuliert wurde. Um auch hier ei­ne Vertrauensbeziehung zwischen dem Hersteller einer Software und einem Kunden

[...]

---

^[1] http://www.jcp.org

^[2] http://www.symbian.com/phones/index.html

^[3] http://jasmin.sourceforge.net