EP2021919A1 - Kommunikation zwischen applikationen auf einem portablen datenträger - Google Patents

Kommunikation zwischen applikationen auf einem portablen datenträger

Info

Publication number
EP2021919A1
EP2021919A1 EP07724944A EP07724944A EP2021919A1 EP 2021919 A1 EP2021919 A1 EP 2021919A1 EP 07724944 A EP07724944 A EP 07724944A EP 07724944 A EP07724944 A EP 07724944A EP 2021919 A1 EP2021919 A1 EP 2021919A1
Authority
EP
European Patent Office
Prior art keywords
application processes
data
operating system
application
data carrier
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP07724944A
Other languages
English (en)
French (fr)
Inventor
Wolfgang Effing
Stephan Spitz
Erich Englbrecht
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke+Devrient GmbH
Original Assignee
Giesecke+Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient GmbH filed Critical Giesecke+Devrient GmbH
Publication of EP2021919A1 publication Critical patent/EP2021919A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication

Definitions

  • the present invention relates to a method for exchanging data between applications that are executed on a portable electronic data carrier, in particular a chip card, as well as a correspondingly set up data carrier.
  • the applications contain sensitive data or are processed and managed by the application processes sensitive data, such as an electronic wallet, which may not be made accessible to other applications.
  • An application in execution is called application process.
  • WO0043876, WO0043877 and WO0043878 disclose such methods, which among other things provide that applications exist in privileged contexts that are allowed access to other contexts, that have interfaces that can be accessed from multiple contexts, that entry objects exist that can allow entry into a foreign context, or that data is exchanged via global data structures that can be accessed from multiple contexts.
  • the applications are processed sequentially one after the other, i. There is only one application process at any one time. For this purpose, access authorizations to the context assigned to an application are given by other applications once, statically, and then remain in this way.
  • the data exchange takes the form of access to a non-volatile memory (e.g., EEPROM) in which the context of the corresponding application is stored.
  • EEPROM non-volatile memory
  • the object of the present invention is to provide a method and a corresponding data carrier, with which data exchange between a plurality of applications stored on a portable data carrier assigned to different contexts can be carried out very quickly in a secure manner.
  • the invention is based on the basic idea that the applications between which data is to be exchanged during the data exchange are application processes and the communication between the application processes is coordinated via a multitasking and / or multithreading-capable operating system.
  • Multitasking-capable operating systems are able to concurrently execute several processes which are simultaneously in the main memory, in that the different processes are always activated alternately in such short intervals, ie processed in the processor, that the impression of simultaneity arises.
  • a process can consist of one or more threads (threads, strands).
  • a thread is an execution thread.
  • a multithreading operating system can execute several threads concurrently, similar to a multi-tasking operating system.
  • the switching, ie the changing assignment of the processes to the processor, between processes with concurrent execution is more complicated for the operating system than the switching between threads, which are therefore also called "lightweight" processes.
  • an application process may also mean a thread (possibly of several) of an application process.
  • the multitasking and / or multithreading operating system controls whether the Application processes are authorized to exchange data with each other. Access rights can be managed securely in this way.
  • the operating system may also include a multitasking and / or multithreading virtual machine that coordinates communication between the application processes, the multitasking and / or multithreading virtual machine controlling whether the application processes are authorized to communicate with each other.
  • a virtual machine is a virtual runtime environment for programs that are available within a guest system. For example, a virtual machine may be used to emulate an operating system within another operating system.
  • the data exchange between applications preferably takes place via memory areas that can be used for data exchange only by application processes, such as single application processes commonly accessible main memory segments, processor registers, a stack (stack) and the like.
  • application processes such as single application processes commonly accessible main memory segments, processor registers, a stack (stack) and the like.
  • stack of the virtual machine can be used to exchange the data.
  • the data exchange can also take place by calling a functionality of an application through another application process. Also in this case, the data generated in the functionality call is preferably exchanged over the aforementioned special memory areas.
  • ACL access control lists
  • ACLs are an advanced method of access control based on concepts such as identity, group rights, and the like.
  • An alternative access control method is capabilities. Capabilities are similar in many ways to "keys". They allow to perform the operations defined by a key on an object designated by the key. The legitimacy to perform this operation is solely in the possession of the key and is independent of the. Identity of the key holder.
  • the secure communication between the applications under control of the operating system can be further increased if the operating system and the application processes run in different operating modes.
  • the operating system runs in a more privileged mode, the system mode, the application processes in the normal, less privileged user mode, which prohibits access to various resources, system functions and secure memory areas.
  • the multitasking and / or multithreding operating system preferably includes a so-called scheduler (process dispatcher).
  • a scheduler is an operating system component for allocating computational time to the processes.
  • the scheduler is set up in such a way that the operating system can ensure via priorities and computer time controls that the computing time previously allocated to the application processes is always met and can not be exceeded, and that important system processes always take precedence over application processes.
  • the management of other hardware resources is the highest priority of the operating system.
  • Application processes can request resources from the operating system during loading or during runtime, which then decides whether and to what extent the corresponding resource is to be allocated. demanding application process may continue to use these resources (for example, exclusively), and / or whether the application process may grant rights to the allocated resources to another application process which may depend on it. In this way, the operating system retains full control of all resources.
  • each application can decide for itself whether and which other application it provides data.
  • it is the operating system alone that determines whether a data exchange corresponding to the specifications of the applications occurs, as well as the way in which such an exchange takes place.
  • the communication between applications is simultaneously controlled and flexibly feasible.
  • FIG. 1 shows a multitasking environment with multitasking kernel and application processes
  • FIG. 2 shows a kernel with authorization table and communication paths.
  • FIG. 1 shows a multitasking environment which includes a kernel 1 of a multitasking and multithreading operating system (MTK, multitasking kernel) and various application processes 2a, 2b, 2c.
  • the kernel 1 (also called core) is the central component of an operating system. It defines the process and data organization. The accesses to resources, such as computing time, memory, I / O interfaces and the like, are controlled by him as the highest authority. Access rights of individual application processes to each other are managed here.
  • the kernel of the operating system and the operating system itself are considered equal.
  • Important functional groups of the MTK 1 are a scheduler, a resource management and a data exchange control.
  • the scheduler is a device for allocating computation time to application processes. It is set up to control the computing time of each application process and to provide the application processes only with predetermined computing time, for example in the form of time quanta. Control over complying with this allocated computation time can be ensured by running the scheduler, as part of the MTK, in system mode, a more privileged mode of operation, whereas the application processes run only in normal user mode.
  • Resource management controls all hardware resources such as memory, I / O interfaces, and the like. These resources can be requested by the application processes on first load or at runtime.
  • the resource management is set up to provide the application processes with access to hardware resources as the highest instance. It determines the type of access of the application process to the resources made available and can specify to which other application processes and / or in which form the resources that are made available to an application process may be forwarded. Unless an application process Even if it is possible to decide which resource rights he intends to pass on to other application processes, this can only be done within the scope of the rights of use granted to him.
  • the data exchange control authorizes and controls all data exchange between the application processes.
  • Application processes can exchange data through function calls or shared storage regions. Each of the applications decides for itself whether and which other application it provides data.
  • the mode of operation of the communication of two application processes 2a, 2b according to the present invention is shown in FIG. All communication paths (3a, 3b, 3c, 3d) of the communication between the application processes 2a and 2b are coordinated by the MTK1.
  • the MTK 1 manages the mutual access rights of all execution threads (threads) of the application processes, for example in an authorization table 10. This table 10 does not necessarily have to be in the MTK, but the coordination of the process communication between the different threads is always an integral part of the MTK.
  • a thread is uniquely identified by an ID and, depending on an authorization, obtains the permission to exchange data with certain other threads.
  • FIG. 2 shows a thread with the ID x, which is allowed to exchange data with the thread with the ID y, but not with the thread with the ID z.
  • MTK-authorized data exchange between two threads takes place, for example, by providing a thread segment accessible to both threads, in which the request or response data 3a, 3b or 3c, 3d can be stored.
  • the data exchange can take place, for example, via processor registers or a stack.
  • the stack of the virtual machine can be used for secure data exchange.
  • a first concrete application example of the invention relates to a chip card which embodies a plurality of "virtual" chip cards.
  • This makes it possible to implement various applications that are currently implemented on different chip cards, such as EC card, health card, access control card and the like, on a single physical card and in a secure multitasking and / or multithreading environment next to each other and unaffected by each other.
  • it may be performed under the control of the MTK using the mechanisms described above.
  • individual authorized and logically separate applications are ex- kl ⁇ siv grants access to the same functionality provided by another secure application via the secure exchange described above.
  • Correspondingly authorized applications can use this functionality by requesting this special application.
  • Certain functionalities that are required by several applications can be kept so resource-saving, such as a memcopy functionality for copying memory areas. But even entire cryptography libraries can be made accessible in this way several legitimate applications.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)

