Sensible Daten - Verschlüsselung - Java?

Rajmund

Aktives Mitglied
Thread Starter
Dabei seit
15.04.2006
Beiträge
575
Reaktionspunkte
75
Hallo,

grundsätzlich besteht ja die Möglichkeit, daß ein Java-Programm dekompiliert werden kann. Wenn auch der erzeugte Quelltext schwer lesbar ist, ein hinreichend motivierter Tüftler findet das was er sucht: Kryptografieralgorithmen, Schlüssel.
Wie seht ihr das? Sollte man Anwendungen, die Daten ver- und entschlüsseln müssen, lieber nicht in Java schreiben? Oder meint ihr, daß die Gefahr, daß Leute sensible Bereich im Code isolieren können, bei Java auch nicht größer ist als bei nativen Programmen?
 
Eine Verschlüsselung, die darauf beruht, dass der Algorithmus geheim ist, ist nie eine gute Idee.

Bei den modernen Kryptographieverfahren ist es ja so, dass der Algorithmus bekannt und lediglich die "Schlüssel" geheim sind. Daher wüsste ich momentan nichts, was gegen Java spricht. Außer vielleicht die Performance. ;)
 
Aber was ist nun, wenn das Programm den Schlüssel zum Entschlüsseln nicht von einem Benutzer entgegennehmen kann, sondern selbst schon "wissen" muß? Dann liegt der Schlüssel zwangsläufig irgendwo im Programmcode bzw. wird er sicher nicht als einfache Zeichenkette dort liegen, sondern man wird sich überlegen, wie man den Schlüssel über den Code am geschicktesten verteilt. Damit sich das Programm den Schlüssel wieder "zusammenbauen" kann, muß es eine Funktion haben, die das erledigt. Hat ein Hacker die gefunden, hat er auch den Schlüssel. Die Frage ist, ob ein Java-Programmcode ihm das leichter macht als z.B. C++.
 
Kannst Du uns mal verraten was Du genau machen willst? Ein Sicherheitsmechanismus der durch Anschauen des Quellcodes ausgehebelt werden kann zeugt von einem gravierenden Designfehler des Programms.
 
was genau verschlüsselt den dein Programm?

Für (direkte) Kommunikation gibt es Algorithmen, die ohne einen vorher festgelegten Schlüssel auskommen, ähnliches auch bei manch anderen Bereichen. Bei temporären Dateien z.B. ist es relativ einfach, sichere
Verschlüsselungen zu integrieren. Auch für das einfache Speichern von Passwort-Safes bietet Java ein (Teil-) API.

Wenn du viel Zeit hast und ein wenig Aufwand nicht scheust, kannst du dir ja
einen eigenen Classloader implementieren, der Klassen lädt, die du vorher verschlüsselt hast.

Generell hat Java das bessere ( und leichtere) Sicherheitskonzept an,
ist aber leichter zu dekompilieren als C(++).
 
Java-Codeobfuskation und ein CustomClassLoader bringen es auch nicht wirklich.

Für C gibt es eine ganze Reihe Tricks und Tools, um das Disassemblieren deutlich schwieriger zu machen aber die Plattformunabhängigkeit bleibt dann auf der Strecke und selbst die "Großen" schaffen keine unknackbaren Binaries.

Eins ist klar: Wenn der Schlüssel bei symmetrischer Verschlüsselung zusammen mit dem Tool kommt, dann extrahiert ihn irgendwer. Siehe AACS ;)
 
Zuletzt bearbeitet:
Zapfenzieher schrieb:
Kannst Du uns mal verraten was Du genau machen willst?
Zum einen interessiert mich das Problem ganz allgemein, zum anderen soll das Programm, an dem ich gerade arbeite, verschiedene verschlüsselte Konfigurationsdateien entgegennehmen. Wichtig dabei ist weniger, ob jemand den Inhalt dieser Dateien lesen kann oder nicht. Entscheidend soll sein, daß kein Unbefugter Konfigurationsdateien für das Programm erstellen kann. Der Inhalt ist nicht sehr kompliziert; würde ich einfach ein nicht offenes Format entwerfen, könnte man es dennoch analysieren und selbst eine solche Datei schreiben. Und das darf nicht sein.

Meine Überlegungen gingen schon in die Richtung, RSA zu verwenden und dabei aber den öffentlichen Schlüssel eben nicht öffentlich zu machen, so daß eben nur befugte Leute verschlüsseln können. Der private Schlüssel wäre im Programm abgelegt. Es könnte also entschlüsseln. Würde jemand diesen Schlüssel im Bytecode finden, würde er ihm nichts nützen, da er zwar entschlüsseln kann, aber nicht verschlüsseln. So vermute ich das zumindest. Oder gibt es Möglichkeiten, mit dem privaten Schlüssel zu verschlüsseln oder den öffentlichen Schlüssel zu generieren?
Zapfenzieher schrieb:
Ein Sicherheitsmechanismus der durch Anschauen des Quellcodes ausgehebelt werden kann zeugt von einem gravierenden Designfehler des Programms.
Um den Quellcode geht es nicht. Der wird ja nicht verteilt.
 
Zuletzt bearbeitet:
LOL, sry. Aber wenn du danach gehst kann dein Programm IMMER gehackt werden. Wenn du was unknackbares entwickelt hast, dann melde es zum Patent an, dann bist du Reich. ;)

Verstreue deinen Schlüssel quer durch das Programm und setze ihn kompliziert zusammen und verschlüssle diesen noch mal. Das sollte reichen. ;)
 
Gegen das Rauspatchen der Signaturprüfung ist er in der Tat machtlos, nur ist die Frage, ob sich das bei seinem Java-Tool so in der Praxis machen lässt und ob da Obfuskieren nicht doch was bringt.
 
Zuletzt bearbeitet:
Ein Obfuscator, der nur Dinge wie z.B. das Ersetzen von Variablennamen erledigt, ist kein guter Schutz,
ein Angreifer mit genügend Zeit hat damit keine Probleme.

Eine andere Möglichkeit sind Obfuscator, die illegalen Bytecode in class-Dateien schreiben um Decompiler zu verwirren.
Damit haben aber auch (vor allem ältere) virtuelle Maschinen Probleme.

Am besten wäre es, etwas in der Art zu machen, wie -Nuke- vorgeschlagen hat.
Oder der Benutzer muss ein eigenes Passwort angeben,
dass bei jedem Start abgefragt wird, das ist auch sicher.
 
http://de.wikipedia.org/wiki/Digitale_Signatur wie schon der Kay gesagt hat. Da muss man keine Schlüssel verstreuen oder ähnliche hässliche Sachen machen. Irgendwann wird das Programm allerdings das File auslesen und verarbeiten müssen und dort kann man einhaken, egal ob das File am Anfang verschlüsselt war oder nicht.

Im Allgemeinen kann man aus dem privaten Schlüssel den öffentlichen generieren.
 
Zurück
Oben Unten