-
Die
Erfindung betrifft ein Betriebssystem für einen tragbaren Datenträger. Weiterhin
betrifft die Erfindung einen tragbaren Datenträger mit einem derartigen 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 Ausweisdokumente 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 Gebrauch 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
entstehende 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 geringen
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 Problemen 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 Chipkarte 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 auftritt, 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 beispielsweise 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 beispielsweise 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 Signaturen 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 Notfalldienst 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 Notfalldienstes 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
direkte 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 beschriebenen 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. Insbesondere 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 Maschinencode gemachten
Ausführungen
für das
zusätzliche
Betriebssystem in entsprechender Weise.