Hi, ich habe ein Programm welches auf einen Server verbindet und sich dort Authentifiziert.

Bisher läuft das ganze so:
Zum Server: HardwareID: abcdefgh-12345678
Vom Server: Code ok!

Die Hardware ID kann auch eine Seriennummer oder sonstwas sein.
Allerdings kann ein Angreifer das System offensichtlich sehr einfach austricksen,
indem man dem Programm immer den OPCode "Code ok!" per Socket zurückgibt.
Bzw. einfach allen Traffic des Programms aufnehmen, zum Cracken dann abspielen. :(

Ich suche also eine minimalistische Möglichkeit mein Authentifizierungsverfahren
zu verbessern bzw meinen Traffic zu verschlüsseln.

Welche relativ simplen aber dennoch sicheren Header/Librarys würdet ihr empfehlen?

Noch einfacher: Solange du einfach nur an einer Stelle im Programm einen Aufruf der Form:
Quellcode:if (!get_authorization_from_server()) { ... Fehlermeldung ... }
stehen hast, kann jeder halbwegs Interessierte einfach auf Binärcodeebene den Test komplett durch NOPs ersetzen. Erst wenn du dazu bereit bist, dich dagegen zu schützen, wird es sinnvoll über Verschlüsselung des Netzwerktraffics nachzudenken.

Grundsätzlich musst du dir erstmal klarmachen, dass solche Maßnahmen einfach nie zu 100% dicht sein können. Das geht nicht. Wenn du das eingesehen hast kannst du dir dann überlegen, wie viel Energie du hineinstecken willst. Je mehr Energie du in Sicherungsmechanismen steckst, desto mehr Energie wird ein Cracker benötigen, sofern deine Maßnahmen auch qualitativ gut ist. An dem Beispiel oben siehst du z.B. dass eine Maßnahme, die nur durch Verschlüsselung "geschützt" ist, de facto eigentlich ungeschützt ist.

Ich weiß nun nicht, was das für Software ist, an der du bastelst. Mit hoher Wahrscheinlichkeit würde ich aber davon abraten, zu viel Energie in die Geschichte hineinzustecken. Den Aufwand, den du in einen sichereren Schutz stecken müsstest, solltest du stattdessen in die Verbesserung deiner Software stecken. Ein primitiver Check hilft vollkommen, um ehrliche Kunden ehrlich zu halten und du solltest eher Energie rein stecken, ehrliche Kunden zu gewinnen und bei der Stange zu halten.

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ich stimme dir in allen Punkten zu Perfect!
Auch bin ich mir vollkommen im klaren darüber das man per Disassembler auch jede menge ungewollten Quatsch mit meinem Programm machen kann.
Dagegen gehe ich bereits mit mehreren wiederholten Abfragen, VMProtect und
einigen eigenen Anti-Debugging tricks vor.

Das eine Sicherung nie 100% sicher ist mir auch klar.

Also, Vorschläge wie ich meine Verbindung Server<>Client
gegen "Traffic aufnehmen & abspielen" / WPE einigermaßen schützen kann ? :)

Alles klar. Also von der Perspektive ausgehend, dass dein Client nicht manipuliert wird sondern nur der Netzwerktraffic zwischen Client und Server:

Du kannst dem Server ein kryptographisch verifizierbares Zertifikat geben. Der öffentliche Teil dieses Zertifikats müsste der Client dann fest gespeichert haben, und beim Verbinden eben prüfen, ob (a) das Zertifikat des Servers mit dem gespeicherten Zertifikat übereinstimmt und ob (b) der Server sich erfolgreich mit dem Zertifikat identifizieren kann (das ist ein kryptographischer Test mit dem Server beweist, dass er den privaten Teil des zugehörigen asymmetrischen Schlüssels kennt).

