PatentDe  


Dokumentenidentifikation DE102004057490B4 22.02.2007
Titel Vorrichtung und Verfahren zum Verarbeiten eines Programmcodes
Anmelder Infineon Technologies AG, 81669 München, DE
Erfinder Lippmann, Bernhard, Dipl.-Phys., 84079 Bruckberg, DE;
Brücklmayr, Franz Josef, Dipl.-Ing., 86916 Kaufering, DE
Vertreter Schoppe, Zimmermann, Stöckeler & Zinkler, 82049 Pullach
DE-Anmeldedatum 29.11.2004
DE-Aktenzeichen 102004057490
Offenlegungstag 01.06.2006
Veröffentlichungstag der Patenterteilung 22.02.2007
Veröffentlichungstag im Patentblatt 22.02.2007
IPC-Hauptklasse G06F 9/45(2006.01)A, F, I, 20051017, B, H, DE
IPC-Nebenklasse G06F 9/42(2006.01)A, L, I, 20051017, B, H, DE   

Beschreibung[de]

Die vorliegende Erfindung bezieht sich auf eine Vorrichtung und ein Verfahren zum Verarbeiten eines Programmcodes wie sie insbesondere zur Verarbeitung von Programmcode objektorientierter Programmiersprachen eingesetzt werden können.

Softwareprogramme erfordern eine Strukturierung des Quellcodes. Eine solche Strukturierung wird von objektorientierten Programmiersprachen durch Klassendefinitionen unterstützt. Über Klassen wird erreicht, dass ein Programmcode wiederverwendet werden kann und dass ein Programm so strukturiert wird, dass die Fehlersuche und die Wartung erheblich erleichtert wird. Die Klasse ist in der objektorientierten Programmierung ein abstrakter Oberbegriff für die Beschreibung einer gemeinsamen Struktur und eines gemeinsamen Verhaltens von Objekten. Die Struktur einer Klasse wird über Attribute und das Verhalten über Methoden, auch Operation, Funktion und Prozedur genannt, definiert. Aus Klassen erzeugte Objekte werden als Exemplare oder Instanzen der Klasse bezeichnet. In manchen Programmiersprachen gibt es zu jeder Klasse ein bestimmtes Objekt, das dazu da ist, die Klasse zur Laufzeit zu repräsentieren und das für die Erzeugung von Objekten der Klasse und den Aufruf von korrekten Methoden zuständig ist.

Bei der Kompilierung eines Quelltextes wird bei manchen Programmiersprachen oder Umgebungen nicht direkt ein Maschinencode, sondern ein Zwischenprodukt, der sogenannten Byte Code oder Intermediate Language Code erstellt. Dieser Zwischencode ist in der Regel maschinenunabhängig und im Vergleich zum Quelltext und zum Maschinencode relativ kompakt.

Java ist heute eines der prominentesten Beispiele für eine Byte Code-basierte Programmiersprache. Andere Sprachen, die Byte Codes verwenden, sind beispielsweise C# oder Delphi.NET.

Eine sogenannte virtuelle Maschine, im Falle von Java die Java VM, führt den Zwischencode aus. Die Ausführung des Zwischencodes durch die virtuelle Maschine kostet Zeit. Spezielle Just-In-Time-Compiler (JIT; JIT = Just In Time) übersetzen Byte Code-Stücke einmal während der Programmausführung in entsprechende Maschinencodestücke und führen diese dann aus. Dadurch lassen sich die Ausführungszeiten, jedoch nicht die Startzeiten, oft in den Bereich von vorübersetzten Maschinencode drücken.

7 zeigt eine Gegenüberstellung eines Quellcodeprogrammes 702 und einem daraus generierten Zwischencodeprogramm 704. Der Zwischencode 704 auch Byte Code oder Intermediate Language genannt, wird durch eine Kompiliervorgang 706 aus dem Quellcode 702 erzeugt.

In dem Quellcode 702 wird eine FOR-Schleife durchlaufen, und bei jedem Durchlauf ein Zählerstand ausgegeben. Zur Ausgabe des Zählerstandes wird ein Unterprogramm oder eine Methode WriteLine aufgerufen.

Der Stack-orientierte Zwischencode 704 besteht noch nicht aus Maschinenbefehlen. Die Struktur des Quellcodes 702, aus dem der Zwischencode 704 generiert wurde, ist noch erkennbar. Insbesondere ist der Unterprogrammaufruf WriteLine und die über einen Rücksprung realisierte FOR-Schleife erkennbar.

In objektorientierten Programmiersprachen werden häufig Methoden oder Prozeduren aufgerufen, wobei es nicht möglich ist, die aufgerufene Prozedur zu bestimmen, ohne auf die dem Methodenaufruf zugeordnete Objekt-Referenz zu schauen. Zur Verwaltung der Methoden in objektorientierten Programmiersprachen werden daher Tabellen erzeugt, die eine Zuordnung zwischen klassenspezifischen Methoden aufrufen und den dazugehörigen Prozeduren aufweisen. Bei Aufruf sogenannter virtueller Methoden speichert der Compiler nicht die Adresse der Methode im Programmcode, sondern er verwaltet diese Methoden in einer separaten Tabelle, der sogenannten Virtuellen Methoden Tabelle (VMT; VMT = virtuell method table). Im dazugehörigen Objekt wird lediglich die Adresse der Virtuellen Methoden Tabelle gespeichert. Der Compiler sorgt dafür, dass bei einer Ausführung des Programms für jede Klasse eine eigene VMT im Speicher angelegt wird. Alle virtuellen Methoden dieser Klasse werden in dieser Tabelle, zusammen mit deren Adresse, eingetragen. An der Stelle des Aufrufs virtueller Methoden erzeugt der Compiler Zwischenprogrammcode, der in der VMT nachschaut, welche Methode für das jeweilige Objekt nun tatsächlich aufgerufen werden soll. Dabei wird nicht der Datentyp der Referenz (Klasse), sondern der Datentyp des Objektes verwendet, um die VMT zu identifizieren. Der Aufruf der Methode führt also über die VMT immer zu der korrekten Methode. Dieser Aufruf wird auch als späte Bindung bezeichnet, weil das auszuführende Programm in der Laufzeit die Adresse der Methode ermittelt.

8 zeigt die Struktur einer Virtuellen Methoden Tabelle und ihr Verhältnis zu der Objektinstanz. Die Virtuellen Methoden Tabelle 812 ist eine Nur-Lese-Nachschlagtabelle, die ein Feld von Zeigern aufweist und für jede Klasse eines Quellprogrammes bei der Kompilierung des Quellcodes erzeugt und in dem Befehlsraum des Programmierers gespeichert wird.

Die Virtuellen Methoden Tabelle 812 weist vier Methoden auf, die einer Klasse zugeordnet sind. Bei den Methoden handelt es sich um die Methoden VirtualMethod 1 bis 4. Ein Methodenaufruf im Quellprogramm 813 wird im Zwischencode als ein Zeiger 814 dargestellt, der auf das Objekt 816 zeigt, von dem aus die Methode aufgerufen wurde. Das Quellprogramm 813 weist einen Methodenaufruf für die Methode VirtualMethod1 auf. Der Ausdruck VirtualMethod1 kann ein Index oder Offset sein, der dazu dient den tatsächlichen Ort der Unterprogrammadresse zu ermitteln. Das Objekt 816 weist einen VMT Zeiger „VMT Pointer" auf, der auf die Virtuellen Methoden Tabelle 812 zeigt. Die Virtuellen Methoden Tabelle 812 ermöglicht es somit, dass bei einem Methodenaufruf die korrekte Methode ausgewählt wird. Dies ist wichtig, da es für unterschiedliche Klassen unterschiedliche Methoden geben kann, für die jedoch der gleiche Methodenname vergeben wurde. Ohne die Virtuellen Methoden Tabelle 812 ist es deshalb nicht möglich, einen Methodenaufruf die korrekte Methode zuzuordnen.

Eine Dynamischen Methoden Tabelle DMT (DMT; DMT = dynamic method table) wird für jede Klasse erzeugt, die neue dynamische Methoden oder vererbte dynamische Methoden deklariert. Die Dynamischen Methoden Tabelle ist viel kleiner als die Virtuellen Methoden Tabelle und speichert nur spezielle Informationen über dynamische Methoden einer Klasse.

9 zeigt die Struktur einer Dynamischen Methoden Tabelle DMT 912b und ihr Verhältnis zu der Objektinstanz 816 und der Virtuellen Methoden Tabelle 912a.

10 zeigt die .NET Technologie des Softwareherstellers Microsoft im Detail. .NET ist ein Satz von Softwaretechnologien, der neben einer virtuellen Laufzeitumgebung aus einem Rahmenwerk von Klassenbibliotheken und Diensten besteht, die als Basis für Eigenentwicklungen dienen. Die sogenannte Common-Language Specification definiert eine gemeinsame Untermenge von Binärcode, der von der virtuellen Laufzeitumgebung in den Maschinencode einer Zielmaschine übersetzt und von der Zielmaschine ausgeführt werden kann. Somit ist es möglich, .NET mit verschiedenen Sprachen zu programmieren. Als Sprachen stehen beispielsweise Visual Basic.NET, Visual C#.NET oder Visual C++.NET zur Verfügung. Ein in diesen Sprachen erstelltes Quellprogramm 702 wird von einem Compiler 706 in einem Zwischencode 704, dem sogenannten Binärcode gemäß der Common Language Specification umgewandelt. Durch verschiedene Techniken wird versucht, den negativen Einfluss der Runtime eines Programmes auf die Programmgeschwindigkeit möglichst klein zu halten. Dazu steht ein Just In Time Compiler JIT 1022 (JIT; JIT = Just In Time) zur Verfügung, der den Binärcode 704 in einen maschinenausführbaren Maschinencode 1024 übersetzt. Der Just In Time-Compiler bietet einen Mittelweg zwischen Interpretation und Kompilierung des Binärcodes 704. Ferner können weiterhin Programmiersprachen eingesetzt werden, bei denen der Compiler direkt den Maschinencode 1026 erzeugt. Dieser Maschinencode 1026 wird dann auf dem Betriebssystem, unter Umgehung des Zwischenschrittes über den Binärcode 704 ausgeführt.

Wie aus 7 ersichtlich ist, repräsentiert der Quellcode oder Sourcecode und insbesondere die Objektstrukturen im Code das geistige Eigentum und den ökonomischen Wert eines Softwareprogrammes. Performance und Code Effektivität sind direkt von den optimalen Definitionen von Klassen und Objekten abhängig. Der Zwischencode enthält immer noch die Daten und Objektstrukturen des Quellcodes. Objektorientierte Hochsprachen, die in Form von Zwischencode vertrieben werden, wie Java, C#, Delphi.NET bieten daher einen geringeren Schutz gegen Disassemblierung als eine 100 % Compilersprache.

Im Unterschied zu der bisherigen Windows Umgebung, in der ein Anwender einen ausführbaren Maschinencode als *.exe Datei erhalten hat, wird in der neuen .NET Umgebung ein Zwischencode an den Anwender ausgeliefert. Im Maschinencode der *.exe Datei, dem sogenannten Native Code, ist eine Verbindung zur Hochsprachendatenstruktur weitestgehend aufgelöst. Es besteht somit kein direkter Bezug zwischen dem Maschinencode und Quellcodeobjekten, Datenstrukturen und Methoden. Somit wurde in der bisherigen Windowsumgebung durch den Kompilierprozess das geistige Eigentum des Softwareentwicklers geschützt, da der Nutzer der *.exe Datei keine Kenntnis von internen Programmstrukturen erhalten konnte.

In der neuen .NET-Umgebung ist das geistige Eigentum des Softwareentwicklers nicht mehr durch einen Kompiliervorgang geschützt, da in der .NET-Umgebung anstelle des Maschinencodes Binärcode 704 an den Kunden ausgeliefert wird.

Durch die Auslieferung von Zwischencode läuft ein Softwarehersteller somit Gefahr, dass ein Anwender des Zwischencodes Reengineering betreibt und somit in der Lage versetzt wird, die verwendete Software selber herzustellen oder Datenstrukturen nachzubilden und zu vertreiben.

