Client Server Kommunikation verschlüsseln

[brainless]

hallo Java-forum 🙂

Ich zerbreche mir gerade über folgendes Problem den Kopf:
Es geht um die Benutzeranmeldung von Clients an einen Server. Dazu wird momentan beim Server eine Funktion aufgerufen, welche den Login-Name und Passwort übergeben bekommt und der Server fragt dies dann bei der Datenbank ab. Das Problem dabei ist, dass momentan die Kommunikation zwischen Client und Server unverschlüsselt ist und so das Passwort im Klartext übertragen wird. 😳

Als eine erste Lösung wird das Passwort symmetrisch mit AES verschlüsselt, wobei der dazu verwendete Key (salt) fest im Code vom Server und Client verdrahtet ist. Nun ist es aber nicht gewünscht, dass der Key im Code steht.

Als erstes habe ich an ein Hybrides-Verfahren aus RSA und AES gedacht:

1. der Client erfragt beim Server den PublicKey
2. Server erstellt Private- und PublicKey und sendet den PublicKey an Client
3. Client erzeugt zufälligen SecretKey (AES) und verschlüsselt diesen mit dem PublicKey des Servers
4. Client sendet SecretKey an Server
5. Server entschlüsselt den SecretKey mit seinem PrivateKey
6. --> Client und Server kennen den SecretKey (AES)
7. --> alte Methode vom ersten Ansatz kann genutzt werden

Eigentlich könnte man für diesen Fall auf ein hybrides Verfahren verzichten und das Passwort gleich mit dem PrivateKey verschlüsseln. 😱 Ich dachte mir aber man könnte die Symmetrische Verschlüsselung dann später noch für andere Aufrufe benutzen. 😎

So... das Problem was ich bei diesem Ansatz sehe ist: Wie authentifiziert sich der Server? 😕 (um sicher zu stellen, dass wirklich mit dem Server kommuniziert wird und niemand die Passwörter klauen will = Sicherheitslücke?)

Ich habe auch schon an ein Signaturverfahren mittels PKI gedacht. Allerdings ist da, glaube ich, der Aufwand zur Verwaltung der gültigen Signaturen für die Clients und den Server zu hoch. 😵

Das selbe Problem bei SSL-Sockets: dafür müsste man auch die gültigen Signaturen bei Client und Server verwalten. 😕

Hat jemand vielleicht eine Idee, wie man das Problem der Verschlüsslung/Authentifizierung lösen könnte? 😉

 

[Ch4t4r]

Speicher doch einfach den publickey des Servers ab. Nachteil ist hierbei natürlich, dass der Schlüssel nicht einfach geändert werden kann, Vorteil aber, dass nur dein Server die Daten lesen kann. Ob ein solches Konzept sinnvoll ist, ist deine Entscheidung.
Ein Tipp, falls du eine app für z.b Android programmieren willst: aus den usa exportierte Produkte haben teilweise Beschränkungen, was die Verschlüsselung angeht. Allerdings steige ich dort auch nicht komplett durch.

 

[brainless]

Danke für deine Antwort. 🙂

Ja man müsste dann halt alle Clients einmalig mit dem PublicKey des Servers versorgen (und dann nur noch, falls dieser geändert wird). Dann müsste man sich halt nur überlegen, wo im Client man den Speichert, um ihn austauschbar zu halten? (Am besten wahrscheinlich einfach als externe Datei, welche eingelesen wird...)

 

[cafebabe]

Als eine erste Lösung wird das Passwort symmetrisch mit AES verschlüsselt, wobei der dazu verwendete Key (salt) fest im Code vom Server und Client verdrahtet ist. Nun ist es aber nicht gewünscht, dass der Key im Code steht.

Ja, davon würde ich auch abraten, symmetrische Schlüssel gehören nicht hart in den code...

Prinzipell sehe ich hier mehrere Möglichkeiten (alle haben vor/nachteile):

