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