Bei großen Programmen bietet ein Umbenennen von Unterprogrammaufrufen bereits einen Schutz gegenüber einer Rekonstruktion des Originalquellcodes. Bei geringeren Sicherheitsanforderungen kann dies bereis als ein ausreichender Schutz des Quellcodes angesehen werden.

Die Schrift von Hawblitzel, C. et al.; SLK: A Capability System Based on Safe Language Technology; Department of Computer Science, Cornell University; Internal Memo, March 1997; S 1-20 befasst sich mit einer Technologie der sicheren Sprachen, die es einer Mehrzahl von Sicherheitsdomänen ermöglicht, innerhalb eines einzigen Adressraums nebeneinander zu existieren. Dies wird durch sogenannte „Capabilities" ermöglicht. Die Capabilities sind in einer C-Liste angeordnet. Jede Capability enthält eine Adresse eines Objekts und eine Beschreibung der Zugriffsrechte eines Teilprozesses auf ein Objekt. Einem gerade ausgeführten Teilprozess ist eine C-Liste zugeordnet, wobei der Teilprozess Indizes in die C-Liste als Objektreferenz benutzt.

US 2001/0005901 A1 beschreibt eine Sicherheitsvorrichtung, die mit einem Empfänger kooperiert. Dazu ist es erforderlich, dass eine Schnittstelle zwischen der Sicherheitsvorrichtung und dem Empfänger konfiguriert ist. Dies kann mit Hilfe eines Zeigers erfolgen, der auf eine Stelle verweist, in der eine Software zur Konfiguration der Schnittstelle enthalten ist. Der Zeiger ist unkodiert und veröffentlicht.

Es ist die Aufgabe der vorliegenden Erfindung, eine Vorrichtung und ein Verfahren zum Verarbeiten eines Programmcodes zu schaffen, die einen Schutz des in dem Programmcode enthaltenen geistige Eigentums ermöglichen.

Diese Aufgabe wird durch eine Vorrichtung zum Verarbeiten gemäß Anspruch 1 und ein Verfahren zum Verarbeiten gemäß Anspruch 11 und ein Computerprogramm gemäß Anspruch 17 gelöst.

Der vorliegenden Erfindung liegt die Erkenntnis zugrunde, dass eine Rekonstruktion eines ursprünglichen Quell-Programmcodes, bzw. der verwendeten Daten oder Objektstrukturen nur dann sinnvoll möglich ist, wenn die Zuordnungsvorschrift zwischen Unterprogrammaufrufen und Unterprogrammen bekannt ist. Ist die Zuordnung zwischen Unterprogrammaufrufen und Unterprogrammen aufgebrochen, so ist das geistige Eigentum eines Programmcodes geschützt, da keine Rückschlüsse auf die Algorithmik, die Daten-Modellierung oder die Objektzuordnung in einem Programmcode möglich sind.

Im folgenden wird Quelltext auch als Quellcode oder Quell-Programmcode bezeichnet. Quelltext ist beispielsweise ein in C oder Java geschriebenes Programm. Unter den Begriff Zwischencode fallen die Bezeichnungen Byte Code, Intermediate Language Code, Binärcode und Programmcode. Zwischenprogrammcode ist Code für interne Abläufe, beispielsweise zur Ermittlung einer zu rufenden Prozedur. Maschinencode ist der direkt von der Zielplattform ausführbare Code.

Gemäß dem erfindungsgemäßen Ansatz wird ein Zugriff auf eine Zuweisungstabelle, die die Zuordnungsvorschrift zwischen Unterprogrammaufrufen und Unterprogrammen aufweist, dadurch eingeschränkt, dass die Zuweisungstabelle in einem Container abgelegt wird, der den Zugriff auf die Zuweisungstabelle einschränkt. Der Container kann dabei in Software oder in Hardware ausgeführt werden.

Im Gegensatz zu dem bisher bekannten Stand der Technik wird gemäß der vorliegenden Erfindung die Zuweisungstabelle als ein wesentlicher Bestandteil des Kompiliervorganges eines Programmcodes nicht mehr direkt im Sourcecode eingebettet sondern in ein Sicherheitsmodul ausgelagert. Dadurch wird ein direkter Zugriff auf die Zuweisungstabelle unterbunden. Zugriffe auf die Zuweisungstabelle müssen über das Sicherheitsmodul erfolgen.

Der Vorteil der vorliegenden Erfindung liegt darin, dass das geistige Eigentum eines Softwareentwicklers auch bei objektorientierten Hochsprachen, die in Form von Zwischencodes vertrieben werden, geschützt werden kann, da der erfindungsgemäße Ansatz einen Schutz gegen Disassemblierung bietet. Der erfindungsgemäße Ansatz kann dabei sowohl bei bestehenden objektorientierten Hochsprachen als auch in der MS.NET Technologie eingesetzt werden.

Ferner sind für die Erweiterungen der Sicherheit des geistigen Eigentums keine Zusatzaufwendungen erforderlich. Eine Klassenrekonstruktion mittels einer Analyse des Maschinencodes ist nicht möglich, da keine eindeutige Korrelation zwischen einer Klassendefinition und einem Unterprogramm erkennbar ist.

Gemäß einem Ausführungsbeispiel wird die Zuweisungstabelle in einem Sicherheitsprozessor oder einem Sicherheitsbaustein angeordnet. Der Sicherheitsprozessor kann ein Trusted Platform Module TPM oder eine Smartcard sein. In diesem Fall wird beispielsweise zusammen mit dem Programmcode eine Chipkarte an einen Anwender ausgeliefert, wobei die Chipkarte die Zuweisungstabelle enthält. Der Programmcode ist nur zusammen mit der Chipkarte ausführbar, da die Zuweisungstabelle die Zuordnung zwischen einem Unterprogrammaufruf und dem dazugehörigen Unterprogramm aufweist. Ein Zugriff auf die Daten der Zuweisungstabelle in der Chipkarte, beispielsweise durch den Anwender des Programmcodes ist nicht möglich. Auf diese Weise ist es dem Anwender nicht möglich, den ursprünglichen kompletten Programmcode zu rekonstruieren.

