Installieren eines Patch in einem Smartcard-Modul

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 Mobil telefons 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 Card™ 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™ 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 Telekommunikations- 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 Merk- malen 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 Funk- tionen 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 αir) 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 haupt- sächlich Smartcard-Module nach dem /cuα-Cαrd-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:

Fig. 1 ein Blockdiagramm mit Funktionseinheiten eines Smartcard-Moduls nach einem Ausführungsbeispiel der Erfindung,

Fig. 2 eine Darstellung der Systemprogramme und der Pseudo- Applikation im Speicher des Smartcard-Moduls nach Fig. 1 bei der Installation des Patch, und

Fig. 3 ein Ablaufdiagramm eines Verfahrens zur Installation eines Patch in dem Smartcard-Modul nach Fig. 1.

Das in Fig. 1 dargestellte Smartcard-Modul 10 ist im vorliegenden Ausführungsbeispiel als Chipmodul zum Einlöten in ein Host-Gerät - z.B. ein Mobil telefon - 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 Kom- munikation 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 beschrie- ben wird. In dem Ausführungsbeispiel gemäß Fig. 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 Fig. 1 ist beispielhaft nur eine Applikation 42 gezeigt - im nicht-flüchtigen überschreibbaren Speicher 22 aufzunehmen. Im vorliegenden Ausführungs- beispiel ist jede Applikation 42 als Java Card Applet ausgebildet und aus der Klasse javacard.frameiυork.Applet abgeleitet. Jede Applikation 42 weist mehrere Methoden auf, die in Fig. 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 Card™ 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 "instaW-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 /αuα-Cαrd-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 Fig. 2 gezeigte Pseudo- Applikation 50 entspricht in ihrer Struktur einer regulären Applikation 42. Insbesondere weist die Pseudo- Applikation 50 eine als "instaZ/"-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 Fig. 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 Fig. 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 Fig. 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 sicherheits- kritische 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.

Fig. 3 stellt die gerade kurz beschriebenen Schritte des Installierens 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-App- likation 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 "zns£α//"-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 Patch- routine 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 Smart- card-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 Abwand- lungen und Kombinationen der hier beschriebenen Merkmale sind für den Fachmann unmittelbar ersichtlich.