DE102005056357A1

DE102005056357A1 - Multithreading-fähige virtuelle Maschine

Info

Publication number: DE102005056357A1
Application number: DE102005056357A
Authority: DE
Inventors: Wolfgang Effing; Stephan Dr. Spitz
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2005-11-25
Filing date: 2005-11-25
Publication date: 2007-05-31
Also published as: EP1801696B1; EP1801696A2; ATE551647T1; EP1801696A3

Abstract

Auf einem portablen Datenträger (1; 10) wird eine virtuelle Maschine (5a-5c; 22, 23) unter Kontrolle eines Betriebssystemkerns (3; 16) mehrfach nebenläufig ausgeführt, wobei die nebenläufig ausgeführten virtuellen Maschinen (5a-5c; 22, 23) ihrerseits Applikationen (6a-6f; 24-27) nebenläufig ausführen. Der Betriebssystemkern (3; 16) teilt jeder ausgeführten virtuellen Maschine (5a-5c; 22, 23) ein individuelles Kontingent von Betriebsmitteln zu, auf das die von der jeweiligen virtuellen Maschine (5a-5c; 22, 23) ausgeführten Applikationen (6a-6f; 24-27) zugreifen können. Der Betriebsystemkern (3; 16) ordnet einer auszuführenden Applikation (18-21) anhand ihrer Zugriffsberechtigung Betriebsmittel zur Ausführung einer virtuellen Maschine (5a-5c; 22, 23) zu. Dadurch besitzt der Betriebssystemkern (3; 16) die unmittelbare Kontrolle über die Betriebsmittelvergabe, während die Applikationsprozesse (6a-6f; 24-27) der virtuellen Maschinen (5a-5c; 22, 23) von dem Betriebssystemkern (3; 16) weitgehend unabhängig sind.

Description

Die vorliegende Erfindung betrifft ein Verfahren zum Ausführen von Applikationen durch eine auf einem portablen Datenträger installierte virtuelle Maschine sowie einen entsprechend eingerichteten portablen Datenträger.