Gemäß einem weiteren Ausführungsbeispiel ist die Einrichtung zum Verwenden des Programmcodes ausgebildet, um die Berechtigungsinformation in Form einer Anfragesequenz bereitzustellen. Das Sicherheitsmodul ist ferner ausgebildet, um die Anfragesequenz auszuwerten und, um abhängig von der Auswertung die, dem Unterprogrammaufruf entsprechenden Unterprogrammdaten bereitzustellen. Eine Anfragesequenz kann eine Historie sein, welche Anfragen in der Vergangenheit enthält, um daraus zu ermitteln welche Elemente in der Zukunft angefragt werden können.

Gemäß einem Ausführungsbeispiel wird ein Security Compiling durchgeführt. Dabei wird ein exe-file zusammen mit dem Securitymodul generiert. Die Zuweisungstabelle darf dabei jedoch nicht direkt auf die Zielplattform transportiert werden.

Eine hardwarebasierte Lösung des Sicherheitsmoduls bietet einen hohen Schutz gegenüber einer Disassemblierung des Programmcodes. Für viele Anwendungen sind bereits Geräte erforderlich, die ein zusätzliches Sicherheitsmodul, beispielsweise in Form einer Chipkarte benötigen. In diesem Fall ist eine Anordnung der Zuweisungstabelle in diesem schon bereits vorhandenen Sicherheitsmodul mit keinen Zusatzkosten verbunden.

Alternativ kann das Sicherheitsmodul in Software ausgeführt sein. In diesem Fall können die Daten der Zuweisungstabelle so verschlüsselt werden, dass ein Anwender, an den der Programmcode mit der verschlüsselten Zuweisungstabelle ausgeliefert wurde, die verschlüsselten Daten der Zuweisungstabelle nicht entschlüsseln kann und somit keine Erkenntnis über die in dem Programmcode enthaltenen Algorithmen, Methoden und Objektstrukturen erlangen kann. Eine Ausführung der Sicherheitsmodule in Software ist sehr kostengünstig, da keine zusätzliche Hardware erforderlich ist und der Vertriebe des Programmcodes zusammen mit der Zuweisungstabelle sehr einfach, beispielsweise über Internet, möglich ist.

Der erfindungsgemäß Ansatz bietet einem Softwareentwickler die Möglichkeit zu entscheiden, ob er einen hohen Schutz seines geistigen Eigentums wünscht und daher auf eine hardwarebasierte Ausführung des Sicherheitsmoduls zurückgreift oder ob eine kostengünstigere und einfach zu handhabende Softwarelösung ausreichend ist. Bei dieser Entscheidung kann mitberücksichtigt werden, wie hoch der Aufwand für ein Reengineering eines ausgelieferten Programmcodes ist.

Der erfindungsgemäße Ansatz eignet sich besonders auch für Programme mit einfachen Programmstrukturen, beispielsweise bei Anwendungen für mobile Endgeräte wie Mobiltelefone, bei denen Reengineering aufgrund der einfachen Programmstrukturen leicht möglich ist. Ist der Aufwand für ein Reengineering aufgrund einer komplexen Programmstruktur bereits hoch oder wird nur ein geringer Schutz benötigt, so bietet sich die Ausführung des Sicherheitsmoduls in einer Softwarelösung an. Ist dagegen einer hoher Schutz erforderlich, so bietet sich eine hardwarebasierte Lösung an.

Gemäß dem erfindungsgemäßen Ansatz erfolgt der Schutz des geistigen Eigentums eines Softwareentwickler durch eine modifizierte Compilertechnologie. Dabei werden die Daten der Zuweisungstabelle während des Kompiliervorganges eines Sourcecodes in den Sicherheitsmodul abgelegt. Dies kann beispielsweise durch einen Einsatz eines zusätzlichen Sicherheits-Compilers erfolgen. Dabei wird der eigentliche Compiler gestoppt sobald zu schützende Programmstrukturen kompiliert werden sollen und es wird der Sicherheits-Compiler aufgerufen, der diesen Teil des Programmcodes kompiliert und die Daten der Zuweisungstabelle so extrahiert, dass sie sogleich oder später in dem Sicherheitsmodul abgelegt werden können. In diesem Fall ist ein modifizierter Compiler erforderlich.

Um bereits vorhandene Compilertechnologien weiter verwenden zu können, kann ein zusätzlicher Pre-Compiler eingesetzt werden. Dieser Vorcompiler hat die Aufgabe, die in einem zu Kompilierenden Sourcecode vorhandenen Unterprogrammaufrufe zu modifizieren und die Zuweisungstabelle zu erstellen, so dass anschließend der vorkompilierte Sourcecode mit einem herkömmlichen Compiler kompiliert werden kann, um den Zwischencode zu erstellen.

Der Einsatz eines Vorcompilers hat auch den Vorteil, dass die im Sourcecode verwendeten Namen von Unterprogrammaufrufen verändert werden können. Typischerweise sind im Sourcecode Nomenklaturen verwendet, die auf die zugehörigen Unterprogramme hinweisen. Werden solche Namen durch willkürliche Namen ausgetauscht, so bietet dies bereits einen ersten Schutz gegenüber einer Rekonstruktion des ursprünglichen Programmcodes.

Gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung weist die Vorrichtung einen Postprozessor auf, der Namen austauscht und Tabellen in eine Lade-Datei für einen Sicherheitsmodul-Transfer lädt. Der Postprozessor kann nach der Kompilierung eingesetzt werden.

Gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist die Einrichtung zum Verwenden des Programmcodes ein Compiler, der aus einem Zwischencode einen ausführbaren Maschinencode erstellt. Gemäß einem weiteren Ausführungsbeispiel ist die Einrichtung zum Verwenden des Programmcodes ein Interpreter oder eine virtuelle Maschine, die ausgebildet ist, um den Zwischencode in Form des Programmcodes zu kompilieren und direkt auszuführen.

Bevorzugte Ausführungsbeispiele der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:

1 ein Blockschaltbild einer Vorrichtung zum Verarbeiten eines Programmcodes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

2 ein Ablaufdiagramm eines Verfahren zum Verarbeiten eines Programmcodes gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung;

3 ein weiteres Ablaufdiagramm eines Verfahrens zum Verarbeiten eines Programmcodes gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung;

4 eine schematische Darstellung einer Erzeugung eines Maschinencodes aus einem Quellcode gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;

5 eine schematische Darstellung der Zusammenhänge zwischen einem Unterprogrammaufruf und Zuweisungsdaten in einem Sicherheitsmodul gemäß der vorliegenden Erfindung;

6 eine schematische Darstellung einer Einbindung des Sicherheitsmoduls in eine virtuelle Maschine;

7 Gegenüberstellung eines Quellcodes und eines Zwischencodes gemäß dem Stand der Technik;

8 Struktur einer virtuellen Methoden Tabelle gemäß dem Stand der Technik;

9 Struktur einer dynamischen Methoden Tabelle gemäß dem Stand der Technik; und

10 Detaildarstellung der .NET Technologie im Detail.

In der nachfolgenden Beschreibung der bevorzugten Ausführungsbeispiele der vorliegenden Erfindung werden für die in den verschiedenen Zeichnungen dargestellten und ähnlich wirkenden Elemente gleiche oder ähnliche Bezugszeichen verwendet, wobei eine wiederholte Beschreibung dieser Elemente weggelassen wird.

1 zeigt ein Blockschaltbild einer Vorrichtung zum Verarbeiten eines Programmcodes gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Vorrichtung zum Verarbeiten eines Programmcodes ist ausgebildet, um einen Programmcode 104 zu empfangen. Die Vorrichtung zum Verarbeiten weist ein Sicherheitsmodul 113 mit einer Zuweisungstabelle auf, wobei die Zuweisungstabelle eine Zuordnung zwischen Unterprogrammaufrufen, die in dem Programmcode 104 enthalten sind, und den zugehörigen Unterprogrammen ermöglicht. Der Programmcode 104 wird in einer Einrichtung 122 zum Verwenden eines Programmcodes abgearbeitet. Die Einrichtung 122 zum Verwenden eines Programmcodes ist ausgebildet, um ansprechend auf einen Unterprogrammaufruf in dem Programmcode 104 eine Unterprogrammanfrage 123a an das Sicherheitsmodul 113 mit der Zuweisungstabelle bereitzustellen und aus der Zuweisungstabelle Unterprogrammdaten 123b wiederzugewinnen, um dem Unterprogrammaufruf in dem Programmcode 104 das zugehörige Unterprogramm zuordnen zu können. Das Unterprogramm kann in dem Programmcode 104 enthalten sein oder in zusätzlichen Bibliotheken abgelegt sein. Alternativ können die Unterprogrammdaten 123b das Unterprogramm enthalten.

Das Sicherheitsmodul 113 ist ein Container, das die Zuweisungstabelle enthält, und kann entweder in Hardware oder in Software ausgeführt sein. Ein Zugriff auf die Zuweisungstabelle in dem Sicherheitsmodul 113 ist eingeschränkt, um zu verhindern, dass die Daten der Zuweisungstabelle von Angreifern, die versuchen, den Quellcode aus dem Programmcode 104 zurückzugewinnen, ausgelesen werden können. Um die Unterprogrammdaten 123b aus dem Sicherheitsmodul wiederzugewinnen, ist die Einrichtung 122 zum Verwenden eines Programmcodes mit Berechtigungsinformationen ausgestattet. Die Berechtigungsinformationen können dazu dienen, um einen Zugang zu dem Sicherheitsmodul 113 zu erhalten oder um die in dem Sicherheitsmodul 113 gespeicherten Daten der Zuweisungstabelle zu entschlüsseln.

Beispielsweise kann die Berechtigungsinformation ein Schlüssel sein, der von der Einrichtung 122 zum Verwenden eines Programmcodes zusammen mit der Unterprogrammanfrage 123a an das Sicherheitsmodul 113 bereitgestellt wird. Das Sicherheitsmodul 113 kann ausgebildet sein, um den empfangenen Schlüssel zu prüfen und abhängig von der Prüfung die angeforderten Unterprogrammdaten 123b bereitzustellen bzw. den Zugriff auf die Zuweisungstabelle zu verweigern, wenn der Schlüssel falsch ist.

Sind die Daten der Zuweisungstabelle in dem Sicherheitsmodul 113 in verschlüsselter Form abgelegt, so kann die Berechtigungsinformation ein Entschlüsselungswert sein, der es der Einrichtung 122 zum Verwenden eines Programmes ermöglicht, die empfangenen und verschlüsselten Unterprogrammdaten 123b zu entschlüsseln. Liegen der Daten der Zuweisungstabelle in verschlüsselter Form vor, so kann das Sicherheitsmodul 113 eine einfache Speichereinrichtung zum Speichern der verschlüsselten Zuweisungsdaten sein.

Die Berechtigungsinformation wird während bzw. nach der Bereitstellung des Programmcodes und der Zuweisungstabelle von dem Softwareentwickler bzw. dem Vertreiber des Programmcodes definiert und im Programmcode und dem Sicherheitsmodul bzw. der Zuweisungstabelle so festgelegt, dass es der Einrichtung zum Verwenden ermöglicht wird, die Daten der Zuweisungstabelle bei der Ausführung des Programmcodes zurückzugewinnen, jegliche andere Zugriffe auf die Daten der Zuweisungstabelle jedoch verhindert werden.

Gemäß einem Ausführungsbeispiel ist die Vorrichtung zum Verarbeiten eines Programmcodes ausgebildet, um einen Programmcode 104 in Form eines Zwischencodes oder Byte Codes zu verarbeiten. Der Zwischencode wird durch einen Kompiliervorgang aus einem Quellcode erzeugt. Bei dem Kompiliervorgang wird neben dem Programmcode 104 auch die Zuweisungstabelle erzeugt. Die Einrichtung 122 zum Verwenden des Programmcodes 104 kann ein weiterer Compiler sein, der den Zwischencode 104 in einen maschinenlesbaren Code umwandelt. Die Einrichtung 122 zum Verwenden eines Programmcodes kann auch ein Interpreter oder eine virtuelle Maschine sein, die ausgebildet ist, um den Zwischencode 104 zu interpretieren und auszuführen.