Das sind alles Funktionen, die meines Wissens von SSL abgedeckt werden. Ein Experte in der Implementation davon bin ich aber nicht. An deiner Stelle würde ich versuchen, mich in OpenSSL einzuarbeiten - ich habe zwar ziemliche Horrorgeschichten über die Unverständlichkeit der API gehört, aber es ist nunmal die De facto-Standardimplementierung, die frei verfügbar und ziemlich genauer Prüfung unterworfen ist, d.h. ich würde diese Route wählen, wenn ich in deiner Position wäre.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Und SSL, und damit genau das was du beschrieben hast, basiert auf RSA. Das wäre der Teil, den du zu implementieren hast ;)
Ist selbst unter Wikipedia so gut beschrieben dass du damit keine Probleme haben solltest. ( http://de.wikipedia.org/wiki/RSA-Kryptosystem )

http://www.di-mgt.com.au/rsa_alg.html
Hier gibts unten auf der Seite sogar Implementierungen für VB. Für andere IDEs kannst du den Code ja einfach anpassen.

Music Artist / 2D Artist / Mapper

RSA selbst zu implementieren ist eine blöde Idee, zumindest wenn man es mit der Sicherheit ernst meint. RSA, so wie es im Lehrbuch meist steht, ist nämlich nicht sicher. Sicher wird es erst, wenn man eine ganze Reihe zusätzlicher Probleme berücksichtigt. Das wird zwar auf der Seite, die du verlinkt hast, auch erwähnt, aber schon Kleinigkeiten, die man leicht übersieht, führen bei kryptographischen Protokollen zu deutlichen Schwächen.

Klar, wenn du dich Interesse halber mit Kryptographie beschäftigen willst, dann ist es eine nette Übung, RSA selber zu implementieren. Aber wenn du RSA verwenden willst, ist echt davon abzuraten. Dann sollte man eine existierende Bibliothek verwenden, bei der das Bugfixen schon gemacht wurde.

Abgesehen davon basiert SSL bei weitem nicht nur auf RSA. RSA wird höchstens beim Handshake verwendet um den Schlüssel für eine symmetrische Block Cipher auszutauschen.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

was spricht gegen nen signierten hash von paar hardware eigenschaften?, kann man genausoleicht rauspatchen, aber der kram braucht keine internetverbindung

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.

Zitat:

default postete
was spricht gegen nen signierten hash von paar hardware eigenschaften?, kann man genausoleicht rauspatchen, aber der kram braucht keine internetverbindung

Soweit so gut.
Allerdings nutze ich einen "selbstgemurksten" Verschlüsselungsalgo der eventuell (mit sicherheit) relativ leicht angreifbar ist.
Dazu kommt noch dass das ganze nicht automatisiert verläuft.

SSL ist irgenwie nicht gerade einfach.
Noch jemand Dinge auf die ich achten sollte / Lücken in meinem System / Tipps, wenn ich die derzeitige Lösung auf Sockets übertrage?

Da hast du default wohl falsch verstanden. Er hat ein System vorgeschlagen, bei dem überhaupt keine Netzwerkverbindung notwendig ist.

Ich stimme ihm da auch grundsätzlich zu. Ich weiß ja nicht, woran du genau arbeitest, aber ich wette, dass du da gerade viel Zeit und Energie in etwas hineinsteckst, womit du höchstens ehrliche Menschen ärgern wirst, effektiv aber nichts gegen unehrliche Menschen erreichen kannst. Mit anderen Worten, du produzierst eine Lose-Lose-Situation.

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Zitat:

Felheart postete
SSL ist irgenwie nicht gerade einfach.

Zitat:

Felheart postete
Noch jemand Dinge auf die ich achten sollte / Lücken in meinem System / Tipps, wenn ich die derzeitige Lösung auf Sockets übertrage?

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.

@Perfect:
Hmm, wenn ich das jetzige System auf Sockets übertrage ändere ich ja eigentlich nur WIE die Authentifizierungsdaten ausgetauscht werden;
was bei einer Lösung über Sockets (also komplett ohne "Der Nutzer muss einen Serial eingeben) eigentlich Benutzerfreundlicher sein sollte.

Es sei denn du meinst das ich "vorregistrierte" Versionen verteile, dann handelt es sich um ein Missverständnis. Also eine Vollversion die per HardwareID usw. an einen Computer gebunden ist.

Hier gestaltet sich dann aber eine Begrenzung der Nutzzeit auf eine gewisse Zeitspanne recht aufwändig. (Jedesmal wenn die Zeit um ist eine neue Version installieren ??)

@default:
Nur aus Interesse: Was werde ich wohl eh nicht machen?
Beispiele für unlösbare Probleme ?

Zum Thematik 'Sicherung von Netzwerktraffic':
Ich werde mich trotz allem mal mit SSL auseinandersetzen.
Ich hoffe allerdings das es ähnliche Systeme/Lösungen gibt wie SSL. Ich habe auch schon daran gedacht mehr Vertrauen in die Assembly-Sicherung zu stecken (VMProtect) und allen Netzwerktraffic mit DES oder Konsorten zu verschlüsseln.
(Wobei der Key zum entschlüsseln durch eben die Mutation/Verschlüsselung/Virtualisierung von Code und Strings durch VMProtect gesichert sein sollte).

Vielen lieben Dank für die Antworten bisher!

Wieso schreibst du jetzt eigentlich schon zum zweiten Mal "auf Sockets uebertragen"? Ueber welchen Mechanismus kommunizieren denn bei dir Client und Server im Moment miteinander?

Zitat:

Wobei der Key zum entschlüsseln durch eben die Mutation/Verschlüsselung/Virtualisierung von Code und Strings durch VMProtect gesichert sein sollte

Prefect und default haben eigentlich schon alles gesagt, was es zu sagen gibt.
Mach es nicht und wenn es doch wirklich unbedingt ohne Ausweg sein muss dann nimm SSL/TLS. Wenn dir die API von OpenSSL nicht zusagt kannst du ja mal bei GnuTLS vorbeischauen.
edit: Und dann mach dir vor allem Gedanken was dein Client machen soll wenn die Verbindung zum Server mal nicht moeglich ist, weil bspw. euer RZ gerade DOS'ed wird oder bei eurem Kunden vor der Tuer die Telefonleitungen angebaggert wurden.

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Ich würd mal gerne wissen um was für eine Perle es sich hier handelt, dass der Kopierschutz so komplex sein darf.

Für die client/server Geschichte:
- der Server muss sich gegenüber dem Client eindeutig authentifizieren - SSL Zertifikate machen das preiswert, aber du brauchst idealerweise ein Zertifikat signiert von einer echten CA, das kost Geld und ist Aufwand
- der ganze Kram verlangt, dass der Nutzer immer Internet hat,
- und funktioniert nur solange dein "Lizenzserver" auch läuft

Ich hab bisher nicht den Eindruck gewonnen, dass du überhaupt ne Grundlegende Idee von SSL hast.
GnuTLS ist btw keine alternative zu OpenSSL, die behaupten das nur.

Wenn dir der nen Kopierschutz so wichtig ist, hashe paar Hardware Eigenschaften, Festplatten Seriennummer, Netzwerkinterface MAC, und Lizenzlaufzeit und *signiere* das.
Beim Startup lässt du dann checken, ob das signierte Lizenzfile korrekt mit dem public key von *dir* signiert ist, ob die Lizenz noch gültig ist, und fertig.
Vorteil, braucht kein Internet.

Am Ende sind es eh nur 2 Byte die gesetzt werden möchten, damit das auch ohne Lizenz geht, aber ein offline Lizenzverfahren ist halt weniger Hass für den Nutzer, daher eher weniger Lose-Lose.
Im Endeffekt bestrafst du mit deinem Ranz ja eh nur Nutzer die die Software kaufen.

Du musst Deine Bandbreite verbreitern, damit du breiter wirst von der Bandbreite her und ein breiteres Publikum ansprechen kannst.