-
HINTERGRUND
DER ERFINDUNG
-
Integrierte Schaltungskarten (IC-Chipkarten) werden
in zunehmendem Maße
für viele
verschiedene Zwecke in der modernen Welt eingesetzt. Eine IC-Karte
hat typischerweise die Größe einer
herkömmlichen
Kreditkarte, in die 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 sonstige Schaltungen zum Unterstützen des Mikroprozessors bei
seiner Arbeit. Eine IC-Karte kann ein oder mehrere Anwendungen im
Speicher enthalten. Ein Anwendungslader ist die Entität, die die
Anwendung auf die Karte lädt.
Der Anwendungslader kann der eigentliche Entwickler der Anwendung
oder ein Dritter sein.
-
Die WO-A-88/09019 offenbart einen
Mikroprozessor mit Speicher- und Schnittstellenfähigkeiten. Mittels einer Speichermanagementroutine
können
verschiedene Objekte in der Karte vor einem unbefugten oder unsachgemäßen Zugriff
durch ein Anwendungsprogramm geschützt werden. Auf der Karte sind
Sicherheitsflags in Bezug auf Datendateien gespeichert. Diese werden
in den Datendateien selbst gespeichert, die Teil des Datei-Headers
bilden (siehe Seite 16, Zeilen 31 bis 33). Während der Ausführung eines
Anwendungsprogramms kann sich der Zustand der Sicherheitsflags ändern. Dieses
System dient zum Schützen
von Daten sowie zum Gewährleisten,
dass nur zu den richtigen Zeiten auf die Daten zugegriffen wird.
-
MULTOSTM ist
ein Mehranwendungsbetriebssystem, das auf IC-Karten, zwischen anderen Plattformen,
läuft und
es zulässt,
dass mehrere Anwendungen auf der Karte selbst abgearbeitet werden.
So kann ein Kartenbenutzer mehrere in der Karte gespeicherte Programme
(z. B. Kredit/Debit, elektronisches) Geld/Geldbörse und/oder Treueanwendungen)
unabhängig
vom Terminal-Typ (d. h. ATM, Telefon und/oder Point-of-Sale) abarbeiten,
in dem die Karte für
den Gebrauch eingeführt
wird. Von höchster
Bedeutung beim Gebrauch einer solchen Karte ist die Sicherheit,
und der Betreiber eines Kartensystems ermöglicht es, dass Karten auf
sichere Weise mit Terminals oder anderen Karten kommunizieren. Der
Betreiber verwaltet auch das Laden und Löschen von Anwendungen auf die/von
den Karten, sowie die kryptografischen Schlüssel, die das System sicher
machen.
-
IC-Karten haben typischerweise aufgrund von
Größen- und Kostenbeschränkungen
des Platzierens von Speicher auf der Karte eine begrenzte Speicherkapazität. Anwendungen
für Mehranwendungs-Smart-Cards
werden in Programmiersprache geschrieben und gewöhnlich im EEPROM gespeichert,
dessen Inhalt sich im Laufe der Lebenszeit der Karte ändern kann.
Ein Beispiel für
eine in IC-Karten verwendete Programmiersprache ist die Multos Executable
Language MELTM. Die MEL-Programmanweisungen
werden vom EEPROM gelesen, wenn sie ausgeführt werden, und werden von
dem im ROM gespeicherten Betriebssystem interpretiert.
-
Der ROM auf der IC-Karte beinhaltet
das im Assemblersprachcode geschriebene Betriebssystem für die jeweilige
IC-Konfiguration (maschinenabhängige
Sprache). Der im ROM gespeicherte Betriebscode ist beim anfänglichen
Schreiben des ROM fest, und die im ROM gespeicherten Informationen ändern sich
im Leben der Karte nicht.
-
Im ROM können sich auch Subroutinen,
so genannte Grundstrukturen, befinden, die in einer maschinenabhängigen Sprache
für den
Mikroprozessor geschrieben sind und die entweder vom Betriebssystem
selbst oder von Anwendungen bei deren Ausführung aufgerufen werden können. Grundstrukturen sind
in der maschinenabhängigen
Sprache (d. h. Assembler-Sprache)
geschrieben, so dass sie sehr schnell ausgeführt werden können und
nur eine minimale Interpretation der Anweisungen für die Ausführung nötig ist.
Diese Grundstrukturen sind Sammlungen von Anweisungen, die gewöhnlich eine
gewünschte
Funktion ausführen,
wie z. B. eine mathematische oder kryptografische Funktion. Die
Anweisungen ändern
sich während
der Lebenszeit der Karte nie. Eventuelle Daten, die von den Grundstrukturen
benutzt werden oder auf die diese zugreifen, sind im EEPROM gespeichert,
so dass der Inhalt der Datenelemente nach Bedarf geändert werden
kann.
-
Im MULTOSTM System
können
Anwendungen auf der Karte gespeicherte Grundstrukturen abrufen,
die dann vom Betriebssystem ausgeführt werden. Wenn beispielsweise
in einer Anwendung zwei Zahlen dividiert werden müssen, dann
kann die Anwendung die "Division"-Grundstruktur abrufen
und die Operanden für
die Funktion bereitstellen, und die Grundstruktur führt die
Berechnung aus. Jede Anwendung auf der Karte hat die Fähigkeit,
die Divisionsgrundstruktur durch Ausführen einer "auf Divisionsgrundstruktur zugreifen" Anweisung abzurufen. Während einige
Grundstrukturen für
praktisch alle Anwendungen notwendig sind, wie z. B. mathematische
Grundformeln oder fundamentale Datenrückspeicherungen, sind einige
Grundstrukturen fakultativ und nur für den Gebrauch durch einige
Anwendungen beabsichtigt. So können
beispielsweise sicherheitsbezogene Grundstrukturen, die Daten ver/entschlüsseln, von
einigen Anwendungen ja (z. B. einer Bankanwendung), aber von anderen
(z. B. einer Air-Miles- oder
Unterhaltungsanwendung) aufgrund der Erfordernisse der jeweiligen
Anwendung nicht verwendet werden.
-
Darüber hinaus können externe Überlegungen
die zulässige
Verwendung einiger Grundstrukturen durch eine Anwendung beeinflussen.
Diese Überlegungen
würden
erfordern, dass der Betreiber des Kartensystems die Kontrolle über den
Zugriff auf bestimmte Grundstrukturen durch einzelne Anwendungen
hat (d. h. einen solchen Zugriff verhindert). Eine solche Überlegung
wäre die
Besorgnis eines Landes in Bezug auf starke Verschlüsselungsalgorithmen
für bestimmte
Typen von Anwendungen, die in dem Land verwendet und aus dem Land
exportiert werden. So könnte
beispielsweise Großbritannien den
Export eines Verschlüsselungsalgorithmus,
der Teil einer Grundstruktur ist, aus dem Land zulassen, wenn der
Algorithmus für
eine Bankfunktion verwendet wird. Wenn der Verschlüsselungsalgorithmus
jedoch auf allgemeine Daten wie z. B. Gesundheitsinformationen angewendet
wird, dann diktiert möglicherweise
die öffentliche
Politik Großbritanniens, dass
der Verschlüsselungsalgorithmus
nicht außerhalb
seiner Grenzen verwendet wird. Somit wäre es vorteilhaft, die Verschlüsselungsgrundstruktur
für diese
Anwendung zu sperren, wenn es die Gesetze eines Landes verbieten,
dass dieser Datentyp verschlüsselt
und exportiert wird. Diese selektive Freigabe von Grundstrukturen
für einzelne
Anwendungen wäre
ein leistungsstarker Mechanismus zum Regulieren des Kartensystems.
-
Es gibt weitere Gründe, um
einen selektiven Zugriff auf verschiedene Grundstrukturen zu ermöglichen.
So wäre
es insbesondere wünschenswert,
eine Zugriffsprüfung
für verschiedene
Grundstrukturen zu haben, um selektiv Grundstrukturen freigeben,
je nach den Erfordernissen des Kartensystembetriebs und/oder der
Provider der Anwendungen, die auf dem System laufen. So könnte beispielsweise
ein "Zugriffsflag" eines E/A-Ports
geprüft
werden, wenn eine gewählte
Grundstruktur aufgerufen wird. Die meisten IC-Karten können derzeit Informationen
mit einem Terminal austauschen, indem ein E/A-Port an der Karte
physisch mit dem Terminal verbunden wird. Die auf der Karte befindlichen Kontakte
werden physisch gegen die Kontakte des Terminals gedrückt, so dass
ein elektrisches Signal zwischen Karte und Terminal passieren kann.
Jüngere
Entwicklungen lassen es zu, dass eine IC-Karte mit einem Terminal
kommuniziert, ohne dass ein physischer Kontakt zwischen Karte und
Terminal hergestellt wird. Der Austausch von Informationen erfolgt über Radiofrequenz-(RF-) Wellen,
zelluläre
Signale oder andere übertragene Signale.
Für kontaktlose
Karten befindet sich eine Antenne auf der Karte, die die Übertragungssignale sendet
und empfängt.
IC-Karten können
sowohl physische Kontakte als auch Antennen für eine drahtlose Kommunikation
beinhalten. Die kontakt- oder drahtlose Übertragung von Informationen
ist zwar für
den Karteninhaber vorteilhaft, da die Zeit für die gesamte Transaktion verkürzt wird,
aber die Übertragungssignale
können
leichter von Dritten abgefangen werden als bei einer physischen
Verbindung. Infolgedessen möchte
der Betreiber des Kartensystems bestimmte Anwendungsprogramme wie
Finanztransaktionen möglicherweise
auf physische Verbindungen beschränken.
-
Es ist daher eine Aufgabe einer Ausgestaltung
der Erfindung, eine Mehranwendungskarte mit der Fähigkeit
bereitzustellen, den Zugriff auf die Grundstrukturen zu regulieren
und es zuzulassen, dass der Kartensystembetreiber eine Grundstruktur für eine bestimmte
Anwendung freigibt oder sperrt oder einen Zugriff darauf verhindert.
-
Aspekte der Erfindung sind in den
unabhängigen
Ansprüchen
1, 5 und 12 offenbart.
-
ZUSAMMENFASSUNG
DER ERFINDUNG
-
Die Anmelder haben somit ein System
und ein Verfahren zum Regulieren des Zugriffs auf Computercode und
insbesondere, aber nicht ausschließlich, auf in einer Mehranwendungs-IC-Karte
eingebettete Grundstrukturen bereitgestellt. Die Anmelder haben
festgestellt, dass eine Möglichkeit,
dieses Ziel zu erreichen, in der Verwendung von "Zugriffsflags" besteht, die, wie nachfolgend ausführlicher
erläutert wird,
in Bits gesetzt werden, um entweder anzuzeigen, dass eine Grundstruktur
(z. B. eine Verschlüsselungsgrundstruktur)
für eine
bestimmte Anwendung zugängig
ist (wenn beispielsweise das Bit auf 1 gesetzt ist) oder nicht (wenn
das Bit auf 0 gesetzt ist). Bei einer verschlüsselungsbezogenen Grundstruktur kann
der "Zugriffsflag" auch als "Krypto-Flag" bezeichnet werden.
-
E/A-bezogene Zugriffsflags können auch verwendet
werden, um den Zugriff auf die kontaktlosen Grundstrukturen für finanzielle
Anwendungen zu verhindern. Die E/A-Zugriffsflags würden vom Kartensystembetreiber
kontrolliert und gesetzt und vom Anwendungslader gemeinsam mit der
Anwendung auf die Karte geladen. Dieser Zugriffsflag würde es zulassen,
dass der Betreiber des Kartensystems verhindert, dass eine finanzielle
oder andere gewählte Anwendung
die kontaktlose Grundstruktur benutzt, so dass eine physische Verbindung
für eine
Terminal-Kommunikation notwendig wäre.
-
Zugriffsflags, die auf der Karte
gespeichert und vom Betriebssystem geprüft werden, erlauben es, dass
der Betreiber des Kartensystems den Zugriff auf selektive Grundstrukturen
oder andere Subroutinen kontrolliert, indem der Status des Zugriffsflags vor
der Ausführung
der Grundstruktur oder Subroutine geprüft wird. Auch mit anderen Subroutinen,
wie z. B. Codelets (Subroutinen, die in einer Anwendungssprache
wie MEL geschrieben sind), Subroutinen im Betriebssystem selbst
oder mit anderen Typen von Subroutinen, könnten Zugriffsflags assoziiert
sein. Das Prüfen
des Zugriffsflags erfolgt vorzugsweise durch das Betriebssystem,
wenn eine spezifische Subroutinen-Abrufanweisung von einer Anwendung oder
einer anderen Anweisung ausgeführt
wird. Je nach den Ergebnissen der Zugriffsflag-Prüfung führt die
Anwendung dann entweder die fragliche Grundstruktur oder Subroutine
aus oder führt
eine andere Reihe von Anweisungen aus, wenn der Zugriff verweigert
wird.
-
Die Zugriffsflags werden mit Anwendungssteuerdaten
gespeichert, die im EEPROM gespeichert werden, wenn die Anwendung
auf die Karte geladen wird. Die Vorgabeeinstellung des Flags ist
vorzugsweise vor dem Laden "nicht
freigegeben", aber der
Betreiber des Kartensystems kann den Flag bei Bedarf auf logisch "1" setzen, um "freigegeben" anzuzeigen. Wenn beispielsweise eine
Anwendung so programmiert ist, dass eine starke Verschlüsselungssubroutine
in Land B abgerufen wird, das sich außerhalb von Land A befindet,
wo der Algorithmus entwickelt wurde, dann wäre es möglich, dass der Anwendungsprovider
vom Kartensystembetreiber aufgefordert wird, ein Zertifikat aus
dem Land vorzulegen, in dem die Karte benutzt werden soll, das zeigt,
dass der Anwendungsprovider die Genehmigung der Regierung von Land
A (Exportlizenz) und Land B (Gebrauchslizenz) hat, die Verschlüsselungsgrundstruktur
zu benutzen. Nach Vorlage des Zertifikats gibt der Kartenbetreiber
das Zugriffsflag-Bit frei. In diesem Fall könnte der "Zugriffsflag" auch "Krypto-Flag" genannt werden, weil er sich auf Verschlüsselung
bezieht.
-
KURZE BESCHREIBUNG 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
im Leben einer Mehranwendungs-IC-Karte in einem sicheren System
zeigt;
-
2 eine
IC-Karte, die in Verbindung mit Ausgestaltungen der vorliegenden
Erfindung verwendet werden kann;
-
3 ein
Funktionsblockdiagramm der in 2 gezeigten
integrierten Schaltung;
-
4 eine
Bitmap einer Anwendungssteuerdatenstruktur gemäß einer Ausgestaltung der vorliegenden
Erfindung; und
-
5 ein
Ablaufdiagramm eines Verfahrens zum Steuern des Zugriffs auf Computercode.
-
In allen Figuren wurden, wo nicht
anders angegeben, dieselben Bezugsziffern und Zeichen zur Bezeichnung
gleichartiger Merkmale, Elemente, Komponenten oder Teile der illustrierten
Ausgestaltungen verwendet. Außerdem
werden zwar nachfolgend Ausgestaltungen des erfinderischen Gegenstands
auführlich
mit Bezug auf die Figuren beschrieben, aber dies geschieht in Verbindung
mit den illustrativen Ausgestaltungen. Es ist vorgesehen, dass Änderungen
und Modifikationen an den beschriebenen Ausgestaltungen vorgenommen
werden können, ohne
vom wahren Umfang und Wesen der vorliegenden Erfindung gemäß Definition
durch die beiliegenden Ansprüche
abzuweichen.
-
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN
AUSGESTALUNG
-
1 zeigt
die drei Schritte zur Bereitstellung einer funktionsfähigen Mehranwendungs-IC-Karte
in einem sicheren System. Der erste Schritt ist die Kartenherstellung 101.
Im zweiten Schritt, Personalisierung 103, werden Kartenpersonalisierungsdaten
(auch Entität-Authentifizierungsdaten
genannt) auf die Karte geladen. Der dritte Schritt ist das Laden
der Anwendung 105. Dabei wird geprüft, ob eine Karte zur Aufnahme
einer Anwendung qualifiziert ist, d. h. wenn die Persönlichkeitsdaten
anhand der Anwendungszulassungsdaten in Verbindung mit der zu ladenden
Anwendung geprüft werden.
Jeder dieser drei Schritte ist ausführlich in der mitanhängigen Anwendung
mit der Seriennummer 09/076,551 beschrieben, die hierin als Anhang
A enthalten ist.
-
2 illustriert
eine Karte 106, die IC-Technologie ausgestaltet, die mit
Ausgestaltungen der hierin beanspruchten Erfindung angewendet werden kann.
Karte 106 sieht ähnlich
aus wie eine herkömmliche
Kreditkarte, aber beinhaltet auch eine integrierte Schaltung (IC) 108,
die einen Mikroprozessor sowie elektrische Kontakte 110 für die Kommunikation zwischen
IC 108 und Geräten
außerhalb
der Karte 106 enthält.
Karte 106 kann z. B. als Kreditkarte, als Debitkarte und/oder
als elektronische Cash-Karte verwendet werden, d. h. als eine Karte
mit einem Geldwert, der übertragen
werden kann, wenn der Karteninhaber Einkäufe tätigt, wie z. B. eine MONDEXTM Cash-Karte.
-
3 zeigt
ein Funktionsblockdiagramm des IC-Teils 108 und enthält wenigstens
eine Verarbeitungseinheit 112 und eine Speichereinheit 114.
Die IC 108 beinhaltet auch vorzugsweise Steuerlogik 116,
einen Timer 118 sowie Ein/Ausgabeports 120. Der
IC-Teil 108 beinhaltet auch einen Koprozessor 122.
Die Steuerlogik 116 stellt in Verbindung mit der Verarbeitungseinheit 112 die
notwendige Steuerung zum Handhaben von Kommunikationen zwischen der
Speichereinheit 114 (mit ROM 124, EEPROM 126 und
RAM 128 sowie Ein-/Ausgabeports 120) bereit. Der
Timer 118 erzeugt ein Synchronisierreferenzsignal für Verarbeitungseinheit 112 und
Steuerlogik 116. Der Koprozessor 122 bietet die
Fähigkeit, komplexe
Rechnungen in Echtzeit durchzuführen, wie
z. B. solche, die von kryptografischen Algorithmen benötigt werden.
-
4 zeigt
ein Beispiel für
die Anwendungssteuerdatenstruktur 401, zuweilen als Bitmap bezeichnet,
die sich vorzugsweise im EEPROM befindet und mehrere Zugriffsflags
für eine
bestimmte Anwendung enthält,
die auf eine IC-Karte geladen wurde. Die Bitmap befindet sich vorzugsweise
im EEPROM mit der Anwendung, obwohl sie sich auch im ROM befinden
könnte,
wenn die Zugriffsflags vor dem Zeitpunkt ermittelt wurden, an dem
die Daten auf den ROM geschrieben wurden. Die Daten 401 zeigen
8 Bits (ein Byte) von Daten, die im Speicher der Karte gespeichert
sind. Die Länge
der Bitmap kann mit der Länge
von verfügbaren
Bits variabel sein, je nach der jeweiligen Anwendung und dem System,
auf dem sie läuft.
Im vorliegenden Beispiel entspricht Bit 403 einem Krypto-Flag
in Verbindung mit einer Verschlüsselungsgrundstruktur,
die oben beschrieben wurde. Das Krypto-Flag-Bit wird auf "1" gesetzt, wenn die Verschlüsselungsgrundstruktur
für die
jeweilige Anwendung freigegeben wird, und wird auf "0" gesetzt, wenn die Grundstruktur nicht
freigegeben wird. Der Vorgabezustand in der bevorzugten Ausgestaltung
ist immer "0", d. h. nicht freigegeben. Dadurch
wird gewährleistet,
dass die Genehmigung zum Ausführen
einer gewählten
Grundstruktur nur dann gegeben wird, wenn dies vom Betreiber des Kartensystems
beim Laden der Anwendung explizit eingestellt wird. In anderen Systemen
könnte
die Vorgabe jedoch "1" oder freigegeben
sein, es sei denn, der Betreiber des Kartensystems sperrt die Karte
explizit.
-
Das kontaktlose E/A-Zugriffsflag-Bit,
ebenfalls oben beschrieben, ist als Bit 405 dargestellt.
Dieses Bit wird geprüft,
wenn kontaktloser Betrieb (z. B. eine Grundstruktur) von einer Anwendung
abgerufen wird. Der kontaktlose Betrieb kann beispielsweise aus
allen Anweisungen bestehen, die zum Senden und Empfangen von drahtlosen
Signalen benötigt werden,
oder er kann ein benötigter
Teil dieser Anweisungen sein. Wenn das kontaktlose Bit 406 auf "1" gesetzt ist, dann kann der Betrieb
ausgeführt
werden, und wenn das kontaktlose Bit 405 auf "0" gesetzt ist, dann kann der kontaktlose
Betrieb nicht ausgeführt
werden.
-
Andere unterschiedliche E/A-Ports
können ebenfalls
einen Zugriffsflag haben. Der kontaktlose Zugriffsflag kann auch
zusätzliche
Flags für
eine verfeinerte Regulierung haben, einen RF-Signalzugriffsflag
und ein zelluläres
Zugriffssignal. So ist beispielsweise ein weiteres, in 4 gezeigtes Zugriffsflag-Bit das
Application Program Interface (API) Bit 407. Dieses Bit
kann steuern, ob eine Anwendung von einer auf der Karte gespeicherten
spezifischen API abgearbeitet werden kann. So kann eine Karte beispielsweise
eine MEL-API und eine zweite Betriebssystem-API enthalten. Das API-Bit
kann Anwendungen darauf beschränken,
die MEL API zu verwenden, oder sie kann die Karte befähigen, die
API des zweiten Betriebssystems zu verwenden. Die Verwendung der
API des zweiten Betriebssystems durch die jeweilige Anwendung kann
eine ausgegebene Lizenz vom Inhaber des zweiten Betriebssystems
erfordern, und der API-Flag kann den Gebrauch der Karte mit der
zweiten API beschränken,
es sei denn, eine Lizenz wird erworben. Der Systembetreiber kann
weitere Zugriffsflag-Bits 409 definieren.
-
4 zeigt
zwar mehrere Zugriffsflags, aber die Anwesenheit von wenigstens
einem Zugriffsflag ist vorteilhaft, und die Gesamtzahl der Zugriffsflags kann
auf System oder Benutzer zugeschnitten werden. Darüber hinaus
ist, obwohl ein Krypto-Flag ein wichtiges Merkmal für die IC-Karte
ist, die eine Ausgestaltung der Erfindung ist, ein Krypto-Flag nicht
unbedingt einer der Zugriffsflags. Welcher Zugriffsflag was kontrolliert,
wird vom Systembetreiber bestimmt. 4 zeigt
zwar eine bevorzugte Bitdarstellung von einem Bit für jeden
Zugriffsflag, aber die Datenorganisation kann anders sein, z. B.
Verwenden der Zugriffsliste als Indexregister, um auf die richtigen Flag-Daten zu zeigen.
-
Jede Anwendung hat ihre eigenen zugehörigen Bitmap-Listendaten, wie
in 4 gezeigt ist. Die Bitmap-Daten,
die die Zugriffsflags enthalten, werden mit anderen Anwendungsladeinformationen
während des
Ladens der Anwendung auf die Karte geladen. Vor der Zugriffsliste
kann ein Feld stehen, das die Länge
der Bitmap vorgibt, was eine Zugriffsliste variabler Länge ermöglicht.
Wenn die Werte auf der Bitmap festgelegt sind, werden diese nicht
mehr verändert,
um eventuelle unzulässige
Eingriffe in die Flag-Daten
minimal zu halten.
-
Nachfolgend wird beschrieben, wie
das Betriebssystem prüft,
ob ein Zugriffsflag-Bit gesetzt ist, wenn eine Anwendung versucht,
eine Grundstruktur mit zugehörigem
Zugriffsflag abzurufen. In diesem Beispiel endet, wenn der zugehörige Flag
auf "0" gesetzt ist und
die Grundstruktur aufgerufen wird, die Ausführung anormal (abend). Das
Beispiel illustriert insbesondere die Verwendung eines Krypto-Flags.
-
Es wird ein Mechanismus benötigt, in
der Form einer Bitmap, mit dem der Zugang zu den kryptografischen
Grundstrukturen gewährt
oder beschränkt
werden kann, die einer Anwendung von einer MULTOSTM Implementation
geboten werden. Zugang zu den kryptografischen MULTOSTM Grundstrukturen
mit "beschränktem Zugang" wird nur denjenigen
Entwicklern gewährt,
die Dokumente vorweisen, die besagen, dass sie die Genehmigung der
entsprechenden Regierungsbehörden
haben, auf diese kryptografischen Zugriffsstrukturen zuzugreifen.
-
Eine Interaktion zwischen der Karte
mit einem Kartenausgeber (der typischerweise die Entität ist, die
das Laden einer Anwendung anfordert) in einem Mehranwendungskartensystem
erfolgt durch die Bereitstellung eines Application Load Certificate ("ALC") (in Anhang A beschrieben,
der hierin durch Bezugnahme eingeschlossen ist), das während des mit
Bezug auf 1 beschriebenen
Personalisierungsvorgangs auf die Karte geladen wird. Das Application
Load Certificate kann Zugriffsflag-Daten für eine bestimmte Anwendung
enthalten, die eine Bitmap (oder einen Flag) mit einer Anwendung
in einer integritätsgeschützten Weise
assoziiert.
-
Im ALC wird ein Datenelement benutzt,
vorzugsweise als "Zugriffsliste" bezeichnet, um anzuzeigen,
ob Zugang zu einer bestimmten Grundstruktur möglich ist oder nicht. Spezifischer
ausgedrückt,
wird vorzugsweise ein einzelnes Bit benutzt, um den auf der IC-Karte
gespeicherten "Zugriffslisten"-Flag anzuzeigen,
obwohl auch andere Datenkonfigurationen möglich sind. Wenn also eine
Anwendung versucht, auf eine beschränkte (unverfügbare) kryptografische Grundstruktur
zuzugreifen (z. B. ein "Zugriffslisten"-Wert für diese
Grundstruktur in Bezug auf die ablauffähige Anwendung ist 0), dann
bricht der Vorgang anormal ab. Im Abend-Fall kann die Ausführung des
gerade laufenden Anwendungsprogramms unterbrochen und eine Fehlermeldung
zu einem Display-Terminal gesendet werden, wenn ein solcher mit der
IC-Karte verbunden ist. Ansonsten wird Zugang gewährt, der
Programmieranweisungssatz der Grundstruktur wird ausgeführt, und
danach setzt die Anwendung die Ausführung ihrer Anweisungen fort.
-
5 zeigt
ein Ablaufdiagramm der Schritte zum Implementieren eines Verfahrens
zum Steuern des Zugriffs auf Computercode in einer IC-Karte. Schritt 501 speichert
eine Anwendung auf einer IC-Karte. Die Anwendung kann bei der Herstellung oder
vorzugsweise während
eines in 1 geschriebenen
Personalisierungsvorgangs auf der Karte gespeichert werden. Die
IC-Karte beinhaltet ein Mehranwendungsbetriebssystem, das es zulässt, dass der Mikroprozessor
auf der Karte mehrere auf der Karte gespeicherte Anwendungen ausführt.
-
Schritt 503 speichert einen
Zugriffsflag in Bezug auf eine Grundstruktur oder einen anderen
Satz von Programmieranweisungen für eine oder mehrere auf der
IC-Karte gespeicherte
Anwendungen. Der Zugriffsflag kann vor dem Laden der Anwendung gleichzeitig
mit dem Laden der Anwendung oder nach dem Laden der Anwendung gespeichert
werden. Zur Erzielung maximaler Sicherheit wird der Zugriffsflag
bei der Herstellung auf Festwertspeicher gespeichert und kann nicht
verändert
werden. Alternativ kann der Zugriffsflag in programmierbarem Speicher
gespeichert werden, der geändert
werden kann, um die Karte in Bezug auf die einzelnen Anwendungen
zu personalisieren, die auf die IC-Karte geladen werden, und um
die Fähigkeit
zu haben, die Zugriffsflags zu beseitigen, wenn und falls eine Anwendung
von der Karte gelöscht
wird. So erhält
möglicherweise
ein Anwendungsprovider mit Bezug auf einen kryptografischen Zugriffsflag
die Genehmigung zum Exportieren und Importieren bestimmter Kryptografiedaten,
die als Grundstruktur gespeichert sind, nachdem eine Anwendung auf
die Karte geladen wurde. In diesem Fall kann der Zugriffsflag geändert werden,
wenn der den Zugriffsflag speichernde Speicher veränderbar
ist.
-
In Schritt 505 wird eines
der auf der Karte gespeicherten Anwendungsprogramme abgearbeitet (z.
B. eine Kredit/Debit-Anwendung). Wenn die Programmanweisungen in
der ablaufenden Anwendung verlangen, dass in Schritt 507 auf
eine Grundstruktur zugegriffen wird, dann prüft das auf der IC-Karte befindliche
Betriebssystem zunächst
den Zugriffsflag in Verbindung mit der jeweiligen Grundstruktur
oder Funktion. Jede Grundstruktur kann verschiedene Zugriffsflags
für jede
Anwendung oder Gruppe von Anwendungen haben, so dass einer Anwendung
der Zugriff gestattet werden kann und einer zweiten Anwendung nicht.
Mit den Zugriffsflags erhält
der Verwalter des Mehranwendungskartensystems einen wichtigen Kontrollmechanismus über den
Zugriff auf gewählte
Grundstrukturen.
-
Schritt 509 prüft den Zustand
des entsprechenden Zugriffsflags in Schritt 509. Wenn der
Zugriffsflag anzeigt, dass der Zugriff verweigert wird (z. B. der
Wert des Zugriffsflags ist null), dann endet die Ausführung der
Anwendung in Schritt 511 anormal (abend). Dem Kartenbenutzer
kann eine Fehlermeldung angezeigt werden, die den Grund für den Abend
angibt. Alternativ kann die Anwendung über ihre Programmieranweisungen
entweder für
eine positive oder eine negative Zugriffsflag-Prüfung programmiert werden und
gewählte
Teile des Programms als Reaktion auf den Wert des Zugriffsflags ausführen.
-
Wenn der Zugriffsflag auf einen positiven Wert
gesetzt ist (d. h. "1"), dann wird die
Grundstruktur, auf die zugegriffen wurde, in Schritt 513 ausgeführt. Nach
dem Ausführen
der Programmanweisungen der Grundstruktur fährt der Prozess mit Schritt 515 fort.
Schritt 515 setzt dann die Ausführung der Anwendung fort, die
gerade vom Mikroprozessor auf der IC-Karte ausgeführt wird.