Handelt es sich bei dem Programmcode 104 um einen Programmcode einer objektorientierten Sprache, so kann die Zuweisungstabelle eine Virtuellen Methoden Tabelle oder eine dynamische Methoden Tabelle DMT sein. Bei den Unterprogrammaufrufen kann es sich in diesem Fall um Methodenaufrufe handeln. Ebenso fallen unter den Begriff Unterprogrammaufrufe alle Arten von Prozeduraufrufen oder Funktionsaufrufen, bei denen zur Ausführung des Unterprogramms ein Programmsprung zu der Speicherstelle des Unterprogramms erforderlich ist.

2 zeigt ein Ablaufdiagramm zur Erstellung eines Maschinenprogrammcodes aus einem Quellcode unter Verwendung des erfindungsgemäßen Ansatzes. Der Quellcode 202 ist in diesem Ausführungsbeispiel ein Hochsprachenprogramm. Durch einen ersten Kompiliervorgang 206 wird aus dem Quellcode 202 der Programmcode 104, in diesem Fall ein Zwischenprogrammcode und Daten der Zuweisungstabelle 212 erzeugt. Die Zuweisungstabelle 212 wird in dem Sicherheitsmodul 113 angeordnet. In einer Einrichtung zum Verwenden eines Programmcodes (nicht gezeigt in 2) erfolgt ein zweiter Kompiliervorgang 222, bei dem aus dem Zwischenprogrammcode 104 unter Verwendung 223 der Daten der Zuweisungstabelle 212 in dem Sicherheitsmodul 113 ein Maschinenprogrammcode 224 erzeugt wird. Bei dem zweiten Kompiliervorgang kann es sich um eine Interpretation handeln. Dabei fließt Runtime-Information ein, beispielsweise bei Verwendung von Virtuellen Methoden.

Gemäß diesem Ausführungsbeispiel erfolgt bei der Codegeneration, d.h. der Erstellung des Zwischencodes aus dem Quellcode, eine Abtrennung der Klasseninformation „class-info" von dem Code. Der Zwischencode wird mittels eines Compilers generiert. Bei der Erstellung des Maschinencodes aus dem Zwischencode während der Runtime oder Loadtime erfolgt ein Einfügen von Sicherheitsmodul-Abfragen. Die Erstellung des Maschinencodes erfolgt mittels einem Interpreter/JIT. Bei der Runtime-Ausführung des Maschinencodes erfolgt bei einem Methodenaufruf eine Sicherheitsmodul-Abfrage 250.

Gemäß einem weiteren Ausführungsbeispiel ist die Einrichtung zum Verwenden des Programmcodes ausgebildet ist, um Maschinencode auszuführen und, um Code zur Erstellung und Auswertung von Unterprogrammanfragen bereitzustellen.

Das Anordnen der Zuweisungstabelle 212 in dem Sicherheitsmodul 113 bzw, ein Verschlüsseln der Daten der Zuweisungstabelle 212 kann automatisch bereits während des ersten Kompiliervorgangs 206 erfolgen. Alternativ kann die Zuweisungstabelle 212 erst nachfolgend verschlüsselt werden oder nachfolgend in dem Sicherheitsmodul 113 angeordnet werden. Der erste Kompiliervorgang 206 erfolgt bei dem Softwareentwickler bzw. Vertreiber des Zwischenprogrammcodes 104.

Wird die Zuweisungstabelle in verschlüsselter Form bereitgestellt, so kann die verschlüsselte Zuweisungstabelle Teil des Pogrammcodes 104 sein oder alternativ als ein zweites Programm an den Anwender ausgeliefert werden. Alternativ kann die Zuweisungstabelle erst beim Anwender des Programmcodes 104 in dem Sicherheitsmodul 113 angeordnet werden. In diesem Fall können die Daten der Zuweisungstabelle in einem gesicherten, selbstextrahierenden zweiten Programm ausgeliefert werden, das ausgebildet ist, um bei seiner Installation die Daten der Zuweisungstabelle in dem Sicherheitsmodul abzulegen, so dass der Anwender des Programmcodes 104 keinen Zugriff auf die Zuweisungstabelle hat.

3 zeigt ein Ablaufdiagramm eines weiteren Ausführungsbeispieles zum Erstellen des Maschinenprogrammcodes 224 aus dem Quellcode 202. Gemäß diesem Ausführungsbeispiel wird der Zwischenprogrammcode 104 nicht direkt aus dem Quellcode 202 erzeugt, sondern es wird zuvor ein Vor-Programmcode 302' aus dem Quellcode 202 generiert. Dazu wird der Quellcode 202 in einem Vor-Kompiliervorgang 306' kompiliert. Bei dem Vor-Kompiliervorgang 306' wird sowohl der Vor-Programmcode 302' als auch die Zuweisungstabelle 212 erzeugt. Aus dem Vor-Programmcode 302' wird durch den ersten Kompiliervorgang 206 der Zwischenprogrammcode 104 erzeugt.

Während des Vor-Kompiliervorgangs 306' können Unterprogrammaufrufe des Quellcodes 202 umbenannt werden, so dass Unterprogrammaufrufe in dem Vor-Programmcode 302' keinen namentlichen Bezug zu den aufzurufenden Unterprogrammen aufweisen.

4 zeigt eine Anordnung der Zuweisungstabelle 212 in Form einer virtuellen Methoden Tabelle oder einer dynamischen Methoden Tabelle innerhalb eines Sicherheitsmoduls, beispielsweise einem Sicherheitsbaustein wie einem TPM oder einer Chipkarte. Die Zuweisungstabelle 212 ist in dem Sicherheitsbaustein 113 gespeichert. Ein Methodenaufruf 414 „Call M1" im Sourcecode 202 weist eine Referenz 415 auf, die ein Parameter des Calls ist. Die Referenz 415 wird dem Call übergeben und weist einen Zeiger auf die zugehörigen Objektklassendefinition 416a, b des Methodenaufrufes 414 auf. Der Methodenaufruf 414 im Sourcecode hat im Zwischencode die Unterprogrammanfrage 123a zur Folge, die an die Zuweisungstabelle 212 gestellt wird. Ansprechend auf die Unterprogrammanfrage 123a stellt das Sicherheitsmodul 113 Unterprogrammdaten 123b bereit.

