AT500519A2 - Verfahren zur ausführung interpretierbarer computerprogramme - Google Patents

Description

·· · I • · · · · · • · · · · „ · · · ·· ·· ··· P9120

Verfahren zur Ausführung INTERPREΉERBARER Comfuterprogramme

Die Erfindung betrifft ein Verfahren zum Ausführen einer Programmdatei, in der interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist, bei welchem von einem Lademodul interpretierbarer Objektcode in einen RAM-Speicher geladen wird und dieser sodann von einem Ausführmodul interpretiert wird.

Gleichermaßen bezieht sich die Erfindung auf eine Rechnereinrichtung zum Ausführen von Programmdateien, in denen interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist, mit einem Interpretersystem, das ein Lademodul zum Laden von interpretierbarem Objektcode in einen RAM-Speicher und ein Ausführmodul zum Interpretieren von im RAM-Speicher befindlichen Objektcode aufweist.

Ebenso bezieht sich die Erfindung auf einen Datenträger, auf welchem zumindest eine Programmdatei abgelegt ist, in der interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist.

Viele moderne Programmiersprachen - z.B. Java - sehen vor, dass der Quelltext von Programmen nicht in Maschinencode kompiliert wird, der direkt vom Prozessor eines Computersystems ausführbar ist, sondern in interpretierbaren Objektcode, sogenannten „Metacode", konvertiert wird. Dieser Metacode ist ein Plattform-unabhängiger Objektcode gemäß einer maschinennahen Metasprache, die auf einem Computer interpretativ ausgeführt wird. Das hierbei verwendete, für die jeweilige Plattform spezifische Interpreter-Programm wird auch als „virtueller Prozessor" (Virtual Machine) bezeichnet. Diese Bezeichnung leitet sich daraus ab, dass der virtuelle Prozessor sich in Bezug auf den Metacode wie ein plattformunabhängiger Prozessor verhält; er übersetzt die im Metacode enthaltenen Anweisungen in Maschinenanweisungen, die vom Prozessor des Computersystems ausgeführt werden. Im Beispiel eines Programms, dessen Quelltext in Java erstellt ist, wird dieses in einen als „Metacode" bezeichneten Interpreter-Code vorkompiliert, der unabhängig von dem Computersystem ist, auf dem er ausgeführt werden soll. Für die Ausführung von Byte-Code-Programmen wird als virtueller Prozessor eine 'Java Virtual Machine' verwendet, die wie gesagt für die verwendete Plattform spezifisch ist.

Die Verwendung von Metacode hat unter Anderem den Vorteil, dass der Metacode zwar kompakter und schneller ausführbar als der ursprüngliche Quellcode ist - wenn für den betreffenden Quellcode überhaupt Interpreter-Systeme bestehen -, jedoch infolge seiner Unabhängigkeit von dem Computersystem, auf dem er ausgeführt werden soll, problemlos P9120 ··· · -2- zwischen verschiedenen Plattformen portierbar ist. Nachteilig jedoch ist, dass Metacode mit geeigneten Programmen wieder in Quelltext rück-übersetzt werden kann. Solche „Dekompi-ler" sind leicht verfügbar und beispielsweise für Java wohlbekannt.

Naturgemäß besteht bei Programmen, die in Quellform vorliegen, die Gefahr von Eingriffen in den Code, die für den Hersteller oder Vertreiber der Programme unerwünscht sind. Gleiches gilt für einen Objektcode, welcher - z.B. durch Dekompilation - in Quellform konvertiert werden kann. Solche unerwünschte Eingriffe sind insbesondere die Entnahme von Code-Segmenten (z.B. durch Kopieren) für die Verwendung in anderen Programmen des Anwenders oder die Manipulation des Codes, z.B. zum Ausschalten von (vom Anwender) ungewollten Code-Abschnitten, z.B. zur Durchführung einer Anwender-Autorisierung, Vergebührung oder Ähnlichem. Insbesondere für lizenzierte und/oder kopiergeschützte Programme besteht die Gefahr, dass ein im Code vorgesehener Mechanismus zur Überprüfung der Lizenz- oder Kopierinformation auskommentiert bzw. auf andere geeignete Weise unwirksam gemacht wird.

