Wie Java-Datei selbst signieren?
Ich habe eine Anwendung in Java geschrieben, der ich einen Auto-Updater hinzufügen möchte. Der Auto-Updater fragt zunächst über HTTP ab, ob eine neue Version verfügbar ist. Wenn das der Fall ist, wird die neue Datei heruntergeladen und dann wird die alte mit der neuen überschrieben. Soweit funktioniert auch alles. Um den Prozess sicherer zu machen, soll die Datei nach dem Download überprüft werden, dass nur eine von mir zertifizierte Datei akzeptiert wird. Das schützt auch vor unvollständigen oder beschädigten Dateien.
Wir kann ich das mit Java signieren und die Signatur überprüfen? Das Zertifikat kann auch von mir selber erstellt sein, der Public-Key gehardcoded.
3 Antworten
Signatur: Verschlüsseln und Entschlüsseln mit ein und demselben Schlüssel (Symmetrische Verschlüsselung)
Auf beschädigte Dateien überprüfen: Checksumme
Bei einer symmetrischen Verschlüsselung müsste der Schlüssel irgendwo im Klartext lesbar sein, was nicht sein soll.
Die Datei soll eine Signatur haben, die aus dem Private Key und der Checksumme generiert wurde und mit der Checksumme und dem Public Key überprüfbar ist.
Lieber nicht^^.
Dann popelt sich der Hacker sich den Key aus einem Client raus, packt ihn auf seinen Server und klemmt sich zwischen :-D.
Eine einfache Prüfsumme und Download per HTTPS (vielleicht selbstsigniertes mit in der App hinterlegtem Zertifikat) müsste doch reichen?
Was willst du da "sicherer" machen?
Wenn die Datei manipuliert wird, stimmt die Prüfsumme nicht mehr. Das hat sich seit Jahren bewährt, um manipulierte Dateien zu erkennen.
Das nützt dir sowieso alles nichts, wenn der böse Angreifer den Client manipuliert und deine Prüfroutinen einfach deaktiviert/verändert und die Update-Download-URL innerhalb der App auf einen "bösen" Download umändert.
Ja, das wäre doch HTTPS. Der "man in the middle" braucht den privaten Schlüssel des tatsächlichen Servers, um sich als ihn authentifizieren zu können. Die Signatur wäre dann nicht korrekt und deine App bricht den Vorgang (hoffentlich) ab.
Da ist sozusagen die von dir gewünschte Funktionalität schon servierfertig "drin". Sogar nicht nur die Signatur, sondern sogar komplett verschlüsselt :-).
Musst halt noch ne Prüfsumme implementieren (ohne Signatur, weil der Kommunikationsweg bereits gesichert ist).
Kannst an der Stelle ein selbstsigniertes Zertifikat benutzen.
Nochwas: Sowas sicherheitskritisches musst du nicht (und solltest du auch nicht) selber als "square wheel" neu implementieren.
Einfach die URL deines API-Zugriffes von "http://...." auf "https://..." ändern und fertig. Ggf. das selbst-signierte Zertifikat einbinden.
Https würde ich sowieso verwenden, mich interessiert aber auch das Prinzip, wie man sowas machen kann. Natürlich würde ich auch einen etablierten Algorithmus verwenden, dann kann man bei der Implementierung selber glaube ich auch nicht mehr so viel falsch machen.
Die Funktionsweise von HTTPS/SSL steht im Internet beschrieben.
Viel Spaß.
Aber produktiv würde ich den Eigenbau nicht einsetzen. Jeder Bug ist eine kritische Sicherheitslücke und ab einer gewissen Menge Codezeilen nicht mehr zu 100% zu verhindern.
Es gab die letzten Jahre genug gefährliche Lücken bei SSL.
Hä? Ich möchte es ausprobieren, zusätzlich zu HTTPS. Und ich möchte dabei keinen neuen Standard erfinden, sondern z. B. RSA.
Eine Signatur macht man mit einer asymmetrischen Verschlüsselung. Es wird mit dem privaten Schlüssel verschlüsselt, kann es dann mit dem öffentlichen Schlüssel entschlüsselt werden, ist die richtige Herkunft sichergestellt. Um Aufwand zu sparen, wird in der Regel nur ein Hashwert signiert.
Java liefert mit der java.security Bibliothek alle Mittel, die man dafür benötigt. Schlüsselpaar generieren, signieren und verifizieren ist da alles schon implementiert. Auch die Verwendung des Hashwertes kann einfach durch die Auswahl des Signaturalgorithmus konfiguriert werden.
Aber wie hier schon erklärt wurde, ist das ziemlich sinnlos, da HTTPS im Prinzip schon das Gleiche macht. Dazu kommen noch andere Vorteile, zum Beispiel muss man keinen Schlüssel mehr in der Anwendung hardcoden und kann diesen dann problemlos öfters wechseln.
Wenn der Client direkt manipuliert wird, kann man natürlich nichts machen. Aber bei einem Man-in-the-Middle-Angriff, der die URL umleitet, würde eine Signatur schon Sinn machen. Es ist ja irgendwie möglich, eine Signatur zu generieren, der auf der Prüfsumme der neuen Datei und dem Private Key aufbaut und mit der Prüfsumme der Datei und dem Public Key überprüft werden kann.