Verschlüsselung von Delphi zu SPS

[Friday]

Hallo,
ich suche einen Verschlüsselungsalgorithmus mit dem ich in einer Dephi Anwendung eine 10-stellige Zahl verschlüssele, sie an eine SPS sende und dort wieder entschlüssele.
Dabei darf es nicht möglich sein den Schlüssel zu berechnen wenn die unverschlüsselte und verschlüsselte Zahl bekannt sind.
Also:
z1: bekannte Zahl
k: unbekannter Schlüssel
x1: bekannter verschlüsselte Zeichenfolge

z2: bekannte Zahl
k: hoffentlich immernoch unbekannter Schlüssel
x2: unbekannte verschlüsselte Zeichenfolge

Anforderung ist also das x2 nicht berechnet werden darf, obwohl z1, x1 und z2 bekannt sind.

Somit sollte RC4 schon mal wegfallen.
RSA ist mit 100 bis 200stelligen Primzahlen auf der SPS nicht durchführbar.
AES? Scheint mir auch nicht einfach auf einer SPS zu implementieren zu sein, außerdem verwendet das ebenfalls wie RC4 S-Boxen, womit ich mir unsicher bin ob die im ersten Fall (z1, x1 bekannt) diese S-Box nicht berechnet werden kann.

Alternative wäre eine eigene leicht zu implementierende Verschlüsselung einzubauen, aber das wird mit Sicherheit keine große Sicherheit bieten.

[gammatester]

Schau Dir mal XTEA an. Ist kompakt und relativ sicher (64-Bit Blöcke). Pascal-Quellcode u.a. hier.

[Assarbad]

Kopierschutz, nehme ich mal an? Klingt arg danach. Ich empfehle dir, laß es. Wenn du mit SPSen arbeitest, ist das in einem Bereich wo rechtliches Vorgehen allgemein effektiver sein sollte (Firmen, zumal in Europa sind da meist vorsichtig).

Hatte mal für eine Firma gearbeitet, die speziell für Glaswerke Vorrichtungen (inklusive Anpassung an die lokalen Gegebenheiten) anbieten, welche die Emissionen und (entsprechend) den Verbrauch senken.

Habe immernoch Kontakt zu denen über nen Freund und mir scheint, daß bei denen die das Knowhow hätten es zu reversen der Wille nicht da wäre (wg. möglicher rechtlicher Schritte), bei den Firmen die da aber keine Skrupel hätten das Knowhow schon fehlt ;)

(Die Firma arbeitet weltweit)

Ansonsten nochmal generell zu Verschlüsselungen. Was du versuchst ist Unsinn und ohnehin nicht machbar. Du kannst es maximal schwerer machen, aber sicher nicht unmöglich sowas zu knacken (und jetzt nur bezogen auf die Verschlüsselung). Wenn hier jemand mit einer Lösung kommt, dann kann es nur Voodoo sein. Der Grund ist daß du nicht gleichzeitig dem Kunden trauen und mißtrauen kannst. Und dabei ist es egal ob symmetrische oder asymmetrische Verschlüsselung zum Einsatz kommt. Da die SPS und der SCADA-Rechner vermutlich beide beim Kunden stehen hat der jeden Zugriff den er braucht. Nehmen wir mal an du benutzt eine PPK-Verschlüsselung bei der SPS und SCADA jeweils den öffentlichen Schlüssel der anderen Seite und ihren eigenen privaten Schlüssel haben. Siehste das Problem? Der Kunde hat Zugriff auf beide privaten Schlüssel (wenn auch vielleicht mit etwas Aufwand).

Die meisten Kopierschutzsysteme (jetzt nicht nur auf die Verschlüsselung bezogen) leiden unter genau diesem Problem. Das ist auch der Grund weshalb die DVD/CD-Schutzmechanismen so ausgefeilt sind. Man versucht immer weiter zu erschweren, übersieht aber das eigentlich unübersehbare: wenn es beim Kunden funktionieren soll, muß der über die Technik (oder den Schlüssel oder oder oder ...) verfügen um es zum Laufen zu bekommen. Und das ist der Knackpunkt.

[Friday]

