WO2005017748A1 - Betriebssystem für einen tragbaren datenträger - Google Patents

Betriebssystem für einen tragbaren datenträger Download PDF

Info

Publication number
WO2005017748A1
WO2005017748A1 PCT/EP2004/008814 EP2004008814W WO2005017748A1 WO 2005017748 A1 WO2005017748 A1 WO 2005017748A1 EP 2004008814 W EP2004008814 W EP 2004008814W WO 2005017748 A1 WO2005017748 A1 WO 2005017748A1
Authority
WO
WIPO (PCT)
Prior art keywords
operating system
data carrier
portable data
emergency service
primary operating
Prior art date
Application number
PCT/EP2004/008814
Other languages
English (en)
French (fr)
Inventor
Wolfgang Rankl
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 WO2005017748A1 publication Critical patent/WO2005017748A1/de

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/77—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in smart cards
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0806—Details of the card
    • G07F7/0833—Card having specific functional components
    • G07F7/084—Additional components relating to data transfer and storing, e.g. error detection, self-diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded

Definitions

  • the operating system according to the invention is designed such that the emergency service can function independently of the primary operating system.
  • the emergency service can have all the functionalities and data required to operate the portable data carrier, so that the portable data carrier can be operated completely independently of the primary operating system.
  • the emergency service has direct access to data of further functional units of the portable data carrier. This has the advantage that the data for the emergency service does not have to be kept in addition, but the direct access nevertheless ensures availability of the data even if the respective functional unit fails.
  • the emergency service can have a limited range of functions compared to the primary operating system. As a result, the effort for the emergency service can be kept within reasonable limits, and manipulations or malfunctions during operation with the emergency service can be prevented or at least the damage that may result is limited.
  • the portable data carrier When the portable data carrier is used in conjunction with an external device, it can be displayed by the external device when the portable data carrier is operated with the emergency service. This is a very simple way of informing the user of the portable data carrier about the transition to the emergency service so that he can adapt to it.
  • the operation of the portable data carrier with the emergency service can be limited to a predefinable period of time, in the case of payment cards, for example, to a predetermined maximum amount. This can at least limit potential misuse of the portable data carrier during operation with the emergency service and there is a strong incentive for the data carrier to be subjected to a check after the period of time has elapsed or when the maximum amount has been reached.
  • the portable data carrier is designed as a chip card.
  • the chip card has an emergency service 6 in addition to the primary operating system 2.
  • the emergency service 6 serves to enable emergency operation of the chip card if the primary operating system 2 fails. In normal operation of the chip card, the emergency service 6 is not active and the chip card is operated with the primary operating system 2.
  • the primary operating system 2 generally supports all of the applications 5 implemented on the chip card, so that, depending on the design of the chip card, there are many possible uses. If an unusual operating situation occurs in which further operation of the chip card with the primary operating system 2 is not advisable or is not possible, a transition takes place from the primary operating system 2 to the emergency service 6, so that control over the chip card is transferred to the emergency service 6 the emergency operation is started. In emergency operation, the range of functions available is usually restricted compared to normal operation.
  • Certain events are defined as triggers for the transition from normal operation to emergency operation, the occurrence of which is continuously monitored in normal operation.
  • An event that triggers the transition can, for example, consist in the primary operating system 2 or the hardware 1 detecting a memory limit violation.
  • the limitation of the range of functions during the transition to the emergency service 6 can be caused on the one hand by the training of the emergency service 6 and on the other hand can be carried out for security reasons.
  • the limitation of the scope of functions in emergency operation is preferably carried out in such a way that potential damage is limited, but use is still possible within these limits.
  • the restriction of the range of functions during the transition from the primary operating system 2 to the emergency Service 6, for example consists in the fact that only domestic calls can be made. It is also possible that calls can still be made for a predetermined remaining amount and then the SIM is finally blocked.
  • the emergency service 6 is designed as an additionally available complete operating system, which exists independently of the primary operating system 2 and is activated instead of the primary operating system 2 when one of the triggering events is present. Since this additional operating system only ensures emergency operation and thus does not have to have all the functionalities of the primary operating system 2, it can be designed to be comparatively simple.
  • a conventional operating system for chip cards can be used as an additional operating system, which has been in use for a long time and in large numbers, so that its reliability is proven. As a result, complex development work can be avoided.
  • the statements made regarding the machine code apply in a corresponding manner to the additional operating system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Mathematical Physics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein Betriebssystem für einen tragbaren Datenträger, das ein primäres Betriebssystem (2) zum Betreiben des tragbaren Datenträgers unter Normalbedingungen beinhaltet. Die Besonderheit des erfindungsgemässen Betriebssystems besteht darin, dass weiterhin ein Notfalldienst (6) vorgesehen ist, mit dem der tragbare Datenträger anstelle des primären Betriebssystems (2) betreibbar ist.

