Zitat:

Bei der "eigenen Updateprüfung" empfehle ich ein asymetrisches Verschlüsselungs Verfahren (z.B. RSA), da kann man im Programm den PublicKey ruhig mit rein linken.
Nur man selbst kann per PrivateKey die UpdateFiles so verschlüsseln, das es das eigene Programm dann auch dekodieren kann... Das ist dann quasi zugleich eine sehr sichere Authentifizierung der Herkunft, weil auch böse Hacker mit dem PublicKey aus der EXE noch lange keinen PrivateKey zur Erstellung eines modifizierten/bösen Updates haben.

Wie würde ein solcher Mechanismus schematisch gesehen ablaufen?

Wäre das hier nicht auch eine Idee oder ist das zu unsicher?

- Client fragt Updatedateien vom Server an
- ein Script auf dem Server antwortet, dass Updates vorhanden sind oder nicht
- sind welche vorhanden, entschlüsselt das Script, welches auf dem Server liegt, die Dateien die auch auf dem Server liegen und schickt sie dann los

Oder habe ich gerade einen Knoten im Hirn?

Du hast Konten im Hirn

..."sind welche vorhanden, entschlüsselt das Script, welches auf dem Server liegt, die Dateien die auch auf dem Server liegen und schickt sie dann los"..
=> NIEMALS entschlüsselt der Server etwas vor der Übertragung!!!

-> Eventuell verschlüsselt es der Server mit dem Key des Systems und übeträgt die Daten dann so, das NUR der Client sie entschlüsseln kann, würde ich aber NICHT so machen, denn dann lägen SystemKeys auf dem Server... NÖ, man verschlüsselt die ClientUpdates in eigener sicherer Umgebung selbst und lädt die verschlüsselten Dateien auf den Server hoch.
-> Anfragende Clients bekommen so der so stets nur verschlüsselte Dateien per Download, welche auch nur sie selbst entschlüsseln können. Hacker nützt es hier nix bei Server oder Client das Programm, den Speicher oder die Datenübertragung zu analysieren/manipulieren.
->eine "Verschlüsselung" mit dem privaten Schlüssel stellt eine Signatur dar, da jeder(Client), der im Besitz des öffentlichen Schlüssels ist(im Programcode oder gehackt), die Nachricht entschlüsseln kann.
Somit schützt man so nicht direkt die Daten gegen fremdes dekodieren, sondern man beweist dem Empfänger(also dem ClientProgramm), dass man selbst sie herausgegeben hat und es ein echtes Update ist(s. Authentitzität und Integrität).

Das mit dem privaten und öffentlichen Schlüssel kapiere ich nicht.

Wenn der private sowie der öffentliche Schlüssel entschlüsseln können kann man doch auch gleich einen einzigen Schlüssel nehmen.
Am Ende liegt ja trotzdem ein Schlüssel in der Exe.

Bei asymetrischen Verfahren wie RSA gibt es immer ein SchlüsselPaar...
- einen PrivateKEY und einen zugehörigen PublicKEY
- der PublicKey ist öffentlich, DARF UND SOLL also verteilt werden... wie z.B. hier in die EXE einkompiliert werden
- es gilt erstens, mit dem Key welchen man zu Verschlüsselung benutzt hat, kann man die Daten nicht mehr dekodieren (=> ASYMETRISCHES VERFAHREN)
- es gilt zweitens: was mit dem PublicKEY "verschlüsselt" wird, kann nur mit dem "PrivateKEY" entschlüsselt werden
- es gilt dritens: was mit dem PrivateKEY "verschlüsselt" wird, kann man mit dem "PublicKEY" dekodieren und so die Herkunft prüfen, denn nur der Besitzer des PrivateKEY konnte das so erstellen... deshalb nennt sich dieser Weg auch "signieren" und nicht verschlüsseln


