Java Applet Alternativen

Transkript

1 White Paper Java Applet Alternativen Version 1.0, Tobias Kellner Zusammenfassung: Aufgrund diverser Meldungen über Sicherheitslücken in Java haben in letzter Zeit Browser-Hersteller vermehrt die Verwendung von Java- Applets in Browsern eingeschränkt bzw. erschwert, was ein Problem für die Verwendung der Online-BKU darstellt. Es ist auch nicht davon auszugehen, dass sich dieser Trend ändert, sodass in naher Zukunft möglicherweise eine Verwendung von Java in Browsern nicht mehr möglich sein wird. Dies gewinnt insbesondere vor dem Hintergrund der zunehmenden Verbreitung von Tablet- Computern, deren Betriebssysteme (Windows RT, ios, Android) kein Java in Browsern unterstützen, an Bedeutung. In diesem Projekt soll evaluiert werden, welche Möglichkeiten für einen Kartenzugriff an Stelle von Java derzeit oder in Zukunft zur Verfügung stehen. E-Government Innovationszentrum Inffeldgasse 16/a, A-8010 Graz Tel Fax Das E-Government Innovationszentrum ist eine gemeinsame Einrichtung des Bundeskanzleramtes und der TU-Graz

2 Inhaltsverzeichnis 1 Einleitung Online-BKU Motivation Voraussetzungen Alternativen Übersicht Adobe Flash Microsoft Silverlight Browser-Plug-In Microsoft ActiveX Netscape Plug-In API (NPAPI) Google (Portable) Native Client (NaCL/PNaCL + PPAPI) HTML Detaillierte Analyse Adobe Flash / Microsoft Silverlight Browser-Plug-In Microsoft ActiveX Netscape Plug-In API (NPAPI) Google (Portable) Native Client (NaCL/PNaCL + PPAPI) HTML Fazit Anhang Einleitung 2

3 1 Einleitung 1.1 Online-BKU Bei der Online-BKU MOCCA handelt es sich um eine Implementierung einer Bürgerkartenumgebung als Java-Applet, mit dem Ziel, die Verwendung der Karten- Implementierung der Bürgerkarte für den Benutzer möglichst einfach zu gestalten, indem die Installation zusätzlicher Software auf ein Minimum gehalten wird. So kann die Bürgerkarten-Funktion der Chipkarte ohne Installation einer lokalen Bürgerkarten-Software genutzt werden. Dies ist allerdings nur möglich, wenn auf dem PC des Benutzers Java installiert ist und Java-Applets im Browser ausgeführt werden können. Hierfür wurde Java gewählt, da dies für alle gängigen Betriebssysteme verfügbar ist und zum Zeitpunkt der Entwicklung eine weit verbreitete Standard-Plattform für Web- Applikationen war. Die Online-BKU besteht aus einer Server- und einer Client-Komponente, wobei nur die Client-Komponente als Java-Applet ausgeführt ist, und für die Interaktion mit dem Benutzer und der Kommunikation mit der Chipkarte zuständig ist. 1.2 Motivation Aufgrund des vermehrten Auftretens von und der damit verbunden öffentlichen Aufmerksamkeit auf Sicherheitslücken in Java wurde in letzter Zeit das Ausführen von Java-Applets in diversen Browsern eingeschränkt bzw. erschwert, was die Benutzer vor zusätzliche Herausforderungen stellt und zusätzliche Support-Anfragen verursacht. Des Weiteren gewinnen Mobile Devices zusehends an Bedeutung, deren Browser oft kein Java unterstützen. Somit wäre es wünschenswert, gangbare Alternativen für die Implementierung einer Bürgerkartenumgebung zu finden, die nicht auf Java-Applets basieren. 1.3 Voraussetzungen Dafür gilt es vorerst, notwendige Voraussetzungen für eine Bürgerkartenumgebung festzustellen: Einleitung 3

