20Sicherheitskonzepte 

»Vorsicht ist die Einstellung, die das Leben sicherer macht, aber selten glücklich.«
– Samuel Johnson (1709–1784)

 

20.1Zentrale Elemente der Java-Sicherheit 

Damit Java-Programme sicher arbeiten, greift eine Reihe von Elementen ineinander: die Sprache, die JVM, die Bibliotheken. Einige Dinge gibt schon die Sprache selbst vor (wie fehlende Pointer-Arithmetik, Sichtbarkeitsbereiche, Überwachung der Feldgrenzen), und andere ergeben sich durch die Laufzeitumgebung selbst.

 

20.1.1Sichere Java Virtual Machine 

Zunächst ist da der Bytecode-Verifier, der grob sicherstellt, dass der Java-Bytecode korrekt geformt ist. Zu den Prüfungen zählt zum Beispiel, dass Bytecode nicht in der Mitte enden darf, dass der Index auf Variablen korrekt ist und dass Sprünge nicht außerhalb des Programmcodes erfolgen. Der Klassenlader ist die nächste Einheit, und sein Einfluss auf die Sicherheit ist nicht offensichtlich. Er stellt jedoch sicher, dass sich Klassen in Paketen nicht überschreiben können und dass ein selbst geschriebenes java.lang.Object nicht plötzlich das Original überdeckt; beide befinden sich in unterschiedlichen Runtime Packages. Durch eine Hierarchie der Klassenlader kommt eine Anforderung an die Klasse java.lang.Object auch zuerst an den obersten Vater-Klassenlader, den Bootstrap Class Loader. Sind die Klassen geladen, überwacht zur Laufzeit der Sicherheitsmanager gültige Aufrufe; er sitzt immer zwischen unserer Java-Applikation und dem Betriebssystem. Der Sicherheitsmanager existiert seit Java 1.0, gibt aber die Arbeit seit Java 1.2 an eine verallgemeinerte Einheit weiter, den Access Controller. Er nutzt Tricks wie Stack-Überprüfung, um herauszufinden, ob Aufrufer einer Methode schon gewisse Rechte erworben haben, um die Operation ausführen zu können. Der Access Controller stellt sicher, dass Programmcode nur dann ausgeführt werden kann, wenn die passenden Rechte vorhanden sind.

 

20.1.2Der Sandkasten (Sandbox) 

Seit den ersten Java-Versionen gibt es das Prinzip der Sandbox, wonach Applikationen nur ganz bestimmte Rechte haben und sich nicht mehr ergaunern können. Das gilt insbesondere für Applets im Browser. Sie dürfen nicht das Gleiche tun wie Applikationen: auf Festplatten zugreifen, die Zwischenablage auslesen und vieles mehr.

Die Sandbox besteht aus zwei Teilen, die für die Java-Sicherheit sehr wichtig sind: dem Klassenlader (Klasse ClassLoader) und dem Sicherheitsmanager (SecurityManager). Der Klassenlader lädt die .class-Dateien und erzeugt (unter anderem) die dazugehörigen Class-Exemplare. Wir wollen uns in diesem Kapitel intensiver mit dem zweiten Teil, dem Sicherheitsmanager, auseinandersetzen.

Normale Applikationen benutzen den Standardklassenlader und verwenden keinen Sicherheitsmanager. Applets aus dem Internet fordern besondere Sicherheit, sodass Browser einen besonderen Klassenlader und Sicherheitsmanager nutzen. Der Security-Manager für Applets erlaubt zum Beispiel kein Ausführen von externen Programmen, da auf diese Weise die Festplatte formatiert werden könnte. Auch darf ein Applet keine Klassen von einem fremden Server laden; zulässig ist nur der Server, von dem das Applet selbst geladen wurde. Diese Vorgabe stellt der Klassenlader sicher.

 

20.1.3Security-API der Java SE 

Die Gesamtheit aller Bibliotheken, die sich in Java um die Sicherheit kümmern, wird Security-API genannt. Sie besteht aus unterschiedlichen Teilen:

• Verschlüsselung und Nachrichten-Authentifizierung: Seit Java 1.1 gibt es die Java-Cryptography-API. Die Java Cryptography Architecture (JCA) beschreibt, wie diese API benutzt werden kann. Ihr ist das Paket java.security gewidmet. In Java 1.4 ist dann die Java Cryptography Extension (JCE) hinzugekommen, die vorher nur als optionales Paket seit 1.2 erhältlich war. Sie erweitert die Möglichkeiten der JCA. Die Klassen und Schnittstellen sind an dem Paket javax.crypto zu erkennen.

• Sichere Verbindungen sind ein Teilaspekt der Verschlüsslung auf Netzwerkebene, wobei hier SSL/TLS hervorzuheben sind.

• Public-Key-Infrastruktur: Sie dient dem Verwalten von Schlüsseln in Keystores und dem Prüfen von digitalen X.509-Zertifikaten.

• Authentifizierung und Zugriffskontrolle: Java Authentication and Authorization Service (JAAS) ist eine API mit Benutzerauthentifizierung, etwa über ein Kerberos-System.

 

20.1.4Cryptographic Service Providers 

Die Security-API ist so entworfen worden, dass über so genannte Cryptographic Service Provider Implementierungen ausgewechselt werden können. Die Security-API von Java ist völlig unabhängig von der Implementierung der kryptografischen Algorithmen und bietet zunächst Schnittstellen an. Die konkreten Algorithmen wie RC5, RSA oder DES realisieren Provider.

Jeder Provider hat einen Namen und implementiert einen oder mehrere Algorithmen. Die Provider aus dem JDK sind unter http://download.java.net/jdk8/docs/technotes/guides/security/StandardNames.html aufgelistet und erklärt. Vieles ist historisch gewachsen und würde wohl heute anders aussehen.

Neue Provider lassen sich jederzeit einbringen, insbesondere dann, wenn uns die Amerikaner nicht erlauben, eine starke Verschlüsselung zu verwenden. Sonst ist jedoch die Benennung eines speziellen Providers nicht notwendig.[ 144 ](Mehr Details auch zu den Namen unter http://download.java.net/jdk8/docs/technotes/guides/security/SunProviders.html.)