Der Trick an RSA ist ja, das man im unsicherem Gebiet, also im ClientBereich oder bei der Übertragung (Server,INET,..) NIEMALS den PrivateKey herausgeben muss und trotzdem per PublicKey sowohl sichere Verschlüsselung aus auch sichere Herkunftsprüfung(im Sinne von Identifikation und Authentifizierung) möglich ist.

Die Besonderheiten Asym. Cryptoverfahren und die sich daraus ergebende jeweils sinnvolle Anwendung der Keys bzw. Methoden zum PrivatKeyManagement sprengen den Rahmen dieses Threads, hier geht es um eine sinnvoll Absicherung von Updates, und da bietet es sich an NICHTS mit geheimen Schlüsseln oder Passwörtern im Clientprogramm zu machen. Genau da ist der PublicKey der Ideale KEY.
So kann sogar wenn der Client zum Server damit echt verschlüsselte Daten schicken, die dann im Server undekodierbar lagern, bis man sie selbst von dort abholt und in eigener sicherer Umgebung dann mit dem PrivateKey dekodiert... so gibt es nie Datenschutzprobleme auf dem Server, denn dort liegen stets nur wertlose verschlüsselte Binärdateien und keinerlei Keys.

Also kurz gefasst:
Dateien auf dem Server mit dem privateKey kodieren und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann?

Wo bekommt man irgendwas mit RSA denn her? DEC scheint ja keine zwei Keys zu unterstützen http://www.delphipraxis.net/75286-rs...b-und-wie.html
Ich hätte hier zwar was, aber das ist glaube ich nur für Strings http://delphiforfun.org/programs/Mat...SA_KeyDemo.htm

..."Dateien auf dem Server mit dem privateKey kodiert speichern und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann"...
=> ja genau so



http://tmssoftware.com/site/tmscrypto.asp

sorry, auch bei sowas ist mir die Suche nach Freewarevarianten zu lässtig, wenn es für unter 100Eur was gibt was gepflegt wird und gut mit Support noch gut dokumentiert ist

Zu teuer Außerdem halte ich von TMS nix.

Was ist denn davon zu halten? https://github.com/TurboPack/LockBox3

RSA steht bei LockBox3 mit dabei... und genau da ist jetzt der Unterschied... bei an TMS schreibste denen was du vor hast und die antworten dir mit welchen ihrer Komponenten es wie geht

Jedem das seine, ich finde DevArt und TMS haben angemessene Preise und überleben so trotz der Freewarealternativen ja auch.
Und TMS+UniDAC machen günstiger für DB und Cloud aus einem Delphi-Pro mehr, wie einem ein Delphi-Ent für teuer Geld bietet, sogesehen ist TMS da sogar "billig", zumal Source und 2Jahre VollSupport immer dabei

Ich habe nix gegen Freeware und Leute die diese machen oder die es nutzen, nur die Suche nach XY nervt im Delphibereich, weil es im INet dazu kaum eine breite offene Sourcebasis gibt.
Da stehe ich dann dazu, das ich privat bei 100€ max. 5h meiner Zeit investieren würde, denn 20€/h ist mir meine Freizeit wert. Geschäftlich würde ich bei 100€ Kosten die Grenze schon bei nur 3h setzen.

Zitat von mensch72:

..."Dateien auf dem Server mit dem privateKey kodiert speichern und den publicKey in die Exe aufnehmen, damit diese die runtergeladenen Dateien dekodieren kann"...
=> ja genau so

Sicher? Gerade hast du es andersherum gesagt und nur andersherum kenne ich es auch. Der private Schlüssel kann entschlüsseln und der public Key verschlüsseln. Also irgendwie macht das gerade keinen Sinn. Oder habe ich jetzt einen Knoten im Hirn?

Knoten im Hirn. Wenn jemand was an dich schickt nimmt er den Public Key. Das kannst nur du mit deinem Private Key entschlüsseln und niemand sonst.

Verschickst du, nimmst du logischerweise den Private Key. Das kann der Empfänger mit deinem Public Key entschlüsseln.