-
Die
Erfindung betrifft ein Verfahren und ein System zum Schutz eines
Maschinencodes, beispielsweise eines Java-Byte-Codes, gegen einen unbefugten Zugriff
durch einen Dritten.
-
Java
ist eine von der Firma Sun Microsystems zunächst für den Internetbereich entwickelte objektorientierte
Programmiersprache. Java wird inzwischen jedoch als universelle
Programmiersprache eingesetzt. Alle Programmobjekte sind in Java
in sog. Klassen definiert. Eine Eigenschaft von Java besteht darin,
dass ausführbare
Java-Programme vollständig portabel
sind. Dies wird dadurch erreicht, dass der Java-Compiler keinen
rechnerarchitekturspezifischen Maschinencode, sondern einen architekturneutralen
sog. Java-Byte-Code generiert. Dieser Java-Byte-Code wird bei der
Ausführung
des Java-Programms interpretiert oder während der Ausführung in
den architekturspezifischen Maschinencode der jeweiligen CPU durch
einen JIT(Just In Time)-Compiler übersetzt. Eine Abhängigkeit
von dem jeweiligen Betriebssystem oder der jeweiligen Fensteroberfläche wird
bei Java durch Verwendung von Programmbibliotheken weitgehend vermieden.
-
Bei
herkömmlichen
Geräten,
die Java-Quelldateien verwenden, wird der Java-Quellcode bzw. Uni-Code
durch einen Compiler kompiliert und in einem Speicher des Gerätes, bei
dem es sich beispielsweise um einen Steuerrechner handelt, abgelegt
bzw. gespeichert. Die in dem Speicher abgelegten Java-Object-Files
(.-Class-Files) können
nach Auslieferung bzw. Verbreitung des Gerätes durch unbefugte Dritte
relativ leicht ausgelesen und zu Reverse Engineering Zwecken dekompiliert
werden.
-
Es
ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren
und ein System zum Schutz gegen einen unbefugten Zugriff auf einen
Maschinencode eines Gerätes
zu schaffen.
-
Diese
Aufgabe wird erfindungsgemäß durch ein
Verfahren mit den im Patentanspruch 1 angegebenen Merkmalen gelöst.
-
Die
Erfindung schafft ein Verfahren zum Schutz gegen einen Zugriff auf
einen Maschinencode eines Geräts
mit den Schritten:
- (a) Verschlüsseln eines
Maschinencodes mittels eines gerätespezifischen
Schlüssels,
der durch ein in dem Gerät
enthaltenes TPM(Trusted Plattform Module)-Modul bereitgestellt wird,
- (b) Speichern des verschlüsselten
Maschinencodes in einem Speicher des Geräts,
- (c) wobei der gerätespezifische
Schlüssel
nach einer an dem Gerät
vorgenommenen Manipulation nicht mehr aus dem TPM-Modul auslesbar ist.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
wird der Maschinencode durch einen Java-Byte-Code gebildet.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
wird der gerätespezifische Schlüssel durch
eine AIK(Attestation Identity Key)-Schlüssel des TPM-Moduls gebildet.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
entschlüsselt
ein Class-Loader einer Java Virtual Machine den in dem Speicher
des Gerätes
gespeicherten und verschlüsselten
Maschinencode mittels des aus dem TPM-Modul ausgelesenen gerätespezifischen
Schlüssels
und stellt den entschlüsselten
Maschinencode einer Ausführeinheit des
Geräts
bereit.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
wird der gerätespezifische Schlüssel von
dem TPM-Modul über ein
Netzwerk zu einer Verschlüsselungseinheit übertragen,
die den Maschinencode mittels des gerätespezifischen Schlüssels verschlüsselt. Diese
Verschlüsselungseinheit
kann sich auch in dem Gerät
befinden.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
wird der entschlüsselte
Maschinencode durch die Ausführeinheit
des Gerätes
ausgeführt
oder interpretiert.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
wird der Maschinencode durch MP3-Daten gebildet.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Verfahrens
werden verschlüsselte MP3-Daten
mittels eines aus dem TPM-Modul
ausgelesenen gerätespezifischen
Schlüssels
entschlüsselt
und einem MP3-Decoder des Gerätes
bereitgestellt.
-
Die
Erfindung schafft ferner ein System zum Schutz gegen einen Zugriff
auf einen Maschinencode eines Gerätes, wobei der Maschinencode
mittels eines gerätespezifischen
Schlüssels,
der durch ein in dem Gerät
enthaltenes TPM-Modul bereitgestellt wird, verschlüsselt und
in einem Speicher des Gerätes
gespeichert wird, wobei der gerätespezifische Schlüssel nach
einer an dem Gerät
vorgenommenen Manipulation nicht mehr aus dem TPM-Modul auslesbar
ist.
-
Die
Erfindung schafft ferner ein Gerät
mit zugriffsgeschütztem
Maschinencode mit:
- (a) einem Speicher zum Speichern
eines verschlüsselten
Maschinencodes MC;
- (b) einem Class-Loader zum Entschlüsseln des verschlüsselten
Maschinencodes mittels eines aus einem TPM-Modul ausgelesenen gerätespezifischen
Schlüssels;
und mit
- (c) einer Ausführeinheit
zum Ausführen
des entschlüsselten
Maschinencodes;
- (d) wobei der gerätespezifische
Schlüssel
nach einer an dem Gerät
vorgenommnen Manipulation von dem TPM-Modul gesperrt wird.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Gerätes ist
der Speicher ein nicht flüchtiger Speicher.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Geräts weist
der nicht flüchtige
Speicher eine Festplatte auf.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Geräts ist die
Ausführeinheit
in einer JVM (Java Virtual Machine) vorgesehen.
-
Bei
einer Ausführungsform
des erfindungsgemäßen Geräts ist die
Ausführeinheit
ein Decoder.
-
Die
Erfindung schafft ferner ein Programm mit Programmbefehlen zur Durchführung eines
Verfahrens zum Schutz gegen einen Zugriff auf einen Maschinencode
eines Geräts
mit den Schritten:
- (a) Verschlüsseln eines
Maschinencodes mittels eines gerätespezifischen
Schlüssels,
der durch ein in dem Gerät
enthaltenes TPM(Trusted Plattform Module)-Modul bereitgestellt wird,
- (b) Speichern des verschlüsselten
Maschinencodes in einem Speicher des Geräts,
- (c) wobei der gerätespezifische
Schlüssel
nach einer an dem Gerät
vorgenommenen Manipulation nicht mehr aus dem TPM-Modul auslesbar ist.
-
Die
Erfindung schafft ferner einen Datenträger zum Speichern eines Programms
mit Programmbefehlen zur Durchführung
eines Verfahrens zum Schutz gegen einen Zugriff auf einen Maschinencode eines
Geräts
mit den Schritten:
- (a) Verschlüsseln eines
Maschinencodes mittels eines gerätespezifischen
Schlüssels,
der durch ein in dem Gerät
enthaltenes TPM(Trusted Plattform Module)-Modul bereitgestellt wird,
- (b) Speichern des verschlüsselten
Maschinencodes in einem Speicher des Geräts,
- (c) wobei der gerätespezifische
Schlüssel
nach einer an dem Gerät
vorgenommenen Manipulation nicht mehr aus dem TPM-Modul auslesbar ist.
-
Im
Weiteren werden bevorzugte Ausführungsformen
des erfindungsgemäßen Verfahrens und
des erfindungsgemäßen Systems
zum Schutz gegen einen Zugriff auf einen Maschinencode unter Bezugnahme
auf die beigefügten
Figuren zur Erläuterung
erfindungswesentlicher Merkmale beschrieben.
-
Es
zeigen:
-
1:
ein Ablaufdiagramm zur Darstellung einer Ausführungsform des erfindungsgemäßen Verfahrens;
-
2:
ein Blockschaltbild zur Darstellung eines Verschlüsselungsvorgangs
bei einer Ausführungsform
des erfindungsgemäßen Verfahrens;
-
3:
ein Blockschaltbild einer möglichen Ausführungsform
eines Geräts
mit zugriffsgeschütztem
Maschinencode gemäß der Erfindung.
-
Das
erfindungsgemäße Verfahren
ist zum Schutz gegen einen Zugriff auf einen Maschinencode eines
Geräts
vorgesehen, um insbesondere ein Auslesen von Dateien und deren Dekompilierung
zu Reverse-Engineering Zwecken zu verhindern.
-
Bei
dem Maschinencode kann es sich beispielsweise um einen Java-Byte-Code
handeln. Java-Programme werden nach ihrer Er stellung zunächst kompiliert.
Dabei wird der sog. Byte-Code erstellt.
-
Eine
Java Virtual Machine (JVM) besteht aus Computerprogrammen und Datenstrukturen,
die ein spezifisches virtuelles Maschinenmodell implementieren.
Dieses virtuelle Maschinenmodell akzeptiert in Java-Zwischencode
bzw. Java-Byte-Code, welche durch den Java-Compiler generiert wird.
Die Java Virtual Machine ist eine Software, die für jede Plattform
gesondert entwickelt wird und für
fast jede denkbare Kombination aus Betriebssystem und Hardware verfügbar ist.
Die JVM Virtual Machine stellt eine Schnittstelle zwischen dem plattformunabhängigen Java-Byte-Code
und dem System, auf dem dieser Java-Byte-Code ausgeführt wird,
dar. Der Java-Quelltext eines Java-Programms wird zunächst kompiliert
und anschließend
wird der erzeugte Byte-Code auf einem Zielrechner durch die JVM
Virtual Machine interpretiert. Dies bietet den Vorteil einer Portabilität und einer
Plattformunabhängigkeit des
Java-Quelltextes.
Auch andere Systeme verwenden Zwischencodes, die anschließend interpretiert werden.
Java-Byte-Code oder MSIL (Microsoft Intermediate Language) können dabei
auf verschiedenen Plattformen nicht nur basierend auf der gleichen Sprache
erzeugt werden, sondern auch basierend auf verschiedenen Sprachen
erzeugt werden.
-
Wie
man aus 1 erkennen kann, wird bei dem
erfindungsgemäßen Verfahren
zum Schutz gegen einen Zugriff ein Maschinencode MC, beispielsweise
einen Java-Byte-Code, in einem Schritt S1 verschlüsselt. Die
Verschlüsselung
erfolgt mittels eines gerätespezifischen
Schlüssels,
der durch ein in dem Gerät
enthaltenes TPM-Modul bereitgestellt wird. Bei dem TPM-Modul (Trust Platform
Modul) handelt es sich beispielsweise um einen Chip, der in dem
Gerät eingebaut
ist. Bei einer möglichen
Ausführungsform ist
das TPM-Modul aktiv und überprüft den Bootcode vor
dessen Ausführung.
Vor der Ausführung
des Betriebssystems stellt sich der Bootcode dem TPM-Modul den Betriebssystemcode
zur Überprüfung bereit. Ebenso
stellt das Betriebssystem vor Ausführung der JVM dem TPM-Modul
den JVM-Code zur Überprüfung bereit.
Hierdurch werden Manipulationen, insbesondere Änderungen am Code, erkannt.
-
Das
TPM-Modul besitzt eine eindeutige Kennung und dient u. a. zur Identifizierung
des Gerätes. Das
TPM-Modul verfügt über verschiedene
Schlüssel,
nämlich
einen sog. Endorsement-Key (EK), der dem TPM-Modul eindeutig zugeordnet
ist und Attestation Identity Keys (AIK). Weiterhin verfügt das TPM-Modul über einen
sog. Storage-Root-Key (SRK), der dazu dient, weitere benutzte Schlüssel, beispielsweise
private Schlüssel,
zu verschlüsseln und
stellt somit die Wurzel eines TPM-Schlüsselbaums
dar. Aus Sicherheitsgründen
darf der Endorsement-Key (EK) das TPM-Modul niemals verlassen, so
dass auch ein Back-up des Endorsement-Keys (EK) ausgeschlossen ist.
Die Erzeugung des Endorsement-Keys (EK) kann hingegen extern erfolgen. Das
Auslesen des Endorsement-Keys kann mit einem Kommando blockiert
werden, wobei diese Blockierung endgültig ist und nicht mehr aufgehoben werden
kann.
-
Die
Attestation Identiy Keys (AIK) können
zur Attestation bzw. Beglaubigung eingesetzt werden. Die AIK-Schlüssel sind
beispielsweise RSA-Schlüssel
mit einer festgelegten Länge
von 2048 Bit. Die AIK-Schlüssel
sind nicht migrierbar und werden von dem TPM-Modul für die Signatur
bzw. Beglaubigung von Daten eingesetzt. Die Attestations-Identity-Keys (AIK)
werden von dem TPM-Modul bereitgestellt, weil der Endorsement-Key
(EK) eines TPM-Moduls für die
Beglaubigung einer Plattformintegrität (Attestation) eingesetzt
werden kann. Daher werden die AIK-Schlüssel und das TPM-Modul für Beglaubigungsprozesse
verwendet und können
in beliebiger Anzahl erzeugt bzw. generiert werden. Zur Sicherstellung,
dass nur gültige
AIK-Schlüssel erstellt
werden, können
diese Schlüssel
durch eine vertrauenswürdige
dritte Partei (Trusted Third Party), die auch als Privacy CA bezeichnet
werden kann, bestätigt werden.
Diese Bestätigung
erfolgt in Form eines AIK-Zertifikats (Credential).
-
Die
Schlüssel
werden innerhalb des TPM-Moduls erzeugt, benutzt und sicher abgelegt, um
sie vor Softwareangriffen zu schützen.
Das TPM-Modul ist derart ausgelegt, dass eine physische Manipulation,
die unweigerliche Zerstörung
der Daten, insbesondere der darin enthaltenen kryptographischen
Schlüssel,
zur Folge hat.
-
In
Schritt S1 des in 1 dargestellten Verfahrens wird
der Maschinencode MC, beispielsweise der Java-Byte-Code, in einer
Ausführungsform
mittels eines AIK-Schlüssels,
der durch ein in dem Gerät vorhandenes
TPM-Modul bereitgestellt wird, verschlüsselt.
-
Der
verschlüsselte
Maschinencode wird anschließend
im Schritt S2 in einem Speicher des Gerätes abgelegt. Der gespeicherte
verschlüsselte
Maschinencode kann nur entschlüsselt
werden, wenn man über
den zugehörigen
AIK-Schlüssel
verfügt. Dieser
AIK-Schlüssel
kann allerdings nur ausgelesen werden, solange das TPM-Modul, in
dem sich der AIK-Schlüssel
befindet, nicht manipuliert wird.
-
Wird
im Schritt S3 festgestellt, dass eine Manipulation an dem TPM-Modul
erfolgt ist, werden bei einer möglichen
Ausführungsform
die in dem TPM-Modul enthaltenen Schlüssel irreversibel zerstört und sind
nicht mehr auslesbar, d. h. der Schlüssel, insbesondere der AIK-Schlüssel, werden
im Schritt S4 gesperrt.
-
2 zeigt
ein Blockschaltbild zur Verdeutlichung einer möglichen Ausführungsform
des erfindungsgemäßen Verfahrens.
-
Ein
Compiler 2 kompiliert einen Java-Quellcode 1 zur
Erzeugung eines Java-Byte-Codes bzw. interpretierbaren Uni-Codes
oder Zwischencode. Eine Verschlüsselungseinheit 3 liest
einen gerätespezifischen
Schlüssel
K aus einem Gerät 4 aus. Bei
dem gerätespezifischen
Schlüssel
handelt es sich beispielsweise um einen AIK(Attestation Identity Key)-Schlüssel. Das
Gerät 4 bei
dem in 2 dargestellten Ausführungsbeispiel weist eine Java
Virtual Machine 4A, einen Speicher 4B und ein
TPM-Modul 4C auf.
Bei dem Speicher 4B handelt es sich beispielsweise um einen
nicht flüchtigen
Speicher, der durch eine Festplatte gebildet wird. Bei dem Gerät 4 kann
es sich beispielsweise um einen Steuerungsrechner für eine Anlage
handeln. Die Verschlüsselungseinheit 3 liest
einen gerätespezifischen AIK-Schlüssel (KAIK) aus dem TPM-Modul 4C des Gerätes 4 aus
und verschlüsselt
mit diesem Schlüssel
den Maschinencode bzw. den Java-Byte-Code. Bei dem Maschinencode
MC muss es sich nicht notwendigerweise um einen Java-Byte-Code handeln. In
alternativen Ausführungsformen
kann es sich bei dem Maschinencode um einen beliebigen Maschinencode
MC eines beliebigen Prozessors, auch um MP3-Daten handeln. Der von
der Verschlüsselungseinheit 3 verschlüsselte Maschinencode
wird von der Verschlüsselungseinheit 3 in
den Speicher 4B des Gerätes 4 eingeschrieben.
Der in den Speicher 4B eingeschriebene, verschlüsselte Maschinencode
ist in dieser Form noch nicht ausführbar, dafür aber sicher gegen Dekompilieren
zu Reverse-Engineering Zwecken.
Nach Einschreiben des verschlüsselten Maschinencodes
in den Speicher 4B des Gerätes 4 kann das Gerät an Kunden
ausgeliefert werden.
-
Ein
unbefugter Dritter, der nicht über
den gerätespezifischen
Schlüssel
verfügt,
kann den verschlüsselten
Maschinencode, beispielsweise den verschlüsselten Java-Byte-Code, nicht
dekompilieren, da dieser verschlüsselt
in dem Speicher 4B abgelegt ist. Um an den gerätespezifischen
Schlüssel zu
gelangen, müsste
ein unbefugter Dritter Manipulationsversuche an dem TPM-Modul 4C vornehmen, wobei
allerdings der gerätespezifische
Schlüssel
bei einer an dem TPM-Modul 4C vorgenommene Manipulation
durch das TPM-Modul 4C automatisch gesperrt bzw. die Schlüsseldaten
zerstört
werden.
-
3 zeigt
ein Blockschaltbild des ausgelieferten Gerätes 4 zur Verdeutlichung
der Entschlüsselung
des Maschinencodes MC bei einem befugten Abnehmer des Gerätes 4.
Die JVM-Maschine 4A weist
einen sog. Class-Loader 4A-1 und eine Ausführeinheit 4A-2 auf.
Die JVM 4A ermöglicht
es, einen benutzerdefinierten Class-Loader zu erstellen und einzusetzen.
Die JVM 4A erzeugt standardmäßig ein Exemplar einer Klasse,
den sog. System-Class-Loader. Dieser System-Class-Loader kann Klassen
aus .-Class-Dateien in einem lokalen Datensystem laden.
-
Ein
anwendungsdefinierter Class-Loader ist mit dem System-Class-Loader verkettet,
entweder direkt oder indirekt über
andere Class-Loader.
-
Ein
Class-Loader erhält
durch den Aufruf einer Methode Loadclass () die Aufforderung, eine
bestimmte Klasse zu laden. Der Class-Loader leitet dann die Anfrage
zunächst
an einen übergeordneten Class-Loader
weiter. Nur wenn dieser die Klasse nicht findet, versucht der Class-Loader
selbst, die Klasse zu laden.
-
Bei
dem in 3 dargestellten Gerät ist der Class-Loader 4A-1 ein
benutzer- bzw. anwendungsdefinierter Class-Loader, den man auch
als Trusted-Class-Loader bezeichnen kann. Wenn der Trusted-Class-Loader 4A-1 eine
Klasse lädt,
erhält
er zunächst
eine verschlüsselte
Form einer Datei aus dem Speicher 4B und entschlüsselt anschließend mit Hilfe
des aus dem TPM-Modul 4C ausgelesenen AIK-Schlüssels Daten
der geladenen Datei. Der Class-Loader 4A-1 der JVM entschlüsselt den
in dem Speicher 4B des Gerätes 4 gespeicherten
und verschlüsselten
Maschinencode, beispielsweise den verschlüsselten Java-Byte-Code, mittels des
aus dem TPM-Modul 4C ausgelesenen gerätespezifischen Schlüssels und
stellt den entschlüsselten
Maschinencode MC der Ausführeinheit 4A-2 der
JVM zur Verfügung.
Wird das in 3 dargestellte, ausgelieferte
Gerät bei
einem Abnehmer bzw. Kunden eingeschaltet, prüft das TPM-Modul 4C zunächst ob eine
Manipulation stattgefunden hat oder nicht. Nur wenn keine Manipulation
vorgenommen wurde, wird der gerätespezifische
Schlüssel
(KAIK) zur Verfügung gestellt. Der benutzerdefinierte
Class-Loader führt die
Entschlüsselung
mit Hilfe des ausgelesenen gerätespezifischen
Schlüssels
durch.
-
Zum
Einlesen eines Byte-Codes wird die von dem Class-Loader bereitgestellte
Methode Define Class () aufgerufen, um aus dem Byte-Code ein Class-Object
zu erzeugen. Anschließend
wird der Byte-Code von der Java Virtual Machine JVM als Klasse registriert.
-
In
einer möglichen
Ausführungsform
wird die Ausführeinheit 4A-2 durch
eine außerhalb
der JVM-Maschine vorgesehene Ausführeinheit, beispielsweise durch
eine CPU gebildet.
-
In
einer weiteren Ausführungsform
wird die Ausführeinheit 4A-2 durch
einen Decoder, insbesondere einen MP3-Daten-Decoder, gebildet.
-
In
einer möglichen
Ausführungsform
wird der gerätespezifische
Schlüssel
von dem TPM-Modul 4C über
ein Netzwerk zu der Verschlüsselungseinheit 3 übertragen,
die den Maschinencode MC mittels des gerätespezifischen Schlüssels verschlüsselt.