Client<->Server Authentifizierungsproblem

L

lone.wolf

0
Hoi, mal wieder was von mir ;)

Ich frag mich hier gerade, ob es eine Methode gibt, mit die eine Server Anwendung EINDEUTIG feststellen kann, dass es sich bei den zu ihm verbindenden Clienten um einen für den Server speziell entwickelte Clienten handelt.

Falls das Problem nicht in diese Sparte passt, wäre ich sehr erfreut darüber, wenn ein Mod sich darum kümmern könnte.

Mein bisheriger Gedanke:
-Server generiert einen Buffer, verschlüsselt es mit <Server.PrivatKey> und schickt es dem Client
-Client entschlüsselt mit <Server.PublicKey>, ~verunstaltet den Buffer, verschlüsselt ihn mit <Client.PrivatKey> und schickt es dem Server
- Server entschlüsselt mit <Client.PublicKey> und prüft, ob der Buffer dem vorberechnetten (siehe Veruntaltung) entspricht.

Die Schwachstelle hier ist, dass man eine Applikation zu 100% reverse-engineer'en kann. Somit wären die Keys im Clienten aufdeckbar und joa... der Gedanke ist leider Kloreif. Und sonst fällt mir auch nichts ein.

Gute Nacht *gähn,
MfG
 
Zuletzt bearbeitet:
Hardwaretokens sind vermutlich keine Option. Man könnte den Server dem Clienten auch Assembler schicken, den der dann ausführen soll. Ist zwar ne Top-Sicherheitslücke aber relativ schwer zu knacken, denke ich...
 
csde_rats hat gesagt.:
Hardwaretokens sind vermutlich keine Option. Man könnte den Server dem Clienten auch Assembler schicken, den der dann ausführen soll. Ist zwar ne Top-Sicherheitslücke aber relativ schwer zu knacken, denke ich...
Zum Vergrößern anklicken....

Ein Hardwaretoken würde nur den Client-PC identifizieren jedoch nicht die Applikation selbst.
Zum gesendeten Assemblercode - Warum sollte die nachgebaute Applikation nicht den Code ausführen?

lone.wolf so wie du dein Problem schilderst ist es 100% nicht möglich die Applikation genau zu identifizieren.
Natürlich kann man den Aufwand jedoch hoch halten, nur steht dann irgendwann nicht der Sinn des Programmes im Hintergrund?

MfG
Inliferty
 
lone.wolf hat gesagt.:
Hoi, mal wieder was von mir ;)

Ich frag mich hier gerade, ob es eine Methode gibt, mit die eine Server Anwendung EINDEUTIG feststellen kann, dass es sich bei den zu ihm verbindenden Clienten um einen für den Server speziell entwickelte Clienten handelt.
Zum Vergrößern anklicken....

Verstehe ich das richtig?
Du willst also, dass nur eine ganz bestimmte Applikation mit dem Server kommunizieren kann?

Um das wirklich sicher zu machen, würde ich einen RSA verschlüsselten Diffie-Hellman einsetzen. Ist zwar extrem viel Overhead, aber sicherer geht es wohl im Moment nicht.
Knackpunkt ist in deinem Szenario dann, dass du den privaten Schlüssel aus Hardware-Spezifischen Faktoren des Klienten bildest und dem Server den öffentlichen Schlüssel hinterlässt - Jetzt nicht beirren lassen, die Rollen der Schlüssel müssen natürlich getauscht werden, was aber keine Rolle spielt ;)
 
Hallo,
man könnte hier mit clientseitigen SSL-Zertifikaten arbeiten, so könnte sich sowohl der Server beim Client ausweisen, als auch der Client beim Server.

Alternativ bietet sich noch das Challenge-Response-Protokoll an. Der Server sendet eine Zufallszahl an den Client, der Client signiert diese Zahl (z.B. mit RSA 'entschlüsseln') und der Server überprüft dann die Signatur (z.B. bei RSA mit dem public key verschlüsseln).

Dabei hat der Server den Public-Key des Clients zuvor gespeichert und im Client wird der private Key mitgeliefert.

So erfolgt aber nur die Authentifizierung, man müsste dann noch gucken wie man die Verbindung sichert (z.B. zuvor per Diffie-Hellman einen Schlüssel austauschen).
Das Challenge-Response-Protokoll wäre eine Vereinfachung von der Authentifizierung per Client-SSL-Zertifikat. Um beides zu haben (sichere Verbindung UND gegenseitige Authentifizierung), wäre in der Tat SSL mit Server und Client-Zertifikat zu empfehlen, insbesondere da es dort schon viele fertige Implementierungen gibt.


Allerdings, wenn ich dich richtig verstanden habe, machst du dir auch sorgen, dass jemand auf Clientseite angreifen könnte und das Programm stehlen könnte und wo anders ausführen könnte.
Dies ist in der Tat ein Problem und lässt sich mit Kryptographie selber nicht lösen.

Das sicherste wäre ein Hardware-Token bzw. eine Smartcard, die man dem legitimen Benutzer aushänigt. Dieser würde dann die entsprechenden kritischen Operationen durchführen.

Dies ist aber denk ich mal wenig praktisch. Ansonsten musst du dein Programm so gegen reverse-engineering schützen, dass die Geheimisse geschützt bleiben. Das dies funktioniert, zeigt z.B. Microsoft, Skype und diverse Computerspielehersteller.
Da diese Schutzmechanismen auf Geheimhaltung basieren, wo genau die geheimen Daten nun abgespeichert werden, findet man kein Patentrezept wie man dies anstellt. Überlicherweise erfordern diese Programme eine Online-Registeriung.

Man könnte es so machen, dass der User einen Aktivierungscode bekommt. Dann nach der (erfolgreichen) Registeriung könnte der Client ein entsprechendes SSL-Clientzertifikat runterladen und es zukünftig zur Kommunikation nutzen. Dieses müsste aber entsprechend gut im Dateisystem / auf dem Computer versteckt werden, so dass ein Angreifer es nicht finden kann.

Evt. ist auch der Microsoft Key Container nützlich, sofern die Applikation für Windows gedacht ist.

Hoffe das hilft weiter
 
csde_rats hat gesagt.:
Weil ein manipulierter Server dann beliebigen Code ausführen kann!?
Zum Vergrößern anklicken....
Das ist schon klar, aber es geht hier nicht um manipulierte Server :)
Und wenn wir uns ehrlich sind:
Ließt du bei jedem Update deines Anti-Virus, Firewall, Firefox, Chrome, ... den Changelog und überprüfst nachher noch ob es wirklich ein Update des Herstellers ist?
Und nichteinmal dann ist sicher, ob die Datei nicht kompromittiert wurde.
Ein Beispiel das mir jetzt gerade dazu einfällt wäre eine frühere Version von putty.

@blue182:
Soweit ich dein Konzept verstanden habe willst du den Schlüssel aus der Hardware bastln.
Problem wäre hier wiederrum, das nur die Hardware, jedoch nicht die Software verifiziert für den Gebrauch ist.

MfG
Inliferty
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben