EP2193471A1 - Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes - Google Patents

Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes

Info

Publication number
EP2193471A1
EP2193471A1 EP08803305A EP08803305A EP2193471A1 EP 2193471 A1 EP2193471 A1 EP 2193471A1 EP 08803305 A EP08803305 A EP 08803305A EP 08803305 A EP08803305 A EP 08803305A EP 2193471 A1 EP2193471 A1 EP 2193471A1
Authority
EP
European Patent Office
Prior art keywords
machine code
specific key
tpm module
memory
module
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP08803305A
Other languages
English (en)
French (fr)
Inventor
Konrad Schwarz
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP2193471A1 publication Critical patent/EP2193471A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action

Definitions

  • the invention relates to a method and a system for protecting a machine code, for example a Java byte code, against unauthorized access by a third party.
  • Java is an object-oriented programming language first developed by Sun Microsystems for the Internet domain. Java is now used as a universal programming language. All program objects are defined in Java in so-called classes. A feature of Java is that executable Java programs are completely portable. This is achieved by the fact that the Java compiler does not generate a machine architecture-specific machine code, but rather an architecture-neutral so-called Java byte code. This Java byte code is interpreted during execution of the Java program or translated during execution into the architecture-specific machine code of the respective CPU by a JIT (Just In Time) compiler. A dependence on the respective operating system or the respective window surface is largely avoided in Java by using program libraries.
  • JIT Just In Time
  • the Java source code or uni code is compiled by a compiler and stored in a memory of the device, which is for example a control computer.
  • the Java object files (.class files) stored in the memory can be read out relatively easily by unauthorized third parties after delivery or dissemination of the device and can be decompiled for reverse engineering purposes. It is therefore an object of the present invention to provide a method and system for protection against unauthorized access to a machine code of a device.
  • the invention provides a method of protection against access to a machine code of a device comprising the steps of:
  • the machine code is formed by a Java byte code.
  • the device-specific key is formed by an AIK (Attestation Identity Key) key of the TPM module.
  • AIK Attestation Identity Key
  • a class-loader of a Java Virtual Machine decrypts the machine code stored and encrypted in the memory of the device by means of the device-specific key read from the TPM module and makes the decrypted machine code available to an execution unit of the device.
  • the device-specific key is transferred from the TPM module transmit a network to an encryption unit that encrypts the machine code using the device-specific key.
  • This encryption unit can also be located in the device.
  • the decrypted machine code is executed or interpreted by the execution unit of the device.
  • the machine code is formed by MP3 data.
  • encrypted MP3 data is decrypted by means of a device-specific key read from the TPM module and provided to an MP3 decoder of the device.
  • the invention further provides a system for protection against access to a machine code of a device, wherein the machine code by means of a device-specific
  • TPM module which is provided by a TPM module contained in the device, is encrypted and stored in a memory of the device, the device-specific key after a manipulation performed on the device is no longer read out of the TPM module.
  • the invention further provides a device with access-protected machine code comprising:
  • Machine codes MC (b) a class loader for decrypting the encrypted
  • Machine codes by means of a device-specific key read from a TPM module; and with (c) an execution unit for executing the decrypted
  • the memory is a non-volatile memory.
  • the non-volatile memory has a hard disk.
  • the execution unit is provided in a JVM (Java Virtual Machine).
  • JVM Java Virtual Machine
  • the execution unit is a decoder.
  • the invention also provides a program
  • Program instructions for carrying out a method of protection against access to a machine code of a device comprising the steps of:
  • the invention further provides a data carrier for storing a program with program instructions for carrying out a method for protecting against access to a machine code of a device, comprising the steps:
  • TPM Trusted Platform Module
  • FIG. 1 shows a flow chart for illustrating an embodiment of the method according to the invention
  • FIG. 2 shows a block diagram for illustrating an encryption process in an embodiment of the method according to the invention
  • FIG. 3 shows a block diagram of a possible embodiment of an access-protected machine code device according to the invention.
  • the inventive method is provided for protection against access to a machine code of a device, in particular to prevent read-out of files and their decompilation for reverse engineering purposes.
  • the machine code may be, for example, a Java byte code. Java programs are after their Creation initially compiled. The so-called byte code is created.
  • Java Virtual Machine consists of computer programs and data structures that implement a specific virtual machine model.
  • This virtual machine model accepts Java intermediate code or Java bytecode generated by the Java compiler.
  • the Java Virtual Machine is a software that is developed separately for each platform and is available for almost every conceivable combination of operating system and hardware.
  • the JVM virtual machine provides an interface between the platform-independent Java bytecode and the system running this Java bytecode.
  • the Java source code of a Java program is first compiled and then the generated bytecode is compiled. Code on a target computer interpreted by the JVM Virtual Machine. This offers the advantage of portability and platform independence of the Java source code.
  • Other systems also use intermediate codes, which are subsequently interpreted.
  • Java byte code or MSIL Microsoft Intermediate Language
  • a machine code MC for example a Java byte code
  • Encryption is by means of a device-specific key provided by a TPM module included in the device.
  • the TPM module (Trust Platform Module) is, for example, a chip that is installed in the device.
  • the TPM module is active and checks the boot code prior to its execution. Before running the operating system, the boot code provides the TPM module with the operating system code for review. Likewise, before running the JVM, the operating system provides the JVM code to the TPM module for review. This will detect any manipulation, especially changes to the code.
  • the TPM module has a unique identifier and is used, for example. a. to identify the device.
  • the TPM module has several keys, namely a so-called endorsement key (EK), which is uniquely assigned to the TPM module and Attestation Identity Keys (AIK).
  • EK endorsement key
  • AIK Attestation Identity Keys
  • the TPM module has a so-called Storage Root Key (SRK), which is used to encrypt other used keys, such as private keys, and thus represents the root of a TPM key tree dar.
  • SRK Storage Root Key
  • Endorsement Key never leave the TPM module, so that a back-up of the endorsement key (EK) is also excluded.
  • the generation of the endorsement key (EK) can be done externally.
  • the reading of the endorsement key can be blocked with a command, whereby this blocking is final and can not be canceled.
  • the Attestation Identity Keys can be used for attestation.
  • the AIK keys are, for example, RSA keys with a fixed length of 2048 bits.
  • the AIK keys are not migratable and are used by the TPM module to sign or authenticate data.
  • the attestation identity keys (AIK) are provided by the TPM module because the endorsement key (EK) of a TPM module is used to authenticate a TPM module
  • AIK keys and the TPM module are used for authentication processes and can be generated or generated in any number.
  • these keys may be issued by a trusted third party, which may also be referred to as Privacy CA, beeing confirmed. This confirmation takes the form of an AIK certificate (Credential).
  • the keys are generated, used and securely stored within the TPM module to protect them from software attacks.
  • the TPM module is designed so that physical manipulation results in the inevitable destruction of the data, in particular the cryptographic keys contained therein.
  • step S1 of the method illustrated in FIG. 1 the machine code MC, for example the Java byte code, is encrypted in one embodiment by means of an AIK key provided by a TPM module present in the device.
  • the encrypted machine code is then stored in step S2 in a memory of the device.
  • the stored encrypted machine code can only be decrypted if you have the associated AIK key. However, this AIK key can only be read as long as the TPM module containing the AIK key is not tampered with.
  • step S3 If it is determined in step S3 that a manipulation has taken place on the TPM module, in one possible embodiment the keys contained in the TPM module are irreversibly destroyed and can no longer be read out, that is to say they are not readable. H. the key, in particular the AIK key, is blocked in step S4.
  • FIG. 2 shows a block diagram to clarify a possible embodiment of the method according to the invention.
  • a compiler 2 compiles a Java source code 1 for
  • An encryption unit 3 reads a device-specific key K from a device 4.
  • the device-specific key is, for example, an AIK (Attestation Identity Key) key.
  • the device 4 in the embodiment shown in Figure 2 comprises a Java virtual machine 4A, a memory 4B and a TPM module 4C.
  • the memory 4B is, for example, a nonvolatile memory formed by a hard disk.
  • the device 4 may be, for example, a control computer for a system.
  • the encryption unit 3 reads a device-specific AIK key (K A i ⁇ ) from the TPM module 4C of the device 4 and uses this key to encrypt the machine code or the Java byte code.
  • the machine code MC does not necessarily have to be a Java byte code. In alternative embodiments, it may be in the
  • Machine code to any machine code MC of any processor, even act on MP3 data The machine code encrypted by the encryption unit 3 is written by the encryption unit 3 into the memory 4B of the device 4.
  • the encrypted machine code written in the memory 4B is not yet executable in this form, but it is safe against decompilation for reverse engineering purposes. After writing the encrypted machine code in the memory 4B of the device 4, the device can be delivered to customers.
  • FIG. 3 shows a block diagram of the delivered device 4 to illustrate the decryption of the machine code MC at an authorized customer of the device 4.
  • the JVM machine 4A has a so-called. Class Loader 4A-1 and an execution unit 4A-2.
  • the JVM 4A allows you to create and deploy a custom class loader. By default, the JVM 4A creates a copy of a class called the System Class Loader. This system class loader can take classes. Load class files into a local data system.
  • An application-defined class loader is concatenated with the system class loader, either directly or indirectly through other class loaders.
  • a class loader is prompted to load a specific class by calling a load class () method.
  • the class loader first forwards the request to a higher-level class loader. Only if the class does not find the class will the class loader itself attempt to load the class.
  • the class loader 4A-1 is a user-defined or application-defined class loader, which may also be referred to as a trusted class loader.
  • the trusted-class loader 4A-1 loads a class, it first obtains an encrypted form of a file from the memory 4B and then decrypts data of the loaded file using the AIK key read from the TPM module 4C.
  • the class loader 4A-1 of the JVM decrypts the machine code stored in the memory 4B of the device 4, for example the encrypted Java byte code, by means of the device-specific key read from the TPM module 4C and provides the decrypted machine code MC Execution Unit 4A-2 of JVM available. If the device shown in FIG.
  • the TPM module 4C first checks whether a Manipulation has taken place or not. Only if no manipulation has been made, the device-specific key (K A i ⁇ ) is provided. The user-defined class loader performs the decryption using the device-specific key that has been read out.
  • the Define Class () method provided by the class loader is called to produce a class object from the byte code.
  • the bytecode is then registered as a class by the Java Virtual Machine JVM.
  • the execution unit 4A-2 is formed by an execution unit provided outside the JVM machine, for example by a CPU.
  • the execution unit 4A-2 is formed by a decoder, in particular an MP3 data decoder.
  • the device-specific key is transmitted from the TPM module 4C via a network to the encryption unit 3, which encrypts the machine code MC by means of the device-specific key.