gammatester: Danke, vom Umfang her genau das was ich wollte, allerdings schwer vorzustellen dass es nicht einfach knackbar sein soll (auf den ersten Blick)

Assarbad: Richtig, dabei handelt es sich um einen Kopierschutz. Um genauer zu sein soll die Delphi Applikation eine Datei einlesen die eine verschlüsselte Zahl enthält die auf jeder SPS einmalig ist. Diese verschlüsselte Zahl soll nun auf die SPS übertragen werden, damit diese sich dann frei schalten kann. Der private Schlüssel steckt also in der kompilierten Software der Delphi-Anwendung und der SPS und ist dem Kunden somit nicht (leicht) zugänglich.

Dass das alles nicht 100%ig sicher ist, ist klar. Einen fähigen Kryptologen oder Hacker wird das wohl nicht aufhalten. Ich möchte bloss nicht direkt zum cracken einladen in dem ich es gar nicht verschlüssele oder so, dass es sehr einfach ist es zu entschlüsseln. Wie du schon sagst geht es nur darum es schwierig-er zu machen.

[gammatester]

Zitat:

Zitat von Friday (Beitrag 1064764)

gammatester: Danke, vom Umfang her genau das was ich wollte, allerdings schwer vorzustellen dass es nicht einfach knackbar sein soll (auf den ersten Blick)

Knackbar ist via Brute-Force alles. Aber Brute-Force beseite ist XTEA ziemlich sicher, das englische Wiki listet unter References ein paar weitere Analysen. Ich denke, ein korrekt implementiertes XTEA wird in Deinem System das kleinste Sicherheitsrisiko sein. Allerdings wird es wohl nicht ausreichen, einfach eine Zahl zu verschlüsseln. Zumindest ein variabler 64-Bit IV (Initialisierungsvektor) ist erforderlich, sonst kann man ja einfach ein Paar wiederholen.

[Assarbad]

:wall:

Zitat:

Zitat von gammatester (Beitrag 1064769)

Knackbar ist via Brute-Force alles.

Ja, bloß in wievielen Jahren. Der Unterschied ist aber, daß durch den Zugriff des Kunden auf die SPS und den Rechner mit dem Delphiprogramm der Schlüssel nicht geheim ist. Und nun einfach nochmal Schneier's Buch oder so durchlesen. Alternativ: wenn ich dem Einbrecher den Schlüssel unter die Fußmatte lege ("verstecke") dann hilft auch mein Hochsicherheitsschloß nix (und ich nehme einfach mal an, daß es keine Fenster gibt oder die sicher verrammelt sind).

Aber ist egal, wenn es nur darum geht hier ein Placebo zu haben, dann haste das ja nun (@Friday).

Ich weiß ja nicht welche Sorte SPS das ist und welches Framework verwendet (bzw. Bus, Profibus?) wird, aber mir war so, als hätten viele SPSen auch eine Seriennummer. Kannste die nicht verwenden? Ist mindestens genauso leicht zu hacken, aber definitiv einfacher zu implementieren.

Nachtrag:

Zitat:

Zitat von Friday (Beitrag 1064764)

Einen fähigen Kryptologen oder Hacker wird das wohl nicht aufhalten. Ich möchte bloss nicht direkt zum cracken einladen in dem ich es gar nicht verschlüssele oder so, dass es sehr einfach ist es zu entschlüsseln. Wie du schon sagst geht es nur darum es schwierig-er zu machen.

Ein fähiger Kryptologe kann auch nix gegen die Macht der Mathematik hinter den Algorithmen machen. Ohne privaten Schlüssel ist bei ordentlicher Implementierung nichts auszurichten. Du gibst aber den privaten Schlüssel mit.

[Friday]

Zitat:

Zitat von Assarbad (Beitrag 1064773)

Ohne privaten Schlüssel ist bei ordentlicher Implementierung nichts auszurichten. Du gibst aber den privaten Schlüssel mit.

Da ich die Anwendung mit UPC packe wird das auch nicht direkt aus dem Disassemblierten Code lesbar sein. Klar kommt man an den dekomprimierten Code in dem man den Speicher ausliest und diesen Disassembliert. Aber wie einfach es dann ist den Schlüssel zu finden weiss ich nicht. Aber ich denke das sollte dann sicher genug sein, da der 0815 IT-kundige soweit nicht kommen wird. Die Einladung zum betrügen ist damit zumindest nicht gegeben.

