RMI RMI SSL Sichertheit auf Clientseite

[multiholle]

Ich habe eine Verbindung von Client/Server mit Hilfe von SSL verschlüsselt. Trotzdem habe ich noch ein Sicherheitsproblem:

Auf der Clientseite liegen die truststore und keystore Dateien vor. Diese sind zwar verschlüsselt jedoch kann ich den Key aus der Class-Datei entnehmen. Damit kann sich ein böswilliger Client vollen Zugriff zum Server verschaffen. Gibt es eine Möglichkeit dieses Problem zu umgehen?

System.setProperty("javax.net.ssl.keyStore", System.getProperty("user.dir") + "/bin/server/security/keystore");
System.setProperty("javax.net.ssl.keyStorePassword", "mtvirgig");
System.setProperty("javax.net.ssl.trustStore", System.getProperty("user.dir") + "/bin/server/security/truststore");
System.setProperty("javax.net.ssl.trustStorePassword", "mtvirgig");

 

[Quurks]

Ich kann zwar nicht genau nachvollziehen wo das Problem ist bzw warum die Sachen in dem CLienten liegen müssen, aber allgemein gesagt ist es nicht möglich sachen wie SChlüssel die in einer JAR bzw Class datei liegen geheim zu halten. Die Lösung wäre auf dem Server zu beschränken was jmd der sich anmeldet (im Normalfall der Client) darf

 

[FArt]

Ich habe das Gefühl, du machst noch was falsch, vermutlich hast du noch nicht ganz verstanden, wie das genau läuft.
In der Regel authentifiziert sich der Server gegenüber dem Client (mit Zertifikat), es werden Schlüssel ausgehandelt und dann die Verbindung damit verschlüsselt.
Der Server hat den privaten Schlüssel, der Client kriegt nur den öffentlichen. Das ist völlig gefahrlos.

Noch mal ein wenig Theorie:
Transport Layer Security ? Wikipedia
Public-Key-Infrastruktur ? Wikipedia

 

[multiholle]

Angenommen ich bin ein böswilliger Nutzer. Dann habe ich, sobald ich den Client habe auch den key- und truststore, sowie die dazugehörigen Passwörter aus den Class-Dateien.

Jetzt kann ich meinen eigenen Client bauen, mich beim Server authentifizieren und machen was ich will. Genau das soll aber nicht passieren!

 

[FArt]

Nein. Ausserdem schmeißt du alles zusammen... Verschlüsseln, Authentifizieren für Server, für Client, für Server und Client, ...

1. Frage: Was soll erreicht werden?
2. Frage: Wer soll sich dabei auf was verlassen können?

In Kürze (genauere Erklärungen bitte in der Literatur nachlesen, z.B. für den Einstieg die von mir geposteten Links):

Verschlüsseln von Daten mit dem privaten Schlüssel, entschlüsseln mit dem öffentlichen Schlüssel => der Empfänger kann sicher sein, dass die Daten vom Sender kommen.
Verschlüsseln von Daten mit dem öffentlichen Schlüssel, entschlüsseln der Daten mit dem privaten Schlüssel => der Sender kann sicher sein, dass die Daten nur vom Empfänger benutzt werden können.
Zertifikat: ich bekommen einen Schlüssel, weiß aber nicht ob ich dem vertrauen kann. Über die Zertifizierungskette kann er u.U. als vertrauenswürdig eingestuft werden.
usw.

In der Regel werden die Schlüssel, die zur Verschlüsselung der Kommunikation verwendet werden zur Laufzeit generiert und ausgetauscht. Das Aushandeln geschieht über PKI mit mehr oder weniger Sicherheit. Besonder sicher wäre die Cross-Authentifizierung, bei der sich Server und Client gegenseitig authentifizieren.

Gib NIE den privaten Schlüssel aus der Hand, sonst machst du was falsch.

 

[multiholle]

Nochmal zur Begriffsklärung:
Keystore: Enthält meine Identität und meinen privaten Schlüssel.
Truststore: Enthält eine Liste von vertrauenswürdigen Identitäten und den öffentlichen Schlüssel.

Das heißt der Client und der Server haben jeweils einen eigenen Keystore und zusammen einen Truststore. Die Keystore Datei liegt dem Client bei, damit er sich identifizieren kann. Gleichzeitig kann aber jeder andere diese Keystore Datei auch nutzen. Das kann ich doch nicht verhindern?

 

[FArt]

Client und Server haben jeweils ihre eigenen Stores (Key- und Truststore) und ihre eigenen Schlüssel und Zertifikate. Sowohl der Client, als auch der Server sind für seine Schlüssel verantwortlich.

Wenn ich ein Programm ausliefere, den Keystore dazulege und im Programm das Passwort für den Keystore hartcodiert ablege dann hat das den gleichen Charme, wie wenn die Bank den Schlüssel für den Tresor neben den Haupteingang hängt.

Der Keystore steht unter der Verwaltung des Clients und der hat dafür zu sorgen, dass seinen Daten nicht in die Hände anderer kommen.
Was gibt es für Möglichkeiten: Passwort für den Keystore eingeben lassen; Authentifizierungs- und Authorisierungsmechanismen der Clientinfrastruktur benutzen und vieles mehr....

 

[multiholle]

Passwort für den Keystore eingeben lassen

Ob ich das Passwort eingeben lasse oder beilege macht auch keinen Unterschied. Mit dem Passwort kann der böswillige Nutzer dann auch machen was er will. Aber irgendwo muss ich das Passwort für den keystore doch lassen?!

Zusätzlich zur SSL-Verschlüsselung habe ich ja noch eine Authentifizierung des Users gegenüber einer LDAP-Datenbank. Dann muss ich darüber auf dem Client die Rechte einschränken und die SSL-Verschlüsselung nur für den Transportweg nutzen.

 

[FArt]

Ob ich das Passwort eingeben lasse oder beilege macht auch keinen Unterschied. Mit dem Passwort kann der böswillige Nutzer dann auch machen was er will. Aber irgendwo muss ich das Passwort für den keystore doch lassen?!

:autsch:

Natürlich macht das einen Unterschied. Wenn es vom Nutzer eingegeben wird, kann es schlimmstenfalls ausgespäht werden. Wenn es im Code steht, kann es dein böser Junge auch auslesen.

Keystores (allgemein, nicht nur Java) werden interaktiv berechtigt... Passwort, Fingerabdruck, Anmeldung (z.B. an Domäne wobei dann der Keystore in einem speziell authorisierten Bereich liegt) ...

Bei Elster kann man seinen Schlüssel auf einem USB Stick bestellen. Wenn man dann damit signieren möchte, muss man den Stick einstöpseln, der in der Regel am Schlüsselbund baumelt... (und jetzt kommst du: und wenn ich den verliere? ;( )

Auf den Schlüssel muss man halt aufpassen. Der Mensch ist immer das schwächste Glied in der ganzen Kette, da kannst du dir technisch nen Wolf programmieren...