Eine bekannte Lösung, um solche Eingriffe zu verhindern, besteht darin, anstelle eines interpretierbaren Objektcodes das Programm in direkt ausführbaren Maschinencode zu übertragen und diese kompilierten Programme an die Anwender zu verteilen. Diese Lösung führt zu verringerter Kompatibilität der Ausführung auf Systemen mit verschiedenen Konfigurationen und unterläuft den eigentlichen Zweck des Metacodes, nämlich auf einer Vielzahl von Betriebssystemen ausführbar zu sein; vielmehr muss bei dieser Lösung der Hersteller dafür sorgen, dass er einen auf dem Anwender-System lauffähigen Programmcode ausliefert. Dies führt besonders bei der Entwicklung von Programmen zu erheblich erhöhtem Aufwand. In manchen Fällen kann dies auch gänzlich immöglich sein, beispielsweise wenn Anwender-seitig aus Sicherheitsgründen nur Programme mit interpretativem Code zur Ausführung zugelassen sind.

Eine anderer Lösungsansatz setzt sogenannte „Konfusionskompiler" ein, die in den Skripts die Variablen- und Funktionsnamen verändern, sodass die Funktionalität erschwert durchschaut werden kann. Diese Lösung ist wenig zuverlässig, da bestimmte algorithmische Strukturen - z.B. Lizenzierungsmechanismen - dennoch leicht ausfindig gemacht werden und ausgeschaltet oder sonst modifiziert werden können.

Es ist daher Aufgabe der Erfindung, einen Weg aufzuzeigen, die unerwünschte Manipulation interpretierbarer Objekteode-Programme seitens des Anwenders zu erschweren bzw. gänzlich zu unterbinden. P9120 ··· · -3-

Die Aufgabe wird hinsichtlich eines Verfahrens der eingangs genannten Art dadurch gelöst, dass erfindungsgemäß seitens des Lademoduls zumindest ein Teil des zu ladenden Objektcodes aus in der angebotenen Programmdatei vorliegendem Chiffre-Code gemäß folgenden Schritten gewonnen wird: a) Bestimmen eines Mittels zum Entschlüsseln des Chiffre-Codes unter Verwendung von der Programmdatei zugeordneter Hinweis-Information und b) Berechnen von Objektcode durch Entschlüsseln des Chiffre-Codes unter Verwendung des Entschlüssel-Mittels.

Durch die erfindungsgemäße Lösung gelingt der Schutz von Metacode-Programmen auf effektive Weise. Die Entschlüsselung und die Ausführung des Metacodes erfolgt gemäß der Erfindung nicht in getrennten Schritten, sondern miteinander verknüpft. Dadurch wird dem Anwender der Zugriff auf den entschlüsselten Code unmöglich gemacht oder zumindest wesentlich erschwert.

Um den für die Entschlüsselung verwendeten Schlüssel vor dem Zugriff unberechtigter Benutzer zu schützen, sieht eine bevorzugte Weiterbildung der Erfindung vor, dass als Mittel zum Entschlüsseln ein Programmmodul („Entschlüsselungsmodul") verwendet wird, das vom Lademodul unter Übergabe des zu entschlüsselnden Chiffre-Codes aufgerufen wird, daraus Objektcode entschlüsselt und den so gewonnenen Objektcode an das Lademodul zurückgibt. Da das Entschlüsselungsmodul dem Anwender zur Verfügung steht, sollte es in Maschinensprache (anstelle einer Interpretersprache) oder in vergleichbarer Form erstellt sein, die eine Dekodierung nur unter hohem Aufwand zulässt.

Vorteilhafter Weise werden für verschiedene Programmdateien verschiedene Schlüssel bzw. Entschlüsselungsmodule verwendet, um dem Anwender mangels der Information, welcher Schlüssel und/ oder Entschlüsselung zu welcher Datei gehört, das eigenmächtige Entschlüsseln zu erschweren. In diesem Fall wird in Schritt a) das Mittel zum Entschlüsseln aus einer Anzahl von auf einem dem Lademodul zugeordneten Speichermedium gehaltenen Mitteln zum Entschlüsseln ausgewählt.

Weiters ist es vorteilhaft, wenn vor dem Aufruf des Lademoduls seine Integrität von einem Startermodul geprüft wird, insbesondere durch Berechnung eines Prüfwerts aus dem Lademodul nach einem Hash-Verfahren und Vergleich mit einem vorgegebenen Kontrollwert, und nur im Falle eines positiven Prüfergebnisses das Lademodul aufgerufen wird.

In einer anderen günstigen Ausführungsform der Erfindung wird das Lademodul erst anlässlich der Ausführung aus einer Chiffre-Datei durch ein Startermodul entschlüsselt. P9120 ··· · • · « · ··· • · · · · • · * «· ♦· ··· -4-

Nach der Ausführung kann das entschlüsselte Lademodul wieder gelöscht werden, da es bei Bedarf aus der Chiffre-Datei erzeugt werden kann.

Die Hinweis-Information kann in Schritt a) einer der Programmdatei zugeordneten Konfigurationsdatei und/oder in der Programmdatei enthaltenen Steuerdaten entnommen werden.

Um ein Nebeneinanderbestehen von verschlüsselten und unverschlüsselten Programmen zu ermöglichen, ist es zweckmäßig, wenn vor Schritt a) seitens des Lademoduls geprüft wird, ob in der angebotenen Programmdatei Chiffre-Code vorliegt, und falls dies zutrifft, mit Schritt a) fortgesetzt wird, ansonsten in der Programmdatei enthaltener Objektcode direkt geladen wird.

Das Lademodul und/oder das Startermodul können günstiger Weise in Form eines Computerprogramms realisiert sein, nämlich mit Programmcodemitteln, um das erfindungsgemäße Verfahren durchzuführen, wenn das Programm auf einem Computer ausgeführt wird. Ebenso können sie in einem Computerprogrammprodukt mit Programmcodemitteln realisiert sein, die auf einem computerlesbaren Datenträger gespeichert sind, um das erfindungsgemäße Verfahren durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.

Gleichermaßen wird die gestellte Aufgabe von einer Rechnereinrichtung der eingangs genannten Art gelöst, bei welcher seitens des Lademoduls ein Mittel zum Entschlüsseln von in einer angebotenen Programmdatei vorliegendem Chiffre-Code in Abhängigkeit von der Programmdatei zugeordneter Hinweis-Information vorgesehen ist, und das Lademodul dazu eingerichtet ist, durch die Entschlüsselung gewonnenen Klartext als Objektcode in den RAM-Speicher zu laden.

Die bevorzugten Weiterbildungen der erfindungsgemäßen Rechnereinrichtung und ihre Vorteile entsprechen denen des erfindungsgemäßen Verfahrens.

Ebenso wird die Erfindung mithilfe eines Datenträgers der eingangs genannten Art gelöst, bei welchem die Programmdatei Chiffre-Code aufweist, welcher interpretierbaren Objektcode in verschlüsselter Form enthält, und der Datenträger und/oder die Programmdatei Hinweis-Informationen aufweist, anhand der Mittel zum Entschlüsseln des Chiffre-Codes bestimmbar sind. Hierbei ist es vorteilhaft, wenn die Hinweis-Infonnation als der Programmdatei zugeordnete Konfigurationsdatei und/oder in der Programmdatei enthaltene Steuerdaten realisiert ist. • · · • ··· ··♦ · -5-

Die Erfindung samt weiterer Vorzüge wird im Folgenden anhand eines nicht einschränkenden Ausführungsbeispiels für die Programmiersprache Java unter Verwendung der beigefügten Figur näher erläutert. Die Figur zeigt die Erzeugung und Ausführung verschiedener Java-Programmmodule gemäß der Erfindung.

Das im Folgenden dar gestellte Ausführungsbeispiel betrifft die Ausführung von Programmdateien Ml, C2, C3, die auf Java-Metacode beruhen. Selbstverständlich ist die Erfindung nicht auf Java beschränkt; vielmehr kann jede andere Zielsprache verwendet werden, bei der die Ausführung von interpretierbarem Objektcode durch eine virtuelle Maschine vorgesehen ist.

Anhand der ersten Programmdatei Ml soll zunächst die grundsätzliche Vorgangsweise zur Ausführung von Metacode-Programmen beschreiben werden, auf der die Erfindung beruht.

Die Programmdatei Ml in Form eines Metacode-Programmmoduls liegt typischerweise als sogenannte ".class"-Datei vor, z.B. mit einem Dateinamen der Art "m1 .dass". Das Pro-grammmodul Ml wird z.B. auf einem Datenträger Dl, z.B. eine Diskette oder ein CD-ROM, einem Anwender zur Verfügung gestellt, der über ein Rechnersystem S2 verfügt, auf der eine Plattform zur Ausführung von Metacode-Programmen einschließlich Java-Metacode eingerichtet ist. Eine virtuelle Maschine VM ist in ein Starter-Modul SM eingebettet, das vorzugsweise in einer Kompiler-Programmiersprache geschrieben und zu einem lauffähigen Programm kompiliert ist, z.B. in Form einer Datei "SM. exe". Die zum Erstellen des Starter-Moduls SM verwendete Programmiersprache - im Folgenden als Aufrufsprache bezeichnet - kann z.B. C, C++ od.dgl. sein. Wenn das Starter-Modul SM für ein Programm Ml aufgerufen wird, beispielsweise aufgrund eines Start-Befehles stc des Anwenders der Form "SM m1", generiert das Starter-Modul SM einen Aufruf der virtuellen Maschine VM für das betreffende Programm Ml. Die virtuelle Maschine führt sodann den Metacode des Programmmoduls Ml aus.

