Sicherer, authenzitierter Datenaustausch Client+Server

[gore]

Hallo,

wir müssen für eine größere Firma eine Client-Server-Anwendungen für W2k und XPPro erstellen. Die Daten müssen sicher zwischen Client und Server Rechner übermittelt werden (Authentifizierung: Fragt wirklich der Client an? Kommen die Daten wirklich vom Server? Wurden die Daten auf dem Übertragungsweg verändert?).
Können wir das in Delphi machen? Vorschläge? Hinweise?
Schön wäre es wenn das Client-Programm nicht zu groß wird - also würde ich alles im reinen Win32 API programmieren.
Meine Idee ist es die Daten via Named Pipe zu übertragen (vorher verschlüsseln+signieren, aber wie stelle ich sicher, dass die Daten wirklich vom Client oder Server kommen?)
Oder sollen wir lieber auf RPC (siehe Writing a Secure RPC Client or Server) setzen?
Oder kann man diese Kommunikation über das MS CryptoAPI abwickeln?

Vielen, vielen Dank für jeden Denkanstoß!

Bernd

[negaH]

Vieleicht ist das was für den Anfang:

http://www.delphipraxis.net/internal...976&highlight=

Eines steht jetzt schon fest, egal für welche Methode du dich entscheidest, du benötigst auf Client Seite immer ein sicheres Passwort. Also auch wenn du mit digitalen Signaturen und MS Crypto API oder secure RPS arbeiten möchtest, so müssen auch bei diesen Verfahren die Secret Keys für die Signaturen orgendwo auf dem Rechner gespeichert sein. Damit diese dann sicher sind werden sie verschlüsselt gespeichert, benötigen also wiedrrum ein Passwort. SRP hat eben den Vorteil das man auf Client Seite keinerlei Daten zu den Schlüseln speichern muß und ist ansonsten identisch sicher (wenn nicht sogar sicherer) als über PRC+MS Crypt API zu gehen. Davon abgesehen ist SRP frei verfügbar. Suche im Netz nach SRP-6a.

Gruß hagen

[gore]

Vielen Danke! Ich werde das studieren!
Gibt es sonst noch Meinungen, Hinweise oder Ideen?

Gruß
Bernd

[gore]

negaH, in den NewsGroups fand ich folgendes "SRP seems like a poor-man's authentication system that is good enough. But falls significantly short of the other services provided by protocols like Kerberos."
Ich möchte auch wenig Fremdkomponenten verwenden (Sicherheitslecks..., VistaUpdates), deshalb wäre mir eine Lösung basierend auf API Funktionen die W2k und XPPro bereitstellen am liebsten. Was kann ich da machen?
Danke,
Bernd

[negaH]

Also, das SRP ein schlechtes Protokoll sein soll davon höre ich zum ersten mal. Es wird eher so sein das Kerberos ein so veraltetes Protokoll ist das sich moderne Algortihmen nicht integrieren lassen. Wenn du dir ein fundiertes Urteil bilden möchtest dann schau in den Newsgroups bei news.scicrypt rein.

Ich kenne mich ein bischen mit Kryptographie aus und kann dir folgendes versichern:

1.) SRP ist ein sehr modernes und sehr sicheres Protokoll. In fact ist es die beste Lösung für ein Passwort basiertes Authentiifkations- und Schlüsselaustauschprotokoll. Besser als jede Lösung wie zb. SSL,SSH oder so. Allerdings muß man immer sehr differenzieren und die verknüpften Zielsetzungen für ein Protokoll betrachten. Soll heisen das je nach Aufgabenstellung SRP zb. nicht mit SSL vergleichbar ist.

2.) egal welche Lösung du benutzt, schlußendlich wirst du immer ein Passwort auf Clientseite benutzen müssen. Es sei denn du benutzt eine Hardwarebasierte Authentifikation, zb. SmartCards (hat jeder Client ein SmartCard Reader und möchtest du dir den enormen Streß im Support antuen mit dem beschie..enen Microsoft SmartCard API ??), oder zb. RSA-Cryptotoken-ID (vertraust du einem nicht veröffentlichtem und prohibitärem Algorithmus dessen Sicherheit nicht verifizierbar ist??).