1. Auth. per Hash:
   Client erfragt Challenge C vom Server
   Client berechnet aus C und Password P [bzw. Hash(Passwort) HP] Response R1 = HMAC(HP , C)
   Server berechnet ebenfalls R2 = HMAC(HP , C)
   R1 bzw R2 ist der sym. Schlüssel für die Verschlüsselung (z.b. mit AES)
   Das ganze kann man beliebig erweitern...
   
   Vorteil: Sehr einfach implementierbar und schnell
   Nachteil: Wie kommt das Passwort auf den Server/Datenbank ??? , Keine Eigenschaften wie PFS
2. Dein beschriebens Protokoll, public-key wird im Code des Clients hinterlegt.
   
   Vorteil: Sehr einfach implementierbar, PFS umsetzbar, etc.
   Nachteil: Wird der Server kompromentiert, lassen sich Clients nicht mehr sicher updaten (evtl. eine 2 pubKey hinterlegen)
   
3. SSL / TLS
   Zertifikat kann auch selbst erstellt werden
   
   Vorteil: Alles was TLS bietet
   Nachteil: Aufwand etwas höher

Was du einsetzen solltest hängt vom Anwendungsfall ab.

 

[Tobse]

Ich kann mich cafeable nur anschließen; allerdings ist es immer äußerst Risikoreich, sowas selbst zu implementieren. Du kannst auf SSL zurückgreiffen - von Hartbleed abgesehen ist das die Sicherste Methode. Du kannst die Mechanismen von SSL auch selbst implementieren, nur musst du hierbei weider auf viele kleine Details achten, die dein ganzes System komprommitieren können.

Bei SSL läuft es im grunde so:

1. Server hat ein Zertifikat (= RSA Public Key + Sigantur vom CA)
2. Nach dem TCP Verbindungsaufbau gibt es einen Schlüsselaustausch alá DiffieHellman; dabei ist wichtig, dass der Server (und am besten auch der Client) ihre Parameter ordentlich (= sicheres Padding) signieren.
3. Mit dem über DH ausgetauschten Schlüssel wird dann ein synchroner Cipher genutzt, z.B. AES-128 oder AES-256

Bei der synchronen Verschlüsselung gibt es auch wieder einige Fallstricke: Richtiger Cipher Mode of Operation, sicheres Padding, gute NONCEs.

Über den Kanal, der dann zustande kommt, kannst du dann sicher kommunizieren. Aber auch dann macht es sinn, die Passwortprüfung mit einer Challenge zu machen, wie cafebable beschrieben hat.

 

[brainless]

Vielen Dank für euer Input. 🙂

JPrinzipell sehe ich hier mehrere Möglichkeiten (alle haben vor/nachteile):

1. Auth. per Hash:
Client erfragt Challenge C vom Server
Client berechnet aus C und Password P [bzw. Hash(Passwort) HP] Response R1 = HMAC(HP , C)
Server berechnet ebenfalls R2 = HMAC(HP , C)
R1 bzw R2 ist der sym. Schlüssel für die Verschlüsselung (z.b. mit AES)
Das ganze kann man beliebig erweitern...

Vorteil: Sehr einfach implementierbar und schnell
Nachteil: Wie kommt das Passwort auf den Server/Datenbank ??? , Keine Eigenschaften wie PFS

Die Idee mit Challenge-Response finde ich eigentlich super. ;-) Aber leider stehen die Passwörter gehasht in der Datenbank. Und auf Clientseite steht die entsprechende Hash-Funktion nicht zur Verfügung. :-/ Ein anderes gemeinsames Geheimnis müsste man wieder hart in den Clientcode rein - und das wollen wir ja nicht.^^ Dann wahrscheinlich lieber doch lieber mit Public-Key.

2. Dein beschriebens Protokoll, public-key wird im Code des Clients hinterlegt.

Vorteil: Sehr einfach implementierbar, PFS umsetzbar, etc.
Nachteil: Wird der Server kompromentiert, lassen sich Clients nicht mehr sicher updaten (evtl. eine 2 pubKey hinterlegen)