4 Smartcard-Kommunikation Dies ist die Grundlegende Anforderung und gleichzeitig das Ausschlusskriterium für viele Alternativen es muss die Kommunikation mit der Chipkarte über den Kartenleser ermöglich werden Benutzer-Interkation Es müssen diverse Interfaces angezeigt werden, um mit dem Benutzer zu interagieren. Beispielsweise zur PIN-Eingabe, Anzeige der Signaturdaten, Auslösen der Signatur, Netzwerk-Kommunikation Die Bürgerkartenumgebung muss mittels Security-Layer-Protokoll mit einer Gegenstelle kommunizieren können. Zusätzlich zu diesen notwendigen Voraussetzungen gibt es noch einige Aspekte, die für eine praktikable Alternative zum derzeitigen Java-Applet wünschenswert sind: Installations-Aufwand Wenn möglich sollte der Benutzer für die Benutzung der Online-BKU keine zusätzliche Software installieren müssen, und, falls doch nötig, sollte sich diese Installation an für den Benutzer bekannte Wege halten. Ausführungs-Transparenz Der Benutzer sollte kein eigenes Programm ausführen müssen, die Online-BKU sollte direkt aus dem Browser gestartet werden können. Plattform-Unabhängigkeit Die Verwendung der Online-BKU soll unter allen gängigen Betriebssystemen möglich sein, optimaler Weise auch mit mobilen Endgeräten. Einleitung 4

5 2 Alternativen Ausgehend von diesen Voraussetzungen, insbesondere den letzten Punkten, liegen die Standard-Plattformen für Webapplikationen nahe, welche in Folge im Einzelnen analysiert werden. 2.1 Übersicht Adobe Flash Unterstützt keinen Chipkarten-Zugriff Microsoft Silverlight Unterstützt keinen Chipkarten-Zugriff. Nur bedingt unter allen Betriebssystemen verfügbar Browser-Plug-In Unterstützt Chipkarten-Zugriff Plattform-Abhängig Erfordert Installation durch den Benutzer Microsoft ActiveX Unterstützt Chipkarten-Zugriff Nur für Windows + Internet Explorer verfügbar Plattform-Abhängig Netscape Plug-In API (NPAPI) Unterstützt Chipkarten-Zugriff Wird von gängigen Browsern nicht mehr unterstützt Erfordert Installation durch den Benutzer Google (Portable) Native Client (NaCL/PNaCL + PPAPI) Unterstützt derzeit keinen Chipkarten-Zugriff Nur für Chrome/Chromium verfügbar Erfordert Installation durch den Benutzer HTML5 Unterstützt derzeit keinen Chipkarten-Zugriff Alternativen 5

6 2.2 Detaillierte Analyse Adobe Flash / Microsoft Silverlight Unterstützen keinen Chiparten-Zugriff und sind daher nicht für die Implementierung einer Bürgerkarten-Umgebung geeignet Browser-Plug-In Browser-Plug-Ins bieten die Möglichkeit, nativen Code auszuführen und mit Webseiten zu interagieren, und sind somit prinzipiell geeignet, eine Bürgerkartenumgebung zu implementieren. Zu beachten ist, dass jeder Browser-Hersteller eigene Schnittstellen für derartige Plug-Ins zur Verfügung stellt, es muss also für jeden unterstützen Browser ein eigenes Plug-In erstellt werden. Abhilfe dafür könnte eine Browser-übergreifende Plug-In-Plattform wie zum Beispiel FireBreath schaffen. Allerdings kämpft auch dieses Projekt mit dem generellen Problem von Browser-Plug-Ins, dass der Support für solche Plug-Ins von Seiten einiger Browser- Hersteller eingeschränkt bzw. eingestellt wird 1 (siehe folgende Abschnitte). Da es sich bei Browser-Plug-Ins um nativen Code handelt, muss das Plug-In außerdem für jedes zu unterstützende Betriebssystem extra umgesetzt werden, wodurch sich der Aufwand für Entwicklung und Support vervielfacht Microsoft ActiveX Erlaubt die automatische Installation benötigter Komponenten und bietet vollständigen Zugriff auf das System, ist also Grundsätzlich für die Implementierung einer Bürgerkarten- Umgebung geeignet. Die Unterstützung für ActiveX beschränkt sich allerdings weitestgehend auf Microsoft Windows, und da weiters nativer Code ausgeführt wird wäre auch keine Plattformunabhängigkeit gegeben. Selbst unter Windows wird ActiveX (ohne Installation weiterer Komponenten) lediglich von Internet Explorer unterstützt. 1 Alternativen 6