Abstract

Bei einem Verfahren zum Austauschen von Daten zwischen mindestens zwei auf einem portablen elektronischen Datenträger, insbesondere einer Chipkarte, gespeicherten Applikationen, sind die Applikationen während des Datenaustauschs Applikationsprozesse (2a, 2b, 2c) und die Kommunikation zwischen den Applikationsprozessen (2a, 2b, 2c) wird über ein multitasking- und/oder multithreadingfähiges Betriebssystem (1) koordiniert. Dabei kontrolliert das multitasking- und/ oder multithreadingfähige Betriebssystem (1), ob die Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch untereinander autorisiert sind. Bevorzugt findet der Datenaustausch über Speicherbereiche statt, die zum Datenaustausch nur von Applikationsprozessen (2a, 2b, 2c) benutzt werden können, wie beispielsweise den Applikationsprozessen (2a, 2b, 2c) gemeinsam zugängliche Hauptspeichersegmente, Prozessor- register oder ein Stapelspeicher.

Description

Kommunikation zwischen Applikationen auf einem portablen Datenträger
Die vorliegende Erfindung betrifft ein Verfahren zum Datenaustausch zwischen Applikationen, die auf einem portablen elektronischen Datenträger, insbesondere einer Chipkarte, ausgeführt werden, sowie einen entsprechend eingerichteten Datenträger.
Es ist bekannt, dass auf portablen Datenträgern, wie beispielsweise Chipkarten, mehrere Applikationen zur Verfügung gestellt werden können. Auch besteht die Möglichkeit, nachträglich neue Applikationen auf dem Datenträger zu installieren.
Oftmals beinhalten die Applikationen sensible Daten bzw. werden von den Applikationsprozessen sensible Daten bearbeitet und verwaltet, beispielsweise eine elektronische Geldbörse, die anderen Applikationen nicht zugänglich gemacht werden dürfen. Eine Applikation in Ausführung wird Ap- plikationsprozess genannt.
Dies wird gemäß der US 6,823,520 beispielsweise dadurch erreicht, dass jeder Applikation ein sogenannter Kontext zugewiesen wird, der Daten enthält, für die die Applikation eine Zugriffsberechtigung hat. Zugriff auf Daten und Objekte in diesem Kontext erhält zuerst nur die Applikation, der dieser Kontext zugewiesen ist. Es können mehrere Applikationen demselben Kontext zugewiesen werden. Verschiedene Kontexte sind durch Kontextbarrieren oder Firewalls getrennt. Ein Zugriff einer Applikation in einen Kontext, der nicht ihr, sondern einer anderen Applikation zugewiesen ist, ist dadurch nicht möglich.
Andererseits ist es erstrebenswert, verschiedenen Applikationen auf demselben Datenträger zu ermöglichen, kontrolliert Daten auszutauschen. Um nun kontrollierten Zugriff von einer Applikation, die einem Kontext zugewiesen ist, auf Daten einer einem anderen Kontext zugewiesenen Applikation prinzipiell zu ermöglichen, sind daher Verfahren geschaffen worden, die es unter definierten Umständen möglich machen, Kontextbarrieren zu überwinden.
Aus der WO0043876, WO0043877 und der WO0043878 sind derartige Verfahren bekannt, die unter anderem vorsehen, dass Applikationen in privilegierten Kontexten existieren, denen ein Zugriff auf andere Kontexte erlaubt ist, dass Schnittstellen existieren, auf die von mehreren Kontexten aus zuge- griffen werden kann, dass Einsprungsobjekte existieren, die einen Eintritt in einen fremden Kontext erlauben können, oder dass Daten über globale Datenstrukturen ausgetauscht werden, auf die von mehreren Kontexten aus zugegriffen werden kann.
Die Applikationen werden dabei sequentiell nacheinander abgearbeitet, d.h. zu jedem Zeitpunkt gibt es nur einen Applikationsprozess. Dazu werden Zugriffsberechtigungen auf den einer Applikation zugewiesenen Kontext durch andere Applikationen einmal, statisch, eingeräumt und bleiben dann in dieser Weise bestehen. Der Datenaustausch findet in Form eines Zugriffs auf einen nichtflüchtigen Speicher (z.B. EEPROM) statt, in dem der Kontext der entsprechenden Applikation abgespeichert ist.
Aufgabe der vorliegenden Erfindung ist es, ein Verfahren und einen entsprechenden Datenträger zur Verfügung zu stellen, mit dem Datenaustausch zwischen mehreren auf einem portablen Datenträger gespeicherten Applikationen, die unterschiedlichen Kontexten zugewiesen sind, sehr schnell auf sichere Weise durchgeführt werden kann.
Diese Aufgabe wird durch ein Verfahren und einen tragbaren elektronischen Datenträger mit den Merkmalen der nebengeordneten Ansprüche gelöst. In den davon abhängigen Ansprüchen sind vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung angegeben.
Die Erfindung basiert auf dem Grundgedanken, dass die Applikationen, zwischen denen Daten ausgetauscht werden sollen, während des Datenaustausche Applikationsprozesse sind und die Kommunikation zwischen den Applikationsprozessen über ein multitasking- und/ oder multithreadingfähi- ges Betriebssystem koordiniert wird. Multitaskingfähige Betriebssysteme sind in der Lage, nebenläufig mehrere Prozesse auszuführen, die sich gleichzeitig im Hauptspeicher befinden, indem die verschiedenen Prozesse in so kurzen Abständen immer abwechselnd aktiviert werden, also im Prozessor bearbeitet werden, dass der Eindruck der Gleichzeitigkeit entsteht. Dadurch kann der Datenaustausch sehr schnell erfolgen. Ein Prozess kann aus einem oder mehreren Threads (Fäden, Strängen) bestehen. Ein Thread ist ein Ausführungsstrang. Ein multithreadingfähiges Betriebssystem kann analog zu einen multitaskingfähigen Betriebssystem mehrere Threads nebenläufig ausführen. Die Umschaltung, also die wechselnde Zuweisung der Prozesse zum Prozessor, zwischen Prozessen bei nebenläufiger Ausführung ist für das Be- triebssystem aufwendiger als die Umschaltung zwischen Threads, die deswegen auch "leichtgewichtige" Prozesse genannt werden.
Im Sinne der Erfindung muss zwischen Applikationsprozessen und Threads von Applikationsprozessen nicht unterschieden werden. Im weiteren kann also mit einem Applikationsprozess auch ein Thread (von eventuell mehreren) eines Applikationsprozesses gemeint sein.
Um dabei die Sicherheit des Datenaustauschs zu gewährleisten, kontrolliert das multitasking- und/ oder multithreadingfähige Betriebssystem, ob die Applikationsprozesse zum Datenaustausch untereinander autorisiert sind. Zugriffsrechte können auf diese Weise sicher verwaltet werden.
Das Betriebssystem kann auch eine multitasking- und/ oder multithreading- fähige Virtuelle Maschine umfassen, die die Kommunikation zwischen den Applikationsprozessen koordiniert, wobei die multitasking- und/ oder multi- threadingfähige Virtuelle Maschine kontrolliert, ob die Applikationsprozesse zum Datenaustausch untereinander autorisiert sind. Eine Virtuelle Maschine ist eine virtuelle Laufzeitumgebung für Programme, die innerhalb eines Gastsystems zur Verfügung steht. Beispielsweise kann eine Virtuelle Maschine zur Emulation eines Betriebssystems innerhalb eines anderen Betriebssystems dienen.
Der Datenaustausch zwischen Applikationen findet dabei bevorzugt über Speicherbereiche statt, die zum Datenaustausch nur von Applikationsprozessen benutzt werden können, wie beispielsweise einzelnen Applikationsprozessen gemeinsam zugängliche Hauptspeichersegmente, Prozessorregister, einen Stapelspeicher (Stack) und dergleichen. Im Falle einer Virtuellen Maschine kann beispielsweise der Stapelspeicher der Virtuellen Maschine zum Austausch der Daten dienen. Der Datenaustausch kann auch durch Aufrufen einer Funktionalität einer Applikation durch einen anderen Applikations- prozess erfolgen. Auch in diesem Fall werden die Daten, die bei dem Funktionalitätsaufruf erzeugt werden, vorzugsweise über die vorgenannten speziellen Speicherbereiche ausgetauscht.
Die Kontrolle der Autorisierung der Applikationsprozesse zum Datenaustausch erfolgt bevorzugt über Zugangskontrolllisten (access control list, ACL). ACLs sind eine erweiterte Methode zur spezifischen Zugriffskontrolle, die auf Konzepten wie Identität , Gruppenrechten und dergleichen basieren. Eine alternative Zugriffskontrollmethode sind Capabilities. Capabilities ähneln in vielen Aspekten "Schlüsseln". Sie erlauben es, die durch einen Schlüssel definierten Operationen an einem durch den Schlüssel bezeichneten Objekt durchzuführen. Die Legitimation zum Durchführen dieser Operation liegt alleine im Besitz des Schlüssels und ist unabhängig von der. Identität des Schlüsselinhabers.
Die sichere Kommunikation zwischen den Applikationen unter Kontrolle des Betriebssystems kann weiter erhöht werden, wenn das Betriebssystem und die Applikationsprozesse in verschiedenen Betriebsmodi laufen. Das Betriebssystem läuft in einem höher privilegierten Modus, dem Systemmodus, die Applikationsprozesse im normalen, weniger privilegierten Benutzermodus, der den Zugriff auf verschiedene Ressourcen, Systemfunktionen und gesicherte Speicherbereiche verbietet.
Darüber hinaus umfasst das multitasking- und/ oder rnultithradingsfähige Betriebssystems vorzugsweise einen sogenannten Scheduler (Prozess- Disponent). Ein Scheduler ist eine Betriebssystemkomponente zum Zuteilen von Rechenzeit an die Prozesse. Der Scheduler ist so eingerichtet, dass das Betriebssystem über Prioritäten und Rechenzeitkontrollen sicherstellen kann, dass die den Applikationsprozessen zuvor begrenzt zugewiesene Rechenzeit stets eingehalten wird und nicht überschritten werden kann, und dass wichtige Systemprozesse stets Vorrang vor Applikationsprozessen haben.
Auch die Verwaltung anderer Hardware-Ressourcen, wie beispielsweise I/O-Schnittstellen, unterliegt dem Betriebssystem als oberster Instanz. Applikationsprozesse können beim Laden oder während der Laufzeit Ressourcen beim Betriebssystem anfordern, das dann darüber entscheidet, ob und in welchem Umfang die entsprechende Ressource zugeteilt wird, wie der an- fordernde Applikationsprozess diese Ressourcen weiterverwenden darf (beispielsweise exklusiv), und / oder ob der Applikationsprozess einem weiteren, eventuell von ihm abhängenden Applikationsprozess Rechte an den zugeteilten Ressourcen einräumen darf. Auf diese Weise behält das Betriebssy- stem die vollständige Kontrolle über alle Ressourcen.
Es ist vorteilhaft, wenn jede Applikation selbst entscheiden kann, ob und welchen anderen Applikation sie Daten zur Verfügung stellt. Über das Zustandekommen eines den Vorgaben der Applikationen entsprechenden Da- tenaustauschs wie auch über den Weg, über den ein solcher Austausch dann stattfindet, entscheidet jedoch allein das Betriebssystems. Somit ist die Kommunikation zwischen Applikationen zugleich kontrolliert und flexibel durchführbar.
Nachfolgend wird die Erfindung anhand der begleitenden Zeichnungen beispielhaft erläutert. Darin zeigen:
Figur 1 eine multitasking-Umgebung mit multitasking-Kernel und Appli- kationsprozessen, und
Figur 2 einen Kernel mit Autorisierungstabelle und Kommunikationspfaden.
Ein Ausführungsbeispiel der Erfindung wird im folgenden mit Bezug auf die Figuren 1 und 2 genauer dargestellt. Figur 1 zeigt eine Multitasking- Umgebung, die einen Kernel 1 eines multitasking- und multithreadingfähi- gen Betriebssystems (MTK, Multitasking Kernel) und verschiedene Applikationsprozesse 2a, 2b, 2c umf asst. Der Kernel 1 (auch Kern genannt) ist der zentrale Bestandteil eines Betriebssystems. In ihm ist die Prozess- und Datenorganisation festgelegt. Die Zugriffe auf Ressourcen, beispielsweise Rechenzeit, Speicher, I/O-Schnittstellen und dergleichen, werden von ihm als höchster Instanz kontrolliert. Zugriffsrechte einzelner Applikationsprozesse aufeinander werden hier verwaltet. Im Sinne der Erfindung werden der Kernel des Betriebssystems und das Betriebssystem selbst als gleich angesehen.
Wichtige Funktionsgruppen des MTK 1 sind ein Scheduler, eine Ressourcenverwaltung und eine Datenaustauschkontrolle.
Der Scheduler ist eine Einrichtung zum Zuteilen von Rechenzeit an Applikationsprozesse. Er ist eingerichtet, die Rechenzeit jedes Applikationsprozesses zu kontrollieren und den Applikationsprozessen nur vorbestimmte Rechenzeit zur Verfügung zu stellen, beispielsweise in Form von Zeitquanten. Die Kontrolle über das Einhalten dieser zugeteilten Rechenzeit kann dadurch gewährleistet werden, dass der Scheduler, als Teil des MTK, im Systemmodus, einem höher privilegierten Betriebsmodus, läuft, die Applikationsprozesse hingegen nur im normalen Benutzermodus.
Die Ressourcenverwaltung kontrolliert sämtliche Hardware-Ressourcen wie beispielsweise Speicher, I/O-Schnittstellen und dergleichen. Diese Ressourcen können von den Applikationsprozessen beim ersten Laden oder zur Laufzeit angefordert werden. Die Ressourcenverwaltung ist eingerichtet, als oberste Instanz den Applikationsprozessen Zugriff auf Hardware- Ressourcen zur Verfügung zu stellen. Sie bestimmt die Art des Zugriffs des Applikationsprozesses auf die zur Verfügung gestellten Ressourcen und kann angeben, an welche weiteren Applikationsprozesse und / oder in welcher Form die Ressourcen, die einem Applikationsprozess zur Verfügung gestellt sind, weitergegeben werden dürfen. Sofern ein Applikationsprozess selbst darüber entscheiden kann, welche Ressourcennutzungsrechte er an andere Applikationsprozesse weitergeben will, so kann dies nur im Rahmen der ihm eingeräumten Nutzungsrechte erfolgen.
Die Datenaustauschkontrolle autorisiert und kontrolliert sämtlichen Datenaustausch zwischen den Applikationsprozessen. Applikationsprozesse können Daten über Funktionsaufrufe oder über ihnen gemeinsam zugängliche Speicherregionen austauschen. Jede der Applikationen entscheidet selbst, ob und welcher anderen Applikation sie Daten zur Verfügung stellt. Die Funk- tionsweise der Kommunikation zweier Applikationsprozesse 2a, 2b gemäß der vorliegenden Erfindung ist in Figur 2 dargestellt. Sämtliche Kommunikationspfade (3a, 3b, 3c, 3d) der Kommunikation zwischen den Applikationsprozessen 2a und 2b werden durch den MTK 1 koordiniert. Dabei verwaltet der MTK 1 die gegenseitigen Zugriffsrechte aller Ausführungsstränge (Threads) der Applikationsprozesse beispielsweise in einer Autorisierungs- tabelle 10. Diese Tabelle 10 muss nicht zwingend im MTK liegen, jedoch ist die Koordination der Prozesskommunikation zwischen den verschiedenen Threads immer integraler Bestandteil des MTK. Ein Thread wird eindeutig über eine ID identifiziert und erlangt abhängig von einer Autorisierung die Berechtigung, Daten mit bestimmten anderen Threads auszutauschen. In Figur 2 ist ein Thread mit der ID x zu sehen, dem es erlaubt ist, mit dem Thread mit der ID y Daten auszutauschen, nicht aber mit dem Thread mit der ID z. Es gibt verschiedene Möglichkeiten und Zeitpunkte für einen Thread, sich gegenüber dem MTK zu authentisieren: entweder authentisiert sich der Applikationsprozess, der den Thread erzeugt, einmalig beim MTK, oder der Thread authentisiert sich bevor er gestartet wird beim MTK oder aber der Thread authentisiert sich erst, wenn er mit einem anderen Thread über den ihm zugewiesenen Kontext hinaus Daten austauschen will. Nur im Falle einer ausreichenden Authentisierung ist der Applikationsprozess bzw. Thread zum Datenaustausch autorisiert.
Da jeder Thread nur einen beschränkten Speicherbereich innerhalb des ihm zugewiesenen Kontexts besitzt, der anderen Threads nicht zugänglich ist, der MTK hingegen den gesamten Speicherbereich kontrolliert, erfolgt der vom MTK autorisierte Datenaustausch zwischen zwei Threads beispielsweise durch Bereitstellung eines beiden Threads gemeinsam zugänglichen Speichersegments, in dem die Anfrage- bzw. Antwortdaten 3a, 3b bzw. 3c, 3d abgelegt werden können.
Alternativ kann der Datenaustausch beispielsweise über Prozessorregister oder einen Stapelspeicher stattfinden. Im Fall einer multitasking- und/ oder multithreadingfähigen Virtuelle Maschine kann der Stapelspeicher der Virtuellen Maschine zum gesicherten Datenaustausch dienen.
Ein erstes konkretes Anwendungsbeispiel der Erfindung betrifft eine Chipkarte, die mehrere "virtuelle" Chipkarten verkörpert. Damit ist es möglich, verschiedene Applikationen, die derzeit auf verschiedenen Chipkarten realisiert sind, wie beispielsweise EC-Karte, Gesundheitskarte, Zutrittskontroll- karte und dergleichen, auf einer einzigen physischen Karte zu implementieren und in sicherer Multitasking- und/ oder Multithreading-Umgebung nebeneinander und unbeeinflusst voneinander zu betreiben. In den Fällen, in denen ein Datenaustausch zwischen den ansonsten getrennten Applikationen mit den ihnen zugewiesenen, gesicherten Kontexten nötig oder er- wünscht ist, kann er mit den oben beschriebenen Mechanismen unter Kontrolle des MTK durchgeführt werden.
Bei einem zweiten konkreten Anwendungsbeispiel der Erfindung wird einzelnen berechtigten und voneinander logisch getrennten Applikationen ex- klαsiv Zugriff auf dieselbe Funktionalität gewährt, die über den oben beschriebenen sicheren Datenaustausch durch eine weitere spezielle Applikation bereitgestellt wird. Entsprechend autorisierte Applikationen können mittels Anfrage an diese spezielle Applikation diese Funktionalität nutzen. Bestimmte Funktionalitäten, die von mehreren Applikationen benötigt werden, können so ressourcensparend gehalten werden, wie beispielsweise eine Funktionalität memcopy zum Kopieren von Speicherbereichen. Aber auch ganze Kryptographiebibliotheken können auf diese Weise mehreren berechtigten Applikationen zugänglich gemacht werden.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Austauschen von Daten zwischen mindestens zwei auf einem portablen elektronischen Datenträger, insbesondere einer Chipkarte, gespeicherten Applikationen, dadurch gekennzeichnet, dass die Applikationen während des Datenaustausche Applikationsprozesse (2a, 2b, 2c) sind und die Kommunikation zwischen den Applikationsprozessen (2a, 2b, 2c) über ein multitasking- und/ oder multithreadingfähiges Betriebssystem (1) koordiniert wird, wobei das multitasking- und/ oder multithreadingfähige Betriebssystem (1) kontrolliert, ob die Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch untereinander autorisiert sind.
2. Verfahren gemäß Anspruch 1, dadurch gekennzeichnet, dass das Betriebssystem (1) eine multitasking- und/ oder multithreadingfähige Virtuelle Maschine umfasst, die die Kommunikation zwischen den Applikationsprozessen (2a, 2b, 2c) koordiniert, wobei die multitasking- und/ oder multithreadingfähige Virtuelle Maschine kontrolliert, ob die Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch untereinander autorisiert sind.
3. Verfahren gemäß Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Datenaustausch über Speicherbereiche stattfindet, die zum Datenaustausch nur von Applikationsprozessen (2a, 2b, 2c) benutzt werden können.
4. Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass der Da- tenaustausch über den Applikationsprozessen (2a, 2b, 2c) gemeinsam zugängliche Hauptspeichersegmente stattfindet.
5. Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass der Datenaustausch über Prozessorregister stattfindet.
6. Verfahren gemäß Anspruch 3, dadurch gekennzeichnet, dass der Datenaustausch über einen Stapelspeicher stattfindet.
7. Verfahren gemäß einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass der Datenaustausch durch Aufrufen einer Funktionalität einer Applikation durch einen anderen Applikationsprozess (2a, 2b, 2c) erfolgt.
8. Verfahren gemäß einem der Ansprüche 1 bis 7, dadurch gekenn- zeichnet, dass die Kontrolle der Autorisierung der Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch unter Rückgriff auf Zugangskontrolllisten oder Capabilities erfolgt.
9. Verfahren gemäß einem der Ansprüche 1 bis 8, dadurch gekenn- zeichnet, dass das Betriebssystem (1) in einem höher privilegierten Modus läuft als die Applikationsprozesse (2a, 2b, 2c).
10. Verfahren gemäß einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass die Rechenzeit jedes Applikationsprozesses (2a, 2b, 2c) durch das Betriebssystem (1) kontrolliert wird und das Betriebssystem (1) den Applikationsprozessen (2a, 2b, 2c) nur vorbestimmte Rechenzeit zur Verfügung stellt.
11. Verfahren gemäß einem der Ansprüche 1 bis 10, dadurch gekenn- zeichnet, dass das Betriebssystem (1) den Applikationsprozessen (2a, 2b, 2c)
Zugriff auf Hardware-Ressourcen zur Verfügung stellt.
12. Verfahren gemäß Anspruch 11, dadurch gekennzeichnet, dass das Betriebssystem (1) die Art des Zugriffs der Applikationsprozesse (2a, 2b, 2c) auf die zur Verfügung gestellten Ressourcen bestimmt.
13. Verfahren gemäß Anspruch 11 oder 12, dadurch gekennzeichnet, dass das Betriebssystem (1) bestimmt, an welche weiteren Applikationspro- zesse (2a, 2b, 2c) und / oder in welcher Form die Zugriffsrechte auf die Ressourcen, die einem Applikationsprozess (2a, 2b, 2c) zur Verfügung gestellt worden sind, weitergegeben werden dürfen.
14. Verfahren gemäß einem der Ansprüche 1 bis 13, dadurch gekenn- zeichnet, dass jede Applikation selbständig entscheidet, ob und / oder welche Daten sie einer anderen Applikation zur Verfügung stellt.
15. Portabler elektronischer Datenträger, gekennzeichnet durch ein mul- titasking- und/ oder multithreadingfähiges Betriebssystem (1), das eingerich- tet ist, einen Austausch von Daten zwischen mindestens zwei auf dem portablen Datenträger gespeicherten Applikationen, die gleichzeitig als Applikationsprozesse (2a, 2b, 2c) vorhanden sind, zu koordinieren, und zu kontrollieren, ob die Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch untereinander autorisiert sind.
16. Datenträger gemäß Anspruch 15, dadurch gekennzeichnet, dass das Betriebssystem (1) eine multitasking- und/ oder multithreadingfähige Virtuelle Maschine umfasst, die eingerichtet ist, die Kommunikation zwischen den Applikationsprozessen (2a, 2b, 2c) zu koordinieren und zu kontrollieren, ob die Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch untereinander autorisiert sind.
17. Datenträger gemäß Anspruch 15 oder 16, dadurch gekennzeichnet, dass das Betriebssystem (1) eingerichtet ist, den Datenaustausch über Spei- cherbereiche stattfinden zu lassen, die zum Datenaustausch nur von Applikationsprozessen (2a, 2b, 2c) benutzt werden können.
18. Datenträger gemäß Anspruch 17, dadurch gekennzeichnet, dass das Betriebssystem (1) eingerichtet ist, den Datenaustausch über den Applikationsprozessen (2a, 2b, 2c) gemeinsam zugängliche Hauptspeichersegmente des Datenträgers stattfinden zu lassen.
19. Datenträger gemäß Anspruch 17, dadurch gekennzeichnet, dass das Betriebssystem (1) eingerichtet ist, den Datenaustausch über Prozessorregister des Prozessors des Datenträgers stattfinden zu lassen.
20. Datenträger gemäß Anspruch 17, dadurch gekennzeichnet, dass das Betriebssystem (1) eingerichtet ist, den Datenaustausch über einen Stapel- Speicher des Prozessors des Datenträgers stattfinden zu lassen.
21. Datenträger gemäß einem der Ansprüche 15 bis 20, dadurch gekennzeichnet, dass das Betriebssystem (1) einen Scheduler zur Zuweisung von Rechenzeit an Applikationsprozesse (2a, 2b, 2c) umfasst, der eingerichtet ist, die Rechenzeit jedes Applikationsprozesses (2a, 2b, 2c) zu kontrollieren und den Applikationsprozessen (2a, 2b, 2c) nur vorbestimmte Rechenzeit zur Verfügung zu stellen.
22. Datenträger gemäß einem der Ansprüche 15 bis 21, dadurch gekenn- zeichnet, dass das Betriebssystem (1) eingerichtet ist, die Kontrolle der Autorisierung der Applikationsprozesse (2a, 2b, 2c) zum Datenaustausch unter Rückgriff auf Zugangskontrolllisten oder Capabilities durchzuführen.
23. Datenträger gemäß einem der Ansprüche 15 bis 22, dadurch gekenn- zeichnet, dass das Betriebssystem (1) eingerichtet ist, in einem höher privilegierten Modus zu laufen als die Applikationsprozesse (2a, 2b, 2c).
24. Datenträger gemäß einem der Ansprüche 15 bis 23, dadurch gekenn- zeichnet, dass das Betriebssystem (1) eine Ressourcenverwaltung umfasst, die eingerichtet ist, den Applikationsprozessen (2a, 2b, 2c) Zugriff auf Hardware-Ressourcen zur Verfügung zu stellen.
25. Datenträger gemäß Anspruch 24, dadurch gekennzeichnet, dass die Ressourcenverwaltung eingerichtet ist, die Art des Zugriffs der Applikationsprozesse (2a, 2b, 2c) auf die zur Verfügung gestellten Ressourcen zu bestimmen.
26. Datenträger gemäß Anspruch 24 oder 25, dadurch gekennzeichnet, dass die Ressourcenverwaltung eingerichtet ist zu bestimmen, an welche weiteren Applikationsprozesse (2a, 2b, 2c) und / oder in welcher Form die Ressourcen, die einem Applikationsprozess (2a, 2b, 2c) zur Verfügung gestellt sind, weitergegeben werden dürfen.
EP07724944A 2006-05-08 2007-05-07 Kommunikation zwischen applikationen auf einem portablen datenträger Withdrawn EP2021919A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200610021383 DE102006021383A1 (de) 2006-05-08 2006-05-08 Kommunikation zwischen Applikationen auf einem portablen Datenträger
PCT/EP2007/004020 WO2007128552A1 (de) 2006-05-08 2007-05-07 Kommunikation zwischen applikationen auf einem portablen datenträger

