-
Die
Erfindung betrifft allgemein das technische Gebiet der Installation
von Patches in Smartcard-Modulen. Ein Smartcard-Modul in der Wortwahl des
vorliegenden Dokuments kann beispielsweise die Bauform einer Chipkarte
oder eines kompakten Chipmoduls aufweisen.
-
Smartcard-Module
werden für eine Vielzahl von Anwendungen eingesetzt. Neben
den ursprünglich vorherrschenden Ausgestaltungen als Chipkarten
oder einsteckbare Chipmodule – z. B. SIMs für Mobiltelefone – werden
in zunehmendem Umfang Smartcard-Module entwickelt, die zum festen
Einbau in Geräte vorgesehen sind. Solche eingebaute Module
können beispielsweise als NFC-Module (NFC = Near Field
Communications) ausgestaltet sein, die die Funktion einer Smartcard
mit einer drahtlosen Kommunikationsschnittstelle kurzer Reichweite
kombinieren. Nach der Herstellung eines Gerätes mit fest eingebautem
Smartcard-Modul – z. B. eines Mobiltelefons mit eingelötetem
Smartcard-Modul – ist das Smartcard-Modul nicht mehr oder
nur noch mit erheblichem Aufwand von dem Gerät trennbar.
-
Viele
Ausgestaltungen von Smartcard-Modulen weisen Systemprogramme auf,
die eine Laufzeitumgebung zum Ausführen von Applikationen
und ein Ladeprogramm zum Laden von Applikationen in das Smartcard-Modul
bereitstellen. Derartige Smartcard-Module sind z. B. unter der Marke
Java Card bekannt. Das Dokument "Runtime Environment Specification
Java CardTM Platform, Version 2.2.2", März 2006,
herausgegeben von der Firma Sun Microsystems, Inc., Santa Clara,
USA, beschreibt die Laufzeitumgebung einschließlich des
Ladeprogramms bei Java-Card-Modulen.
-
Viele
Smartcard-Module enthalten umfangreiche und komplexe Software. Dies
gilt insbesondere für Java-Card-Module, weil diese relativ
aufwändig sind und daher primär für anspruchsvolle
Aufgaben eingesetzt werden. Auch wenn die in einem Smartcard-Modul
enthaltene Software mit großer Sorgfalt erstellt wird,
sind Fehler nicht völlig auszuschließen. Um derartige
Fehler vor der Auslieferung des Smartcard-Moduls zu korrigieren,
ist es bekannt, im Zuge der Komplettierung oder der Initialisierung
des Smartcard-Moduls Patches in das Modul einzubringen. Gemäß dem
allgemein üblichen Sprachgebrauch wird hierbei unter einem
Patch oder "Flicken" Programmcode verstanden, der kein eigenständiges System-
oder Anwendungsprogramm darstellt, sondern zur Modifikation eines
bestehenden Programms – insbesondere zur Fehlerkorrektur
oder Funktionserweiterung – dient.
-
Die
gerade erwähnte Patch-Möglichkeit ist jedoch nach
der Komplettierung bzw. Initialisierung des Smartcard-Moduls nicht
mehr nutzbar. Wird ein schwerwiegender Fehler erst nach diesem Zeitpunkt entdeckt,
so kann ein Austausch des Smartcard-Moduls erforderlich werden.
Bei einem Smartcard-Modul in Chipkarten-Bauform besteht das Problem
weniger in den Kosten für eine neue Chipkarte, sondern vielmehr
in dem logistischen Aufwand, der entsteht, wenn sich die Chipkarte
bereits beim Endverbraucher befindet. Handelt es sich dagegen um
ein fest in ein Gerät eingebautes Smartcard-Modul wie z.
B. ein NFC-Modul, so sind möglicherweise viele bereits
produzierte Geräte unbrauchbar oder in ihrer Funktion stark
eingeschränkt. Je nach dem Wert der Geräte kann
dadurch großer Schaden entstehen.
-
Prinzipiell
könnten natürlich eine neue Generation von Smartcard-Modulen
und ein speziell angepasstes Hintergrundsystem entwickelt werden,
die eine Funktion zum Patchen der Smartcard-Module im Feld bereitstellen.
Diese Vorgehensweise wäre jedoch technisch komplex, teuer
und zeitaufwändig. Es besteht daher Bedarf nach einer Patch-Möglichkeit, die
sich mit möglichst wenig Aufwand und möglichst geringen Änderungen
bei heute üblichen Smartcard-Modulen – z. B. Java-Card-Modulen – und
heute üblichen Hintergrundsystemen einsetzen lässt.
-
Das
US-Patent 6,202,208 offenbart
eine Technik zum Patchen eines von einer Java
TM Virtual Machine – also
nicht einer Java Card Virtual Machine – üblicherweise
auf einem PC oder jedenfalls einem hinsichtlich seiner Hardware-Ressourcen
nicht beschränkten System ausgeführten Programms.
Beim Einspielen eines Patch wird mindestens ein Eintrag in einer
Methodentabelle des Programms geändert, so daß der
geänderte Eintrag auf einen durch den Patch bereitgestellten
Methodenkörper (method body) verweist. Auf diese Weise
kann das Programm während des laufenden Betriebs geändert
werden. Diese Funktionalität ist z. B. für Telekommunikation-Vermittlungsanlagen
wichtig, bei denen möglichst keine Ausfallzeiten auftreten
sollen.
-
Die
Erfindung hat die Aufgabe, eine Technik zur Installation eines Patch
in einem Smartcard-Modul auch nach der Komplettierung bzw. Initialisierung des
Smartcard-Moduls bereitzustellen, die nur geringen Aufwand und nur
geringe Änderungen an bestehenden Komponenten und Strukturen
erfordert.
-
Erfindungsgemäß wird
diese Aufgabe durch ein Verfahren mit den Merkmalen des Anspruchs
1, ein Verfahren mit den Merkmalen des Anspruchs 11 und ein Smartcard-Modul
mit den Merkmalen des Anspruchs 12 gelöst. Die abhängigen
Ansprüche betreffen optionale Merkmale einiger Ausgestaltungen
der Erfindung.
-
Die
Erfindung geht von der Grundidee aus, die an sich bekannte Funktion
des Smartcard-Moduls zum Laden von Applikationen auch zum Einbringen des
Patch in das Smartcard-Modul zu verwenden. Hierzu ist erfindungsgemäß vorgesehen,
mittels des Ladeprogramms eine Pseudo-Applikation, die den Patch
enthält, in das Smartcard-Modul zu laden, und eine in der
Pseudo-Applikation enthaltene Installationsroutine aufzurufen, die
ihrerseits den Patch einer in den Systemprogrammen enthaltenen Patchroutine mit teilt,
um den Patch an einen Ort außerhalb der Pseudo-Applikation
zu installieren.
-
Das
erfindungsgemäße "Verpacken" des Patch in die
Pseudo-Applikation hat den erheblichen Vorteil, daß an
sich bekannte Funktionen und Strukturen, wie sie z. B. bei Smartcard-Modulen
nach dem Java-Card-Standard üblich sind, zum Erzielen der Patch-Funktionalität
genutzt werden. So braucht z. B. in manchen Ausgestaltungen lediglich
die Patchroutine neu entwickelt zu werden, und auch diese Patchroutine
kann sich auf bereits bestehende Funktionen zum Einbringen von Patches
während der Initialisierung und/oder Komplettierung des
Smartcard-Moduls stützen. Das eigentlich zum Laden regulärer
Applikationen vorgesehene Ladeprogramm kann in manchen Ausgestaltungen
ohne jede Veränderung auch zum Laden der Pseudo-Applikation,
die den Patch enthält, eingesetzt werden.
-
Das
erfindungsgemäße Verfahren ist für die Außenwelt
transparent. Der in die Pseudo-Applikation verpackte Patch kann
daher auf beliebige Weise – z. B. in einem OTA-Ladevorgang
(OTA = over the air) in das Smartcard-Modul eingebracht werden.
-
In
manchen Ausgestaltungen ist der Patch für mindestens eines
der Systemprogramme des Smartcard-Moduls vorgesehen. Der Patch kann
beispielsweise in einen gesonderten Patchbereich in einem nicht-flüchtigen überschreibbaren
Speicher des Smartcard-Moduls eingeschrieben werden.
-
In
manchen Ausführungsformen ist der Patch durch eine Signatur
abgesichert. Alternativ oder zusätzlich kann ein Identifikator
vorgesehen sein, der sicherstellt, daß nur eine ununterbrochene Folge
aufeinander aufbauender Patches installiert werden kann. Allgemein
können beliebige kryptographische Prüfsummen und
Authentisierungen verwendet werden, um das Verfahren gegen eine
unautorisierte Veränderung der im Smartcard-Modul gespeicherten
Programme abzusichern.
-
In
den Ausführungsbeispielen des vorliegenden Dokuments werden
hauptsächlich Smartcard-Module nach dem Java-Card-Standard
beschrieben. Die Erfindung ist jedoch auch zur Verwendung bei anderen
Smartcard-Modulen geeignet, die ähnliche Strukturen aufweisen.
Dies können beispielsweise Smartcard-Module nach dem NET-Standard
sein.
-
Weitere
Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden
genauen Beschreibung eines Ausführungsbeispiels und mehrerer
Ausführungsalternativen hervor. Es wird auf die schematischen
Zeichnungen verwiesen, in denen zeigen:
-
1 ein
Blockdiagramm mit Funktionseinheiten eines Smartcard-Moduls nach
einem Ausführungsbeispiel der Erfindung,
-
2 eine
Darstellung der Systemprogramme und der Pseudo-Applikation im Speicher
des Smartcard-Moduls nach 1 bei der
Installation des Patch, und
-
3 ein
Ablaufdiagramm eines Verfahrens zur Installation eines Patch in
dem Smartcard-Modul nach 1.
-
Das
in 1 dargestellte Smartcard-Modul 10 ist
im vorliegenden Ausführungsbeispiel als Chipmodul zum Einlöten
in ein Host-Gerät – z. B. ein Mobiltelefon – ausgestaltet.
Das Smartcard-Modul 10 weist einen Prozessor 12,
einen Speicher 14, eine Host-Schnittstelle 16 und
eine Funk-Schnittstelle 18 auf. Hierbei wird die Host-Schnittstelle 16 zur
leitungsgebundenen Kommunikation mit dem Host-Gerät verwendet,
während die Funk-Schnittstelle 18 zur drahtlosen
Kommunikation über kurze Distanzen (NFC = Near Field Communications)
mit einem externen Terminal dient.
-
Der
Speicher 14 ist in mehrere Speicherfelder unterteilt. Im
vorliegenden Ausführungsbeispiel sind als Speicherfelder
ein als ROM ausgebildeter Festwertspeicher 20, ein als
EEPROM ausgebildeter, nicht-flüchtiger überschreibbarer
Speicher 22 und ein als RAM ausgebildeter Arbeitsspeicher 24 vorgesehen.
-
Das
Smartcard-Modul 10 ist gemäß dem Java-Card-Standard
ausgestaltet. Es weist umfangreiche Systemprogramme 26 auf,
die sich teils im Festwertspeicher 20 und teils im nicht-flüchtigen überschreibbaren
Speicher 22 befinden sowie auf Daten im Arbeitsspeicher 24 zugreifen.
Die Systemprogramme 26 bilden ein Betriebssystem 28,
eine Laufzeitumgebung 30 und einen Satz von Hilfsprogrammen 32.
Das Betriebssystem 28 stellt hardwarenahe Funktionen bereit,
die von der Laufzeitumgebung 30 und den Hilfsprogrammen 32 genutzt
werden. Die Laufzeitumgebung 30 weist eine virtuelle Maschine 34 auf,
die im vorliegenden Ausführungsbeispiel als JCVM (Java
Card Virtual Machine) ausgestaltet ist. Ferner ist als Teil der
Laufzeitumgebung 30 eine Klassenbibliothek 36 vorgesehen,
die Anwendungsprogrammierschnittstellen bereitstellt.
-
In
den Systemprogrammen 26 sind ein Ladeprogramm 38 (Installer)
und eine Patchroutine 40 enthalten, deren Arbeitsweise
später noch genau beschrieben wird. In dem Ausführungsbeispiel
gemäß 1 ist die Patchroutine 40 Bestandteil
der Klassenbibliothek 36, während das Ladeprogramm 38 als eines
der Hilfsprogramme 32 ausgestaltet ist. In Ausführungsalternativen
können das Ladeprogramm 38 und/oder die Patchroutine 40 in
anderen Gliederungseinheiten der Systemprogramme 26 enthalten sein.
-
Bis
auf die Patchroutine 40 sind sämtliche Systemprogramme 26 übliche
Komponenten eines Java-Card-Moduls. Die Patchroutine 40 kann
schon bei der Herstellung des Smartcard-Moduls 10 vorgesehen
sein. Es sind jedoch auch Ausgestaltungen möglich, bei
denen die Patchroutine 40 erst zu einem späteren
Zeitpunkt – z. B. bei der Komplettierung oder Initialisierung
des Smartcard-Moduls 10 – in den nicht-flüchtigen überschreibbaren
Speicher 22 eingebracht wird. Hierzu kann beispielsweise
eine Patchfunktion nach dem Stand der Technik verwendet werden.
Derartige Ausgestaltungen haben den Vorteil, daß die erfindungsgemäße
Patch-Funktionalität in einem völlig üblichen
Java-Card-Modul implementiert werden kann.
-
Das
Smartcard-Modul 10 ist dazu eingerichtet, mehrere Applikationen – in 1 ist
beispielhaft nur eine Applikation 42 gezeigt – im
nicht-flüchtigen überschreibbaren Speicher 22 aufzunehmen.
Im vorliegenden Ausführungsbeispiel ist jede Applikation 42 als
Java Card Applet ausgebildet und aus der Klasse javacardframework.Applet
abgeleitet. Jede Applikation 42 weist mehrere Methoden
auf, die in 1 durch horizontale Unterteilungen
angedeutet sind. Insbesondere sind in jeder Applikation 42 eine Installationsroutine 44 und
eine Verarbeitungsroutine 46 enthalten.
-
Die
Installationsroutine 44 ist im vorliegenden Ausführungsbeispiel
eine Methode mit dem Namen "install", die gemäß dem
Java-Card-Standard nach dem Laden der Applikation 42 aufgerufen
wird, um eine Instanz der Applikation 42 zu erzeugen und bei
der Laufzeitumgebung zu registrieren. Die als Methode mit dem Namen
"process" ausgestaltete Verarbeitungsroutine 46 interpretiert
und bearbeitet eingehende Kommando-APDUs (APDU = Application Protocol
Data Unit), die an die Applikation 42 gerichtet sind. In
der Regel weist die Applikation 42 weitere Routinen – z.
B. Methoden mit den Namen "select" und "deselect" – auf,
die hier jedoch nicht weiter von Belang sind.
-
Das
Ladeprogramm 38 (Installer) dient zum Laden weiterer Applikationen
in das Smartcard-Modul 10. In den vorliegenden Ausführungsbeispielen ist
das Ladeprogramm 38 ein an sich bekannter Installer gemäß dem
Java-Card-Standard, wie er z. B. in dem eingangs erwähnten
Dokument "Runtime Environment Specification Java CardTM Platform,
Version 2.2.2" beschrieben ist. Gegenüber seiner Umgebung
verhält sich das Ladeprogramm 38 wie eine vom
Smartcard-Modul 10 ausgeführte Applikation, auch
wenn es in der Wortwahl des vorliegenden Dokuments Teil der Systemprogramme 26 ist.
-
Das
Ladeprogramm 38 erhält eine in das Smartcard-Modul 10 zu
ladende Applikation in Form eines Programmpakets 48 im
CAP-Format (CAP = Converted Applet). Zum Laden der Applikation wird zunächst
das Ladeprogramm 38 selektiert. Werden – wie verbreitet üblich – Kommandos
gemäß der GP (Global Platform) Spezifikation genutzt,
erfolgt der Ladevorgang dann durch die Kommando-APDU "INSTALL FOR
LOAD", gefolgt von einer oder mehrerer Kommando-APDUs "LOAD". Nachdem
das neue Programmpaket 48 erfolgreich in den nicht-flüchtigen überschreibbaren
Speicher 22 geladen wurde, wird es mittels der Kommando-APDU
"INSTALL FOR INSTALL" installiert. Hierbei wird unter anderem die
Installationsroutine – im vorliegenden Ausführungsbeispiel
die "install"-Methode – der neuen Applikation ausgeführt.
Bei Zugrundelegung eines anderen Standards können an Stelle
der genannten GP-konformen Kommandos auch anders aussehende Kommandos
treten, die aber diegleiche Funktion haben.
-
Der
gerade kurz umrissene Vorgang zum Nachladen von Applikationen in
das Smartcard-Modul 10 ist als solcher aus dem Java-Card-Standard bekannt.
In den hier beschriebenen Ausführungsbeispielen wird dieser
Ladevorgang jedoch genutzt, um einen Patch – also einen
"Flicken" für ein bereits im Smartcard-Modul 10 befindliches
System- oder Anwendungsprogramm – in das Smartcard-Modul 10 zu laden
und dort zu installieren. Hierzu ist erfindungsgemäß die
Verwendung einer Pseudo-Applikation 50 vorgesehen.
-
Die
in 2 gezeigte Pseudo-Applikation 50 entspricht
in ihrer Struktur einer regulären Applikation 42.
Insbesondere weist die Pseudo-Applikation 50 eine als "install"-Methode
ausgestaltete Installationsroutine 52 und eine als "process"-Methode
ausgestaltete Verarbeitungsroutine 54 auf. Ferner sind
in der Pseudo-Applikation 50 Patchdaten 56 enthalten, die
im vorliegenden Ausführungsbeispiel in eine Signatur 58,
einen Identifikator 60 und den eigentlichen Patch 62 gegliedert
sind. Der Patch 62 liegt zweckmäßig in
verschlüsselter Form vor. Vorzugsweise erfolgt die Verschlüsselung
unter Verwendung eines symmetrischen Verfahrens. Die zur Entschlüsselung eines
Patches 62 benötigten Schlüssel können
dann vorab zusammen mit der Patchroutine 40 zweckmäßig
in den nicht-flüchtigen Speicher 22 eingebracht werden.
Die Signatur 58 deckt sowohl den Identifikator 60 als
auch den Patch 62 ab und stellt eine Sicherung gegen unerlaubte
Manipulationen dar. Ohne weiteres können statt einer einzelnen
Signatur 58 auch mehrere Signaturen vorgesehen sein, die
z. B. verschiedenen Nutzern der Systemprogramme 26 oder
der Laufzeitumgebung 30 zugeordnet sein können.
-
Im
Unterschied zu einer regulären Applikation 42 ist
die Pseudo-Applikation 50 nicht zur Verarbeitung von Kommando-APDUs
eingerichtet. Die Verarbeitungsroutine 54 der Pseudo-Applikation 50 ist
daher nur der Form nach vorhanden und besteht lediglich aus einem
Befehl, der eine Ausnahmebehandlung auslöst. Dieser Befehl
kann beispielsweise wie folgt lauten:
ISOException.throwIt(ISO7816.SW_FUNC_NOT_SUPPORTED);
-
Die
Installationsroutine 52 führt die eigentliche
Aufgabe der Pseudo-Applikation 50 aus. Diese Aufgabe besteht
im vorliegenden Ausführungsbeispiel darin, daß die
Installationsroutine 52, sobald sie im Zuge des Ladens
der Pseudo-Applikation 50 in das Smartcard-Modul 10 aufgerufen
wird, ihrer seits die Patchroutine 40 aufruft und ihr die
Patchdaten 56 – beziehungsweise einen Verweis
auf die Patchdaten 56 – übergibt. Dieser
Vorgang ist in 2 durch die gestrichelten Pfeile
angedeutet.
-
Die
Patchroutine 40 verifiziert daraufhin die Patchdaten 56.
Hierbei stellt sie mittels geeigneter Verfahren sicher, daß die
Patchdaten 56 in Ordnung und alle Voraussetzungen für
die Installation des Patches 62 erfüllt sind.
Insbesondere überprüft die Patchroutine 40 die
Korrektheit der Signatur 58 und die Gültigkeit
des Identifikators 60 und entschlüsselt den Patch 62,
wenn dieser verschlüsselt vorliegt. Falls Überprüfungen
und Entschlüsselung erfolgreich verlaufen, installiert
die Patchroutine 40 den Patch 62 in dem nicht-flüchtigen
Speicher 22 des Smartcard-Moduls 10. Dies ist
in 2 durch den gepunkteten Pfeil dargestellt. Der
Speicherbereich, in dem der Patch 62 installiert werden
soll, kann beispielsweise in dem Identifikator 60 oder
im Patch 62 oder in anderen – in 2 nicht
gezeigten – Komponenten der Patchdaten 56 angegeben
sein.
-
Die
gerade beschriebene Aufteilung der Funktionen zwischen der Installationsroutine 52 und der
Patchroutine 40 stellt sicher, daß das sicherheitskritische
Einspielen des Patch 62 in das Smartcard-Modul 10 nur
nach einer erfolgreichen Verifikation durch die Patchroutine 40 erfolgt.
Es versteht sich, daß die mit dem Einspielen des Patch 62 zusammenhängenden
Schritte in Ausführungsalternativen anders zwischen der
Installationsroutine 52 und der Patchroutine 40 – sowie
gegebenenfalls weiteren Routinen – aufgeteilt werden können.
Die Verwendung einer in den Systemprogrammen 26 enthaltenen
Patchroutine 40 ist in der Regel erforderlich, um den Patch 62 außerhalb
der Pseudo-Applikation 50 – insbesondere in den
Systemprogrammen 26 oder in manchen Ausgestaltungen auch
in anderen Applikationen – installieren zu können.
-
3 stellt
die gerade kurz beschriebenen Schritte des Installieren des Patch 62 im
Smartcard-Modul 10 ausführlicher dar. Der Ablauf
wird in Schritt 70 dadurch ausgelöst, daß das
Ladeprogramm 38 die Kommando-APDU "INSTALL FOR LOAD" erhält.
Das Programmpaket 48 mit der Pseudo-Applikation 50 wird
daraufhin mit einem oder mehreren "LOAD"-Kommandos in das Smartcard-Modul 10 übertragen.
Hierbei wird die Pseudo-Applikation 50 im nichtflüchtigen überschreibbaren
Speicher 22 angelegt.
-
Im
folgenden Schritt 72 erhält das Ladeprogramm 38 die
Kommando-APDU "INSTALL FOR LOAD". Das Ladeprogramm 38 bearbeitet
diese Kommando-APDU und ruft dabei die Installationsroutine 52 – also
die "install"-Methode der Pseudo-Applikation 50 – auf.
Die Installationsroutine 52 ruft ihrerseits in Schritt 74 die
Patchroutine 40 auf und teilt dieser den Patch 62 mit,
indem die Installationsroutine 52 einen Verweis auf die
Patchdaten 56 an die Patchroutine 40 übergibt.
-
Die
Installationsroutine 52 der Pseudo-Applikation 50 braucht
die bei regulären Applikationen übliche Registrierung
(Aufruf der Methode Applet.register) nicht auszuführen.
Im Gegensatz zu regulären Applikationen braucht die Pseudo-Applikation 50 nämlich
nicht selektierbar zu sein, und ein Eintrag der Pseudo-Applikation 50 in
die Registrierungsdatei (Registry) der Systemprogramme 26 ist
daher nicht erforderlich.
-
Nach
ihrem Aufruf prüft die Patchroutine 40 zunächst
in Schritt 76 die Korrektheit der Signatur 58 bzw.
Signaturen. Hierbei werden sowohl der Identifikator 60 als
auch der eigentliche Patch 62 verifiziert. Sofern er verschlüsselt
vorliegt, wird der Patch 62 dazu zunächst entschlüsselt.
Wenn die Signaturprüfung in Schritt 76 erfolgreich
war, überprüft die Patchroutine 40 in
Schritt 78 den Identifikator 60. Der Identifikator 60 enthält
zweckmäßig eine auch als Patchlevel bezeichnete
laufende Nummer aller Patches für das Smartcard-Modul 10.
In Schritt 78 wird dann geprüft, ob die laufende Nummer
des gerade zur Installation vorgesehenen Patch 62 eine
zulässige Nummer im Hinblick auf die Reihe der Nummern der
bereits vorhandenen Patches ist; in einfachster Ausführung
kann z. B. geprüft werden, ob die laufende Nummer gleich
der nächst höheren Nummer des letzen im Smartcard-Modul 10 installierten
Patch ist. Ist die Nummer zulässig, liegt z. B. eine lückenlose Kette
von Patches vor, kann der aktuelle Patch 62 installiert
werden. Schlägt einer der beiden Prüfschritte 76 und 78 fehl,
wird der Vorgang abgebrochen.
-
Installation
und Aktivierung des Patch 62 erfolgen in Schritt 80.
Hierzu kann ein an sich bekanntes Verfahren eingesetzt werden. In
vielen Ausführungsformen weist das Smartcard-Modul 10 einen gesonderten
Patchbereich im nicht-flüchtigen überschreibbaren
Speicher 22 auf, in den der Patch 62 eingeschrieben
und durch geeignetes Setzen von Sprungzielen aktiviert wird. Es
können jedoch auch andere Techniken zum Ausführen
des eigentlichen Patch-Vorgangs eingesetzt werden.
-
Nach
einer erfolgreichen Installation des Patch in Schritt 80 wird
in einem optionalen Schritt 82 die Pseudo-Applikation 50 gelöscht
und somit der von der Pseudo-Applikation 50 belegte Speicherplatz freigegeben.
Hierzu wird das gemäß dem Java-Card-Standard vorgesehene
Löschprogramm (Applet Deletion Manager) eingesetzt. Es
sind jedoch auch Ausgestaltungen vorgesehen, bei denen die Pseudo-Applikation 50 nicht
gelöscht wird.
-
Die
erfolgreiche Installation des Patch 62 kann nun an das
Hintergrundsystem in einer Antwort-APDU zurückgemeldet
werden.
-
Es
versteht sich, daß die hier beschriebenen Ausführungsformen
und Ausführungsvarianten lediglich als Beispiele zu sehen
sind. Weitere Abwandlungen und Kombinationen der hier beschriebenen Merkmale
sind für den Fachmann unmittelbar ersichtlich.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-