7 2.2.4 Netscape Plug-In API (NPAPI) NPAPI ist ein Versuch von Netscape, Browser-Plug-Ins mittels einer Plattformunabhängigen Schnittstelle zu standardisieren. Vorübergehend wurde diese Schnittstelle von allen gängigen Browsern unterstützt. Sie erlaubt wie ActiveX die Ausführung von nativem Code verbunden mit denselben Nachteilen, also dem Verlust der Plattformunabhängigkeit. Zusätzlich gibt es keine Möglichkeit, NPAPI-Plugins automatisch zu installieren, der Benutzer muss das Plugin also vor der Verwendung händisch im Browser installieren. Außerdem wurde bzw. wird von allen gängigen Browsern die Unterstützung von NPAPI eingestellt: Internet Explorer unterstützt seit v5.5 NPAPI nicht mehr Chrome stellt im Laufe des Jahres 2015 die Unterstützung vollständig ein (zugunsten von NaCl siehe folgenden Abschnitt) Firefox reduziert seit Version 30 die Unterstützung und erwägt eine Einstellung Google (Portable) Native Client (NaCL/PNaCL + PPAPI) NaCl ist der von Google entwickelte Nachfolger für NPAPI. Es erlaubt ebenfalls die Ausführung von nativem Code, allerdings läuft dieser in einer Sandbox, und erlaubt keinen direkten Zugriff auf Betriebssystem-Funktionen. PNaCl verwendet Plattformunabhängigen Bytecode zur Ausführung, und würde somit das Problem der Plattformabhängigkeit beseitigen. Derzeit wird dieser Standard nur von Chrome implementiert. Für den Zugriff auf Betriebssystem-Funktionen gibt es die Pepper Plugin-API (PPAPI), diese Unterstützt zum aktuellen Zeitpunkt (2014) allerdings keinen Zugriff auf Smart Cards. Alternativen 7

8 2.2.6 HTML5 Die wünschenswerteste Implementierung einer Bürgerkartenumgebung wäre mithilfe der Technologien, welche im Allgemeinen unter HTML5 subsummiert werden, und derzeit die Standard-Plattform für Webapplikationen darstellen. Derzeit gibt es noch keine Möglichkeit, ohne zusätzliche Hilfsmittel (Plugins) auf eine Chipkarte zuzugreifen. Allerdings wird von einer W3C-Arbeitsgruppe an der System Applications API gearbeitet, welche Zugriff auf Betriebssystem-Funktionen bieten soll, und welche in Phase 2 auch eine Komponente zum Zugriff auf Secure Elements beinhält. Dieser inoffizielle Entwurf (derzeitiger Stand: Unofficial Draft 08 October 2014) sieht einen Low-Level-Direktzugriff auf Chipkarten vor, welcher für die Umsetzung einer Bürgerkartenumgebung genügen würde. Wird der Standard in dieser oder ähnlicher Form festgelegt und von den Browser- Herstellern implementiert, wäre es somit möglich, die Benutzer-Komponente einer Bürgerkartenumgebung in HTML5 umzusetzen. Aktuell ist allerdings kein Fortschritt bei der Standardisierung dieser Schnittstelle festzumachen; unter anderem hat Google die Teilnahme an der Arbeitsgruppe aufgekündigt 2. Derzeit kann daher keine Aussage darüber getroffen werden, ob, wann, und von welchen Browserherstellern dieser Entwurf umgesetzt werden wird. 2 Alternativen 8

9 2.3 Fazit Zum jetzigen Zeitpunkt gibt es keine adäquate Alternative für eine Plattformunabhängige Online-BKU. Es gilt, die weiteren Entwicklungen der oben genannten Möglichkeiten zu beobachten, insbesondere der System Applications API oder eventuellen Nachfolgern, ob in Zukunft neue Alternativen möglich sind. Alternativen 9

10 3 Anhang Dokumentenhistorie Version Datum Autor(en) Anmerkung Tobias Kellner Tobias Kellner Anhang 10