Stream zwischen Server und Client verschlüsseln

[tom81]

Hallo Zusammen,

mir geht es hier nicht um die konkrete Umsetzung in diesem Thread, denn ich habe erst angefangen mir einige Grundlegende Gedanken zu machen.

Ich möchte eine Java Anwendung schreiben, die mit einem Server kommuniziert. Der Server soll seine Daten aus einer Datenbank bekommen und als XML Strom an den Client schicken.

So, jetzt habe ich mir das so gedacht, der Server macht eine Abfrage beim Datenbankserver und dann einen XML-Steam aus dem Ergebnis, das wird gezipt und das Ergebnis mit AES128 verschlüsselt, anschließend dem Client mitgeteilt.

Der Client entschlüßelt das ganze und entzipt den Datenstrom, anschließend wird alles weiterverarbeitet.

Jetzt zu meiner Frage, eurer Meinung:
Wie sollte man am besten die Encryptionkeys austauschen? Ich meine wie könnte man das sauber implementieren?

1. Public Key
2. Passpharse
3. Dem Server und dem Client die gleiche Bytesequenz als key verpassen (Im Quelltext)

Gibt es noch andere Möglichkeiten, bessere Wege? Ich bevorzuge ja schon das symetrische verfahren, weil es einfacher ist die Clients an das System zu hängen aber andererseit hätte ich gerne eine relativ sichere Lösung...

Beste Grüße
tom

 

[kazcor]

Kommt auf die Anforderungen an bzw. das Einsatzgebiet.

Ich würde das ganze auf Standards aufbauen, also eine PKI aufsetzen, welche via XKMS Schlüsselmaterial bereitstellt (z.B. EJBCA) und dann damit Schlüssel für Transport-Security (TLS), XML-Encryption (xmlenc/xmldsig) oder beides in Kombination verwalten. Die Kompression kannst Du ja entweder XML-intern regeln mittels eigenem Typ, so dass die Struktur erhalten bleibt, oder auf die Transportebene verlagern, indem Du ein passendes Protokoll wählst und das unabhängig von der Anwendung hast.
Am effektivsten könnte je nach Fall auch eine Kommunikation via SOAP/HTTPS sein, über welche Du nur Steuerdaten austauschst (Metainfos) und einen PSK überträgst, welchen Du für einen anderen sicheren Kanal zum effizienten Übertragen der eigentlichen Daten (bei Bedarf) verwendest.

Ist natürlich nur eine Variante und evtl. etwas zu kompliziert gedacht

 

[tom81]

Danke, das ist ganz interessant zumindest mal ein wenig Lesestoff

Aber ich tendiere schon mehr zur symmetrischen Verschlüsselung weil die Bedienbarkeit der Anwendung auf Clientseite so einfach wie möglich sein soll. Andererseits sind Passwörter immer mal wieder suboptimal, entweder man vergisst sie oder man wählt zu leichte... Das Hardcoden eines Passpharse fällt wieder unter die Rubrik "Securit by obscurity" also sind wir wieder bei PKI.

Und dabei wollte ich nur mit der Flut an Stundenzetteln aufräumen

Im Grunde ist es genau das, ich schreibe meine Stunden auf dumme Zettel und am Monatsende ordne ich diese meinen Kunden zu und übertrage die in Tabellen, aus denen ich wiederum Rechnungen schreibe... verliere ich einen dieser Postits, verliere ich bares Geld.

Bei meiner Arbeit habe ich aber immer ein Handy zur Hand (Android) und damit möchte ich meine Zeiten sauber und zentral speichern. Jetzt sollten die Kundendaten natürlich nicht als Freitext durchs Web fliegen, zumindest nicht zu offensichtlich, deshalb meine Idee

Und jetzt eine weitere Frage, ist es überhaupt möglich oder wenig aufwändig die Schlüssel zwischen Server und Client auszutauschen?

Also App wird installiert und erzeugt ein Schlüsselpaar, danach teilt es den öffentlichen Schlüssel dem Server mit und dieser tut dasselbe. Danach können die zwei sich ungestört unterhalten... Ist das in etwa so korrekt gedacht oder zu kompliziert?

Nach den Fragen, frage ich mich warum ich bloß in der IT-Sicherheit Vorlesung so oft geschlafen habe?

Beste Grüße
Tom

 

[oenone]

Bei meiner Arbeit habe ich aber immer ein Handy zur Hand (Android) und damit möchte ich meine Zeiten sauber und zentral speichern. Jetzt sollten die Kundendaten natürlich nicht als Freitext durchs Web fliegen, zumindest nicht zu offensichtlich, deshalb meine Idee

Warum nicht einfach nur HTTPS oder SSL? Da ist die Kommunikation verschlüsselt, Schlüssel wird per Diffie-Hellman ausgetauscht, keine Infrastruktur oder shared keys nötig (außer ein Zertifikat für den Server).

 

[tom81]

Also ein HTTP Server soll da nicht laufen und wenn ich SSL verwende muss ich mich gegenüber dem System ja immer noch authentifizieren um an die Daten zu kommen. Da wären wir doch wieder beim Passpharse?

Ich mache mir je keine Gedanken, darüber wie mein Passwort lautet aber sollte jemand anders als ich das System benutzen und Passwörter wie "12345" benutzen... Ja, sowas würde ich gerne vermeiden und deshalb diese Diskussion

Es ist ein reines Gedankenspiel, ich habe keine riesigen Erfahrungen in dem Bereich, habe mich damit eher nebenbei beschäftigt und hab jetzt etwas Zeit und interesse daran zu arbeiten und der Input, der bisher kam, gefällt mir Danke!

Ich werde mal einen kleinen Server basteln, der ein paar simple Anfragen beantwortet um die verschiedenen Möglichkeiten zu testen, mal schauen was da so geht.

Beste Grüße
Tom

 

[kazcor]

Du kannst die Authentisierung auch gerade über die via SSL verwendeten Schlüssel machen - also quasi ähnlich SSH via keys, um mal den Vergleich heranzuziehen. Dazu verwendest Du serverseitig einen SSLServerSocket mit forcierter client-authentication und fertig bist Du. Sind codetechnisch auf client- als auch auf serverseite vielleicht 10 Zeilen

 

[tom81]

Aber für das gegenseitige Authentifizieren mit Schlüsseln brauche ich schon eine PKI Infrastruktur oder diese wäre zumindest besser, wenn man mehrere Geräte initialisieren will?

Aber die Idee gefällt mir mit am besten...

 

[kazcor]

PKI ist immer relativ. Mit ein paar openssl-Befehlen hast Du auch eine PKI aufgebaut, nur eben ohne Frontend und Services wie sie OpenCA/EJBCA anbieten. Eigentlich kannst Du für alle Deine Endgeräte auch das gleiche Client-Zertifikat/Keypair verwenden - wenns Dich nicht stört, ist ja quasi eine Einbenutzerapplikation Der OpenVPN-Port (zumindest bei fbsd) bringt z.B. eine Skriptsammlung mit, um sowas ganz einfach mit 3-4 Befehlen zu erzeugen.