Die virtuelle Maschine VM weist nach an sich bekannter Art ein Lademodul LM - im Falle von Java der sogenannte „Klassenlader" ('dass loader') - sowie ein Ausführmodul EX ('execute') auf. Zuerst lädt das Lademodul LM den Metacode ml des Moduls Ml in den ./ RAM-Speicher der Rechnereinrichtung Sl, und zwar ab einer Startadresse al. Die Startadresse al wird an das Ausführmodul EX übergeben, das sodann ab der so erhaltenen Startadresse al den dort befindlichen Metacode ml ausführt.

Das Programmmodul Ml stammt im betrachteten Ausführungsbeispiel von einem Entwickler bzw. von dessen Rechnersystem Sl, das als Plattform zur Software-Entwicklung einge- P9120 « · * · · · • ♦ ··« • · t ·· #· -6-richtet ist. Dem Modul Ml ("m1 .dass") liegt ein Java-Quelltext SCI ("m1. java") zugrunde, der mittels eines sogenannten Java-Kompilers JC in sog. „Metacode" vorkompiliert wurde; dieser ist in Form des Programmmoduls Ml abgespeichert. n-wss I ΰόΡ c ka n-n 2

Das Startermodul SM und die virtuelle Maschine VM sind im Ausführungsbeispiel als gemeinsames Programm, das auf der Plattform S2 des Anwenders ausführbar ist, realisiert. In einer Variante können sie auch als gesonderte Dateien angeboten werden; außerdem ist es grundsätzlich möglich, dass das Startermodul SM und/oder die virtuelle Maschine VM mittels Hardware realisiert sind, z.B. in Form von speziellen Prozessoren. Der Anwender erhält diese Module SM, VM z.B. in einem Programmpaket von dem Entwickler.

Gemäß der Erfindung ist zusätzlich die Verwendung eines Verschlüsselungs- und Entschlüsselungsschrittes unter Verwendung kryptographischer Verfahren vorgesehen. Dies wird im Folgenden anhand eines zweiten Java-Programmes SC2/M2 (Quelltext bzw. Metacode) beschrieben.

Seitens des Programm-Entwicklers wird anschließend an die Vorkompilierung des Quellcodes SC2 das Programmmodul M2 mittels eines Verschlüsselungsmoduls EE ('encryption engine') verschlüsselt. Das Verschlüsselungsmodul verwendet vorzugsweise ein asymmetrisches Codierungsverfahren, wie z.B. RSA, ElGamal, etc unter Verwendung eines geheimen Schlüssels s. Die so erzeugte Chiffre-Datei C2 wird sodann auf einen Datenträger D2 gespeichert und als Programmdatei dem Anwender übergeben. Der Anwender erhält somit lediglich einen verschlüsselten Code C2 als Programmdatei (anstelle eines Klartext-Programms Ml). Der darin verborgene Programmcode kann nur mit dem zum Schlüssel s zugehörenden Gegenschlüssel k entschlüsselt werden.

Der zur Verschlüsselung des Moduls M2 verwendelVSchlüssel s stammt von einem Schlüsselpaar s2, k2, das gemeinsam von einem Schlüsselgenerator KG bekannter Art erzeugt wird. Bei Verwendung eines asymmetrischen Verschlüsselungsverfahrens ist der Gegenschlüssel k2 der öffentliche Schlüssel, der zum privaten (geheimen) Schlüssel s2 gehört.

Der Schlüssel k2 wird seitens des Anwenders bzw. seines Rechnersystems S2 von einem Entschlüsselungsmodul DE2 ('decryption engine') zur Entschlüsselung der Chiffre C2 benötigt. Der Schlüssel k2 wird dem Anwender z.B. auf einem weiteren Datenträger DK übergeben, der darüber hinaus z.B. Lizenzinformationen enthalten kann, die die übergebenen Programme Ml, C2, C3 betrifft. Zur verbesserten Sicherung gegen Missbrauch kann der Schlüssel k2 alternativ in einer Kopie des Entschlüsselungsmoduls DE2 abgelegt werden, die mit dem Datenträger DK ausgeliefert wird. Seitens des Entwickler-Rechners S2 wird der P9120 P9120 ♦ • *