Das Updaten der Clients wäre kein Problem, da diese zusammen mit dem Server ausgeliefert werden, falls die Software geupdatet wird.

3. SSL / TLS
Zertifikat kann auch selbst erstellt werden

Vorteil: Alles was TLS bietet
Nachteil: Aufwand etwas höher

Die Umsetzung wäre mit ein wenig Aufwand verbunden. Schlimmer ist aber, das wohl der Aufwand zur Verwaltung der KeyStores und TrustedStores bei den ganzen Clients zu hoch wäre.

Ich kann mich cafeable nur anschließen; allerdings ist es immer äußerst Risikoreich, sowas selbst zu implementieren. Du kannst auf SSL zurückgreiffen - von Hartbleed abgesehen ist das die Sicherste Methode. Du kannst die Mechanismen von SSL auch selbst implementieren, nur musst du hierbei weider auf viele kleine Details achten, die dein ganzes System komprommitieren können.

Ja SSL/TLS wäre wohl ein sichere und saubere Umsetzung. Leider ist die Verwaltung der Zertifikate mit dem Java keytool sehr aufwendig?

Über den Kanal, der dann zustande kommt, kannst du dann sicher kommunizieren. Aber auch dann macht es sinn, die Passwortprüfung mit einer Challenge zu machen, wie cafebable beschrieben hat.

s.o. die Frage ist, was ich als gemeinsames Geheimnis benutze? Da das Passwort im Server nur gehasht zur Verfügung steht.

 

[cafebabe]

Die Idee mit Challenge-Response finde ich eigentlich super. ;-) Aber leider stehen die Passwörter gehasht in der Datenbank. Und auf Clientseite steht die entsprechende Hash-Funktion nicht zur Verfügung. :-/ Ein anderes gemeinsames Geheimnis müsste man wieder hart in den Clientcode rein - und das wollen wir ja nicht.^^ Dann wahrscheinlich lieber doch lieber mit Public-Key.

Das ist ja mal ein setup... Der client keine Java SE ?!
Kannst/darfst du uns die Vefahren verraten (Hashverfahren der Passwörter etc.) Vielleicht findet sich eine Möglichkeit
dem Client das beizubringen... ;-)

s.o. die Frage ist, was ich als gemeinsames Geheimnis benutze? Da das Passwort im Server nur gehasht zur Verfügung steht.

Also dass das passwort nur gehasht auf dem Server liegt ist schonmal lobenswert!
Prinziepell wäre es jetzt praktisch wenn der Client das Hashverfahren ebenfalls beherrscht (lässt sich viell. nachrüsten?)

Die publickey-im-code variante hat noch ein paar tücken, z.B muss, falls das Passwort mit dem Public-key des Servers, verschlüsselt wird, die übertragene Nachricht einmalig sein, was ein encoding wie OAEP oder PKCS1v2 erfordert

Mit ein paar mehr infos zu den Verfahren und den Anforderungen lässt sich das evtl. besser beantworten...

 

[brainless]

Also dass das passwort nur gehasht auf dem Server liegt ist schonmal lobenswert!
Prinziepell wäre es jetzt praktisch wenn der Client das Hashverfahren ebenfalls beherrscht (lässt sich viell. nachrüsten?)

Das müsste ich mal überprüfen...

Die publickey-im-code variante hat noch ein paar tücken, z.B muss, falls das Passwort mit dem Public-key des Servers, verschlüsselt wird, die übertragene Nachricht einmalig sein, was ein encoding wie OAEP oder PKCS1v2 erfordert

Ich würde ein Hybrides Verfahren verwenden: Mit dem Public Key wird nur der Key für die Symmetrische Verschlüsselung ausgehandelt, welcher zufällig vom Client erzeugt wird. Und mit diesem wird dann das Passwort verschlüsselt. Dies sollte die Einmaligkeit gewährleisten.

 

[brainless]

Als erstes habe ich an ein Hybrides-Verfahren aus RSA und AES gedacht:

