Daten sicher übertragen

[maynard]

Tach...

Erstaunlicherweise hat mir die Suche in diesem Forum kein Ergebnis zu diesem Thema geliefert
Jedenfalls geht es darum, Daten mittels Server / Client - Komponenten sicher bzgl. Authenzität und Intigrität zu übertragen. Da fiel mir sofort SSL ein, allerdings konnt ich im Internet nichts wirklich Informatives finden, zb. wie ich es auf meinem eigenen Server einsetzen kann, ob es was kostet und wenn wie viel usw.
Falls SSL nicht die Lösung ist, hatte ich vor, dass "Rad neu zu erfinden" und die Sache mit Hagen Reddmanns DEC anzugehen. Besonders interesant wäre für mich auch, was ihr mir zum Thema Secret Sharing sagen könnt.
Tja, vieleicht verirrt sich ja jemand in diesen Thread und kann mir weiterhelfen, bis denn ...

MfG maynard

[HeikoDD]

hi,

für SSL fällt mir sofort INDY und OpenSSL ein.
Soweit ich weiß brauchste für OpenSSL und Indy nix zahlen.

Gruß

[himitsu]

Es kann auch sein, das auf deinem Server schon SSL drauf ist - frag einfach mal bei deinem Provider nach (oder duchsuch mal seine WebSeite)

Ich denke in meinem Packet auch schonmal irgendwo was von SSL gesehn zu haben - eventuell ist's ja auch bei dir so

[fiasko]

Hallo,

OpenSSL ist GPL, also kein Problem und unterstützt SSL/TSL und ne menge an Chiper und Hash Algorithmen.

Aber für die direkte Verwendung aus Delphi wahrscheinlich ein bißchen ungeeignet. Besser kommt man da wohl mit den Indy's.

Wenn's auch eine extra Anwendung sein darf kann ich noch stunnel empfehlen - das nimmt OpenSSL und baut verschluesselte Verbindungen zu einem anderen stunnel/SSL-Server auf und unterstützt Client-Zertifikate zur Authentifizierung und ne Menge mehr.

(Sowohl OpenSSL als auch STunnel gibt es als fertige Windows Binaries)

[maynard]

Tach...

Danke zuerstmal für die Hilfe.

Zitat von HeikoDD:

für SSL fällt mir sofort INDY und OpenSSL ein.
Soweit ich weiß brauchste für OpenSSL und Indy nix zahlen.

Das klingt schonmal sehr gut, werde mich dann gleich mal zu den Indy - Komponenten und OpenSSL informieren.

Zitat von himitsu:

Es kann auch sein, das auf deinem Server schon SSL drauf ist - frag einfach mal bei deinem Provider nach (oder duchsuch mal seine WebSeite)

Sorry, da habe ich mich wohl etwas falsch ausgedrückt. Ich bin dabei eine Server - Client Software zu schreiben. Unabhängig ob auf dem Server sichere Verbindungen möglich sind, soll die Software immer sichere Verbindungen aufbauen können.

Zitat von fiasko:

OpenSSL ist GPL, also kein Problem und unterstützt SSL/TSL und ne menge an Chiper und Hash Algorithmen.

Aber für die direkte Verwendung aus Delphi wahrscheinlich ein bißchen ungeeignet. Besser kommt man da wohl mit den Indy's.

Wie gesagt, werde mir beide Varianten gleich anschauen und dann entscheiden, was sich am besten für mich eignet und vor allem am besten in den bestehenden Code integrieren lässt.

Ok, danke nochmals an euch alle...

NACHTRAG ::

So, ich hab jetzt mal kurz ein bischen rumgestöbert und dabei diesen
Link gefunden. Muß zugeben, ich hab nur den Anfang kurz überflogen... allerdings gehts hier erstens um HTTP - Verbindungen und das ist nicht das richtige, meine Verbindung soll bis zur ausdrücklichen Beendigung bestehenbleiben und nicht bei jedem neuen Request wieder aufgebaut werden. Zweitens ist hier die Rede von Zertifikaten (schätze, dass ist vieleicht der öffentliche Schlüssel ) und privaten Schlüsseln die Rede, die von verschiedenen Autoritäten erworben werden können. Also hab ich gleich mal bei einem Anbieter (Verisign) vorbeigeschaut und da kommen dann kosten auf den Anwender zu. Habt ihr noch mehr Links zu diesem Thema, die mir allgemein in dieser Materie (Kryptographie/SSL) weiterhelfen könnte?? Ach, hat Hagen Reddmann eingenlich eine HP ... da ist ja da schon richtig spezialist auf diesem Gebiet.

MfG maynard

[negaH]

Nein, habe keine HP.