EDIT: Die einzig "sichere" Lösung wäre eine asymetrische Verschlüsselung bei der, der Public Key in der Datei mit der verschlüsselten Nummer drin ist. Aber eine RSA Verfahren wird in der SPS nicht realisierbar sein (bzw wahrscheinlich schon, aber mit erheblichem Aufwand und großen Ressourcen Kosten). Eine so schlanke einfache verschlüsselung wie XTEA wird es asymetrisch wohl nicht geben.

[Luckie]

Exe-Packer sind auch kein Hindernis mehr.

[Assarbad]

Zitat:

Zitat von Friday (Beitrag 1064778)

EDIT: Die einzig "sichere" Lösung wäre eine asymetrische Verschlüsselung bei der, der Public Key in der Datei mit der verschlüsselten Nummer drin ist. Aber eine RSA Verfahren wird in der SPS nicht realisierbar sein (bzw wahrscheinlich schon, aber mit erheblichem Aufwand und großen Ressourcen Kosten). Eine so schlanke einfache verschlüsselung wie XTEA wird es asymetrisch wohl nicht geben.

Eben nicht. Das ist es was ich die ganze Zeit versuche rüberzubringen. Nicht der Typ des Algos oder seine Implementierung sind hier die Schwachstelle, sondern bereits das Einsatzgebiet. Um zu ver- oder entschlüsseln brauchst du in jedem Fall auf einer Seite einen privaten Schlüssel - und das ist der Pferdefuß, denn der Kunde kann den in Erfahrung bringen.

Was ich damit sagen will ist vor allem, daß es völlig irrelevant ist ob du XTEA benutzt oder einfach XOR. Am Ende ist beides gleich knackbar, da du aufgrund dessen wie du es einsetzt in beiden Fällen die Schlüssel mitliefern mußt. Systembedingt, sozusagen.

Nur XOR ist eben noch leichter als XTEA zu implementieren.

[Friday]

Zitat:

Zitat von Assarbad (Beitrag 1064803)

Um zu ver- oder entschlüsseln brauchst du in jedem Fall auf einer Seite einen privaten Schlüssel - und das ist der Pferdefuß, denn der Kunde kann den in Erfahrung bringen.

Nein den privaten Schlüssel hätte der Kunde in diesem Fall nicht. Ich würde bei mir die Zahl mit dem privaten Schlüssel verschlüsseln, die verschlüsselte Zahl inkl. öffentlichem Schlüssel in eine Datei packen, die die Delphi Anwendung beim Kunden liest, beide Informationen an die SPS sendet und diese entschlüsselt mit dem öffentlichen Key die Zahl. Das meinte ich mit meinem "Edit".

Zitat:

Zitat von Assarbad (Beitrag 1064803)

Was ich damit sagen will ist vor allem, daß es völlig irrelevant ist ob du XTEA benutzt oder einfach XOR.

Dabei gehst du davon aus, dass es einfacher ist den Schlüssel und das verwendete Verschlüsselungsverfahren im disassemblierten Code raus zu lesen als eine XOR verschlüsselung zu knacken. Man könnte den Schlüssel ja auch zur Laufzeit aus diversen Konstanten zusammenstellen/berechnen, was es nochmals einiges schwieriger machen sollte den Code zu lesen. Wobei es im Grunde wie im oberen Beispiel gar nicht zwingend notwendig ist dass die Delphi Anwendung den Aktivierungscode entschlüsselt, sondern kann ihn direkt verschlüsselt an die SPS senden (Natürlich kann auch dieses Kompilat wieder gelesen werden, aber da ist es schon schwieriger ran zu kommen).

[Assarbad]

Zitat:

Zitat von Friday (Beitrag 1064868)

Nein den privaten Schlüssel hätte der Kunde in diesem Fall nicht. Ich würde bei mir die Zahl mit dem privaten Schlüssel verschlüsseln, die verschlüsselte Zahl inkl. öffentlichem Schlüssel in eine Datei packen, die die Delphi Anwendung beim Kunden liest, beide Informationen an die SPS sendet und diese entschlüsselt mit dem öffentlichen Key die Zahl. Das meinte ich mit meinem "Edit".