1. der Client erfragt beim Server den PublicKey
2. Server erstellt Private- und PublicKey und sendet den PublicKey an Client
3. Client erzeugt zufälligen SecretKey (AES) und verschlüsselt diesen mit dem PublicKey des Servers
4. Client sendet SecretKey an Server
5. Server entschlüsselt den SecretKey mit seinem PrivateKey
6. --> Client und Server kennen den SecretKey (AES)
7. --> alte Methode vom ersten Ansatz kann genutzt werden

Mir ist aufgefallen, dass dieses Verfahren anfällig für Replay-Attacken ist. Mallory sendet den verschlüsselten SecretKey an den Server und danach das verschlüsselte PW, ohne jeweils den genauen Inhalt zu kennen.
Als Gegenmaßnahme könnte der Server zu Beginn ein "Nonce" erzeugen, welche als Initialisierungsvektor für die AES-Verschlüsselung benutzt wird. So kann Mallory zwar den alten SecretKey dem Server unterschieben, aber das PW wäre falsch verschlüsselt?

 

[cafebabe]

Mir ist aufgefallen, dass dieses Verfahren anfällig für Replay-Attacken ist. Mallory sendet den verschlüsselten SecretKey an den Server und danach das verschlüsselte PW, ohne jeweils den genauen Inhalt zu kennen.
Als Gegenmaßnahme könnte der Server zu Beginn ein "Nonce" erzeugen, welche als Initialisierungsvektor für die AES-Verschlüsselung benutzt wird. So kann Mallory zwar den alten SecretKey dem Server unterschieben, aber das PW wäre falsch verschlüsselt?

Das kommt darauf an wie man's implementiert...
Meine Empfehlung wäre:

Vorbereitung:

• 
  Erzeuge private & public key des Servers
  Hinterlege den public key im Code des Clients (public key pinning)

Protokol:

• 
  Client erzeugt zufälligen geheimen Schlüssel für AES : SK
  Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
  Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
  Client sendet EK und EP an den Server
  Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
  Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
  Server berechnt Hashwert des Passworts : H = Hash (Passwort)
  Server überprüft ob H == DB_Hashwert, wenn ja ist das übertrage passwort richtig, wenn nein, wurde die Kommonikation manipultiert oder das passwort war falsch

Wichtig:
SK darf sich nicht wiederholen -> Sichere Zufallszahlen
Wie wird das Passwort auf die Blocklänge expaniedert? Padding, AES-CTR mit IV aus 0-bytes

Dieses Protokol ist unter folgenden Vorrausetzungen sicher:

• 
  SK wiederholt sich nicht -> krypt. sichere Zufallszahlen
  Ciphertext der Blockcipher ist von einer Zufallsfolge nicht zu unterscheiden (bei AES erfüllt)
  EK hoch e > n (e ist RSA-exponent , n ist RSA modulus), ansonsten muss z.b das OAEP verwendet werden

 

[brainless]

• Client erzeugt zufälligen geheimen Schlüssel für AES : SK
  Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
  Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
  Client sendet EK und EP an den Server
  Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
  Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
  Server berechnt Hashwert des Passworts : H = Hash (Passwort)
  Server überprüft ob H == DB_Hashwert, wenn ja ist das übertrage passwort richtig, wenn nein, wurde die Kommonikation manipultiert oder das passwort war falsch

Genau so hatte ich es mir ja gedacht. Nun ist aber doch folgendes Problem:

• Client erzeugt zufälligen geheimen Schlüssel für AES: SK
  Client verschlüsselt SK mit dem public key : EK = Enc_RSA (Pub , SK)
  Client verschlüsselt Passwort mit SK : EP = Enc_AES (SK , Passwort)
  Client sendet EK und EP an den Server
  böser Client Mallory fängt EK und EP ab (kennt aber SK und PW nicht, da verschlüsselt)
  beliebige Zeit später:
  Mallory sendet EK und EP an Server
  Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
  Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
  Server berechnet Hash und überprüft, böser Client Mallory authentifiziert