Bei den Unterprogrammdaten 123b handelt es sich um einen Zeiger auf das, dem Unterprogrammaufruf 414 M1 entsprechende Unterprogramm ml.

Gemäß diesem Ausführungsbeispiel werden die Klassenstrukturen unter Nutzung eines einzigartigen Methodenzeigers m(i) umdefiniert. Dieser Methodenpointer m(i) ermöglicht ein Laden der zugehörigen Methode auf einer unsicheren Plattform, die gegen Reverse Engineering nicht geschützt ist, über die geschützte Zuweisungstabelle in Form der VMT bzw. DMT. In diesem Zusammenhang kann die Vorrichtung zum Verarbeiten eines Programmcodes als „Protected Byte Code Compiler" angesehen werden.

5 veranschaulicht den Zusammenhang zwischen einem Unterprogrammaufruf 432 und den, in dem Sicherheitsmodul 113 angeordneten Zuweisungstabellendaten, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

In dem Unterprogrammaufruf 432 wird die Methode TextOut, die dem Objekt MyListBox zugeordnet ist, aufgerufen. Im Zwischenprogramm wurde der Name der Methode Text Out umbenannt in M1. Diese Umbenennung kann in einem Vor-Kompiliervorgang erfolgen. Die Zuweisungstabelle in dem Sicherheitsmodul 113 verweist wiederum auf ein dem Methodenaufruf m[i] entsprechende Methode m(i). Dies hat zur Folge, dass bei dem Unterprogrammaufruf MyListBox.TextOut die Methode m(i) aufgerufen wird.

Gemäß diesem Ausführungsbeispiel wird die VMT und DMT in dem Sicherheitsbaustein 113 während des Vor-Kompiliervorganges, also der Byte Codegenerierung erzeugt. Dabei wird der Methodenaufruf „Call M1" durch einen gesicherten Methodenaufrufprozess (M1->m[i]) ersetzt, der Objekte in sichere Objekte umwandelt. Dadurch wird die Klasseninformation ersetzt. Der Methodenaufruf erfolgt anschließend durch die in dem Sicherheitsbaustein 113 gespeicherte virtuellen Methoden Tabelle bzw. dynamische Methoden Tabelle.

6 veranschaulicht eine Erzeugung des Maschinencodes 224 während einer „On-The-Fly"-Kompilierung, bei der der Zwischencode 104 erst direkt bei der Ausführung übersetzt wird. Dabei wird der Methodenaufruf über die virtuelle Methoden Tabelle bzw. die dynamische Methoden Tabelle 212 in dem Sicherheitsbaustein 113 während der „On-The-Fly"-Kompilierung gelöst. Die erfindungsgemäße Methode ist dabei für alle objektorientierten Sprachen wie beispielsweise Java, C++, Pascal oder .NET anwendbar.

Abhängig von den Gegebenheiten kann das erfindungsgemäße Verfahren zum Verarbeiten eines Programmcodes in Hardware oder in Software implementiert werden. Die Implementation kann auf einem digitalen Speichermedium, insbesondere einer Diskette oder CD mit elektronisch auslesbaren Steuersignalen erfolgen, die so mit einem programmierbaren Computersystem zusammenwirken können, dass das entsprechende Verfahren ausgeführt wird. Allgemein besteht die Erfindung somit auch in einem Computer-Programm-Produkt mit einem, auf einem maschinenlesbaren Träger gespeicherten Programmcode zur Durchführung des erfindungsgemäßen Verfahrens, wenn das Computer-Programm-Produkt auf einem Rechner abläuft. In anderen Worten ausgedrückt kann die Erfindung somit als ein Computer-Programm mit einem Programmcode zur Durchführung des Verfahrens realisiert werden, wenn das Computer-Programm auf einem Computer abläuft.

104
Programmcode
113
Sicherheitsmodul mit Zuweisungstabelle
122
Einrichtung zum Verwenden eines Programmcodes
123a
Unterprogrammfrage
123b
Unterprogrammdaten
202
Quellcode
206
Erster Compiliervorgang
212
Zuweisungstabelle
222
Zweiter Compiliervorgang
223
Unterprogrammanfrage
224
Maschinenprogrammcode
250
Sicherheitsmodulabfrage
302'
Vor-Programmcode
306'
Vor-Compiliervorgang
414
Unterprogrammaufruf im Quellcode
415
Unterprogrammaufruf
416a, b
Objektdefinitionen
702
Quellcode
704
Zwischencode
706c
Erster Compiliervorgang
812
Zuweisungstabelle
823
Quellprogramm
814
Unterprogrammaufruf
816
Objektdefinition
912a
VMT
912b
DMT
1220
JIT Compiler
1024
Maschinencode


Anspruch[de]
Vorrichtung zum Verarbeiten eines Programmcodes mit einer Mehrzahl von Unterprogrammaufrufen, mit folgenden Merkmalen:

einer Maschine (122), die ausgebildet ist, um einen empfangenen Programmcode (104) zu verwenden; und

einem zusätzlichen, hardwarebasierten Sicherheitsmodul (113), das eine Zuweisungstabelle (112) mit Unterprogrammdaten (123b) aufweist, wobei ein Zugriff auf die Zuweisungstabelle in dem Sicherheitsmodul eingeschränkt ist und wobei die Unterprogrammdaten einen Verweis auf ein, dem Unterprogrammaufruf entsprechendes Unterprogramm aufweisen;

wobei die Maschine mit einer Berechtigungsinformation ausgestattet ist und ausgebildet ist, um ansprechend auf einen Unterprogrammaufruf eine Unterprogrammdatenanfrage (123a) mit der Berechtigungsinformation an das Sicherheitsmodul bereitzustellen;