Klingt nach asymmetrischer Verschlüsselung. Die SPS entschlüsselt also mit privatem Schlüssel und nicht wie du hier behauptest dem öffentlichen Schlüssel die Nachricht. Es wird nur der öffentliche Schlüssel des Empfängers beim Verschlüsseln und der private beim Entschlüsseln benötigt. Erst beim (zusätzlichen) Signieren braucht man die kompletten beiden Schlüsselpaare (den privaten des Senders zum Unterschreiben auf Senderseite und den öffentlichen des Senders zum Überprüfen auf Empfängerseite).

Zitat:

Zitat von Friday (Beitrag 1064868)

Dabei gehst du davon aus, dass es einfacher ist den Schlüssel und das verwendete Verschlüsselungsverfahren im disassemblierten Code raus zu lesen als eine XOR verschlüsselung zu knacken.

Allerdings, denn es gibt Heuristiken dafür.

Zitat:

Zitat von Friday (Beitrag 1064868)

Man könnte den Schlüssel ja auch zur Laufzeit aus diversen Konstanten zusammenstellen/berechnen, was es nochmals einiges schwieriger machen sollte den Code zu lesen.

Naja, mich interessiert als Reverse Engineer was rauskommt, also halte ich mich nicht mit unwichtigen Details auf. Abgesehen davon würden Konstanten die du irgendwie zusammenwürfelst im kompilierten Code im Zweifelsfalls sehr RCE-freundlich optimiert ;)

Ja, ich bin da Pragmatiker. Die meisten Reverser sind das :zwinker: ... "jedes Mittel ist recht". Egal ob aus reiner Neugier (für privat), Gier nach Ruhm (sog. "Sicherheitsforscher") oder ob nun der böse Cracker der dein Programm unfreundlicherweise kostenlos an andere weitergibt.

Zitat:

Zitat von Friday (Beitrag 1064868)

Wobei es im Grunde wie im oberen Beispiel gar nicht zwingend notwendig ist dass die Delphi Anwendung den Aktivierungscode entschlüsselt, sondern kann ihn direkt verschlüsselt an die SPS senden (Natürlich kann auch dieses Kompilat wieder gelesen werden, aber da ist es schon schwieriger ran zu kommen).

In der Tat, einfach durchreichen (ich nehme mal an irgendeine Delphi-Client/Server-Anwendung?) macht sehr viel Sinn. Aber auf die SPS kommt doch der Kunde im Zweifelsfall auch, oder gibt es das Hardwarevorkehrungen? In dem Falle wäre der private Schlüssel in der SPS ja sicher. Immer dran denken ein Reverser wird immer den Weg des geringsten Widerstandes gehen.

[divBy0]

Wenn das eine S7 ist, dann les dir doch einfach per SZL einige Informationen raus (Seriennummer, Firmware, Ausgabestand, evtl. Produktionsdatum, usw). Da gibt es schon ein paar Infos, aber sicher bekommst du das ganze nicht, zumal man das Programm ja einfach aus der SPS zurücklesen kann. Bei der S7 fehlen zwar Kommentare und Symbole aber man wird den Schlüssel finden.

[Friday]

Zitat:

Zitat von Assarbad (Beitrag 1064897)

Die SPS entschlüsselt also mit privatem Schlüssel und nicht wie du hier behauptest dem öffentlichen Schlüssel die Nachricht.

Stimmt, das hab ich verwechselt. Wäre also auch keine bessere Lösung.

Das Zusammenstellen des Schlüssels zur Laufzeit klang schon beim tippen nicht sehr vielversprechend, das wär dann wohl so ungefähr bei der Haustür Tesa-Film vors Schloss kleben und sich sicher fühlen. Aber egal, das Problem ist ja keines wenn ich die verschlüsselte Zahl direkt weiter reiche (weiss gar nicht mehr warum ich die im Delphi Programm überhaupt entschlüsseln wollte).

Zitat:

Zitat von Assarbad (Beitrag 1064897)

(ich nehme mal an irgendeine Delphi-Client/Server-Anwendung?) macht sehr viel Sinn. Aber auf die SPS kommt doch der Kunde im Zweifelsfall auch

