-
HINTERGRUND DER ERFINDUNG
-
IC-Karten
werden in zunehmendem Maße für viele
verschiedene Zwecke in der heutigen Welt eingesetzt. Eine IC-Karte
hat typischerweise die Größe einer
herkömmlichen
Kreditkarte, in der ein Computerchip eingebettet ist. Sie umfasst
einen Mikroprozessor, einen Festwertspeicher (ROM), einen elektrisch
löschbaren,
programmierbaren Festwertspeicher (EEPROM), einen Ein-/Ausgabe-(E/A)-Mechanismus sowie
andere Schaltungen zum Unterstützen des
Mikroprozessors bei seinen Operationen. Eine IC-Karte kann eine
oder mehrere Anwendungen im Speicher enthalten. MULTOSTM ist
ein Mehrfachanwendungs-Betriebssystem, das auf IC-Karten (u.a. Plattformen)
läuft und
die Ausführung
mehrerer Anwendungen auf der Karte selbst zulässt. So kann ein Kartenbenutzer
viele in der Karte gespeicherte Programme (z.B. Kredit/Debit, elektronische(s) Geld/Geldbörse und/oder
Kundentreueanwendungen) unabhängig
vom Typ des Terminals (z.B. Geldausgabeautomat, Telefon und/oder
POS), in den die Karte zum Gebrauch eingeführt wird, abarbeiten.
-
Die
EP-A-0218176 offenbart eine IC-Karte, für die bei der Herstellung in
einem ROM ein Betriebssystem und Programmieranweisungen gespeichert
werden. Die Karte wird durch Speichern von Speicheradressen von
wenigstens einer der Programmieranweisungen in einem EEPROM und
einer Adresstabelle personalisiert. Das Betriebssystem kann dann
nur auf die in der Adresstabelle angegebenen Programmieranweisungen
zugreifen.
-
IC-Karten
haben gewöhnlich
aufgrund von Größen- und
Kostenbeschränkungen
für die
Unterbringung von Speicher auf der Karte eine begrenzte Speicherkapazität. Anwendungen
für Mehrfachanwendungs-Smartcards
werden in einer Programmiersprache geschrieben und gewöhnlich im
EEPROM gespeichert, dessen Inhalt während der Lebenszeit der Karte
geändert
werden kann. Ein Beispiel für
eine in IC-Karten benutzte Programmiersprache ist die Multos Executable
Language (MELTM). Die MEL-Programmanweisungen
werden vom EEPROM gelesen, wenn sie von dem im ROM gespeicherten
Betriebssystem ausgeführt
und interpretiert werden.
-
Der
ROM auf der IC-Karte beinhaltet das Betriebssystem, das in Assembler-Sprachcode
für die jeweilige
IC-Konfiguration (maschinenabhängiger Sprachcode)
geschrieben wurde. Der im ROM gespeicherte Betriebssystemcode wird
beim anfänglichen
Schreiben des ROM festgelegt und die im ROM gespeicherten Informationen ändern sich über die Lebensdauer
der Karte nicht.
-
Im
ROM können
sich auch Subroutinen befinden, Grundstrukturen genannt, die in
maschinenabhängigem
Sprachcode für
den Mikroprozessor geschrieben wurden, der entweder vom Betriebssystem selbst
oder von Anwendungen bei deren Ausführung aufgerufen wird. Grundstrukturen
werden in maschinenabhängiger
Sprache (d.h. Assembler-Sprache) geschrieben, so dass sie sehr schnell
ausgeführt werden
können
und ein Minimum an Interpretation der Anweisungen für die Ausführung notwendig
ist. Diese Grundstrukturen sind Sätze von Anweisungen, die gewöhnlich eine
gewünschte
Funktion ausführen, wie
z.B. eine mathematische oder kryptografische Funktion. Die Anweisungen ändern sich
im Laufe der Lebensdauer der Karte nie. Daten, die von den Grundstrukturen
verwendet werden oder auf die diese Grundstrukturen zugreifen, sind
im EEPROM gespeichert, so dass der Inhalt der Datenelemente nach Bedarf
geändert
werden kann.
-
Im
ROM können
auch „Codelets" gespeichert werden,
bei denen es sich um Sätze
von Anweisungen handelt, die in einer Programmiersprache (nicht
in maschinenabhängigem Sprachcode)
geschrieben wurden. Diese Codelets können im ROM gespeichert werden,
um die Speicherauslastung zu maximieren und es zuzulassen, dass
der ROM vollständige
Anwendungen sowie Grundstrukturen speichert. Das Codelet braucht
lediglich eine einzige Anweisung zu enthalten oder kann so groß sein,
dass es in den verbleibenden ROM-Speicherplatz
passt. So kann beispielsweise die oben beschriebene Geldbörsenanwendung
beim Initialisieren der Karte im ROM gespeichert werden, um im EEPROM
Platz für zusätzliche
Anwendungen frei zu machen, die jederzeit geladen werden können.
-
Wenn
Daten im ROM gespeichert sind, können
diese Daten niemals modifiziert oder gelöscht werden und nach dem Konfigurieren
des ROM können
keine neuen Daten hinzugefügt
werden. Außerdem
wird in Systemen des Standes der Technik bei der Herstellung der
Chipkarte eine Grundstruktur-Adresstabelle
auf der Karte gespeichert, mit der das Betriebssystem die Speicheradresse
einer Grundstruktur finden kann. Diese Adresstabelle im ROM ist
ebenfalls permanent.
-
Bei
diesem System, das in der WO98/52162 nach der Kartenherstellung
beschrieben ist (wenn der ROM fest ist), wird die Karte „personalisiert". Dieser Personalisierungsschritt
erfolgt entweder kurz nach der Herstellung der Karte oder irgendwann
danach, bis zu einer Periode von Monaten oder mehr. In der Zwischenzeit
bleiben Karten bis zu ihrer Personalisierung „leer" (d.h. keinem/r einzelnen Benutzer oder
Gruppe zugeordnet) und werden typischerweise beim Kartenhersteller
oder beim Kartenausgeber aufbewahrt, bis sie gebraucht werden. In
dieser Phase besteht, weil die Karten noch nicht personalisiert sind,
eine größere Gefahr,
dass die Karten missbräuchlich
verwendet werden.
-
Der
Personalisierungsschritt – in
dem die Karten einem/r bestimmten Benutzer oder Gruppe zugeordnet
werden – erfolgt
nicht am Standort des Kartenherstellers, sondern im Allgemeinen
unter der Kontrolle des Kartenausgebers (d.h. der die Karte ausgebenden
Bank) oder in einem anderen Personalisierungsbüro („PB"). Eine separate und vorzugsweise zentral
befindliche Certification Authority, die die Interaktion der Karten überwacht,
stellt dem gewöhnlich
ortsfernen PB geeignete Sicherheitsdaten (nachfolgend erörtert) bereit,
damit das PB die Karte personalisieren (d.h. enabeln) kann, und
damit ein Anwendungsprovider ein Anwendungsprogramm wie z.B. eine
Geldbörsenanwendung
auf die Karte laden kann (entweder zum Zeitpunkt des Enabelns oder später).
-
Eines
der Probleme, mit denen die Designer von Mehrfachanwendungskarten
konfrontiert sind, ist die Frage, wie die Situation anzugehen ist,
wenn die Grundstruktur oder das Codelet, nachdem sie/es bei der
Herstellung maskiert oder auf andere Weise im ROM gespeichert wurde
(und somit nicht mehr geändert
werden kann), ausgetauscht, modifiziert oder aktualisiert werden
muss, um einen Fehler zu beheben oder um von einer effizienteren
oder wirksameren Routine zu profitieren. Ein weiteres Anliegen ist
die Gewährleistung,
dass die im ROM maskierten ursprünglichen
Grundstrukturen und Codelets erst dann verwendet werden können, wenn
die Karte personalisiert, d.h. für
einen bestimmten Benutzer oder eine bestimmte Gruppe, mit individuellen
Keys und Kennungen, enabelt ist. Demgemäß ist es Ziel der Erfindung,
wenigstens einige der obigen Probleme anzugehen und insbesondere
ein Verfahren und ein System bereitzustellen, die diese Probleme
lösen.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Der
Gegenstand der Erfindung ist in den Ansprüchen 1 und 7 definiert.
-
KURZBESCHREIBUNG DER ZEICHNUNGEN
-
Weitere
Aufgaben, Merkmale und Vorteile der Erfindung gehen aus der nachfolgenden
ausführlichen
Beschreibung in Verbindung mit den Begleitzeichnungen hervor, die
illustrative Ausgestaltungen der Erfindung zeigen. Dabei zeigt:
-
1 ein
Blockdiagramm, das die drei Zustände
in der Lebenszeit einer Mehrfachanwendungs-IC-Karte in einem sicheren
System illustriert;
-
2 ein
Blockdiagramm, das die Komponenten der Systemarchitektur für den Enablement-Prozess
einer IC-Karte in einem sicheren Mehrfachanwendungs-IC-Kartensystem
zeigt;
-
3 ein
Blockdiagramm, das die Nur-Lese-Speicherplatzsegmente
für eine
IC-Karte bei der Herstellung gemäß einer
Ausgestaltung der vorliegenden Erfindung illustriert;
-
4 ein
Blockdiagramm, das die elektrisch löschbaren, programmierbaren
Nur-Lese-Speicherplatzsegmente für
eine IC-Karte illustriert, nachdem sie in der Personalisierungsstufe
geladen wurde, gemäß einer
Ausgestaltung der vorliegenden Erfindung;
-
5 ein
Blockdiagramm, das die im EEPROM einer IC-Karte in der Personalisierungsstufe geladene
Adresstabelle gemäß einer
Ausgestaltung der vorliegenden Erfindung zeigt;
-
6 eine
IC-Karte, die in Verbindung mit einer Ausgestaltung der vorliegenden
Erfindung verwendet werden kann; und
-
7 ein
Funktionsblockdiagramm der in 6 gezeigten
integrierten Schaltung.
-
In
den Figuren wurden, wo nicht anders angegeben, dieselben Bezugsziffern
und Zeichen zum Kennzeichnen gleicher Merkmale, Elemente, Komponenten
oder Teile der illustrierten Ausgestaltungen verwendet. Ferner werden
zwar jetzt Ausgestaltungen der vorliegenden Erfindung ausführlich mit
Bezug auf die Figuren beschrieben, aber dies erfolgt in Verbindung
mit den illustrativen Ausgestaltungen. Es ist beabsichtigt, dass Änderungen
und Modifikationen an den beschriebenen Ausgestaltungen vorgenommen
werden können,
ohne vom wahren Umfang und Wesen der vorliegenden Erfindung gemäß Definition
in den beiliegenden Ansprüchen
abzuweichen.
-
AUSFÜHRLICHE BESCHREIBUNG DER ZEICHNUNGEN
-
1 zeigt
die drei Schritte, die zur Erzeugung einer funktionellen Mehrfachanwendungs-IC-Karte
in einem sicheren System notwendig sind. Der erste Schritt ist der
Kartenherstellungsschritt 101. Der zweite Schritt ist der
Personalisierungsschritt 103, in dem Kartenpersonalisierungsdaten
(auch Entitätsauthentifizierungsdaten
genannt) auf die Karte geladen werden. Der dritte Schritt ist der Anwendungsladeschritt 105,
bei dem geprüft
wird, ob eine Karte zur Aufnahme einer Anwendung qualifiziert ist,
d.h. in der die Personalisierungsdaten anhand der mit der zu ladenden
Anwendung assoziierten Anwendungszulassungsdaten geprüft werden. Diese
drei Schritte werden jeweils ausführlich in Anhang A beschrieben.
-
2 zeigt
die Komponenten der Systemarchitektur für den Karteninitialisierungsvorgang
einer IC-Karte in einem sicheren Mehrfachanwendungs-IC-Kartensystem.
Das System umfasst einen Kartenhersteller 102, ein Personalisierungsbüro 104, einen
Anwendungslader 106, die initialisierte IC-Karte 107,
den Kartenbenutzer 109 und die Certification Authority 111 für das gesamte
sichere Mehrfachanwendungssystem. Der Kartenbenutzer 109 ist
die Person oder Entität,
die die gespeicherten Anwendungen auf der IC-Karte benutzen wird.
-
Der
Kartenbenutzer könnte
sich an einen Kartenausgeber 113 wie z.B. eine Bank wenden,
die IC-Karten verteilt, und eine IC-Karte anfordern, deren beide
Anwendungen sich im Speicher einer einzelnen IC-Karte befinden.
Der IC-Chip für
die IC-Karte würde
vom Hersteller 102 hergestellt und zum Kartenausgeber 113 (oder
einer Entität,
die für
diesen tätig
ist) in der Form eines IC-Chip auf einer Karte gesendet. Beim Herstellungsprozess
werden Daten über
einen Datenkanal vom Hersteller 102 zur Karte 107 gesendet 115 und
im Speicher der IC-Karte 107 gespeichert (beliebige der
in dieser Figur beschriebenen Datenkanäle könnten eine Telefonleitung,
eine Internet-Verbindung oder ein beliebiges anderes Übertragungsmedium
sein). Die Certification Authority 111, die Ver-/Entschlüsselungskeys
für das
gesamte System führt, überträgt 117 Sicherheitsdaten (d.h.
globalen Public-Key) zum Hersteller über einen Datenkanal, der vom
Hersteller zusammen mit anderen Daten auf die Karte gesetzt wird,
wie z.B. der Card-Enablement-Key und die Kartenkennung. Das Mehrfachanwendungs-Betriebssystem
der Karte wird ebenso vom Hersteller im ROM gespeichert und auf
die Karte gesetzt. Nach dem anfänglichen
Verarbeiten der Karten werden diese zwecks Personalisierung und
Laden der Anwendung zum Kartenausgeber gesendet.
-
Der
Kartenausgeber 113 führt
zwei separate Funktionen aus und lässt sie von einer anderen Entität ausführen. Erstens,
das Personalisierungsbüro 104 personalisiert
die IC-Karte 107 in den oben beschriebenen Weisen, und zweitens,
der Anwendungslader 106 lädt die Anwendung, vorausgesetzt, dass
die Karte wie in Anhang A beschrieben qualifiziert ist.
-
Gehen
wir jetzt zur Herstellungszeit zurück, auf den ROM 120 der
IC-Karte wird, wie in 3 gezeigt, Folgendes geladen:
der Betriebssystemcode 122, die Codelets 1 und 2, an den
Adressen 1000 und 1050 jeweils als 124, 126 identifiziert,
und die Grundstrukturen 1, 2, 3, 4, an den Adressen 2020, 2040,
2080 und 3000 jeweils mit 128, 130, 132, 134 identifiziert.
Die Adressen sind vorzugsweise physische Adressen im ROM, ein Versatz
vom Grundstruktur-Startzeiger
oder ein beliebiges anderes Adressierschema.
-
Danach
wird die Karte wie oben beschrieben personalisiert. Die CA stellt
dem PB Personalisierungsinformationen zur Verfügung, die einen individuellen
Key-Satz 136 enthalten können. Diese Informationen werden
gewöhnlich
an einer abgesetzten Stelle entweder über das Internet, per CD ROM
oder über
einen anderen Datenkanal oder ein anderes Speichergerät zum PB
gesendet. Das PB lädt
diese Informationen ortsfern auf den EEPROM der Karte (siehe 4)
zusammen mit bestimmten Kennungen 138, wie z.B. einer Kartenidentifikation,
einer Ausgeberidentifikation, einer Produkttypidentifikation (die den
Anwendungstyp angibt, z.B. Geldbörse,
Kundentreue usw.) und das Ladedatum. Zu diesem Zeitpunkt können auch
weitere Grundstrukturen oder Codelet-Codes geladen werden.
-
Gemäß einer
Ausgestaltung der vorliegenden Erfindung lädt das PB ferner die Codelet/Grundstruktur-Adresstabelle 140 ortsfern
auf den EEPROM der Karte. Wie in 5 gezeigt,
enthält
diese Adresstabelle 140 eine Liste der Namen der Codelets
und Grundstrukturen, die entweder vom Anwendungsprogramm oder vom
Betriebssystem zusammen mit den den aufzurufenden Code enthaltenden
Speicheradressen aufgerufen werden. Zu diesem Zeitpunkt wird die
Position von Code bestimmt, der einem bestimmten Grundstrukturaufruf
durch das Betriebssystem oder eine Anwendung entspricht. So kann
die Kontrollbehörde
oder der Systemoperator wählen, welche
in der Karte gespeicherte Codeversion beim Aufrufen eines bestimmten
Grundstrukturnamens ausgeführt
wird.
-
In
diesem besonderen Fall würde
ein Programmbefehl wie CALL PRIM 4 (DATA) bewirken, dass die Adresstabelle
nach der Adresse von PRIM 4 durchsucht wird. Da bei der Personalisierung
ein neuer PRIM 4, mit Adresse 3080, in dem programmierbaren Teil
des Kartenspeichers anstelle des alten PRIM 4 addiert wurde, ruft
das Betriebssystem einfach den neuen PRIM 4 an der Position 3080
ab, wie in der Adresstabelle angegeben ist. Auf den alten Code an
der Speicherposition 3000 wird vom Betriebssystem niemals zugegriffen,
weil es hier keinen Eintrag in der Adresstabelle gibt, der auf den
alten Code zeigt.
-
Demgemäß kann durch
dieses Fernladen einer Adresstabelle bei der Personalisierung das
System (1) das Enablement kontrollieren, bis es gewünscht wird;
und (2) eine Karte trotz eines/r veralteten Codelets oder Grundstruktur
nutzen, das/die möglicherweise
bei der Herstellung permanent auf die Karte gesetzt wurde.
-
6 illustriert
eine Karte 600 mit IC-Technik, die mit der hierin beanspruchten
Erfindung benutzt werden kann. Die Karte 600 sieht ähnlich wie eine
herkömmliche
Kreditkarte aus, beinhaltet aber auch eine integrierte Schaltung
(IC) 622, die einen Mikroprozessor enthält, und elektrische Kontakte 624 für die Kommunikation
zwischen der IC 622 und Geräten außerhalb der Karte 600.
Die Karte 600 kann beispielsweise als Kreditkarte, als
Debitkarte und/oder als elektronische Bargeldkarte verwendet werden,
d.h. als eine Karte, die einen Geldwert beinhaltet, der übertragen
werden kann, wenn der Kartenhalter Einkäufe tätigt, z.B. eine MONDEXTM-Cashkarte.
-
7 ist
ein Funktionsblockdiagramm des IC-Teils 622 und enthält wenigstens
eine Verarbeitungseinheit 710 und eine Speichereinheit 750.
Die IC 722 beinhaltet vorzugsweise auch Steuerlogik 720,
einen Zeitgeber 730 und Ein-/Ausgabeports 740.
Der IC-Teil 722 kann auch einen Coprozessor 760 beinhalten.
Steuerlogik 720 bietet, in Verbindung mit der Verarbeitungseinheit 710,
die zum Handhaben von Kommunikationen zwischen der Speichereinheit 750 und
Ein-/Ausgabeports 740 notwendige Steuerung. Der Zeitgeber 730 erzeugt
ein Zeitreferenzsignal für
die Verarbeitungseinheit 710 und die Steuerlogik 720.
Der Coprozessor 760 bietet die Möglichkeit, komplexe Kalkulationen
in Echtzeit durchzuführen,
wie z.B. solche, die von Verschlüsselungsalgorithmen
benötigt
werden.
-
Es
wurden oben lediglich die Grundsätze
der Erfindung illustriert.