Verschlüsselung von Delphi zu SPS

[gammatester]

Zitat von 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)

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]

Zitat von gammatester:

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 von Friday:

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 von Assarbad:

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 von Friday:

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 von Assarbad:

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 von Assarbad:

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 von Friday:

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 von Friday:

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 von Friday:

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 ... "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 von Friday:

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 von Assarbad:

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 von Assarbad:

(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