Sie sind hier : basti1012.de/ informationen / Sicherheitskonzepte.php

22 SicherheitskonzepteZur nächsten Überschrift

22 SicherheitskonzepteZur nächsten Überschrift

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


Rheinwerk Computing - Zum Seitenanfang

22.1 Zentrale Elemente der Java-SicherheitZur nächsten ÜberschriftZur vorigen Überschrift

Damit Java-Programme sicher arbeiten, greift eine Reihe von Elementen ineinander. Einige Dinge gibt schon die Sprache selbst vor (wie fehlende Pointerarithmetik, Sichtbarkeitsbereiche, Überwachung der Feldgrenzen), und andere ergeben sich durch die Laufzeitumgebung selbst. Zunächst ist da der Bytecode Verifier, der grob sicherstellt, dass der Java-Bytecode korrekt geformt ist. Zu den Prüfungen zählen 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, den Access Controller, weiter. 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.


Rheinwerk Computing - Zum Seitenanfang

22.1.1 Security-API der Java SEZur nächsten ÜberschriftZur vorigen Überschrift

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


Rheinwerk Computing - Zum Seitenanfang

22.1.2 Cryptographic Service ProvidersZur vorigen Überschrift

Die Security-API ist so entworfen worden, dass über sogenannte 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 RSA oder DES realisieren Provider – Oracle ist einer von ihnen und bringt einen Standard-Provider für grundlegende Operationen mit.

Beispiel

Welche Provider Java 7 bietet, zeigt folgender Zweiteiler:

for ( Provider p : Security.getProviders() )
System.out.println( p + ": " + p.getInfo() );

Das Ergebnis sind zehn Einträge:

SUN version 1.7: SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests;
SecureRandom; X.509 certificates; JKS keystore; PKIX CertPathValidator; PKIX
CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig
Configuration)
SunRsaSign version 1.7: Sun RSA signature provider
SunEC version 1.7: Sun Elliptic Curve provider (EC, ECDSA, ECDH)
SunJSSE version 1.7: Sun JSSE provider(PKCS12, SunX509 key/trust factories, SSLv3,
TLSv1)
SunJCE version 1.7: SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish,
ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
SunJGSS version 1.7: Sun (Kerberos v5, SPNEGO)
SunSASL version 1.7: Sun SASL provider(implements client mechanisms for: DIGEST-MD5,
GSSAPI, EXTERNAL, PLAIN, CRAM-MD5, NTLM; server mechanisms for: DIGEST-MD5, GSSAPI,
CRAM-MD5, NTLM)
XMLDSig version 1.0: XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory)
SunPCSC version 1.7: Sun PC/SC provider
SunMSCAPI version 1.7: Sun's Microsoft Crypto API provider

Jeder Provider implementiert einen oder mehrere Algorithmen. Neue Provider lassen sich jederzeit einbringen, insbesondere dann, wenn uns die Amerikaner nicht erlauben, eine starke Verschlüsselung zu verwenden. Eine genauere Übersicht liefert http://www.oracle.com/technetwork/java/javase/tech/index-jsp-136007.html und http://download.oracle.com/javase/7/docs/technotes/guides/security/crypto/CryptoSpec.html.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular