Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR EXECUTING AN APPLICATION
Document Type and Number:
WIPO Patent Application WO/2011/095320
Kind Code:
A1
Abstract:
The invention describes a method for executing an application (A) which comprises executable native or interpretable code and calls functions of an operating system (BS), wherein the operating system (BS) transmits a result of a respective function call (f1) to the application (A). The method according to the invention is distinguished by the fact that the application (A) checks the result of a respective function call with regard to tampering in order to detect an attack.

Inventors:
JAUERING MATTHIAS (DE)
HILMER DOROTHEE (DE)
HOLTMANN LUDGER (DE)
TREGER JOERN (DE)
FLADEE INGEBORG (DE)
Application Number:
PCT/EP2011/000451
Publication Date:
August 11, 2011
Filing Date:
February 01, 2011
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
GIESECKE & DEVRIENT GMBH (DE)
JAUERING MATTHIAS (DE)
HILMER DOROTHEE (DE)
HOLTMANN LUDGER (DE)
TREGER JOERN (DE)
FLADEE INGEBORG (DE)
International Classes:
G06F21/77
Domestic Patent References:
WO2009138892A12009-11-19
Foreign References:
EP1892639A22008-02-27
Other References:
W. RANKL, W. EFFING: "Handbuch der Chipkarten", 1 January 2008, HANSER VERLAG, München, ISBN: 978-3-446-40402-1, pages: 494 - 495, XP002643427
HAGAI BAR-EL ET AL: "The Sorcerer's Apprentice Guide to Fault Attacks", INTERNET CITATION, 7 May 2004 (2004-05-07), XP002329915, Retrieved from the Internet [retrieved on 20050527]
Attorney, Agent or Firm:
GIESECKE & DEVRIENT GMBH (DE)
Download PDF:
Claims:
P a t e n t a n s p r ü c h e

Verfahren zum Ausführen einer Anwendung (A), die ausführbaren nativen oder interpretierbaren Code umfasst und Funktionen eines Betriebssystems (BS) aufruft, wobei das Betriebssystem (BS) ein Ergebnis eines jeweiligen Funktionsaufrufs (fl) an die Anwendung (A) überträgt, dadurch gekennzeichnet, dass die Anwendung (A) das Ergebnis eines jeweiligen Funktionsaufrufs auf eine Verfälschung hin überprüft, um einen Angriff zu erkennen.

Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass das Verfahren auf einem tragbaren Datenträger (CC), insbesondere einer Chipkarte oder einem Sicherheitsmodul, ausgeführt wird.

Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass zur Überprüfung des Ergebnisses eines jeweiligen Funktionsaufrufs (fl) eine weitere Funktion des Betriebssystems (BS) durch die Anwendung (A) aufgerufen wird.

Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Aufruf einer jeweiligen Funktion des Betriebssystems (BS) durch die Anwendung (A) über eine erste Schnittstelle (ST1) und der Aufruf der weiteren Funktion durch die Anwendung (A) über eine zweite, insbesondere proprietäre, Schnittstelle (ST2) erfolgt.

Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine zentrale, einheitliche Überprüfung jeweiliger Ergebnisse unterschiedlicher Funktionsaufrufe durchgeführt wird. Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass eine Überprüfung des letzten Funktionsaufrufs erfolgt.

Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Überprüfung des Ergebnisses eines jeweiligen Funktionsaufrufs das von dem Betriebssystem (BS) ermittelte und an die Anwendung (A) übertragene Ergebnis an das Betriebssystem (BS) übertragen und durch dieses verifiziert wird.

Verfahren nach einem der Ansprüche 2 bis 7, dadurch gekennzeichnet, dass in Abhängigkeit des Ergebnisses der Überprüfung das weite re Verhalten des tragbaren Datenträgers (CC) durch die Anwendung (A) gesteuert wird.

Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass die Steuerung des weiteren Verhaltens des tragbaren Datenträgers (CC) eine Zeitverzögerung und/ oder eine Abschaltung umfasst.

Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass als Anwendung ein Java- Applet und als Betriebssystem eine Java virtuelle Maschine verwendet werden.

Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass zur Überprüfung des Ergebnisses eines jeweiligen Funktionsaufrufs ein Parameter an das Betriebssystem (BS) übertragen und durch dieses verifiziert wird, wobei der Parameter den Funktionsaufruf identifiziert. Tragbarer Datenträger (CC), insbesondere Chipkarte, Sicherheitsmodul oder USB-Token, der dazu ausgebildet ist, ein Verfahren gemäß einem der vorhergehenden Ansprüche auszuführen.

Tragbarer Datenträger (CC), insbesondere Chipkarte, Sicherheitsmodul oder USB-Token, mit einem Betriebssystem (B) und einer ersten Schnittstelle (ST1), welche einer auf dem Datenträger ausführbaren Anwendung (A), die ausführbaren nativen oder interpretierbaren Code umfasst, den Aufruf von Funktionen des Betriebssystems (BS) ermöglicht, wobei das Betriebssystem (BS) eingerichtet ist ein Ergebnis eines jeweiligen Funktionsaufrufs (fl) an die Anwendung (A) zu übertragen, dadurch gekennzeichnet, dass das Betriebssystem eine zweite Schnittstelle (ST2) für die Anwendung bereitstellt, über welche die Anwendung dem Betriebssystem einen erkannten Angriff melden kann.

Description:
V e r f a h r e n z u m A u s f ü h r e n e r A n w e n

d u n g

Die Erfindung betrifft ein Verfahren zum Ausführen einer Anwendung, die ausführbaren nativen oder interpretierbaren Code umfasst und Funktionen eines Betriebssystems aufruft, wobei das Betriebssystem ein Ergebnis eines jeweiligen Funktionsaufrufs an die Anwendung überträgt. Die Erfindung betrifft weiterhin einen tragbaren Datenträger, insbesondere eine Chipkarte oder ein Sicherheitsmodul.

Auf dem Gebiet von Chipkarten sind sog. Fehler induzierende Angriffe bekannt, die den Programmablauf oder den Speicherinhalt eines Speichers der Chipkarte manipulieren. Beispielsweise kann bei einem Angriff mit Hilfe der differentiellen Fehleranalyse (DFA) versucht werden, geheime Schlüssel durch selektive Einstreuung von Fehlberechnungen zu erspähen. Mit Hilfe eines Lichtangriffs wird versucht, einen Sicherheitsstatus der Chipkarte gezielt zu verändern, um geheime Daten auszulesen, die ansonsten nur beim Vorliegen einer Authentisierung lesbar wären. Gegen derartige Angriffe wurden diverse Abwehrmechanismen entwickelt, die sowohl auf Softwareais auch auf Hardwaremaßnahmen basieren. Die Angriffserkennung erfolgt dabei regelmäßig durch ein Betriebssystem der Chipkarte oder durch die von Anwendungen auf der Chipkarte aufrufbaren Funktionen des Betriebssystems.

Bei einem tragbaren Datenträger mit einer Anwendung, die Funktionen eines Betriebssystems aufruft und ausführbaren nativen oder interpretierbaren Code enthält, kann das Ergebnis des Funktionsaufrufs durch einen Angriff, beispielsweise einen Lichtangriff, verfälscht werden, ohne dass die Anwen- dung eine Möglichkeit hat, die Verfälschung zu erkennen. Es ist daher Aufgabe der vorliegenden Erfindung, ein Verfahren anzugeben, mit dem die Sicherheit beim Ausführen einer Anwendung weiter verbessert werden kann. Eine weitere Aufgabe der Erfindung ist es, einen tragbaren Datenträger anzugeben, welcher beim Ausführen einer Anwendung eine verbesserte Sicherheit aufweist.

Diese Aufgaben werden gelöst durch ein Verfahren gemäß den Merkmalen des Patentanspruchs 1 sowie einen tragbaren Datenträger gemäß den Merkmalen des Patentanspruchs 11. Vorteilhafte Ausgestaltungen ergeben sich aus den abhängigen Patentansprüchen.

Die Erfindung schafft ein Verfahren zum Ausführen einer Anwendung, die ausführbaren nativen oder interpretierbaren Code umfasst und Funktionen eines Betriebssystems aufruft, wobei das Betriebssystem ein Ergebnis eines jeweiligen Funktionsaufrufs an die Anwendung überträgt. Erfindungsgemäß überprüft die Anwendung das Ergebnis eines jeweiligen Funktionsaufrufs auf eine Verfälschung hin, um einen Angriff zu erkennen. Durch das erfindungsgemäße Vorgehen kann die Sicherheit gegenüber Manipulationen erhöht werden. Im Unterschied zum Stand der Technik erfolgt eine Überprü- f ng einer Manipulation nicht durch das Betriebssystem, sondern durch die Anwendung selbst, welche die Funktionen des Betriebssystems aufruft.

Insbesondere wird bei solchen Anwendungen eine Verbesserung der Sicherheit geschaffen, bei denen das Betriebssystem der Anwendung als Ergebnis lediglich eine boolesche Variable liefert. Dies ist beispielsweise beim Verifizieren von Signaturen der Fall. Hier wird jeder Ergebniswert, der ungleich Null ist, durch die Anwendung als wahr interpretiert. Dabei ist die Wahrscheinlichkeit für einen erfolgreichen Angriff auf den von dem Betriebssystem an die Anwendung übertragenen Ergebniswert stark erhöht, da jedes verfälschte Ergebnis zur erfolgreichen Verifikation einer ungültigen Signatur führt. Durch die Erfindung erfolgt die Überprüfung der an die Anwendung übertragenen Ergebnisse durch die Anwendung selbst, wodurch im Falle eines erkannten Angriffs geeignete Gegenmaßnahmen ergriffen werden können.

Das erfindungsgemäße Verfahren wird insbesondere auf einem tragbaren Datenträger, insbesondere einer Chipkarte oder einem Sicherheitsmodul, ausgeführt.

Zweckmäßigerweise wird zur Überprüfung des Ergebnisses eines jeweiligen Funktionsaufrufs eine weitere Funktion des Betriebssystems durch die Anwendung aufgerufen. Dabei ist insbesondere vorgesehen, dass der Aufruf einer jeweiligen Funktion des Betriebssystems durch die Anwendung über eine erste Schnittstelle und der Aufruf der weiteren Funktion durch die Anwendung über eine zweite, insbesondere proprietäre, Schnittstelle erfolgt. Über die zweite Schnittstelle können die Ergebnisse vorangegangener, sicherheitsrelevanter Vorgänge auf einfache Weise überprüft werden, ohne die Arbeits- und Funktionsweise der ersten Schnittstelle beeinflussen zu müssen. Durch die Erweiterung um die zweite Schnittstelle kann damit auch eine

Überprüfung von durch ein Betriebssystem übertragenen Ergebnissen in solchen Umgebungen erfolgen, welche standardisiert und nicht abwandelbar sind. Eine weitere Ausgestaltung sieht vor, dass eine zentrale, einheitliche Überprüfung jeweiliger Ergebnisse unterschiedlicher Funktionsaufrufe durchgeführt wird. Insbesondere ist vorgesehen, dass eine Überprüfung des letzten Funktionsaufrufs erfolgt. Anhand dieser Überprüfung kann festgestellt werden, ob die aufgerufenen Funktionen tatsächlich ausgeführt wurden und ob der erhaltene Rückgabewert auch dem tatsächlichen Ergebnis entspricht. Auf diese Weise können Angriffe mit hoher Wahrscheinlichkeit erkannt werden.

Eine weitere Ausgestaltung sieht vor, dass zur Überprüfung des Ergebnisses eines jeweiligen Funktionsaufrufs das von dem Betriebssystem ermittelte und an die Anwendung übertragene Ergebnis an das Betriebssystem übertragen und durch dieses verifiziert wird. Die Übertragung des Ergebnisses von der Anwendung an das Betriebssystem erfolgt dabei vorzugsweise über die zweite Schnittstelle, wodurch bestehende Standards hinsichtlich der Kommunikation zwischen Anwendung und Betriebssystem über die erste Schnittstelle nicht verändert oder erweitert werden brauchen.

In vorteilhafter Weise kann in Abhängigkeit des Ergebnisses der Überprüfung das weitere Verhalten des tragbaren Datenträgers durch die Anwen- dung gesteuert werden. Die Steuerung des weiteren Verhaltens des tragbaren Datenträgers umfasst eine Zeitverzögerung und/ oder eine Abschaltung des Datenträgers. Die jeweils ausgewählte Reaktion kann in Abhängigkeit des Ergebnisses der Überprüfung durch die Anwendung erfolgen. Ein Angriff auf den Aufruf der Funktion könnte bereits die aufgerufene

Funktion verändern. Eine weitere Absicherung ist gegen (korrekte) Ergebnisse einer falschen, d.h. nicht der von der Anwendung aufgerufenen, Funktion möglich. Neben dem Ergebnis eines Funktionsaufrufes kann die Anwendung auch prüfen, ob tatsächlich die aufgerufene Funktion ausgeführt wurde. Die Anwendung überträgt einen Prüfparameter an das Betriebssystem, der die aufgerufene Funktion identifiziert. Das Betriebssystem hat einen Referenzparameter für die (zuletzt) aufgerufene Funktion gespeichert und prüft diesen gegen den Prüfparameter. Der Parameter wird vorzugsweise zusammen mit dem Ergebnis an das Betriebssystem übertragen und der Parameter im Rah- men der Prüfung des Ergebnisses geprüft. Sollte also eine andere als die aufgerufene Funktion das Ergebnis geliefert haben, wird dies im Rahmen der Prüfung erkannt. Der überprüfte Funktionsaufruf soll vorzugsweise der letzte Funktionsaufruf sein. Nicht alle Funktionsaufrufe der Anwendung müssen aber sicherheitsrelevante Funktionen sein. Die weiteren Funktionsaufrufe werden jedoch nicht wie vorliegend vorgeschlagen abgesichert, ihr Ergebnis wird also vom Betriebssystem nicht für eine Prüfung gespeichert. Insbesondere soll die Über- prüfung des Ergebnisses jeweils für den letzten sicherheitsrelevanten Funktionsaufruf möglich sein. Nur die Ergebnisse sicherheitsrelevanter Funktionsaufrufe sind überprüfbar. Es können weitere (nicht sicherheitsrelevante) Funktionsaufrufe zwischen dem Aufruf der sicherheitsrelevanten Funktion und dem Prüfen des Ergebnisses der zuletzt aufgerufenen sicherheitsrele- vanten Funktion durch die Anwendung stattfinden.

In einer konkreten Ausgestaltung wird als Anwendung ein Java Card Applet und als Betriebssystem eine Java Card VM (Virtuelle Maschine) verwendet. Bei dem Datenträger, auf dem Anwendung und Betriebssystem laufen, han- delt es sich bevorzugt um eine Java-Card.

Ein erfindungsgemäßer Datenträger, der insbesondere in Gestalt einer Chipkarte oder eines Sicherheitsmoduls ausgebildet ist, ist dazu ausgebildet, das oben beschriebene, erfindungsgemäße Verfahren auszuführen.

Die Erfindung wird nachfolgend näher anhand der Figuren beschrieben. Es zeigen:

Fig. 1 einen schematischen Ablauf des erfindungsgemäßen Verfahrens, und Fig. 2 eine schematische Darstellung eines erfindungsgemäßen tragbaren Datenträgers. Die vorliegende Erfindung geht von einer Anwendung A aus, die Funktionen eines Betriebssystems BS aufruft. Die Anwendung A enthält zu diesem Zweck ausführbaren nativen oder interpretierbaren Code. Obwohl die Erfindung allgemein auf jegliche Anwendung, die auf einem Betriebssystem läuft, anwendbar ist, wird im nachfolgend beschriebenen Ausführungsbeispiel von einer Java-Karte als tragbarem Datenträger ausgegangen, auf welcher eine virtuelle Maschine Funktionsaufrufe eines Java- Applets bearbeitet.

Die Anwendung A kann über zwei Schnittstellen STl, ST2 auf das Betriebssystem BS der Java-Card CC zugreifen (vgl. Fig. 2). Über die erste Schnittstel- le STl werden durch die Anwendung A Funktionen des Betriebssystems BS aufgerufen. Bei der ersten Schnittstelle STl handelt es sich beispielsweise um eine Java-Card API. Die zweite Schnittstelle ST2, welche insbesondere proprietärer Natur ist, bietet der Anwendung zusätzliche Funktionen, welche geeignet sind die Sicherheit zu erhöhen. Insbesondere kann die Anwen- dung mittel der Schnittstelle ST2, ein von dem Betriebssystem BS an die Anwendung A in Folge eines Funktionsaufrufs übertragenes Ergebnis überprüfen.

Das Vorsehen der zusätzlichen, zweiten Schnittstelle ST2 behebt sicherheits- kritische Schwachstellen, wie diese beispielsweise in der Java-Card API von Sun Microsystems bestehen. Die Java-Card API liefert mit Ausnahme des Befehls„Verify PIN", bei dem ein Status modifiziert wird, der von der Anwendung beim Betriebssystem abgefragt werden kann, einen booleschen Wert an die Anwendung A zurück. Bei sicherheitsrelevanten Funktionen, wie z.B. dem Verifizieren von Signaturen, wird als Rückgabe somit lediglich ein boolescher Wert verwendet, der an die Anwendung A zurückgegeben wird. Zwar wird dieser intern zu einem 2-Bytewert erweitert. Jedoch wird jeder Wert der ungleich Null ist, als wahr interpretiert. Daher ist die Wahr- scheinlichkeit für einen erfolgreichen Angriff auf den Rückgabewert stark erhöht, da jedes verfälschte Ergebnis zur erfolgreichen Verifikation einer ungültigen Signatur führt, ohne dass die Anwendung A einen solchen Angriff erkennen kann. Durch die zweite, proprietäre Schnittstelle ST2 kann die Sicherheit gegenüber Manipulationen erhöht werden, indem die von dem Betriebssystem BS an die Anwendung A zurückgelieferten Ergebnisse überprüft werden. In Abhängigkeit vom Ergebnis der Überprüfung kann die Java-Card gegebenenfalls in einen gesicherten Zustand versetzt werden.

Die zweite Schnittstelle ST2 ermöglicht die Bereitstellung neuer Funktionen zur Überprüfung der Ergebnisse vorangegangener, sicherheitsrelevanter Vorgänge. Hierzu kann unabhängig vom Ergebniswert, der von dem Betriebssystem BS an die Anwendung A über die erste Schnittstelle ST1 zu- rückgegeben wird, intern ein weiterer Ergebniswert geführt werden, der an geeigneter Stelle im Programmablauf durch die Anwendung A abgefragt werden kann. Anhand dieses Ergebniswerts kann überprüft werden, ob die aufgerufenen Funktionen der Anwendung durch das Betriebssystem tatsächlich ausgeführt wurden. Hiermit erfolgt eine Verifikation, ob der von dem Betriebssystem erhaltene Ergebniswert auch dem tatsächlichen Ergebnis entspricht. Darüber hinaus wird durch die zweite Schnittstelle ST2 bereitgestellte Methoden die Möglichkeit geboten, auf das Ergebnis einer Überprüfung zu reagieren. Beispielsweise kann die Java-Card abgeschaltet werden oder das zeitliche Verhalten der Java-Card verändert werden. Durch die Bereitstellung der zweiten Schnittstelle ST2 können von dem Betriebssystem BS an die Anwendung A übertragene Ergebniswerte unabhängig überprüft werden. Auf diese Weise ist die erfolgreiche Erkennung von Angriffen und / oder Manipulationen möglich.