Das ist eher eine SPS-Fernsteuerung. Ich weiss nicht wie es bei der S7 ist, aber hierbei handelt es sich um eine Steuerung von Jetter, da liegt nur der kompilierte Code drin. Den kann man mit einem FTP Client zwar downloaden, aber der ftp Zugang ist Passwortgeschützt. Sollte ein cracker dennoch an das Kompilat gelangen und das lesen und verstehen können, dann ist es auch egal, weil dann kann er auch die Sprungadresse der Stelle an der die Aktivierung abgefragt wird einfach ändern, so dass der Schlüssel komplett wertlos wird. Aber das ein Kunde soviel Energie da rein steckt kann ich mir schlecht vorstellen.

Ausser er ist vielleicht auch ein Reverser aus Passion ;)

[Assarbad]

Zitat:

Zitat von Friday (Beitrag 1064907)

Das ist eher eine SPS-Fernsteuerung. Ich weiss nicht wie es bei der S7 ist, aber hierbei handelt es sich um eine Steuerung von Jetter, da liegt nur der kompilierte Code drin.

Keine Ahnung, kenne ich leider nicht. Damals haben wir mit S7 gearbeitet.

Zitat:

Zitat von Friday (Beitrag 1064907)

Den kann man mit einem FTP Client zwar downloaden, aber der ftp Zugang ist Passwortgeschützt.

Kleine Kostprobe meiner Denkweise als Reverser? FTP ist Klartext, also schalte ich meinen Sniffer an und lade nach Eingabe von Paßwort und Benutzernamen bequem das Kompilat runter ;)

... gut gut, dann muß ich auch noch CPU usw. kennen aber im Zweifelsfall habe ich die Software dafür ja schon zur Hand (weil ich ja bspw. zur Firma gehören würde).

Zitat:

Zitat von Friday (Beitrag 1064907)

Sollte ein cracker dennoch an das Kompilat gelangen und das lesen und verstehen können, dann ist es auch egal, weil dann kann er auch die Sprungadresse der Stelle an der die Aktivierung abgefragt wird einfach ändern, so dass der Schlüssel komplett wertlos wird. Aber das ein Kunde soviel Energie da rein steckt kann ich mir schlecht vorstellen.

In der Tat. Ich vermute mal, daß rechtliche Schritte in dem Falle ohnehin besser sind. Ich wollte auch nur klarmachen, daß der Aufwand ggf. umsonst ist, da der "Schutz" den die kompliziertere XTEA-Lösung bspw. im Vergleich zu XOR bietet nicht wirklich größer ist. Also lieber mit dem Produkt überzeugen und ggf. einen Kunden ablehnen wenn einem deren Arbeitsweise nicht geheuer ist.

Viel Erfolg! ;)

[Reinhard Kern]

Zitat:

Zitat von Friday (Beitrag 1064764)

Assarbad: Richtig, dabei handelt es sich um einen Kopierschutz. Um genauer zu sein soll die Delphi Applikation eine Datei einlesen die eine verschlüsselte Zahl enthält die auf jeder SPS einmalig ist. Diese verschlüsselte Zahl soll nun auf die SPS übertragen werden, damit diese sich dann frei schalten kann.

Hallo,

du übersiehst da noch eine Gefahr von einer ganz anderen Seite: wenn das heisst, bei einem beliebigen Fehler am PC (angeblich kommt das vor) läuft eine Maschine nicht mehr nur wegen eines Kopierschutzes, die ansonsten betriebsbereit wäre, bekommst du einen Schadensersatzprozess an den Hals, den du wirtschaftlich nicht überleben wirst. Und das zu Recht.

Da du für die Funktion des Kopierschutzes rechtlich geradestehen musst, wirst du auf nicht absehbare Zeit einen 24h-Service zur sofortigen Behebung entsprechender Probleme einrichten müssen. Der Kopierschutz dient ausschliesslich deinen Interessen, der Kunde muss daher einen dadurch bedingten Ausfall keineswegs als schicksalhaft hinnehmen.

Gruss Reinhard

[Assarbad]

Zitat:

Zitat von Reinhard Kern (Beitrag 1064933)

