Serial ohne Seed

[Meflin]

Aloha!

Ich habe eine Client und eine Serveranwendung, die Clientanwendung kann beim Server Datenpakete ordern. Um zu verhindern, dass böswillig Datenpakete von Fremdanwendungen geordert werden und somit verloren gehen, möchte ich gerne etwas in dieser Art implementieren:

Der Client generiert eine zufällige "Seriennummer", sozusagen einen Key nach einem bestimmten Verfahren. Der Server sollte dann die Validität des Keys überprüfen können ohne diesen aus irgendeinem seed zu bilden, sprich der Unterschied zu normalen Serial Verfahren besteht darin, dass es keinen gemeinsamen Wert gibt aus dem dieser Schlüssel gebildet wird.

Wenn der Schüssel dann vom Server als valid erkannt wird, erhält der Client sein Datenpaket und fertig.

Wie also lässt sich so was realisieren?

[Dax]

Du könntest eine Art Initprotokoll implementieren:

> Client verbindet zum Server und sendet einen Initrequest
> Der Server schickt dem Client ein Initpaket, das der Client verrechnet, hasht und auf dem Port mit der Nummer LowWord(Hash) wieder (verschlüsselt) mit dem Server verbindet (kannst die Portnummer auch anders berechnen, musst eben nur sicherstellen, das der Server den Port auch offen hat)
> Von da aus schickt der Server dem Client (verschlüsselt) einen "endgültigen" Initstream, in dem alles drinsteht, was der Client wissen muss
> Beide trennen sich wieder

Muss nicht funktionieren und hat garantiert Lücken, scheint aber nicht unbedingt eine dumme Lösung zu sein ^^

[generic]

public key verschlüsselnungen ? ssl? tls?

die indy's können das alles - warum das rad neu erfinden.
brauchst nur 2 zertifikate und dann geht das los.

eigendlich brauchst du nur eins.

client denkt sich nummer aus (session key).
diese wird mit dem publickey des servers verschluesselt.
dann wird das verschlüsselte zum server übertragen.
der entschlüsselt das wieder und hat einen session key der zum verschlüsseln taugt.

[Sharky]

Hai Meflin,

wie oft werden denn vom Client Daten angefordert?

Eventuell kannst Du das ganze auf der Basis eines Passwortes und daraus abgeleiteten MD5-Hashs machen.

[MrKnogge]

Oder schau dir mal das DEC an, eventuell ist ja ein OneTimePassword das richtige für dich.

gruss

[negaH]

Das OTP/sKey Verfahren im DEC ist ungeeignet.

Ohne ein Mehrstufen Protokoll wird das niemals kryptographisch sicher umzusetzen gehen (jedenfalls nich ohne zus. Krypto Hardware). Da Meflin aber eben möchte das der Client sofort und direkt authentifiziert werden kann ginge dies nur über digitale Signaturen, sprich Public Key Kryptographie. Der Hacken dabei ist aber das der Schlüssel des Servers schon auf Clientseite bekannt sein muß. Diesen Schlüssel kann man aber als Hacker extrahieren und in die eigene Anwendung einbauen, ergo sich als berechtigter Client ausgeben.

Deshalb meine ich das du unbedingt ein Mehrstufen Protokoll benötigst, zb. SRP ist sehr gut. Bei so einem Protokoll wird der Server und der Client mehrmals nacheinander verschiedene Daten austauschen. D.h. also auch einen Seed auf Serverseite.

Man kann aber zumindestens alle "unintelligenten" Scanning Angriffe auf den Server Port ausschließen. Dazu arbeitet der Server im Stealth Modus. Der Client verbindet mit dem Port und sendet ein Identifizierungs-Packet. Wird dieses Packet nicht gesendet so antwortet der Server überhaupt nicht. Ein Port Scanner wird diesen Port dann als offen aber nicht aktiv erkennen. Die meisten Server, besonders die MS eigenen, senden sofort nach Verbindungsaufbau an den Clienten ein Identifizierungs String. Ein Scanner kann daraus ermitteln was sich hinter dem Port für eine Software befindet und darauf aufbauend eben Angriffe starten.

Gruß Hagen

[generic]

austricksen lässt sich alles.

nur die frage ist viel aufwand will man reinstecken?
(zum austricksen und zum schutz)

[Sharky]

Zitat:

Zitat von generic

austricksen lässt sich alles.

nur die frage ist vieleich aufwand will man reinstecken?

:gruebel:
Hmmm... kannst Du das auch so formulieren das es jeder versteht? :stupid:

[Meflin]

Aloha!

Dann will ich auch mal wieder was dazu sagen 8)

@sharky: das mit der Verbindungshäufigkeit ist ganz und gar unterschiedlich. Es kann sich um Stunden, aber auch nur um Minuten oder Sekunden bis zum nächsten Connect handeln. Das kommt ganz darauf an, wie der User das Netzwerk konfiguriert.

@generic: wie das mit den Zertifikaten funktionieren soll, ist mir im Moment nicht ganz klar :stupid:

@negaH: bist du sicher dass das Ding SRP heisst? Ich habe da nämlich nichts gefunden... zumindest nichts was mit dem Thema zu tun hätte :stupid:

@Dax: im Prinzip eine Idee, über die man nachdenken kann, aber scheint mir etwas Workaround-Charakter zu haben ;)

Mir ist dann noch aufgefallen, dass das so, wie ich meinte, ja garnicht gehen kann. Der Angreifer müsste nur ein paar dieser Keys sammeln und könnte die seine Anwendung verwenden lassen... Müsste man noch eine Blacklist oder sowas implementieren.

Aber ich dachte schon über anwendungen gestolpert zu sein, die mit einer blosen Registrierungsnummer freizuschalten waren, ohne irgendwelche anderen Angaben, die müssten doch genau so funktionieren: eine Serial ohne Seed :gruebel:

[negaH]

@Meflin,

SRP = secure Remote Protocoll

Du verwechselst einen sicheren Login-Mechanismus mit einem Registrations-/Freischalt Mechanismus. Was benötigst du nun ?

Registrations-/Freischaltcodes die auf reiner Software basieren sind immer knackbar, das liegt in der Funktionsweise begründet. Davor schützen kann man sich nur sehr bedingt, es läuft auf alle Fälle auf ein Programmierwettbewerb zwischen Dir und dem Hacker hinaus.

Sichere Login Mechanismen gibt es dagegen sehr wohl. Allerdings benötigt man mindestens ein 3 Stufen Protokoll. D.h. nachdem ein Benutzer auf dem Server registriert wurde, kann dieser sich bei jedem Login Vorgang mit Hilfe eines mindestens 3 stufigen Protokolles anmelden. Eine "Stufe" des Protokolles besteht darin das ein Datenpacket vom Client zum Server bzw. vom Server zum Client gesendet werden muß.

SRP ist ein solches Protokoll das mit bis zu 4 Stufen arbeitet, wenn man den Client beim Server und den Server auf Clientseite sicher authentifizieren will. Dieses Protokoll ist annerkannt als sehr sicher eingestuft worden und es ist ein Standard.

Gruß Hagen