Die zweite Schnittstelle ST2 kann einer Anwendung das Melden eines erkannten Angriffs ermöglichen. Fig. 1 stellt das beschriebene Verhalten der beschriebenen Java-Card schematisch dar. Die Anwendung A ruft in einem Verfahrensschritt Sl eine Funktion f 1 des Betriebssystems BS auf. In Schritt S2 führt das Betriebssystem BS die Funktion fl aus und speichert das hieraus hervorgehende Ergebnis ab. Weiterhin wird das Ergebnis über die erste Schnittstelle ST1 an die Anwen- dung A übertragen. Wird als Ergebniswert lediglich ein boolscher Wert an die Anwendung A als Ergebnis übertragen, so kann dieses auf einfache Weise verfälscht werden. Dies ist in Fig. 1 angenommen und schematisch durch den Pfeil angedeutet. Die Anwendung A empfängt somit zunächst von dem Betriebssystem BS als Ergebnis den Wert„Ergebnis*". In Schritt S3 wird der Ergebniswert„Ergebnis*" überprüft, indem dieser an das Betriebssystem BS übertragen wird. Das Betriebssystem BS überprüft den von der Anwendung A erhaltenen Ergebnis wert„Ergebnis*". Hierbei wird festgestellt, dass„Ergebnis*" nicht mit dem in Schritt S2 an die Anwendung A übertragenen Ergebniswert„Ergebnis" übereinstimmt. In Reaktion hierauf übermittelt das Betriebssystem BS in Schritt S4 eine Information„NIO", welche eine Nichtübereinstimmung des in Schritt S2 an die Anwendung A übermittelten Ergebniswerts und des überprüften Ergebniswerts signalisiert. In Schritt S5 wird somit durch die Anwendung A ein Angriff erkannt. Die Kommunikation zwischen der Anwendung A und dem Betriebssystem BS erfolgt in den Schritten S3, S4 und S5 über die zweite Schnittstelle ST2. Über die Schnittstelle ST2 wird es der Anwendung A ferner ermöglicht, auf den in Schritt S5 erkannten Angriff zu reagieren. Optional kann die Anwen- dung dem Betriebssystem den erkannten Angriff mitteilen. Das Betriebssystem könnte unmittelbar auf diese Meldung reagieren. Vorzugsweise wartet das Betriebssystem jedoch zunächst darauf, dass die Anwendung eine Reaktion auf den Angriff steuert. In Schritt S6 wird eine Anforderung einer Zeitverzögerung an das Betriebssystem BS übertragen. Dieses nimmt in Schritt S7 eine Zeitverzögerung des Ablaufs der Java-Card vor. Die von der Anwendung A angeforderte Zeitverzögerung kann eine zufällige Zeitdauer aufweisen. Alternativ oder zusätzlich kann gemäß Schritt S8 die Anforderung einer Abschaltung der Java-Card an das Betriebssystem BS übertragen werden. Nach Erhalt der Anforderung wird die Java-Card in Schritt S9 durch das Betriebssystem abgeschaltet. Die Schnittstelle ST2 bietet einer Anwendung insbesondere auch folgende, zusätzliche Funktionen, die nicht in Figur 2 dargestellt sind:

- Melden eines durch die Anwendung erkannten Angriffs,

- Bedingte Abschaltungs- Anforderung an das Betriebssystem, welche ein Abschalten durch das Betriebssystem auslöst, falls zuvor ein Fehler erkannt oder gemeldet wurde und

- Rücksetzen des Ergebniswertspeichers des letzten Funktionsaufrufes in einen vordefinierten Zustand. Die Meldung eines erkannten Angriffs ermöglicht eine flexiblere Steuerung durch die Anwendung und/ oder bietet dem Betriebssystem eine bessere Entscheidungsgrundlage für eventuelle eigene Steuerungsmaßnahmen. In einer sichereren Ausgestaltung wird das Ergebnis der Angriffsprüfung unabhängig von dem Ergebnis gemeldet. Auch eine bedingte Abschaltungsanforderung kann durch die Anwendung stets durchlaufen werden. Durch diese beiden Teilschritte wird der Ablauf unabhängig vom Ergebnis der Prüfung.

Das Rücksetzen eines Ergebniswertspeichers ermöglicht der Anwendung letztlich sogar eine Erkennung eines gezielten Angriffs auf die Ergebnisprüfung des Funktionsaufrufes. Wird der Ergebniswertspeicher des Betriebssystems beispielsweise auf den Wert„0" rückgesetzt, kann die Anwendung mit einem Aufruf mit einem Ergebnis„1" die Funktion selbst testen. Diese Prüfung wäre dann sogar unabhängig von tatsächlichen Funktionsaufrufen möglich.