Der Kopierschutz dient ausschliesslich deinen Interessen, der Kunde muss daher einen dadurch bedingten Ausfall keineswegs als schicksalhaft hinnehmen.

In der Tat ein interessanter Aspekt. Bin mal gespannt auf die Antwort von "Friday" ;)

[Friday]

Zitat:

Zitat von Reinhard Kern (Beitrag 1064933)

wenn das heisst, bei einem beliebigen Fehler am PC (angeblich kommt das vor) läuft eine Maschine nicht mehr nur wegen eines Kopierschutzes, die ansonsten betriebsbereit wäre

Hallo, guter Punkt,
wenn dieser beliebige Fehler eine Verbindung zwischen PC und SPS verhindert, wäre ein Teil der Funktionalität deaktiviert, richtig, aber dieser Teil ist sowieso nur in Verbindung mit dem PC verwendbar (Fernwartung/Fernsteuerung). Die Maschine an sich funktioniert auch ohne Freischaltung. Die Aktivierung soll also nur dazu dienen dass die SPS nicht mit einer Software kommuniziert die keine gültige Lizenzdatei hat. Der Fall dass die Verbindung läuft, aber nur der Kopierschutz auf einmal nicht mehr frei geschalten wird, kann nur an einem (plötzlich) falschen Freischaltcode liegen, was nur passieren könnte wenn die Lizenzdatei korrupiert wird (Virus, Festplattenhardwarefehler, ...). Von daher sehe ich da kein Problem. Dass der Kunde eine Kopie der Lizenzdatei aufbewahren sollte eigentlich selbstverständlich sein, aber kann man ja dennoch in die AGB schreiben.

Zitat:

Zitat von Assarbad (Beitrag 1064933)

Kleine Kostprobe meiner Denkweise als Reverser? FTP ist Klartext, also schalte ich meinen Sniffer an und lade nach Eingabe von Paßwort und Benutzernamen bequem das Kompilat runter

Das hatte ich übrigens nicht ganz verstanden, was hilft dir der Sniffer wenn du mit einem ftp Client vergeblich versuchst auf einen ftp Server zuzugreifen von dem du das Passowrt nicht kennst (und Benutzername auch nicht). Der Server wird nur Antworten, dass die Autorisierung fehl schlug, aber keine Daten übertragen mit denen man auf das Passwort rück schließen könnte.

[divBy0]

Eigentlich suchst du eine Möglichkeit deine Software zu schützen. Das kannst du einfach über die Seriennummer der CPU machen oder du suchst dir was anderes für deine Software (z.B. einen Dongle, usw.).

[Assarbad]

Zitat:

Zitat von divBy0 (Beitrag 1064979)

(z.B. einen Dongle, usw.).

Dongles haben eine dumme Angewohnheit. Die sind Hardware und gehen kaputt, die älteren Modelle (LPT usw.) am liebsten. Wenn man nun bspw. auf die Nutzung einer mehrere tausend Euro teuren Software angewiesen ist, und auch ein Ausfall von einigen Tagen nicht okay ist, der Hersteller sich aber querstellt, muß man sich selber helfen. Das An- und Abstöpseln des Dongles um die Software auch im "Home Office" zu nutzen hilft bei der Haltbarkeit der Hardware auch nur wenig. (Ach ja, bevor hier die Kritiker kommen. Die Nutzung im Home Office war keinesfalls aufgrund der Lizenz oder so ausgeschlossen, sondern eben mit An- und Abstöpseln des Dongles verbunden.)

Habe das dann mal für den "Eigenbedarf" (computertechnisch weitgehend unbedarftes Familienmitglied aus dem engsten Familienkreis) gemacht (vor fünf bis sieben Jahren) und einen Dongle durch Software ersetzt. Die Software läuft heute (nach Umzug) auf einem Rechner der nichtmal einen LPT hat noch immer fröhlich. Zugegeben, der Hersteller hatte dann irgendwann einen USB-Dongle als Ersatz geschickt, aber natürlich nur gegen vorherige Herausgabe des alten LPT-Dongles. Das hätte unter anderen Umständen eine zweitägige Zwangspause bedeutet. :zwinker:

