Ausarbeitung - Department of Information Systems
Werbung
Westfälische Wilhelms-Universität Münster Ausarbeitung JavaME Sicherheitskonzepte Im Rahmen des Seminars Mobile Java Julian Chandra Hauck Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Christian Hermanns Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft Inhaltsverzeichnis 1 Vorwort...................................................................................................................... 3 2 Sicherheitskonzepte auf Laufzeitumgebungsebene ................................................... 4 3 4 2.1 Das Sandkasten Modell der KVM .................................................................... 4 2.2 Der Verifikationsprozess der KVM .................................................................. 5 Sicherheitskonzepte auf Konfigurationsebene .......................................................... 7 3.1 Einschränkungen der CDC ............................................................................... 7 3.2 Einschränkungen der CLDC............................................................................. 7 Sicherheitskonzepte auf Profilebene.......................................................................... 9 4.1 Profile für CDC................................................................................................. 9 4.2 Protection domains des MIDP 2.0 .................................................................. 10 4.2.1 4.2.2 4.2.3 4.3 4.3.1 4.3.2 4.3.3 4.4 5 Permissions ................................................................................................. 10 Protection domains ..................................................................................... 11 Zertifizierung eines MIDlets....................................................................... 12 Die Security and Trust Services API .............................................................. 13 Integritätsprüfung einer Nachricht.............................................................. 14 Authentifizierung einer Nachricht .............................................................. 15 Vertraulichkeit von Nachrichten................................................................. 17 Sichere Netzwerkprotokolle im MIDP 2.0 ..................................................... 19 Fazit ......................................................................................................................... 20 Literaturverzeichnis ........................................................................................................ 21 II Kapitel 1: Vorwort 1 Vorwort Neben der Einfachheit der Sprache, sind die zu Grunde gelegten Sicherheitskonzepte einer der Hauptgründe weshalb Java bzw. die Java Virtual Machine (JVM) so populär geworden ist. Die eingeschränkten Ressourcen mobiler Endgeräte und die Form der Kommunikation zwischen diesen verlangt ein vernünftiges Sicherheitskonzept auf Sprach-, Compiler- und Laufzeitumgebungsebene. Programme, die dynamisch heruntergeladen und ausgeführt werden, sowie Funkkommunikation stellen zwei typische Herausforderungen an die Integrität eines Systems dar. Im Rahmen dieser Arbeit werden die Sicherheitskonzepte der JavaME erläutert. Als einen Einstieg zu den hier nicht erläuterten allgemeinen konzeptionellen Grundlagen der JavaME, empfiehlt sich die Lektüre eines Grundlagen Buchs, wie z.B. [BrMo06]. Die Struktur dieser Arbeit ist eine „bottom-up“ Betrachtung des Aufbaus einer JavaME Implementierung. Beginnend mit den Sicherheitskonzepten der Kilobyte Java Virtual Machine (KVM) (Kapitel 2) auf unterster Ebene werden das Sandkasten Modell der KVM (Unterkapitel 2.1) sowie der zweistufige Verifikationsprozess (Unterkapitel 2.2) erläutert. Danach werden die Sicherheitskonzepte der darauf aufsetzenden Konfigurationsebene (Kapitel 3) betrachtet und dabei zwischen der für PDA’s und ähnliche Geräte erdachten Connected Device Configuration (CDC) (Unterkapitel 3.1) und der für Mobiltelefone erdachten Connected Limited Device Configuration (CLDC) (Unterkapitel 3.2) unterschieden. Schließlich folgen die Sicherheitskonzepte der Profilebene (Kapitel 4). Einer Zusammenfassung der Sicherheitskonzepte der CDC Profile (Unterkapitel 4.1) folgt eine Erläuterung zur Anforderung spezieller Rechte für MIDlet’s über die Sicherheitsdomänen des Mobile Information Device Profile 2.0 (MIDP 2.0) (Unterkapitel 4.2). Konzepte zur Implementierung von Integritäts-, Authentizitäts- und Vertraulichkeitsfunktionalität werden im Zusammenhang mit der Security and Trust Service API (SATSA) erläutert (Unterkapitel 4.4). Abschließend werden die Möglichkeiten zum Aufbau sicherer Netzwerkberbindungen behandelt (Unterkapitel 4.5). 3 Kapitel 2: Sicherheitskonzepte auf Laufzeitumgebungsebene 2 Sicherheitskonzepte auf Laufzeitumgebungsebene Über Mechanismen auf Laufzeitumgebungsebene muss sichergestellt werden, dass die Ausführung eines Programms das unterliegende System niemals destabilisiert. Normale JVM Implementierungen erlauben lokalen Programmen den Zugriff auf Systemressourcen (trusted execution). Wenn Code von außerhalb des Systems ausgeführt wird, muss dieser mit Einschränkungen bezüglich des Zugriffs auf Systemressourcen rechnen (untrusted execution). Diese Ausführung findet in einem so genannten Sandkasten statt und wird mit der Klasse SecurityManager kontrolliert. Direkte Speicherzugriffe sowie Zugriffe auf Bereiche außerhalb eines Arrays sind nicht möglich. Da das komplette Sicherheitskonzept einer JVM für Geräte mit geringen Kapazitäten zu speicherintensiv ist, wurde ein einfacheres Sicherheitsmodell für die KVM entworfen. Im Folgenden werden das Sandkasten Modell der KVM (Unterkapitel 2.1) sowie der zweistufige Verifikationsprozess (Unterkapitel 2.2) näher erläutert. 2.1 Das Sandkasten Modell der KVM Der Sandkasten (engl. sandbox) einer KVM ist eine Umgebung, in der ein einzelnes MIDlet ausgeführt wird. Das Nachladen von benötigten Klassen ist auf das JAR des MIDlets beschränkt, sodass MIDlets vollständig voneinander gekapselt sind. Zugriffe auf Geräte oder das System sind nur indirekt über die APIs von Konfigurationen, Profilen, optionalen Paketen und geräteherstellerspezifischen Bibliotheken möglich (vgl. Abbildung 1). System API der optionalen Pakete KVM Sandkasten API des Geräteherstellers MIDlet API des Profils API der Konfiguration Abbildung 1: Das Sandkasten Modell der KVM 4 Kapitel 2: Sicherheitskonzepte auf Laufzeitumgebungsebene Die Stabilität des unterliegenden Systems hängt damit von der richtigen Implementierung des Sandkastens auf Herstellerseite ab. Anwendungen können, abgeschirmt durch den Sandkasten, nicht mehr das unterliegende System destabilisieren. Es bleibt einer Implementierung überlassen, ob sie die parallele Ausführung mehrerer MIDlets in jeweils eigenen Sandkästen erlaubt. 2.2 Der Verifikationsprozess der KVM Die Implementierung einer KVM muss beim Starten eines MIDlets erkennen können, ob es sich möglicherweise um ein ungültiges JAR bzw. um ungültige classfiles handelt. Die Verifikation in einer JavaSE Implementierung benötigt mit seinen 30-100 KB dynamischen Speicher zu viel Kapazitäten für ein ressourcenbeschränktes CLDC Gerät. Daher wurde ein zweistufiger Verifikationsprozess erdacht, der den Speicherverbrauch auf unter 100 B senken kann, ohne jedoch Einschränkungen bei der Sicherheit vorzunehmen (vgl. [JSR30]). Die Verifikation wird dazu in eine off-device preverification und eine in-device verification zur Laufzeit zerlegt (vgl. Abbildung 2). Abbildung 2: Einordnung der Verifikation in den Prozess der Entwicklung und Nutzung Die Präverifikation, die normalerweise auf einer ressourcenstärkeren Hardware wie einem PC oder Server ausgeführt wird, tauscht jsr, jsr_w, ret und wide ret 5 Kapitel 2: Sicherheitskonzepte auf Laufzeitumgebungsebene Bytecodes mit semantisch gleichen Befehlen aus. Im nächsten Schritt werden jeder Methode der classfile zusätzliche Informationen, so genannte stack map Attribute, hinzugefügt. Die stack maps beschreiben den Typ der lokalen Variablen und der Elemente auf dem Operandenstack, welche zusammen auf dem Interpreterstack liegen (Für eine formale Definition der stack maps vgl. Appendix 1 von [JSR139]). Dieser Vorgang erhöht die Größe der Datei zwar ca. um fünf Prozent (vgl. [KVM]), erlaubt dem Gerät aber die Verifikation mit verringertem dynamischen Speicherbedarf und weniger VM Code. Die classfiles sind, dank des erweiterbaren Attribut Mechanismus von classfiles, aufwärts kompatibel zu Überprüfungen mit JavaSE und JavaEE Umgebungen, die die stack maps bei der Verifikation einfach ignorieren. Die in-device verification besteht im wesentlich aus vier Schritten (vgl. [JSR139]: • Im ersten Schritt wird der Bytecode linear gescannt und die Typen der lokalen Variablen und der Stackelemente in einem vorher dafür reservierten Speicher abgelegt. Es wird im weiteren Verlauf der Verifikation kein weiterer Speicher mehr reserviert. • Als nächstes folgt eine Initialisierung, in der der this Zeiger den abgeleiteten Typen der Instanzmethoden zugewiesen, Argument Typen und ein leerer Operandenstack initialisiert werden. • In diesem Schritt wird der Bytecode erneut linear gescannt und die stack maps mit den Wirkungen der Instruktionen abgeglichen bzw. die Typen entsprechend der stack maps gesetzt. • Als letztes wird sichergestellt, dass die letzte Instruktion der Methode ein unbedingter Sprung, eine Rückgabe, athrow, tableswitch oder lookupswitch ist. Zusätzlich zu den oben erwähnten Maßnahmen, wird in der Verifikation dafür gesorgt, dass Konstruktoren für nicht initialisierte Objekte nur genau einmal aufgerufen werden, dass die einzig legale Aktion auf nicht initialisierten Objekten der Aufruf des Konstruktors ist und dass nicht initialisierte lokale Objektvariablen bei alternativem Programmablauf nicht mehr auf dem Operandenstack liegen. Eine Unregelmäßigkeit im Verifikationsprozess führt zu einer Ablehnung der Klasse und somit zu einer Verhinderung der Ausführung. 6 Kapitel 3: Sicherheitskonzepte auf Konfigurationsebene 3 Sicherheitskonzepte auf Konfigurationsebene Es gibt z. Zt. zwei Implementierungen auf Konfigurationsebene. Die Connected Device Configuration (CDC), die für PDA’s und vergleichbare Geräte entworfen wurde (Unterkapitel 3.1) sowie die Connected Limited Device Configuration (CLDC), die auf mobile Endgeräte wie Handys zugeschnitten ist (Unterkapitel 3.2). Im Folgenden wird im Wesentlichen auf die sicherheitsrelevanten Unterschiede und Einschränkungen dieser Konfigurationen gegenüber der JavaSE eingegangen. 3.1 Einschränkungen der CDC Eine CDC Implementierung (vgl. [JSR36] für CDC 1.0.2 und [JSR218] für CDC 1.1.2) hat wesentlich umfangreichere Anforderungen an die Hardware als eine CLDC Implementierung. Daher konnten viele Sicherheitskonzepte der JavaSE portiert werden. Unter anderem fordert die Konfiguration eine vollständige Java Virtual Machine (JVM). Im Folgenden sind die sicherheitsrelevanten Merkmale aufgeführt: • Die Verifikation von Klassen wurde komplett übernommen. • Mit so genannten signed classes wird mit Zertifikaten die Integrität und Herkunft von Klassen gegenüber der JVM verifiziert und authentifiziert (zur Authentifizierung und Integritätsprüfung vgl. 4.3.2) und damit eine Möglichkeit geschaffen, Programme über Sicherheitsdomänen (engl. protection domains) mit unterschiedlichen Rechten auszustatten. • Die aus der JavaSE übernommenen security policies erlauben die Kontrolle der Zugriffsrechte von ausgeführtem Code. • Das komplette Security package ist aus der JavaSE übernommen. 3.2 Einschränkungen der CLDC Die CLDC ist eine Implementierung von JavaME für mobile Endgeräte mit eingeschränkten Ressourcen. Die Sicherheitskonzepte der JavaSE sind zu umfangreich um sie komplett zu übernehmen, daher wurde ein einfacheres Sicherheitskonzept entwickelt, welches aber die für Java typische Abschottung der in der JVM laufenden Programme vom System schafft. Die folgenden Einschränkungen zusammen mit dem 7 Kapitel 3: Sicherheitskonzepte auf Konfigurationsebene Sandkasten Modell der KVM (Unterkapitel 2.2) sind die Grundlage für die Sicherheit in mobilen Endgeräten mit CLDC 1.0 Implementierung (vgl. [JSR30]) und dienen gleichzeitig auch zur Anpassung an die ressourcenbeschränkte Umgebung: • Die Ergänzung oder Veränderung von Systembibliotheken (java.* und javax.microedition.*) ist verboten, da dies von schadhaftem Code als Angriffspunkt genutzt werden kann, um die vorhandenen sicheren Klassen und Methoden zu umgehen. • Die Reihenfolge, in der Klassen nachgeschaut werden (engl. classfile lookup order), darf nicht verändert werden, da sonst externe Bibliotheken einer Systembibliothek vorgeschaltet werden könnten. • Das Erstellen von benutzerdefinierten class loadern ist untersagt. Somit kann auf die Art und Weise des Ladeprozesses von Klassen in die KVM kein Einfluss genommen werden. • Das Java Native Interface (JNI), mit dessen API direkt betriebssystemspezifische Funktionen aufgerufen werden konnten, wurde entfernt, um das Sicherheitskonzept des Sandkastenmodells (vgl. Unterkapitel 2.1) nicht zu kompromittieren. An dessen Stelle tritt ein KVM Native Interface (KNI), das die statische Bindung von nativen Funktionen zur KVM erlaubt und demnach nur für Endgerätehersteller und Plattformanbieter geeignet ist (vgl. [Sch07]) Es gibt weitere Einschränkungen, welche großteils auf den verkleinerten Sprachumfang zurückzuführen sind (für eine vollständige Auflistung vgl. [JSR139]). 8 Kapitel 4: Sicherheitskonzepte auf Profilebene 4 Sicherheitskonzepte auf Profilebene Bisher wurden die Konzepte auf Sprach-, Compiler- und Laufzeitumgebungsebene betrachtet. Es ist sichergestellt, dass Programme richtig kompiliert sind und dass sie außerhalb des Sandkastens keinen Schaden verursachen. Sicherheitskonzepte werden aber nicht nur auf Ebene der Systemstabilität benötigt. Für eine Akzeptanz der Industrie und der Anwender mussten auch sinnvolle Konzepte auf Profilebene erdacht werden. Im Folgenden Kapitel werden zunächst die Sicherheitskonzepte der CDC Profile beschrieben (Unterkapitel 4.1). Vielen Entwicklern waren die Einschränkungen des MIDP 1.0 (vgl. [JSR37]) zu restriktiv und so wurde mit der Spezifikation des MIDP 2.0 (vgl. [JSR118]) für CLDC ein System von Sicherheitsdomänen (engl. protection domains) geschaffen, welches anschließend näher erläutert wird (Unterkapitel 4.2). Danach folgt eine Beschreibung der SATSA (Unterkapitel 4.3), die die Integrität (Abschnitt 4.3.1), Authentizität (Abschnitt 4.3.2) und Vertraulichkeit (Abschnitt 4.3.3) von ausgetauschten Daten auf CLDC Geräten ermöglicht. Das Kapitel schließt mit einer Beschreibung sicherer Netzwerkprotokolle im MIDP 2.0 (Unterkapitel 4.4). 4.1 Profile für CDC Derzeit sind drei Profile für die CDC verfügbar. Diese sind hierarchisch so angeordnet, dass ein weiter unten stehendes Profil jeweils eine Untermenge des in der Hierarchie höher stehenden Profils bildet. Das Foundation Profile (vgl. [JSR219] für Version 1.1.2) bildet die Grundlage und enthält die Java Pakete, die nicht grafische Grundfunktionalität bereitstellen. Das Personal Basic Profile (vgl. [JSR217]) und das darüber liegende Personal Profile (vgl. [JSR216]) ergänzen das Foundation Profile um grafische Funktionalität. Das Foundation Profile in der Version 1.1.2 enthält neben einer Untermenge von J2SE 1.4.2 Klassen (unter anderem auch Klassen aus java.security.*) zusätzlich die vorher optionalen packages Java Authentification und Authorization Service, Java Cryptography Extension und Java Secure Socket Extension. Da eine komplette Portierung der Sicherheitskonzepte von der JavaSE vorgenommen wurde, wird auf eine Beschreibung an dieser Stelle verzichtet. 9 Kapitel 4: Sicherheitskonzepte auf Profilebene 4.2 Protection domains des MIDP 2.0 In der Welt der mobilen Endgeräte und kleinen Bandbreiten sollen heruntergeladene MIDlets die Erlaubnis erhalten können Netzwerkverbindungen aufzubauen. Andererseits soll dies auch nicht unkontrolliert passieren, da dies unter Umständen zu hohen Kosten führen kann. Bei Geräten, die das ältere MIDP1.0 (vgl. [JSR37] implementieren, fehlt die Unterscheidung zwischen vertrauens- und nicht vertrauenswürdigen MIDlets völlig. Alle MIDlets arbeiten mit gleich restriktiven Sicherheitseinschränkungen. Mit dem MIDP 2.0 (vgl. [JSR188]) erhalten Hersteller die Möglichkeit, ein System von Sicherheitsdomänen zu spezifizieren und MIDlets entsprechend ihrer Vertrauenswürdigkeit mehr Rechte zu erteilen. 4.2.1 Permissions Für eine MIDP 2.0 Implementierung ist vorgesehen, dass einige Netzwerkprotokolle nur nach Erteilung einer Berechtigung (engl. permissions) freizugeben sind. Ein MIDlet kann die folgenden Berechtigungen anfordern: • javax.microedition.io.Connector.http • javax.microedition.io.Connector.https • javax.microedition.io.Connector.socket • javax.microedition.io.Connector.serversocket • javax.microedition.io.Connector.ssl • javax.microedition.io.Connector.datagram • javax.microedition.io.Connector.datagramreceiver • javax.microedition.io.Connector.comm • javax.microedition.io.PushRegistry In der [JSR248] sind zusätzlich Berechtigungsgruppen spezifiziert, die die Anforderungen von Berechtigungen und den Umgang mit diesen erleichtern. Für das MIDP 2.0 sind das z.B. die Net Access, Low Level Net Access, Application Auto Invocation und Local Connectivity Berechtigungsgruppen, deren Funktion sich aus dem Namen ableiten. 10 Kapitel 4: Sicherheitskonzepte auf Profilebene Die oben aufgeführten Berechtigungen und Berechtigungsgruppen können von optionalen Paketen erweitert werden. So definiert z.B. die in Unterkapitel 4.4 erläuterte SATSA noch zusätzlich folgende Berechtigungen: • javax.microedition.apdu.aid • javax.microedition.apdu.sat • javax.microedition.jcrmi • javax.microedition.securityservice.CMSMessageSignatureService 4.2.2 Protection domains Die Erteilung von Berechtigungen geschieht dabei nicht auf Ebene des Programmcodes, sondern wird indirekt über die Sicherheitsdomäne in der das MIDlet gestartet wird geregelt. Es werden in aller Regel vier Sicherheitsdomänen definiert: • Gerätehersteller (manufacturer domain) • Betreiber (operator domain) • Vertrauenswürdige Dritte (identified third party domain) • Vertrauensunwürdige Dritte (unidentified third party domain, vor MIDP2.0.1 untrusted) Eine Sicherheitsdomäne definiert allowed und user permissions. Alle permissions, die nicht allowed oder user sind, werden von der Sicherheitsdomäne bei Anforderung abgelehnt. Während allowed permissions ohne weiteres vom MIDlet nutzbar sind, wird bei user permissions der Nutzer zur weiteren Vorgehensweise befragt. Der Nutzer muss dann über so genannte interaction modes entscheiden, ob eine Erlaubnis einmal (oneshot), bis zur Terminierung des MIDlets (session), bis zur Deinstallation des MIDlets (blanket) oder gar nicht (no) zu erteilen ist. Der Programmierer hat nun die Möglichkeit im JAD die Berechtigungen zu integrieren. Dabei wird in notwendige, solche die zur Lauffähigkeit zwingend erforderlich sind, und optionale, solche die brauchbar aber nicht zwingend erforderlich sind, unterschieden. Sie werden in den Attributen MIDlet-Permission und MIDlet-Permission-Opt mit Komma getrennt aufgeführt. Vor der Installation kann mithilfe der JAD Attribute überprüft werden, ob das Programm in der Sicherheitsdomäne überhaupt die nötigen Berechtigungen hat und ggf. die Installation abbrechen, ohne dass der Nutzer dies später 11 Kapitel 4: Sicherheitskonzepte auf Profilebene zur Laufzeit testen muss. Berechtigungen die als user permissions definiert sind, fordern bei Anforderung durch ein MIDlet den Nutzer zur Berechtigung oder Ablehnung auf. Darüber hinaus kann ein MIDlet seine Berechtigungen zur Laufzeit mit der Methode checkPermission() erfragen, um so z.B. seinen Programmablauf zu steuern. 4.2.3 Zertifizierung eines MIDlets Um nun einem Endgerät die Möglichkeit zu geben zu entscheiden, in welcher Sicherheitsdomäne das MIDlet gestartet werden kann, muss die Herkunft des MIDlets sichergestellt sein. Dazu wurde von Seiten der Industrie das Java-Verified-Programm ins Leben gerufen. Nach einem automatisierten Vortest, muss das MIDlet von einem Testhaus „manuell“ auf Produktqualität getestet werden, bevor eine Signatur des MIDlets z.B. mit einem RSA X.509 Version 3 Verfahren bei einer Certificate Authority (CA) ermöglicht wird. Das MIDlet wird dazu gesichert einem Testhaus übermittelt. Nach erfolgreichem Test gilt das MIDlet als Java Verified und muss von einer CA signiert werden. Dazu wird ein Zertifikat für den Entwickler generiert, welches mit dem Hauptzertifikat signiert wird. Nachdem die Anwendung mit dem Zertifikat des Anwendungsentwicklers signiert wurde, wird die JAD Datei entsprechend mit Informationen ergänzt. Die Zertifikatsketten (es sind auch mehrere möglich) werden in fortlaufend nummerierten MIDlet-Certificate-x-y Attributen samt ihrer Zertifikate gespeichert, wobei x für die Zertifikatskette und y für das Element der Kette steht. Mit dem geheimen Schlüssel (private key) der Hauptzertifizierungsstelle wird aus dem JAR eine Signatur erzeugt die im Attribut MIDlet-Jar-RSA-SHA1 als base64 codiert im JAD gespeichert wird. Ist dieses Attribut vorhanden muss beim herunterladen eine Verifikation und Authentifizierung vorgenommen werden (vgl. Abschnitt 4.3.2). Der Prozess besteht aus mehreren Schritten: 1. Die MIDlet-Certificate-x-y Attribute werden für jede Zertifikatkette x, beginnend bei Element y=1 der Zertifikatkette, durchlaufen und es wird versucht ein passendes Hauptzertifikat im Gerät zu finden. 2. Die erste Zertifikatskette, die verifiziert wird, bindet das MIDlet an eine feste Sicherheitsdomäne. 3. Nachdem sichergestellt ist, dass der Versender der ist der er vorgibt zu sein, wird nun mit dem öffentlichen Schlüssel (public key) der Zertifizierungsstelle die Signatur decodiert. 12 Kapitel 4: Sicherheitskonzepte auf Profilebene 4. Der mit der Hash-Funktion SHA-1 erzeugte Wert aus dem übermittelten JAR wird mit der decodierten Signatur verglichen. Nur wenn alle diese Punkte erfolgreich absolviert wurden kann mit der Installation in die gewünschte Sicherheitsdomäne fortgefahren werden. Bei einem Fehler wird die MIDlet Installation entweder abgelehnt oder in die unidentified third party domain vorgenommen. MIDlets auf Basis des MIDP 1.0 werden standardmäßig in die unidentified third party domain installiert. Umgekehrt werden bei MIDlets, die unter MIDP 2.0 verifiziert werden könnten, bei der Installation in MIDP 1.0 Geräten die Zertifikate ignoriert und wie alle anderen MIDlets in derselben restriktiven Sicherheitsdomäne ausgeführt. 4.3 Die Security and Trust Services API Um die vielen Anwendungsgebiete mit JavaME abzudecken und trotzdem das Ziel einer kleinen aber eingeschränkten Umgebung zu gewährleisten, gibt es neben den Konfigurationen und Profilen noch optionale Pakete, die die benutzbare API bei Bedarf um die gewünschte Funktionalität erweitern. Die Security and Trust Services API (SATSA), die in [JSR177] spezifiziert ist, erweitert den Sprachumfang um zwei Typen von Paketen. Zum einen sind das die Kommunikationspakete SATSA APDU Communication API und SATSA JCRMI Communication API, welche das Generic Connection Framework um die Klassen APDUConnection und JavaCardRMIConnection erweitern. Dadurch wird eine Brücke zwischen JavaME und smart cards, wie der Java Card, (Universal) Subscriber Identity Module und token smart cards, geschlagen (für detailliertere Informationen vgl. [SATSA1]). Zum anderen sind dies die SATSA CRYPTO Cryptographic API und die SATSA Public Key Infrastructure Signature Servcie API und einige Exceptions, die zum Teil Untermengen der JavaSE Sicherheitspakete java.security.* und javax.crypto.* sind. Sie ermöglichen einer JavaME Implementierung digitale Signaturen und digitale Zertifikate zu verwalten sowie kryptografische Operationen auszuführen. Die Anwendungen der SATSA werden im Folgenden näher erläutert (vgl. [SATSA2]). 13 Kapitel 4: Sicherheitskonzepte auf Profilebene 4.3.1 Integritätsprüfung einer Nachricht In einigen Anwendungen soll sichergestellt werden, dass Daten, wie z.B. Programme oder Nachrichten, unterwegs keine Veränderung erlitten haben. Die SATSA ermöglicht Benutzern über Einweg Hashfunktionen, wie z.B. den beiden populärsten Vertretern RSA Security MD5 oder NIST’s SHA-1 die Integrität ausgetauschter Daten sicherzustellen. Einweg Hashfunktionen sind Funktionen, die aus einer Eingabe x eine Ausgabe y (in aller Regel ein Element der natürlichen Zahlen) ermitteln, die diese Eingabe repräsentiert. Da die Menge der Eingaben X im Vergleich zu den möglichen so genannten Hashwerten Y sehr groß ist, liegt keine perfekte Injektivität vor, jedoch ist es sehr unwahrscheinlich, dass zwei ähnliche Eingaben die gleiche Ausgabe erzeugen. Es ist zudem unmöglich aus der Ausgabe y auf die Eingabe x zu schließen. Die schon in der JavaSE vorhandene MessageDigest Klasse erzeugt nach Angabe des gewünschten Hash-Algorithmus (für erlaubte Algorithmen vgl. [JCAA]), einer Eingabe in Form eines Strings oder Bytearrays und der Länge des zu erzeugenden Hashbytearrays ein digest genanntes Hashbytearray. Dieses wird dann beim Austausch zusammen mit der Datei übertragen. Der Empfänger kann nun, vorausgesetzt er kennt den Algorithmus und die Länge des digest, aus der mitgeschickten Datei ebenfalls ein digest ermitteln und sie mit dem mitgeschickten digest byteweise vergleichen (vgl. Abbildung 3). Da wie oben beschrieben quasi nur eine identische Eingabe dazu führen kann, dass die Hashbytearrays identisch sind, ist die Integrität der Daten sichergestellt. 14 Kapitel 4: Sicherheitskonzepte auf Profilebene Abbildung 3: Integritätsprüfung 4.3.2 Authentifizierung einer Nachricht Für einige praktische Anwendungen reicht es nicht aus sicherzugehen, dass die Integrität einer Nachricht gewährleistet ist. Es wäre ja theoretisch denkbar, dass jemand eine Nachricht abfängt, das digest entfernt, die mitgeschickte Datei korrumpiert, ein neues digest erzeugt und dieses dann zusammen mit der korrumpierten Datei weiterschickt. Der Empfänger kann dann zwar die Integrität der Daten prüfen, aber von wem die Daten sind, ist für den Empfänger so nicht ersichtlich. Es ist also nötig den Absender in einigen Fällen zusätzlich zu authentifizieren. Der Authentifizierungsprozess fügt dem in Abschnitt 3.2.1 beschriebenen Prozess der Integritätsprüfung Authentifizierungselemente hinzu. Für das folgende asymmetrische Verschlüsselungsverfahren benötigt der Absender ein gültiges Zertifikat mit geheimen (private) und öffentlichen Schlüssel (public key) und einen von einer Hauptzertifizierungsstelle zugewiesenen Namen (Certificate Authority Distinguished Name (CA DN)). Zu Anfang wird aus der Nachricht wieder ein digest erzeugt. Das digest wird dann mit dem private key des Senders signiert und zusammen mit dem Zertifikat und der Nachricht verschickt. Der Empfänger verifiziert die Gültigkeit des 15 Kapitel 4: Sicherheitskonzepte auf Profilebene Zertifikats über das auf dem Gerät integrierte Zertifikat der Hauptzertifizierungsstelle und entnimmt dem mitgeschickten Zertifikat zusätzlich noch den Verschlüsselungsalgorithmus und den public key. Diese Informationen benutzt der Empfänger, um die mitgeschickte Signatur zu dekodieren und das vom Absender generierte digest zu erhalten. Danach wird, wie in Abschnitt 4.3.1 beschrieben, aus den mitgeschickten Daten ein digest generiert und mit dem erhaltenen verglichen. Der Vorgang liefert nur dann ein sinnvolles Ergebnis, wenn das Ergebnis mit dem korrekten private/public Schlüsselpaar ver- und entschlüsselt wird. Unbemerkte Eingriffe Dritter in die Daten sind nicht mehr möglich. Die Authentizität und Integrität der verschickten Daten ist somit sichergestellt (vgl. Abbildung 4). Absender Daten Empfänger Übertragung Daten Signatur Hashfunktion Entschlüsselung Digest Digest Verschlüsselung Hashfunktion Signatur Digest =? Abbildung 4: Authentifizierung des Absenders mit Integritätsprüfung Die SATSA stellt, anders als in JavaSE, Signaturfunktionalität in der Klasse CMSMessageSignatureService aus dem Paket javax.microedition.* bereit. Es werden dabei zwei Möglichkeiten der Erzeugung von Signaturen bezüglich Ihres Zwecks unterschieden. Die für Zwecke der nicht Bestreitbarkeit (engl. non repudiation), wie z.B. in Verträgen, benutzbare Methode sign()und für einfache Authentifizierung die Methode authorize(). Beide unterstützen die Signatur von Strings oder Bytearrays. Für den Signaturprozess benötigt man zusätzlich den oben erwähnten CA 16 Kapitel 4: Sicherheitskonzepte auf Profilebene DN. Eine zusätzliche Signatur mit Zeitstempeln über eine Time Stamping Authority ist in der API nicht vorgesehen. Die Signature Klasse stellt in JavaSE Verifikations- und Signaturfunktionalität bereit. In der SATSA übernimmt sie nur die Aufgabe der Verifikation. Es werden im Verifikationsprozess der public key und der verwendete Algorithmus benötigt, welche sich im mitgeschickten Zertifikat befinden. 4.3.3 Vertraulichkeit von Nachrichten Die Authentizität und Integrität ausgetauschter Daten können wie beschrieben sichergestellt werden. Die oben erwähnten Mechanismen verhindern aber nicht, dass jemand die Daten und den public key abfängt und sie mitliest. Für die Übertragung sensibler Daten ist daher zusätzlich eine Verschlüsselung der Daten notwendig, die nur vom Empfänger entschlüsselt werden kann. Dies kann durch symmetrische und asymmetrische Schlüssel geschehen. Zusätzlich zu den in Abschnitt 4.4.2 besprochenen Mechanismen kann eine sichere asymmetrische Verschlüsselung von Nachrichten dadurch erreicht werden, dass die geschickten Daten zusätzlich durch den public key des Empfängers verschlüsselt werden (vgl. Abbildung 5). Der Empfänger ist damit der einzige, der die Nachricht dekodieren und die in Abschnitt 4.4.2 beschriebenen Schritte zur Authentifizierung des Absenders und der Integritätsprüfung der Nachricht durchführen kann. Die SATSA unterstützt zwar die asymmetrische Verschlüsselung über die Cipher Klasse, beherrscht aber von sich aus keine Funktionalität zur Entschlüsselung solcher Nachrichten über einen private key. Die Anwendungsgebiete sind dementsprechend eingeschränkt. 17 Kapitel 4: Sicherheitskonzepte auf Profilebene Abbildung 5: Asymmetrische Verschlüsselung (links) und Entschlüsselung (rechts) Die symmetrische Ver- und Entschlüsselung von Daten ist hingegen voll implementiert. Die Klasse Cipher besitzt Methoden, um Nachrichten zu ver- und entschlüsseln. Dies sind unter anderem die Methoden init(), die abhängig von der Anwendung für Verschlüsselungen die statische Variable Cipher.ENCRYPT_MODE oder für Entschlüsselungen die statische Variable Cipher.DECRYPT_MODE als Parameter erwartet, update() und doFinal(), die die Ver- bzw. Entschlüsselung durchführen bzw. diese abschließt. Sind der Absender und der Empfänger die einzigen Besitzer des Schlüssels (was in der realen Anwendungen ein nicht triviales Problem darstellt), ist sichergestellt, dass kein Dritter die Daten lesen kann (vgl. Abbildung 6). 18 Kapitel 4: Sicherheitskonzepte auf Profilebene Absender Empfänger Verschlüsselte Daten Übertragung Verschlüsselung Daten Entschlüsselung Verschlüsselte Daten Daten Abbildung 6: Symmetrische Ver- und Entschlüsselung 4.4 Sichere Netzwerkprotokolle im MIDP 2.0 Wie in der Übersicht über die Berechtigungen in Abschnitt 4.3.1 zu sehen war, unterstützt das MIDP ab der Version 2.0 unter anderem Secure Socket Layer (SSL) für sichere Socket Verbindungen und HTTP über SSL, Transport Layer Security (TLS), Wireless TLS oder WAP TLS. Diese werden, wie bei anderen Verbindungen sonst auch, mit bzw. Connector.open(“https://...“) Connector.open(“ssl://...“) geöffnet. HTTPS arbeitet mit einem Zertifikatsverfahren ähnlich dem der asymmetrischen Verschlüsselung, das in den Abschnitten 4.4.1 - 4.4.3 beschrieben ist. Die Klasse HttpsConnection definiert zusätzlich zwei neue Methoden int getPort() sowie SecurityInfo getSecurityInfo(). Das Interface SecurityInfo definiert Methoden, welche Protokolle benutzen können, um sicherheitsrelevante Informationen über ihre Verbindung zur Verfügung zu stellen. Das Interface Certificate definiert Methoden, um Informationen über das benutzte Zertifikat, wie z.B. den CA DN, die Zeitspanne in der das Zertifikat gültig ist und welcher Signaturalgorithmus benutzt wurde, zur Verfügung zu stellen. 19 Kapitel 5: Fazit 5 Fazit Die Sicherheitskonzepte der JavaME sind spätestens seit den neusten Versionen der Konfigurationen und Profile auf allen Ebenen durchdacht. Das zu Grunde gelegte Sandkasten Modell der KVM verhindert effektiv, dass das System, welches die KVM implementiert, destabilisiert wird. Der Verifikationsprozess wurde für CLDC Geräte neu erdacht, so dass eine effiziente Prüfung des Codes zur Laufzeit möglich ist. Die knappen Ressourcen der Geräte, für die JavaME konzipiert wurde, erzwingen einige Einschränkungen auf der Ebene der Funktionalität. Diese Einschränkungen gehen dabei nicht zu Lasten der Sicherheit. Es lässt sich erkennen, dass in steigender Versionszahl auch die Einschränkungen gegenüber der JavaSE kleiner werden. Während im MIDP 1.0 alle MIDlet’s gleich restriktiv behandelt wurden, ermöglicht das MIDP 2.0 Entwicklern eine größere Vielfalt an verschiedenen Anwendungen zu programmieren. Hersteller implementieren dazu Sicherheitsdomänen, die Entwickler, authentifiziert über Zertifikate, anfordern können. Die Unterstützung von HTTPS und SSL Verbindungen ermöglichen den Aufbau gesicherter Verbindungen zwischen Endgeräten und Servern. Für mehr Kontrolle über Integritäts-, Authentizitäts- und Verschlüsselungsfunktionalität bietet die SATSA umfangreiche Funktionalität, wobei an einigen Ecken einige Restriktionen bei den Anwendungen, gegeben durch die knappen Ressourcen, der Geräte erkennbar werden. 20 Literaturverzeichnis [BrMo06] Ulrich Breymann, Heiko Mosemann: Java ME Anwendungsentwicklung für Handys , PDA und Co., Hanse, 2006 [JCAA] JCAA Appendix: http://java.sun.com/j2se/1.4.2/docs/guide/security/CryptoSpec.html#AppA [JSR30] Connected Limited Device Configuration 1.0 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr030/index.html [JSR36] Connected Device Configuration 1.0.2 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr036/index.html [JSR37] Mobile Information Device Profile 1.0 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr037/index.html [JSR118] Mobile Information Device Profile 2.0 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr118/index.html [JSR139] Connected Limited Device Configuration 1.1 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr139/index.html [JSR177] Security and Trust Service API Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr177/index.html [JSR188] Mobile Information Device Profile Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr188/index.html [JSR216] Personal Profile Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr216/index.html [JSR217] Personal Basic Profile Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr217/index.html [JSR218] Connected Device Configuration 1.1.2 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr218/index.html [JSR219] Foundation Profile 1.1.2 Spezifikation: http://jcp.org/aboutJava/communityprocess/final/jsr219/index.html [JSR248] Mobile Service Architecture for CLDC: http://jcp.org/aboutJava/communityprocess/edr/jsr248/index.html [JVM] JVM Spezifikation, Kapitel 4.9: http://java.sun.com/docs/books/vmspec/2ndedition/html/ClassFile.doc.html#88597 [KVM] White Paper on KVM and CLDC http://java.sun.com/products/cldc/wp/KVMwp.pdf [SATSA1] C. Enrique Ortiz: The Security and Trust Service API for J2ME, Part 1, http://developers.sun.com/techtopics/mobility/apis/articles/satsa1/, 2005 [SATSA2] C. Enrique Ortiz: The Security and Trust Service API for J2ME, Part 2, http://developers.sun.com/techtopics/mobility/apis/articles/satsa2/, 2005 [Sch07] Klaus-Dieter Schmatz: Java Micro Edition Entwicklung mobiler JavaMEAnwendungen mit CLDC und MIDP, 2. Auflage, dpunkt.verlag, 2007
