Authentizität von informationen gewährleisten

[Memger]

Hi!
ich habe folgendes Problem:
ich habe zwei programme, einen client und einen server!
der client meldet sich beim server an und sendet diesem ein paar informaationen über sich. das problem ist nur, wie kann ich sicherstellen, dass diese informationen von "meinem" client gesendet wurden, und nicht von einem clienten, der von einem "bösen hacker" geschrieben wurde?
ich möchte also sicherstellen, dass die daten, die der server empfängt, nicht von diesem bösen hacker "gefaket" werden können.

über eine antwort würde ich mich sehr freuen!

danke schon mal

gruß Memger

[Tim Henford]

Hallo,

klingt interessant, das würde mich auch interessieren...

Mir würden im Moment nur Möglichkeiten einfallen, gewisse einmalige Daten mitzusenden - die könnten aber u.U. auch gefälscht sein.

Tschüss..

[Andreas Kosch]

Hallo,

angenommen, sowohl der Client als auch der Server setzen Windows 2000 ein. In diesem Fall würde ich die Anwendung als Three-tier-Anwendung anlegen, bei der der Client nur ein COM+ Objekt auf dem Windows 2000-Server aufruft. In diesem Fall darf man bei der COM+ Application im Eigenschaftsdialog auf der Registerseite <i>Sicherheit</i> die Option <b>Paketdatensicherheit</b> für die Aufrufe auswählen. In diesem Fall prüft das Betriebssystem bei jeder Kommunikation automatisch, ob <br>
a) beide Teilnehmer authentisch sind, und <br>
b) die Paketprüfsumme noch stimmt, wobei <br>
c) das Ganze auch noch verschlüsselt wird.<br>
Und das Ganze erhält man zum "Nulltarif" :-

[Memger]

Hi Andreas!
vielen dank für die antwort!
leider kann ich nicht davonausgehen, dass windows 2000 eingesetzt wird. im gegenteil, es wird vermutlich größtenteils win98(se) vorkommen..mmmh
wie sähe denn ein konzept zur authentizitätsprüfung grundsätzlich aus, also os-unabhängig??

schönen gruß

Memge

[Tim Henford]

Hallo,

Windows 2000 zum "Nulltarif" ist gut, wo bekomme ich das ?...

Könnte man nicht Windows 2000 unter 98 nachempfinden, das heißt
die oben genannten Komponenten mit Delphi realisieren?
<br>"
a) beide Teilnehmer authentisch sind, und <br>
b) die Paketprüfsumme noch stimmt, wobei <br>
c) das Ganze auch noch verschlüsselt wird.<br>
"<br><br>
Wie macht Win2k a) (es muss doch auch irgendwelche einmaligen Daten erkennen und senden - oder)?

Bei b) könnte man sich ja etwas wie CRC einfallen lassen und

c) dürfte auch machbar sein.

Tschüss Ti

[Memger]

hi Tim!
natürlich stimme ich dir zu. Der eigentliche knackpunkt ist jedoch punkt a) (was ja auch meine eigentliche frage war). denn woher weiß mein programm(server), dass es die anfrage vom client ala "hey server, bei mir ist alles in ordnung, sende mir ein paar geheime daten!" nicht von dem "bösen" hacker kommt, sondern von dem von mir programmierten client???

tja...

gruß
Memge

[Memger]

Hi!
Herr Kosch. eine frage an sie, wie würde denn ihr lösungsvorschlag unter win2000 aussehen ode hätten Sie ein code-beispiel?

vielen dank

gruß
Memge

[Gesine Kuhlmann]

Hi,

Dazu gibt es seit langem etwas, was unter dem Stichwort SSH ( SecureShell ) läuft. Komischerweise stammt es aus der Unix-Welt ;-), aber ist sogar unter Windows als Freeware erhältlich.

Also warum das Rad zweimal erfinden ??

Gruß
Gesin

[Andreas Kosch]

Hallo,

mit dem Satz <i>Und das Ganze erhält man zum "Nulltarif"</i> wollte ich nur darauf hinweisen, dass im eigenen Delphi-Programm <b>keine</b> zusätzlichen Komponenten oder Funktionsaufrufe notwendig sind, da sich ausschließlich das Betriebssystem um alles kümmert. Das Ganze wird visuell über den Eigenschafts-Dialog der COM+ Anwendung bzw. des mit Delphi compilierten COM+ Objekts konfiguriert. Wenn man dort diese Prüfungen einschaltet, stellt den Rest Windows sicher. Solange alle angeschlossenen Rechner einem gemeinsamen Domänen-Kontroller angehören, gibt es keinen zusätzlichen Aufwand

[Memger]