Übrigens war das Knacken nicht deswegen so einfach weil das Prinzip oder die Hardware fehlerhaft ist, sondern weil die meisten Entwickler faul sind und es nicht korrekt implementieren. Wenn ich eben nur einen Wert aus dem Dongle abfrage, ist das leicht knackbar. Aber erleichtert hat es mir auch der Donglehersteller doch auch, weil die Anbindung an den Dongle eben in Software passiert und glücklicherweise über eine DLL lief, statt über statisch gelinkten Code. Im letzteren Fall hätte man vermutlich schon einen Filtertreiber schreiben müssen (was ich zuerst auch gedacht hatte). Es wurde dann nur eine DLL. Ich mußte dazu nicht ein einziges Byte der "geschützten" Software ändern und dennoch ist der Dongle jetzt in Software implementiert und der echte liegt sicher in einem Tresor :stupid:

Zitat:

Zitat von Friday (Beitrag 1064977)

Das hatte ich übrigens nicht ganz verstanden, was hilft dir der Sniffer wenn du mit einem ftp Client vergeblich versuchst auf einen ftp Server zuzugreifen von dem du das Passowrt nicht kennst (und Benutzername auch nicht). Der Server wird nur Antworten, dass die Autorisierung fehl schlug, aber keine Daten übertragen mit denen man auf das Passwort rück schließen könnte.

Das verstehe ich nun wiederum nicht. Eine Übertragung wird also bspw. bei Wartung oder so nicht benötigt? Dann würde mein Ansatz natürlich fehlschlagen.

[divBy0]

Zitat:

Zitat von Assarbad (Beitrag 1065009)

Zitat:

Zitat von divBy0 (Beitrag 1064979)

(z.B. einen Dongle, usw.).

Dongles haben eine dumme Angewohnheit. Die sind Hardware und gehen kaputt, die älteren Modelle (LPT usw.) am liebsten. Wenn man nun bspw. auf die Nutzung einer mehrere tausend Euro teuren Software angewiesen ist, und auch ein Ausfall von einigen Tagen nicht okay ist, der Hersteller sich aber querstellt, muß man sich selber helfen. Das An- und Abstöpseln des Dongles um die Software auch im "Home Office" zu nutzen hilft bei der Haltbarkeit der Hardware auch nur wenig. (Ach ja, bevor hier die Kritiker kommen. Die Nutzung im Home Office war keinesfalls aufgrund der Lizenz oder so ausgeschlossen, sondern eben mit An- und Abstöpseln des Dongles verbunden.)

Deswegen war es nur ein Vorschlag. Am sinnvollsten wird für den Einsatz die Seriennummer, usw. der SPS sein. Wenn es ja eine Fernwartungssoftware ist, dann müsste eigentlich auch Zugang zum Internet bestehen, man könnte ja vielleicht auch die Seriennummer von Programm und SPS zu einem Server schicken und dort wird es mit der Lizenz geregelt.

Aber 100% Sicherheit gibt es nicht.

[Friday]

Zitat:

Zitat von Assarbad (Beitrag 1065009)

Das verstehe ich nun wiederum nicht. Eine Übertragung wird also bspw. bei Wartung oder so nicht benötigt? Dann würde mein Ansatz natürlich fehlschlagen.

Nein für diese Software war das nicht angedacht. Eine Update-Software evtl. aber auch nur wenn man auf den ftp-Server einen nur-Schreibrecht-Account einrichten kann. Aber auch das ist noch fraglich wegen möglicher Kompatibilitätsprobleme zu weiterer Firmware-Software die in Kommunikation mit der SPS steht.


Da ich die Software nicht einschränken will (beliebig viele Instanzen auf beliebig vielen Computern), sondern nur die Maschinen die die Fernwarten freigeschalten haben, ist die Überprüfung in der SPS der einzige sinnvolle Weg soweit ich sehe. Und den Kunden zu zwingen immer online zu sein will ich auch nicht. Sonst wär ich ja genauso schlimm wie Microsoft ;)

Ja die Seriennummer überprüfe ich ja auch, das ist im Grunde (evtl einige Zusatzinformationen inkl. Salt) die Zahl die es zu verschlüsseln bzw von der SPS entschlüsseln gilt.