DE102015112143A1

DE102015112143A1 - Ein Verfahren zum Bestimmen einer Integrität einer Ausführung eines Codefragments und ein Verfahren zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes

Info

Publication number: DE102015112143A1
Application number: DE102015112143.3A
Authority: DE
Inventors: Michael Smola; Gerd Dirscherl; Marcel Schaible; Bernhard Sommer
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2015-07-24
Filing date: 2015-07-24
Publication date: 2017-01-26
Anticipated expiration: 2035-07-25
Also published as: DE102015112143B4; CN106372500B; CN106372500A; US10146655B2; US20170024304A1

Abstract

Ein Verfahren zum Bestimmen einer Integrität einer Ausführung eines Codefragments ist bereitgestellt. Das Verfahren umfasst ein Identifizieren einer Referenzsignatur für das Codefragment innerhalb einer abstrahierten Repräsentation eines Programmcodes, der das Codefragment umfasst. Ferner umfasst das Verfahren ein Ausführen des Codefragments und ein Bestimmen einer Signatur des ausgeführten Codefragments. Das Verfahren umfasst ein Vergleichen der Signatur mit der Referenzsignatur.

Description

Gebiet
Ausführungsbeispiele beziehen sich auf eine Integritätsbestimmung. Einige Ausführungsbeispiele beziehen sich auf ein Verfahren zum Bestimmen einer Integrität einer Ausführung eines Codefragments unter Verwendung einer abstrahierten Repräsentation eines Programmcodes, und weitere Ausführungsbeispiele beziehen sich auf ein Verfahren zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes.
Hintergrund
Die Integrität einer Ausführung eines Codes zeigt an, dass beabsichtigte (d. h. korrekte) Anweisungen innerhalb eines Fragments des Codes in einer beabsichtigten (d. h. korrekten) Sequenz ausgeführt werden. Ferner zeigt die Integrität einer Ausführung eines Codes an, dass nur beabsichtigte (d. h. korrekte oder gültige) Pfade zwischen Fragmenten des Codes ausgeführt werden. Anders ausgedrückt, die Integrität zeigt an, dass ein tatsächlicher Programmfluss (Programmablauf) des ausgeführten Codes identisch ist zu einem beabsichtigten Programmfluss des Codes. Die Ausführung eines Codes kann auf vielerlei Weise manipuliert werden. Zum Beispiel kann die Ausführung physisch manipuliert werden durch Anwenden einer definierten Energiemenge auf eine Halbleiterschaltung, die den Code ausführt (Integritätsangriff). Zum Beispiel kann ein elektrischer oder ein elektromagnetischer Impuls auf die Halbleiterschaltung angewandt werden. Ferner können Lichtimpulse auf die Halbleiterschaltung (z. B. mittels eines Lasers) angewandt werden. Der Energieeingang kann einen Bit-Flip (Bit-Kippen) in dem ausgeführten Code verursachen, sodass ein Verlauf der Ausführung geändert werden kann.
Als eine Vorkehrung kann Hardware, die den Code ausführt, bereitgestellt sein, derart, dass eine externe physischer Manipulation detektiert wird. Ferner können Maßnahmen auf Softwareebene ergriffen werden, um Code- und Datenintegrität sicherzustellen. Zum Beispiel können Codefragmente mit der gleichen oder einer ähnlichen Funktionalität parallel ausgeführt werden und die Ergebnisse können verglichen werden, was erfordert, dass der Code eines Softwareprogramms auf proprietäre Weise programmiert ist. Allerdings kann das Verwenden solcher individueller Maßnahmen ohne eine eingebettete Sicherheitsarchitektur viele Ressourcen verbrauchen (z. B. hinsichtlich Programmentwicklungszeit, Speicherverbrauch oder Verarbeitungsleistung zum zweimaligen Implementieren einer Funktion von gleichem Ausgang).
Zusammenfassung
Während eine Datenintegrität mit zunehmendem Aufwand erreicht werden kann, kann ein Bedarf für eine verbesserte Integritätsbestimmung für eine Ausführung eines Codes bestehen. Dieser Bedarf kann durch den Gegenstand gemäß den beigefügten Ansprüchen erfüllt werden.
Einige Ausführungsbeispiele beziehen sich auf ein Verfahren zum Bestimmen einer Integrität einer Ausführung eines Codefragments. Das Verfahren umfasst ein Identifizieren einer Referenzsignatur für das Codefragment innerhalb einer abstrahierten Repräsentation eines Programmcodes, der das Codefragment umfasst. Ferner umfasst das Verfahren ein Ausführen des Codefragments und ein Bestimmen einer Signatur des ausgeführten Codefragments. Das Verfahren umfasst ein Vergleichen der Signatur mit der Referenzsignatur.
Einige Ausführungsbeispiele beziehen sich auf ein Verfahren zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes. Das Verfahren umfasst ein Identifizieren eines Basisblocks. Der Basisblock ist eine Sequenz von Anweisungen, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann. Ferner umfasst das Verfahren ein Bestimmen einer Referenzsignatur für den Basisblock und ein Bestimmen einer Referenz zu einem weiteren Basisblock. Der weitere Basisblock ist die nächste Sequenz von Anweisungen, die innerhalb des Programmcodes ausgeführt werden soll.
Einige Ausführungsbeispiele beziehen sich auf eine Programmausführungsmaschine, die ausgebildet ist zum Durchführen eines der Verfahren.
Einige Ausführungsbeispiele beziehen sich auf eine Chipkarte, die die obige Programmausführungsmaschine umfasst.
Einige Ausführungsbeispiele beziehen sich auf ein Computerprogramm mit einem Programmcode, der ausgebildet ist zum Durchführen eines der Verfahren, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird.
Kurze Beschreibung der Figuren
Einige Ausführungsbeispiele und/oder Verfahren werden nachfolgend nur beispielhaft und unter Bezugnahme auf die beiliegenden Figuren beschrieben, in denen
1 ein Flussdiagram eines Verfahrens zum Bestimmen einer Integrität einer Ausführung eines Codefragments darstellt;
2a einen Programmfluss eines Codefragments darstellt;
2b einen Kontrollflussgraphen des Codefragments darstellt;
3 einen Vergleich zwischen den in 2a und 2b dargestellten Graphen darstellt;
4 ein Verfahren zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes darstellt;
5 eine Einbettung einer Programmausführungsmaschine zum Durchführen des Verfahrens zum Bestimmen einer Integrität einer Ausführung eines Codefragments und/oder des Verfahrens zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes in einem Computersystem darstellt; und
6 schematisch eine Chipkarte darstellt.
Detaillierte Beschreibung
Verschiedene Ausführungsbeispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein.
Während sich Ausführungsbeispiele für verschiedene Modifikationen und alternative Formen eignen, werden dementsprechend Ausführungsbeispiele derselben in den Zeichnungen beispielhaft gezeigt und hier ausführlich beschrieben. Es versteht sich jedoch, dass es nicht beabsichtigt ist, Ausführungsbeispiele auf die offenbarten bestimmten Formen zu begrenzen, sondern im Gegensatz die Ausführungsbeispiele alle in den Rahmen der Offenbarung fallenden Modifikationen, Entsprechungen und Alternativen abdecken sollen. In der gesamten Beschreibung der Figuren beziehen sich gleiche Bezugszeichen auf gleiche oder ähnliche Elemente.
Es versteht sich, dass, wenn ein Element als mit einem anderen Element „verbunden" oder „gekoppelt" bezeichnet wird, es direkt mit dem anderen Element verbunden oder gekoppelt sein kann oder Zwischenelemente vorhanden sein können. Wenn im Gegensatz ein Element als „direkt" mit einem anderen Element „verbunden" oder „gekoppelt" bezeichnet wird, sind keine Zwischenelemente vorhanden. Sonstige zum Beschreiben des Verhältnisses zwischen Elementen benutzten Ausdrücke sollten auf gleichartige Weise ausgelegt werden (z. B. „zwischen" gegenüber „direkt zwischen", „benachbart" gegenüber „direkt benachbart" usw.).
Die hier verwendete Terminologie bezweckt nur das Beschreiben bestimmter Ausführungsbeispiele und soll nicht begrenzend für Ausführungsbeispiele sein. Nach hiesigem Gebrauch sollen die Singularformen „ein, eine" und „das, der, die" auch die Pluralformen umfassen, es sei denn im Zusammenhang wird deutlich etwas anderes angegeben. Es versteht sich weiterhin, dass die Begriffe „umfasst", „umfassend", „aufweisen" und/oder „aufweisend" bei hiesigem Gebrauch das Vorhandensein angegebener Merkmale, Ganzzahlen, Schritte, Operationen, Elemente und/oder Bestandteile angeben, aber nicht das Vorhandensein oder die Zufügung eines oder mehrerer anderer Merkmale, Ganzzahlen, Schritte, Operationen, Elemente, Bestandteile und/oder Gruppen derselben ausschließen.
Sofern nicht anderweitig definiert besitzen alle hier benutzten Begriffe (einschließlich technischer und wissenschaftlicher Begriffe) die gleiche Bedeutung wie sie gewöhnlich von einem Durchschnittsfachmann auf dem Gebiet verstanden wird, zu dem Ausführungsbeispiele gehören. Weiterhin versteht es sich, dass Begriffe, z. B. die in gewöhnlich benutzten Wörterbüchern Definierten, als eine Bedeutung besitzend ausgelegt werden sollten, die ihrer Bedeutung im Zusammenhang der entsprechenden Technik entspricht, sofern sie hier nicht ausdrücklich anderweitig definiert sind.
1 stellt ein Verfahren 100 zum Bestimmen einer Integrität einer Ausführung eines Codefragments dar. Das Codefragment ist Teil eines Programmcodes. Zum Beispiel ist das Codefragment eine Sequenz von Anweisungen. Der Programmcode (d. h. das Codefragment) kann zum Beispiel in einer Maschinensprache (d. h. als ein Satz von Anweisungen, der durch eine Verarbeitungseinheit direkt ausgeführt wird) oder in einer interpretierten Sprache (d. h. als ein Satz von Anweisungen, der direkt ausgeführt wird ohne ihn vorab in eine Maschinensprache zu kompilieren) bereitgestellt sein. Bei einigen Ausführungsbeispielen kann der Programmcode einen Bytecode für eine virtuelle Maschine sein (z. B. ein Bytecode für eine auf einer JavaCard basierende virtuelle Maschine).
Die Integrität der Ausführung des Codefragments zeigt an, dass beabsichtigte (d. h. korrekte) Anweisungen innerhalb des Codefragments in einer beabsichtigten (d. h. korrekten) Sequenz ausgeführt werden. Ferner zeigt die Integrität der Ausführung des Codefragments an, dass nur beabsichtigte (d. h. korrekte oder gültige) Pfade zwischen unterschiedlichen Codefragmenten des Programmcodes ausgeführt werden. Anders ausgedrückt, die Integrität zeigt an, dass ein tatsächlicher Programmfluss des ausgeführten Programmcodes identisch ist zu einem beabsichtigten Programmfluss des Programmcodes.
Das Verfahren 100 umfasst ein Identifizieren 102 einer Referenzsignatur für das Codefragment innerhalb einer abstrahierten Repräsentation des Programmcodes, der das Codefragment umfasst. Die abstrahierte Repräsentation des Programmcodes ist eine Repräsentation, die den Programmfluss des Programmcodes repräsentiert. Allerdings ist die abstrahierte Repräsentation verglichen mit dem Programmcode hinsichtlich Komplexität reduziert. Zum Beispiel kann eine Codesequenz oder ein Codefragment des Programmcodes durch eine einzelne Entität in der abstrahierten Repräsentation repräsentiert sein.
Bei einigen Ausführungsbeispielen kann das Codefragment ein Basisblock des Programmcodes sein. Ein Basisblock ist eine Sequenz von Anweisungen, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird (werden kann) und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann. Das heißt, ein Basisblock hat einen Eintrittspunkt und einen Austrittspunkt, sodass kein Code innerhalb des Basisblocks ein Ziel einer Sprunganweisung innerhalb des Programmcodes ist und dass nur die letzte Anweisung des Basisblocks das Programm veranlassen kann, mit der Ausführung des Codes in einem anderen unterschiedlichen Basisblock zu beginnen. Dementsprechend kann eine Entität in der abstrahierten Repräsentation zum Beispiel einen Basisblock des Programmcodes repräsentieren.
Die Referenzsignatur ist ein Indikator, der eine korrekte Ausführung des Codefragments anzeigt. Das heißt, die Referenzsignatur zeigt an, dass eine Sequenz von beabsichtigten (d. h. korrekten) Anweisungen innerhalb des Codefragments in einer beabsichtigten (d. h. korrekten) Reihenfolge ausgeführt wird. Wenn das Codefragment eine Mehrzahl von Basisblöcken umfasst, kann die Referenzsignatur ferner anzeigen, dass nur beabsichtigte (d. h. gültige) Pfade zwischen den Basisblöcken ausgeführt (genommen) wurden. Zum Beispiel kann die Referenzsignatur ein Wert oder eine Bit-Zeichenkette (bit string) sein. Die Referenzsignatur für das Codefragment kann im Verlauf des Erzeugens der abstrahierten Repräsentation bestimmt (berechnet) werden. Zum Beispiel kann ein Prüfwert für eine zyklische Redundanzprüfung (CRC; CRC = Cyclic Redundancy Check) oder ein Hash-Wert basierend auf dem Code des sich unter Beobachtung befindlichen Codefragments bestimmt werden. Zum Beispiel kann eine Referenzsignatur für jeden Basisblock abhängig von der Sequenz von Anweisungen, die in dem jeweiligen Basisblock enthalten sind, bestimmt werden.
Das Verfahren 100 umfasst ferner ein Ausführen 104 des Codefragments. Wenn das Codefragment zum Beispiel ein Bytecode ist, kann das Codefragment durch eine virtuelle Maschine ausgeführt werden. Bei einigen Ausführungsbeispielen kann das Ausführen des Codefragments ein Interpretieren des Codefragments unter Verwendung eines Interpretierers umfassen.
Das Verfahren 100 umfasst ferner ein Bestimmen 106 einer Signatur des ausgeführten Codefragments. Die Signatur ist ein Indikator, der die tatsächliche Ausführung des Codefragments charakterisiert. Das heißt, die Signatur des ausgeführten Codefragments charakterisiert die Sequenz von tatsächlich ausgeführten Anweisungen. Wenn das Codefragment eine Mehrzahl von Basisblöcken umfasst, kann die Referenzsignatur ferner tatsächlich ausgeführte (genommene) Pfade zwischen den Basisblöcken charakterisieren. Anders ausgedrückt, die Signatur kann parallel zu der Ausführung des Codes berechnet werden, sodass sie auf dem tatsächlich ausgeführten Code basiert. Zum Beispiel kann die Signatur ein numerischer Wert oder eine Bit-Zeichenkette sein. Die Signatur kann ähnlich zu der Referenzsignatur bestimmt werden (z. B. unter Verwendung des gleichen mathematischen Konzeptes oder Algorithmus).
Die Ausführung des Codefragments kann durch bösartige Angreifer manipuliert werden, sodass ein anderer als der ursprünglich erzeugte Code ausgeführt wird, sodass ein Ergebnis der Ausführung korrumpiert oder falsch werden kann. Zu diesem Zweck kann eine individuelle Anweisung abgeändert werden. Eine andere Möglichkeit wäre es, eine Reihenfolge der Ausführung von individuellen Anweisungen zu ändern. Zum Beispiel kann eine definierte Energiemenge auf eine Halbleiterschaltung angewandt werden, die das Codefragment ausführt, um während der Ausführung des Codefragments einen Bit-Flip zu verursachen. Ein Bit-Flip kann verursachen, dass eine inkorrekte Anweisung anstelle einer beabsichtigten Anweisung ausgeführt wird. Ferner kann ein Bit-Flip verursachen, dass eine Reihenfolge der Ausführung von Anweisungen innerhalb des Codefragments geändert wird. Dementsprechend kann das Ergebnis der Ausführung korrumpiert oder falsch werden.
Die Ausführung des Codefragments kann ferner aufgrund von Umwelteinflüssen (z. B. Temperatur, Strahlung) verzerrt werden. Zum Beispiel kann bei sicherheitskritischen Anwendungen, wie Automobilanwendungen (z. B. einem Auto), Eisenbahn (z. B. einem Zug) oder Luftfahrt (z. B. einem Flugzeug) eine korrekte Ausführung eines Programmcodes unerlässlich für die Sicherheit (z. B. von Passagieren) sein. Daher sollte jegliche Integritätsverletzung eines ausgeführten Codefragments umgehend detektiert werden.
Um solche Unstimmigkeiten zu detektieren, umfasst das Verfahren 100 ein Vergleichen 108 der Signatur mit der Referenzsignatur. Zum Beispiel kann das Vergleichen der Signatur des ausgeführten Programmcodes mit der Referenzsignatur ein Validieren dahingehend umfassen, dass die Signatur und die Referenzsignatur identisch sind. Das Vergleichen der Signatur und der Referenzsignatur kann es erlauben, zu detektieren, ob die tatsächliche Ausführung des Codefragments sich von der beabsichtigten (korrekten) Ausführung des Codefragments unterscheidet. Das heißt, die Reihenfolge von tatsächlich ausgeführten Anweisungen ist identisch mit einer beabsichtigten (d. h. korrekten) Reihenfolge von beabsichtigten (d. h. korrekten) Anweisungen innerhalb des Codefragments. Wenn das Codefragment eine Mehrzahl von Basisblöcken umfasst, kann der Vergleich der Signatur mit der Referenzsignatur ferner anzeigen, dass nur beabsichtigte (d. h. gültige) Pfade zwischen den Basisblöcken ausgeführt (genommen) wurden.
Das Verwenden der abstrahierten Repräsentation des Codes kann ferner erlauben, erforderliche Ressourcen für die Integritätsbestimmung zu minimieren, da ein Interpretieren der abstrahierten Repräsentation zum Beispiel weniger Speicherplatz oder Verarbeitungsleistung erfordern kann als ein paralleles Ausführen einer weiteren Instanz des Programmcodes. Zum Beispiel kann die Ausführung eines Programmcodes ohne jeglichen inhärenten Schutzmechanismus gegen Integritätsangriffe durch das vorgeschlagene Verfahren geschützt werden, da der Integritätsangriff durch ein Vergleichen einer Referenzsignatur für das ausgeführte Codefragment mit einer Referenzsignatur von der abstrahierten Repräsentation des Programmcodes detektiert wird. Dementsprechend kann das Verfahren eine Einbettung für jeglichen Programmcode gegen Integritätsangriffe auf den Code und die Daten bereitstellen. Ferner kann das Verfahren erlauben, eine verzerrte Ausführung des Codefragments aufgrund von Umwelteinflüssen zu detektieren.
Bei einigen Ausführungsbeispielen kann das Verfahren ferner ein Ausführen einer Alarmroutine umfassen, wenn die Signatur sich von der Referenzsignatur unterscheidet. Zum Beispiel kann die Alarmroutine eine Alarmbenachrichtigung an einen Benutzer oder eine verantwortliche Person bereitstellen. Alternativ oder zusätzlich kann die Alarmroutine eine Ausführung weiterer Teile des Programmcodes stoppen oder kann die Ausführung weiterer Teile des Codes verbieten. Wenn der Programmcode zum Beispiel auf einer Chipkarte (z. B. einer Zugangskarte) gespeichert ist, kann die Alarmroutine einen Programmcode aktivieren, um einen Zustand der Chipkarte in einen inaktivierten Zustand zu setzen (d. h. die Chipkarte unbrauchbar zu machen).
Bei einigen Ausführungsbeispielen kann die Alarmroutine eine Löschung von Daten aus einem Speicher und/oder einem Register verursachen. Zum Beispiel kann die Alarmroutine eine Löschung sensibler oder gefährdeter Daten (z. B. eines Sicherheitsschlüssels oder eines Passworts), die in dem Speicher oder dem Register gespeichert sind, verursachen. Bei einigen Ausführungsbeispielen kann sich der Speicher oder das Register von einem Speicher oder Register unterscheiden, auf dem der Programmcode zum Ausführen des Verfahrens gespeichert ist. Durch ein Löschen von Daten im Falle einer Alarmbedingung kann der Zugriff auf die Daten durch potenziell bösartige Angreifer verhindert werden.
Dementsprechend kann ein unbefugter Zugriff auf sensible Daten verhindert werden. Wenn die Daten auf einer Chipkarte (z. B. einer Zugangskarte) gespeichert sind, kann zum Beispiel ein Löschen der Daten die Chipkarte unbrauchbar machen, sodass eine betrügerische Verwendung der Chipkarte verhindert werden kann.
Bei einigen Ausführungsbeispielen kann das Identifizieren 102 der Referenzsignatur unabhängig von dem Ausführen 104 des Codefragments und dem Bestimmen 106 der Signatur des ausgeführten Codefragments durchgeführt werden. Das Identifizieren 102 der Referenzsignatur kann durchgeführt werden, derart, dass die tatsächliche Ausführung des Codefragments die Identifizierung der Referenzsignatur nicht beeinflusst. Zum Beispiel können unterschiedliche Speicherorte zum Identifizieren der Referenzsignatur innerhalb der abstrahierten Repräsentation und zum Ausführen des Codefragments und Bestimmen seiner Signatur verwendet werden. Alternativ oder zusätzlich können die Identifizierung der Referenzsignatur und die Ausführung des Codefragments durch getrennte Prozesse durchgeführt werden. Bei einigen Ausführungsbeispielen können die Identifizierung der Referenzsignatur und die Ausführung des Codefragments parallel durchgeführt werden, d. h. im Wesentlichen zu einem gleichen Zeitmoment. Ein Durchführen der obigen Schritte unabhängig voneinander kann erlauben, die Sicherheit weiter zu verbessern, da eine Manipulation von einer von der Ausführung des Codefragments und der abstrahierten Repräsentation des Programmcodes die andere nicht beeinflusst.
Bei einigen Ausführungsbeispielen umfasst die abstrahierte Repräsentation eine verknüpfte Liste, die eine Mehrzahl von Knoten umfasst. Die verknüpfte Liste ist eine Datenstruktur, die den Fluss des Programmcodes durch die Mehrzahl von Knoten repräsentiert. Zumindest ein Knoten aus der Mehrzahl von Knoten kann auf das Codefragment (das z. B. ein Basisblock ist) bezogen sein. Die verbleibenden Knoten können auf andere Codefragmente des Programmcodes (z. B. andere Basisblöcke) bezogen sein.
Der zumindest eine Knoten aus der Mehrzahl von Knoten kann eine Referenzsignatur für den Basisblock umfassen (wenn das Codefragment einem Basisblock entspricht). Der Eintrittspunkt (d. h. die erste Anweisung) des Basisblocks kann zum Beispiel ein Funktionseintritt oder eine Zieladresse einer Verzweigungsanweisung sein. Die Verzweigungsanweisung kann jegliche Anweisung sein, die eine Entität (z. B. einen Prozessor oder eine virtuelle Maschine), die den Basisblock ausführt, dazu veranlasst, mit der Ausführung einer unterschiedlichen Anweisungssequenz (d. h. eines unterschiedlichen Basisblocks oder eines anderen Codefragments) zu beginnen. Zum Beispiel kann die Verzweigungsanweisung eine IF-Anweisung (IF = wenn), eine GOTO-Anweisung (GOTO = gehen zu) oder eine INVOKE-Anweisung (INVOKE, CALL = aufrufen) sein. Bei einigen Ausführungsbeispielen kann die Verzweigungsanweisung die erste Verzweigungsanweisung in der Sequenz von Anweisungen sein.
Die verknüpfte Liste auf Basisblöcken des Programmcodes zu basieren, kann ein einfaches Konstrukt für ein Abstrahieren des Programmcodes sein, während der Programmfluss des Programmcodes beibehalten wird. Ferner kann ein Verwenden von Basisblöcken für die Integritätsbestimmung erlauben, sicherzustellen, dass die Signatur eindeutig ist, da sie nicht von dem Programmfluss abhängt. Zum Beispiel kann der zumindest eine Knoten ferner zumindest eine Referenz zu einem anderen Knoten aus der Mehrzahl von Knoten umfassen, wobei der andere Knoten auf einen weiteren Basisblock bezogen ist. Der weitere Basisblock kann die nächste Sequenz von Anweisungen sein, die innerhalb des Programmcodes ausgeführt werden soll (z. B. beginnt der weitere Basisblock mit einer Zieladresse einer Verzweigungsanweisung, die den aktuellen Basisblock beendet). Dementsprechend kann der Programmcode durch eine Mehrzahl von miteinander verbundenen Knoten repräsentiert sein, wobei jeder Knoten der Referenzsignatur des Basisblocks zugeordnet ist, den er repräsentiert. Durch ein Speichern der Basisblöcke und ihrer zugeordneten Referenzsignaturen als verknüpfte Liste kann ein ausführendes System die Referenzsignatur für ein ausgeführtes Codefragment durch ein Interpretieren der verknüpften Liste identifizieren (schlussendlich selbst im Fall von mehreren Referenzen innerhalb eines Basisblocks). Da die verknüpfte Liste eine komprimierte Repräsentation des Programmcodes ist, kann ein Fußabdruck (Footprint), d. h. ein erforderlicher Speicherplatz, vergleichsweise klein sein.
Obgleich Basisblöcke des Programmcodes als Beispiele für Codefragmente beschrieben wurden, kann die Integrität für jegliche Art von Codefragment bestimmt werden, d. h. auch für Codefragmente, die sich von Basisblöcken des Programmcodes unterscheiden.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in 1 dargestellte Ausführungsbeispiel kann ein oder mehrere zusätzliche optionale Merkmale aufweisen, die einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, nachstehend beschriebenen Ausführungsbeispielen entsprechen.
2a stellt einen Programmflussgraphen 200 eines Fragments eines Programmcodes dar (z. B. ein Java-Applet). Der Programmflussgraph 200 repräsentiert ein Verhältnis zwischen einzelnen Anweisungen oder Sequenzen von Anweisungen, die in dem Codefragment enthalten sind. Jeder Knoten des Programmflussgraphen repräsentiert eine einzelne Anweisung oder eine Sequenz von Anweisungen innerhalb des Codefragments. Der Programmflussgraph 200 umfasst eine Mehrzahl von Verzweigungsknoten, 210-1, ..., 210-11 die sich auf Verzweigungsanweisungen (z. B. eine GOTO-Anweisung, eine RETURN-Anweisung (RETURN = zurück) oder eine SWITCH-Anweisung (SWITCH = schalten) beziehen. Der Programmflussgraph 200 umfasst ferner Eintrittsknoten 220, die sich auf Anweisungen beziehen, zu denen Verzweigungsanweisungen (die durch die Verzweigungsknoten 210-1, ..., 210-11 repräsentiert sind) springen. Ferner umfasst der Programmflussgraph 200 lineare Knoten 230, die sich auf eine oder mehrere Anweisungen beziehen, die in linearer Sequenz ausgeführt werden (z. B. eine Anweisung zum Inkrementieren einer Variablen).
Einer oder mehrere Knoten des Programmflussgraphen 200 können zu einem Basisblock gehören, der in dem Codefragment enthalten ist. Zum Beispiel umfasst ein erster Basisblock 240 den Eintrittsknoten 220-1 und den linearen Knoten 230-1 zwischen den Verzweigungsknoten 210-2 und 210-3. Der erste Basisblock 240 endet mit dem Verzweigungsknoten 210-3. Das heißt, der erste Basisblock 240 umfasst eine Sequenz von Anweisungen, wobei der Basisblock 240 nur an der ersten Anweisung (Eintrittsknoten 220-1) der Sequenz von Anweisungen begonnen werden kann und nur von der letzten Anweisung (Verzweigungsknoten 210-3) der Sequenz von Anweisungen verlassen werden kann. Dementsprechend kann der in 2a dargestellte Programmfluss des Codefragments mittels eines Kontrollflussgraphen dargestellt sein, der die Beziehungen zwischen den verschiedenen Basisblöcken des Codefragments beschreibt (z. B. siehe 2b).
Ferner können erweiterte Basisblöcke in dem in 2a dargestellten Codefragment enthalten sein. Ein erweiterter Basisblock ist ein Basisblock, der einen anderen Basisblock enthält. Das heißt, der erweiterte Basisblock kann nicht nur an der ersten Anweisung der Sequenz von Anweisungen, sondern auch an einer Anweisung innerhalb der Sequenz von Anweisungen begonnen werden.
Zum Beispiel umfasst ein erweiterter Basisblock 241 die linearen Knoten 230-2, 230-3, 230-4 und den Eintrittsknoten 220-2 zwischen den Verzweigungsknoten 210-2 und 210-4. Der erweiterte Basisblock 241 endet mit dem Verzweigungsknoten 210-4. Ein zweiter (regulärer) Basisblock 242 umfasst den linearen Knoten 230-4 und den Eintrittsknoten 220-2 zwischen den Verzweigungsknoten 210-3 und 210-4. Der zweite Basisblock 242 endet mit dem Verzweigungsknoten 210-4. Das heißt, der zweite Basisblock 242 ist in dem erweiterten Basisblock 241 enthalten.
Anders ausgedrückt, 2a kann ein Beispiel einer Graphen-Repräsentation eines Java-Applets darstellen. Der Graph kann drei Typen von Knoten umfassen: a) Verzweigung (Anweisungen mit einer, zwei oder mehr Sprungzielen); b) Eintritt (Anweisungen zu denen Verzweigungen springen); und c) Linear (einfache Anweisungen, die in linearer Sequenz ausgeführt werden).
2b stellt einen Kontrollflussgraphen 200 des in 2a dargestellten Fragments des Programmcodes dar. Der Kontrollflussgraph 200 umfasst Knoten 210-1', ..., 210-11', die Basisblöcken des in 2a dargestellten Codefragments entsprechen. Die Knoten 210-1', ..., 210-11', sind in 2b als Verzweigungsknoten dargestellt, wobei jeder Knoten 210-1', ..., 210-11', einen Basisblock repräsentiert, der mit einem entsprechenden Verzweigungsknoten 210-1, ..., 210-11, in dem in 2a dargestellten Programmflussgraphen 200 endet. Jeder Knoten 210-1', ..., 210-11', ist mit einer Referenzsignatur für den Basisblock bereitgestellt, der mit dem jeweiligen Verzweigungsknoten endet. Zum Beispiel umfasst der Knoten 210-3 eine Referenzsignatur für den ersten Basisblock 240, da der erste Basisblock 240 mit dem entsprechenden Verzweigungsknoten 210-3 in dem in 2a dargestellten Programmflussgraphen endet.
Der Kontrollflussgraph 200 kann als eine abstrahierte Repräsentation des Fragments des Programmcodes betrachtet werden, da die Repräsentation des tatsächlichen Programmcodes auf seine Basisblöcke reduziert ist.
Anders ausgedrückt, eine abstrahierte und komprimierte Repräsentation kann aufgebaut werden durch ein Reduzieren des ursprünglichen Graphen um die linearen Anweisungen (z. B. linearen Bytecode) und die Eintrittspunkte, sodass nur ein Graph der Verzweigungen verbleibt.
Die Integrität einer Ausführung eines Basisblocks des durch den Programmflussgraphen 200 in 2a dargestellten Codefragments kann bestimmt werden durch ein Vergleichen des Programmflussgraphen 200 mit dem abstrakten Kontrollflussgraphen 200 , wie in 3 dargestellt. Der Programmflussgraph 200 wird mit dem Kontrollflussgraph 200 an den Verzweigungsknoten, d. h. an der letzten Anweisung des jeweiligen Basisblocks, verglichen. Zum Beispiel wird für den Basisblock 240 eine Signatur während der Ausführung des Programmcodes bestimmt. Wenn der Verzweigungsknoten 210-3 ausgeführt wird, wird die Signatur mit einer Referenzsignatur des entsprechenden Knotens 210-3 des abstrakten Programmflussgraphen 200 verglichen. Zum Beispiel kann die Referenzsignatur während der Erzeugung des Programmflussgraphen 200 bestimmt (berechnet) werden.
Durch ein Vergleichen der bestimmten Signatur für die tatsächliche Ausführung der Sequenz von Anweisungen, die durch den Basisblock 240 repräsentiert ist, mit der Referenzsignatur wird eine Integrität der Ausführung bestimmt. Das heißt, es wird bestimmt, ob beabsichtigte (d. h. korrekte) Anweisungen innerhalb des Codefragments in einer beabsichtigten (d. h. korrekten) Reihenfolge ausgeführt wurden. Wenn sich die Signatur von der Referenzsignatur unterscheidet, kann ein Integritätsangriff angenommen werden. Dementsprechend kann eine Alarmroutine ausgeführt werden. Zum Beispiel kann eine Alarmbenachrichtigung gesendet werden, Daten können aus dem Speicher gelöscht werden oder die Ausführung des Programmcodes kann gestoppt werden. Durch ein Vergleichen der Ausführung des Programmcodes mit der abstrahierten Repräsentation an den Verzweigungsanweisungen (d. h. ein gleichzeitiges Vergleichen der Repräsentationen mit der Ausführung des Programmcodes) kann eine Integrität der Ausführung unmittelbar nach der Ausführung eines Basisblocks (d. h. nach Ausführung nur eines Fragments des gesamten Programmcodes) bestimmt werden. Somit kann eine Integritätsverletzung in Echtzeit bestimmt werden, sodass eine weitere fehlerhafte Ausführung des Programmcodes verhindert werden kann. Ferner können Gegenmaßnahmen umgehend nach der fehlerhaften Ausführung des Basisblocks gestartet werden.
Das in 3 dargestellte Ausführungsbeispiel kann ein oder mehrere zusätzliche optionale Merkmale aufweisen, die einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, vor- oder nachstehend beschriebenen Ausführungsbeispielen entsprechen.
Ein Verfahren 400 zum Bereitstellen (Erzeugen) einer abstrahierten Repräsentation eines Programmcodes (z. B. in 2b oder 3 dargestellt) ist in 4 dargestellt. Der Programmcode kann in einer Maschinensprache oder einer interpretierten Sprache (z. B. als ein Bytecode) bereitgestellt sein.
Das Verfahren 400 umfasst ein Identifizieren 402 eines Basisblocks innerhalb des Programmcodes. Der Basisblock ist eine Sequenz von Anweisungen, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird (werden kann) und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann. Zum Beispiel kann eine erste Anweisung einer Codesequenz, die einer Verzweigungsanweisung innerhalb des Programmcodes folgt, der Eintrittspunkt des Basisblocks sein. Der Basisblock kann zum Beispiel an einer nachfolgenden Verzweigungsanweisung enden. Das heißt, die letzte Anweisung der Sequenz von Anweisungen kann eine Verzweigungsanweisung sein.
Ferner umfasst das Verfahren 400 ein Bestimmen 404 einer Referenzsignatur für den Basisblock. Die Referenzsignatur ist ein Indikator, der eine korrekte Ausführung des Codefragments (Codesequenz), das durch den Basisblock repräsentiert ist, anzeigt. Das heißt, die Referenzsignatur zeigt an, dass eine Sequenz von beabsichtigten (d. h. korrekten) Anweisungen innerhalb des Basisblocks in einer beabsichtigten (d. h. korrekten) Reihenfolge ausgeführt wird. Zum Beispiel kann die Referenzsignatur ein numerischer Wert oder eine Bit-Zeichenkette sein (z. B. ein Prüfwert für eine CRC oder ein Hash-Wert).
Das Verfahren umfasst ferner ein Bestimmen 406 einer Referenz zu einem weiteren Basisblock. Der weitere Basisblock ist die nächste Sequenz von Anweisungen, die innerhalb des Programmcodes ausgeführt werden soll. Die Referenz zu dem weiteren Basisblock kann erlauben, einen Programmfluss des Programmcodes innerhalb der abstrahierten Repräsentation zu repräsentieren.
Die erzeugte abstrahierte Repräsentation ist reduziert verglichen zu dem Programmcode, da Fragmente des Programmcodes (Codefragmente) durch Basisblöcke repräsentiert sind. Die Basisblöcke werden ihrer jeweiligen Referenzsignatur zugeordnet, sodass ein Vergleich der Referenzsignatur mit einer berechneten Signatur für eine Ausführung des Codefragments, das durch den Basisblock repräsentiert ist, möglich sein kann.
Bei einigen Ausführungsbeispielen kann das Verfahren 400 ferner ein Hinzufügen von Information über den Basisblock (z. B. zum Identifizieren des Basisblocks, oder die Anzahl von Anweisungen, die in dem Basisblock enthalten sind) und seine zugeordnete Referenzsignatur zu einem Knoten einer Liste umfassen. Ein Speichern der Information über den Basisblock und seiner zugeordneten Referenzsignatur in einem Knoten der Liste erlaubt, eine Liste als eine abstrahierte Repräsentation bereitzustellen. Die Liste kann erlauben, den Programmfluss des Programmcodes zu repräsentieren. Zum Beispiel kann die Liste eine verknüpfte Liste sein, sodass die Referenz zu dem weiteren Basisblock in eine Referenz zu einem weiteren Knoten übersetzt werden kann. Durch das Speichern der Information über den Basisblock und seine zugeordnete Referenzsignatur als eine Liste, kann ein ausführendes System (z. B. ein Prozessor oder eine virtuelle Maschine) die Referenzsignatur für ein ausgeführtes Codefragment durch ein Lesen der Liste identifizieren. Da die Liste eine komprimierte Repräsentation des Programmflusses ist, kann ferner ein Fußabdruck, d. h. ein erforderlicher Speicherplatz, vergleichsweise klein sein.
Das Verfahren 400 kann ferner ein Speichern der Liste (d. h. der abstrahierten Repräsentation) und des Programmcodes umfassen. Zum Beispiel kann die abstrahierte Repräsentation zusammen mit dem Programmcode (z. B. in einem gleichen Speicher) gespeichert werden. Bei einigen Ausführungsbeispielen können die abstrahierte Repräsentation und der Programmcode in einem Speicher einer Chipkarte gespeichert werden.
Das Verfahren zum Erzeugen der abstrahierten Repräsentation des Programmcodes kann zum Beispiel auf einem Zielsystem (z. B. durch eine integrierte Schaltung einer Chipkarte) durchgeführt werden. Dementsprechend kann die abstrahierte Repräsentation ohne jegliche externe Mittel erzeugt werden. Daher kann das Zielsystem erlauben, eine abstrahierte Repräsentation eines Programmcodes (z. B. eines Applets) für eine Integritätsprüfung einer Ausführung des Programmcodes auf dem Zielsystem bereitzustellen. Herkömmliche externe Vorrichtungen (z. B. ein herkömmlicher Kartenleser) für die Kommunikation mit dem Zielsystem können verwendet werden, da die Erzeugung der abstrahierten Repräsentation auf dem Zielsystem durchgeführt wird (sowie die Integritätsbestimmung). Zum Beispiel kann die Erzeugung der abstrahierten Repräsentation im Verlauf einer Initialisierung des durch den Programmcode repräsentierten Programms durchgeführt werden.
Bei einigen Ausführungsbeispielen kann das Verfahren zum Erzeugen der abstrahierten Repräsentation des Programmcodes durch eine externe Vorrichtung (z. B. einen Kartenleser, eine mit dem Kartenleser verbundene Verarbeitungseinheit oder ein System, das den Programmcode erzeugt hat) durchgeführt werden. Dementsprechend kann eine Verhaltensanforderung für das Zielsystem reduziert sein, da die Erzeugung durch das externe Mittel (z. B. mit einer erhöhten Verarbeitungsleistung verglichen mit dem Zielsystem) ausgeführt wird. Ferner kann das Erzeugen der abstrahierten Repräsentation durch das System, das den Programmcode erzeugt hat, erlauben, die abstrahierte Repräsentation nur einmal zu erzeugen, da die zentral erzeugte abstrahierte Repräsentation an jegliches Zielsystem oder externe Vorrichtung, die mit dem Zielsystem kommuniziert, bereitgestellt werden kann.
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in 4 dargestellte Ausführungsbeispiel kann ein oder mehrere zusätzliche optionale Merkmale aufweisen, die einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, vor- oder nachstehend beschriebenen Ausführungsbeispielen entsprechen.
Die Verfahren gemäß einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, hierin beschriebenen Ausführungsbeispielen können durch eine Programmausführungsmaschine durchgeführt werden. Bei einigen Ausführungsbeispielen kann die Programmausführungsmaschine als Hardware (z. B. eine integrierte Schaltung oder ein Prozessor) implementiert sein. Bei einigen Beispielen kann die Programmausführungsmaschine als Software (z. B. ein Interpretierer oder eine virtuelle Maschine) implementiert sein.
Zum Beispiel kann die Programmausführungsmaschine einen Interpretierer für einen Bytecode umfassen. Bei einigen Ausführungsbeispielen kann der Bytecode auf JAVA basieren. Zum Beispiel kann die Programmausführungsmaschine eine JavaCard-Virtuelle-Maschine sein und der Programmcode kann ein JavaCard-Bytecode sein.
Ein Ausführungsbeispiel einer Einbettung einer Programmausführungsmaschine 500 in ein Computersystem ist in 5 dargestellt. Eine Softwareumgebung 510 wird auf einer Hardware 520 (z. B. einem Prozessor) ausgeführt. Die Softwareumgebung 510 umfasst eine virtuelle Maschine 511 (z. B. eine JavaCard-Virtuelle-Maschine). Innerhalb der virtuellen Maschine 511 ist ein Computerprogramm 512 mit einem Programmcode zum Durchführen von Verfahren gemäß einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, hierin beschriebenen Ausführungsbeispielen implementiert. Ein Bytecode 513 ist durch das Computerprogramm 512 geschützt. Zum Beispiel kann das Computerprogramm 512 eine abstrahierte Repräsentation des Bytecodes 513 erzeugen. Die abstrahierte Repräsentation kann verwendet werden, um die Integrität einer Ausführung (von Fragmenten) des Bytecodes 513 auf der virtuellen Maschine zu bestimmen. Das heißt, das Computerprogramm 512 stellt eine Schutzschicht für den Bytecode 513 innerhalb der virtuellen Maschine 512 bereit. Eine weitere Sicherheitsmaßnahme kann auf der Hardwareschicht ergriffen werden.
Anders ausgedrückt, das Signaturprüfverfahren kann in eine Schicht-Sicherheitsarchitektur (Layer-Sicherheitsarchitektur) eingebettet sein: a) Hardwareschicht; b) Interpretiererschicht (Adherent Instruction Set Signature = Adhärente Anweisungssatzsignatur); und c) Anwendung/Bibliothek/Firmware-Schicht (der interpretierte Bytecode des Laufzeitsystems).
Weitere Einzelheiten und Aspekte sind in Verbindung mit den vor- oder nachstehend beschriebenen Ausführungsbeispielen erwähnt. Das in 5 dargestellte Ausführungsbeispiel kann ein oder mehrere zusätzliche optionale Merkmale aufweisen, die einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, vor- oder nachstehend (z. B. 1 oder 4) beschriebenen Ausführungsbeispielen entsprechen.
Ein Ausführungsbeispiel unter Verwendung der Integritätsbestimmung einer Ausführung eines Codefragments oder Bereitstellung einer abstrahierten Repräsentation eines Programmcodes gemäß einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, vorstehend beschriebenen Beispielen ist in 6 dargestellt.
6 stellt eine Chipkarte 600 dar. Die Chipkarte 600 umfasst eine Programmausführungsmaschine 610 (z. B. einen Prozessor oder eine virtuelle Maschine) gemäß hierin beschriebenen Beispielen. Die Programmausführungsmaschine ist ausgebildet zum Durchführen von Verfahren gemäß einem oder mehreren Aspekten des vorgeschlagenen Konzeptes oder einem oder mehreren, hierin beschriebenen Ausführungsbeispielen.
Die Chipkarte 600 kann erlauben, einen Integritätsangriff auf die Karte zu detektieren. Ferner kann die Chipkarte 600 erlauben, eine abstrahierte Repräsentation eines Programmcodes für die Integritätsbestimmung des Programmcodes bereitzustellen. Dementsprechend kann die Chipkarte 600 eine hohe Sicherheitsstufe bereitstellen.
Ausführungsbeispiele können weiterhin ein Computerprogramm mit einem Programmcode zum Durchführen eines der obigen Verfahren bereitstellen, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird. Ein Fachmann würde leicht erkennen, dass Schritte verschiedener oben beschriebener Verfahren durch programmierte Computer durchgeführt werden können. Hierbei sollen einige Ausführungsbeispiele auch Programmspeichervorrichtungen, z. B. Digitaldatenspeichermedien, abdecken, die maschinen- oder computerlesbar sind und maschinenausführbare oder computerausführbare Programme von Anweisungen codieren, wobei die Anweisungen einige oder alle der Schritte der oben beschriebenen Verfahren durchführen. Die Programmspeichervorrichtungen können z. B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien sein. Auch sollen weitere Ausführungsbeispiele Computer programmiert zum Durchführen der Schritte der oben beschriebenen Verfahren oder (feld-)programmierbare Logik-Arrays ((F)PLA = (Field) Programmable Logic Arrays) oder (feld-)programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays) programmiert zum Durchführen der Schritte der oben beschriebenen Verfahren abdecken.
Durch die Beschreibung und Zeichnungen werden nur die Grundsätze der Offenbarung dargestellt. Es versteht sich daher, dass der Fachmann verschiedene Anordnungen ableiten kann, die, obwohl sie nicht ausdrücklich hier beschrieben oder dargestellt sind, die Grundsätze der Offenbarung verkörpern und in ihrem Sinn und Rahmen enthalten sind. Weiterhin sollen alle hier aufgeführten Beispiele grundsätzlich nur Lehrzwecken dienen, um den Leser beim Verständnis der Grundsätze der Offenbarung und der durch den (die) Erfinder beigetragenen Konzepte zur Weiterentwicklung der Technik zu unterstützen, und sollen als ohne Begrenzung solcher besonders aufgeführten Beispiele und Bedingungen dienend aufgefasst werden. Weiterhin sollen alle hiesigen Aussagen über Grundsätze, Aspekte und Ausführungsbeispiele der Offenbarung wie auch besondere Beispiele derselben deren Entsprechungen umfassen.
Als „Mittel für..." (Durchführung einer gewissen Funktion) bezeichnete Funktionsblöcke sind als Funktionsblöcke umfassend Schaltungen zu verstehen, die jeweils zum Durchführen einer gewissen Funktion ausgebildet sind. Daher kann ein „Mittel für etwas" ebenso als „Mittel ausgebildet für oder geeignet für etwas" verstanden werden. Ein Mittel ausgebildet zum Durchführen einer gewissen Funktion bedeutet daher nicht, dass ein solches Mittel notwendigerweise die Funktion durchführt (in einem gegebenen Zeitmoment).
Funktionen verschiedener in den Figuren dargestellter Elemente einschließlich jeder als „Mittel", „Mittel zur Bereitstellung eines Sensorsignals", „Mittel zum Erzeugen eines Sendesignals" usw. bezeichneter Funktionsblöcke können durch die Verwendung dedizierter Hardware wie beispielsweise „eines Signalanbieters", „einer Signalverarbeitungseinheit", „eines Prozessors", „einer Steuerung", usw. wie auch als Hardware fähig der Ausführung von Software in Verbindung mit zugehöriger Software bereitgestellt werden. Weiterhin könnte jede hier als „Mittel" beschriebene Entität als „ein oder mehrere Module", „eine oder mehrere Vorrichtungen", „eine oder mehrere Einheiten", usw. implementiert sein oder diesem entsprechen. Bei Bereitstellung durch einen Prozessor können die Funktionen durch einen einzigen dedizierten Prozessor, durch einen einzelnen geteilten Prozessor oder durch eine Vielzahl einzelner Prozessoren bereitgestellt werden, von denen einige geteilt sein können. Weiterhin soll ausdrückliche Verwendung des Begriffs „Prozessor" oder „Steuerung" nicht als ausschließlich auf zur Ausführung von Software fähige Hardware bezogen ausgelegt werden, und kann implizit ohne Begrenzung Digitalsignalprozessor-(DSP-)Hardware, Netzprozessor, anwendungsspezifische integrierte Schaltung (ASIC = Application Specific Integrated Circuit), feldprogrammierbare Logikanordnung (FPGA = Field Programmable Gate Array), Nurlesespeicher (ROM – Read Only Memory) zum Speichern von Software, Direktzugriffsspeicher (RAM = Random Access Memory) und nichtflüchtige Speichervorrichtung (storage) einschließen. Auch kann sonstige Hardware, herkömmliche und/oder kundenspezifische, eingeschlossen sein.
Der Fachmann sollte verstehen, dass alle hiesigen Blockschaltbilder konzeptmäßige Ansichten beispielhafter Schaltungen darstellen, die die Grundsätze der Offenbarung verkörpern. Auf ähnliche Weise versteht es sich, dass alle Flussdiagramme, Ablaufdiagramme, Zustandsübergangsdiagramme, Pseudocode und dergleichen verschiedene Prozesse darstellen, die im Wesentlichen in computerlesbarem Medium dargestellt und so durch einen Computer oder Prozessor ausgeführt werden, ungeachtet dessen, ob ein solcher Computer oder Prozessor ausdrücklich dargestellt ist.
Weiterhin sind die nachfolgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wo jeder Anspruch als getrenntes Ausführungsbeispiel für sich stehen kann. Wenn jeder Anspruch als getrenntes Ausführungsbeispiel für sich stehen kann, ist zu beachten, dass obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine besondere Kombination mit einem oder mehreren anderen Ansprüchen beziehen kann andere Ausführungsbeispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs einschließen können. Diese Kombinationen werden hier vorgeschlagen, sofern nicht angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Weiterhin sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt abhängig von dem unabhängigen Anspruch gemacht ist.
Es ist weiterhin zu beachten, dass in der Beschreibung oder in den Ansprüchen offenbarte Verfahren durch eine Vorrichtung mit Mitteln zum Durchführen jedes der jeweiligen Schritte dieser Verfahren implementiert sein können.
Weiterhin versteht es sich, dass die Offenbarung vielfacher, in der Beschreibung oder den Ansprüchen offenbarter Schritte oder Funktionen nicht als in der bestimmten Reihenfolge befindlich ausgelegt werden sollte. Durch die Offenbarung von vielfachen Schritten oder Funktionen werden diese daher nicht auf eine bestimmte Reihenfolge begrenzt, es sei denn, dass diese Schritte oder Funktionen aus technischen Gründen nicht austauschbar sind. Weiterhin kann in einigen Ausführungsbeispielen ein einzelner Schritt mehrere Teilschritte einschließen oder in diese aufgebrochen werden. Solche Teilschritte können eingeschlossen sein und Teil der Offenbarung dieses Einzelschritts sein, sofern sie nicht ausdrücklich ausgeschlossen sind.

Claims

Ein Verfahren (100) zum Bestimmen einer Integrität einer Ausführung eines Codefragments, umfassend: Identifizieren (102) einer Referenzsignatur für das Codefragment innerhalb einer abstrahierten Repräsentation eines Programmcodes, der das Codefragment umfasst; Ausführen (104) des Codefragments; Bestimmen (106) einer Signatur des ausgeführten Codefragments; und Vergleichen (108) der Signatur mit der Referenzsignatur.
Das Verfahren gemäß Anspruch 1, wobei das Identifizieren (102) der Referenzsignatur unabhängig von dem Ausführen (104) des Codefragments und dem Bestimmen (106) der Signatur des ausgeführten Codefragments durchgeführt wird.
Das Verfahren gemäß einem der vorangehenden Ansprüche, ferner umfassend: Ausführen einer Alarmroutine, wenn die Signatur sich von der Referenzsignatur unterscheidet.
Das Verfahren gemäß Anspruch 3, wobei die Alarmroutine eine Löschung von Daten aus einem Speicher und/oder einem Register verursacht.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das Codefragment einen Basisblock des Programmcodes umfasst, wobei ein Basisblock eine Sequenz von Anweisungen ist, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei die abstrahierte Repräsentation eine verknüpfte Liste umfasst, die eine Mehrzahl von Knoten umfasst, wobei zumindest ein Knoten aus der Mehrzahl von Knoten auf das Codefragment bezogen ist.
Das Verfahren gemäß Anspruch 6, wobei das Codefragment einen Basisblock des Programmcodes umfasst, wobei ein Basisblock eine Sequenz von Anweisungen ist, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann.
Das Verfahren gemäß Anspruch 7, wobei der zumindest eine Knoten aus der Mehrzahl von Knoten eine Referenzsignatur für den Basisblock umfasst.
Das Verfahren gemäß Anspruch 6 oder Anspruch 7, wobei der zumindest eine Knoten ferner zumindest eine Referenz zu einem anderen Knoten aus der Mehrzahl von Knoten umfasst, wobei der andere Knoten auf einen weiteren Basisblock bezogen ist, wobei der weitere Basisblock die nächste Sequenz von Anweisungen ist, die innerhalb des Programmcodes ausgeführt werden soll.
Das Verfahren gemäß einem der Ansprüche 5 oder 7 bis 9, wobei die letzte Anweisung der Sequenz von Anweisungen eine Verzweigungsanweisung ist.
Das Verfahren gemäß einem der vorangehenden Ansprüche, wobei das Codefragment ein Fragment eines Bytecodes ist.
Ein Verfahren (400) zum Bereitstellen einer abstrahierten Repräsentation eines Programmcodes, umfassend: Identifizieren (402) eines Basisblocks innerhalb des Programmcodes, wobei der Basisblock eine Sequenz von Anweisungen ist, die nur an der ersten Anweisung der Sequenz von Anweisungen begonnen wird und die nur von der letzten Anweisung der Sequenz von Anweisungen verlassen werden kann; Bestimmen (404) einer Referenzsignatur für den Basisblock; Bestimmen (406) einer Referenz zu einem weiteren Basisblock, wobei der weitere Basisblock die nächste Sequenz von Anweisungen ist, die innerhalb des Programmcodes ausgeführt werden soll.
Das Verfahren gemäß Anspruch 12, ferner umfassend: Hinzufügen von Information über den Basisblock und seine zugeordnete Referenzsignatur zu einem Knoten einer Liste; und Speichern der Liste und des Programmcodes.
Das Verfahren gemäß Anspruch 12 oder Anspruch 13, wobei die letzte Anweisung der Sequenz von Anweisungen eine Verzweigungsanweisung ist.
Das Verfahren gemäß einem der Ansprüche 12 bis 14, wobei der Programmcode ein Bytecode ist.
Eine Programmausführungsmaschine (610), die ausgebildet ist zum Durchführen des Verfahrens gemäß einem der Ansprüche 1 bis 15.
Die Programmausführungsmaschine gemäß Anspruch 16, wobei die Programmausführungsmaschine (610) einen Interpretierer für einen Bytecode umfasst.
Die Programmausführungsmaschine gemäß Anspruch 16 oder Anspruch 17, wobei der Bytecode auf Java basiert.
Eine Chipkarte (600), die die Programmausführungsmaschine (610) gemäß einem der Ansprüche 16 bis 18 umfasst.
Ein Computerprogramm mit einem Programmcode, der ausgebildet ist zum Durchführen des Verfahrens gemäß einem der Ansprüche 1 bis 15, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird.