-
HINTERGRUND
DER ERFINDUNG
-
Integrierte
Schaltungs-("IC")-Karten werden in
zunehmendem Maße
für viele
verschiedene Zwecke in der heutigen Welt eingesetzt. Eine IC-Karte (auch
Chipkarte genannt) hat typischerweise die Größe einer konventionellen Kreditkarte,
die einen Computerchip mit einem Mikroprozessor, einem Festwertspeicher
(ROM), einem elektrisch löschbaren
programmierbaren Festwertspeicher (EEPROM), einem Ein-/Ausgabe-(E/A)-Mechanismus
und sonstigen Schaltungen zum Unterstützen des Mikroprozessors bei
seinen Betriebsabläufen
beinhaltet. Eine IC-Karte kann eine einzelne Anwendung oder auch mehrere
unabhängige
Anwendungen in ihrem Speicher enthalten. MULTOSTM ist
ein Multiapplikationsbetriebssystem, das auf IC-Karten, unter verschiedenen
Plattformen, läuft
und die Ausführung
mehrerer Anwendungen auf der Karte selbst zulässt. So kann ein Kartenbenutzer
viele auf der Karte gespeicherte Programme (z.B. Kredit/Debit-,
elektronische Geldbörsen-
[= Electronic Money/Purse] und/oder Loyalitätsanwendungen) unabhängig vom
Terminaltyp (d.h. Geldausgabeautomat, Telefon und/oder POS) abarbeiten,
in den die Karte für
den Gebrauch eingesteckt wird.
-
Das
Dokument EP-A-328 289 offenbart ein IC-Kartensystem, umfassend wenigstens eine IC-Karte,
eine auf die genannte Karte zu aktualisierende Anwendung und Mittel
zum Ermitteln, ob die genannte Karte qualifiziert ist, das Aktualisieren
der genannten Anwendung auf die genannte Karte zu akzeptieren, wobei
die genannte Karte Kartenpersonalisierungsdaten enthält und der
genannten Anwendung Anwendungsgenehmiqungsdaten zugewiesen werden.
-
Auf
eine konventionelle Einzelanwendungs-IC-Karte, wie z.B. eine Telefonkarte
oder eine elektronische Cash-Karte, wird in ihrer Personalisierungsphase
eine einzige Anwendung geladen. Diese Anwendung kann jedoch nach
dem Ausgeben der Karte nicht mehr modifiziert oder geändert werden, selbst
dann nicht, wenn eine solche Modifikation vom Kartenbenutzer oder
Kartenausgeber gewünscht wird.
Ferner müsste
der Kartenbenutzer, wenn er die Durchführung einer Reihe verschiedener
Anwendungsfunktionen durch von ihm ausgegebene IC-Karten wünscht, wie
z.B. eine Electronic-Purse- und
eine Kredit/Debit-Funktion, dann mehrere physische Karten mit sich
führen,
was recht umständlich und
unpraktisch wäre.
Wenn ein Anwendungsentwickler oder Kartenbenutzer wünscht, dass
zwei verschiedene Anwendungen miteinander interagieren oder Daten
miteinander austauschen, wie z.B. eine Purse-Anwendung, die mit
einer Vielflieger-Loyalitätsanwendung
interagiert, dann wäre
der Kartenbenutzer gezwungen, mehrere Karten nacheinander in den
Kartenaufnahmeterminal einzuführen
und wieder herauszunehmen, was die Transaktion schwierig, langwierig
und unpraktisch macht.
-
Die
Anmelderin hat daher erkannt, dass es nützlich wäre, mehrere Anwendungen auf
derselben IC-Karte zu speichern. So könnte ein Kartenbenutzer z.B.
sowohl eine Purse-Anwendung als auch eine Kredit/Debit-Anwendung
auf derselben Karte haben, so dass er auswählen könnte, welchen Zahlungstyp (elektronische
Cash-Karte oder Kreditkarte) er für einen bestimmten Kauf benutzt.
Es könnten
mehrere Anwendungen auf einer IC-Karte vorgesehen werden, wenn ausreichend
Speicherkapazität
und ein Betriebssystem auf der Karte vorhanden ist, um mehrere Anwendungen
zu unterstützen.
Es könnten mehrere
Anwendungen vorgewählt
und in der Produktionsphase in den Speicher der Karte geladen werden,
aber es wäre
auch nützlich
die Fähigkeit
zu haben, Anwendungen nach Bedarf für die Kartennachproduktion
zu laden und zu löschen.
-
Durch
die erhöhte
Fähigkeit
und Leistung des Speicherns mehrerer Anwendungen auf einer einzelnen
Karte ergeben sich neue technische Herausforderungen in Bezug auf
Integrität
und Sicherheit der Informationen (einschließlich Anwendungscode und zugehörige Daten),
die zwischen der jeweiligen Karte und dem Applikationsprovider sowie
innerhalb des gesamten Systems beim Laden und Löschen von Anwendungen überwunden
werden müssen.
Die Anmelderin hat ferner erkannt, dass es nützlich wäre, wenn man im IC-Kartensystem Daten
zwischen Karten, Kartenausgebern, Systembetreibern und Applikationsprovidern
austauschen und Anwendungen auf sichere Weise jederzeit entweder
von einem Terminal oder ortsfern über eine Telefonleitung, über eine
Internet- oder Intranet-Verbindung oder über einen anderen Datenkanal
laden und löschen könnte. Da
diese Datenübertragungsleitungen
typischerweise keine sicheren Leitungen sind, müsste eine Reihe von Sicherheits-
und Entitätsauthentifizierungstechniken
ausgeführt
werden, um sicherzustellen, dass über die Übertragungsleitungen gesendete Anwendungen
nur auf die beabsichtigten Karten geladen werden.
-
Wie
erwähnt,
ist es wichtig – besonders dann,
wenn dem Kartenhalter ständig
eine Vielfalt neuer Anwendungen zur Verfügung steht – dass das System die Möglichkeit
hat, der IC-Karte nach der Ausgabe Anwendungen hinzuzufügen. Dies
ist äußerst vorteilhaft,
weil dadurch die Lebensdauer der IC-Karten geschützt wird, weil die Karte sonst,
wenn die Anwendung veraltet, nutzlos würde. In dieser Hinsicht hat
die Anmelderin ferner erkannt, dass es zum Schutz vor einem unrechtmäßigen oder
unerwünschten
Laden von Anwendungen auf IC-Karten nützlich wäre, wenn das IC-Kartensystem
die Fähigkeit
hätte, den
Ladevorgang zu steuern und wo notwendig oder gewünscht die Benutzung bestimmter
Anwendungen auf eine begrenzte Gruppe oder Anzahl von Karten zu
beschränken,
so dass die Anwendungen für
die IC-Karten im
System "selektiv
verfügbar" sind. Diese "Selektionsfähigkeit" würde es erlauben,
Anwendungen z.B. zu einem gewünschten
Zeitpunkt im Lebenszyklus der Karte zu laden und zu löschen. So könnte auch
eine Anwendung nur auf die Karten geladen werden, die für den Empfang
der gewählten Anwendung
ausgewählt
wurden.
-
Es
ist demgemäß ein Vorteil
einer bevorzugten Ausgestaltung der Erfindung, dass sie diese wichtigen
Merkmale und insbesondere ein sicheres IC-Karten-System bereitstellt,
das eine selektive Verfügbarkeit
von Chipkartenanwendungen zulässt,
die auf IC-Karten geladen werden können. Es können auch Anwendungen von der
IC-Karte gelöscht
werden.
-
Diese
und andere Vorteile werden mit den Merkmalen der Ansprüche 1, 16,
23 und 28 erzielt. Bevorzugte Ausgestaltungen sind in den Ansprüchen 2–15, 17–22, 24–27 des
vorliegenden Dokuments offenbart.
-
Weitere
Aspekte, Merkmale und Vorteile von Ausgestaltungen der Erfindung
gehen aus der nachfolgenden ausführlichen
Beschreibung im Zusammenhang mit den beiliegenden Figuren hervor,
die illustrative Ausgestaltungen der Erfindung zeigen. Dabei zeigt:
-
1 ein
Blockdiagramm der drei Stadien während
der Lebenszeit einer Multiapplikations-IC-Karte in einem sicheren
System;
-
2 ein
Blockdiagramm der Schritte des Kartenherstellungsprozesses;
-
3 ein
Ablaufdiagramm, das die Schritte beim Freigeben der einzelnen IC-Karten
in dem sicheren System illustriert;
-
4 ein
Blockdiagramm eines IC-Kartenchips, der gemäß der Erfindung verwendet werden kann;
-
5 ein
Blockdiagramm, das die auf der IC-Karte gespeicherten Daten gemäß Anzeige
in Block 307 von 3 illustriert;
-
5A ein
Schema der Datenstrukturen, die in einer IC-Karte resident sind
und Personalisierungsdaten repräsentieren;
-
6 ein
Ablaufdiagramm, das die Schritte des Ladens einer Anwendung auf
eine IC-Karte in dem sicheren System illustriert;
-
7 ein
Ablaufdiagramm, das die Prüfschritte
wie in Block 601 von 6 angezeigt
illustriert;
-
8 ein
Ablaufdiagramm, das die Schritte illustriert, die bei der Bestimmung
durchgeführt
wurden, ob eine Anwendung genehmigt wird;
-
9 ein
Blockdiagramm, das die Komponenten der Systemarchitektur für den Freigabeprozess
einer IC-Karte in einem sicheren Multiapplikations-IC-Kartensystem
zeigt; und
-
10 ein
Systemdiagramm von Entitäten, die
an der Verwendung der IC-Karte nach deren Personalisierung beteiligt
sind.
-
In
allen Figuren werden dieselben Bezugsziffern und – zeichen,
wenn nicht anders angegeben, zum Bezeichnen gleichartiger Merkmale,
Elemente, Komponenten oder Teile der illustrierten Ausgestaltungen
verwendet. Ferner wird der Erfindungsgegenstand zwar ausführlich mit
Bezug auf die Figuren beschrieben, aber diese Beschreibung 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 des Erfindungsgegenstandes gemäß Definition in
den beiliegenden Ansprüchen
abzuweichen.
-
Eine
Ausgestaltung gemäß der vorliegenden Erfindung
stellt ein IC-Kartensystem und ein Verfahren bereit, die die Flexibilität bieten,
gewählte
Anwendungen über
die Lebenszeit einer Multiapplikations-IC-Karte als Reaktion auf
die Erfordernisse oder Wünsche
von Kartenbenutzern, Kartenausgebern und/oder Anwendungsentwicklern
zu laden und zu löschen.
Ein Kartenbenutzer, der eine solche Karte hat, kann Anwendungen
nach Bedarf selektiv laden und löschen,
wenn der Kartenausgeber dies in Verbindung mit dem Systembetreiber
oder der Zertifizierungsautorität
("CA") zulässt, die
den Lade- und Löschprozess
durch Zertifizieren der Übertragung von
Informationen über
den Prozess steuert.
-
Da
Anwendungen selektiv auf die Karte geladen und von dieser gelöscht werden
können,
kann ein Kartenausgeber die Funktionalität einer einzelnen IC-Karte
erweitern, ohne neue Karten ausgeben zu müssen. Außerdem können Anwendungsentwickler alte
Anwendungen durch neue erweiterte Versionen ersetzen, und Anwendungen,
die auf derselben Karte, die ein gemeinsames Multiapplikationsbetriebssystem
verwendet, resident sind, können
auf sichere Weise interagieren und Daten austauschen. So kann z.B.
ein Vielflieger-Loyalitätsprogramm
dem internen Konto eines Kartenbenutzers für jeden mit der Mondex-Purse
oder einer Kredit/Debit-Anwendung ausgegebenen Dollar automatisch
eine Vielfliegermeile gutschreiben. Durch Ermöglichen des selektiven Ladens
und Löschens
von Anwendungen erhält
der Kartenbenutzer, vorbehaltlich der Anforderungen des Kartenausgebers,
auch die Option, Loyalitätsprogramme
nach Bedarf zu ändern.
-
Ein
Kartenausgeber oder Anwendungsentwickler hat möglicherweise die Absicht, eine
bestimmte Anwendung nur auf eine Karte für einen bestimmten Kartenbenutzer
in einem Kartensystem zu laden. Eine regionale Bank möchte möglicherweise, dass
eine proprietäre
Anwendung nur auf den Karten resident ist, die die Bank ausgibt.
Ausgestaltungen der vorliegenden Erfindung würden ein solches selektives
Laden zulassen und es insbesondere ermöglichen zu verhindern, dass
proprietäre
Anwendungen auf unautorisierte, von Dritten ausgegebenen Karten geladen
werden.
-
Um
diese gewünschten
Ziele zu erreichen, geben Ausgestaltungen der vorliegenden Erfindung jeder
Karte eine bestimmte Kennung, indem sie "Kartenpersonalisierungsdaten" auf der Karte speichert. Ferner
werden jeder Anwendung, die auf eine oder mehrere Karten in dem
System geladen oder von ihr gelöscht
werden sollen, "Anwendungsgenehmigungsdaten" zugewiesen, die
die Karten vorgeben, auf die die Anwendungen geladen werden dürfen.
-
Der
Typ der personalisierten Daten kann von den Erfordernissen und Anforderungen
des Kartensystems abhängen.
In der nachfolgend ausführlicher beschriebenen
bevorzugten Ausgestaltung beinhalten die Personalisierungsdaten
eindeutige Kartenidentifikations-Bezeichnungsdaten,
Kartenausgeber, Produktklasse oder -typ (vom Kartenausgeber definiert)
sowie das Datum der Personalisierung. Es brauchen jedoch nicht alle
diese Datenelemente verwendet zu werden, und es können weitere
Elemente einbezogen werden.
-
Die mit einer Anwendung
assoziierten
-
Anwendungsgenehmigungsdaten,
die ebenfalls nachfolgend ausführlicher
beschrieben werden, können
ein einziger Wert in einem Kennungsfeld sein oder könnten mehrere
Werte in dem Kennungsfeld beinhalten. So könnten beispielsweise die Anwendungsgenehmigungsdaten
im Kartenausgeberfeld sowohl die Produktklasse A als auch die Produktklasse
B einer bestimmten Bank X repräsentieren,
was bedeutet, dass die Anwendung auf Karten geladen werden könnte, die
als von der Bank X ausgegebene Produktklassen A und B bezeichnet
sind (gemäß Anzeige
im Kartenprodukt-ID-Feld der Personalisierungsdaten der Karte).
-
Außerdem könnte ein "Globalwert" im Ausgeberfeld
(oder einem anderen Feld) der Anwendungsgenehmigungsdaten gespeichert
werden, der anzeigt, dass alle IC-Karten in dem System mit diesem
Genehmigungsfeld übereinstimmen
würden,
unabhängig
davon, wer die Karte ausgegeben hat. In diesem Fall stimmt z.B.
ein im Anwendungsgenehmigungs-Kartenausgeberfeld
gespeicherter Datenwert von null mit allen Personalisierungs-Kartenausgeberfeldern
der Karten überein.
-
1 zeigt
die drei Schritte, die bei der Bereitstellung einer funktionsfähigen Multiapplikations-IC-Karte in einem sicheren
System beteiligt sind. Der erste Schritt ist der Kartenherstellungsschritt 101.
Der zweite Schritt ist der Personalisierungsschritt 103,
bei 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 zum Empfangen einer Anwendung qualifiziert ist,
d.h. wo die Personalisierungsdaten anhand der Anwendungsgenehmigungsdaten
geprüft
werden, die mit der zu ladenden Anwendung assoziiert sind. Jeder
dieser drei Schritte wird nachfolgend ausführlich beschrieben.
-
Kartenherstellung
-
2 zeigt
die Schritte, die bei der Herstellung einer IC-Karte in einem sicheren
System notwendig sind. In Schritt 201 wird die physische
IC-Karte durch Produzieren der integrierten Schaltung auf Silicium
und deren Platzieren auf der Karte hergestellt. Der integrierte
Schaltungschip beinhaltet RAM-, ROM- und EEPROM-Speicher. Bei der
Herstellung der Karte wird zunächst
in Schritt 203 ein globaler Public-Key des Systembetreibers
(in diesem Fall Zertifizierungsautorität (CA) genannt) auf jeder Karte
im ROM gespeichert. So kann die Karte authentifizieren, ob die Quelle
einer Nachricht zu ihr von der CA stammt, da der Public-Key auf
der Karte mit dem Geheimschlüssel
der CA verglichen wird.
-
Spezifischer
ausgedrückt, über diesen
auf der Karte gespeicherten Public-Key kann die individuelle Karte
mit dem Private-Key der CA signierte Daten überprüfen. Der Public-Key der CA,
der auf der Karte gespeichert ist, wird nur zum Ermitteln benutzt, ob
die zu der Karte gesendeten Daten mit dem richtigen Private-Key
der CA signiert wurden. So kann die Karte die Quelle jeder von der
CA kommenden Nachricht prüfen.
-
In
Schritt 205 wird ein Kartenfreigabeschlüssel in einen sicheren Teil
des EEPROM in der Karte eingefügt,
um die kartenspezifische Vertraulichkeit während der Freigabe zu erleichtern,
und in Schritt 207 wird eine Kartenkennung in den EEPROM
der Karte eingefügt.
Die Kennung, auf die von jedem Terminal zugegriffen werden kann,
erlaubt es dem System, die Identität der Karte in späteren Prozessen
zu ermitteln. Die Kennung ist frei verfügbar und wird nicht zum Authentifizieren
von Nachrichten verwendet.
-
Schritt 209 speichert
den Betriebssystemcode im ROM auf der Karte, einschließlich eventueller
Grundelemente, die vom Betriebssystem abgerufen oder unterstützt werden.
Die Grundelemente werden in maschinenabhängiger Sprache (z.B. Assembler-Sprache)
geschrieben und im ROM gespeichert. Die Grundelemente sind Subroutinen,
die vom Betriebssystem oder von auf der Karte residenten Anwendungen
abgerufen werden können,
z.B. mathematische Funktionen (Multiplizieren oder Dividieren), Datenabruf-,
Datenmanipulations- oder Verschlüsselungsalgorithmen.
Die Grundelemente können
sehr rasch ausgeführt
werden, weil sie in der maschinenabhängigen Sprache des Prozessors
geschrieben sind.
-
Nach
der Herstellung der IC-Karten werden diese zu einem Personalisierungsbüro ("PB") gesendet, um die
Karte freizugeben und zu personalisieren, indem Kartenpersonalisierungsdaten
im Speicher der Karte gespeichert werden. Die Begriffe Freigabe und
Personalisierung werden hier untereinander austauschbar verwendet,
um die Vorbereitungsschritte anzuzeigen, die durchgeführt werden,
um auf sichere Weise eine Anmeldung auf die Karte zu laden. Die
individuellen Karten werden vorzugsweise in Serien hergestellt und
zu einem Personalisierungsbüro
in einer Gruppe zur Verarbeitung gesendet.
-
Kartenfreigabe/-personalisierung
-
3 zeigt
die Schritte des Kartenfreigabeprozesses, wenn die Karte bei einem
Personalisierungsbüro
ankommt. Das Personalisierungsbüro kann
der Kartenausgeber (z.B. eine Bank oder ein anderes Finanzinstitut)
oder ein Dritter sein, der den Service für den Kartenausgeber ausführt. Das
Personalisierungsbüro
konfiguriert die Karte auf einen spezifischen Benutzer oder eine
spezifische Benutzerklasse.
-
3 zeigt
speziell die Schritte, die durchgeführt werden, um jede IC-Karte,
die in dem System aktiv sein soll, freizugeben und zu personalisieren. Die
Karten können
in einen Terminal eingeführt
werden, der mit IC-Karten kommuniziert und die Kartenkennungsdaten
(die zuvor beim Herstellungsprozess auf die Karte geladen wurden – siehe
Schritt 207) liest. Diese Kartenidentifikationsdaten werden
in Schritt 301 von der Karte gelesen. Der Terminal sendet
effektiv einen Befehl "Identifikationsdaten
holen" zur Karte,
und die Karte gibt die Identifikationsdaten zum Terminal zurück.
-
Das
PB verarbeitet eine Gruppe von Karten gleichzeitig und erstellt
zunächst
eine Liste mit IC-Karten-Identifikationsdaten
für die
Gruppe von Karten, die es personalisiert. Das PB sendet diese Liste
von Identifikationsdaten dann elektronisch (oder auf andere Weise)
zur Zertifizierungsautorität ("CA"), die einen Personalisierungs-
(oder Freigabe-) Datenblock für
jede Kartenkennung erzeugt. Der Datenblock beinhaltet die Kartenpersonalisierungsdaten,
die zu einer Anzahl von Kennungsfeldern organisiert sind, und einen
individuellen Key-Set für
die Karte, wie nachfolgend erörtert
wird. Diese Datenblöcke werden
dann verschlüsselt
und zum PB gesendet (Schritt 302). Das PB stimmt dann die
Karten anhand der Kartenidentifikationsdaten auf die verschlüsselten
Datenblöcke
ab und lädt
jeden Datenblock separat auf die abgestimmte Karte. Um zu gewährleisten, dass
die CA die Kontrolle über
die Identität
der Karte und die Integrität
des Systems behält,
erhält
das PB niemals Kenntnis über
den Inhalt der übertragenen Datenblöcke. Einige
Aspekte der Personalisierung werden vom Kartenausgeber von der CA
für deren bevorzugtes
Management der von ihnen ausgegebenen Karten angefordert. Es werden
die folgenden zusätzlichen
Schritte durchgeführt.
-
Schritt 303 prüft zunächst, ob
ein im EEPROM der Karte gespeichertes Freigabebit bereits gesetzt
ist. Ist es bereits gesetzt, dann wurde die Karte bereits konfiguriert
und personalisiert, und der Freigabeprozess endet wie in Schritt 304 gezeigt. Eine
Karte kann nicht zweimal freigegeben und personalisiert werden.
Ist das Bit nicht gesetzt, dann wird der Prozess mit Schritt 305 fortgesetzt.
-
In
Schritt 305 wird der individualisierte Karten-Key-Set (dieser Schlüsselsatz
wird bei der CA generiert) für
die Karte, die gerade freigegeben wird, auf der Karte gespeichert.
Die Keys können
später bei
der kartenexternen Prüfung
(d.h. um zu prüfen, ob
die Karte eine authentische Karte ist) verwendet werden. Diese Prüfung ist
notwendig, um die Karte als diejenige zu authentifizieren, für die die
Anwendung beabsichtigt ist.
-
In
Schritt 307 werden bei der CA vier verschiedene, für den MULTOS
Security Manager (MSM) charakteristische Datenelemente (ansonsten hierin
als Personalisierungsdaten bezeichnet) für die Karte erzeugt, die für ein sicheres
und korrektes Laden und Löschen
von Anwendungen auf eine und von einer bestimmte(n) Karte verwendet
werden. Die MSM-Charakteristiken
ermöglichen
auch das Laden von Anwendungen auf spezifische Klassen von identifizierten
Karten. (Diese MSM-Charakteristiken werden in Verbindung mit 5 näher beschrieben.)
-
Jetzt
können
auch noch je nach Systemdesignbedarf weitere Daten auf der Karte
gespeichert werden, wie z.B. eine Adresstabelle oder weitere Subroutinen.
-
In
Schritt 311 wird das Freigabebit im EEPROM der Karte gesetzt,
was bedeutet, dass der Freigabeprozess für die jeweilige Karte beendet
ist. Wenn dieses Bit gesetzt ist, kann kein weiterer Freigabeprozess
auf der Karte erfolgen. Dadurch wird gewährleistet, dass nur ein Personalisierungs-
und Freigabeprozess an der Karte erfolgen kann, so dass ein illegaler
Eingriff in die Karte oder eine versehentliche Änderung der Karte verhindert
wird. In der bevorzugten Ausgestaltung wird das Freigabebit nicht bei
der Herstellung der Karte, sondern am Ende des Freigabeprozesses
gesetzt.
-
4 zeigt
ein Beispiel für
ein Blockdiagramm eines IC-Kartenchips, der hergestellt und personalisiert
wurde. Der IC-Kartenchip befindet sich auf einer IC-Karte für den Gebrauch.
Die IC-Karte beinhaltet vorzugsweise eine Zentraleinheit 401,
einen RAM 403, einen EEPROM 405, einen ROM 407,
einen Timer 409, eine Steuerlogik 411, E/A-Ports 413 und
einen Sicherheitsschaltkomplex 415, die über einen
konventionellen Datenbus miteinander verbunden sind.
-
Die
Steuerlogik 411 in Speicherkarten bietet genügend Sequenzierung
und Umschaltung für
die Handhabung von Lese- Schreib-Zugriff
auf den Speicher der Karte durch die Ein/Ausgabeports. Die CPU 401 kann
mit ihrer Steuerlogik Berechnungen durchführen, auf Speicherstellen zugreifen,
Speicherinhalt modifizieren und Ein-/Ausgabeports verwalten. Einige
Karten haben einen Koprozessor zum Handhaben komplexer Berechnungen
wie Verschlüsselungsalgorithmen.
Ein-/Ausgabeports 413 werden nur gesteuert von einer CPU
und von Steuerlogik für
Kommunikationen zwischen der Karte und einem Kartenannahmegerät verwendet.
Der Timer 409 (der einen Taktimpuls erzeugt oder bereitstellt)
steuert die Steuerlogik 411 und die CPU 401 durch
die Schrittfolge zur Durchführung
von Speicherzugriff, Speicherlesen oder – schreiben, Verarbeitung und
Datenkommunikation an. Ein Timer kann für Anwendungsmerkmale wie Rufdauer
verwendet werden. Ein Sicherheitsschaltkomplex 415 beinhaltet
schmelzbare Verbindungen, die die Ein-/Ausgabeleitungen zum internen Schaltkomplex
nach Bedarf zum Testen während
der Herstellung verbinden, die aber nach Testabschluss zerstört ("durchgebrannt") werden, um einen
späteren
Zugriff zu verhindern. Die Personalisierungsdaten zum Qualifizieren
der Karte werden an einer sicheren Stelle des EEPROM 405 gespeichert.
Der Vergleich zwischen den Personalisierungsdaten und Anwendungsgenehmigungsdaten
erfolgt durch die CPU 401.
-
5 zeigt
die Schritte zum Erstellen und Laden der vier Elemente der Kartenpersonalisierungsdaten
in den Speicher der IC-Karten, und 5A zeigt
ein Schema von Bitmaps für
jedes Kennungsfeld, das im Speicher einer IC-Karte resident ist, die Personalisierungsdaten
gemäß der vorliegenden
Erfindung enthält.
Jede Datenstruktur für
jedes Kennungsfeld hat ihren eigenen Deskriptor-Code. In Schritt 501 wird
die Datenstruktur für
das Kennungsfeld "Karten-ID" mit der Bezeichnung "msm_mcd_permissions_mcd_no" geladen. Diese Nomenklatur
bedeutet die "MULTOS
system manager_MULTOS card device_permissions_MULTOS Kartengerätenummer". Diese Zahl hat
zwar typischerweise eine Länge von
8 Bytes wie in 5A gezeigt, aber die Daten könnten jede
beliebige Länge
haben, die eine eindeutige Nummer für die Karte bedeutet. In der
bevorzugten Ausgestaltung sind 2 Bytes als Signalindikator dediziert,
2 Bytes umfassen ein MULTOS Injection Security Module ID (MISM ID),
die anzeigt, welches Sicherheitsmodul die injizierten Keys bei der
Herstellung in die Karte injiziert hat, und 4 Bytes umfassen eine
Seriennummer der Integrated Circuit Card (ICC), die die an diesem
MISM erzeugte individuelle Karte identifiziert.
-
In
Schritt 503 wird die Datenstruktur für das Kennungsfeld "Issuer ID" (Ausgeber-ID) mit
der Bezeichnung "msm_mcd_permissions_mcd_issuer_id" geladen. Diese,
Nomenklatur bedeutet eine MULTOS-Kartengeräteausgeber-Identifikationsnummer. Jedem Kartenausgeber
(wie z.B. einer bestimmten Bank, einem bestimmten Finanzinstitut
oder einem anderen an einer Anwendung beteiligten Unternehmen) wird
eine eindeutige Nummer in dem Kartensystem zugeordnet. Jede IC-Karte
in dem MULTOS-System enthält
Informationen über
den Kartenausgeber, der die Karte personalisiert hat oder für die Karte
verantwortlich ist. Ein Kartenausgeber bestellt eine bestimmte Anzahl
von Karten bei einem Hersteller und führt den hierin beschriebenen
Personalisierungsprozess durch oder lässt ihn durchführen. So bestellt
beispielsweise eine regionale Bank 5000 Karten, die an ihre Kunden
verteilt werden. Die Datenstruktur "mcd_issuer_id" auf diesen Karten gibt an, welcher
Ausgeber die Karten ausgegeben hat. In der bevorzugten Ausgestaltung
hat die Datenstruktur eine Länge
von 4 Bytes (wie in 5A bei 503A gezeigt),
so dass viele verschiedene Ausgeber im System möglich sind, obwohl die Länge der
Datenstruktur je nach den Bedürfnissen
des Kartensystems variieren kann. In Schritt 505 wird die
Datenstruktur für das
Kennungsfeld "Product
ID" mit der Bezeichnung "msm_mcd_permissions_mcd_issuer_product_id" geladen. Diese Nomenklatur
bedeutet die MULTOS-Kartengeräteausgeber-Produktidentifikationsnummer.
Jeder Kartenausgeber kann verschiedene Klassen von Produkten oder
Karten haben, zwischen denen er möglicherweise unterscheiden
will. So könnte
beispielsweise eine Bank eine gewöhnliche Kreditkarte mit einer
Produkt-ID, eine Gold-Kreditkarte mit einer anderen Produkt-ID und
eine Platinkarte mit noch einer anderen Produkt-ID ausgeben. Der Kartenausgeber
möchte
möglicherweise
bestimmte Anwendungen nur auf eine Klasse von Kreditkarten laden.
Der Benutzer einer Gold-Kreditkarte,
der eine Jahresgebühr
zahlt, ist möglicherweise
zu einer größeren Vielfalt
von Anwendungen berechtigt als ein Benutzer einer gewöhnlichen
Kreditkarte, der keine Jahresgebühr
zahlt. Das Produkt-ID-Feld identifiziert die Karte als eine bestimmte
Klasse und erlaubt es dem Kartenausgeber später, die Produkt-ID zu prüfen und
nur Anwendungen auf Karten zu laden, die mit der gewünschten
Klasse übereinstimmen.
-
Eine
weitere Unterscheidungsmöglichkeit zwischen
Produkten wäre
der Anwendungstyp, wie z.B. nach Anwendungskategorien wie Finanzen, Recht,
Medizin und/oder Freizeit/Erholung, oder durch Zuweisen bestimmter
Anwendungen zu einer Gruppe von Karten. So stellt beispielsweise
ein Kartenausgeber möglicherweise
verschiedene Loyalitätsprogramme
mit verschiedenen Unternehmen zu verschiedenen Sätzen von Kartenbenutzern zur
Verfügung.
So kann beispielsweise eine Bank ein Loyalitätsprogramm für American
Airlines® und
ein Loyalitätsprogramm
für British
Airways® für verschiedene Regionen
des Landes haben, je nach dem, wo die Airlines fliegen. Über den
Produkttyp kann der Ausgeber die Produktklassifizierung der Karte
während des
Personalisierungsvorgangs festlegen. Beim Laden von Anwendungen
auf die Karte wird die Produkttyp-Identifikationsnummer auf jeder Karte
geprüft,
um sicherzustellen, dass sie mit dem Kartentyp übereinstimmt, auf den der Ausgeber
laden möchte. Die
Produkttyp-Datenstruktur
ist vorzugsweise ein Indexiermechanismus (im Gegensatz zu der anderen Personalisierungstruktur)
von 8 Bits (wie bei 505A in 5A gezeigt),
könnte
jedoch jede beliebige Länge haben,
je nach den Erfordernissen des Kartensystems. In der illustrierten
Ausgestaltung würde
sich die resultierende Anweisung darauf beziehen, das zweite Bit
(da der angezeigte Wert des Bytes 2 ist) in der zu durchsuchenden
Array zu finden (siehe Erörterung
von Schritt 809 unten).
-
In
Schritt 507 wird die Datenstruktur für die Kennungsfelddaten mit
der Bezeichnung "msm_mcd_permissions_mcd_controls_data_date" geladen. Diese Nomenklatur
bedeutet MULTOS-Kartengerätedatensteuerdatum
oder, mit anderen Worten, das Datum, an dem die Karte personalisiert
wurde, so dass beispielsweise der Anwendungslader Daten auf Karten
laden kann, die nach einem bestimmten Datum datiert sind, Karten
vor einem bestimmten Datum (z.B. für Anwendungs-Updates) laden
oder Karten mit einem bestimmten Datendatum laden kann. Die Informationen
können
Jahr, Monat und Tag der Personalisierung oder bei Bedarf auch weniger
Informationen beinhalten. Die Datenstruktur data date hat vorzugsweise
eine Länge
von 1 Byte (siehe 507A in 5A), könnte aber
jede beliebige Länge
haben, je nach den Erfordernissen des jeweiligen benutzten Kartensystems.
-
Wenn
alle Personalisierungsdatenstrukturen geladen und in der Karte gespeichert
sind, dann ist die Karte nach Ausgeber, Produktklasse, Datum und Identifikationsnummer
(bei Bedarf auch mit anderen Datenfeldern) identifiziert und kann
ihre Identität nicht
mehr ändern;
diese Felder können
im Speicher der Karte nicht verändert
werden. Wenn ein Kartenbenutzer die in der Karte gespeicherte product_id ändern möchte, um
Zugang zu anderen Anwendungen zu erhalten, die für einen anderen Produkttyp
zur Verfügung
steht, dann muss dem Benutzer eine neue Karte ausgegeben werden,
die die korrekten Personalisierungsdaten enthält. Dieses System steht im Einklang
mit einer Situation, in der der Besitzer einer Goldkarte eine neue
Karte erhält,
wenn die Klassifizierung auf Platin geändert wird.
-
Nach
dem Freigeben und Personalisieren der Karte durch Speichern ihres
individuellen Karten-Key-Set, ihrer MSM-Personalisierungscharakteristiken und
des Freigabebits wie in 3 beschrieben, können jetzt
Anwendungen in den Speicher der Karte geladen werden.
-
Laden von Anwendungen
-
Der
Anwendungsladeprozess enthält
eine Reihe von Sicherheits- und Kartenkonfigurationschecks, um das
sichere und ordnungsgemäße Laden einer
Anwendung auf die beabsichtigte IC-Karte zu gewährleisten. Dieser Anwendungsladeprozess
erfolgt vorzugsweise im Personalisierungsbüro, so dass die Karte bei der
Ausgabe eine oder mehrere Anwendungen enthält. Die Karte kann bestimmte
gemeinsame Anwendungen enthalten, die auf jeder von dem Ausgeber
verschickten Karte vorhanden sind, wie z.B. eine Electronic-Purse-Anwendung
oder eine Kredit/Debit-Anwendung. Alternativ könnte das Personalisierungsbüro die freigegebenen
Karten zu einem Dritten zum Laden von Anwendungen senden. Das im
ROM jeder Karte gespeicherte Multiapplikationsbetriebssystem und
die MSM-Personalisierungsdaten der Karte sind so ausgelegt, dass
ein späteres Laden
und Löschen
von Anwendungen nach dem Ausgeben der Karte je nach den Wünschen des
jeweiligen Kartenbenutzers und des verantwortlichen Kartenausgebers
möglich
sind. So könnte
eine ältere Version
einer auf der IC-Karte gespeicherten Anwendung durch eine neue Version
der Anwendung ersetzt werden. Es könnte auch eine zusätzliche
Loyalitätsanwendung
zur Karte hinzugefügt
werden, nachdem sie anfänglich
zum Kartenbenutzer gesendet wurde, weil die Anwendung jetzt neu
zur Verfügung
steht oder der Benutzer die neue Anwendung benutzen möchte. Diese
Lade- und Löschfunktionen für Anwendungen
können
direkt durch einen Terminal oder auch über Telefonleitungen, Datenleitungen, ein
Netzwerk wie z.B. das Internet oder eine beliebige andere Weise
zum Übertragen
von Daten zwischen zwei Objekten (Entitäten) durchgeführt werden.
Im vorliegenden IC-Kartensystem gewährleistet der Prozess des Übertragens
des Anwendungsprogramms und der Daten, dass nur IC-Karten, die die richtigen
Personalisierungsdaten enthalten und die dem Anwendungsgenehmigungsprofil
entsprechen, qualifiziert sind und das entsprechende Anwendungsprogramm
und die Daten empfangen.
-
6 zeigt
die bevorzugten Schritte, die beim Laden einer Anwendung auf eine
IC-Karte im MULTOS-IC-Kartensystem durchgeführt werden. Für dieses
Beispiel lädt
das Personalisierungsbüro
eine Anwendung von einem Terminal, der dieselbe Karte freigegeben
hat. In Schritt 601 wird ein vom Terminal eingeleiteter "Öffnungsbefehl" ausgeführt, der
eine Voransicht der Karte durchführt,
um sicherzustellen, dass die Karte qualifiziert ist, das Laden einer
spezifischen Anwendung zu akzeptieren. Mit dem Öffnungsbefehl erhält die Karte
die Genehmigungsdaten der Anwendung, die Größe der Anwendung und die Anweisung
zu ermitteln (1), ob das Freigabebit gesetzt ist, was anzeigt, dass
die Karte personalisiert ist; (2) ob der Anwendungscode und die
zugehörigen Daten
auf den existierenden Speicherplatz auf der Karte passen; und (3)
ob die Personalisierungsdaten, die der zu ladenden Anwendung zugewiesen
wurden, das Laden der Anwendung auf die jeweilige Karte bei der
Ausgabe zulassen. Der Öffnungsbefehl könnte auch
zusätzliche
Checks durchführen,
die das Kartensystem möglicherweise
verlangt. Diese Prüfschritte
während
der Ausführung
des Öffnungsbefehls
werden nachfolgend ausführlich
in Verbindung mit 7 beschrieben.
-
Nach
dem Ausführen
des Öffnungsbefehls wird
dem Anwendungslader über
das Terminal mitgeteilt, ob die Karte die richtigen Identifikationspersonalisierungsdaten
enthält
und ob genügend
Platz im Speicher der Karte für
den Anwendungscode und die zugehörigen
Daten vorhanden ist. Wenn nicht genügend Speicherplatz vorhanden
ist, dann wird der Karte eine negative Antwort zurückgegeben
und der Prozess wird abnormal beendet. Wenn die Identifikationspersonalisierungsdaten
nicht mit den Anwendungsgenehmigungsdaten übereinstimmen, wird in Schritt 603 eine
Warnantwort gegeben, aber der Prozess wird mit den Lade- und Erstellungsschritten
fortgesetzt. Alternativ wird der Prozess, wenn keine Übereinstimmung
vorliegt, automatisch abnormal beendet. Gibt die Karte dem Terminal
in Schritt 605 eine positive Antwort, dann geht der Anwendungslader vorzugsweise
auf die nächsten
Schritten über.
Der Öffnungsbefehl
erlaubt der Anwendung eine Voransicht der Karte vor dem Start von Übertragungen
von Code und Daten.
-
In
Schritt 607 werden dann Anwendungscode und Daten in den
EEPROM der IC-Karte geladen. Der tatsächliche Ladevorgang erfolgt
in Verbindung mit dem Erstellungsschritt 609, der den Ladeprozess
vollendet und die Anwendung befähigt,
nach dem Laden auf der IC-Karte abzulaufen. Die Kombination aus Öffnungs-,
Lade- und Erstellungsbefehl wird vom Terminal oder einer anderen
Anwendungsproviderquelle zur Durchführung des Anwendungsladeprozesses
zur IC-Karte gesendet. Das Betriebssystem in den IC-Karten wird
zur Durchführung
eines bestimmten Satzes von Anweisungen in Bezug auf jeden dieser
Befehle programmiert, so dass die IC-Karte mit den Anweisungen vom
Terminal kommuniziert und diese ordnungsgemäß ausführt.
-
In
Schritt 609 wird der Erstellungsbefehl ausgeführt, der
wenigstens die folgenden Tätigkeiten umfasst:
(1) prüfen,
ob ein Anwendungsladezertifikat von der CA signiert (verschlüsselt) ist
und die Anwendung somit als eine ordnungsgemäße Anwendung für das System
authentifiziert; und (2) Prüfen
der auf der Karte gespeicherten Kartenpersonalisierungsdaten anhand
des Genehmigungsprofils für
die zu ladende Anwendung, um die Karte zum Laden zu qualifizieren.
Nach Bedarf können
auch andere Prüfungen
durchgeführt
werden. Verläuft
einer der Checks erfolglos, dann wird eine Störungsantwort 610 gegeben
und der Prozess abgebrochen. Die Anwendung wird nach dem erfolgreichen
Durchlaufen dieser Checks in den Speicher der Karte geladen.
-
7 zeigt
die verschiedenen Schritte des Öffnungsschrittes 601 von 6 ausführlicher.
In Schritt 701 wird ermittelt, ob das Freigabe- (d.h. Steuer-)
Bit gesetzt ist. Dieses Bit wird gesetzt, wenn die Karte ihren Personalisierungsprozess
vollendet hat und ihr die Personalisierungsdaten zugewiesen wurden.
Eine Anwendung kann nur dann auf eine IC-Karte im Kartensystem geladen
werden, wenn die Karte die Personalisierungsdaten enthält. Ist
das Freigabebit nicht gesetzt, dann wurde die Karte nicht personalisiert,
und daher gibt die Karte dem Terminal eine negative Antwort 703.
Ist das Freigabebit gesetzt, dann wurde die Karte freigegeben und
die Testbedingungen werden mit Schritt 711 fortgesetzt.
-
In
Schritt 711 wird geprüft,
ob genügend Platz
im Speicher auf der Karte vorhanden ist, um Anwendungscode und zugehörige Daten
zu speichern. Anwendungen haben typischerweise assoziierte Daten,
die sich auf ihre Funktionen beziehen. Diese Daten werden verwendet
und manipuliert, wenn die Anwendung abgearbeitet wird. Speicherplatz
im Speicher einer IC-Karte ist aufgrund des relativ großen für den EEPROM
benötigten
physikalischen Speicherplatzes und aufgrund der Art und Weise, in
der er in die integrierte Schaltung passt, die klein genug sein
muss, damit sie auf eine Karte mit der Größe einer Kreditkarte passt,
ein ständiges
Anliegen. Ein Beispiel für
die Größe eines
bestimmten EEPROM auf einer IC-Karte ist 16 KB, aber die tatsächliche
Größe variiert.
Anwendungen können
von 1 KB oder weniger für
eine sehr einfache Anwendung bis hin zu verfügbaren Speicherplatzgrößen für höher entwickelte
Anwendungen reichen. Die mit einer Anwendung assoziierten Daten
können
von keinen im Kartenspeicher gespeicherten Daten bis zu einer Größe reichen,
die durch die Menge an verfügbarem Speicherplatz
beschränkt
ist. Diese verschiedenen Größen von
Anwendungscode und Daten nehmen ständig in dem Maße zu, in
dem Anwendungen immer fortschrittlicher und diverser werden.
-
MULTOS
als Betriebssystem ist nicht durch die Anzahl von Anwendungen und
zugehörigen
Daten begrenzt, die es auf der Karte speichern kann. So können fünf Anwendungen
in den verfügbaren
Speicherplatz der Karte passen, der Kartenbenutzer hat weitaus größere Funktionalität, als wenn
nur ein oder zwei Anwendungen auf der Karte gespeichert wären. Wenn
der Speicher einer Karte voll ist, kann jedoch keine neue Anwendung
auf die Karte geladen werden, es sei denn, dass eine andere, ausreichend
große
Anwendung samt ihres Codes und ihrer Daten gelöscht werden kann. Daher ist
das Prüfen
der Menge an verfügbarem
Speicherplatz auf der Karte ein wichtiger Schritt. Wenn nicht genügend Raum
vorhanden ist, wird eine Zuwenig-Platz-Antwort 713 an das
Terminal zurückgegeben.
Der Anwendungslader kann dann entscheiden, ob eine andere existierende
Anwendung auf der Karte gelöscht
werden soll, um für die
neue Anwendung Platz zu machen. Das Löschen ist davon abhängig, ob
der Kartenausgeber ein Anwendungslöschzertifikat von der CA hat.
Wenn genügend
Speicherplatz auf der Karte vorhanden ist, wird der Prozess mit
Schritt 715 fortgesetzt.
-
Nachfolgend
wird ein Beispiel für
das Testen von Speicherplatz in Schritt 711 beschrieben.
Die in diesem Beispiel verwendeten Zahlen sollen den Umfang der
Erfindung in keiner Weise einschränken, sondern dienen nur zum
Illustrieren von Speicherplatzanforderungen. Eine IC-Karte kann
bei der Herstellung zunächst
16 KB an verfügbarem
EEPROM haben. Die für
das Betriebssystem notwendigen Betriebssystemdaten können 2 KB
Speicherplatz einnehmen. Somit wären
14 KB übrig.
Der Code einer Electronic-Purse-Anwendung
wird im EEPROM gespeichert und nimmt 8 KB Speicherplatz ein. Die
von der Purse-Anwendung benötigten
Daten können
zusätzliche
4 KB Speicherplatz im EEPROM einnehmen. Der Speicherplatz, der dann
noch für
andere Anwendungen frei wäre,
betrüge
somit 2 KB (16 KB – 2
KB – 8
KB – 4
KB = 2 KB). Wenn ein Kartenausgeber eine Kredit/Debit-Anwendung
auf die Karte laden möchte,
deren Code in diesem Beispiel eine Größe von 6 KB hat, dann passt
die Anwendung nicht auf den Speicher der IC-Karte. Daher kann die
Anwendung die neue Anwendung nicht laden, ohne zuvor die Purse-Anwendung
von der Karte zu entfernen. Würde
eine neue Kredit/Debit-Anwendung in den EEPROM der IC-Karte geladen,
dann müsste
sie Code oder Daten einer anderen Anwendung überschreiben. Es wird verhindert,
dass der Anwendungslader dies tut.
-
8 zeigt
die Schritte, die beim Ermitteln durchgeführt werden, ob die Personalisierungsdaten der
Karte unter den zulässigen
Satz von Karten fallen, auf die die Anwendung bei der Ausgabe geladen werden
können.
Diese Schritte werden vorzugsweise während der Ausführung des "Erstellen"-Befehls durchgeführt. Diese
Schritte können
jedoch zu jedem beliebigen Zeitpunkt während des Ladens oder Löschens einer
Anwendung durchgeführt
werden. Wie zuvor beschrieben, wird die Karte durch Speichern von
Daten personalisiert, die für
die Karte spezifisch sind (MSM-Personalisierungsdaten),
einschließlich: eine
für eine
individuelle Karte spezifische Karten-ID-Bezeichnung, wobei die
Kartenausgebernummer den Ausgeber der Karte, den Produkttyp der
Karte wie z.B. eine Gold- oder Platinkarte, sowie das Datum angibt,
an dem die Karte personalisiert wurde. Diese Daten kennzeichnen
die Karte eindeutig von allen anderen IC-Karten im System.
-
Demgemäß können Anwendungen
selektiv auf individuellen Karten im IC-Kartensystem auf praktisch
jeder Basis gespeichert werden, einschließlich der folgenden. Eine Anwendung
kann selektiv auf Karten geladen werden, die eine oder mehrere spezifische
Kartennummern enthalten. Eine Anwendung kann selektiv auf eine oder
mehrere Karten geladen werden, die eine vorgegebene Kartenausgeber-ID
enthalten. Ferner kann eine Anwendung nur auf einen vom jeweiligen
Kartenausgeber vorgegebenen Produkttyp geladen werden, und/oder
die Anwendung kann nur auf Karten geladen werden, die ein e) vorgegebene
(s) Personalisierungsdatum oder -datumsserie tragen. Jedes Personalisierungsdatenelement
erlaubt das selektive Laden einer Anwendung auf bestimmte Karten
oder Gruppen von Karten und gewährleistet,
dass Karten ohne die entsprechenden Genehmigungen die Anwendung
nicht empfangen. Je nach Bedarf können außer den vier beschriebenen
auch noch andere Personalisierungsdatentypen verwendet werden.
-
Die
Auswahl von IC-Karten, auf die eine bestimmte Anwendung geladen
werden kann, wird durch die Verwendung von "Anwendungsgenehmigungsdaten" ermöglicht,
die der Anwendung zugewiesen werden und die wenigstens einen Satz
von Karten repräsentieren,
auf die die Anwendung geladen werden kann. Der Satz kann auf praktisch
jedem Faktor basieren, wie z.B. unter anderem: Kartennummer, Kartenausgeber,
Produkttypen und/oder Personalisierungsdaten. Die Personalisierungsdaten
der einzelnen Karte identifizieren zwar typischerweise eine bestimmte
Nummer, einen Kartenausgeber, einen Produkttyp und ein Datum, aber
die Genehmigungsdaten der Anwendung können eine Kartennummer oder
eine Blankogenehmigung, einen Kartenausgeber oder eine Blankogenehmigung
sowie eine Reihe von Produkttypen und Datumsangaben anzeigen.
-
So
könnte
beispielsweise ein Vielflieger-Loyalitätsprogramm
so konfiguriert werden, dass es auf Karten in verschiedenen Produktklassen
geladen und verwendet werden kann, die zu einem Kartenausgeber gehören. Darüber hinaus
können
die Anwendungsgenehmigungsdaten anzeigen, dass das Loyalitätsprogramm
auf Gold- und Platin-Produkttypen
verwendet werden kann, wenn die Karte nach dem Mai 1998 ausgegeben
wurde. Somit wird mit dem MSM-Genehmigungscheck
ermittelt, ob die individuellen Personalisierungsdaten der Karte
im zulässigen
oder genehmigten Satz von Karten enthalten sind, wonach die Anwendung
geladen werden kann. Wenn ja, dann wird die Anwendung geladen.
-
Um
den Vergleichsprozess zu beschleunigen, kann eine alternative Ausgestaltung
das Setzen von einer oder mehreren Genehmigungsdaten auf null beinhalten,
was eine Blankogenehmigung für diese
Daten bedeutet. Wenn z.B. für
den "Kartennummer"-Eintrag in den Anwendungsgenehmigungsdaten
eine Null oder ein anderer Wert, der anzeigt, dass alle Karten unabhängig von
ihrer Nummer geladen werden dürfen,
gesetzt wird, dann weiß das System,
dass keine Karte auf der Basis ihrer Kartennummer zurückgewiesen
wird. Ebenso bestehen, wenn in den Anwendungsgenehmigungsdaten "Issuer ID" eine Null gesetzt
wird, alle Karten den "Ausgeber"-Testvergleich. Dieses
Merkmal bietet höhere Flexibilität beim Wählen von
Gruppen von Karten. Der Null-Indikator könnte auch für andere Genehmigungsdaten
nach Bedarf verwendet werden.
-
Gemäß 8 werden
die einzelnen Genehmigungsdaten in der gezeigten Reihenfolge geprüft, dies
könnte
aber auch in einer anderen Reihenfolge geschehen, da, wenn eine
der Genehmigungen erfolglos verläuft,
verhindert wird, dass die Anwendung auf die geprüfte IC-Karte geladen wird.
Die Genehmigungen werden vorzugsweise in der gezeigten Reihenfolge
geprüft.
In Schritt 801 wird geprüft, ob der Anwendungsgenehmigungs-Produkttypensatz
die im Speicher der Karte gespeicherte Produkttypennummer der Karte
umfasst. Jedem Kartenprodukttyp wird vom Systembetreiber eine Nummer
zugewiesen. Die Produkttypen werden für jeden Kartenausgeber vorgegeben,
weil verschiedene Kartenausgeber verschiedene Produkttypen haben
werden. Die Karten werden selektiv geprüft, um zu gewährleisten,
dass Anwendungen nur auf Karten des autorisierten Produkttyps geladen
werden. Der Anwendungsgenehmigungs-Produkttypensatz kann eine Länge von
32 Byte haben, die mehrere akzeptable Produkttypen beinhalten, oder
er kann eine andere Länge
haben, je nach den Erfordernissen des Systems. Unter Verwendung
der Datenstruktur 505A als Beispiel, würde das Betriebssystem Bit
Nr. 2 in der 256-Bit-Array (32 Byte × 8 Bit pro Byte) prüfen, die
von der 32 Byte langen Anwendungsgenehmigungs-Datenstruktur resultieren. Wenn der
Genehmigungscheck erfolglos verläuft,
gibt die Karte in Schritt 803 eine Störungsmeldung an das Terminal.
Wenn der Produkttypencheck erfolgreich verläuft (wenn Bit Nr. 2 z.B. den Wert
1 hat), dann wird der Prozess mit Schritt 805 fortgesetzt.
-
In
Schritt 805 wird geprüft,
ob der in den Anwendungsgenehmigungen zulässige Kartenausgebernummernsatz
die im Speicher der Karte gespeicherte Ausgebernummer der Karte
enthält
oder ob der Anwendungsgenehmigungs-Ausgeberdatenwert null ist (was bedeutet,
dass alle Karten diesen individuellen Genehmigungscheck bestehen).
Jedem Kartenausgeber wird vom Systembetreiber eine Nummer zugewiesen,
und die Karten werden selektiv geprüft, um zu gewährleisten,
dass Anwendungen nur auf Karten geladen werden, die von autorisierten
Kartenausgebern verteilt wurden. Der Anwendungsgenehmigungs-Kartenausgebernummernsatz
kann eine Länge
von 4 Byte haben, wenn ein Ausgeber designiert ist, oder er kann
länger
sein, je nach den Erfordernissen des Systems. Wenn der Ausgebercheck erfolglos
verläuft,
gibt die Karte eine Störungsmeldung
in Schritt 807 an das Terminal. Verläuft der Check erfolgreich,
dann wird der Prozess mit Schritt 809 fortgesetzt.
-
In
Schritt 809 wird geprüft,
ob der Anwendungsgenehmigungs-Datumssatz das im Speicher der Karte
gespeicherte Datendatum der Karte umfasst. Das Datum, an dem die
IC-Karte personalisiert wurde, wird gespeichert und beinhaltet vorzugsweise wenigstens
den Monat und das Jahr. Die Karten werden selektiv geprüft, um zu
gewährleisten,
dass Anwendungen nur auf Karten mit dem autorisierten Personalisierungsdatum
geladen werden. Der Anwendungsgenehmigungs-Datumssatz kann eine
Länge von
32 Byte haben, die mehrere Daten beinhalten, oder kann eine andere
Länge haben,
je nach den Erfordernissen des Systems. Wenn der Datumsgenehmigungscheck
erfolglos verläuft,
gibt die Karte in Schritt 811 eine Störungsmeldung an das Terminal. Wenn
der Datumscheck erfolgreich verläuft,
wird der Prozess mit Schritt 813 fortgesetzt.
-
In
Schritt 813 wird geprüft,
ob der in den Anwendungsgenehmigungen zulässige Kartennummernsatz die
im Kartenspeicher gespeicherte ID-Nummer der Karte umfasst oder
ob die in den Anwendungsgenehmigungen zulässigen Kartennummerndaten null
sind (was anzeigt, dass alle Karten diesen individuellen Genehmigungscheck
bestehen). Das Testen der Genehmigungen erfolgt an der Karte während der
Ausführung
der Öffnungs-,
Lade- und Erstellungsbefehle. Der Anwendungsgenehmigungs-Kartennummerndatensatz
kann eine Länge von
8 Byte haben, wenn eine Nummer designiert ist, oder er kann länger sein,
je nach den Erfordernissen des Systems. Wenn der Kartennummerncheck
erfolglos verläuft,
gibt die Karte eine Störungsmeldung in
Schritt 815 an das Terminal. Verläuft der Check erfolgreich,
dann wird der Prozess mit Schritt 817 fortgesetzt.
-
Zusammenfassung des IC-Kartensystem-Prozesses
-
9 zeigt
die Komponenten der Systemarchitektur für den Karteninitialisierungsprozess
einer IC-Karte in einem sicheren Multiapplikations-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 Zertifizierungsautorität 111 für das gesamte
sichere Multiapplikationssystem. Der Kartenbenutzer 131 ist
die Person oder Entität,
die die gespeicherten Anwendungen auf der IC-Karte verwenden wird.
So bevorzugt beispielsweise ein Kartenbenutzer möglicherweise eine IC-Karte,
die sowohl eine Electronic-Purse-Anwendung mit elektronischem Bargeld
(z.B. MONDEXTM) als auch eine Kredit/Debit-Anwendung (z.B. die
EMV-Anwendung MasterCard®) auf derselben IC-Karte
hat. Es folgt eine Beschreibung einer Art und Weise, in der der
Kartenbenutzer eine IC-Karte erhalten würde, die die gewünschten
Anwendungen auf sichere Weise beinhaltet.
-
Der
Kartenbenutzer würde
einen Kartenausgeber 113 wie z.B. eine Bank kontaktieren,
die IC-Karten ausgibt, und eine IC-Karte anfordern, auf denen die
beiden Anwendungen im Speicher einer einzelnen IC-Karte resident
sind. Der integrierte Schaltungschip für die IC-Karte würde vom
Hersteller 102 hergestellt und in der Form eines IC-Chips
auf einer Karte zum Kartenausgeber 113 (oder einer für diesen
agierende Entität)
gesendet. Wie oben erörtert
(siehe Schritte 201–209),
werden die Daten während
des Herstellungsprozesses vom Hersteller 102 über einen
Datenkanal zur Karte 107 übertragen 115 und
im Speicher der IC-Karte 107 gespeichert. (In dieser Figur
beschriebene Datenkanäle
könnten
eine Telefonleitung, eine Internet-Verbindung oder ein beliebiges anderes Übertragungsmedium
sein.) Die Zertifizierungsautorität 111, die Verschlüsselungs/Entschlüsselungs-Keys
für das
gesamte System führt, überträgt (117)
Sicherheitsdaten (d.h. den globalen Public-Key) zum Hersteller über einen
Datenkanal, der vom Hersteller zusammen mit anderen Daten auf die
Karte gesetzt wird, wie z.B. den Kartenfreigabe-Key und die Kartenkennung.
Das Multiapplikationsbetriebssystem der Karte wird vom Hersteller ebenfalls
im ROM gespeichert und auf die Karte gesetzt. Nach der anfänglichen
Verarbeitung der Karten werden diese zum Kartenausgeber zur Personalisierung
und zum Laden der Anwendung gesendet.
-
Der
Kartenausgeber 113 führt
zwei separate Funktionen aus oder lässt sie von einer anderen Entität ausführen. Zunächst personalisiert
das Personalisierungsbüro 104 die
IC-Karte 107 auf die oben beschriebenen Weisen, und dann
lädt der
Anwendungslader 106 die Anwendung unter der Voraussetzung,
dass die Karte qualifiziert ist, wie oben beschrieben wurde.
-
Was
die Personalisierung betrifft, so wird ein individualisierter Karten-Key-Set
von der CA generiert und auf der Karte gespeichert (siehe 3).
Der Karte wird ferner eine spezielle Identität unter Verwendung von MSM-Personalisierung
(siehe 3, Schritt 307, und 5)
gegeben. Diese enthält
eine Karten-ID-Nummer, eine Ausgeber-ID-Nummer, die den Kartenausgeber
identifiziert, der die Karte verarbeitet hat, eine Kartenprodukttypennummer,
die vom Kartenausgeber vorgegeben wird, und das Datum, an dem die
Personalisierung stattfand. Nach dem Personalisieren der Karte müssen Anwendungen
auf die Karte geladen werden, damit die Karte die gewünschten
Funktionen ausführen
kann.
-
Der
Anwendungslader 106, der denselben Terminal oder Datenkanal
verwenden könnte
wie das Personalisierungsbüro 104,
muss zunächst
ermittelt haben, ob die Karte zum Akzeptieren der Anwendung qualifiziert
ist. Dieser Vergleich fand auf der Karte selbst (von dessen Betriebssystem
angewiesen) unter Verwendung der Genehmigungsinformationen statt.
Die Karte lädt
somit, wenn sie qualifiziert ist, selektiv die Anwendung auf sich
selbst auf der Basis der Identität
der Karte und der Anweisungen des Kartenausgebers. Der Anwendungslader
kommuniziert (119) mit der IC-Karte über einen Terminal oder über einen
anderen Datenkanal. Nach dem Laden der Anwendungen auf die Karte
wird diese dem Kartenbenutzer 109 für den Gebrauch zugestellt.
-
Das
hierin beschriebene sichere Multiapplikations-IC-Kartensystem ermöglicht das selektive Laden
und Löschen
von Anwendungen zu jedem beliebigen Zeitpunkt im Lebenszyklus der
IC-Karte nach deren Personalisierung. Somit könnte ein Kartenbenutzer auch
eine personalisierte Karte ohne Anwendungen empfangen und dann eine
gewünschte
Anwendung über
eine allgemeine Übertragungsleitung
wie z.B. eine Telefonleitung oder eine Internet-Verbindung wählen.
-
10 ist
ein Systemdiagramm von Entitäten,
die an der Verwendung einer IC-Karte nach deren Personalisierung
beteiligt sind. Das System beinhaltet eine IC-Karte 151,
einen Terminal 153 und eine Anwendungslade-/-löschentität 155,
die Zertifizierungsautorität 157,
einen Kartenausgeber 171 und andere IC-Karten 159 in
dem System. Die Pfeile zeigen Kommunikationen zwischen den jeweiligen
Entitäten
an. Die CA 157 erleichtert das Laden und Löschen von
Anwendungen. Nach dem Bereitstellen der MSM-Genehmigungsdaten und des kartenspezifischen
Key-Set zur Karte während
der Kartenfreigaben lässt
es die CA zu, dass Anwendungen später geladen und gelöscht werden,
vorzugsweise durch Ausgeben eines Anwendungszertifikats. Anwendungsspezifische
Schlüssel
werden für
die Authentifizierung von Kommunikationen zwischen einer Karte und
einem Terminal benötigt.
Die IC-Karte 151 kann auch mit anderen IC-Karten 159 kommunizieren.
Der Kartenausgeber 171 ist an allen Entscheidungen des Ladens
und Löschens
von Anwendungen für
eine Karte beteiligt, die er ausgegeben hat. Alle Kommunikationen
werden authentifiziert und sicher in dem System übertragen.
-
So
verwendet beispielsweise die IC-Karte 151 das folgende
Verfahren, um eine neue Anwendung auf die Karte zu laden. Die IC-Karte 101 ist
mit dem Terminal 153 verbunden, und der Terminal fordert
das Laden einer Anwendung an. Der Terminal 153 kontaktiert
die Anwendungslade-/-löschentität 155,
die infolge dessen und in Verbindung mit dem Kartenausgeber 171 Anwendungscode,
Daten und Anwendungsgenehmigungsdaten (zusammen mit eventuellen
weiteren notwendigen Daten) zum Terminal 153 sendet. Der
Terminal 153 fragt dann die Karte 151 ab, um zu gewährleisten,
dass sie die richtige Karte ist, auf die die Anwendung geladen werden darf.
Wenn die IC-Karte die oben beschriebenen Checks besteht, wird die
Anwendung auf die Karte 151 geladen. Die CA 157 gibt
das Anwendungslade- oder – löschzertifikat
aus, das es ermöglicht,
dass die Anwendung auf die Karte geladen oder von dieser gelöscht wird.
Dieses Beispiel zeigt eine Art und Weise des Ladens der Anwendung,
aber es sind auch Variationen nach denselben Prinzipien möglich, wie beispielsweise
ein direktes Laden der Anwendung bei der Anwendungslade-/-löschentität 155.
-
Die
obigen Ausführungen
illustrieren lediglich die Grundsätze der Erfindung. Es ist klar,
dass Fachpersonen in der Lage sein werden, zahlreiche Systeme und
Methoden zu erdenken, die, auch wenn sie nicht ausdrücklich hier
gezeigt oder beschrieben wurden, die Grundsätze der Erfindung ausgestalten und
somit in den Umfang der Erfindung gemäß Definition in den beiliegenden
Ansprüchen
fallen.
-
Es
ist beispielsweise verständlich,
dass die MSM-Personalisierungs-
und Genehmigungsdaten nicht nur zum Laden von Anwendungen auf IC-Karten,
sondern auch zum Löschen
von Anwendungen von den genannten Karten verwendet werden können. Dieselben
Checks, die MSM-Genehmigungen und das Laden von Anwendungen involvieren,
werden zum Löschen
von Anwendungen durchgeführt. Ein
Löschzertifikat
von der CA, die das Löschen
einer Anwendung autorisiert, kontrolliert, von welchen Karten die
Anwendung gelöscht
werden darf. Dies erfolgt über
die Personalisierungsdaten, die auf jeder IC-Karte gespeichert sind,
und den hierin beschriebenen Genehmigungscheck.
-
Ferner
können
die Daten auch auf Personal Computer oder andere Geräte angewendet
werden, auf die Anwendungen geladen werden können, die nicht physikalisch
auf Karten geladen werden. Außerdem
können
die Genehmigungsdaten der Anwendung tatsächlich Daten beinhalten, die
für einen
Satz oder für
Sätze von
Karten repräsentativ
sind, die ausgeschlossen anstatt eingeschlossen werden sollen, d.h.
Karten, auf die die Anwendung nicht geladen werden kann.