[HaBo]

lone.wolf

Anzeige

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

enkore

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...

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++

Inliferty

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

enkore

Weil ein manipulierter Server dann beliebigen Code ausführen kann!?

__________________

"It is the human race! The deterioration of the spirit of man. Man undermining himself, causing a self-willed, self-imposed, self-evident self-destruction."

+++ BREAKING +++ Troll ertrinkt im Planschbecken +++

blue182

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

Elderan

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

Inliferty

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