··· *· • · ♦ » ··· -7-

Schlüssel k2 bzw. das Entschlüsselungsmodul DE2 auf einem permanenten Speicher HD2, z.B. einer Festplatte, abgelegt.

Gemäß der Erfindung sieht das Lademodul LM ein Entschlüsselungsmodul DE vor, dessen Aufgabe es ist, aus der Chiffre C2 das zugrunde liegende Programm M2 zu entschlüsseln. Der daraus erhaltene Metacode m2 wird, analog zu dem Metacode ml wie weiter oben dargestellt, im RAM bei einer Startadresse a2 beginnend abgelegt und dort vom Ausführmodul EX ausgeführt. Nach der Ausführung wird der Metacode m2 zweckmäßiger Weise im RAM überschrieben.

Das Lademodul LM entnimmt den Schlüssel k2 von dem permanenten Speicher HD2, bzw. das Entschlüsselungsmodul DE2 mit dem darin kodierten Schlüssel k2 wird als Modul DE vom Lademodul LM aufgerufen. Bevorzugt wird die letztere Alternative, bei der der Schlüssel k2 im Maschinencode des Entschlüsselungsmoduls DE2 verborgen ist und erst im Laufe der Ausführung des Moduls DE2 aus dem Maschinencode entnommen wird. Beispielsweise wird das Modul DE2 an die im Lademodul LM vorgesehen Speicherstelle geladen und dort ausgeführt.

In dem Ausführungsbeispiel ist das erfindungsgemäße Lademodul LM ein entschlüsselnder Klassenlader, dessen Klasse entsprechend Javas objektorientierter Architektur von der Klasse eines bekannten Klassenladers abgeleitet ist. Die abgeleitete Klasse unterscheidet sich von der Basisklasse dadurch, dass ein Entschlüsselungsmodul DE aufgerufen wird, gegebenenfalls nach vorhergehender Auswahl und Laden des geeigneten Schlüssels k2, k3 oder Moduls DE2, DE3. Im Gegensatz zum Lademodul LM sind die Entschlüsselungsmodule DE, DE2, DE3 zweckmäßiger Weise in Maschinencode erstellt; ihr Start erfolgt in Java durch einen sogenannten Ursprungsaufruf ('native call').

Das oben beschriebene Verfahren funktioniert grundsätzlich auch mit einem symmetrischen Verschlüsselungsverfahren; in diesem Fall entfällt die Unterscheidung zwischen den beiden Schlüssel s2 und k2. Der Vorteil der asymmetrischen Verschlüsselung liegt darin, dass ein Benutzer, der in die Kenntnis des Schlüssels k2 gelangt, zwar das Modul M2 entschlüsseln kann, eine geänderte Version des Metacodes jedoch nicht einsetzen kann. Denn hierzu wäre eine Verschlüsselung in eine Chiffre C2 erforderlich, die mangels des Schlüssels s2 (der beim Entwickler verbleibt) nicht möglich ist. Dadurch wird eine Manipulation des Programmmoduls M2 vereitelt.

Eine Chiffredatei kann auch mehrere Programmmodule enthalten, insbesondere wenn diese Teile eines Java-Programms darstellen und somit ein gleichzeitiges Laden der Module • · · ··· P9120 • · ·♦· -8- zweckmäßig ist. Dies ist in Fig. 1 am Beispiel des Programms M3 gezeigt, das zwei Unter-module M3a, M3b umfasst. Nach der Vorkompilierung der einzelnen Untermodule M3a, M3b aus dem Quellcode SC3 werden diese jeweils verschlüsselt und in eine Chiffredatei C3 zusammengefasst. Diese werden dann bei der Ausführung jeweils entschlüsselt und die zugehörenden Metacodes m3a, m3b im Speicher abgelegt, wobei a3 die Startadresse für den Aufruf des ersten Untermoduls m3a (z.B. des Hauptprogramms) darstellt. Im Übrigen entspricht dieser Fall dem oben Gesagten. Bei Bedarf können auch verschiedene Schlüssel für die einzelnen Untermodule eingesetzt werden.