Description

Betriebssystem für einen tragbaren Datenträger
Die Erfindung betrifft ein Betriebssystem für einen tragbaren Datenträger. Weiterhin betrifft die Erfindung einen tragbaren Datenträger mit einem der- artigen Betriebssystem und ein Verfahren zum Betreiben eines tragbaren Datenträgers.
Tragbare Datenträger können sehr vielfältig eingesetzt werden, beispielsweise zur Abwicklung von Transaktionen des Zahlungsverkehrs, als Ausweis- dokumente bei Zugangskontrollen, als Berechtigungsnachweis zur Nutzung eines Mobilfunksystems usw. Hierzu können die tragbaren Datenträger als Chipkarten ausgebildet sein, bei denen ein integrierter Schaltkreis in einen Kartenkörper mit genormten Abmessungen eingebettet ist. Weiterhin sind auch tragbare Datenträger bekannt, bei denen nicht von der Kartenform Ge- brauch gemacht wird, sondern der integrierte Schaltkreis in einen andersartig ausgebildeten Gegenstand eingebettet oder in irgendeiner Form mit einem andersartig ausgebildeten Gegenstand verbunden ist. Im Extremfall kann der integrierte Schaltkreis sogar als separates Bauteil eingesetzt werden.
Unabhängig von seiner Einbauumgebung wird der integrierte Schaltkreis, außer bei sehr einfach strukturierten Anwendungen, mit einem Betriebssystem ausgestattet, mit dem der Betrieb des integrierten Schaltkreises gesteuert wird. Mit der Erweiterung der Einsatzgebiete der tragbaren Datenträger und der Zunahme der Leistungsfähigkeit der integrierten Schaltkreise geht eine zunehmende Komplexität der verwendeten Betriebssysteme einher, wobei ein Ende dieser Entwicklung zur Zeit noch nicht absehbar ist. Der zunehmende Umfang und die zunehmende Komplexität der Betriebssysteme von tragbaren Datenträgern erhöhen trotz sorgfältiger Programmierung und ausgedehnter Testläufe das Risiko, dass die Betriebssysteme unerkannte Fehler enthalten und dadurch möglicherweise instabil werden können. Um unkontrollierte Situationen und insbesondere daraus resultierende Manipulationsmöglichkeiten zu vermeiden, sind die Betriebssysteme für tragbare Datenträger in der Regel so ausgebildet, dass der tragbare Datenträger bei einer erkannten Fehlfunktion innerhalb der Software oder bei einem Absturz des Betriebssystems deaktiviert wird und somit vom Benutzer nicht mehr einsetzbar ist. Ein unvorhersehbarer Ausfall des tragbaren Datenträgers kann für den Benutzer mit erheblichen Unannehmlichkeiten verbunden sein, beispielsweise wenn sich der Benutzer auf den Datenträger als Zahlungsmittel verlässt und er sich in einer Situation befindet, in der er nicht über eine alternative Zahlungsmöglichkeit verfügt. Instabile Betriebssysteme können somit zu einem Rückgang der Akzeptanz von tragbaren Datenträgern führen. Diese Problematik wird dadurch verschärft, dass auf demselben tragbaren Datenträger immer mehr Anwendungen implementiert werden, so dass die Abhängigkeit des Benutzers von der Funktionstüchtigkeit des tragbaren Datenträgers ständig zunimmt.
Der Erfindung liegt die Aufgabe zugrunde, das Ausfallrisiko bei tragbaren Datenträgern möglichst gering zu halten.
Diese Aufgabe wird durch ein Betriebssystem mit der Merkmalskombination des Anspruchs 1 gelöst.
Das erfindungsgemäße Betriebssystem für einen tragbaren Datenträger beinhaltet ein primäres Betriebssystem zum Betreiben des tragbaren Datenträ- gers unter Normalbedingungen. Die Besonderheit des erfindungsgemäßen Betriebssystems besteht darin, dass weiterhin ein Notfalldienst vorgesehen ist, mit dem der tragbare Datenträger anstelle des primären Betriebssystems betreibbar ist. Das erfindungsgemäße Betriebssystem hat den Vorteil, dass es sehr robust gegenüber Störeinflüssen ist und somit eine hohe Betriebssicherheit und Verfügbarkeit des tragbaren Datenträgers gewährleistet ist. Auch nach einem Ereignis, das einen Ausfall des primären Betriebssystems zur Folge hat, ist der tragbare Datenträger weiterhin betriebsbereit.
In der Regel ist das erfindungsgemäße Betriebssystem so ausgebildet, dass der Notfalldienst unabhängig vom primären Betriebssystem funktionsfähig ist. Insbesondere kann der Notfalldienst über sämtliche zum Betreiben des tragbaren Datenträgers erforderliche Funktionalitäten und Daten verfügen, so dass ein vom primären Betriebssystem vollständig autarker Betrieb des tragbaren Datenträgers möglich ist. Neben einer vollständigen Abschottung des Notfalldienstes besteht auch die Möglichkeit, dass der Notfalldienst über eine direkte Zugriffsmöglichkeit auf Daten weiterer Funktionseinheiten des tragbaren Datenträgers verfügt. Dies hat den Vorteil, dass die Daten für den Notfalldienst nicht zusätzlich vorgehalten werden müssen, durch den direkten Zugriff aber dennoch eine Verfügbarkeit der Daten auch bei einem Ausfall der jeweiligen Funktionseinheit sichergestellt ist.
Der Notfalldienst kann über einen gegenüber dem primären Betriebssystem eingeschränkten Funktionsumfang verfügen. Dadurch kann der Aufwand für den Notfalldienst in vertretbaren Grenzen gehalten werden und es können Manipulationen oder Fehlfunktionen während des Betriebs mit dem Notfalldienst verhindert werden oder zumindest der dabei potentiell entste- hende Schaden begrenzt werden.
Abhängig von den jeweiligen Anforderungen an die Betriebssicherheit und an den Funktionsumfang kann der Notfalldienst auf unterschiedliche Weise realisiert werden. So kann der Notfalldienst beispielsweise als ein Maschi- nencode ausgebildet sein, der direkt von einer Hardware des tragbaren Datenträgers ausführbar ist. Damit lässt sich eine sehr hohe Betriebssicherheit erreichen. Ebenso ist es auch möglich, den Notfalldienst als ein zusätzliches Betriebssystem auszubilden. Dies hat den Vorteil eines vergleichsweise ge- ringen Entwicklungsaufwands und bietet die Möglichkeit eines relativ großen Funktionsumfangs.
Die Erfindung bezieht sich weiterhin auf einen tragbaren Datenträger mit dem erfindungsgemäßen Betriebssystem. Dieser tragbare Datenträger weist vorzugsweise einen von außen ohne Einbeziehung des primären Betriebssystems lesbaren Speicher auf und ist insbesondere als Chipkarte ausgebildet.
Beim erfindungsgemäßen Verfahren zum Betreiben eines tragbaren Datenträgers wird der tragbare Datenträger unter Normalbedingungen mit einem primären Betriebssystem betrieben. Beim Auftreten eines vorgebbaren Ereignisses wird vom primären Betriebssystem auf einen Notfalldienst übergegangen und der weitere Betrieb des tragbaren Datenträgers erfolgt mittels des Notfalldienstes. Dies hat den Vorteil, dass mit dem Notfalldienst Ereignisse abgefangen werden können, die beim primären Betriebssystem zu Pro- blemen bis hin zu einem Ausfall führen würden. Der Übergang vom primären Betriebssystem zum Notfalldienst kann irreversibel erfolgen. Dadurch kann eine unkontrollierte Reaktivierung des primären Betriebssystems 5 verhindert werden. Vorzugsweise wird der Übergang vom primären Betriessystem zum Notfalldienst in von außen lesbarer Form in einem Speicher des tragbaren Datenträgers dokumentiert, so dass von außen jederzeit feststellbar ist, ob der tragbare Datenträger mit dem primären Betriebssystem oder mit dem Notfalldienst betrieben wird. Insbesondere ist es zur Erleichterung der Fehlerdiagnose möglich, die Umstände des Übergangs vom primären Betriessystem zum Notfalldienst in von außen lesbarer Form in einem Speicher des tragbaren Datenträgers zu dokumentieren. Bei einem Einsatz des tragbaren Datenträgers in Zusammenwirkung mit einem externen Gerät kann es von dem externen Gerät angezeigt werden, wenn der tragbare Datenträger mit dem Notfalldienst betrieben wird. Dies stellt eine sehr einfache Möglichkeit dar, den Benutzer des tragbaren Datenträgers über den Übergang zum Notfalldienst zu informieren, damit sich dieser darauf einstellen kann. Der Betrieb des tragbaren Datenträgers mit dem Notfalldienst kann auf eine vorgebbare Zeitspanne, im Falle von Zahlungsverkehrskarten beispielsweise auch auf einen vorgegebenen Maximalbetrag begrenzt werden. Dadurch kann ein potentieller Missbrauch des tragbaren Datenträgers während des Betriebs mit dem Notfalldienst zumindest begrenzt werden und es wird ein starker Anreiz gegeben, dass der Datenträger nach Ablauf der Zeitspanne oder bei Erreichen des Maximalbetrages einer Prüfung unterzogen wird.
Die Erfindung wird im folgenden anhand des in der Zeichnung dargestellten Ausführungsbeispiels näher erläutert, bei dem der tragbare Datenträger als Chipkarte ausgebildet ist.
Die einzige Fig. zeigt eine stark vereinfachte Darstellung der Architektur einer Chipkarte. Zum Betrieb einer Hardware 1, die üblicherweise als ein in einen Kartenkörper der Chipkarte eingebetteter integrierter Schaltkreis ausgebildet ist, ist ein Betriebssystem vorgesehen, das im folgenden als primäres Betriebssystem 2 bezeichnet wird. Weiterhin sind eine Hardware- Abstraktionsschicht 3 und ein Funktionsblock 4 vorgesehen, der eine Reihe von grundlegenden Diensten wie beispielsweise Übertragungsprotokolle, Kryptoalgorithmen und eine Speicherverwaltung repräsentiert. Abhängig vom Verwendungszweck der Chipkarte sind eine oder mehrere Anwendungen 5 vorhanden, die mit Hilfe des primären Betriebssystems 2 ausgeführt werden können. Die für die Ausführung der Anwendungen 5 erforderlichen Schnittstellen und sonstige Funktionseinheiten, die für die Erläuterung der Erfindung nicht von Relevanz sind, sind aus Gründen der Übersichtlichkeit nicht figürlich dargestellt und werden im folgenden auch nicht beschrieben.
Von wesentlicher Bedeutung für die Erfindung ist es, dass die Chipkarte zusätzlich zum primären Betriebssystem 2 einen Notfalldienst 6 aufweist. Der Notfalldienst 6 dient dazu, beim Ausfall des primären Betriebssystems 2 einen Notbetrieb der Chipkarte zu ermöglichen. Im Normalbetrieb der Chip- karte ist der Notfalldienst 6 nicht aktiv und die Chipkarte wird mit dem primären Betriebssystem 2 betrieben. Das primäre Betriebssystem 2 unterstützt in der Regel sämtliche auf der Chipkarte implementierten Anwendungen 5, so dass je nach Ausbildung der Chipkarte vielfältige Einsatzmöglichkeiten bestehen können. Wenn eine außergewöhnliche Betriebssituation auf- tritt, in der ein weiterer Betrieb der Chipkarte mit dem primären Betriebssystem 2 nicht angeraten oder nicht möglich ist, erfolgt ein Übergang vom primären Betriebssystem 2 zum Notfalldienst 6, so dass die Kontrolle über die Chipkarte an den Notfalldienst 6 übergeben wird und dadurch der Notbetrieb gestartet wird. Im Notbetrieb ist der verfügbare Funktionsumfang in der Regel gegenüber dem Normalbetrieb eingeschränkt.
Als Auslöser für den Übergang vom Normalbetrieb auf den Notbetrieb werden bestimmte Ereignisse definiert, deren Auftreten im Normalbetrieb fortwährend überwacht wird. Ein den Übergang auslösendes Ereignis kann bei- spielsweise darin bestehen, dass vom primären Betriebssystem 2 oder von der Hardware 1 eine Speichergrenzverletzung detektiert wird. Weiterhin können als auslösende Ereignisse ein von der virtuellen Javamaschine bemerkter falscher Byte-Code, ein detektierter Angriff, ein durch die Betriebs- system-Integritätsprüfungen bemerktes Problem, oder ähnliches definiert sein.
Der Übergang vom primären Betriebssystem 2 zum Notfalldienst 6 erfolgt vorzugsweise irreversibel. Ein reversibler Übergang ist allerdings prinzipiell auch möglich. Wenn es zu einem Übergang kommt, wird dies in einer von außen lesbaren Form auf der Chipkarte gespeichert. Dabei wird auch gespeichert, durch welches auslösende Ereignis der Übergang hervorgerufen wurde, um eine spätere Fehlersuche zu unterstützen. Die Speicherung kann bei- spielsweise in einer Protokolldatei erfolgen. Damit der Benutzer der Chipkarte Kenntnis davon erhält, dass bei der Chipkarte ein Problem aufgetreten ist und infolgedessen nicht mehr der volle Funktionsumfang der Chipkarte, sondern nur noch die vom Notfalldienst 6 unterstützten Funktionen verfügbar sind, wird beispielsweise von einem Chipkarten-Terminal, in das die Chipkarte eingeführt worden ist, eine entsprechende Meldung angezeigt. Um eine baldige Überprüfung der Chipkarte zu erzwingen, kann die Verwendbarkeit der Chipkarte auf einen vorgebbaren Zeitraum nach dem Übergang vom primären Betriebssystem 2 zum Notfalldienst 6 oder bei Zahlungsverkehrskarten auf einen vorgegebenen Maximalbetrag begrenzt werden.
Die Einschränkung des Funktionsumfangs beim Übergang zum Notfalldienst 6 kann zum einen durch die Ausbildung des Notfalldienstes 6 bedingt sein und zum anderen aus Sicherheitserwägungen durchgeführt werden. Dabei wird die Einschränkung des Funktionsumfangs im Notbetrieb vorzugsweise so vorgenommen, dass ein potentiell entstehender Schaden begrenzt wird, innerhalb dieser Grenzen eine Nutzung jedoch noch möglich ist. Bei einer Telekommunikationskarte kann die Einschränkung des Funktionsumfangs beim Übergang vom primären Betriebssystem 2 zum Notfall- dienst 6 beispielsweise darin bestehen, dass nur noch Inlandsgespräche geführt werden können. Ebenso ist es auch möglich, dass noch für einen vorgegebenen Restbetrag telefoniert werden kann und dann eine endgültige Sperrung der SIM erfolgt. Weiterhin könnten im Normalbetrieb verfügbare Zusatzdienste gesperrt werden und der Einsatz der Telekommunikationskarte auf das Führen von Gesprächen eingeschränkt werden oder die maximale Gesprächsdauer auf einen vorgebbaren Wert beschränkt werden. Bei einer Zahlungsverkehrskarte könnte der Übergang vom primären Betriebssystem 2 zum Notfalldienst 6 dazu führen, dass eine Bezahlung nur noch über eine Online- Autorisierung möglich ist. Im Fall einer elektronischen Börse könnte der Übergang bewirken, dass nur noch über einen kleinen Geldbetrag verfügt werden kann. Handelt es sich bei der Chipkarte um eine Signaturkarte, so könnte der Funktionsumfang beim Übergang zum Notfalldienst 6 derart eingeschränkt werden, dass mit der Signaturkarte zwar digitale Si- gnaturen geprüft, jedoch keine digitalen Signaturen mehr erstellt werden können.
Um den Notfalldienst 6 möglichst robust zu machen und dadurch den Notbetrieb mit hoher Zuverlässigkeit gewährleisten zu können, ist der Notf all- dienst 6 weitgehend oder vollständig autark ausgebildet. Dabei ist allerdings zu beachten, dass mit einer zunehmenden Abschottung des Notfalldienstes 6 in der Regel auch eine Einschränkung des möglichen Funktionsumfangs einhergeht. Je nach Anwendungsgebiet sind daher im Rahmen der Erfindung unterschiedliche Ausführungsbeispiele für die Ausbildung des Not- falldienstes 6 vorgesehen.
In einem ersten Ausführungsbeispiel ist der Notfalldienst 6 als kompakter und robuster Maschinencode ausgebildet, der nicht interpretiert, sondern direkt von der Hardware 1 ausgeführt wird. Der Maschinencode für den Notfalldienst 6 weist einen relativ geringen Umfang auf und ist einfach strukturiert, so dass eine hohe Wahrscheinlichkeit für eine fehlerfreie Ausführung besteht. Um die Wahrscheinlichkeit einer fehlerfreien Ausführung weiter zu erhöhen, kann der Maschinencode einer Evaluierung unterzogen werden. Mit Hilfe des Maschinencodes für den Notfalldienst 6 können bestimmte Notfalloperationen direkt abgewickelt werden. Vorzugsweise erfolgt die Abwicklung der Notfalloperationen unter vollständiger Umgehung des primären Betriebssystems 2. Dadurch wird mit großer Zuverlässigkeit verhindert, dass sich etwaige Fehlfunktionen des primären Betriebssystems 2 auf die Abwicklung der Notfalloperationen auswirken. Die für die Abwicklung der Notfalloperationen benötigten Daten wie beispielsweise Transaktionsnummern, persönliche Identifikationsnummern, Schlüssel usw. werden vom Notfalldienst 6 vorgehalten, so dass auch bzgl. der Daten ein Rückgriff auf das primäre Betriebssystem 2 nicht erforderlich ist und lediglich eine di- rekte Anbindung an die Hardware 1 benötigt wird. Die direkte Anbindung des Notfalldienstes 6 an die Hardware 1 ist in der Fig. durch einen Doppelpfeil verdeutlicht. Durch die mit den vorstehenden Maßnahmen erreichte Unabhängigkeit ist der Notfalldienst 6 extrem robust.
Alternativ zur vollständigen Abschottung des Notfalldienstes 6 sind auch unterschiedlich stark ausgeprägte Teilabschottungen möglich. So kann beispielsweise eine Anbindung an die Hardware- Abstraktionsschicht 3 vorgesehen sein, die in der Fig. durch einen Doppelpfeil zwischen dem Notfalldienst 6 und der Hardware- Abstraktionsschicht 3 dargestellt ist. Weiterhin besteht die Möglichkeit einer Anbindung des Notfalldienstes 6 an den Block 4, der die grundlegenden Dienste repräsentiert. Auch diese Anbindung ist in der Fig. durch einen entsprechenden Doppelpfeil dargestellt. Schließlich ist es auch möglich, die für die Notfalloperationen benötigten Daten beispielsweise aus den vom primären Betriebssystem 2 unterstützten Anwendungen 5 auszulesen. Hierzu wird im Sinne einer hohen Betriebssicherheit eine direkte Speicheradressierung bevorzugt. Dies ist in der Fig. durch Pfeile zwischen dem Notfalldienst 6 und den Anwendungen 5 dargestellt. Je nach Einsatzgebiet, für das die Chipkarte vorgesehen ist, können die vorstehend be- schriebenen Abweichungen von einer vollständigen Abschottung des Notfalldienstes 6 einzeln oder in Kombination realisiert werden.
In einem weiteren Ausführungsbeispiel ist der Notfalldienst 6 als zusätzlich vorhandenes vollständiges Betriebssystem ausgebildet, das autark neben dem primären Betriebssystem 2 besteht und beim Vorliegen eines der auslösenden Ereignisse anstelle des primären Betriebssystems 2 aktiviert wird. Da dieses zusätzliche Betriebssystem lediglich den Notbetrieb sicherstellt und somit nicht sämtliche Funktionalitäten des primären Betriebssystems 2 aufweisen muss, kann es vergleichsweise einfach ausgebildet werden. Insbe- sondere kann als zusätzliches Betriebssystem ein herkömmliches Betriebssystem für Chipkarten verwendet werden, das bereits seit langer Zeit und in großer Stückzahl eingesetzt wird, so dass dessen Zuverlässigkeit nachgewiesen ist. Dadurch können aufwendige Entwicklungsarbeiten vermieden werden. Bezüglich der Abschottung des Notfalldienstes 6 gelten die zum Ma- schinencode gemachten Ausführungen für das zusätzliche Betriebssystem in entsprechender Weise.

Claims

P a t e n t a n s p r ü c h e
1. Betriebssystem für einen tragbaren Datenträger, das ein primäres Be- triebssystem (2) zum Betreiben des tragbaren Datenträgers unter
Normalbedingungen beinhaltet, dadurch gekennzeichnet, dass weiterhin ein Notfalldienst (6) vorgesehen ist, mit dem der tragbare Datenträger anstelle des primären Betriebssystems (2) betreibbar ist.
2. Betriebssystem nach Anspruch 1, dadurch gekennzeichnet, dass der Notfalldienst (6) unabhängig vom primären Betriebssystem (2) funktionsfähig ist.
3. Betriebssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Notfalldienst (6) über sämtliche zum Betreiben des tragbaren Datenträgers erforderliche Funktionalitäten und Daten verfügt.
4. Betriebssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Notfalldienst (6) über eine direkte Zugriffsmöglichkeit auf Daten weiterer Funktionseinheiten des tragbaren Datenträgers verfügt.
5. Betriebssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Notfalldienst (6) über einen gegenüber dem primären Betriebssystem (2) eingeschränkten Funktionsumfang verfügt.
6. Betriebssystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Notfalldienst (6) als ein Maschinencode ausgebildet ist, der direkt von einer Hardware (1) des tragbaren Datenträgers ausführbar ist.
7. Betriebssystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass der Notfalldienst (6) als ein zusätzliches Betriebssystem ausgebildet ist.
8. Tragbaren Datenträger, dadurch gekennzeichnet, dass er ein Betriebssystem nach einem der vorhergehenden Ansprüche aufweist.
9. Datenträger nach Anspruch 8, dadurch gekennzeichnet, dass ein von außen ohne Einbeziehung des primären Betriebssystems (2) lesbarer Speicher vorgesehen ist.
10. Datenträger nach einem der Ansprüche 8 oder 9, dadurch gekennzeichnet, dass er als Chipkarte ausgebildet ist.
11. Verfahren zum Betreiben eines tragbaren Datenträgers, wobei der tragbare Datenträger unter Normalbedingungen mit einem primären Betriebssystem (2) betrieben wird, dadurch gekennzeichnet, dass beim Auftreten eines vorgebbaren Ereignisses vom primären Betriebssystem (2) auf einen Notfalldienst (6) übergegangen wird und der weitere Betrieb des tragbaren Datenträgers mittels des Notfalldienstes
(6) erfolgt.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass der
Übergang vom primären Betriebssystem (2) zum Notfalldienst (6) irreversibel erfolgt.
13. Verfahren nach einem der Ansprüche 11 oder 12, dadurch gekennzeichnet, dass der Übergang vom primären Betriessystem (2) zum Notfalldienst (6) in von außen lesbarer Form in einem Speicher des tragbaren Datenträgers dokumentiert wird.
14. Verfahren nach einem der Ansprüche 11 bis 13, dadurch gekennzeichnet, dass die Umstände des Übergangs vom primären Betriessystem (2) zum Notfalldienst (6) in von außen lesbarer Form in einem Speicher des tragbaren Datenträgers dokumentiert werden.
15. Verfahren nach einem der Ansprüche 11 bis 14, dadurch gekennzeichnet, dass bei einem Einsatz des tragbaren Datenträgers in Zusammenwirkung mit einem externen Gerät es von dem externen Gerät angezeigt wird, wenn der tragbare Datenträger mit dem Notfalldienst (6) betrieben wird.
16. Verfahren nach einem der Ansprüche 11 bis 15, dadurch gekennzeichnet, dass der Betrieb des tragbaren Datenträgers mit dem Notfalldienst (6) auf eine vorgebbare Zeitspanne begrenzt wird.
17. Verfahren nach einem der Ansprüche 11 bis 16, dadurch gekennzeichnet, dass der Betrieb des tragbaren Datenträgers mit dem Notfalldienst (6) auf einen Maximalbetrag begrenzt wird, wenn es sich um einen Datenträger für die Bezahlung von Waren oder Dienstleistungen handelt.
PCT/EP2004/008814 2003-08-08 2004-08-06 Betriebssystem für einen tragbaren datenträger WO2005017748A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10336568.0A DE10336568B4 (de) 2003-08-08 2003-08-08 Betriebssystem für einen tragbaren Datenträger
DE10336568.0 2003-08-08