Publications (1)

Publication Number Publication Date
EP2021919A1 true EP2021919A1 (de) 2009-02-11

Family

ID=38330596

Family Applications (1)

Application Number Title Priority Date Filing Date
EP07724944A Withdrawn EP2021919A1 (de) 2006-05-08 2007-05-07 Kommunikation zwischen applikationen auf einem portablen datenträger

Country Status (3)

Country Link
EP (1) EP2021919A1 (de)
DE (1) DE102006021383A1 (de)
WO (1) WO2007128552A1 (de)

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2007128552A1 *

Also Published As

Publication number Publication date
WO2007128552A1 (de) 2007-11-15
DE102006021383A1 (de) 2007-11-22

Similar Documents

Publication Publication Date Title
DE3689569T2 (de) Verfahren zur Systemdateiensicherung und Datenverarbeitungseinheit zu dessen Durchführung.
DE102014002181B4 (de) Chip und Verfahren zum Betreiben eines Chips
DE102018115489A1 (de) Krypto-erzwungene rechte für isolation
DE102016220639A1 (de) Speicherschutzeinheit und Verfahren zum Schützen eines Speicheradressraumes
DE102022108625B4 (de) Mehrere physische anforderungsschnittstellen für sicherheitsprozessoren
DE112020000792T5 (de) Durch grafikverarbeitungseinheit beschleunigte vertrauenswürdige ausführungsumgebung
DE102015002191A1 (de) Sicherheits-Hypervisor-Funktion
DE102012200613A1 (de) System und Verfahren zur Unterstützung von JIT in einem sicheren System und zufällig zugewiesenen Speicherbereichen
DE102018132970A1 (de) Verfahren und Vorrichtung zur Isolation von sensiblem nichtvertrauenswürdigem Programmcode auf mobilen Endgeräten
EP4078415A1 (de) Verfahren und vorrichtung zum betreiben einer recheneinrichtung
DE1163579T1 (de) Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von laufzeitumgebungsprivilegien
DE1151378T1 (de) Techniken zum gewähren des zugriffs durch eine kontextsperre in einem gerät mit kleinem platzbedarf unter verwendung von gemeinsamen objektschnittstellen
DE102012203521A1 (de) Architektur mit zwei Vertrauenswürdigkeitsstufen
WO2023036672A1 (de) Ausführen von privilegierten operationen in einem container
DE60100363T2 (de) Sequenznummerierungsmechanismus zur sicherung der ausführungsordnungs-integrietät von untereinander abhängigen smart-card anwendungen
DE60017438T2 (de) System zur betriebsmittelzugriffsteuerung
WO2007128552A1 (de) Kommunikation zwischen applikationen auf einem portablen datenträger
DE102015210539A1 (de) Speicherschutzeinheit, Speicherverwaltungseinheit und Mikrocontroller
DE102013016114B3 (de) Bussystem und Verfahren für geschützte Speicherzugriffe
Salaün Landlock LSM: toward unprivileged sandboxing
EP1801696B1 (de) Multithreading - fähige virtuelle Maschine
WO2015197544A1 (de) Verfahren und schaltkreis zur vermeidung von speicherschutzverletzungen
EP4381386B1 (de) Priorisieren eines zugriffs von einer containerinstanz auf eine datei in einer dateisystemressource
DE102005019260A1 (de) Steuerung der Programmausführung in einem ressourcenbeschränkten System
DE10148007A1 (de) Verfahren zur Ressourcenzugriffskoordinierung in einem Datenverarbeitungssystem, Datenverarbeitungssystem und Computerprogramm

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20081208

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL BA HR MK RS

17Q First examination report despatched

Effective date: 20090303

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

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

18D Application deemed to be withdrawn

Effective date: 20090915