@Gesine: danke, aber SSH ist mir ein begriff! di authentifizierung soll aber unabhängig vom benutzer erfolgen, das PROGRAMM soll authentifiziert werden, und zwar genau mein Programm!!! (und nicht das fake-programm eines hackers z.B.

[Gesine Kuhlmann]

Hi Memger,

Dann würde ich ein PGP-ähnliches Verfahren zur C/S-Kommunikation verwenden. Dann bist du wieder bei dem Three-Tier-Vorgehen von A. Kosch. Aber egal wie du es anfängst ist eine Lösung immer offen wie ein Scheunentor, wenn du eine Umgebung ( alle Win9x-Versionen ) mit mangelnder Protokollsicherheit einsetzt. Um ein Programm zu identifizieren ist es m.E. am einfachsten, einen Nutzer anzulegen, der nur mit diesem einen Programm arbeiten darf. Dann ist Nutzer=Programm. Um die mangelnde Nutzersicherheit in den Win9x-Systemen wenigstens ein bischen sicherer zu gestalten, ist der heute übliche Weg Hardware mit entsprechenden Zusatzfunktionen zu verwenden (z.B. ISDN-Karten mit zusätzlichem EEPROM).

Fazit:
Auf'n besch.. Fundament bekommst du nie nen' Wolkenkratzer, auch wenn das manche aus Eigeninteresse gerne suggerieren.

Gruß
Gesin

[Memger]

Hi Gesine!
auf die analogie zu pgp bin ich auch schon gekommen, aber die sache ist, dass ich in meinem fall nicht den benutzer validieren will sonder das PROGRAMM. hintergrund ist folgender:
in einer client server umgebung läuft auf dem client ein programm (p), welches mit dem server kommuniziert! jetzt kann es aber vorkommen, dass der "böse hacker" zusätzlich zu programm (p) noch das programm "böse" programm (m) startet. dieses programm (m) verändert speicherseiten von (p), sodass der server falsche informationen von programm (p) erhält.
an dieser stelle möchte ich ein programm (g1) schreiben, welches wiederum (m) aushebelt und die erfolgreiche "aushebelung" dem server mitteilt. auf dem server wiederum läuft ein von mir geschriebenes programm (g2). nun weiß server, dass (c) sauber ist!!! aber woher weiß (g2) , dass die info "hey ich bin sauber!" von meinem programm (g1) kommt?????? (und nicht vom programm eines hackers, das einfach auch "hey ich bin sauber!" an den server schickt

[Gesine Kuhlmann]

Hi Memger,

Wieso ??

Wenn dein Middle-Tier von Clienten aus unsicheren Umgebungen nur verschlüsselte Daten entgegennimmt, dann wird es für einen Angreifer schon schwierig sich in die Kommunikation einzuschleichen bzw. sich als vertrauenswürdig auszugeben. Das 'böse' Programm müsste seine injizierten Daten ja in der gleichen Weise verschlüsseln, wie der 'echte' Client um nicht dumm aufzufallen. Die Sicherheit der Strecke vom Client zum Middle-Tier hängt dann also in erster Linie von der Stärke deiner verwendeten Verschlüsselung ab. Wichtig ist natürlich, dass du die Schlüssel selbst nie über eine ungesichert Strecke schickst. Die Kommunikation zwischen Middle-Tier und Server sollte durch transparente Verfahren ( eben SSH oder proprietäre MS-Algorithmen ) bereits gesichert sein.

Falls das böse Programm es nun darauf anlegt, dir den Schlüssel zu mopsen, siehst du natürlich wieder recht alt aus.

Gruß
Gesin

[Memger]

Hi Gesine!
selbst wenn ich die kommunikation verschlüssele, dann hört sich der hacker halt einmal die gesendeten daten meines programms an mit einem portsniffer und schickt mir das gleiche beim nächsen mal aber nun mit seinem programm. und einen schlüssel hart in dem client zu programmieren wäre auch schwachsinnig, der hacker benutzt einen disassembler und aht den key.....und da bringt mir auch ssh nix

gruß memge

[Hagen Reddmann]

Hi

Sehr interessante Diskusion.
@MemGer, der böse Hacker mit seinem (M) ist viel cleverer als Du und schreibt ein böses Program (m1) das Dein (g1) aushebelt um zu verhindern das (g1) sein (M) aushebelt. Daraufhin würdest Du nun (G2) ins Rennen schicken und der Hacker clever wie er ist seine Version (M2). Was das bringt kennen wir ja aus dem Kalten Krieg.

Kommen wir zur Authentifizierung:
Es wird ohne zusätzliche Hardware keinen Weg geben. Da hilft auch keine SSH oder COM-Certifizierung oder Win2000. Dein Protokoll ist so aufgebaut das Irgendwer Deine Software installiert und sich mithilfe Deiner Software , und nur mit dieser, Zugang verschaffen soll. Deine Software IST die lesbare Bedienungsanleitung, also so als würde der Hacker Deine Sourcen kennen. Da nutzt kein SSH oder sonstiges da irgendwo ja das "Passwort" bzw. "Geheimniss" bzw. "Zertifikat" gespeichert sein muß. Der Angreifer kann also jederzeit Deine Software durch seine eigene ersetzen, woraufs ankommt sind die Zertifikate. Diese kann er allerdings NICHT so einfach knacken, egal wie mans dreht eine gültige Public Key Signature KANN nicht geknackt werden. Sie kann aber vom Hacker in Deinem Falle einfach benutzt werden um sich gültig bei Dir einzuloggen.

D.h. in Deinem Protokoll hast Du eine Leine, am einen Ende sitzt der Server und am anderen Ende ?? weiste eben nicht und kannste auch NIE wissen, damit wackelt die Leine im Nrigendwo rum.
Sollte zur Software eine vom Server zertifizierte und einbruchssichere SmartCard dazukommen, sitzt am Clientende der Leine ein externes Stück vom Server. Beide kennen sich, beide sind einbruchssicher und somit ist die Leine an beiden Enden fest, die Wäsche kann sicher aufgehangen werden.

Gruß Hage