Publications (1)

Publication Number Publication Date
WO2005017748A1 true WO2005017748A1 (de) 2005-02-24

Family

ID=34089133

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/008814 WO2005017748A1 (de) 2003-08-08 2004-08-06 Betriebssystem für einen tragbaren datenträger

Country Status (2)

Country Link
DE (1) DE10336568B4 (de)
WO (1) WO2005017748A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2443008A (en) * 2006-10-20 2008-04-23 Vodafone Plc Group management in a Session Initiation Protocol network.
DE102012015573A1 (de) 2012-08-07 2014-02-13 Giesecke & Devrient Gmbh Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
EP2704053B1 (de) 2012-08-27 2016-09-21 Giesecke & Devrient GmbH Verfahren und System zur Aktualisierung einer Firmware eines Sicherheitsmoduls

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5354974A (en) * 1992-11-24 1994-10-11 Base 10 Systems, Inc. Automatic teller system and method of operating same
US5708776A (en) * 1996-05-09 1998-01-13 Elonex I.P. Holdings Automatic recovery for network appliances
EP0848537A1 (de) * 1996-12-12 1998-06-17 E-Plus Mobilfunk GmbH Verfahren und Vorrichtung zum Wiederaufladen bzw. Wiedernutzbarmachen einer Telefonkarte für Handys
WO1998059325A2 (de) * 1997-06-23 1998-12-30 Siemens Aktiengesellschaft Chipkarte zur ausführung von nicht änderbaren system-programmroutinen und diesen zugeordneten ersatz-programmroutinen, sowie verfahren zum betrieb der chipkarte
WO2001084512A1 (fr) * 2000-04-28 2001-11-08 Gemplus Carte a puce multi-applicatives

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6381694B1 (en) 1994-02-18 2002-04-30 Apple Computer, Inc. System for automatic recovery from software problems that cause computer failure
US5627964A (en) * 1994-12-13 1997-05-06 Microsoft Corporation Reduce or fail-safe bootstrapping of a system having a graphical user interface
US6490722B1 (en) * 1999-03-30 2002-12-03 Tivo Inc. Software installation and recovery system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5354974A (en) * 1992-11-24 1994-10-11 Base 10 Systems, Inc. Automatic teller system and method of operating same
US5708776A (en) * 1996-05-09 1998-01-13 Elonex I.P. Holdings Automatic recovery for network appliances
EP0848537A1 (de) * 1996-12-12 1998-06-17 E-Plus Mobilfunk GmbH Verfahren und Vorrichtung zum Wiederaufladen bzw. Wiedernutzbarmachen einer Telefonkarte für Handys
WO1998059325A2 (de) * 1997-06-23 1998-12-30 Siemens Aktiengesellschaft Chipkarte zur ausführung von nicht änderbaren system-programmroutinen und diesen zugeordneten ersatz-programmroutinen, sowie verfahren zum betrieb der chipkarte
WO2001084512A1 (fr) * 2000-04-28 2001-11-08 Gemplus Carte a puce multi-applicatives