Im Ausführungsbeispiel wird jede Programmdatei Ml, C2, C3 jeweils für sich auf einem computerlesbaren Datenträger Dl, D2, D3 ausgegeben. Selbstverständlich können bei Bedarf auf einem Datenträger auch mehrere Programmdateien nach der Erfindung abgespeichert sein. Für verschiedene erfindungsgemäß verschlüsselte Programmdateien C2, C3 werden günstiger Weise jeweils eigenen Schlüssel(paare) verwendet. Beispielsweise liegt der Chiffre C3 des Programmmoduls M3 ein eigener Schlüssel s3 zugrunde. Aufseiten des Anwenders wird dem entsprechend beim Aufruf der Programmdatei C3 der zugehörende Gegenschlüssel k3 bzw. das zugehörende Entschlüsselungsmodul DE3 verwendet. Günstigerweise prüft das Lademodul LM beim Aufruf einer angebotenen Programmdatei Ml, C2, C3, ob dieses eine imverschlüsselte Programmdatei Ml oder eine Chiffre-Datei C2, C3 ist; im letzteren Fall wird dann bestimmt, welcher Schlüssel k2, k3 und/ oder welches Entschlüsselungsmodul DE2, DE3 zu verwenden ist. Die Information über die Verschlüsselung kann z.B. anhand einer Datei-Erweiterung bestimmt werden - z.B. ". dass" für eine Metacode-Datei und ". crypt" für eine verschlüsselte Datei - oder anhand von im Kopf der Datei enthaltenen Steuerdaten ermittelt werden - z.B. nach Art der sogenannten 'magic numbers' am Beginn einer Datei unter UNIX. Im Allgemeinen wird überprüft, ob die auszuführende Datei Merkmale aufweist, denen zufolge sie eine verschlüsselte Datei (wie die Datei C2) ist, und falls dies zutrifft, wird dem entsprechend die Entschlüsselung versucht, ansonsten die Datei als unkodierte Metacode-Datei (wie die Datei Ml) behandelt wird.

Die Information, welche Entschlüsselung k2/DE2 bzw. k3/DE3 für die Ausführung einer bestimmten (verschlüsselten) Programmdatei C2, C3 zu wählen ist, kann das Lademodul LM auf verschiedene Wege erhalten. Beispielsweise wird diese beim Aufruf durch das Startermodul SM übergeben, in das in diesem Fall die entsprechende Information vom Entwickler einprogrammiert wurde. Die Information kann auch in der Programmdatei codiert sein, z.B. in einem Header cc2, oder die Zuordnung geschieht über den Dateinamen - P9120 P9120 • · • · • « ·* • · · ·»·

♦ · · · I • · · ·· Μ* -9- z.B. gehört zur Programmdatei C3 mit dem Dateinamen "m3.crypt" das Entschlüsselungsmodul DE3 "m3. decod" - oder eine Initialisierungsdatei cf3 "m3. ini", in der (neben anderen Informationen) der Name des Entschlüsselungsmoduls enthalten ist, und zwar je nach Anforderung in Klartext oder kodiert.

Der Vorteil der Verwendung eines Startermoduls SM als Shell (Oberflächenprogramm für den Aufruf) des Lademoduls LM liegt darin, dass hierbei verwendete Parameter gegenüber dem Anwender verborgen werden können. Wenn beispielsweise der Anwender einen Befehl stc zum Aufruf der Programmdatei C2 eingibt, nämlich SM m2 mit dem Parameter m2 entsprechend dem Basisteil des Dateinamens "m2.crypt" der Datei C2, so wird das Startermodul SM aufgerufen und generiert - für den Anwender nicht erkennbar - einen Java-Aufruf für das Lademodul LM. Dieser Java-Aufruf würde, wenn über eine Kommandozeile eingegeben, z.B. der Form java LM.class m2.class arg1 arg2 entsprechen, wobei "LM.class" der Dateiname des Lademoduls LM, "m2.class" der Dateiname des Metacodes M2 zur Chiffre C2 ist. Weitere, eventuell benötigte kompilierte Java-Dateien werden automatisch nachgeladen und bei Bedarf entschlüsselt, wobei der beschriebene Vorgang iteriert wird. Die übrigen Parameter arg1 arg2 repräsentieren zusätzliche Argumente, die vom Startermodul SM ergänzt werden. Diese Paramter werden beispielsweise einer Konfigurationsdatei cf2 (z.B. mit Dateinamen "m2.ini") entnommen, in der diese Parameter festgelegt sind. Die Konfigurationsdatei wird im Ausführungsbeispiel gemeinsam mit der Programmdatei C2 ausgeliefert, kann jedoch auch auf anderem Wege, z.B. zusammen mit dem Schlüssel k2 auf dem Datenträger DK, übergeben werden.