Es ist ein bekanntes Konzept bei gängigen Computern und insbesondere bei portablen Datenträgern, wie z.B. Chipkarten, und eingebetteten Systemen („Embedded Systems"), die Ausführung von plattformunabhängigen und portierbaren Applikationen mittels einer auf dem Computer installierten virtuellen Maschine zu ermöglichen. Die Installation einer virtuellen Maschine z.B. auf einem portablen und mit einem Prozessor ausgestatteten Datenträger, wie z.B. einer Chipkarte, schafft eine von der eigentlichen Hardware und den spezifischen Vorgaben des Betriebssystems des Datenträgers unabhängige Laufzeitumgebung. Innerhalb dieser Laufzeitumgebung können plattformunabhängige und demzufolge leicht portierbare Applikationen entwickelt und ausgeführt werden, die ausschließlich die Vorgaben der virtuellen Maschine zu berücksichtigen haben. Mittels einer virtuellen Maschine wird also von der konkreten Hardware des Datenträgers bzw. seines Betriebssystems derart abstrahiert, dass anstelle auf die spezifischen Programmierschnittstellen des hardwarenäheren Betriebssystems lediglich auf die von der virtuellen Maschine bereitgestellten plattformunabhängigen Programmierschnittstellen, beispielsweise API (Application Programming Interface) oder ByteCode-Interpreter, zugegriffen werden muss. Die virtuelle Maschine fungiert also als Schnittstelle zwischen einer plattformunabhängig programmierten Applikation und dem hardwarenäheren Betriebssystem. Das Betriebssystem umfasst neben einer Vielzahl von Systemprogrammen einen Betriebssystemkern für zentrale und sicherheitskritische Aufgaben, der die eigentliche Schnittstelle zur Hardware bildet und z.B. die Prozess- und Betriebsmittelverwaltung übernimmt. Dabei werden die Prozesse und/oder Threads der virtuellen Maschine von dem Betriebssystem in Betriebssystem prozesse umgesetzt, welche von dem Prozessor des Computers bzw. der Chipkarte ausgeführt werden können.

Problematisch kann es sein, wenn auf einer virtuellen Maschine mehrere Applikationen nebenläufig ausgeführt werden. Insbesondere bei sicherheitskritischen Applikationen, zum Beispiel bei der Authentifikation oder Identifikation von Personen oder bei der kryptografischen Sicherung, ist es wichtig, dass die von der virtuellen Maschine nebenläufig ausgeführten Applikationen logisch strikt voneinander getrennt sind. Auch der Zugriff der Applikationen auf die Betriebsmittel des Computers muß entsprechend kontrolliert werden. Das betrifft z.B. die Inanspruchnahme von Prozessorzeit oder Speicherplatz oder Zugriffe auf Ein-/Ausgabeschnittstellen.

Es ist andererseits auch möglich, in einem multitaskingfähigen Betriebssystem zur logischen Separation der auszuführenden Applikationen für jede Applikation eine eigene virtuelle Maschine auszuführen. Anders als bei der nebenläufigen Ausführung mehrerer Applikationen auf derselben virtuellen Maschine ist es hierbei möglich, jede Applikation bzw. jeden Ausführungspfad (Thread) einer Applikation unmittelbar auf Betriebssystemprozesse abzubilden. So kann der Zugriff der Applikationen auf Betriebsmittel von dem Betriebssystem kontrolliert werden. Es besteht jedoch das Problem, dass die Umsetzung jeder Applikation bzw. jeden Ausführungsdfades in korrespondierende Betriebssystemprozesse ("native threads") aufgrund eines erhöhten Verwaltungsaufwands vergleichsweise ineffizient und zumindest für portable Datenträger, die nur mit geringen Ressourcen ausgestattet sind, oftmals nichtmöglich ist.

Bei einer alternativen Technik der sogenannten "green threads" schottet dagegen eine virtuelle Maschine die von ihr ausgeführten Applikationsprozes se von dem Betriebssystem ab. Dadurch ergibt sich einerseits zwar eine geringere Abhängigkeit der Applikationen von dem Betriebssystem, andererseits ist eine kontrollierte Betriebsmittelvergabe durch das Betriebssystem nicht möglich, sondern erfolgt durch die virtuelle Maschine.

Es ist demzufolge die Aufgabe der vorliegenden Erfindung, die Ausführung von Applikationen durch virtuelle Maschinen sicher und effizient zu gestalten, so dass sie auch für portable Datenträger geeignet ist.

Diese Aufgabe wird erfindungsgemäß durch ein Verfahren und einen portablen Datenträger mit den Merkmalen der unabhängigen Ansprüche gelöst. Die abhängigen Ansprüche beschrieben vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung.

Erfindungsgemäß wird auf einem portablen Datenträger eine virtuelle Maschine unter Kontrolle eines Betriebssystemkerns mehrfach nebenläufig ausgeführt. Hierbei führt zumindest eine der nebenläufig ausgeführten virtuellen Maschinen ihrerseits zumindest zwei Ausführungspfade zumindest einer Applikation nebenläufig aus. Der Betriebssystemkern teilt jeder der ausgeführten virtuellen Maschinen ein bestimmtes Kontingent von Betriebsmitteln zu, auf das die von der virtuellen Maschine ausgeführten Ausführungspfade bzw. Applikationen zugreifen können. Applikationen bzw. Ausführungspfade können also nur auf diejenigen Betriebsmittel zugreifen, die in dem Betriebsmittelkontingent enthalten sind, welches der ausführenden virtuellen Maschine von dem Betriebssystemkern zugeteilt wurde.

Durch die direkte Zuteilung von verschiedenen Betriebsmittelkontingenten an nebenläufig ausgeführte virtuelle Maschinen, die ihrerseits mehrere Applikationen bzw. Ausführungspfade nebenläufig ausführen können, besitzt der Betriebssystemkern die unmittelbare Kontrolle über die Betriebsmittelvergabe an eine Gruppe von Ausführungspfaden und/oder Applikationen. Hierdurch wird einerseits ein hohes Sicherheitsniveau erreicht, da der Zugriff von Applikationen auf Betriebsmittel des Datenträgers auf Betriebssystemebene überwacht wird und z.B. von der Vertrauenswürdigkeit einer Applikation abhängig gemacht werden kann. Andererseits wird ein effizientes nebenläufiges Ausführen der Ausführungspfade und/oder Applikationen von einer virtuellen Maschine ermöglicht, da die virtuelle Maschine die Nebenläufigkeit weitgehend unabhängig von dem Betriebssystem des Datenträgers organisieren kann.

Für jede auszuführenden Applikation prüft der Betriebssystemkern zunächst anhand einer Zugriffsberechtigung der Applikation, auf welche Betriebsmittel diese Applikation zugreifen darf. Anschließend wird die Applikation derjenigen virtuellen Maschine zur Ausführung zugewiesen, deren zugeteiltes Betriebsmittelkontingent die Zugriffsberechtigung der auszuführenden Applikation entspricht. Auf diese Weise kann ein differenziertes, vom Betriebssystemkern unmittelbar kontrolliertes Sicherheitssystem aus abgestuften Zugriffsberechtigungen bzw. Betriebsmittelzugriffen aufgebaut werden, das den Ansprüchen eines in einem sicherheitskritischen Kontext operierenden Datenträgers genügt.

Die Zugriffsberechtigung einer Applikation kann beispielsweise aus einer vorhergehenden Benutzerauthentisierung desjenigen Benutzers, der die Applikation ausführen möchte, abgeleitet werden, z.B. aus einer am Datenträger eingegebenen Kennung oder PIN oder einer biometrische Authentisierung. Ebenso ist es möglich, eine im Programmcode der Applikation vorhandene Signatur durch den Betriebssystemkern zu überprüfen und daraus die Sicherheitsstufe für die Applikation abzuleiten und eine dazu passende virtu elle Maschine auszuwählen. Falls zu diesem Zeitpunkt keine virtuelle Maschine ausgeführt wird, die zu der Zugriffsberechtigung der auszuführenden Applikation passt, kann der Betriebssystemkern eine weitere virtuelle Maschine nebenläufig zu den bereits laufenden virtuellen Maschinen starten und dieser ein zu der Zugriffsberechtigung der auszuführenden Applikation korrespondierendes Betriebsmittelkontingent zuteilen.

Der Betriebssystemkern umfasst vorzugsweise eine definierte Zugriffsschnittstelle für die virtuellen Maschinen, über welche eine ausgeführte virtuelle Maschine für eine Applikation bestimmte Betriebsmittel anfordern kann. Über die Zugriffsschnittstelle werden dann auch die angeforderten Betriebsmittel von dem Betriebssystemkern bereitgestellt. Eine derartige definierte Schnittstelle entkoppelt die virtuellen Maschinen von dem multitaskingfähigen Betriebssystemkern und sichert das Betriebssystem sowie die Betriebsmittel des portablen Datenträgers vor missbräuchlichen Zugriffen.

Als weitere Sicherheitsmaßnahme kann der Betriebssystemkern die zu einem Zeitpunkt ausgeführten virtuellen Maschinen logisch voneinander isolieren, z.B. mittels einer Speicherverwaltungseinheit/Speicherschutzeinheit (MMU/MPU, „Memory Management/Protection Unit") des Prozessors des portablen Datenträgers, um die jeweiligen Speicherbereiche der virtuellen Maschinen vor Zugriffen durch nicht berechtigte Prozesse zu schützen. Ebenso ist es möglich, dass eine virtuelle Maschine die von ihr nebenläufig ausgeführten Applikationen aus Sicherheitsgründen logisch voneinander isoliert, z.B. mittels einer Applikations-Firewall der virtuellen Maschine.

Als bevorzugte portable Datenträger kommen z.B. Chipkarten mit Prozessor, sichere Multimediakarten, Mobilfunkkarten, USB-Speichermedien oder dergleichen, aber auch herkömmliche Computer sowie eingebettete Systeme („embedded systems") in Frage. Hierbei ist die auf einem portablen Datenträger ausgeführte virtuelle Maschine vorzugsweise eine virtuelle Java-Maschine bzw. eine Java-Laufzeitumgebung mit einem Java-Interpreter zum Ausführen von Java-Bytecode-Applikationen („Applets"). Ferner ist der portable Datenträger vorzugsweise mit einem Java-Card-Betriebssystem ausgestattet, dessen Betriebssystemkern zentrale Funktionen von Java-Card bereitstellt, insbesondere die Schnittstelle zur Hardware sowie die Prozess- und Betriebsmittelverwaltung. Auf einem mit Java-Card ausgestatteten portablen Datenträger kann dann ein sicherer Web-Server installiert werden, bei dem zur Beantwortung von Client-Anfragen Servlets („Server Applets") von einer virtuellen Java-Maschine bzw. dem entsprechenden Java-Interpreter ausgeführt werden. Die Servlets haben dann nur auf die Betriebsmittel des Betriebsmittelkontingents der entsprechenden virtuellen Maschine Zugriff.

Weitere Merkmale und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung verschiedener erfindungsgemäßer Ausführungsbeispiele und Ausführungsalternativen im Zusammenhang mit den begleitenden Zeichnungen. Darin zeigen:
1 eine schematische Darstellung der Beziehung zwischen Applikationen, virtuellen Maschinen, Betriebssystemkern und Hardware; und
2 einen erfindungsgemäß ausgestatteten portablen Datenträger.
1 illustriert die hierarchischen Beziehungen der Komponenten eines mit einer virtuellen Maschine 5 ausgestatteten portabeln Datenträgers 1 bei der Ausführung von Applikationen 6, ausgehend von der Hardware 2 des Datenträgers 1. Logisch über der Hardware 2 ist das Betriebssystem mit dem hardwarenahen Betriebssystemkern 3 (KERNEL) angeordnet, der die Hardware 2 des Datenträgers 1 verwaltet. Über der Ebene des Betriebssystemkerns 3 liegt die Ebene der von der hardwarenahen Betriebssystemebene abstrahierenden Laufzeitumgebung („Runtime Environment"), die im vorliegenden Ausführungsbeispiel eine Java-Laufzeitumgebung mit einer virtuellen Java-Maschine 5 („Java Virtual Machine") als wichtigstem Bestandteil ist. In der Regel liegt die virtuelle Java-Maschine als Java-Interpreter vor, sie kann jedoch auch als Übersetzer ausgestaltet sein, z.B. als Just-in-Time-Compiler. Von der virtuellen Maschine 5 bzw. einem entsprechenden Java-Interpreter werden schließlich Java-Applikationen 6 ausgeführt, die vorher durch Kompilierung eines Java-Quellprogramms in ein plattformunabhängiges Zwischenformat erzeugt wurden, z.B. in das interpretierbare Java-Bytecode-Format. Ein ähnliches, im Rahmen der vorliegenden Erfindung ebenso einsetzbares Konzept einer virtuellen Laufzeitumgebung bietet das NET-System mit der "Common Language Runtime" (CLR) als virtuelle Maschine zur Ausführung/Interpretation von CIL-Programmen ("Common Intermediate Language").
Bei der Ausführung einer plattformunabhängigen Applikation 6 müssen ihre Anweisungen bzw. die von der virtuellen Maschine 5 gebildeten Prozesse in hardwarenähere Anweisungen/Prozesse auf der Ebene des Betriebssystems umgesetzt werden. Ebenso muss für einen Zugriff einer Applikation 6 auf Betriebsmittel des Datenträgers 1, also auf dessen Hardware 2, eine Interaktion zwischen einer virtuellen Maschine 5 und den Betriebssystemkern 3 erfolgen. Hierzu besitzt der Betriebssystemkern 3 eine wohldefinierte und gesicherte Schnittstelle 4, über die Betriebsmittelanfragen 4a einer virtuellen Maschine 5 und Betriebsmittelzuteilungen 4b des Betriebssystemkerns 3 an die anfragende virtuelle Maschine 5 abgewickelt werden. Die Sicherung der Schnittstelle 4 besteht darin, dass nur Betriebsmittelanfragen von autorisierten virtuellen Maschinen 5 und/oder Applikationen 6 von dem Betriebssystemkern 3 entsprochen wird.
Der Betriebssystemkern 3 bzw. das Betriebssystem ist multitaskingfähig ausgestaltet, so dass mehrere virtuelle Maschinen 5a, 5b, 5c gleichzeitig nebenläufig (d.h. quasi-parallel) ausgeführt werden können. Die einzelnen virtuellen Maschinen 5a, 5b, 5c werden durch einen entsprechenden Betriebssystemmechanismus 8 logisch/datentechnisch derart voneinander isoliert, dass kein nicht authorisierter Datenaustausch zwischen ihnen oder keine nicht authorisierten Zugriffe auf die Speicherbereiche fremder virtueller Maschinen 5a, 5b, 5c möglich ist. Hierzu kann eine Speicherverwaltungseinheit/Speicherschutzeinheit (MMU/MPU) des Prozessors eingesetzt werden, um die Adressräume der virtuellen Maschinen 5a, 5b, 5c zu verwalten und Fremdzugriffe auszuschließen.
Die ausgeführten virtuellen Maschinen 5a, 5b, 5c können multithreadingfähig sein, d.h. sie unterstützen das nebenläufige Abarbeiten mehrerer Ausführungsstränge („Threads") innerhalb eines Prozesses. Dadurch kann jede virtuelle Maschine 5a, 5b, 5c ihrerseits mehrere Applikationen 6a–6c, 6d, 6e–6f gleichzeitig nebenläufig ausführen. Hierbei stellen die einzelnen virtuellen Maschinen 5a, 5b, 5c wiederum eine logische Isolation 7 der von ihnen nebenläufig ausgeführten Applikationen 6a–6c, 6e–6f her, z.B. mittels einer Applikations-Firewall, so dass auch die Applikationen 6a–6c, 6d, 6e–6f in geschützten Addressräumen/Speicherbereichen operieren können. Auf diese Weise ergibt sich in 1 eine geschachtelte Nebenläufigkeit, indem einerseits die Applikationen 6a–6f von den entsprechenden virtuellen Maschine 5a–5c und andererseits die virtuellen Maschinen 5a–5c von dem Betriebssystemkern 3 nebenläufig ausgeführt werden. Da die virtuellen Maschinen 5a–5c zur Ausführung ihrer Applikationen 6a–6f ihre jeweiligen Prozesse und/oder Threads unabhängig von der eigentlichen Prozessstruktur des Betriebssystemkerns 3 einrichten können, können die Applikationen 6a–6f effizient und ohne überflüssigen Verwaltungs- und Koordinationsaufwand zwischen der Ebene der virtuellen Maschinen 5 und der des Betriebssystemkerns 3 ausgeführt werden.
Die Anforderung 4a von Betriebsmitteln des Datenträgers 1 durch die Applikationen 6a–6f und die Zuteilung 4b von Betriebsmitteln durch den Betriebssystemkern 3 ist sicherheitskritischer Punkt, da ein unautorisierter und schädigender Zugriff z.B. auf sensible Speicherbereiche oder andere Systemressourcen die Integrität des Datenträgers 1 gefährden kann. Derartige zuteilungsbedürftige Betriebsmittel sind z.B. sämtliche Speicher eines Computers, wie z.B. Festplatten, Flash-Speicher, Arbeitsspeicher, etc., Ein-/Ausgabeschnittstellen und daran angeschlossene Peripheriegeräte, wie z.B. Drucker, Netzwerkzugänge oder dergleichen, oder der Prozessor selbst.
Die Betriebsmittel des Datenträgers 1 werden über die Schnittstelle 4 zwischen dem Betriebssystemkern 3 und den nebenläufig ausgeführten virtuellen Maschinen 5a, 5b, 5c unmittelbar von dem Betriebssystemkern 3 verwaltet und direkt zugeteilt. Auf diese Weise besteht eine Kontrolle der Betriebsmittel durch den Betriebssystemkern 2, da dieser die Betriebsmittel einerseits den einzelnen virtuellen Maschinen 5 als individuelle Betriebsmittelkontingente zuteilt und andererseits anfragende Applikationen 6a–6f nur auf die Betriebsmittel des der ausführenden virtuellen Maschinen 5a–5c zugeteilten Kontingents zugreifen können. Selbstverständlich können sich die Kontingente durchaus überlappen, so dass verschiedenen virtuellen Maschinen auch teilweise die gleichen Betriebsmittel zugeteilt werden. Die Zuordnung einer auszuführenden Applikation 6a–6f zu einer virtuellen Maschine 5a–5c wird dabei von dem Betriebssystemkern 3 aufgrund einer vorher geprüften Zugriffsberechtigung der jeweiligen Applikation 6a–6f vorgenommen, z.B. mittels für diesen Zweck von dem Betriebssystemkern 3 angelegten Zuordnungstabellen. Die Betriebsmittelvergabe 4b wird also ausschließlich von dem multitaskingfähigen Betriebssystemkern 3 vorgenommen und über die gemeinsame Zugriffsschnittstelle 4 den virtuellen Maschinen 5a–5c mitgeteilt.
Bei der individuellen Zuteilung bestimmter Betriebsmittelkontingente an die einzelnen virtuellen Maschinen 5a–5c können die den jeweiligen virtuellen Maschinen 5a–5c zugeteilten Kontingente gemäß vorgegebener Sicherheitskriterien so zugeteilt werden, dass die einzelnen virtuellen Maschinen 5a–5c als unterschiedliche Sicherheitsstufen bzw. Sicherheitslaufzeitumgebung zur Ausführung von bestimmten, der jeweiligen Sicherheitsstufe entsprechenden Applikationen 6a–6f ausgebildet werden können. Eine Applikation 6a–6f wird dann genau derjenigen virtuellen Maschine 5a–5c zur Ausführung zugeordnet, deren Betriebsmittelkontingent der von einer Applikation 6a–6f nachgewiesenen Zugriffsberechtigung entspricht.
Die Zugriffsberechtigung kann eine Authentisierung des Benutzers sein, der eine Applikation 6a–6f gestartet hat, oder direkt aus dem Programmcodes der jeweiligen Applikation 6a–6f abgeleitet werden. Hierbei sind verschiedene Authentisierungsverfahren denkbar, zum Beispiel digitale Programmcodesignaturen, Benutzerverifikationen über kryptografische Schlüssel, biometrische Identifikationen oder PINs, oder die Authentisierung im Challenge-Response-Verfahren.
2 illustriert eine erfindungsgemäß eingerichtete Chipkarte 10, umfassend einen Prozessor 12, eine Schnittstelle 11 zur Interaktion mit einem Kartenlesegerät oder dergleichen, sowie einer Speicherhierarchie, umfassend einen permanenten ROM-Speicher 13, einen wiederbeschreibbaren EEPROM-Speicher 14 und einen flüchtigen RAM-Arbeitsspeicher 15. Ebenso wie eine Chipkarten kann auch eine sichere Multimediakarte, Mobilfunkkarte, ein USB-Speichertoken oder gar ein eingebettetes System als erfindungsgemäßer portabler Datenträger entsprechend der 2 eingerichtet sein. Falls es sich bei dem portablen Datenträger um eine Chipkarte handelt, wird als Betriebssystem vorzugsweise Java-Card eingesetzt.
Das Betriebssystem mit dem Betriebssystemkern 16 liegt üblicherweise in dem permanenten ROM-Speicher 13 vor, während die virtuelle Maschine 17 bzw. ein Java-Interpreter zusammen mit einigen Java-Applikationen 18, 19, 20 als ausführbare Programme im EEPROM-Speicher 14 abgelegt sind. In dem in 2 dargestellten Beispiel wurde der Programmcode der virtuelle Maschine 17 bereits zweimal als unabhängige, nebenläufig ausgeführte Betriebssystemprozesse 22, 23 gestartet, wobei den beiden Betriebssystemprozessen 22, 23 bei ihrem Start vom Betriebssystemkern 16 verschiedene Betriebsmittelkontingente zugeordnet wurden. So hat beispielsweise die ausgeführte virtuelle Maschine 22 lediglich eine geringe Ausführungspriorität und einen demzufolge selteneren Prozessorzugriff, einen eingeschränkten Zugriff auf den RAM-Arbeitsspeicher 15 und der EEPROM-Speicher 14, sowie keinen Zugriff auf Ein-/Ausgabeschnittstellen 11 und etwaige daran angeschlossene Peripheriegeräte, Netzwerke oder Kommunikationspartner. Die virtuelle Maschine 23 hat demgegenüber eine hohe Ausführungspriorität und kann entsprechend mehr Prozessorzeit in Anspruch nehmen. Darüber hinaus ist ihr ein umfassender Zugriff auf den Speicher des Datenträgers 10 sowie die sonstigen Betriebsmittel des Datenträgers 10 einschließlich der Kommunikationsschnittstelle 11 erlaubt.
Die ausgeführten virtuellen Maschinen 22, 23 bilden also zwei Sicherheitsstufen, wobei besonders vertrauenswürdige Applikationen 20, 21 von dem Betriebssystemkern 16 der virtuellen Maschine 23 zur Ausführung zugewiesen werden, während weniger vertrauenswürdige Applikationen 18, 19 von der virtuellen Maschine 22 ausgeführt werden. Die auszuführenden Applikationen 18, 19, 20, 21 können dabei nicht nur solche Applikationen 18, 19, 20 sein, die auf dem Datenträger 10 vorliegen, sondern auch Applikationen 21 die von einem Kommunikationspartner über die Schnittstelle 11 empfangen werden, um auf dem Datenträger 10 ausgeführt zu werden. Bei dem vorliegenden Beispiel der 2 stellt der Betriebssystemkern 16 eine hohe Vertrauenswürdigkeit und somit eine umfassende Betriebsmittelzugriffsberechtigung der Applikation 21 fest und ordnet sie deshalb zur Ausführung der virtuellen Maschine 23 zu.
Die Applikationen 18, 19, 20, 21 bilden bei ihrer Ausführung Applikationsprozesse 24, 25, 26, 27 und belegen, wie auch die Betriebssystemprozesse 22, 23 der zwei ausgeführten virtuellen Maschinen, jeweils einen Speicherbereich im RAM-Arbeitsspeicher 15. Die Prozesse 22, 23 der virtuellen Maschinen und die Applikationsprozesse 24, 25, 26, 27 sind hierbei aus Sicherheitsgründen mittels bestimmter Speicherschutzmethoden (z.B. MMU/MPU, Applikations-Firewall) logisch so voneinander getrennt, dass ein Fremdzugriff nicht möglich ist. So werden einerseits die virtuellen Maschinen 22, 23 und andererseits die einzelnen Applikationsprozesse 24, 25, 26, 27 logisch voneinander getrennt ausgeführt.
Das erfindungsgemäße Konzept kann insbesondere zum Aufbau eines sicheren Web-Servers auf eine Chipkarte 10 eingesetzt werden, der bestimmte Applikationen 18, 19, 20 – sogenannte Java-Servlets – zum Entgegennehmen und Beantworten von Anfragen eines Clients ausführt. Die Servlets 18, 19, 20 werden abhängig von der Autorisierung (Vertrauenswürdigkeit) eines Clients einem Servlet-Container einer bestimmten virtuellen Maschine 22, 23 zugeordnet und dadurch auf der entsprechende Sicherheitsstufe ausgeführt.
Abhängig von der Zugriffsberechtigung bzw. der Authentisierung eines HTTP/S-Clients, d.h. eines auf den Web-Server über das HTTP/S-Protokoll zugreifenden anderen Geräts, wird eine Anfrage von einem Servlet 18, 19, 20 bearbeitet, das entsprechend der Vertrauenswürdigkeit des Clients Zugriff auf das von der ausführenden virtuellen Maschine 22, 23 bereitgestellte. So ist es beispielsweise möglich, dass der Betriebssystemkern 16 einem Servlet, welches von einem HTTP/S-Client („Secure Hypertext Transmission Protocol") ohne eine SSL-Authentisierung („Secure Socket Layer") angesprochen wird, nur einen eingeschränkten Betriebsmittelzugriff gewährt und es dem Servlet-Container der virtuellen Maschinen 22 mit eingeschränktem Betriebsmittelkontingent zuordnet. Andererseits kann ein Servlet, das von einem HTTP/S-Client mit sicherer SSL-Kryptografie und Authentisierung durch ein SSL-Zertifikat angesprochen wird, von der virtuellen Maschine 23 mit umfangreichem Betriebsmittelkontingent ausgeführt werden.
Die vorliegende Erfindung wurde mit Bezug auf die Figuren für mehrere nebenläufig ausgeführte Applikationen in einer virtuellen Maschine beschrieben. Sie ist aber analog anwendbar auf nebenläufig ausgeführte Ausführungspfade der gleichen Applikation in einer virtuellen Maschine. Eine Applikation kann aus genau einem Ausführungspfad bestehen. Ebenso möglich sind Kombinationen aus diesen Gestaltungen, also beispielsweise mehrere Ausführungspfade zumindest einer ersten Applikation und zumindest eine zweite Applikation mit genau oder zumindest einem Ausführungspfad werden in einer der virtuellen Maschinen ausgeführt.

Claims

Verfahren zum Ausführen mehrerer Ausführungspfade zumindest einer Applikation (6a–6f; 24–27) auf einem Prozessor (12) eines portablen Datenträgers (1; 10), umfassend den Schritt des – mehrfachen nebenläufigen Ausführens einer virtuellen Maschine (5a–5c; 22, 23) durch den Prozessor (12) des Datenträgers; gekennzeichnet durch die weiteren Schritte: – nebenläufiges Ausführen von mindestens zwei der mehreren Ausführungspfade durch eine der nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23); und – Zuteilen von unterschiedlichen Betriebsmittelkontingenten an die nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23).
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die mindestens zwei Ausführungspfade Ausführungspfade der gleichen Applikation sind.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die mindestens zwei Ausführungspfade Ausführungspfade unterschiedlicher Applikationen (6a–6f; 24–27) sind.
Verfahren nach einem der Ansprüche 1 bis 3, gekennzeichnet durch die Schritte: – Überprüfen einer Berechtigung einer auszuführenden Applikation (6a–6f; 24–27), auf Betriebsmittel zuzugreifen; und – Auswählen derjenigen virtuellen Maschine (5a–5c; 22, 23) zum Ausführen der Applikation (6a–6f; 24–27), deren zugeteilte Betriebsmittel der Berechtigung der auszuführenden Applikation (6a–6f; 24–27) entsprechen.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die virtuelle Maschine (5a–5c; 22, 23) ein weiteres mal nebenläufig ausgeführt wird, falls keine der nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23) Betriebsmittel zugeteilt hat, die der Berechtigung der auszuführenden Applikation (6a–6f; 24–27) entsprechen.
Verfahren nach Anspruch 4 oder 5, dadurch gekennzeichnet, dass die Berechtigung der auszuführenden Applikation (6a–6f; 24–27) durch Verifizieren einer Benutzerauthentisierung und/oder einer Signatur der Applikation (6a–6f; 24–27) geprüft wird.
Verfahren nach einem der Ansprüche 1 bis 6, gekennzeichnet durch, die Schritte: – Anfordern von Betriebsmitteln zur Ausführung aller auszuführenden Applikationen (6a–6f; 24–27) über eine gemeinsame Zugriffsschnittstelle; und – Zuweisen der angeforderten Betriebsmittel über die Zugriffsschnittstelle (4).
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass die nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23) logisch voneinander isoliert werden, vorzugsweise mittels einer Speicherverwaltungseinheit (MMU) und/oder einer Speicherschutzeinheit (MPU).
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die von einer ausgeführten virtuellen Maschine (5a–5c; 22, 23) nebenläu fig ausgeführten Ausführungspfade und/oder Applikationen (6a–6f; 17–21) logisch voneinander isoliert werden.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass den ausgeführten virtuellen Maschinen (5a–5c; 22, 23) derart unterschiedliche Kontingente von Betriebsmitteln zugewiesen werden, dass die ausgeführten virtuellen Maschinen (5a–5c; 22, 23) unterschiedliche Sicherheitsstufen bieten.
Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass eine virtuelle Java-Maschine (5a–5c; 22, 23) mit einem Java-Interpreter mehrfach nebenläufig ausgeführt wird und dass Java-Bytecode-Applikationen (6a–6f; 17–21) von dem Java-Interpreter ausgeführt werden und/oder das Verfahren auf einem Java-Card-Betriebssystem ausgeführt wird.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die Applikationen (6a–6f; 17–21) auf einem Web-Server als Java-Servlets ausgeführt werden.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass als Betriebsmittel Prozessorzeit und/oder Speicherplatz und/oder Ein-/Ausgabeschnittstellen zugeteilt werden.
Portabler Datenträger (1; 10), umfassend Betriebsmittel einschließlich eines Prozessors (12), einen Betriebssystemkern (3; 16), der auf die Betriebsmittel Zugriff hat, und eine unter Kontrolle des Betriebssystemkerns (3; 16) von dem Prozessor (12) ausführbare virtuelle Maschine (5a–5c; 22, 23), wobei der Betriebssystemkern (3; 16) eingerichtet ist, die virtuelle Maschine (5a–5c; 22, 23) mehrfach nebenläufig auszuführen, dadurch gekennzeichnet, dass die virtuelle Maschine (5a–5c; 22, 23) eingerichtet ist, Ausführungspfade zumindest einer Applikation (6a–6f; 17–21) nebenläufig auszuführen, und der Betriebssystemkern (3; 16) eingerichtet ist, den ausgeführten virtuellen Maschinen (5a–5c; 22, 23) unterschiedliche Betriebsmittelkontingente zuzuteilen.
Datenträger (1; 10) nach Anspruch 14, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eingerichtet ist, einer ausgeführten virtuellen Maschine (5a–5c; 22, 23) eine auszuführende Applikation (6a–6f; 24–27) in Abhängigkeit von einer Berechtigung der Applikation (6a–6f; 24–27, auf Betriebsmittel zuzugreifen, zuzuordnen.
Datenträger (1; 10) nach Anspruch 14, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eingerichtet ist, die virtuelle Maschine (5a–5c; 22, 23) ein weiteres mal auszuführen, falls keine der nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23) Betriebsmittel zugeteilt hat, die der Berechtigung der auszuführenden Applikation (6a–6f; 24–27 entsprechen.
Datenträger (1; 10) nach Anspruch 15 oder 16, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eingerichtet ist, die Berechtigung der auszuführenden Applikation (6a–6f; 24–27) durch Verifizieren einer Benutzerauthentisierung und/oder einer Signatur der Applikation (6a–6f; 24–27) zu prüfen.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 17, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eine gemeinsame logische Zugriffsschnittstelle (4) für die nebenläufig ausgeführten virtuellen Maschinen (5a–5c; 22, 23) umfasst, über die Betriebsmittel von einer Applikation (6a–6f; 24–27) angefordert und von dem Betriebssystemkern (3; 16) zugewiesen werden können.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 18, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eingerichtet ist, ausgeführte virtuelle Maschinen (5a–5c; 22, 23) logisch voneinander zu isolieren.
Datenträger (1; 10) nach Anspruch 19, gekennzeichnet durch eine Speicherverwaltungseinheit (MMU) und/oder eine Speicherschutzeinheit (MPU), mittels der der Betriebssystemkern (3; 16) ausgeführte virtuelle Maschinen logisch voneinander isolieren kann.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 20, dadurch gekennzeichnet, dass die virtuelle Maschine (5a–5c; 22, 23) eingerichtet ist, von ihr ausgeführte Applikationen (6a–6f; 17–21) logisch voneinander zu isolieren.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 21, dadurch gekennzeichnet, dass der Betriebssystemkern (3; 16) eingerichtet ist, ausgeführten virtuellen Maschinen (5a–5c; 22, 23) derart unterschiedliche Kontingente von Betriebsmitteln zuzuweisen, dass ausgeführte virtuelle Maschinen (5a–5c; 22, 23) unterschiedliche Sicherheitsstufen bieten.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 22, dadurch gekennzeichnet, dass die virtuelle Maschine (5a–5c; 22, 23) eine virtuelle Java-Maschine (5a–5c; 22, 23) mit einem Java-Interpreter ist und die Applikationen (6a–6f; 17–21) von dem Java-Interpreter ausführbare Java-Bytecode-Applikationen sind und/oder der Betriebssystemkern (3; 16) Teil des Java-Card-Betriebssystems ist.
Datenträger (1; 10) nach Anspruch 23, dadurch gekennzeichnet, dass der Datenträger (1; 10) einen ausführbaren Web-Server umfasst und die Applikationen (6a–6f; 17–21) von dem Web-Server ausführbare Java-Servlets sind.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 24, dadurch gekennzeichnet, dass die Betriebsmittel Prozessorzeit und/oder Speicherplatz und/oder Ein-/Ausgabeschnittstellen des Datenträgers (1; 10) umfassen.
Datenträger (1; 10) nach einem der Ansprüche 14 bis 25, dadurch gekennzeichnet, dass der Datenträger (1; 10) eine Chipkarte, sichere Multimediakarte, Mobilfunkkarte oder ein USB-Speichermedium ist.