Java SE 8 Standard-Bibliothek  
Professionelle Bücher. Auch für Einsteiger.
 
Inhaltsverzeichnis

Vorwort
1 Neues in Java 8 und Java 7
2 Fortgeschrittene String-Verarbeitung
3 Threads und nebenläufige Programmierung
4 Datenstrukturen und Algorithmen
5 Raum und Zeit
6 Dateien, Verzeichnisse und Dateizugriffe
7 Datenströme
8 Die eXtensible Markup Language (XML)
9 Dateiformate
10 Grafische Oberflächen mit Swing
11 Grafikprogrammierung
12 JavaFX
13 Netzwerkprogrammierung
14 Verteilte Programmierung mit RMI
15 RESTful und SOAP-Web-Services
16 Technologien für die Infrastruktur
17 Typen, Reflection und Annotationen
18 Dynamische Übersetzung und Skriptsprachen
19 Logging und Monitoring
20 Sicherheitskonzepte
21 Datenbankmanagement mit JDBC
22 Java Native Interface (JNI)
23 Dienstprogramme für die Java-Umgebung
Stichwortverzeichnis

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Java SE 8 Standard-Bibliothek von Christian Ullenboom
Das Handbuch für Java-Entwickler
Buch: Java SE 8 Standard-Bibliothek

Java SE 8 Standard-Bibliothek
Pfeil 20 Sicherheitskonzepte
Pfeil 20.1 Zentrale Elemente der Java-Sicherheit
Pfeil 20.1.1 Sichere Java Virtual Machine
Pfeil 20.1.2 Der Sandkasten (Sandbox)
Pfeil 20.1.3 Security-API der Java SE
Pfeil 20.1.4 Cryptographic Service Providers
Pfeil 20.2 Sicherheitsmanager (Security-Manager)
Pfeil 20.2.1 Der Sicherheitsmanager bei Applets
Pfeil 20.2.2 Sicherheitsmanager aktivieren
Pfeil 20.2.3 Rechte durch Policy-Dateien vergeben
Pfeil 20.2.4 Erstellen von Rechtedateien mit dem grafischen Policy-Tool
Pfeil 20.2.5 Kritik an den Policies
Pfeil 20.3 Signierung
Pfeil 20.3.1 Warum signieren?
Pfeil 20.3.2 Digitale Ausweise und die Zertifizierungsstelle
Pfeil 20.3.3 Mit keytool Schlüssel erzeugen
Pfeil 20.3.4 Signieren mit jarsigner
Pfeil 20.4 Kryptografische Hashfunktion
Pfeil 20.4.1 Die MDx-Reihe
Pfeil 20.4.2 Secure Hash Algorithm (SHA)
Pfeil 20.4.3 Mit der Security-API einen Fingerabdruck berechnen
Pfeil 20.4.4 Die Klasse MessageDigest
Pfeil 20.5 Verschlüsseln von Daten(-strömen) *
Pfeil 20.5.1 Den Schlüssel, bitte
Pfeil 20.5.2 Verschlüsseln mit Cipher
Pfeil 20.5.3 Verschlüsseln von Datenströmen
Pfeil 20.6 Zum Weiterlesen
 
Zum Seitenanfang

20Sicherheitskonzepte Zur vorigen ÜberschriftZur nächsten Überschrift

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

 
Zum Seitenanfang

20.1Zentrale Elemente der Java-Sicherheit Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 
Zum Seitenanfang

20.1.1Sichere Java Virtual Machine Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 
Zum Seitenanfang

20.1.2Der Sandkasten (Sandbox) Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 
Zum Seitenanfang

20.1.3Security-API der Java SE Zur vorigen ÜberschriftZur nächsten Überschrift

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.

 
Zum Seitenanfang

20.1.4Cryptographic Service Providers Zur vorigen ÜberschriftZur nächsten Überschrift

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.

[zB]Beispiel

Welche Provider das JDK bietet, zeigt folgender Zweizeiler:

for ( Provider p : Security.getProviders() )
System.out.printf( "%s (%s): %s%n", p.getName(), p.getVersion(), p.getInfo() );

Das Ergebnis sind zehn Provider, wobei bei der Standardinstallation alle Implementierungen von Oracle kommen:

SUN (1.8): SUN (DSA key/parameter generation; DSA signing; SHA-1, MD5 digests; SecureRandom; X.509 certificates; JKS & DKS keystores; PKIX CertPathValidator; PKIX CertPathBuilder; LDAP, Collection CertStores, JavaPolicy Policy; JavaLoginConfig Configuration)
SunRsaSign (1.8): Sun RSA signature provider
SunEC (1.8): Sun Elliptic Curve provider (EC, ECDSA, ECDH)
SunJSSE (1.8): Sun JSSE provider(PKCS12, SunX509/PKIX key/trust factories, SSLv3/TLSv1/TLSv1.1/TLSv1.2)
SunJCE (1.8): SunJCE Provider (implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, PBE, Diffie-Hellman, HMAC)
SunJGSS (1.8): Sun (Kerberos v5, SPNEGO)
SunSASL (1.8): 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 (1.8): XMLDSig (DOM XMLSignatureFactory; DOM KeyInfoFactory; C14N 1.0, C14N 1.1, Exclusive C14N, Base64, Enveloped, XPath, XPath2, XSLT TransformServices)
SunPCSC (1.8): Sun PC/SC provider
SunMSCAPI (1.8): Sun's Microsoft Crypto API 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.)

 


Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Java SE 8 Standard-Bibliothek Java SE 8 Standard-Bibliothek
Jetzt Buch bestellen

 Buchempfehlungen
Zum Rheinwerk-Shop: Java ist auch eine Insel
Java ist auch eine Insel


Zum Rheinwerk-Shop: Professionell entwickeln mit Java EE 8
Professionell entwickeln mit Java EE 8


Zum Rheinwerk-Shop: Besser coden
Besser coden


Zum Rheinwerk-Shop: Entwurfsmuster
Entwurfsmuster


Zum Rheinwerk-Shop: IT-Projektmanagement
IT-Projektmanagement


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo

 
 


Copyright © Rheinwerk Verlag GmbH 2018. Original - https://www.rheinwerk-verlag.de/openbook/
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

 
 


19.03.2024 - Sitemap.xml