Obwohl Mallory SK und PW nicht kennt, kann er sich mit dem Mitgeschnitteten EK und EP anmelden (Replay-Attacke). Natürlich ist dann keine weitere Kommunikation möglich, da er SK nicht kennt. Aber das er sich anmelden kann, ist schon eine Lücke. ?

Das mit dem Padding habe ich mir schon notiert. Danke für deine Tipps. 🙂

 

[cafebabe]

• böser Client Mallory fängt EK und EP ab (kennt aber SK und PW nicht, da verschlüsselt)
  beliebige Zeit später:
  Mallory sendet EK und EP an Server
  Server berechnet geheimen AES Schlüssel : SK' = Dec_RSA (Pri , EK)
  Server berechnet Passwort : Passwort = Dec_AES (SK' , EP)
  Server berechnet Hash und überprüft, böser Client Mallory authentifiziert

Obwohl Mallory SK und PW nicht kennt, kann er sich mit dem Mitgeschnitteten EK und EP anmelden (Replay-Attacke). Natürlich ist dann keine weitere Kommunikation möglich, da er SK nicht kennt. Aber das er sich anmelden kann, ist schon eine Lücke. ?

Hab ich doch tatsächlich übersehen! Danke für den Hinweis! Im nachhinein, ist es dann völlig klar... ;-)
Die einfachste und wahrscheinlich sehr effektive Methode wäre das generieren einer Nonce durch den Server , wie du es bereits gesagt hast.
Am besten erzeugt der Server die Nonce gleich zu beginn und der Client verwendet diese zur verschlüsselung des Passworts. Der AES key kann weiterhin zufällig gewählt werden und asymmetrisch verschlüsselt übertragen werden.

 

[Tobse]

Seht ihr? Ihr habt es selbst versucht und seit direkt auf eine Lücke gestoßen 🙂 Ich sags nochmal: benutze TLS; und damit meine ich das Protokoll, nicht den ganzen kram drumrum.
Meines Wissens nach kann man die Java-Klassen, welche das SSL Protokoll implementieren, auch mit einem im Client gespeicherten Public-Key nutzen. Solange du ein KeyPair nimmst, was von einem bekannten CA signiert ist, musst du dich auch nicht um die Keystores kümmern.

Hier ein Auszug aus dem Google Android Developer Blog über SSL-Verbindungen ausserhalb von HTTP:

// Open SSLSocket directly to gmail.com
SocketFactory sf =SSLSocketFactory.getDefault();
SSLSocket socket =(SSLSocket) sf.createSocket("gmail.com",443);
HostnameVerifier hv =HttpsURLConnection.getDefaultHostnameVerifier();
SSLSession s = socket.getSession();

// Verify that the certicate hostname is for mail.google.com
// This is due to lack of SNI support in the current SSLSocket.
if(!hv.verify("mail.google.com", s)){
    throw new SSLHandshakeException("Expected mail.google.com, found "
                                    + s.getPeerPrincipal());
}

// At this point SSLSocket performed certificate verificaiton and
// we have performed hostname verification, so it is safe to proceed.

// ... use socket ...

socket.close();

 

[cafebabe]

Seht ihr? Ihr habt es selbst versucht und seit direkt auf eine Lücke gestoßen 🙂

Ja, und dann auch noch auf eine sehr banale...
Fast schon peinlich xD

Ich sags nochmal: benutze TLS; und damit meine ich das Protokoll, nicht den ganzen kram drumrum.

Ist im Allgemeinen auch die beste Wahl, aber auch hier muss man so manches bachten:
z.B ist TLS/SSL keine Option, wenn die Standardimplementierung < JDK-7 verwendet wird -> beherscht kein TLS_1.2
Ist in Unternehmen öfter mal der Fall, das JDK-6 noch im Einsatz ist.

Also ja, TLS ist (richtige version, CA-cert etc. vorrausgesetzt) die 1. Wahl.
Wenn man es aber richtig macht (nicht so wie ich vorher ;-) ), dann ist ein etwas einfacheres Protokoll (cha-resp + encryption) durchaus auch einsetzbar