Also Published As

Publication number Publication date
DE10336568A1 (de) 2005-02-24
DE10336568B4 (de) 2019-06-19

Similar Documents

Publication Publication Date Title
DE69817543T2 (de) Automatische Datenrückgewinnung in Chipkarten
DE69909379T2 (de) System und Verfahren zum Schützen von geheimen Informationen gegen analytische Spionage
EP1611510B1 (de) Kontrollierte ausführung eines für eine virtuelle maschine vorgesehenen programms auf einem tragbaren datenträger
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
DE10336568B4 (de) Betriebssystem für einen tragbaren Datenträger
EP2652665B1 (de) Portabler datenträger mit fehlbedienungszähler
EP2531949B1 (de) Verfahren zum ausführen einer anwendung
EP2524333A1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
EP1927870B1 (de) Tragbarer Datenträger
DE102007018777A1 (de) Steuervorrichtung für Fahrzeuge
DE102007027935A1 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
DE10351745B4 (de) Verfahren und System zum Betreiben eines tragbaren Datenträgers
DE10247794A1 (de) Verwalten eines Fehlversuchszählers in einem tragbaren Datenträger
EP1564639B1 (de) Verfahren zum Betreiben einer Datenträgervorrichtung mit Ablaufdiagnosespeicher
EP1899883B1 (de) Verfahren zum schutz vertraulicher daten
DE19930144C1 (de) Verfahren zum Erkennen von fehlerhaften Speicherzugriffen in prozessorgesteuerten Einrichtungen
DE102008027456A1 (de) Verfahren zum Schutz eines tragbaren Datenträgers
EP1032878B1 (de) Überwachungssystem für datenverarbeitungsanlagen
DE102004029104A1 (de) Verfahren zum Betreiben eines tragbaren Datenträgers
DE60035915T2 (de) Einrichtung und Verfahren zur Prüfung eines nichtflüchtigen wiederprogrammierbaren Speichers
WO2004064427A1 (de) Authentifizierungsmodul
DE102010035314B4 (de) Verfahren zum Verwalten eines Fehlbedienungszählers in einem tragbaren Datenträger
DE10323033A1 (de) Laden eines ausführbaren Programms in einen tragbaren Datenträger
EP3469511A1 (de) Speicherverwaltung eines sicherheitsmoduls
DE10334815B4 (de) Verfahren zum Abspeichern und Auslesen von Daten

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
122 Ep: pct application non-entry in european phase