Abstract

Verfahren zum Schutz gegen einen Zugriff auf einen Maschinencode eines Gerätes mit den Schritten: (a) Verschlüsseln eines Maschinencodes mittels eines gerätespezifischen Schlüssels, der durch ein in dem Gerät enthaltenes TPM (Trusted Platform 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.

Description

Beschreibung
Verfahren und System zum Schutz gegen einen Zugriff auf einen Maschinencode eines Gerätes
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:
Figur 1: ein Ablaufdiagramm zur Darstellung einer Ausführungsform des erfindungsgemäßen Verfahrens;
Figur 2: ein Blockschaltbild zur Darstellung eines Verschlüsselungsvorgangs bei einer Ausführungsform des erfindungsgemäßen Verfahrens ;
Figur 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 Erstellung 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 Figur 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 Sl 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 Sl des in Figur 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.
Figur 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 Figur 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 (KAiκ) 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. Figur 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 Load- class () 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 Figur 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 Figur 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 (KAiκ) 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.

Claims

Patentansprüche
1. Verfahren zum Schutz gegen einen Zugriff auf einen Maschinencode eines Gerätes (4) mit den Schritten: (a) Verschlüsseln eines Maschinencodes mittels eines gerätespezifischen Schlüssels, der durch ein in dem Gerät (4) enthaltenes TPM (Trusted Platform Module) -Modul (4C) bereitgestellt wird,
(b) Speichern des verschlüsselten Maschinencodes in einem Speicher (4B) des Geräts (4),
(c) wobei der gerätespezifische Schlüssel nach einer an dem Gerät (4) vorgenommenen Manipulation nicht mehr aus dem TPM-Modul (4C) auslesbar ist.
2. Verfahren nach Anspruch 1, wobei der Maschinencode (MC) durch einen Java-Byte-Code gebildet wird.
3. Verfahren nach Anspruch 1, wobei der gerätespezifische Schlüssel durch einen AIK
(Attestation Identity Key) -Schlüssel (KAiK)des TPM-Moduls (4C) gebildet wird.
4. Verfahren nach Anspruch 1, wobei ein Class-Loader (4A-1) einer Java Virtual Machine (4A) den in dem Speicher (4B) des Gerätes (4) gespeicherten verschlüsselten Maschinencode mittels des aus dem TPM-Modul (4C) ausgelesenen gerätespezifischen Schlüssels entschlüsselt und einer Ausführeinheit (4A-2) bereitstellt.
5. Verfahren nach Anspruch 1, wobei der gerätespezifische Schlüssel von dem TPM-Modul (4C) über ein Netzwerk zu einer Verschlüsselungseinheit (3) übertragen wird, die den Maschinencode (MC) mittels des gerätespezifischen Schlüssels verschlüsselt.
6. Verfahren nach Anspruch 4, wobei der entschlüsselte Maschinencode durch die Ausführeinheit (4A-2) ausgeführt oder interpretiert wird.
7. Verfahren nach Anspruch 1, wobei der Maschinencode (MC) durch MP3-Daten gebildet wird.
8. Verfahren nach Anspruch 7, wobei verschlüsselte MP3-Daten mittels eines aus dem TPM- Modul (4C) ausgelesenen gerätespezifischen Schlüssels entschlüsselt und einem MP3-Decoder bereitgestellt werden.
9. System zum Schutz gegen ein Zugriff auf einen Maschinencode eines Gerätes (4), wobei der Maschinencode (MC) mittels eines gerätespezifischen Schlüssels, der durch ein in dem Gerät (4) enthaltenes TPM- Modul (4C) bereitgestellt wird, verschlüsselt und in einem Speicher (4B) des Gerätes (4) gespeichert wird, wobei der gerätespezifische Schlüssel nach einer an dem Gerät (4) vorgenommenen Manipulation nicht mehr aus dem TPM-Modul (4C) auslesbar ist.
10. Gerät mit zugriffsgeschützten Maschinencode mit:
(a) einem Speicher (4B) zum Speichern eines verschlüsselten Maschinencodes (MC) ;
(b) einem Class-Loader (4A-1) zum Entschlüsseln des verschlüsselten Maschinencodes mittels eines aus einem TPM- Modul (4C) ausgelesenen gerätespezifischen Schlüssels; und mit (c) einer Ausführeinheit (4A-2) zum Ausführen des entschlüsselten Maschinencodes;
(d) wobei der gerätespezifische Schlüssel nach einer an dem
Gerät (4) vorgenommnen Manipulation von dem TPM-Modul (4C) gesperrt wird.
11. Gerät nach Anspruch 10, wobei der Speicher (4B) ein nicht flüchtiger Speicher ist.
12. Gerät nach Anspruch 11, wobei der nicht flüchtige Speicher (4B) eine Festplatte aufweist .
13. Gerät nach Anspruch 10, wobei die Ausführeinheit (4A-2) in einer JVM (Java Virtual Machine) vorgesehen ist.
14. Gerät nach Anspruch 10, wobei die Ausführeinheit (4A-2) ein Decoder ist.
15. Programm mit Programmbefehlen zur Durchführung des Verfahrens nach Anspruch 1 - 8.
16. Datenträger zum Speichern des Programms nach Anspruch 15
EP08803305A 2007-09-25 2008-08-28 Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes Withdrawn EP2193471A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200710045743 DE102007045743A1 (de) 2007-09-25 2007-09-25 Verfahren und System zum Schutz gegen einen Zugriff auf einen Maschinencode eines Gerätes
PCT/EP2008/061279 WO2009040207A1 (de) 2007-09-25 2008-08-28 Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes

Publications (1)

Publication Number Publication Date
EP2193471A1 true EP2193471A1 (de) 2010-06-09

Family

ID=40345035

Family Applications (1)

Application Number Title Priority Date Filing Date
EP08803305A Withdrawn EP2193471A1 (de) 2007-09-25 2008-08-28 Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes

Country Status (4)

Country Link
US (1) US8843766B2 (de)
EP (1) EP2193471A1 (de)
DE (1) DE102007045743A1 (de)
WO (1) WO2009040207A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8402448B2 (en) * 2008-09-18 2013-03-19 Infineon Technologies Ag Compiler system and a method of compiling a source code into an encrypted machine language code
EP3923165A1 (de) * 2009-11-13 2021-12-15 Irdeto B.V. System und verfahren zum schützen des java-bytecodes vor statischen und dynamischen attacken innerhalb feindlicher ausführungsumgebungen
US8417965B1 (en) * 2010-04-07 2013-04-09 Xilinx, Inc. Method and circuit for secure definition and integration of cores
US9087196B2 (en) * 2010-12-24 2015-07-21 Intel Corporation Secure application attestation using dynamic measurement kernels
CN102360412B (zh) * 2011-09-26 2014-07-02 飞天诚信科技股份有限公司 Java源代码的保护方法和系统
US9021271B1 (en) * 2011-12-27 2015-04-28 Emc Corporation Injecting code decrypted by a hardware decryption module into Java applications
CN104573425B (zh) * 2014-12-31 2018-01-30 上海格尔软件股份有限公司 一种基于对称算法和专用加载模块的Python程序模块加密方法
EP3516573A1 (de) * 2016-09-22 2019-07-31 Telefonaktiebolaget LM Ericsson (PUBL) Versionskontrolle zur sicheren datenverarbeitung
CN111159661B (zh) * 2018-11-08 2022-07-12 迈普通信技术股份有限公司 一种防止反编译方法、装置、电子设备及存储介质
EP4208798A1 (de) * 2020-09-05 2023-07-12 ICU Medical, Inc. Identitätsbasierte sichere kommunikation medizinischer vorrichtungen
US11550883B2 (en) * 2020-09-08 2023-01-10 Assured Information Security, Inc. Code protection

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10301773A (ja) * 1997-04-30 1998-11-13 Sony Corp 情報処理装置および情報処理方法、並びに記録媒体
JPH10301772A (ja) 1997-04-30 1998-11-13 Sony Corp 情報処理装置および情報処理方法、並びに記録媒体
GB2341461B (en) * 1998-09-10 2003-03-12 Ibm Program component distribution
US6477540B1 (en) * 1999-12-22 2002-11-05 Ncr Corporation Method and apparatus for using Java as a stored procedure language and as an embedded language on a client
US7516331B2 (en) * 2003-11-26 2009-04-07 International Business Machines Corporation Tamper-resistant trusted java virtual machine and method of using the same
JP2005227995A (ja) * 2004-02-12 2005-08-25 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
FR2887097A1 (fr) * 2005-06-14 2006-12-15 France Telecom Procede de protection d'un code-source en langage semi-interprete
US9171161B2 (en) * 2006-11-09 2015-10-27 International Business Machines Corporation Trusted device having virtualized registers

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2009040207A1 *

Also Published As

Publication number Publication date
US20100205459A1 (en) 2010-08-12
WO2009040207A1 (de) 2009-04-02
US8843766B2 (en) 2014-09-23
DE102007045743A1 (de) 2009-04-02

Similar Documents

Publication Publication Date Title
WO2009040207A1 (de) Verfahren und system zum schutz gegen einen zugriff auf einen maschinencode eines gerätes
EP3259698B1 (de) Autonom bootendes system mit einem sicherheitsmodul
DE102008021567B4 (de) Computersystem mit sicherem Hochlaufmechanismus auf der Grundlage einer Verschlüsselung mit symmetrischem Schlüssel
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE60303476T2 (de) Verfahren und server für eine programm-aktualisierung
DE102007057900B4 (de) Authentifikation von verdächtigen Daten unter Verwendung von Schlüsseltabellen
DE102008006759B4 (de) Prozessor-Anordnung und Verfahren zum Betreiben der Prozessor-Anordnung ohne Verringerung der Gesamtsicherheit
DE60302844T2 (de) Halbleitervorrichtung mit Verschlüsselung, Halbleitervorrichtung mit externer Schnittstelle, und Inhaltswiedergabeverfahren
DE102009041176B4 (de) Compiler-System und Verfahren zum Kompilieren eines Quellencodes zu einem verschlüsselten Maschinensprachcode
EP2006792A2 (de) Verschlüsselungs- und Entschlüsselungsverfahren und PLC-System, das diese Verfahren benutzt
DE10392528T5 (de) Microcode-Patch-Authentifizierung
DE112010004580T5 (de) Sichere Pin-Verwaltung einer für Benutzer vertrauenswürdigen Einheit
DE102015113468A1 (de) Datenverarbeitungsvorrichtung und verfahren zum sichern einer datenverarbeitungsvorrichtung gegen angriffe
EP3403214B1 (de) Verfahren und einrichtung zum bereitstellen einer kryptographischen sicherheitsfunktion für den betrieb eines geräts
EP2434424B1 (de) Verfahren zur Erhöhung der Sicherheit von sicherheitsrelevanten Online-Diensten
DE102015201298A1 (de) Verfahren zum kryptographischen Bearbeiten von Daten
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
DE102009048756A1 (de) Verfahren und Anordnung zur Verbesserung der Sicherheit von verschlüsselten Computerdaten
DE102010006432A1 (de) Verfahren und System zum Bereitstellen von EDRM-geschützten Datenobjekten
DE102014113441A1 (de) Schutz vor Software-Komponenten mittels Verschlüsselung
EP3251281B1 (de) Intrinsische authentifizierung von programcode
EP2569726B1 (de) Verfahren zum überprüfen, ob programmanweisungen von einem tragbaren endgerät ausgeführt wurden
DE102021126509B4 (de) Tragbare Chipvorrichtung und Verfahren zum Ausführen eines Softwaremodul-Updates in einer tragbaren Chipvorrichtung
EP3441898B1 (de) Verfahren und vorrichtung zum schützen einer software gegen ein unbefugtes nutzen
EP1904980A1 (de) Verfahren zum betreiben eines tragbaren datenträgers

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100209

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MT NL NO PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL BA MK RS

17Q First examination report despatched

Effective date: 20101105

DAX Request for extension of the european patent (deleted)
RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: SIEMENS AKTIENGESELLSCHAFT

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20190301