wobei das Sicherheitsmodul ferner ausgebildet ist, um die Berechtigungsinformation zu prüfen und um abhängig von der Prüfung die, dem Unterprogrammaufruf entsprechenden Unterprogrammdaten an die Maschine bereitzustellen; und

wobei die Maschine ausgebildet ist, um unter Verwendung der Unterprogrammdaten das, dem Unterprogrammaufruf entsprechende Unterprogramm auszuführen.
Vorrichtung gemäß Anspruch 1, wobei die Unterprogrammdaten in der Zuweisungstabelle (112) in verschlüsselter Form angeordnet sind, und wobei die Maschine (122) ausgebildet ist, um die Unterprogrammdaten (123b) unter Verwendung der Berechtigungsinformation zu entschlüsseln. Vorrichtung gemäß einem der vorangegangenen Ansprüche, wobei die Maschine (122) ausgebildet ist, um die Berechtigungsinformation in Form einer Anfragesequenz bereitzustellen, und wobei das Sicherheitsmodul ferner ausgebildet ist, um die Anfragesequenz auszuwerten, um abhängig von der Auswertung die, dem Unterprogrammaufruf entsprechenden Unterprogrammdaten (123b) bereitzustellen. Vorrichtung gemäß einem der Ansprüche 1 bis 3, wobei der Programmcode (104) ein aus einem Quellcode generierter Zwischencode ist. Vorrichtung gemäß einem der Ansprüche 1 bis 4, wobei die Maschine (122) des Programmcodes eine Kompiliereinrichtung ist, die ausgebildet ist, um aus dem Programmcode (104) einen Maschinencode (124) bereitzustellen. Vorrichtung gemäß einem der Ansprüche 1 bis 5, wobei die Maschine (122) des Programmcodes eine Interpretiereinrichtung ist, die ausgebildet ist, um den Programmcode (104) zu interpretieren und den interpretierten Programmcode auszuführen. Vorrichtung gemäß einem der Ansprüche 1 bis 6, wobei die Maschine (122) des Programmcodes eine virtuelle Maschine ist. Vorrichtung gemäß einem der Ansprüche 1 bis 7, wobei die Maschine (122) des Programmcodes ausgebildet ist, um Maschinencode auszuführen und, um Code zur Erstellung und Auswertung von Unterprogrammanfragen (123a, 123b) bereitzustellen. Vorrichtung gemäß einem der Ansprüche 1 bis 8, wobei das Sicherheitsmodul (113) eine Chipkarte oder ein Trusted Platform Modul ist. Vorrichtung gemäß einem der Ansprüche 1 bis 8, wobei die Unterprogrammaufrufe Methodenaufrufe einer objektorientierten Programmiersprache sind und wobei die Zuweisungstabelle (112) eine virtuelle Methoden Tabelle oder eine dynamische Methoden Tabelle ist. Verfahren zum Verarbeiten eines Programmcodes mit einer Mehrzahl von Unterprogrammaufrufen, mit folgenden Schritten:

Bereitstellen des Programmcodes (104) an eine Maschine; Bereitstellen einer Zuweisungstabelle (112) mit Unterprogrammdaten (123b) in einem zusätzlichen, hardwarebasierten Sicherheitsmodul (113), wobei ein Zugriff auf die Zuweisungstabelle in dem Sicherheitsmodul eingeschränkt ist und wobei die Unterprogrammdaten einen Verweis auf ein dem Unterprogrammaufruf entsprechendes Unterprogramm aufweisen;

Ausstatten der Maschine mit einer Berechtigungsinformation;

Verwenden des Programmcodes (104) in der Maschine und, ansprechend auf einen Unterprogrammaufruf, Bereitstellen einer Unterprogrammdatenanfrage (123a) mit der Berechtigungsinformation an das Sicherheitsmodul

Prüfen der Berechtigungsinformation durch das Sicherheitsmodul und, abhängig von der Prüfung Bereitstellen der, dem Unterprogrammaufruf entsprechenden Unterprogrammdaten an die Maschine; und

Ausführen des, dem Unterprogrammaufruf entsprechenden Unterprogramm durch die Maschine, unter Verwendung der Unterprogrammdaten.
Verfahren gemäß Anspruch 11, wobei der Schritt des Bereitstellens der Zuweisungstabelle (112) einen Schritt des Anordnens der Zuweisungstabelle in dem Sicherheitsmodul (113) umfasst. Verfahren gemäß Anspruch 12, wobei der Schritt des Bereitstellens der Zuweisungstabelle (112) einen Schritt des Bereitstellens eines ausführbaren Programms mit Zuweisungstabellendaten umfasst, wobei ein Zugriff auf die Zuweisungstabellendaten in dem ausführbaren Programm beschränkt ist; und einen Schritt des Ausführens des ausführbaren Programms umfasst, wobei das ausführbare Programm ausgebildet ist, um die Zuweisungstabellendaten in dem Sicherheitsmodul anzuordnen. Verfahren gemäß einem der Ansprüche 11 bis 13, wobei der Schritt des Bereitstellens des Programmcodes (104) und der Zuweisungstabelle (112) einen Schritt des Kompilierens (206) eines Quellcodes (202) umfasst, um den Programmcode (104) und die Zuweisungstabelle zu erzeugen. Verfahren gemäß Anspruch 14, wobei der Schritt des Kompilierens (206) ein Schritt des Vor-Kompilierens (306') umfasst, um die Zuweisungstabelle (112) aus dem Quellcode (202) zu erzeugen. Verfahren gemäß Anspruch 14, wobei der Schritt des Kompilierens einen Schritt des Vor-Kompilierens umfasst, um Quellprogramm-Unterprogrammaufrufe so umzubenennen, dass eine Zuordnung zwischen Unterprogrammaufrufname und Unterprogramm über den Unterprogrammaufrufnamen ohne Kenntnis der Zuweisungstabellendaten erschwert ist. Computer-Programm mit einem Programmcode zur Durchführung des Verfahrens gemäß Anspruch 11, wenn das Computer-Programm auf einem Computer abläuft.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com