3.) baust du auf APIs wie MS CryptoAPI so wirst du noch viel weniger Einblicke in die reale Implementierung bekommen. DU musst also noch viel mehr darauf vertrauen das alles sicher ist und du kannst es eben nicht selber verifizieren, du hast ja die Sourcen nicht. Im Falle meiner SRP Implementation kannst du

a.) die Sourcen von mir einsehen
b.) das SRP Verfahren als Algorithmus im WEB nachschauen, es ist alles vollkommen veröffentlicht
c.) auf den einschlägig als fachfundiert bekannten Seiten wie scicrypt Analysen vom SRP von Experten nachlesen
d.) bei bekannten secret Startwerten jeden Berechnungsschritt meiner SRP Implemenation selber in einer eigenen Implementierung nachberechnen und somit reproduzieren und ergo als sicher verifizieren. Das wirst du mit SmartCards, RSA TokenIDs niemals können denn diese sind einbruchsichere Hardware und du musst immer dem Hersteller trauen. Nur nebenbei bemerkt, wenn du mein DECMath samt Beispielen downlodest dann wirst du dort ein Beispeiel eines "forged RSA" finden. Dieses demonstriert einen absolut korrekten und äußerlich sicheren RSA Algorithmus, der aber denoch auf Grund seiner Schlüsselerzeugung durch den "Wissenden" sofort geknackt werden kann. D.h. derjenige der die Schlüsselerzeugung programmiert hat kann von jedem RSA Schlüssel (nur dem öffentlichen Teil wohl bemerkt) sofort diesen Schlüssel knacken, obwohl diese Schlüssel ansonsten identisch sicher zu normalem RSA sind !! Das bedeutet, kennst du die RSA Implementierung die im MS CryptoAPI real benutzt wurde NICHT als Source so kannst du deren RSA garnicht mehr vertrauen. Denn ich habe bewiesen das es Möglichkeiten für die RSA Implementierung gibt die einen verdeckten Kanal einrichten und so deren erzeugte RSA Schlüssel sofort brechen kann. Das es sowas gibt, geben muß, ist ein offenes Geheimnis.
Nun der Geck was grlaubst du worauf die meisten Digitalen Signaturen/Authentifizierungen, wie zb. SSL/SSH bauen ? auf RSA !

SPR arbeitet nicht mit dem Faktorizationsproblem wie RSA, sondern auf dem Problem der Logarithmen und deren Inversionen. SRP arbeitet also mit einem abgewandelten Diffie Hellman Verfahren. Es gibt sogar SRP Varianten die in Elliptischen Kurven arbeiten, was ich für noch besser halte. Bisher habe ich aber meine Elliptische Kurven Version vom SRP noch nicht fertig bekommen

Gruß hagen

[negaH]

Zitat:

Ich möchte auch wenig Fremdkomponenten verwenden (Sicherheitslecks..., VistaUpdates)

Sicherheitslecks, je komplexer ein System desto mehr Lecks entstehen. Ein komplexes System dieser Art ist meiner Meinung nach das MS Windows OS, ergo Vista. Und es zeigt sich ja immer wieder das gerade dort enorme Sicherheitslücken auftreten. Egal erstmal warum sie auftraten !

Zitat:

, deshalb wäre mir eine Lösung basierend auf API Funktionen die W2k und XPPro bereitstellen am liebsten. Was kann ich da machen?

Ja dann arbeite dich ins MS API ein und nutze es. Es sind grundsätzlich alle notwendigen Funktionen vorhanden. Eine Garantie für Kompatibilität, und somit weniger Supportaufwand, wirst du aber dadurch keinefalls bekommen. Nicht umsonst gibt es genügen Softwarefirmen mit Spezialisierung auf Kryptrographie die mit ihren eigenen Bibliotheken, am MS API vorbei, genügend Geld verdienen. Warum wohl ?

Gruß Hagen