In einer Variante, die ohne solche Konfigurationsdateien auskommt, ist im Startermodul der Java-Aufruf jeweils für eine Programmdatei fest einkodiert. Es ist dann für jedes Programm Ml, C2, C3 jeweils ein eigenes Startermodul erforderlich.

Wie bereits erwähnt, liegt das Lademodul LM als (kompilierter) Java-Code vor. Zum Schutz vor Dekompilierung und Manipulation des Lademoduls LM kann dieses in verschlüsselter Form CVM abgespeichert sein. Das Startermodul veranlasst unmittelbar vor dem Aufruf des Lademoduls dessen Entschlüsselung, und zwar mittels eines Dekodierschlüssels kv, der günstiger Weise im Startermodul SM abgelegt ist. Der ausführbare Klartext-Code des Lademoduls LM liegt in diesem Fall nur vor, bis das Ausführmodul EX die Interpretation der Programmdatei übernimmt, und wird dann gelöscht bzw. überschrieben. Beim nächsten Aufruf muss das Lademodul LM dann neuerlich entschlüsselt werden. P9120 P9120 « · t · • · · · · • ♦ · * · · ·· · * · • · · · · · « ··· -10-

In einer anderen Variante zum Schutz vor Manipulation des Lademoduls LM kann vor seiner Ausführung eine Überprüfung der Integrität vorgesehen sein. Dies geschieht beispielsweise unter Verwendung eines geeigneten Hash-Verfahrens bekannter Art dadurch, dass das Startermodul SM eine Hash-Summe über das Lademodul berechnet und den so erhaltenen Prüfwert der Hash-Summe mit einem - im vorhinein anhand des ursprünglichen Lademoduls berechneten und im Programmcode des Startermoduls kodierten - Kontroll-wert vergleicht. Nur wenn Kennwert und Prüfwert übereinstimmen, wird das Lademodul gestartet; ansonsten liegt ein manipuliertes Lademodul LM vor, dessen Ausführung zu verweigern ist.

Wien, den 1 a Mai 2003

Claims (16)

