Ja. Sie benötigen die JInstaller-Secure-Edition, um die verschlüsselten SJAR-Dateien erstellen zu können. Wählen Sie dazu im JInstaller-Creator den Menüpunkt Datei->"SJAR(s) erzeugen..." aus und selektieren Sie alle JAR-Dateien, die Sie verschlüsseln möchten.

Verwenden Sie dann die Klasse com.componio.jarcryp.SjarClassLoader aus dem Archiv sjarcl.jar, um die Klassen aus den verschlüsselten Archiven zu laden. Lesen Sie dazu bitte auch die Dokumentation zu JarCryp unter ext/jarcryp/doc/manual/index.html in Ihrem JInstaller-Installationsverzeichnis.
Wenn Sie eine Stand-Alone-Applikation verschlüsseln möchten, die Sie über eine Kommandozeile starten, dann geben Sie einfach die Klasse com.componio.jarcryp.SjarClassLoader als System-Class-Loader an. Dies geschieht mit Hilfe der Kommandozeilenoption -Djava.system.class.loader. Sie können dann statt der JAR-Dateien einfach die SJAR-Dateien in Ihren Classpath aufnehmen und Ihre Anwendung sinngemäß folgendermaßen starten:

java -cp sjarcl.jar;xyz.sjar;... -Djava.system.class.loader=com.componio.jarcryp.SjarClassLoader com.ihre.StartKlasse argumente...

Zusätzlich müssen Sie dafür sorgen, dass die native Bibliothek sjarcl gefunden wird (siehe JarCryp-Dokumenation).

Es ist geplant, JInstaller und die Verschlüsselungsroutinen in Zukunft auch für andere Betriebssysteme zur Verfügung zu stellen. Derzeit ist die Unterstützung für Solaris in Arbeit. Einen genauen Termin für weitere Betriebssysteme können wir leider noch nicht angeben.

Ja, Sie können Ihre JAR-Dateien einfach per Kommandozeile in SJAR-Dateien umwandeln, ohne dass Sie dazu JInstaller Creator starten müssen.

Verwenden Sie dazu einfach den Befehl bzw. die Verknüpfung build_sjar in Ihrem JInstaller-Installationsverzeichnis (JInstaller Secure Edition erforderlich):

build_sjar[.lnk] <jar-files...>

Prinzipiell ja, allerdings müssen sowohl die verwendeten SJAR-Dateien als auch die Bibliotheken sjarcl.jar und sjarcl.dll/libsjarcl.so lokal verfügbar sein. In Zukunft wird es auch möglich sein, SJAR-Archive über eine URL zu laden. Derzeit können jedoch nur lokale Dateien geladen werden.

Gehen wie folgt vor, um verschlüsselte Archive in einem Applet zu laden:

1) Kopieren Sie die Dateien sjarcl.jar und sjarcl.dll (bzw. libsjarcl.so) nach [JRE_HOME]/lib/ext/

2) Laden Sie die verschlüsselten Archive in Ihrem Applet über den Aufruf:

    SjarClassLoader cl = SjarClassLoader.getInstance(getClass().getClassLoader(), <my-sjar-files...>);

3) Stellen Sie sicher, dass in der Datei [JRE_HOME]/lib/security/java.policy die benötigten Rechte für das Applet vergeben sind oder verwenden Sie signierte JARs.

JarCryp bietet einen Schutzmechanismus für JAR-Dateien, der verhindern soll, dass der Inhalt der Datei entpackt und durch einfache Dekompilation nutzbar und veränderbar ist. Die native Implementierung verhindert zusätzlich, dass die entschlüsselten Klassendaten auf einfache Weise abgefangen werden können. Bei JarCryp handelt es sich im Wesentlichen um eine in C++ implementierte Bibliothek (derzeit nur für Windows- und Linux-Betriebssysteme), die über das Java Native Interface (JNI) in die jeweilige Java-Virtual-Machine eingebunden wird.

Alle Klassen aus den SJAR-Archiven werden erst zur Laufzeit jeweils einzeln und nur bei Bedarf kurzzeitig im Speicher entschlüsselt und über das JNI an die Java-VM übergeben. Auch Ressourcen wie Bilder und Konfigurationsdateien können über diesen Mechanismus geladen werden.

Die native Bibliothek ruft nicht die defineClass-Methoden des java.lang.ClassLoader auf, so dass die Klassendaten nicht einfach durch Austausch dieser Klasse abgefangen werden können. Die Bibliothek verhindert zusätzlich, dass die entschlüsselten Rohdaten einer Klasse an sogenannte ClassLoadHooks vorhandener “Java programming language agents”, die die JVMPI/JVMTI Schnittstellen verwenden, übergeben werden.

Wir weisen darauf hin, dass es ähnlich wie im Bereich der digitalen Musik naturgemäß auch für Software auf Client-Seite keine hundertprozentige Sicherheit geben kann. Durch geeignete Sicherheitsmechanismen kann man aber erreichen, dass die Hürden für einen Großteil potentieller Angreifer so hoch sind, dass sich ein Angriff entweder nicht lohnt oder technisch nicht durchführbar ist. Mit JarCryp ist die Umgehung der Sicherheitsmechanismen mit einem hohen Aufwand verbunden (wie bspw. Debugging auf Maschinencode-Ebene, Prozessspeicher-Analyse oder der Implementierung bzw. Verwendung einer eigenen modifizierten Java-Virtual-Machine), wodurch der Schutz der Software im Vergleich zur normalen ungeschützten Auslieferung von JAR-Dateien deutlich erhöht ist.

Die Verschlüsselung der SJAR-Dateien selbst basiert zwar auf einem gängigen symmetrischen Verschlüsselungsalgorithmus, allerdings spielt dies im Prinzip eine untergeordnete Rolle, da die Sicherheit des Gesamtsystems sicherlich nicht, wie oben beschrieben, im kryptografischen Sinne zu bewerten ist und bewertet werden sollte.

Nein, aber es geht die Möglichkeit verloren, die geschützten Programme auf beliebigen VMs auszuführen. In Zukunft wird JarCryp sicherstellen, dass ein geschütztes Programm nur auf verifizierten, nicht-kompromittierten VMs ausgeführt werden kann.