-
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.
-
Die
vorliegend betrachteten Ausgestaltungen von Smartcard-Modulen weisen
Systemprogramme auf, die eine objektorientierte Laufzeitumgebung
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 von Java-Card-Modulen. Auf
dieses Dokument wird hiermit Bezug genommen.
-
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.
-
Bei
Java-Card-Modulen ist es prinzipiell denkbar, ein bestehendes – fehlerhaftes – Programmpaket (package)
zu löschen und eine korrigierte Fassung des Programmpakets
neu zu laden. Dies ist jedoch nur möglich, wenn noch keine
Objekte angelegt wurden und noch kein anderes Programmpaket auf
das zu korrigierende Programmpaket gelinkt wurde. Diese Voraussetzungen
sind sehr einschränkend und verhindern in den meisten Fällen
das Patchen eines Smartcard-Moduls, das gerade personalisiert wird
oder sich bereits beim Endverbraucher befindet.
-
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 – ausgeführten
Programms. Beim Einspielen eines Patch wird mindestens ein Eintrag
in einer Methodentabelle des Programms geändert, so dass
der geänderte Eintrag auf einen durch den Patch bereitgestellten
Methoden kö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 bereitzustellen, die umfassend einsetzbar
ist, also insbesondere auch dann, wenn sich das Smartcard-Modul
bereits in den letzten Stufen der Herstellung oder sogar schon beim
Endverbraucher befindet. Es ist ferner eine Aufgabe mancher Ausführungsformen
der Erfindung, bereits im Smartcard-Modul vorhandene Daten möglichst
weitgehend über den Patchvorgang hinweg zu erhalten.
-
Erfindungsgemäß wird
diese Aufgabe durch ein Verfahren mit den Merkmalen des Anspruchs
1, ein Verfahren mit den Merkmalen des Anspruchs 6, einen maschinenlesbaren
Datenträger gemäß Anspruch 15 und ein
Smartcard-Modul gemäß Anspruch 16 gelöst.
Die abhängigen Ansprüche betreffen optionale Merkmale
einiger Ausgestaltungen der Erfindung.
-
Ein
erster Aspekt der Erfindung geht von der Grundidee aus, den Patch
in die Klassenhierarchie als Subklasse der gepatchten Klasse einzufügen.
Hierdurch kann der bei objektorientierten Laufzeitumgebungen vorhandene
Polymorphie-Mechanismus in natürlicher Weise verwendet
werden, um den im Patch vorhandenen Programmcode korrekt in die
Aufrufordnung der Klassen des Programmpakets einzubinden. In manchen Ausgestaltungen
wird der Patch ähnlich wie beim dynamischen Nachladen einer
Klasse im Speicher des Smartcard-Moduls angelegt.
-
In
manchen Ausführungsformen wird der Patch ferner in die
Klassenhierarchie als Superklasse jeder ursprünglichen
Subklasse der gepatchten Klasse eingefügt. Diese Maßnahme
stellt sicher, dass Elemente (z. B. Methoden oder Felder) des Patch
von abgeleiteten Klassen im selben Programmpaket korrekt angesprochen
werden. Um den Patch auch für externe abgeleitete Klassen
(also Subklassen der gepatchten Klasse, die sich in einem anderen
Programmpaket befinden) bereitzustellen, wird in manchen Ausgestaltungen
ferner für mindestens ein vom Patch überschriebenes
Element (z. B. eine Methode oder ein Feld) der gepatchten Klasse
der Patch in eine Exportkomponente eingetragen.
-
Gemäß einem
zweiten Aspekt der Erfindung wird mindestens eine Instanzfeldstruktur
der gepatchten Klasse und/oder einer Subklasse davon an den Patch
angepasst. Dies hat den erheblichen Vorteil, dass bereits im Smartcard-Modul
enthaltene Daten (z. B. persönliche Daten des Benutzers,
die beider Personalisierung in das Smartcard-Modul eingetragen wurden)
weitgehend oder vollständig erhalten werden können.
Das Anpassen der Instanzfeldstruktur kann in manchen Ausführungsformen
z. B. beinhalten, dass ein Feld angehängt oder eingefügt
wird und/oder dass der Typ eines Feldes geändert wird.
-
In
vielen Ausgestaltungen werden Maßnahmen getroffen, um ein
nicht autorisiertes Patchen des Smartcard-Datenträgers,
das erhebliche Schäden verursachen könnte, zu
verhindern. Beispielsweise kann vorgesehen sein, dass die zu patchende
Klasse oder eine Superklasse bestimmt oder zumindest beeinflusst, ob
der Patch installiert werden darf. Hierdurch können die
Authentisierungsanforderungen klassenindividuell festgelegt werden,
und der bei objektorientierten Laufzeitumgebungen vorhandene Vererbungsmechanismus kann
in vorteilhafter Weise verwendet werden, um die Zulässigkeit
des Patchvorgangs zu bestimmen.
-
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.
-
Der
erfindungsgemäße maschinenlesbare Datenträger
kann als körperliches Medium – z. B. als Diskette
oder CD-ROM oder Halbleiterspeicher – oder als nicht-körperliches
Medium – z. B. als über ein Computernetzwerk übermitteltes
Signal – ausgestaltet sein. Der Datenträger kann
beispielsweise bei der Herstellung und/oder Komplettierung und/oder
Initialisierung des Smartcard-Moduls verwendet werden, um eine Patchroutine
mit der erfindungsgemäßen Funktionalität
in das Smartcard-Modul einzubringen.
-
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 von Teilen des Speicherinhalts des Smartcard-Moduls
vor dem Installieren eines Patch,
-
3 eine
Darstellung wie in 2 nach dem Installieren des
Patch,
-
4 ein
Flussdiagramm eines Verfahrens zum Installieren des Patch,
-
5 ein
Flussdiagramm eines dem Verfahren von 4 vorgeschalteten
Verfahrens zur Autorisierungsprüfung, und
-
6 eine
beispielhafte Darstellung der Anpassung einer Instanzfeldstruktur
durch Einfügen eines zusätzlichen Feldes.
-
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. In Ausführungsalternativen
ist das Smartcard-Modul 10 dagegen als übliche
Chipkarte oder als übliches Chipmodul mit nur einer Schnittstelle
zur leitungsgebundenen oder drahtlosen Kommunikation mit einem externen
Terminal ausgestaltet.
-
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 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 umfassen ein hardwarenahes Betriebssystem 28 und
eine objektorientierte Laufzeitumgebung 30. Die Laufzeitumgebung 30 weist
eine virtuelle Maschine 32 auf, die im vorliegenden Ausführungsbeispiel
als JCVM (Java Card Virtual Machine) ausgestaltet ist. Ferner ist
als Teil der Laufzeitumgebung 30 eine Klassenbibliothek 34 vorgesehen,
die Anwendungsprogrammierschnittstellen und Hilfsprogramme bereitstellt.
Insbesondere weist die Laufzeitumgebung 30 – im
vorliegenden Ausführungsbeispiel die Klassenbibliothek 34 – eine
Patchroutine 36 auf, die die im folgenden noch genau beschriebenen
Patchfunktionen steuert.
-
In 1 ist
ein in dem Smartcard-Modul 10 installiertes Programmpaket 38 veranschaulicht,
das beispielsweise eine vom Smartcard-Modul 10 ausgeführte
Applikation (Applet) bildet. Es versteht sich, dass zusätzliche,
in 1 nicht gezeigte Programmpakete vorhanden sein
können. Das Programmpaket 38 weist eine Mehrzahl
von Klassen auf, von denen in 1 beispielhaft
drei Klassen A, B, C dargestellt sind. Die Klassen A, B, C bilden
eine Klassenhierarchie. In dieser Klassenhierarchie ist die Klasse
A die unmittelbare Superklasse der Klasse B, und die Klasse C ist
eine unmittelbare Subklasse der Klasse B. Dies ist durch Verweise 40, 42 veranschaulicht,
die zu jeder Klasse deren Superklasse bezeichnen.
-
Im
nicht-flüchtigen überschreibbaren Speicher 22 sind
Klassenfeldstrukturen 44 und Instanzfeldstrukturen 46 angelegt,
die in 1 lediglich schematisch gezeigt sind. Jede Klassenfeldstruktur 44 enthält
die Felder der Klassenvariablen je einer Klasse. Jede Instanzfeldstruktur 56 ist
je einer Klasseninstanz – also je einem Objekt – zugeordnet
und enthält die Felder der Instanzvariablen dieses Objekts.
-
In
dem hier beschriebenen Ausführungsbeispiel befinden sich
sowohl die Klassenfeldstrukturen 44 als auch die Instanzfeldstrukturen 46 in
einem Heap (Haldenspeicher) 48, der in einem Bereich des
nicht-flüchtigen überschreibbaren Speichers 22 angelegt
ist. Es sind jedoch auch Ausführungsformen vorgesehen,
bei denen die Klassenfeldstrukturen 44 als statische Datenstrukturen
außerhalb des Heap 48 angelegt werden.
-
1 zeigt
ferner ein Patchpaket 50, das über die Host-Schnittstelle 16 in
das Smartcard-Modul 10 eingelesen wird. Das Patchpaket 50 enthält
einen oder mehrere Patches P. Jedem Patch P kann optional je eine
Anpassungsbeschrei bung 52 zugeordnet sein, die angibt,
auf welche Weise durch den Patch P betroffene Instanzfeldstrukturen 46 beim
Installieren des Patches P geändert werden müssen.
Beispielsweise kann das Patchpaket 50 ähnlich
wie eine CAP-Datei (CAP = Converted Applet) aufgebaut sein, wobei
eventuell vorhandene Anpassungsbeschreibungen 52 in einer
zusätzlichen Komponente enthalten sind. Die diversen in
einer solchen CAP-Datei enthaltenen Datenkomponenten sind also solche
gut bekannt und daher in 1 nicht gezeigt.
-
Das
Patchpaket
50 wird im vorliegenden Ausführungsbeispiel
durch die bei Java-Card-Modulen üblichen Mechanismen wie
ein Programmpaket (Package) in das Smartcard-Modul
10 geladen.
Bei der Installation des Patchpakets
50 als "Pseudo-Applikation"
wird jedoch die Patchroutine
36 ausgeführt, die
den Patch P auf die im folgenden beschriebene Weise in die Programmausführungsumgebung
des Smartcard-Moduls
10 einbindet. Das Laden eines Patchpakets
als "Pseudo-Applikation" ist bereits in der
deutschen Patentanmeldung 10 2007 003
580.4 der Giesecke & Devrient
GmbH, eingereicht am 24. Januar 2007, beschrieben.
-
2 und 3 zeigen
jeweils Datenstrukturen im nicht-flüchtigen überschreibbaren
Speicher 22 des Smartcard-Moduls 10 vor bzw. nach
der Installation des Patch P durch die Patchroutine 36.
Die Schritte, die von der Patchroutine 36 zur Installation
des Patch P für die Klasse B als zu patchende Klasse ausgeführt
werden, sind in 4 dargestellt. Mit anderen Worten
ist 3 das Ergebnis, wenn das Verfahren gemäß 4 auf
Speicherstrukturen gemäß 2 angewendet
wird.
-
Der
in 2 gezeigte ursprüngliche Speicherinhalt
entspricht der Darstellung von 1 mit den
drei Klassen A, B, C, deren Klassenhierarchie durch die Verweise 40, 42 auf
die jeweilige Superklasse angegeben ist. Jeder Verweis 40, 42 ist
in einer Klassenkomponente CLASS der entsprechenden Methode B, C
enthalten. In an sich bekannter Weise enthalten die Klassen komponenten
CLASS weitere Informationen, beispielsweise eine Tabelle mit Verweisen
auf Bytecode für die implementierten Methoden und eine
Tabelle der in der Klasse definierten Interfaces. Ein solches Interface 54 mit
dem Namen "patchable" ist in der Klassenkomponente der Klasse B
gezeigt.
-
Die
Klassen A, B, C weisen ferner Bytecode der von ihnen implementierten
Methoden auf. 2 zeigt beispielhaft eine Implementierung
der Methode "authorize", deren Bedeutung später noch beschrieben
werden wird.
-
Das
Programmpaket 38 (1) mit den
Klassen A, B, C weist ferner eine Exportkomponente 58 (2)
auf, die Verweise auf alle exportierten Elemente (Klassen, Methoden
und Felder) des Programmpakets 38 enthält. 2 zeigt
beispielhaft einen solchen Verweis 60, der ein von der
Klasse B exportiertes Element betrifft und daher auf die Klasse
B gerichtet ist. Die Darstellung in 2 ist hier
lediglich symbolisch zu verstehen. In einer realen Implementierung
würde sich die Information des Verweises 60 in
einer Konstantenpool-Komponente des Programmpakets 38 befinden.
Aus Gründen der Übersichtlichkeit werden diese
und andere Einzelheiten hier jedoch nicht im Detail beschrieben
und gezeigt, weil sie im Zusammenhang mit Java-Card-Umgebungen gut
bekannt sind.
-
Vor
dem Patchvorgang weist der Heap 48 den in 2 beispielhaft
gezeigten Speicherinhalt auf. Eine Klassenfeldstruktur 44B enthält
Felder für die Klassenvariablen von Klasse B, und eine
Klassenfeldstruktur 44C enthält ein Feld für
eine Klassenvariable der abgeleiteten Klasse C. Bidirektionale Verweise 62B, 62C – zusammenfassend
als Verweise 62 bezeichnet – erlauben es, von
der Klasse B, C auf die zugehörige Klassenfeldstruktur 44B, 44C zuzugreifen
und umgekehrt.
-
In
der Darstellung von 2 wird angenommen, dass zwei
Instanzen der Klasse B und eine Instanz der Klasse C existieren.
Entsprechende Instanz feldstrukturen 46B.1, 46B.2 und 46C.1 für
die Felder dieser Instanzen sind in 2 gezeigt.
Da die Klasse C von der Klasse B abgeleitet ist, weist die Instanzfeldstruktur 46C.1 dasselbe
erste Feld wie die Instanzfeldstrukturen 46B.1, 46B.2 auf,
das in 2 durch eine schräge Schraffur gekennzeichnet
ist. Ferner enthält die Instanzfeldstruktur 46C.1 ein
weiteres, in 2 senkrecht schraffiertes Feld
für eine zusätzliche Instanzvariable der Klasse
C. Verweise 64B.1, 64B.2 und 64C.1 – zusammenfassend
als Verweise 64 bezeichnet – erlauben es, von
den Instanzfeldstrukturen 46B.1, 46B.2 und 46C.1 auf
die zugeordneten Klassen B und C zuzugreifen.
-
Das
in 4 gezeigte Verfahren zur Installation des Patch
P, der die Klasse B als zu patchende Klasse betrifft, beginnt in
Schritt S1 mit dem Anlegen geeigneter Speicherstrukturen. Insbesondere
sind dies die Speicherstrukturen für die diversen Komponenten
des Patch P sowie, falls der Patch P mindestens eine Klassenvariable
enthält, eine entsprechende Klassenfeldstruktur 44P (gezeigt
in 3).
-
Der
Patch P ist im wesentlichen wie eine Klasse aufgebaut und weist
daher auch dieselben Komponenten wie eine Klasse auf. Unter anderem
sind dies eine Klassenkomponente CLASS, Bytecode für die
vom Patch P implementierten Methoden, ein Konstantenpool, und so
weiter. Das Anlegen der Speicherstrukturen in Schritt S1 (4)
entspricht damit ungefähr dem dynamischen Nachladen einer
Klasse, so dass die an sich bekannten Funktionen der Laufzeitumgebung 30 ohne
oder mit geringfügigen Änderungen verwendet werden können.
Im Unterschied zu einer vollständigen Klasse implementiert
der Patch jedoch nicht alle Methoden der zu patchenden Klasse, sondern
nur diejenigen Methoden, die in der zu patchenden Klasse fehlerhaft
sind oder aus sonstigen Gründen verändert werden
sollen.
-
In
Schritt S2 wird der Patch P nun in die Klassenhierarchie als Subklasse
der zu patchenden Klasse – hier B – eingefügt.
Hierzu wird ein Verweis 66 auf die Klasse B in die Klassenkomponente
CLASS des Patch P eingetragen und somit die Klasse B als Superklasse
des Patch P definiert. Dieser Schritt kann auch mit Schritt S1 kombiniert
werden.
-
Abgeleitete
Klassen der gepatchten Klasse sollen nur dann eine Methode der gepatchten
Klasse aufrufen, wenn diese Methode nicht durch den Patch P ersetzt
wurde. Für Klassen, die von der gepatchten Klasse intern
abgeleitet sind – also Klassen, deren Superklasse die gepatchte
Klasse ist und die sich im selben Programmpaket 38 wie
die gepatchte Klasse befinden – wird dies dadurch erzielt,
dass der Patch P als Superklasse dieser abgeleiteten Klassen eingetragen
wird. Dies geschieht in den Schritten S3 und S4. Die abgeleiteten Klassen
können in Schritt S3 beispielsweise durch Überprüfen
ihrer Superklassen-Verweise (Bytecodes "instance_of" bzw. "checkcast")
identifiziert werden.
-
Im
vorliegenden Beispiel ist die Klasse C die einzige intern abgeleitete
Klasse, und deren Verweis 42 wird in Schritt S4 auf den
Patch P gerichtet, um P als Superklasse von C zu definieren.
-
Insgesamt
ist durch die Schritte S2, S3 und S4 der Patch P in die Klassenhierarchie
"zwischen" die gepatchte Klasse B und deren ursprüngliche
Subklassen – hier C – eingebunden worden. Dies
ermöglicht es, die von der Java-Card-Umgebung bereitgestellte
Polymorphie zu nutzen, um die im Patch P enthaltenen Methoden in
der gewünschten Weise in das Programmpaket 38 einzubinden.
So wird ein von der Klasse C ausgehender Methodenaufruf, der eine
in der Klasse B enthaltene und nun vom Patch P überschriebene
Methode betrifft, korrekt durch den Patch P ausgeführt.
Eine vom Patch P nicht überschriebene Methode der Klasse
B wird jedoch nach wie vor von der Implementierung der Klasse B
ausgeführt.
-
Klassen
die sich nicht im Programmpaket 38 befinden ("externe Klassen")
und die von der gepatchten Klasse B abgeleitet sind, werden von
der Java-Card-Laufzeitumgebung 30 dynamisch über
die Exportkomponente 58 des Programmpakets 38 gelinkt.
Auch in diesem Fall soll eine korrekte Einbindung des Patch P sichergestellt
werden. Hierzu werden in Schritt S5 alle Exporttoken der Exportkomponente 58,
die sich auf ein ursprünglich von der gepatchten Klasse
B bereitgestelltes und durch den Patch P ersetztes Element beziehen, so
verändert, dass sie nun auf den Patch P verweisen. Wie
bereits erwähnt, ist zur Anpassung der Exporttoken in vielen
Implementierungen des hier beschriebenen Verfahrens eine Veränderung
der Einträge in der Konstantenpool-Komponente der gepatchten
Klasse B erforderlich.
-
Die
in Schritt S5 ausgeführte Anpassung ist in 3 dadurch
veranschaulicht, dass der Verweis 60 der Exportkomponente 58 so
verändert wurde, dass er nicht mehr auf die gepatchte Klasse
B, sondern auf den Patch P zeigt. Durch diese Maßnahme
wird der Patch P auch hinsichtlich externer abgeleiteter Klassen
korrekt in die Aufrufordnung der Java-Card-Laufzeitumgebung 30 eingebunden.
-
Wenn
der Patch P keine Objekte mit eigenen Instanzvariablen deklariert,
dann ist der Installationsvorgang nun abgeschlossen, wie dies in 4 durch
einen gestrichelten Pfeil angedeutet ist. In manchen Ausgestaltungen
kann es jedoch auch in diesem Fall erforderlich sein, die Klassenverweise 64 einiger
oder aller Instanzfeldstrukturen 46, die bislang auf die
zu patchende Klasse – z. B. Klasse B – verweisen,
in Verweise auf den Patch P zu ändern. In diesen Ausgestaltungen
werden immer Schritte ähnlich den Schritten S6 und S7 ausgeführt.
-
Wenn
die Methoden des Patch P zusätzliche Felder für
Instanzvariablen benötigen und/oder für bestehende
Felder einen anderen Typ erfordern, so werden auf jeden Fall die
Schritte S6–S10 ausgeführt, in denen die bereits
im Heap 48 bestehenden Instanzfeldstrukturen 46 dem
Patch P angepasst werden. Hierdurch wird erreicht, dass bereits
vorhandene Objekte (z. B. mit personalisierten Daten) über
den Patchvorgang hinweg erhalten bleiben.
-
In
Schritt S6 werden alle Instanzfeldstrukturen 46 gesucht,
die der zu patchenden Klasse zugeordnet sind. Dies kann geschehen,
indem der Heap 48 durchsucht wird und die Verweise 64 der
Instanzfeldstrukturen 46 analysiert werden. Die Verweise 64 der
gefundenen Instanzfeldstrukturen 46 werden in Schritt S7
so verändert, dass sie sich auf den Patch P beziehen. Ferner
werden in Schritt S8 die zusätzlich benötigten
Felder in die Instanzfeldstrukturen 46 eingefügt
bzw. der Typ bestehender Felder geändert (z. B. Änderung
eines Feldes des Typs "short" in ein Feld des Typs "int"). Hierbei
wird der bisherige Feldinhalt soweit möglich erhalten und – bei
einer Typänderung – an den neuen Typ angepasst.
-
In
dem in 3 gezeigten Beispiel betreffen die Schritte S6–S8
die beiden Instanzfeldstrukturen 46B.1 und 46B.2,
deren Verweise 64B.1, 64B.2 in Schritt S7 auf
den Patch P gerichtet werden. Ferner werden in dem Beispiel von 3 die
Instanzfeldstrukturen 46B.1 und 46B.2 um je ein
zusätzliches Feld – das durch eine horizontale
Schraffur gekennzeichnet ist – erweitert.
-
Während
in dem Beispiel gemäß 3 das horizontal
schraffierte Feld lediglich an die Instanzfeldstrukturen 46B.1 und 46B.2 angehängt
wurde, ist in manchen Ausgestaltungen der Erfindung ein Mechanismus
vorgesehen, der eine weitgehende Umgestaltung der in Schritt S6
identifizierten Instanzfeldstrukturen 46 gestattet. Hierzu
wertet die Patchroutine 36 die in diesen Ausführungsformen
im Patchpaket 50 enthaltene Anpassungsbeschreibung 52 aus.
Diese Anpassungsbeschreibung 52 gibt an, auf welche Weise
die Anpassung der bestehenden Instanzfeldstrukturen 46 erfolgen
soll.
-
In
einem Ausführungsbeispiel enthält die Anpassungsbeschreibung
52 einen
Eintrag "objektfeld_anpassungsbeschreibung_1", der beispielsweise
wie folgt definiert sein kann:
-
Ein
solcher beispielhafter Eintrag gibt an, dass eine alte Instanzfeldstruktur 46 – z.
B. der Klasse B – fünf Felder hat, während
die angepasste Instanzfeldstruktur 46' – z. B.
der Klasse P – sechs Felder haben soll und das neue Feld
zwischen die früheren Felder mit den Indexwerten 2 und
3 eingefügt werden soll. 6 veranschaulicht
die Anpassung einer Instanzfeldstruktur 46 mit Feldinhalten
F0–F4 gemäß diesem Eintrag.
-
In
den weiteren Schritten S9 und S10 werden diejenigen Instanzfeldstrukturen 46 gesucht
und angepasst, die Subklassen der zu patchenden Klasse zugeordnet
sind. Die Schritte S9 und S10 werden ähnlich wie die Schritte
S5 und S8 ausgeführt; eine Änderung von Klassenverweisen 64 ist
hier nicht erforderlich. Zur Anpassung der Instanzfeldstrukturen 46 in
Schritt S10 können die gleichen Regeln und/oder Anpassungsbeschreibungen 52 wie
in Schritt S8 herangezogen werden, da jede in Schritt S10 bearbeitete
Instanzfeldstruktur 46 dieselbe anfängliche Folge
von Feldern wie jede in Schritt S8 bearbeitete Instanzfeldstruktur 46 der
zu patchenden Superklasse enthält. Die in Schritt S10 bearbeiteten
Instanzfeldstrukturen 46 können jedoch, weil sie abgeleiteten
Klassen zugeordnet sind, zusätzliche ("angehängte")
Felder aufweisen. Diese Felder müssen bei der Anpassung
in Schritt S10 erhalten bleiben.
-
In
dem in 3 gezeigten Beispiel betreffen die Schritte S9
und S10 die Instanzfeldstruktur 46C.1, die der abgeleiteten
Klasse C zugeordnet ist. In diese Instanzfeldstruktur 46C.1 wird
das zusätzliche vom Patch P benötigte Feld (in 3 horizontal
schraffiert) eingefügt, und zwar vor das (in 3 vertikal
schraffierte) Feld für die zusätzliche Instanzvariable
der Klasse C.
-
In
Ausführungsvarianten der gerade beschriebenen Schritte
werden die bestehenden Instanzfeldstrukturen 46 nicht verändert
(oder zumindest werden keine Felder zwischen bestehende Felder eingefügt),
so dass auch auf die Anpassungsbeschreibung 52 verzichtet
werden kann. Felder, die vom Patch P gegebenenfalls zusätzlich
benötigt werden, werden in diesen Ausführungsvarianten
in einem gesonderten Patchfeld angelegt, das sich beispielsweise
am Ende jeder Instanzfeldstruktur 46 oder davon getrennt
im Heap 48 befinden kann. Die Laufzeitumgebung 30 hat
dann die Aufgabe, Zugriffe auf solche Felder geeignet auf die jeweiligen Speicherorte
zu lenken.
-
Es
versteht sich, dass die Aufteilung der Schritte S6–S8 und
S9–S10 in 4 lediglich aus Gründen der
klareren Darstellung gewählt wurde. In einer Implementierung
können insbesondere die Schritte S6 und S9 kombiniert werden,
so dass der gesamte Heap 48 nach Instanzfeldstrukturen 46 durchsucht
wird und für jede gefundene Struktur je nach dem Ziel ihres
Verweises 64 entweder die Schritte S7 und S8 oder der Schritt 10 oder
kein weiterer Verarbeitungsvorgang ausgeführt wird (letzteres
dann, wenn die Instanzfeldstruktur 46 weder der gepatchten
Klasse noch einer davon abgeleiteten Klasse zugeordnet ist).
-
Ferner
versteht sich, dass in möglichen Implementierungen die
in 4 gezeigten Schritte in unterschiedlicher, gegebenenfalls
von 4 abweichen der Reihenfolge und/oder ineinander
verzahnt (interleaved) ausgeführt werden können.
Die Installation des Patch P erfolgt jedoch in den hier beschriebenen
Ausführungsbeispielen stets als atomare Transaktion.
-
Das
hier beschriebene Verfahren gestattet die Installation des Patch
P in einer ungesicherten Umgebung, also beispielsweise, wenn sich
das Smartcard-Modul 10 bereits beim Endbenutzer befindet.
Da ein fehlerhafter oder böswillig programmierter Patch
P hohen Schaden anrichten kann, ist es in den hier beschriebenen
Ausführungsbeispielen wichtig, jede unautorisierte Installation
sicher zu verhindern. Zu diesem Zweck können an sich bekannte
Signatur- und Authentifizierungsprüfungen eingesetzt werden,
die z. B. beim Laden des Patchpakets 50 oder vor dem Beginn
der Patchinstallation durchgeführt werden.
-
In
diesem Zusammenhang ist es ein besonderes Merkmal vieler Ausführungsformen
der Erfindung, dass die zu patchende Klasse oder eine Superklasse
davon – hier z. B. die Klassen B oder A – bestimmt
oder zumindest beeinflusst, ob die Patchinstallation zugelassen
wird. Auf diese Weise können unterschiedliche Sicherheitsanforderungen
unproblematisch berücksichtigt werden. Beispielsweise kann
eine Klasse, die lediglich ein Adressbuch verwaltet, die Installation
eines Patches zulassen, während eine sicherheitskritische
Klasse, die z. B. für die Kennwortüberprüfung
zuständig ist, keine Veränderung erlaubt.
-
Im
hier beschriebenen Ausführungsbeispiel führt die
Patchroutine 36 vor dem eigentlichen, in 4 gezeigten
Patchvorgang eine Autorisierungsprüfung durch, wie sie
beispielhaft in 5 gezeigt ist. Der Ablauf startet
in Schritt T1 damit, dass die Patchroutine 36 das Patchpaket 50 überprüft
und die zu patchende Klasse und das zugehörige Programmpaket – hier
z. B. die Klasse B und das Programmpaket 38 – identifiziert.
-
In
Schritt T2 überprüft die Patchroutine
36 nun,
ob das Patchen der identifizierten Klasse grundsätzlich zulässig
ist. Hierzu wird im vorliegenden Ausführungsbeispiel ermittelt,
ob in der zu patchenden Klasse – hier B – oder
einer Superklasse davon – hier A – das Interface
"patchable" implementiert ist. Dieses Interface, das als sogenanntes
"tagging interface" verwendet wird, kann beispielsweise wie folgt
definiert sein:
-
Im
vorliegenden Beispiel ist gemäß 2 das
Interface "patchable" in der Klasse B als Interface 54 definiert,
und die Methode "authorize" ist durch den Bytecode 56 implementiert.
Das Verfahren wird daher mit Schritt T3 fortgesetzt. Andernfalls
würde das Verfahren mit einer Fehlermeldung abgebrochen
und der Patch P nicht installiert werden.
-
In
Schritt T3 wird durch einen Aufruf der Methode "authorize" bestimmt,
ob der Patch P installiert werden darf. Hierbei ist grundsätzlich
die Klasse, die das Interface "patchable" implementiert, selbst
für die Sicherheit verantwortlich. So erwartet die Methode
"authorize" im vorliegenden Beispiel die Parameter "buffer", "offset"
und "length", die auf Autorisierungsdaten des Patch P – z.
B. ein Kennwort oder eine Signatur – verweisen. Ferner
kann in manchen Ausgestaltungen vorgesehen sein, dass der Patch
P ganz oder teilweise verschlüsselt ist; in diesem Fall
muss der Code zusätzlich entschlüsselt werden.
-
Die
Funktionen zur Autorisierung des Patch P und gegebenenfalls zur
Entschlüsselung von Programmcode brauchen nicht notwendigerweise
in der Klasse der Methode "authorize" implementiert zu sein. Vielmehr
ist in manchen Ausführungsformen vorgesehen, dass die Methode
"authorize" auf Funktionen zurückgreift, die von einer
Security Domain bereitgestellt werden.
-
Im
Einklang mit dem üblichen Sprachgebrauch ist eine Security
Domain eine auf dem Smartcard-Modul 10 befindliche Applikation,
die Aufgaben der Schlüsselverwaltung übernimmt
und sonstige sicherheitskritische Dienste bereitstellt. Auch in
Ausgestaltungen, die eine Security Domain verwenden, ist jedoch
aus Sicherheitsgründen nach wie vor eine explizite Kennzeichnung
der pachbaren Klassen durch das Interfache "patchable" vorgesehen.
-
Als
Abwehrmaßnahme gegen Angriffe, bei denen der Berechnungsablauf
der Autorisierungsüberprüfung in Schritt T3 durch
externe Einwirkung gestört wird, kann die Autorisierungsüberprüfung
oder ein Teil davon mehrfach durchgeführt werden, indem
z. B. die Methode "authorize" mehrfach aufgerufen wird. Die Ergebnisse
werden dann verglichen, und die Erlaubnis zur Installation des Patch
wird nur bei positiver Übereinstimmung erteilt.
-
Wenn
in Schritt T4 festgestellt wird, dass die Autorisierung zur Installation
des Patch P erteilt wurde, wird in Schritt T5 das Installationsverfahren
gemäß 4 für die in Schritt
T1 aufgefundene Klasse B als zu patchende Klasse ausgeführt.
Andernfalls wird das Verfahren abgebrochen.
-
Es
versteht sich, dass zumindest der von der zu patchenden Klasse ausgeführte
Schritt T3 abgeschlossen sein muss, bevor der eigentliche Patchvorgang
in Schritt T5 beginnt. Mit anderen Worten darf während
des Patchvorgangs kein Thread aktiv sein, der die zu patchende Klasse
oder Objekte davon betrifft.
-
In
dem hier beschriebenen Ausführungsbeispiel reicht es aus,
wenn das Interface "patchable" in der zu patchenden Klasse oder
einer ihrer Superklassen implementiert ist. Die Eigenschaft, patchbar
zu sein, ist somit vererbbar. Der bei Java-Card-Umgebungen übliche
Vererbungsmechanismus kann in vorteilhafter Weise auch eingesetzt
werden, wenn eine abgeleitete Klasse aus Sicherheitsgründen
nicht patchbar sein soll. Diese abgeleitete Klasse braucht dann
lediglich das Interface "patchable" neu zu implementieren.
-
Es
versteht sich, dass in Abwandlungen statt eines Interface "patchable"
auch ein Interface "non-patchable" vorgesehen sein kann, das die
Patchbarkeit einer Klasse und der davon abgeleiteten Klassen ausschließt.
-
In
weiteren Ausführungsalternativen können die Klassen
eines Programmpakets 38 auf andere Weise als durch die
Implementierung eines Interface angeben, ob ein Patch zulässig
sein soll und gegebenenfalls welche Sicherheitsüberprüfungen
vorgenommen werden sollen. Die eigentliche Autorisierung wird dann
durch die Patchroutine 36 durchgeführt. Es sind
auch Ausführungsformen vorgesehen, bei denen die Autorisierungsüberprüfung
gänzlich durch die Patchroutine 36 – ohne
eine Beeinflussungsmöglichkeit durch die zu patchende Klasse – ausgeführt
wird.
-
Es
versteht sich, dass 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
-
- - US 6202208 [0007]
- - DE 102007003580 [0030]
-
Zitierte Nicht-Patentliteratur
-
- - "Runtime Environment
Specification Java CardTM Platform, Version 2.2.2", März
2006 [0003]