Wie Java-Datei selbst signieren?

3 Antworten

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.

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.

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.

0
@erfddf33232

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.

0
@erfddf33232

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.

0
@Franky12345678

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.

0
@erfddf33232

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.

0
@Franky12345678

Hä? Ich möchte es ausprobieren, zusätzlich zu HTTPS. Und ich möchte dabei keinen neuen Standard erfinden, sondern z. B. RSA.

0

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.

0

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.

0

Lieber nicht^^.

Dann popelt sich der Hacker sich den Key aus einem Client raus, packt ihn auf seinen Server und klemmt sich zwischen :-D.

1

Was möchtest Du wissen?