Eine Frage kann ich dir noch beantworten, Secret Sharing.
Solche Verfahren wirst du höchstwahrscheinlich nicht benötigen für deine Client/Server Anwendung.
Im Grunde kann man Secret Sharing mit einem Banktresor vergleichen. Es gibt 2 Schlüssel die an 2 Personen verteilt werden. Nur mit beiden Schlüsseln gleichzeitig kann man den Tresor öffnen. Das ist im Grunde Secret Sharing, nur das die heutigen Elektronischen Formen eben viel mehr können. Man kann 1000'ende Schlüssel erzeugen bei denen aber immer 5 verschiedene Schlüssel nötig sind um das geheimnis zu entschlüsseln. Man kann sogar diese 1000 möglichen Schlüssel unterschiedlich gewichten, also Hierarchien einbauen. Es gäbe dann Schlüssel die nur einen einzigsten weiteren starken Schlüssel benötigen um das geteilte Geheimnis zu entschlüsseln, oder aber es gäbe zum gleichen Geheimnis andere Schlüsselgruppen bei denen dann 10 verschiedene Schlüssel benötigt werden.
D.h. man kann die geheimen Daten mit ganz vielen Schlüsseln schützen, es werden immer eine bestimmte Anzahl dieser Schlüssel benötigt um wieder entschlüsseln zu können, und je nach Schlüsselwichtigkeit kann diese Anzahl varieren.

Somit ist das Secret Sharing ein Mittel der Schlüsselverwaltung. Es wird benutzt als sehr sichereres Backupsystem für Masterschlüssel, als Zugangskontrolle bei denen Mehrparteien nötig sind, fazit zur Gewaltenteilung, aber auch zur Anominisierung von Gewaltenentscheidungen. Denn mit hilfe des Secret Sharings, bzw. der gleichen mathematischen Grundlagen, ist es möglich das ein Vertrag durch mehrere Parteien unterzeichnet wird so daß erst nachdem ALLE Parteien unterzeichnet haben die gemeinsamme Unterschrift gültig wird. Der Vertrag selber könnte sogar unbekannt und der Inhalt für die einzelnen Parteien nur teilweise bekannt sein. Denoch kann man über solche Verfahren die Protokolle zur Unterzeichnung absichern so das keiner betrügen kann. Alles ist elektronisch über ungesicherte Datenkanäle durchführbar OHNE das einer schummeln oder dritte Einfluß nehmen können.
Da Geld auch nichts anderes als "Gewaltenteilung" ist lag die Idee die Methoden des Secret Sharings auch für elektronisches Geldzu benutzen nicht weit. Und tatsächlich gibt es Verfahren die sicheres elektronisches Geld über secret sharing ermöglichen. Selbst elektronische Aktien wären so möglich.

Wohl eher nicht das richtige für dich.

Achso, ein sehr bekanntes Verfahren nennt sich Asmut-Bloohm und ein weiteres ist von Diffie Hellman (nicht der DH Schlüsselaustausch).

Gruß Hagen

[fiasko]

Zitat von maynard:

So, ich hab jetzt mal kurz ein bischen rumgestöbert und dabei diesen
Link gefunden. Muß zugeben, ich hab nur den Anfang kurz überflogen... allerdings gehts hier erstens um HTTP - Verbindungen und das ist nicht das richtige, meine Verbindung soll bis zur ausdrücklichen Beendigung bestehenbleiben und nicht bei jedem neuen Request wieder aufgebaut werden.

Wozu denn das? Ob das sich nun um HTTP handelt oder ein andere "Socket-Verbindung" ist ja wurscht...

Zitat von maynard:

Zweitens ist hier die Rede von Zertifikaten (schätze, dass ist vieleicht der öffentliche Schlüssel ) und privaten Schlüsseln die Rede, die von verschiedenen Autoritäten erworben werden können. Also hab ich gleich mal bei einem Anbieter (Verisign) vorbeigeschaut und da kommen dann kosten auf den Anwender zu.

Die Zertifikate dienen dazu um die Authentizität der Parteien zu sichern. Grob gesagt gibt es da eine CA (Certificate Authority) der du vertraust (bzw. dein Browser Hersteller, der die Zertifikate der CA's in deinen Browser eingebaut hat). Diese CA's stellen also Zertifikate aus (für viiiieeel Geld) und bestätigen damit die Authentizität von z.B. Web-Seiten. Wenn dein Browser eine CA nicht kennt, nervt er dich dann jedesmal wenn du auf eine Web-Seite mit einem Zertifikat welches von so einer unbekannten CA signiert wurde surfst. IMHO hat das System aber eine rießige Schwachstelle - du mußt nämlich dem CA Aussteller ("Trustcenter") vertrauen .

Für deinen Fall ist das aber erstmal egal, man kann auch seine eigene CA Aufbauen (da gibt von openssl Skripts dazu) und so die Authentifizität seiner Clients gewährleisten. Mit deiner CA erstellst du einfach für jeden Teilnehmer ein eigenes Client Zertifikat, und die können dann mittels des öffentlichen CA-Zertififkates gegenseitig überprüfen ob die Kommunikationspartner vertrauenswürdig sind.

Die ganze Verschlüsselungsgeschichte ist davon unabhängig - das wird dann klassisch über DH und Co gemacht.