-
Die
Erfindung betrifft allgemein das technische Gebiet der tragbaren
Datenträger,
die zum Ausführen
von mehr als einer Applikation – auch
Anwendung oder Anwendungsprogramm genannt – eingerichtet sind. Ein solcher
Multiapplikations-Datenträger
kann in unterschiedlichen Bauformen beispielsweise als Chipkarte
(Smart Card) oder als Chipmodul (Smart Token) oder als vergleichbares
ressourcenbeschränktes
System ausgestaltet sein.
-
Im
Zuge der technischen Entwicklung wächst die Leistungsfähigkeit
von tragbaren Datenträgern – sowohl
im Hinblick auf die Rechenleistung als auch im Hinblick auf den
zur Verfügung
stehenden Speicherplatz – immer
weiter an. Da auch stets neue Anwendungsgebiete für tragbare
Datenträger erschlossen
werden, gewinnen Datenträger
mit Multiapplikations-Funktionalität zunehmend an Bedeutung.
-
Bei
Multiapplikations-Datenträgern
können mehrere
Applikationen gleichzeitig installiert sein und in der Regel auch
während
des Betriebs des Datenträgers
beim Endbenutzer nachgeladen werden. Dadurch verkompliziert sich
die Applikationsverwaltung, weil im Laufe der Zeit eine unüberschaubare
Vielfalt unterschiedlicher Kombinationen von Applikationen und Applikationsversionen
auf den im Besitz der Endbenutzer befindlichen Datenträgern entsteht.
-
Aus
dem Dokument "GlobalPlatform
Card Specification",
herausgegeben von GlobalPlatform, Inc., Foster City, Kalifornien,
USA, Version 2.1.1, März
2003, ist eine Architektur für
Multiapplikations-Datenträger
bekannt, bei der ein als Card Manager bezeichnetes, zentrales Verwaltungsmodul
vorgesehen ist. Der Card Manager führt eine Vielzahl von Aufgaben
aus, die insbesondere verwaltungs- und sicherheitstechnischer Natur
sind. Hierbei nutzt der Card Manager eine als Registry bezeichnete, zentrale
Verwaltungsdatei, die eine Vielzahl von Verwaltungsinformationen
enthält.
-
Eine
Aufgabe des Card Manager ist die Applikationsverwaltung, die unter
anderem das Laden von Programmdateien auf den Datenträger, die
Installation von Applikationen und das Löschen von Applikationen und
Programmdateien umfaßt.
Der Card Manager verwaltet hierbei Datenelemente in der Registry,
die in Abschnitt 6.6.2 des Dokuments "GlobalPlatform Card Specification" beschrieben sind.
Unter anderem umfassen diese Datenelemente je einen Applikationsbezeichner
AID (Application Identifier) für
jede auf dem Datenträger
installierte Applikation.
-
Der
Card Manager kann jedoch keine Informationen darüber liefern, welche Applikationen
aufeinander aufbauen beziehungsweise erforderlich sind, um andere
Applikationen ausführen
zu können. Diese
Einschränkung
beeinträchtigt
die Applikationsverwaltung insbesondere bei komplexen Applikationsstrukturen.
Es besteht daher ein Bedürfnis
nach verbesserten Möglichkeiten
zur Applikationsverwaltung.
-
Bei
tragbaren Datenträgern
ist die Verwendung von Dateisystemen gemäß der Norm ISO/IEC 7816-4,
herausgegeben von der International Standardisation Organisation,
Genf, Schweiz, weit verbreitet. Ein Dateisystem gemäß dieser
Norm weist eine als EFDIR oder kurz DIR
(Directory) bezeichnete Datei auf, in der für jede installierte Applikation
der eindeutige Applikationsbezeichner AID dieser Applikation und
eine Pfadangabe zu der Applikation enthalten sind. Auch die DIR-Datei
kann jedoch keine Informationen über
Abhängigkeiten
zwischen den Applikationen liefern.
-
Die
Erfindung hat demgemäß die Aufgabe, eine
verbesserte Technik zur Applikationsverwaltung auf einem tragbaren
Multiapplikations-Datenträger bereitzustellen.
Insbesondere soll durch die Erfindung die Verwaltung von Applikationsstrukturen
mit Abhängigkeiten
zwischen den Applikationen vereinfacht werden.
-
Erfindungsgemäß wird diese
Aufgabe ganz oder zum Teil gelöst
durch ein Verfahren mit den Merkmalen von Anspruch 1, einen tragbaren
Multiapplikations-Datenträger
gemäß Anspruch
10 und ein Computerprogrammprodukt gemäß Anspruch 11. Die abhängigen Ansprüche definieren
optionale Merkmale in manchen Ausführungsformen der Erfindung.
-
Die
Erfindung geht von der Grundidee aus, in zentralen – also nicht
nur applikationslokalen – Verwaltungsdaten
zu vermerken, von welchen anderen Applikationen der Betrieb einer
ersten Applikation abhängig
ist. Dadurch wird eine unkomplizierte Möglichkeit zur Applikationsverwaltung
geschaffen. Zum Beispiel kann – von
außen
oder innerhalb des Datenträgers – geprüft werden,
ob Abhängigkeiten
zwischen Applikationen vorliegen. Als weiteres Beispiel können gegebenenfalls
fehlende – also
erforderliche, aber nicht auf dem Datenträger vorhandene – Applikationen
auf einfache Weise nachgeladen werden.
-
In
bevorzugten Ausgestaltungen wird unter einer "Applikation" ein individuell anwählbares Anwendungsprogramm
auf dem Datenträger
verstanden. Eine ausführbare
Ladedatei (Executable Load File) und ein ausführbares Modul (Executable Module)
gemäß der GlobalPlatform-Spezifikation,
die lediglich Programmcode für
eine Applikation enthalten, aber selbst nicht anwählbar sind,
sollen vorzugsweise nicht als Applikationen im Sinne des vorliegenden Dokuments
angesehen werden.
-
Vorzugsweise
erfolgt das Eintragen der erfindungsgemäßen Informationen im Zusammenhang mit
dem Laden und/oder der Installation einer Applikation. Hierbei kann
in manchen Ausgestaltungen ein Verwaltungsmodul eingesetzt werden.
Das Verwaltungsmodul kann optional auch dazu dienen, Informationen über fehlende
Applikationen zu ermitteln und z.B. in Reaktion auf eine externe
Anfrage auszugeben.
-
Der
tragbare Datenträger
und/oder das Computerprogrammprodukt weisen in bevorzugten Weiterbildungen
Merkmale auf, die den oben erwähnten
und/oder den in den Verfahrensansprüchen genannten Merkmalen entsprechen.
Das erfindungsgemäße Computerprogrammprodukt
kann ein körperliches
Medium sein, z.B. ein Halbleiterspeicher oder eine Diskette oder
eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nichtkörperliches
Medium sein, z.B. ein über
ein Computernetzwerk übermitteltes
Signal. Insbesondere kann das Computerprogrammprodukt bei der Herstellung und/oder
Initialisierung und/oder Personalisierung des Datenträgers oder
während
des Einsatzes des Datenträgers
beim Endbenutzer verwendet werden.
-
Weitere
Merkmale, Aufgaben und Vorteile der Erfindung ergeben sich aus der
folgenden Beschreibung eines Ausführungsbeispiels und mehrerer
Ausführungsalternativen.
-
1 zeigt
als einzige Zeichnungsfigur ein Blockdiagramm eines Datenträgers nach
einem Ausführungsbeispiel
der Erfindung.
-
Der
in 1 dargestellte Multiapplikations-Datenträger 10 weist
einen Ein-Chip-Mikrocontroller
auf, in dem in an sich bekannter Weise ein Prozessor 12,
ein Speicher 14 und eine Schnittstellenschaltung 16 integriert
sind. Der Speicher 14 ist in mehrere in unterschiedlichen
Technologien ausgestaltete Speicherfelder – z.B. RAM, ROM und EEPROM – gegliedert.
Die Schnittstellenschaltung 16 dient zur kontaktgebundenen
oder kontaktlosen Kommunikation mit einem externen – in 1 nicht gezeigten – Terminal.
-
Im
Speicher 16 – und
zwar teils im ROM und teils im EEPROM – befindet sich ein Betriebssystem 18,
das multiapplikationsfähig
ist und beispielsweise eine weiterentwickelte Version eines der
an sich bekannten Betriebssysteme STARCOS® oder
SECCOS® sein
kann. Das Betriebssystem 18 weist in mehreren aufeinander
aufbauenden Schichten hardwarenahe Treiber, eine Laufzeitumgebung
und Anwendungsprogrammierschnittstellen (APIs) auf.
-
Im
Speicher 14 des Datenträgers 10 befinden
sich mehrere Applikationen 20A, 20B, 20C,
die im folgenden zusammenfassend mit 20x bezeichnet werden.
Jede Applikation 20x stellt ein lauffähiges und durch das externe
Terminal individuell selektierbares Anwendungsprogramm dar. Manche
der Applikationen 20x können
schon bei der Herstellung des Datenträgers 10 in das ROM
oder EEPROM eingeschrieben worden sein, während andere Applikationen 20x erst
bei der Initialisierung oder Personalisierung oder während der
Benutzung des Datenträgers 10 in
diesen nachgeladen worden sind.
-
Der
Datenträger 10 enthält ferner
ein Verwaltungsmodul 22, das eine Vielzahl von Aufgaben übernimmt
und unter anderem zur Applikationsverwaltung dient. Das Verwaltungsmodul 22 ist
in 1 als vom Betriebssystem 18 getrennte
Einheit gezeigt, aber es versteht sich, dass das Verwaltungsmodul 22 in
Ausführungsalternativen
auch in das Betriebssystem 18 integriert sein kann.
-
Das
Verwaltungsmodul 22 greift auf Verwaltungsdaten 24 zu,
die im EEPROM des Datenträgers 10 gespeichert
sind. Die Verwaltungsdaten 24 sind zentral gespeichert.
Hierunter wird in den vorliegenden Ausführungsbeispielen verstanden,
dass die Verwaltungsdaten 24 in einer oder mehreren Datei/en
enthalten sind und allen Applikationen 20x – gegebenenfalls
unter Vermittlung des Verwaltungsmoduls 22 – zur Verfügung stehen.
Eine bei den einzelnen Applikationen 20x verteilte Speicherung
der Verwaltungsdaten 24 ist also in den hier beschriebenen
Ausführungsbeispielen
nicht vorgesehen. Dies schließt
nicht aus, dass in den Applikationen 20x zusätzliche
Daten, die zur Verwaltung des Datenträgers 10 nützlich sind,
lokal gespeichert sein können.
-
In
unterschiedlichen Ausgestaltungen können die Verwaltungsdaten 24 geringen
oder großen Umfang
aufweisen; für
das hier beschriebene Ausführungsbeispiel
ist hauptsächlich
ein in den Verwaltungsdaten 24 enthaltenes Applikationsverzeichnis 26 von
Interesse. In dem Applikationsverzeichnis 26 sind für jede im
Datenträger 10 installierte
Applikation 20x ein eindeutiger Applikationsbezeichner
(AID = Application Identifier) der Applikation 20x sowie
ferner Applikationsbezeichner derjenigen anderen Applikationen 20x vermerkt,
die die erstgenannte Applikation 20x benötigt, um
lauffähig
zu sein. So gibt beispielsweise der in 1 dargestellte
Eintrag im Applikationsverzeichnis 26 an, dass die Applikation 20A mit
dem Applikationsbezeichner 123 zum Betrieb die Applikation 20B mit
dem Applikationsbezeichner 345 sowie eine weitere, in 1 nicht
gezeigte Applikation mit dem Applikationsbezeichner 567 benötigt.
-
In 1 ist
das Applikationsverzeichnis 26 in Form einer Tabelle veranschaulicht,
aber es versteht sich, dass zur Implementierung des Applikationsverzeichnisses 26 beliebige
Datenstrukturen verwendet werden können.
-
So
kann das Applikationsverzeichnis 26 beispielsweise als
Datei mit einer Vielzahl von TLV-Objekten (TLV = Tag, Length, Value
= Kennzeichen, Länge,
Wert) ausgestaltet sein, die je einen Applikationsbezeichner einer
vorhandenen Applikation 20x und gegebenenfalls einen oder
mehrere Applikationsbezeichner der jeweils benötigten Applikationen 20x angeben.
-
Im
vorliegend beschriebenen Ausführungsbeispiel übermittelt
jede Applikation 20x die Informationen über die von ihr benötigten anderen
Applikationen 20x an das Verwaltungsmodul 22,
das seinerseits einen oder mehrere entsprechende Einträge in den
Verwaltungsdaten 24 – insbesondere
dem Applikationsverzeichnis 26 – anlegt. Dieser Vorgang, der in 1 durch
einen gestrichelten Pfeil 28 veranschaulicht ist, kann
insbesondere im Zusammenhang mit dem Laden der Applikation 20x in
den Datenträger 10 oder
im Zusammenhang mit der Installation der Applikation 20x erfolgen.
Die Einschaltung des Verwaltungsmoduls 22 ist erforderlich,
weil im vorliegenden Ausführungsbeispiel
nur das Verwaltungsmodul 22 Zugriff auf die Verwaltungsdaten 24 hat.
In Ausführungsalternativen
kann dagegen vorgesehen sein, dass die Applikationen 20x unmittelbar
auf die Verwaltungsdaten 24 zugreifen und die erforderlichen
Informationen in das Applikationsverzeichnis 26 eintragen.
-
Aufgrund
der im Applikationsverzeichnis 26 enthaltenen Daten kann
das Verwaltungsmodul 22 mit geringem Aufwand prüfen, ob
eine Applikation 20x lauffähig ist, oder ob zusätzliche
Applikationen 20x benötigt
werden und in den Datenträger 10 nachgeladen
werden müssen.
Eine solche Prüfung und/oder
ein erforderlicher Nachladevorgang kann/können intern angestoßen werden.
Alternativ oder zusätzlich
kann jedoch auch eine externe Abfrage der Applikationskonfiguration
des Datenträgers 10 vorgesehen
sein. 1 zeigt hierzu beispielhaft eine Anfrage 30 in
Form einer Kommando- APDU
(APDU = Application Protocol Data Unit) mit einem Statusabfragebefehl
wie z.B. dem Befehl GET STATUS.
-
In
Reaktion auf den Erhalt des Statusabfragebefehls überprüft das Verwaltungsmodul 22,
ob zusätzliche
Applikationen 20x erforderlich sind, um alle Abhängigkeiten
einer oder mehrerer bereits auf dem Datenträger 10 befindlichen
Applikation/en 20x aufzulösen. In dem in 1 gezeigten
Beispiel fehlt noch die Applikation mit dem Applikationsbezeichner 567,
die von der Applikation 20A benötigt wird. Das Verwaltungsmodul 22 meldet
diese Information in einer geeigneten Antwort 32, nämlich einer
Antwort-APDU, an das externe Terminal, das dann seinerseits – gegebenenfalls
in Abstimmung mit einem Hintergrundrechner – das Nachladen der noch fehlenden
Applikation (AID 567) veranlassen kann.
-
In
manchen Ausgestaltungen ist der Datenträger 10 gemäß der eingangs
bereits erwähnten GlobalPlatform
Card Specification ausgestaltet. Das Verwaltungsmodul 22 kann
dann insbesondere als Card Manager ausgebildet sein, und die Verwaltungsdaten 24 können als
Registry ausgebildet oder in der Registry enthalten sein. Das Applikationsverzeichnis 26 wird
in solchen Ausführungsformen
vorzugsweise durch entsprechende Einträge in der Registry gebildet.
-
Alternativ
oder zusätzlich
zu den Merkmalen der GlobalPlatform Card Specification kann der
Datenträger 10 in
manchen Ausgestaltungen ein Dateisystem gemäß der Norm ISO/IEC 7816-4 aufweisen. In
diesem Fall kann das Applikationsverzeichnis 26 durch die
Datei EFDIR gebildet sein. Die einzelnen
Applikationen 20x können
die Datei EFDIR unmittelbar oder über einen
Betriebssystemdienst beschreiben, um die erforderlichen Informationen
einzutragen. Ein Verwaltungsmodul 22 ist nicht in allen
Ausgestaltungen vorhan den, es kann aber insbesondere als Teil des
Betriebssystems 18 vorgesehen sein, um eine Funktionalität zur Ermittlung
von fehlenden Applikationen 20x und zur internen und/oder
externen Abfrage bereitzustellen.
-
Die
beschriebenen Lösungsansätze sind
allgemein anwendbar für
Softwarekomponenten eines tragbaren Datenträgers. Als Softwarekomponenten können neben
Applikationen auch Teile von Applikationen, Teile des Betriebssystems,
wie beispielsweise Systemprogramme, Treiber, insbesondere für I/O-Schnittstellen
und Bibliotheken gesehen werden.