1. P9120 ¥ · • · • ·· • · • · • · ι ··· • ♦· · • · ·· ··· -11- Patentansprüche 1. Verfahren zum Ausführen einer Programmdatei, in der interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist, bei welchem von einem Lademodul interpretierbarer Objektcode in einen RAM-Speicher geladen wird und dieser sodann von einem Ausführmodul interpretiert wird, dadurch gekennzeichnet, dass seitens des Lademoduls (LM) zumindest ein Teil des zu ladenden Objektcodes (m2, m3a, m3b) aus in der angebotenen Programmdatei (C2, C3) vorhegendem Chiffre-Code gemäß folgenden Schritten gewonnen wird: a) Bestimmen eines Mittels (k, DE) zum Entschlüsseln des Chiffre-Codes unter Verwendung von der Programmdatei zugeordneter Hinweis-Information und b) Berechnen von Objektcode (m2, m3a, m3b) durch Entschlüsseln des Chiffre-Codes unter Verwendung des Entschlüssel-Mittels (k, DE).
2. 2. Verfahren nach Anspruch 1, dadurch gekennzeichnet dass als Mittel zum Entschlüsseln ein Programmmodul (DE) („Entschlüsselungsmodul") verwendet wird, das vom Lademodul (LM) unter Übergabe des zu entschlüsselnden Chiffre-Codes (C2, C3) aufgerufen wird, daraus Objektcode entschlüsselt und den so gewonnenen Objektcode an das Lademodul (LM) zurückgibt.
3. 3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet dass in Schritt a) das Mittel zum Entschlüsseln (k, DE) aus einer Anzahl von auf einem dem Lademodul zugeordneten Speichermedium (HD2) gehaltenen Mitteln zum Entschlüsseln (k2, k3, DE2, DE3) ausgewählt wird.
4. 4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet dass vor dem Aufruf des Lademoduls (LM) seine Integrität von einem Startermodul (SM) geprüft wird, insbesondere durch Berechnung eines Prüfwerts aus dem Lademodul nach einem Hash-Verfahren und Vergleich mit einem vorgegebenen Kontrollwert, und nur im Falle eines positiven Prüfergebnisses das Lademodul aufgerufen wird.
5. 5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet dass das Lademodul (LM) für seine Ausführung aus einer Chiffre-Datei auf Veranlassung durch ein Startermodul (SM) entschlüsselt wird. P9120 * · * » » * I t ·+ ··· · • · • · I • · · · t> • · I ·* ·· M· « · ·»· -12-
6. 6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet dass in Schritt a) die Hinweis-Information einer der Programmdatei zugeordneten Konfigurationsdatei (cf2, cf3) und/ oder in der Programmdatei enthaltenen Steuerdaten (cc2) entnommen wird.
7. 7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet dass vor Schritt a) seitens des Lademoduls (LM) geprüft wird, ob in der angebotenen Programmdatei (Ml, C2, C3) Chiffre-Code vorliegt, und falls dies zutrifft, mit Schritt a) fortgesetzt wird, ansonsten in der Programmdatei enthaltener Objektcode direkt geladen wird.
8. 8. Computerprogramm mit Programmcodemitteln, um das Verfahren nach einem der Ansprüche 1 bis 7 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
9. 9. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um das Verfahren nach einem der Ansprüche 1 bis 7 durchzuführen, wenn das Programm auf einem Computer ausgeführt wird.
10. 10. Rechnereinrichtung zum Ausführen von Programmdateien, in denen interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist, mit einem Interpretersystem (VM), das ein Lademodul (LM) zum Laden von interpretierbarem Objektcode in einen RAM-Speicher und ein Ausführmodul (EX) zum Interpretieren von im RAM-Speicher befindlichen Objektcode aufweist, dadurch gekennzeichnet, dass seitens des Lademoduls (LM) ein Mittel (k, DE) zum Entschlüsseln von in einer angebotenen Programmdatei (C2, C3) vorliegendem Chiffre-Code in Abhängigkeit von der Programmdatei zugeordneter Hinweis-Information vorgesehen ist, und das Lademodul (LM) dazu eingerichtet ist, durch die Entschlüsselung gewonnenen Klartext (m2, m3a, m3b) als Objektcode in den RAM-Speicher zu laden.
11. 11. Einrichtung nach Anspruch 10, dadurch gekennzeichnet dass das Mittel zum Entschlüsseln als Programmmodul (DE) („Entschlüsselungsmodul") realisiert ist, das vom Lademodul (LM) unter Übergabe des zu entschlüsselnden Chiffre-Codes (C2, C3) für die Rückgabe des daraus entschlüsselten Objektcodes aufrufbar ist. P9120 P9120

    k t | ·♦ #·· 13
12. 12. Einrichtung nach Anspruch 10 oder 11, gekennzeichnet durch eine Anzahl von auf einem dem Lademodul zugeordneten Speichermedium (HD2) gehaltenen Mitteln zum Entschlüsseln (k2, k3, DE2, DE3), aus denen jeweils ein Mittel zum Entschlüsseln (k, DE) gemäß der der Programmdatei zugeordneter Information auswählbar ist.
13. 13. Einrichtung nach einem der Ansprüche 10 bis 12, gekennzeichnet durch ein Startermodul (SM), welches dazu eingerichtet ist, das Lademodul (LM) auf seine Integrität zu prüfen, insbesondere durch Berechnung eines Prüfwerts aus dem Lademodul nach einem Hash-Verfahren und Vergleich mit einem vorgegebenen Kontrollwert, und nur im Falle eines positiven Prüfergebnisses den Aufruf des Lademoduls zuzulassen.
14. 14. Einrichtung nach einem der Ansprüche 10 bis 13, gekennzeichnet durch eine Chiffre-Datei (CVM), in der das Lademodul in verschlüsselter Form enthalten ist, und ein Startermodul (SM) zum Veranlassen der Entschlüsselung des Lademoduls (LM) aus der Chiffre-Datei anlässlich der Ausführung des Lademoduls (LM).
15. 15. Datenträger (D2, D3) auf welchem zumindest eine Programmdatei (C2, C3), in der interpretierbarer Objektcode gemäß einer Interpreter-Sprache enthalten ist, abgelegt ist, dadurch gekennzeichnet, dass die Programmdatei Chiffre-Code aufweist, welcher interpretierbaren Objektcode (m2, m3a, m3b) in verschlüsselter Form enthält, und der Datenträger und/ oder die Programmdatei Hinweis-Informationen aufweist, anhand der Mittel (k, DE) zum Entschlüsseln des Chiffre-Codes bestimmbar sind.
16. 16. Datenträger nach Anspruch 15, dadurch gekennzeichnet dass die Hinweis-Information als der Programmdatei (C2, C3) zugeordnete Konfigurationsdatei (cf2, cf3) und/oder in der Programmdatei enthaltene Steuer daten (cc2) realisiert ist.

    Wien, den