DE69402955T2

DE69402955T2 - Datenauswechselsystem mit tragbaren Datenverarbeitungseinheiten

Info

Publication number: DE69402955T2
Application number: DE69402955T
Authority: DE
Inventors: Eduard Karel 1097 Hs Amsterdam De Jong
Original assignee: Belle Gate Investments BV
Current assignee: Belle Gate Investments BV
Priority date: 1994-02-08
Filing date: 1994-02-08
Publication date: 1997-08-14
Anticipated expiration: 2014-02-09
Also published as: EP0666550A1; US5802519A; CA2466650A1; NZ278967A; JPH09508733A; AU1546095A; KR100386154B1; ATE152539T1; AU681754B2; EP0666550B1; WO1995022126A1; DE69402955D1; FI963111A0; KR100417502B1; FI963111A; FI117990B; CN1079968C; CA2182783A1; CA2182783C; CN1150850A

Description

Die Erfindung betrifft ein Datenaustauschsystem mit wenigstens einer tragbaren Datenverarbeitungseinheit, welche eine Datenkommunikationseinrichtung, eine Verarbeitungseinrichtung und eine Speichereinrichtung umfaßt, wobei die letztere ein Ausführungsprogramm umfaßt.
Die europäische Patentanmeldung EP-A1-0 466 969 offenbart ein Datenaustauschsystem mit einer mehrfache Anwendungen unterstützenden IC-Karte und einem Endgerät Die IC-Karte umfaßt ein ROM zur Speicherung von Basisfunktionen, z.B. Verschlüsselungsalgorithmen, einem anwendungsunabhängigen gemeinsamen Datenfeld ("Gemeinschaftsdatenfeld") und einem Feld von Anwendungsdaten ("Anwendungsdatenfeld") mit einer Steuerliste ("Steuerliste"). Jedes Protokoll bildet eine Kombination eines Satzes von Basisfunktionen und möglichen Zwischenzuständen, und zwar bestimmt durch die Steuerliste der gewählten Anwendung.
Die internationale Patentanmeldung WO-A-87/07063 offenbart ein System für einen tragbaren Datenträger mit mehreren Anwendungsdateien. Eine der wichtigsten Anwendungen eines solchen tragbaren Datenträgers ist eine für Mehrfachanwendungen geeignete Chipkarte. Der bekannte Datenträger ist als Träger hierarchisch strukturierter Daten mit Sicherheitsmerkmalen zur Unterstützung mehrfacher Anwendungen auf demselben Datenträger beschrieben. Die Anwendungen werden als Sätze von Daten gesehen. Die Patentanmeldung beschreibt eine Ausführung eines hierarchischen Dateisystems auf einem Datenträger zur Speicherung veränderbarer Daten in Kombination mit einem hierarchischen Satz von Zugriffserlaubnissen. Der Datenträger antwortet auf einen Satz von gemeinsamen Befehlen. Die Dateizugriffserlaubnisse sind für unterschiedliche Operationen verschieden und werden in Abhängigkeit einer Paßwortverifikation erteilt. Es wird ein Paßwortverifikationsversuchszähler eingeführt wie auch die Maßnahme der Zerstörung gespeicherter Daten als Sanktion gegen zu viele Zugriffsversuche. Der bekannte Datenträger stellt sich primär als Speichervorrichtung und nicht als Prozessor dar. Durch das Ausführungsprogramm können nur sehr einfache Funktionen durchgeführt werden, wie etwa eine binäre logische Operation. Es ist nicht möglich, auf Anforderung eines mit dem Datenträger kommunizierenden Endgeräts hin die Durchführung eines unspezifizierten Satzes von Operationen zu erlauben. Die einzige Sicherheitsoption ist die Einführung der Paßwortverifikation. Andere Zugriffsbedingungsverifikationen sind innerhalb des bekannten Systems nicht möglich. Daneben besitzt jede Anwendung des Datenträgers ihre eigene Datei in der Speichereinrichtung des Datenträgers. Es sind keine speziellen Maßnahmen getroffen, um die Nutzung des verfügbaren Speicherraums zu verbessern, der insbesondere bei Chipkarten sehr eingeschränkt ist und daher der Zahl möglicher Anwendungen Grenzen setzt.
Die EP-A-0 479 655 betrifft die Ausbildung von Zugriffsbedingungsprüfungen bei Chipkarten. Hierfür ist eine Spezifizierungstechnik offenbart; es ist jedoch wünschenswert, Maßnahmen vorzusehen, um die Möglichkeit weiterer Verifikationen von Zugriffsbedingungen einzuschließen.
Die EP-A-0 361 491 betrifft ein Chipkartenprogrammierungssystem, um die geschützte (Um)Programmierung von Karten zu ermöglichen. Sie beschreibt die Verwendung von Einmal- Schreib-Zugriffsbedingungen zur Steuerung des Zugriffs auf zu programmierende Teile des programmierbaren Speichers. Die Zahl der Anwendungen auf einer einzelnen Karte kann auf diese Weise erweitert werden. Es wird die Verifikation der Zugriffsbedingungen mit einer Vielzahl von Techniken einschließlich kryptographischer Protokolle beschrieben.
Die EP-A-0 292 248 betrifft das Laden von Anwendungen auf eine Chipkarte unter Verwendung eines unveränderbaren Betriebssystemprogramms. Sie beinhaltet die Ausbildung eines Verfahrens zur Verbesserung der Bedingungen für den Datenzugriff, das Speicherzonen mit zugeordneten Zugriffsattributen verwendet. Spezielle Zugriffsbedingungen sind "Einmal- Schreiben" (was nur implizit beschrieben ist) und "Nur-Ausführen".
Die US-A-4 874 935 betrifft die Kartenprogrammierung unter Verwendung eines Datenwörterbuchs, wobei das Datenwörterbuch die Anordnung von in dem Kartenspeicher gespeicherten Datenelementen beschreibt. Man versteht Datenwörterbücher gemeinhin so, daß sie sich insoweit von Verzeichnissen unterscheiden, als sie nicht nur Daten beschreiben, die tatsächlich gespeichert sind, sondern auch Daten, die später gespeichert werden. Außerdem beinhalten Datenwörterbücher üblicherweise eine Beschreibung des Datenformats. In kompiliertem Format werden Datenwörterbücher in Datenbankverwaltungssystemen verwendet, wo sie auf der Festplatte als Teil der Datenbank gespeichert sind. Man findet sie auch in den Objektladedateien, die aus der Programmkompilierung in Softwareentwicklungsumgebungen resultieren. Das Patent beansprucht jedoch keine speziell für Chipkarten geeignete Darstellung von Datenwörterbüchern.
Das Hauptziel der vorliegenden Erfindung ist, Mittel bereitzustellen, um optimal mit den Beschränkungen umzugehen, die durch begrenzte physikalische Dimensionen des verfügbaren Speicherraums auf tragbaren Datenverarbeitungseinheiten, insbesondere auf Chipkarten, auferlegt werden.
Ein weiteres Ziel der vorliegenden Erfindung ist, einen allgemeineren Mechanismus zum geschützten Laden von Programmcodes anzubieten und ein derartiges Laden für vielfache Programme zu erlauben, nämlich jeweils für eine Anwendung jeder tragbaren Datenverarbeitungseinheit.
Darüber hinaus ist die vorliegende Erfindung auf die Maßnahme gerichtet, Zugriffsbedingungsverifikationen zu verwenden, die nicht durch den Hersteller der tragbaren Verarbeitungseinheit vorgeschrieben sind, sondern seitens des Anwendungsentwicklers so gewählt werden, daß sie seinen speziellen Anforderungen gerecht werden.
Das erfindungsgemäße System ist daher dadurch gekennzeichnet, daß die Speichereinrichtung ferner wenigstens einen Interaktionskontext umfaßt, welcher die folgende kohärente Datenstruktur beinhaltet:
a. einen Satz von Basis-Kommunikationsgrundelementen, die immer dann akzeptiert werden, wenn die Datenverarbeitungseinheit mit einer entsprechenden Einheit kommuniziert, wobei die Grundelemente zumindest ein Grundelement umfassen, das dazu verwendet wird, selektiv in einen der Interaktionskontexte einzusteigen;
b. einen Satz von Prozedurbeschreibungen, die die in Antwort auf jedes der akzeptierten Kommunikationsgrundelemente durchzuführenden Aktionen definieren und zumindest eine erste Prozedurbeschreibung umfassen, die bei Aktivierung des Interaktionskontextes durchzuführen ist, sowie eine letzte Prozedurbeschreibung, die unmittelbar vor Deaktivierung des Kontextes durchzuführen ist;
c. einen möglicherweise leeren Satz von entweder permanent gespeicherten oder berechneten Datenelementen, die zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen definiert sind, durchgeführt werden;
d. einen möglicherweise leeren Satz von Verweisen auf Datenelemente, welche Verweise den Prozedurbeschreibungen zugeordnet sind, wobei die Datenelemente auch möglichen weiteren Interaktionskontexten zugänglich sind und zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen definiert sind, durchgeführt werden;
e. eine möglicherweise leere Datenliste mit einer Liste von Verweisen auf Datenelemente, die zum expliziten Verweis als Teil eines Kommunikationsgrundelements verfügbar sind, um durch die dem Kommunikationsgrundelement zugeordnete Prozedurbeschreibung verwendet zu werden;
f. einen Satz von Zugriffsbedingungen, die den Datenelementen zugeordnet sind, auf welche im Zusammenhang mit den Prozedurbeschreibungen verwiesen wird;
g. einen Satz von Zugriffsbedingungen, die der Liste von Datenverweisen in der Datenliste zugeordnet sind.
Indem die Daten in der Speichereinrichtung der tragbaren Verarbeitungseinheit in dieser Weise definiert werden, ist die Verarbeitungseinheit in der Tat als Prozessor organisiert, d.h. sie erlaubt nicht nur logische Operationen, sondern führt auch Prozesse durch, die in die Verarbeitungseinheit durch hierzu authorisierte Personen geladen werden können, z.B. einen Angestellten einer Bank. Dadurch, daß Prozeduren bereitgestellt werden, die beliebige komplexe Operationen in Antwort auf erhaltene Befehle vorsehen können, und eine explizite Liste von gespeicherten Datenelementen bereitgestellt wird, welche als Teil solcher Befehle adressierbar sind, kann die Kommunikationsbandbreite optimal genutzt werden, was in einer reduzierten Anzahl ausgetauschter Befehle resultiert. Bei einem erfindungsgemäßen System werden viele tatsächliche Verwendungen des Systems immerhin den Austausch von zwei Befehlen erfordern. Was einzig und allein festgelegt ist, ist die Struktur innerhalb der Speichereinrichtung, die in solcher Weise definiert ist, daß verschiedene Anwendungen der Einheit in sehr effizienter Weise hinzugefügt werden konnen, d.h. unter Verwendung so wenig zusätzlichen Speicherraums wie möglich. Dies ist insbesondere von vorrangiger Bedeutung, wenn die Einheit eine Chipkarte ist, die streng begrenzt ist, was den verfügbaren Speicherraum anbelangt. Daneben bietet die erfindungsgemäße Struktur alle Möglichkeiten, Sicherheitsmaßnahmen einzuschließen, um den Zugriff auf Prozesse oder Daten durch unauthorisierte Personen, die zu deren Nutzung nicht befugt sind, zu unterbinden.
Bei einer ersten bevorzugten Ausführungsform ist das oben definierte Datenaustauschsystem dadurch gekennzeichnet, daß die Speichereinrichtung ferner mindestens zwei Interaktionskontexte, mindestens eine Anwendungsbeschreibung sowie ein Speicherelement umfaßt, das einen Verweis auf den Interaktionskontext speichert, der momentan in Kraft ist, wobei jede Anwendungsbeschreibung umfaßt:
a. eine Datenliste mit Verweisen auf Datenelemente, welche Verweise zwei oder mehr Interaktionskontexten zugänglich sind und durch zusätzliche Datenelemente erweitert sein können;
b. einen weiteren Satz von Zugriffsbedingungen, die den Verweisen oder den zusätzlichen Datenelementen zugeordnet sind und Nutzungsbeschränkungen festlegen.
Durch diese Maßnahmen sind alle Verweise auf Datenelemente, die verschiedenen Interaktionskontexten gemeinsam sind, für alle diese Interaktionskontexte zugänglich, so daß sie nur einmal gespeichert werden müssen, was Speicherplatz spart. Außerdem sind gemeinsame Zugriffsbedingungen für die Datenverweise vorbestimmten Interaktionskontexten zugänglich. Daher müssen auch diese gemeinsamen Zugriffsbedingungen nur einmal gespeichert werden, wodurch Speicherplatz gespart und die Effizienz verbessert wird.
Jede Anwendungsbeschreibung kann darüber hinaus eine Prozedurbibliothek mit ausführbaren Codeeinheiten umfassen, welche durch Prozedurbeschreibungen jedes Interaktionskontextes verwendet werden können, der jeder der Anwendungsbeschreibungen zugeordnet ist.
Vorzugsweise ist die Verarbeitungseinheit für mindestens zwei Anwendungen geeignet unter Verwendung geringfügigen zusätzlichen Speicherplatzes. Um dieses Ziel zu erreichen, ist das erfindungsgemäße Datenaustauschsystem dadurch gekennzeichnet, daß die Speichereinrichtung mindestens zwei Anwendungsbeschreibungen und ausführbare Codeeinheiten umfaßt, welche durch Prozedurbeschreibungen jedes Interaktionskontextes innerhalb jeder Anwendungsbeschreibung oder durch jede ausführbare Codeeinheit jeder Prozedurbibliothek innerhalb jeder Anwendungsbeschreibung verwendet werden können.
Vorzugsweise sind die ausführbaren Codeeinheiten in der Prozedurbibliothek dadurch erweitert, daß eine Spezifikation der Verwendung ihrer Operationsparameter in Klassen eingefügt ist, welche sich auf Attribute beziehen, die Datenelemente betreffen, welche als tatsächlicher Wert in einer Berechnung genommen werden können, welche Berechnung nur dann fortschreitet, wenn die Datenattribute und die Parameterklassen zueinander passen. Dies ist ein effizienter Weg zur Verifizierung von Zugriffsbedingungen sowohl auf Datenebene als auch auf funktionaler Ebene, wofür eine sehr effiziente Implementierung existiert.
Das System bietet eine höhere Zuverlässigkeit, wenn das erfindungsgemäße Datenaustauschsystem dadurch gekennzeichnet ist, daß das Ausführungsprogramm einen Verweis auf einen Standardinteraktionskontext umfaßt, welcher dazu verwendet wird, das Speicherelement zu initialisieren, das einen Verweis auf den momentan in Kraft befindlichen Interaktionskontext speichert, um eine Endaktion nach einer Erfassung einer internen Inkonsistenz bei einer Wiederaufnahme eines normalen Operationszustands durchzuführen oder wann immer das Ausführungsprogramm aktiv ist und kein expliziter Interaktionskontext durch ein von einer gegenüberliegenden Datenverarbeitungseinheit erhaltenes Kommunikationsgrundelement spezifiziert worden ist.
Um die Sicherheit der Daten und Funktionen in der Verarbeitungseinheit zu verbessern, kann das erfindungsgemäße Datenaustauschsystem dadurch gekennzeichnet sein, daß die Speichereinrichtung einen Interaktionskontext umfaßt, dessen Zweck es ist, persönliche Identifizierungsnummern zu umfassen, und daß das Ausführungsprogramm dazu ausgelegt ist, von einem Benutzer des Datenaustauschsystems gelieferte persönliche Identifizierungsnummern zu verifizieren.
Vorteilhafterweise können der Interaktionskontext zur Verwaltung der persönlichen Identifizierungsnummer und der Standardkontext als Teil derselben Besitzeranwendung für den Besitzer der Vorrichtung implementiert sein. Die Unterstützung dieser Anwendung durch die meisten Geräte, mit denen eine erfindungsgemäße Vorrichtung kommuniziert, würde dem Eigentümer der Vorrichtung die Möglichkeit geben, seine persönlichen Daten, so wie sie in dem Vorrichtungsspeicher gespeichert sind, nachzuschauen; beispielsweise könnte es einem Chipkartenbesitzer erlaubt sein, seine PIN an jedem Chipkarten-Terminal zu modifizieren, das eine geeignete Benutzerschnittstelle bereitstellt.
Jede Anwendungsbeschreibung kann eine Liste von numerischen Werten umfassen, die so aufgebaut ist, daß sie Bezeichner für alle Interaktionskontexte bereitstellt, und zumindest einen ersten numerischen Wert umfaßt, welcher einen Anwendungstyp angibt, einen zweiten numerischen Wert, welcher eine ausschließliche Bezeichnung des Bereitstellers der Anwendung angibt, einen dritten numerischen Wert, welcher die Art der Anwendungsbeschreibung angibt, und weitere Zahlen, die sich jeweils ausschließlich auf einen der Anwendungsbeschreibung zugeordneten Interaktionskontext beziehen.
Die Reihe numerischer Werte, die sich ausschließlich auf einen Interaktionskontext beziehen, sieht ein Mittel vor, die Funktionsfähigkeit zwischen zwei Kommunikationseinrichtungen untereinander sicherzustellen, das effizienter ist, als man sich gegenwartig etwa für Chipkarten vorstellt, wobei dem Anwendungsbereitsteller die Verantwortung übertragen wird, jedem Interaktionskontext eigene Werte zuzuweisen, während es betroffenen Gruppen sektoraler bzw. internationaler Zusammenarbeit überlassen bleibt, Personen und Anwendung eigene Nummern zuzuordnen. Vorteilhafterweise kann der Anwendungsbereitsteller diese ausschließlichen Kontextnummern zuweisen, um Informationen über die Version der Ausführung und die Geheimschlüsselerzeugung einzubauen.
Die Datenkommunikationseinrichtung kann so ausgeführt sein, daß sie den Datenaustausch in Datenblöcke strukturiert, welche wenigstens zwei Teile umfassen, wobei ein erster Teil Daten sind, die insofern als operationsrelevant qualifiziert sind, als sie dazu verwendet werden, die Art der Operationen zu beeinflussen, die durch einen Befehl durchgeführt werden, wie er durch ein Kommunikationsgrundelement angegeben ist, oder die Art von Daten zu beeinflussen, welche aus durchgeführten Operationen resultieren, wobei ein zweiter Teil insofern als sicherheitsrelevant qualifiziert ist, als er dazu verwendet wird, die Eignung zur Durchführung einer Operation oder der Akzeptierbarkeit von Daten in dem operationsrelevanten Teil zu bestimmen, um in der Operation verwendet zu werden, oder die Beendigung der Operation oder die Korrektheit der resultierenden Daten nachzuweisen.
Solche Eignung, Akzeptierbarkeit, Nachweis und Korrektheit werden erhalten, indem relevante kryptographische Operationen an den Daten durchgeführt werden. Die Authentisierung und der Datenschutz werden so zu einem integralen Teil der Befehlsausführung gemacht, was für eine bessere Sicherheit sorgt, als sie bei gegenwärtigen Systemen, etwa bei Chipkarten, erreichbar ist.
Das Ausführungsprogramm kann so ausgelegt sein, daß es bei Akzeptierung eines Kommunikationsgrundelements zur Durchführung von in dem momentanen Interaktionskontext spezifizierten Operationen jede Operation als Teil einer vorbestimmten und festen Folge von Aktionen durchführt, die jeweils gesondert als Teil einer dem akzeptierten Kommunikationsgrundelement zugeordneten Prozedurbeschreibung spezifiziert sind, welche Aktionen zumindest die folgenden Aktionen umfassen:
a. Authorisierung der Verwendung des Kommunikationsgrundelements;
b. Entschlüsselung der Operationsdaten oder eines Teils derselben;
c. Durchführen eines Befehls mit Eingangsdaten;
d. Verschlüsselung von Operationsdaten, die aus einer durchgeführten Operation resultieren;
e. Berechnung eines Nachweises der Beendigung einer durchgeführten Aktion oder der Korrektheit der resultierenden Daten, um in Sicherheitsberechnungen verwendet zu werden.
Die Sicherheit wird weiter verbessert, wenn die Datenverarbeitungseinheit bei Initialisierung des Datentransfers eine zufällige Transaktionsnummer erzeugt, die als Basis für kryptographische Berechnungen dient.
Um für die Möglichkeit zu sorgen, erforderlichenfalls in einen neuen Interaktionskontext einzusteigen, kann einem Kommunikationsgrundelement ein spezifizierter Wert zugewiesen sein, der stets als Anforderung interpretiert wird, in einen neuen Interaktionskontext einzusteigen.
Bei einer weiteren bevorzugten Ausführungsform ist das erfindungsgemäße Datenaustauschsystem dadurch gekennzeichnet, daß eine weitere Datenverarbeitungseinheit mit den gleichen Elementen wie die Datenverarbeitungseinheit sowie eine Anwendungsprogrammiererschnittstelle umfaßt, welche aus einem Programmcode besteht, der so ausgeführt ist, daß er die Implementierung zusätzlicher Computerprogramme erlaubt, um Benutzern die Kontrolle über die Abfolge ausgetauschter Kommunikationsgrundelemente zu geben oder um die darin transferierten Daten zu beeinflussen oder die beim Austausch erhaltenen Daten zu lernen oder weiterzuverarbeiten. Die Entwicklung von Software für erfindungsgemäße Systeme wird sich die Verfügbarkeit einer Anwendungsprogrammiererschnittstelle zunutze machen.
Bei einer solchen bevorzugten Ausführungsform der Erfindung kann das zum Einstieg in einen spezifizierten Interaktionskontext verwendete Grundelement numerische Werte umfassen, die bei Sicherheitsberechnungen in nachfolgenden Kommunikationen zu verwenden sind, einen ersten, durch eine der Verarbeitungseinheiten zufällig erzeugten Wert sowie einen zweiten, der Identifizierung dieser einen Verarbeitungseinheit dienenden Wert.
Um die vorliegende Erfindung weiter zu nutzen, kann jedes Kommunikationsgrundelement ferner so strukturiert sein, daß es aus zwei oder mehr numerischen Werten besteht, was die Ausdruckskraft des Kommunikationsgrundelements zur Interpretation durch das Ausführungsprogramm erhöht.
Als erste Alternative kann jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt sein, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer festen Zahl von Binärwerten zusammengesetzt ist, die durch das Ausführungsprogramm jeweils als Verweis auf ein einzelnes Datenelement interpretiert werden.
Als zweite Alternative kann jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt sein, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert dazu verwendet wird zu bestimmen, welche der zum externen Verweis in einem aktiven Interaktionskontext verfügbaren Datenelemente verwendet werden, während Antwortaktionen in solcher Weise durchgeführt werden, daß ein Datenelement ausgewählt wird, wenn es einen Wert enthält, der mit dem zweiten Wert übereinstimmt.
Als dritte Alternative kann jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt sein, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer Anzahl von Binärwerten zusammengesetzt ist, denen durch das Ausführungsprogramm spezielle Bedeutungen zugewiesen sind, um bei der Interpretation von Datenformaten in dem Kommunikationsgrundelement und bei der Durchführung von Antwortaktionen verwendet zu werden.
Der oben definierte Kontextmechanismus und die Techniken, die er verfügbar macht, führen zu einem breiteren Einsatzbereich für Chipkarten und zu einem Ansatz zur Entwicklung von Chipkartenanwendungen, wobei sich zahlreiche Vorteile gegenüber den herkömmlichen Wegen ergeben.
Zunächst wird die Ausführung eines anwendungsspezifischen Programmcodes in einer Chipkarte ohne die Notwendigkeit ermöglicht, den Code auf mögliche Gefahren für die Sicherheit von Daten, die für andere Anwendungen gespeichert sind, sorgfältig zu untersuchen. Da den Zugriffsbedingungen, die mit den Daten auf der Karte gespeichert sind, durch das Kartenbetriebssystem Geltung verschafft wird, ohne daß während der Ausführung eines Anwendungscodes Störungen von außerhalb möglich sind, benötigt ein Kartenschema für mehrfache Anwendungen keine den Programmcode überprüfende Instanz. Eine derartige Instanz ist der einzige Weg, bei herkömmlichen Chipkarten eine Ausführungsmöglichkeit für private Codes zu erlauben. Durch Genehmigung eines Codes zur Ausführung auf einer Karte zieht eine Überprüfungsinstanz Anfälligkeiten im Hinblick auf die Sicherheit des Gesamtsystems auf sich; sie macht die Verwaltung von Chipkartenschemata für Mehrfachanwendungen viel komplexer. Die einhergehende Komplexität und die einhergehenden Kosten machen anwendungsspezifische Codes bei herkömmlichen Kartenschemata fast unmöglich. Mit der neuen Technik kann der seit einiger Zeit seitens der Bereitsteller von Chipkartenanwendungen bestehende Bedarf nach dieser Möglichkeit erfüllt werden.
Zweitens kann als unmittelbare Folge der geschützten Anwendung spezieller Programme in Karten eine spezielle Anwendung implementiert werden, die dazu bestimmt ist, weitere Anwendungen in die Karte zu laden. Auf diese Weise können die einmal in eine Karte geladenen Anwendungen vor genau der Anwendung geschützt werden, die sie geladen hat. Dieser Schutz gibt den an einem Kartenschema für Mehrfachanwendungen beteiligten Parteien; insbesondere dem Kartenausgeber und den Anwendungsbereitstellern, eine Basis für ihre Geschäftsübereinkunft. Anhand greifbarer Dinge wie der auf jeder Karte benötigten Speichermenge, der Zahl der auszurüstenden Karten und der Dauer der Anwendung auf der Karte anstelle einer abstrakten Anmerkung von "Vertrauen" und "hoher Sorgfalt" ist der Vertrag des Anwendungsbereitstellers leichter als bei herkömmlich ausgeführten Chipkarten zu formulieren. Außerdem müssen der Kartenausgeber und der Anwendungsbereitsteller keine Geheimschlüssel teilen und diese Teilung mit vertraglichen Verpflichtungen und gegenseitig abgestimmten Schlüsselübermittlungsmöglichkeiten schützen.
Drittens besitzt die Anwendungssoftware, falls sie auf Grundlage der neuen Technik implementiert wird, einige Vorteile im Vergleich zu bekannten Chipkartenbetriebssystemen:
- Ein minimaler Austausch von Daten zwischen einem Endgerät und einer Karte ist erforderlich, um die Funktionsfähigkeit zwischen Karte und Endgerät untereinander sicherzustellen, z.B. unterstützen sie dieselbe(n) Anwendung(en). Zu diesem Zweck auszutauschende Datenwerte können so strukturiert sein, wie in dem Entwurf des internationalen Standards ISO 7816-5 vorgeschlagen;
- zur Beendigung einer Transaktion zwischen Karte und Endgerät kann die minimale Zahl von Datenaustauschen wie theoretisch hergeleitet tatsächlich verwendet werden, weil die Transaktion als private Berechnung beendet wird anstelle der Notwendigkeit, eine lange Folge von Standardbefehlen zu verwenden;
- sie erlaubt den kontrollierten Zugriff auf Daten, ohne einen beteiligten Zugriffsweg zu benötigen, der durch eine von allen Anwendungen geteilte Verzeichnis- und Dateihierarchie vorgeschrieben ist, wie momentan gebräuchlich und zur Standardisierung vorgeschlagen;
- sie erlaubt die parallele Entwicklung der Endgeräte- und Chipkartenanwendung, welcher Entwicklungsprozeß mit Computersoftwarewerkzeugen, wie Compilern und Emulatoren, unterstützt werden kann. Gestaltung und Implementierung der Karten- und Endgerätesoftware können so über die langweilige und fehleranfällige Codierung in Assemblersprache, die gegenwärtig erforderlich ist, hinausgehoben werden;
- sie erlaubt die Standardisierung der Ausrüstung, und zwar sowohl der Karten als auch der Endgeräte, unter Verwendung eines abstrakten Formalismus zur Beschreibung der Fähigkeiten der Komponenten, was Flexibilität im Hinblick auf zukünftige Entwicklungen, etwa neue, von Karten- oder Endgeräteherstellern offerierte Merkmale, verleiht. Die standardisierte Endgerätekapazität könnte ein API umfassen. Dagegen konzentrieren sich die gegenwärtigen Standardisierungsbemühungen bei Chipkarten darauf, feststehende Dateninhalte von Nachrichten vorzuschreiben, um Identifizierungswerte bereitzustellen, die in einer Weise zu interpretieren sind, wie sie durch den Standard festgelegt ist, was wenig Raum für neue Entwicklungen läßt.
Schließlich ist den Herstellern von Chipkartenbetriebssystemen mit der neuen Technik eine große Freiheit bei der Gestaltung optimaler Implementierungen des Betriebssystemkerns der Karte und des Entgerätebetriebssystems gegeben. Hardwarekonstrukteuren von Chipkarten sind verschiedene Optionen gegeben, um die Ausnutzung des Chip-Siliziums mit Hardwareunterstützung für Basisoperationen, die im Systemkern enthalten sind, zu optimieren. Die erhaltene Reduzierung der Hardwarekosten, beginnend mit dem oben definierten spezialisierten Design, kann größer sein, als wenn man Verbesserungen bei universellen Ein-Chip-Computern zugrundelegt.
Die Erfindung wird nun im einzelnen mit Bezug auf einige Zeichnungen beschrieben, die ein Ausführungsbeispiel der Grundprinzipien der vorliegenden Erfindung zeigen.
Figur 1 zeigt ein auf einer hierarchisch organisierten Sammlung von Datenelementen basierendes, bekanntes Anwendungsdesign bei Chipkarten;
Figur 2 stellt ein Schaubild des Kommunikationsstroms zwischen einer tragbaren Verarbeitungseinheit und einer entsprechend aufgebauten Verarbeitungseinheit in einem gegenwärtig als Standard akzeptierten Format dar;
Figur 3 stellt eine Grundausführung der vorliegenden Erfindung unter Verwendung des Konzepts der Interaktionskontexte in tragbaren Verarbeitungseinheiten, wie etwa Chipkarten, und in Kartenendgeräten dar;
Figur 4 stellt ein Beispiel einer zweckmäßigen Organisation eines Ausführungskontexts dar, das verschiedene Beziehungen zwischen in dem Interaktionskontext enthaltenen Prozedurbeschreibungen und Datenelementen sowie Bibliotheksfunktionen herausstellt, welche bei der Durchführung der Prozeduren benutzt werden;
Figur 5 zeigt ein Beispiel eines Flußdiagramms für eine Programmausführungssteuerung und Sicherheitskontextwechsel, die mit der Durchführung der durch ein Kommunikationsgrundelement aufgerufenen Prozedurbeschreibung verknüpft sind.
Die Struktur der Daten und Dateien in bekannten Systemen ist in Figur 1 dargestellt. Grundsätzlich gibt es eine Stammdatei 1, die mit mehreren Elementardateien 3 und einer oder mehreren reservierten Dateien 2 verbunden ist. Jede reservierte Datei 2 kann mit einer oder mehreren weiteren reservierten Dateien 2 und mit einer oder mehreren Elementardateien 3 verbunden sein. Der Stand der Technik benutzt eine baumartige Hierarchie der Verzeichnisse und Dateien. Die Zahl der untergeordneten Ebenen ist bei der bekannten Struktur prinzipiell unbeschränkt. Die in Figur 1 benutzte Terminologie ist dem vorgeschlagenen internationalen ISO-Standard 7816-4 entnommen. Gemäß dem Standardformat für den Kommunikationsstrom zwischen einer tragbaren Datenverarbeitungseinheit 5 und einer entsprechend aufgebauten Datenverarbeitungseinheit 4, wie in Figur 2 gezeigt, umfaßt die Kommunikation eine Menge von Blockpaaren. Die Kommunikation beginnt mit einem Rücksetzsignal m0 von der Datenverarbeitungseinheit 4. Ein derartiges Rücksetzsignal kann außerhalb der Kommunikationsbandbreite liegen, wie etwa durch die Betriebslogik in der Datenverarbeitungseinheit 5 erzeugt. Die tragbare Datenverarbeitungseinheit 5 antwortet mit einem Rücksetzantwortsignal (ATR) m1, auf das möglicherweise Inhalte folgen. Alle nachfolgenden Paare von Blöcken m2, m3, ... m(n-1), mn bestehen aus Blöcken, die von einem Kommunikationsgrundelement (z.B. einem Befehl) angeführt werden, auf das Inhalte folgen.
Figur 3 zeigt die interne Struktur zweiter erfindungsgemäßer Datenverarbeitungseinheiten, die durch Senden und Empfangen von Daten miteinander kommunizieren. Die linke Datenverarbeitungseinheit 4 kann unter anderem ein Endgerät sein, die rechte Datenverarbeitungseinheit kann unter anderem eine tragbare Datenverarbeitungseinheit, z.B. eine Chipkarte, sein. Die Erfindung ist jedoch auch auf zwei tragbare Datenverarbeitungseinheiten anwendbar, die durch geeignete Kommunikationsmittel miteinander kommunizieren können.
Jede der Datenverarbeitungseinheiten 4, 5 umfaßt eine Datenkommunikationseinrichtung 7, 14, über die strukturierte Blöcke von Daten ausgetauscht werden können. Jede der Datenverarbeitungseinheiten 4, 5 umfaßt eine Verarbeitungseinrichtung 8, 15 sowie eine Speichereinrichtung 9, 16. Die Speichereinrichtung 9, 16 kann jede beliebige Ausbildung eines Festspeichers (ROM), eines Direktzugriffsspeichers (RAM) und eines programmierbaren Festspeichers, wie etwa eines elektrisch löschbaren programmierbaren Festspeichers (EEPROM), sein.
Die Speichereinrichtung 9, 16 umfaßt ein Ausführungsprogramm 12, 17, das hier durch "MAXOS" angedeutet ist. Wenn die tragbare Datenverarbeitungseinheit 5 für zwei oder mehr Anwendungen geeignet ist, umfaßt die Speichereinrichtung 9, 16 zwei oder mehr Anwendungsbeschreibungen 13(1) ... 13(n), 18(1) ... 18(n). Es gibt so viele Anwendungsbeschreibungen, wie Anwendungen der betreffenden Datenverarbeitungseinheit vorgesehen sind. Jede Anwendungsbeschreibung ist durch "CSA" angedeutet. Die zweite Anwendungsbeschreibung 13(2), 18(2) ist in Figur in vergrößertem Maßstab gezeigt, um die Darstellung der Inhalte jeder Anwendungsbeschreibung zu erlauben. Jede Anwendungsbeschreibung 13(i), 18(i) umfaßt zumindest einen "Interaktionskontext" 11(1) ... 11(m), 19(1) ... 19(m). Jeder Interaktionskontext ist durch "CTA" angedeutet. Der erste dieser Interaktionskontexte 11(1), 19 (1) ist in vergrößertem Maßstab gezeigt, um die Darstellung seiner Inhalte zu erlauben. Jeder Interaktionskontext enthält:
- einen Satz von Befehlen, welche die durch den Interaktionskontext erkannten Kommunikationsgrundelemente spezifizieren und auf geeignete, in einem Prozedurensatz spezifizierte Prozeduren verweisen;
- einen Satz von Daten;
- einen Satz von Datenverweisen auf Daten, welche in anderen Interaktionskontexten - falls vorhanden - angesiedelt sind;
- einen Satz von Prozeduren, welche von dem Ausführungsprogramm 12, 17 durchgeführt werden können;
- einen Satz von Zugriffsbedingungen für die Datenelemente;
- einen Satz von externen Verweisen, welche auf Datenelemente verweisen, die bei Befehlen zu verwenden sind, welche von der anderen Datenverarbeitungseinheit ausgegeben werden;
- optional entwicklerspezifizierte weitere Listen.
Schließlich umfaßt die Speichereinrichtung 9, 16 ein Speicherelement 21, 20, das einen Verweis auf den "momentanen CTA" enthält, d.h. den Interaktionskontext, der momentan in Kraft ist.
Der Sinn mehrerer Interaktionskontexte innerhalb einer Anwendungsbeschreibung ist, eine funktionale Trennung in mögliche Interaktionen zwischen den Datenverarbeitungeinheiten 4, 5 vorzusehen. Dies ist besonders bedeutsam, wenn die funktionale Trennung auch eine Trennung in Sicherheitsbedingungen ist. Ein Beispiel kann eine erste Interaktion zwischen einer Chipkarte und einem Endgerät zum Öffnen etwa einer Tür und eine zweite Interaktion bei der Programmierung von Türen, die geöffnet werden dürfen, sein. Die zweite Interaktion benötigt eine bessere Sicherheit als die erste Interaktion und besitzt ihren eigenen Interaktionskontext. Zugriff auf den Interaktionskontext zu erhalten, ist der erste Schritt bei der Gewährleistung der Sicherheit der Operationen, die im Rahmen des Interaktionskontextes ausgeführt werden können.
Figur 4 zeigt einen zweckmäßigen Ansatz zur Realisierung des Kontextmechanismus, der als Speicherorganisationsmodell dargestellt ist, das die Beziehungen zwischen Datenelementen, Zugriffsbedingungen und Prozeduren zeigt. Die Struktur der Figur 4 gilt immer dann, wenn es zwei oder mehr Anwendungen der tragbaren Datenverarbeitungseinheit 5 gibt. Wenn es nur eine Anwendung gibt, ist die Struktur stark vereinfacht, wie später erläutert wird. In Figur 4 sind die Bezugsziffern der Datenverarbeitungseinheit 5 dargestellt. Die Struktur der Figur 4 ist jedoch in gleicher Weise auf die Speichereinrichtung 9 der Datenverarbeitungseinheit 4 anwendbar. In Figur 4 sind Datenelementbeschreibungen und Prozedurbeschreibungen optimal organisiert, um die Aufteilung des Programmcodes und die Aufteilung der Daten zwischen verschiedenen Interaktionskontexten (CTA's) widerzuspiegeln, die eine Anwendung (CSA) bilden.
Die Speichereinrichtung 16 umfaßt Datenelemente H(1) ... H(7), ausführbare Codeelemente G(1) ... G(5), welche Teil des Betriebssystems sind, sowie Anwendungsbeschreibungen 18(1), 18(2) (CSA1, CSA2). In Figur 4 sind betriebssysteminterne Daten und Codes weggelassen. Die Zahl der Datenelemente, der ausführbaren Codeelemente und der Anwendungsbeschreibungen, wie sie in Figur 4 dargestellt sind, ist lediglich beispielhaft: In der Realität können sich die Zahlen nach Bedarf ändern.
Jede Anwendungsbeschreibung 18(1), 18(2) ist physikalisch in der Speichereinrichtung vorhanden. Sie sehen eine erste, untere Schicht der Abstraktion vor, um die Speichernutzung widerzuspiegeln. Jede Anwendungsbeschreibung 18(1), 18(2) besteht aus:
- einer Prozedurbibliothek, welche aus ausführbaren Codeeinheiten F(1) ... F(4) besteht, die auf zu diesem Zweck verfügbar gemachte ausführbare Codeeinheiten des Betriebssystems verweisen können, wie durch Pfeile p(1) ... p(5) angedeutet;
- eine Liste von Datenelementen E(1) ... E(7), welche von Prozeduren im Rahmen der Interaktionskontexte 19(1) ... 19(2) in der gegenwärtigen Anwendungsbeschreibung 18 zu verwenden sind. Diese Datenliste umfaßt Datenzugriffsbedingungen sowie Zeiger q(1) ... q(7) auf Speicherbereiche, welche Datenelemente enthalten;
- eine Interaktionskontextliste mit einer Anzahl von Interaktionskontextbeschreibungen 19(1), 19(2).
Die Zahl der Elemente in der Prozedurbibliothek, in der Liste der Datenelemente und in der Interaktionskontextliste in der Anwendungsbeschreibung 18(1), wie sie in Figur 4 gezeigt ist, ist lediglich zum Zwecke der Darstellung. Selbstverständlich kann die Zahl der Elemente abhängig von der gewünschten Anwendung variieren.
Die Interaktionskontexte 19(1), 19(2) sind physikalisch in der die Anwendungsbeschreibung 18(1) speichernden Speichereinrichtung vorhanden. In logischer Hinsicht sehen die Interaktionskontexte eine zweite Schicht der Speichernutzungssteuerung vor. Die durch diese zweite Schicht und die Anwendungsbeschreibungsschicht vorgesehene kombinierte Steuerung ergibt eine effektive Realisierung eines Ausführungskontextmechanismus für tragbare Datenverarbeitungseinheiten, wie etwa Chipkarten. Jeder Interaktionskontext 19(1), 19(2) umfaßt:
- Eine Liste von Prozedurbeschreibungen C(1) ... C(5). Diese Prozedurbeschreibungen können auf Prozedurbeschreibungen in der Prozedurbibliothek innerhalb der Anwendungsbeschreibung 18 verweisen, wie durch Beispielspfeile s(1), s(2) angedeutet. Alternativ können diese Prozedurbeschreibungen auf durch das Betriebssystem bereitgestellte ausführbare Codeelemente G(1) ... G(5) verweisen, wie durch einen Beispielspfeil t(1) angedeutet. Als weitere Alternative können diese Prozedurbeschreibungen explizite Verweise auf Datenelemente enthalten, die von der Prozedur während der Ausführung verwendet werden und die in der Datenliste der betreffenden Anwendungsbeschreibung 18 vorhanden sind, wie durch Pfeile r(1) ... r(6) angedeutet;
- eine Datenliste, welche Datenelemente B(1) ... B(5) enthält, die exklusiv zur Verwendung durch die Prozeduren in dem betreffenden Interaktionskontext verfügbar sind. Die Datenelemente sind als Verweise auf die Datenliste der betreffenden Anwendungsbeschreibung 18 mit zugehörigen Zugriffsbedingnngen dargestellt, an die man sich beim Zugriff auf die eigentlichen Daten halten muß, wie durch Pfeile u(1) ... u(5) angedeutet;
- eine Außenschnittstellenliste mit Kommunikationsgrundelementen A(1) ... A(4), die von den betreffenden Interaktionskontexten 19(1), 19(2) als Befehle akzeptiert werden. Jeder Befehl innerhalb eines Kommunikationsgrundelements verweist auf ein Element der Prozedurbeschreibungen C(1) ... C(5) der Prozedurenliste innerhalb des betreffenden Interaktionskontexts, wie durch Pfeile v(1) ... v(4) angedeutet. Die Befehle können, wenn sie durch die Kommunikationseinrichtung 4 ausgegeben werden, durch eine oder mehrere dem Befehl folgende Adressen auf Elemente in der Datenliste der Anwendungsbeschreibung verweisen. Jeder Befehl kann von Datenelementen als Eingabe für die Befehlsverarbeitung begleitet werden. Die Zahl der hier angegebenen Adressen ist lediglich beispielhaft und wird in der Realität für jeden Befehl nach Bedarf festgelegt.
Für den Schutz der Datenelemente wird durch die Vorsehung der Zugriffsbedingungen gesorgt. Jeder externe Befehl in einem Kommunikationsgrundelement A(1) ... A(4) kann lediglich Datenelemente adressieren, auf die in der Datenliste des betreffenden Interaktionskontexts 19 verwiesen wird. Der Zugriff wird nur dann gestattet, wenn die Zugriffsbedingungen erfüllt sind. Diese Zugriffsbedingungen spezifizieren die Art des Zugriffs, der für den Befehl zugelassen ist; eine derartige Zugriffsbedingung kann sein: kein Zugriff, nur Lesezugriff, Lese- und Schreibzugriff und Geheimschlüsselverwendung. Es können auch andere Zugriffsbedingungen gelten. Beispielsweise kann der Befehl des Kommunikationsgrundelements A(1) nur einen Lesezugriff auf das Datenelement B(2) über den Bezugspfeil w(2) haben, während der Befehl des Kommunikationsgrundelements A(2) über den Bezugspfeil w(3) einen Lese- und Schreibzugriff auf dasselbe Datenelement B(2) hat.
Die Prozedurbeschreibungen C(1) ... C(5) können auf Datenelemente in der Datenliste der betreffenden Anwendungsbeschreibung 18 und keine anderen verweisen. Wiederum erfolgt der Zugriff nur, wenn die Zugriffsbedingung erfüllt ist. Diese Zugriffsbedingungen spezifizieren ebenfalls die Art des Zugriffs, der erlaubt ist: beispielsweise kein Zugriff, nur Lesezugriff, Lese- und Schreibzugriff und Geheimschlüsselverwendung. Die Zugriffsbedingungen für verschiedene Prozedurbeschreibungen innerhalb desselben Interaktionskontexts 19 können für das gleiche Datenlistenelement E(1) ... E(7) der Anwendungsbeschreibung unterschiedlich sein, z.B. kann der Bezugspfeil r(1) eine Nur-Lese-Zugriffsbedingung darstellen, wogegen der Bezugspfeil r(2) eine Lese/Schreib-Zugriffsbedingung darstellen kann.
Die Zugriffsbedingungen werden auf der betroffenen Ebene geprüft, d.h. auf der Ebene der Anwendungsbeschreibung oder der Ebene des Interaktionskontexts, und zwar nur einmal. Ein Element B(1) ... B(5) der Datenliste innerhalb eines Interaktionskontexts 19(1), 19(2) verweist durch den Pfeil u(1) ... u(5) direkt auf den Zeiger eines Datenelements in der Datenliste der Anwendungsbeschreibung 18(1), weil die Zugriffsbedingnngen in dem Datenlistenelement E(1) ... E(7) der Anwendungsbeschreibung 18(1) bereits erfüllt sind. Die Prozedurbeschreibungen C(1) ... C(5) innerhalb eines Interaktionskontexts 19(1), 19(2), die auf Datenlistenelemente in der Anwendungsbeschreibung 18(1) verweisen, müssen jedoch zunächst die den Datenlistenelementen E(1) ... E(7) innerhalb der Anwendungsbeschreibung 18(1) zugeordnete Zugriffsbedingung erfüllen. Auf Datenelemente oder Prozedurbeschreibungselemente innerhalb der Datenlisten der Anwendungsbeschreibung 18(1) und ihrer zugehörigen Interaktionskontexte 19(1), 19(2) kann nicht von einer anderen Anwendungsbeschreibung in der Speichereinrichtung 16 verwiesen werden. Der ausführbare Code, der die Prozedurbeschreibung bildet, kann Daten lediglich indirekt über die beschränkte Menge von Datenverweisen adressieren, die jeder der Prozedurbeschreibungen C(1) ... C(5) zugeordnet sind. Unter Verwendung der durch B(1) ... B(5) beschriebenen Datenelemente wird die Liste von Verweisen durch das Ausführungsprogramm zeitweilig um Verweise auf Datenelemente erweitert, wie sie durch Auswertung von Adressen erhalten werden, die in der Kommunikationsnachricht, die als der mit der Prozedurbeschreibung verbundene Befehl akzeptiert wird, tatsächlich spezifiziert sind. Auf diese Weise kann auf keine anderen Daten als explizit spezifiziert zugegriffen werden, wobei nur bestimmte Bedingungen der Verwendung beachtet werden. Mit anderen Worten sieht das bevorzugte Speicherreferenzmodell der Figur 4, was die Anwendungsbeschreibung mit ihren zugehörigen Interaktionskontexten anbelangt, einen exklusiven Kontext für Operationen im Rahmen einer einzelnen Anwendung der Datenverarbeitungseinheit 5 vor. Die Datenelemente H(1) ... H(7) sind für alle Anwendungen gemeinsam in der Speichereinrichtung 16 gespeichert, enthalten jedoch Daten zur exklusiven Verwendung innerhalb des Kontextes der Anwendungsbeschreibung 18 (1), wobei diese Exklusivität durch das Ausführungsprogramm gewährleistet wird, indem die Existenz eines einzelnen Zeigers auf jeden Speicherplatz zugelassen wird, wie etwa q(1) von E(1) nach H(2). Lediglich auf die Codeelemente G(1) ... G(5) kann durch jede der in der Speichereinrichtung 16 gespeicherten Anwendungsbeschreibungen 18(1) ... verwiesen werden. Diese letzten Verweise einer anderen Anwendungsbeschreibung als der Anwendungsbeschreibung 18(1) auf die gemeinsamen Codes G(1) ... G(5) sind in Figur 4 nicht explizit angegeben. Es kann jedoch jeder Fachmann die Struktur der Figur 4 ohne weiteres auf zwei oder mehr Anwendungsbeschreibungen 18(1), 18(2), ... ausdehnen.
Nach der Erläuterung, wie die Datenelemente durch die Verwendung von Zugriffsbedingungen unterschiedlicher Arten geschützt werden können, werden nun die Vorkehrungen zur Speicherverwaltung erläutert. Für die Speicherverwaltung ist es wünschenswert, daß veränderbare Daten (Datenelemente) und unveränderbare Daten (Betriebssystemcode) von dem Betriebssystem gesondert verwaltet werden können. Das in Figur 4 gezeigte Speicherreferenzmodell sieht eine Trennung der Code- und Datenelemente in der Speichereinrichtung 16 vor, auf die durch Zeiger q(1) ... q(7), p(1) ... p(5) von der Datenliste bzw. der Prozedurbibliothek in der betreffenden Anwendungsbeschreibung 18 aus verwiesen wird. Die Datenlistenelemente in jedem Interaktionskontext 19(1), 19(2) enthalten lediglich Verweise auf diese Zeiger und keine unmittelbaren Verweise auf die Codes G(1) ... G(5) und die Datenelemente H(1) ... H(7) in der Speichereinrichtung 16. Die Datenliste der betreffenden Anwendungsbeschreibung 18 sieht den durch das Betriebssystem benötigten Grad der Indirektheit vor, um die Speicherverwaltung zu erfüllen.
Eine Codeverdopplung wird dadurch vermieden, daß gemeinsame Codebibliotheken auf zwei Ebenen bereitgestellt werden: "Befehlsrümpfe" wie die Prozedurbeschreibung C(3), die auf das Codeelement F(2) in der Prozedurbibliothek in der Anwendungsbeschreibung 18(1) verweist, um gemeinsame Codes unter verschiedenen Interaktionskontexten aufzuteilen. Der Rumpf der Prozedurbeschreibung C(3) verweist jedoch auch direkt auf einen Code G(3), der in der Speichereinrichtung 16 gespeichert ist und durch das Betriebssystem bereitgestellt ist. Alle durch das Betriebssystem bereitgestellten ausführbaren Codeeinheiten G(1) ... G(5) sind zur effizienten Ausführung ausgebildet.
Grundsätzlich ist die Speicherstruktur nach Figur 4 auch in Situationen anwendbar, in denen nur eine Anwendung der Datenverarbeitungseinheit 5 vorgesehen ist. In diesem Fall kann die einzige Anwendungsbeschreibung 18(1) sogar mit einem Interaktionskontext 19(1) zusammenfallen, welcher Interaktionskontext dann zumindest die folgende kohärente Datenstruktur enthält:
a. einen Satz von Basis-Kommunikationsgrundelementen A(1) ... , die immer dann akzeptiert werden, wenn die Datenverarbeitungseinheit 5 mit einer entsprechenden Einheit 4 kommuniziert, wobei die Grundelemente zumindest ein Grundelement umfassen, das dazu verwendet wird, selektiv in einen der Interaktionskontexte einzusteigen;
b. einen Satz von Prozedurbeschreibungen C(1) ... , die die in Antwort auf jedes der akzeptierten Kommunikationsgrundelemente A(1) ... durchzuführenden Aktionen definieren und zumindest eine erste Prozedurbeschreibung umfassen, die bei Aktivierung des Interaktionskontextes durchzuführen ist, sowie eine letzte Prozedurbeschreibung, die unmittelbar vor Deaktivierung des Kontextes durchzuführen ist;
c. einen möglicherweise leeren Satz von entweder permanent gespeicherten oder berechneten Datenelementen H(1) ... , die zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen C(1) ... definiert sind, durchgeführt werden;
d. einen möglicherweise leeren Satz von Verweisen auf Datenelemente, welche Verweise den Prozedurbeschreibungen C(1) ... zugeordnet sind, wobei die Datenelemente auch möglichen weiteren Interaktionskontexten zugänglich sind und zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen C(1) ... definiert sind, durchgeführt werden;
e. eine möglicherweise leere Datenliste mit einer Liste von Verweisen auf Datenelemente, die zum expliziten Verweis als Teil eines Kommunikationsgrundelements verfügbar sind, um durch die dem Kommunikationsgrundelement zugeordnete Prozedurbeschreibung verwendet zu werden;
f. einen Satz von Zugriffsbedingungen, die den Datenelementen zugeordnet sind, auf welche im Zusammenhang mit den Prozedurbeschreibungen verwiesen wird;
g. einen Satz von Zugriffsbedingungen, die der Liste von Datenverweisen B(1) ... in der Datenliste zugeordnet sind.
Wenn für die Datenverarbeitungseinheit 5 nur eine Anwendung vorgesehen ist und es wenigstens zwei Interaktionskontexte 19(1), 19(2) gibt, umfaßt jede Anwendungsbeschreibung:
a. eine Datenliste mit Verweisen E(1) ... auf Datenelemente, welche Verweise zwei oder mehr Interaktionskontexten 19(1) ... zugängfich sind und durch zusätzliche Datenelemente erweitert sein können;
b. einen weiteren Satz von Zugriffsbedingungen, die den Verweisen E(1) ... oder den zusätzlichen Datenelementen zugeordnet sind und Nutzungsbeschränkungen festlegen.
Der Satz von Prozedurbeschreibungen in jeder der zwei oder mehr Interaktionskontextbeschreibungen enthält außerdem eine zusätzliche letzte Prozedurbeschreibung, die unmittelbar vor Deaktivierung des Kontexts durchzuführen ist.
Figur 5 stellt den Ablauf der Steuerung in dem oben durch "MAXOS" (12, 17) definierten Ausführungsprogramm dar.
Nach Einschalten des Systems beginnt die Software mit der Verarbeitung eines Rücksetzcodes in Schritt 30. In Schritt 31 erfolgt der Einstieg in die Sicherheitsebene für die Kernoperationen der Datenverarbeitungseinheit. Die diese Ebene beschreibenden Zugriffsbedingungen sind in einem nicht modifizierbaren Teil des Speichers gespeichert, z.B. in einem ROM oder einer Hardware-Logik. In Schritt 32 wird der nicht flüchtige Speicher auf Übereinstimmung geprüft; jegliche Modifikationen, die durch ein plötzliches Abschalten, etwa durch Herausziehen einer Chipkarte, unbeendigt geblieben sein können, werden anulliert. Die Übereinstimmungsprüfung des nicht flüchtigen Speichers beinhaltet nur die Untersuchung der im Speicher gespeicherten Zustandsinformationen und die Berechnung von Prüfsummen. Der Inhalt des Speichers - falls überhaupt auf ihn zugegriffen wird - wird lediglich zur Berechnung der Prüfsummen verwendet. Die Übereinstimmungsprüfung ist daher ein sicherer Vorgang. Die genaue Art der Möglichkeiten zur Konsistenzprüfung hängt von den Einzelheiten der Hardware in der Datenverarbeitungseinheit und von Modifikationsroutinen für den nicht flüchtigen Speicher ab, die für die spezielle Sicherheitsarchitektur in hohem Maße irrelevant sind. Nach der allgemeinen Speicherübereinstimmungsprüfung werden die vorberechneten, im Speicher gespeicherten Ebenen des Sicherheitskontexts verifiziert. Schließlich wird der Direktzugriffsspeicher der Datenverarbeitungseinheit gestartet.
Wenn die Ausführungsumgebung somit für sicher erklärt wird, erfolgt in Schritt 33 der Einstieg in die Sicherheitsebene für eine sichere Anwendung der Datenverarbeitungseinheit. In dieser Ebene wird jeder Zugriff auf Speicherbereiche, welche die Kernoperationen betreffen, blockiert. Der Zugriff auf Anwendungsdaten und -beschreibungen von dieser Ebene erfolgt exklusiv über Routinen im Kern, die Zustandsinformationen über ablaufende Speicheroperationen führen.
Beim ersten Einstieg nach dem Rücksetzen werden in Schritt 34 Anwendungsdatenelementdeskriptoren verwendet, um die Übereinstimmung gespeicherter Daten mit dem Deskriptor zu prüfen; der Speicher wird geändert, falls er sich in einem mit dem so beschriebenen Attribut inkonsistenten Zustand befindet. Eine Rücksetzantwortnachricht (ATR) wird aus Anwendungsbezeichnern zusammengesetzt, die in den Anwendungsdeskriptoren gespeichert sind, und mit einer Transaktionsnummer vervollständigt, die so berechnet wird, daß sie durch die empfangende andere Datenverarbeitungseinheit 4 unvorhersagbar ist. Intern in der Datenverarbeitungseinheit wird ein Endgerätebefehl erzeugt, um einen Standardinteraktionskontext zu aktivieren. Unmittelbar nachdem die ATR-Nachricht an die andere Datenverarbeitungseinheit 4 geschickt wird, wird dieser interne Kontextaktivierungsbefehl ausgeführt, um einen Interaktionskontext für nachfolgende Befehle bereitzustellen. Die ATR-Nachricht signalisiert klarerweise die Bereitschaft der Datenverarbeitungseinheit 5, weitere Befehle anzunehmen. Der Standardinteraktionskontext kann als Teil einer "Chipkartenbesitzeranwendung" ausgeführt sein, die als eine Normalanwendung in allen Multianwendungs-Chipkarten vorhanden ist. Bei diesem speziellen Anwendungskontext kann der Benutzer, d.h. der Chipkartenbesitzer, seine persönlichen Daten nachsehen oder eine der anderen Anwendungen auf der Karte öffnen.
In Schritt 35 erfolgt als Folge des Kontextaktivierungsbefehls der Einstieg in die Interaktionskontext- (CTA) Sicherheitsebene für den normalen Chipkartenbesitzer CTA.
Nachdem eine Anwendung vollständig aktiviert worden ist, ist sie bereit, Befehle von der anderen Datenverarbeitungseinheit 4 zu empfangen. Die weitere Verarbeitung hängt von dem erhaltenen Befehl ab: Ein Befehl, eine Anwendung zu aktivieren, wird anders behandelt als ein Befehl, der ausgeführt werden soll. Daher wird in Schritt 38 nach der Feststellung, daß in Schritt 36 ein Kommunikationsgrundelement erhalten wird und in Schritt 37 als akzeptierbar nachgewiesen wird, getestet, ob eine neue Anwendung aktiviert werden soll. Falls nicht, wird in Schritt 39 eingetreten, in dem der Befehl geprüft wird, um zu bestimmen, ob er zugelassen wird und die Eingangsdaten akzeptiert werden können. Diese Prüfungen werden für einen Befehl nur durchgeführt, falls sie in dem Anwendungsdeskriptor spezifiziert sind. In Schritt 39 kann auch eine Entschlüsselung der Eingangsdaten durchgeführt werden.
Wenn der Test erfolgreich ist, erfolgt der Einstieg in die "Datenzugriffsschutzebene", Schritt 40. Auf dieser Ebene, der höchsten Sicherheitsebene, können Routinen ausgeführt werden, die von Anwendungsherstellern codiert wurden, Schritt 41. Diese Routinen sind in dem Anwendungsdeskriptor gespeichert und wirken als anwendungsspezifische Reaktion auf einen von der anderen Datenverarbeitungseinheit 4 ausgegebenen speziellen Befehl. Diese Sicherheitsebene beschränkt den Speicherzugriff auf eine Teilmenge, die speziell für den Befehl festgelegt ist, der gerade ausgeführt wird.
Nach Ausführung des Befehls mit den übermittelten Eingangsdaten in Schritt 41 wird die Datenzugriffsschutzebene verlassen, Schritt 42.
In Schritt 43 werden Ausgabedaten und ein (kryptographischer) Nachweis der Befehlsbeendigung erzeugt. Nach Schritt 43 wartet das Programm auf neue Kommunikationsgrundelemente, Schritt 36.
Falls keine spezielle Befehlsroutine definiert ist und der Befehl anhand von Prozeduren ausgeführt werden kann, die lediglich aus Betriebssystemfunktionen bestehen, wird nicht in die Datenzugriffsschutzebene (Schritt 40) eingestiegen; der Befehl wird unmittelbar auf der Interaktionskontext- Sicherheitsebene durchgeführt, da die Betriebssystemroutinen so ausgelegt sind, daß sie keinen Datenschutz verletzen.
Wenn in Schritt 38 festgestellt wird, daß keine neue Anwendung aktiviert werden soll, fährt das Programm mit Schritt 44 fort, in dem eine Kontextdeaktivierungsprozedur durchgeführt wird. In Schritt 45 wird die momentane anwendungsspezifische Sicherheitsebene verlassen, und in Schritt 46 werden im Rahmen der Sicherheitsebene des Ausführungsprogramms "MAXOS" die den Befehl begleitenden Daten geprüft.
Wenn der Befehl durch geeignete Authentisierung, wie sie für die verlangte Anwendung spezifiziert ist, zugelassen wird, erfolgt der Einstieg in eine neue anwendungsspezifische CTA- Sicherheitsebene, Schritt 47. Diese Ebene beschränkt den Zugriff auf Daten, welche die neu geöffnete Anwendung betreffen.
Die Datenverarbeitungeinheit 5 erzeugt Daten in Antwort auf einen Kontextaktivierungsbefehl, indem sie eine Initialisierungsanweisung ausführt, wie sie in der Prozedurenliste festgelegt ist, Schritt 48. Wenn eine solche vom Anwendungshersteller codierte Routine vorhanden ist, wird in die Datenzugriffsschutzebene in Schritt 49 eingestiegen. Die Kontextaktivierungsprozedur wird in Schritt 50 durchgeführt. In Schritt 51 wird die Datenzugriffsschutzebene verlassen und die Antwort der anderen Datenverarbeitungeinheit 4 mitgeteilt; die Datenverarbeitungseinheit 4 selbst ist bereit, nach dem oben angegebenen Schritt 43 einen neuen Befehl zu erhalten.
Nach der Beschreibung der Figuren 1 bis 5 werden nun einige allgemeine Bemerkungen über das erfindungsgemäße Datenaustauschsystem gemacht.
Die Codes in der Prozedurbibliothek innerhalb jeder Anwendungsbeschreibung 18(1), 18(2) können dadurch erweitert werden, daß eine Spezifikation der Verwendung ihrer Operationsparameter in Klassen eingefügt wird, welche sich auf Attribute beziehen, die Datenelemente betreffen, welche als tatsächlicher Wert in einer Berechnung genommen werden können, welche Berechnung nur dann fortschreitet, wenn die Datenattribute und die Parameterklassen zueinander passen. Dies stellt einen Weg bereit, Zugriffsbedingungen sowohl für Datenelemente als auch für Funktionen zu verifizieren. Der Vergleich von geeignet codierten Bitkarten (engl. : "bitmaps") von Datenattributen bzw. Parameterklassen kann eine effiziente Realisierung dieser zusätzlichen Technik vorsehen.
Das Ausführungsprogramm 12, 17 kann einen Verweis auf einen Interaktionskontext umfassen, der dazu verwendet wird, den momentanten Interaktionkontext in dem Speicherelement 20 zu initialisieren, das einen Verweis auf den Interaktionskontext speichert, der gerade in Kraft ist. Durch diese Maßnahme ist es möglich, eine Endaktion nach einer Erfassung einer internen Inkonsistenz bei einer Wiederaufnahme eines normalen Operationszustands durchzuführen oder wann immer das Ausführungsprogramm 12, 17 aktiv ist und kein expliziter Interaktionskontext durch ein von der anderen Datenverarbeitungseinheit 5 erhaltenes Kommunikationsgrundelement spezifiziert worden ist. Dieser Standardinteraktionskontext kann sehr gut ein solcher Kontext sein, der in der Kartenbesitzeranwendung enthalten ist, wie sie oben beschrieben wurde.
Zusätzlich kann die Speichereinrichtung 9, 16 einen Interaktionskontext 11, 19 umfassen, dessen Zweck es ist, persönliche Identifizierungsnummern (PINs) zu umfassen, wobei das Ausführungsprogramm 12, 17 dazu ausgebildet ist, von einem Benutzer des Datenaustauschsystems gelieferte persönliche Identifizierungsnummern zu verifizieren. Es können mehrere solcher persönlichen Identifizierungsnummern - Paßwörter - verwendet werden. Ein solches Paßwort kann dazu verwendet werden, den Gebrauch der Einrichtung bei Transaktionen zu schützen, bei denen geheimhaltungsempfindliche Daten offenbart werden können. Ein zweites Paßwort kann dazu verwendet werden, Transaktionen zu schützen, bei denen Daten mitgeteilt werden, die einen von dem Paßwortbesitzer zahlbaren Wert darstellen. Ein drittes Paßwort kann dazu verwendet werden, Transaktionen zu schützen, bei denen Operationen durchgeführt werden, die als kritisch für die Sicherheit der Anwendung angesehen werden, wie etwa Schutzbetriebsarten, die in Anspruch genommen werden, so wie in jedem der Interaktionskontexte 11, 19 spezifiziert, die dies benötigen können. Es können weitere Paßwörter vorgesehen sein. Dieser PIN-Verwaltungsinteraktionskontext kann sehr gut ein solcher Kontext sein, der in der Kartenbesitzeranwendung enthalten ist, wie sie oben beschrieben wurde.
Jede Anwendungsbeschreibung 13, 18 kann eine Liste von numerischen Werten umfassen, die so aufgebaut ist, daß sie Bezeichner für alle Interaktionskontexte 11, 19 bereitstellt, und jede Anwendungsbeschreibung 13, 18 kann wenigstens einen ersten numerischen Wert umfassen, der einen Anwendungstyp angibt, einen zweiten numerischen Wert, der eine ausschließliche Bezeichnung des Bereitstellers der Anwendung angibt, einen dritten numerischen Wert, der die Art der Anwendungsbeschreibung 13, 18 angibt, und weitere Zahlen bzw. Nummern, die sich jeweils ausschließlich auf einen Interaktionskontext 11, 19 beziehen. Die ersten beiden Zahlen können nach im Markt wohl etablierten Regeln zugewiesen werden, wogegen die übrigen Zahlen seitens des Anwendungsherstellers so gewählt werden können, wie es geeignet erscheint. Speziell kann er numerische Werte zuweisen, um zwischen verschiedenen Versionen der Implementierung zu unterscheiden oder die Erzeugung des Satzes von kryptographischen Schlüsseln zu identifizieren, die seitens der Anwendung bei deren kryptographischen Berechnungen benutzt werden. Zusätzlich kann die Einrichtung in der Rücksetzantwortnachricht eine Liste einer Identifizierungsnummer für jeden der in ihrer Speichereinrichtung enthaltenen Interaktionskontexte 11, 19 umfassen, welche Identifizierungsnummer aus den mit dem Interaktionskontext gespeicherten eigenen Identifizierungswerten aufgebaut ist. Das erste Element in der Liste von Interaktionskontext-Identifizierungsnummern kann eine Bezeichnung für den Standardkontext sein.
Die Datenkommunikationseinrichtungen 7, 14 sind vorzugsweise so ausgeführt, daß sie den Datenaustausch in Datenblöcke strukturieren. Diese Blöcke von Daten umfassen wenigstens zwei Teile, wobei ein erster Teil Daten sind, die insofern als operationsrelevant qualifiziert sind, als sie dazu verwendet werden, die Art der Operationen zu beeinflussen, die durch einen Befehl durchgeführt werden, wie er durch ein Kommunikationsgrundelement angegeben ist, oder von Daten, welche aus durchgeführten Operationen resultieren. Ein zweiter Teil wird insofern als sicherheitsrelevant qualifiziert, als er dazu verwendet wird, die Eignung zur Durchführung einer Operation oder der Akzeptierbarkeit von Daten in dem operationsrelevanten Teil zu bestimmen, um in der Operation verwendet zu werden, oder die Beendigung der Operation oder die Korrektheit der offenbarten Daten nachzuweisen.
Wenn die Daten in dieser Weise strukturiert sind, kann das Ausführungsprogramm 17 so ausgelegt sein, daß es bei Akzeptierung eines Kommunikationsgrundelements zur Durchführung von in dem momentanen Interaktionskontext 20, 21 spezifizierten Operationen jede Operation als Teil einer vorbestimmten und festen Folge von Aktionen durchführt, die jeweils gesondert als Teil einer dem akzeptierten Kommunikationsgrundelement zugeordneten Prozedurbeschreibung spezifiziert sind. Eine erste Aktion kann als Funktion zur Authorisierung der Verwendung des Kommunikationsgrundelements an diesem Punkt in der Folge von Kommunikationen spezifiziert sein. Eine zweite Aktion kann als Funktion zur Entschlüsselung der Operationsdaten oder eines Teils derselben spezifiziert sein, wogegen eine dritte Aktion als die eigentliche Operationsprozedur spezifiziert sein kann. Ein vierter Teil kann zur Verschlüsselung von Operationsdaten, die aus den durchgeführten Operationen resultieren, spezifiziert sein, und eine fünfte Aktion kann als Funktion spezifiziert sein, um einen Nachweis der Beendigung der durchgeführten Aktion oder der Korrektheit der resultierenden Daten zu berechnen oder in Sicherheitsbereichnungen in der empfangenden Datenverarbeitungseinheit verwendet zu werden. Diese Aktionen werden durch das Flußdiagramm der Figur 5 wiedergegeben.
Darüber hinaus kann die Datenverarbeitungseinheit in ihrer Rücksetzantwortnachricht eine Zahl enthalten, die derart gewählt ist, daß ihr Wert durch die empfangende Datenverarbeitungseinheit 4 unvorhersagbar ist, und die als Basis für kryptographische Berechnungen dienen kann. Eine derartige Zahl kann als "Kartentransaktionszahl" bezeichnet werden.
Für ein Kommunikationsgrundelement wird ein spezifizierter, zugewiesener Wert vorgesehen sein, der stets als Anforderung interpretiert wird, in einen neuen Interaktionskontext 11, 19 einzusteigen. Dieses Kommunikationsgrundelement kann als "Aktivierungsbefehl" bezeichnet werden. Die den Aktivierungsbefehl begleitenden Daten spezifizieren in ausreichender Weise den zu aktivierenden Kontext, indem sie möglicherweise auf die Identifizierungsnummern verweisen, welche als Teil der Rücksetzantwortnachricht mitgeteilt wurden. Die in Antwort auf den Aktivierungsbefehl durchgeführten Aktionen werden erstens durch die Prozedurbeschreibung beschrieben, die in dem Kontext enthalten ist, der das als zur Deaktivierung bezeichnete Grundelement akzeptiert, und zweitens in der Prozedurbeschreibung, die zur Aktivierung bezeichnet ist und in dem Kontext enthalten ist, dessen Einstieg spezifiziert ist.
Vorzugsweise umfaßt das zum Einstieg in einen spezifizierten Interaktionskontext 11, 19 verwendete Kommunikationsgrundelement numerische Werte, die in Sicherheitsberechnungen in nachfolgenden Kommunikationen zu verwenden sind. Ein erster Zufallswert kann durch eine der Verarbeitungseinheiten 4, 5 erzeugt werden, und ein zweiter Wert kann zur Identifizierung dieser einen Verarbeitungseinheit dienen. Diese Identifizierung kann das Ergebnis von Berechnungen sein, die derart sind, daß der resultierende Wert die Vorrichtung und den Zustand ihres Speichers ausreichend identifiziert, wie für Berechnungen oder andere Aktionen erforderlich ist, die in nachfolgenden Datenaustauschvorgängen in dem zu aktivierenden Interaktionskontext 11, 19 erfolgen können. Der zweite Wert kann als "Endgeräteidentifizierung" bezeichnet werden.
Zusätzlich gibt der Aktivierungsbefehl als Teil der resultierenden Daten einen numerischen Wert, welcher dazu dient, die spezielle antwortende Datenverarbeitungseinheit ausreichend zu identifizieren, wie für Berechnungen oder andere Aktionen erforderlich, die in nachfolgenden Datenaustauschvorgängen im soeben aktivierten Kontext erfolgen können, welche Zahl als "Chipkartenidentifizierung" bezeichnet werden kann.
Daneben kann die Chipkartenidentifizierungsnummer unter Verwendung kryptographischer Funktionen aus in der Datenverarbeitungseinheit 5 gespeicherten Daten oder aus den als Teil des Aktivierungsbefehls erhaltenen Daten in solcher Weise berechnet werden, daß die Nummer in unvorhersagbarer Weise variiert, wenn sie in Antwort auf Aktivierungsbefehle berechnet wird, die von auslösenden Vorrichtungen mit unterschiedlichen Endgeräteidentifizierungsnummern erhalten werden; eine so berechnet Chipkartenidentifizierung kann als "Chipkartenpseudonym" bezeichnet werden. Bevor die in der Prozedurbeschreibung der Aktivierungsprozedur eines einzusteigenden Kontexts beschriebenen Aktionen durchgeführt werden, kann darüber hinaus das Ausführungsprogramm eine kryptographische Berechnung durchführen, welche als Teil der Prozedurbeschreibung in diesem Kontext spezifiziert ist und dazu bestimmt ist, bei Aktivierung durchgeführt zu werden, um zu bestimmen, ob der Kontext aktiviert werden kann. Die Berechnungen können die Verwendung der Chipkartentransaktionsidentifizierung, der Endgerätetransaktionsidentifizierung und der Endgeräteidentifizierung sowie anderer Werte, die in der Speichereinrichtung gespeichert sind, miteinbeziehen.
Als Alternative zu derartigen speziellen Berechnungen, die mit speziellen Daten unterstützt werden, bei der Durchführung von Befehlen können Befehle mit einer Bitfeldspezifikation von Datenelementen verwendet werden, auf die verwiesen wird. Jedes Kommunikationsgrundelement ist dann aus zwei oder mehr numerischen Werten zusammengesetzt, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer festen Zahl von Binärwerten zusammengesetzt ist, die durch das Ausführungsprogramm 12, 17 jeweils als Verweis auf ein einzelnes Datenelement interpretiert werden. Dieses Datenelement ist in der Liste externer Datenverweise in dem betreffenden Interaktionskontext 11, 19 spezifiziert, wobei jedes Datenelement in der Liste durch das Vorhandensein eines binären Werts einer der binären Zahlen an einer entsprechenden Position in der Liste der Binärwerte spezifiziert ist. Dieser zweite Wert kann als "Operandenadressen" bezeichnet werden. Jedes der Datenelemente, das so spezifiziert ist, wird durch das ablaufende Ausführungsprogramm 12, 17 verfügbar gemacht, um in der Antwortaktion in einer Weise verwendet zu werden, wie sie in der Prozedurbeschreibung dieser Aktion beschrieben sein kann.
Als Alternative zu speziellen Berechnungen mit speziellen Daten und Befehlen mit einer Bitfeldspezifikation von Datenelementen, auf die verwiesen wird, kann ein Befehlsformat mit einer Datenübereinstimmungsspezifikation von Datenelementen zur Anwendung kommen. In diesem Fall ist jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert dazu verwendet wird zu bestimmen, welche der zum externen Verweis in einem aktiven Interaktionskontext 12, 19 verfügbaren Datenelemente verwendet werden, während Antwortaktionen in solcher Weise durchgeführt werden, daß ein Datenelement ausgewählt wird, wenn es einen Wert enthält, der mit dem zweiten Wert übereinstimmt. Dieser zweite Wert kann als "Operandenkennzeichnungsspezifizierer" bezeichnet werden. Zusätzlich kann der Interaktionskontext 11, 19 eine Prozedurbeschreibung enthalten, welche angibt, in welcher Weise ein als Teil eines Befehls gegebener Operandenkennzeichnungsspezifizierer mit Daten zu vergleichen ist, die in einem der zum externen Verweis in diesem Kontext verfügbaren Datenelemente enthalten sind, welche Prozedurbeschreibung durchgeführt wird, um die vorgesehenen Datenelemente auszuwählen, bevor die die eigentlichen Befehlsaktionen spezifizierende Prozedurbeschreibung durchgeführt wird.
Als weitere Alternative kann ein Befehlsformat mit einer Bitfeldspezifikation der Befehlsinterpretation verwendet werden. Jedes Kommunikationsgrundelement ist dann aus zwei oder mehr numerischen Werten zusammengesetzt, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer Anzahl von Binärwerten zusammengesetzt ist, denen durch das Ausführungsprogramm 12, 17 spezielle Bedeutungen zugewiesen sind, um bei der Interpretation von Datenformaten in dem Kommunikationsgrundelement und bei der Durchführung von Antwortaktionen verwendet zu werden. Der zweite Wert kann hier als "Befehlsmodifizierer" bezeichnet werden. Die Werte werden von allen mit dieser zusätzlichen Technik ausgestatteten Einheiten im Hinblick auf ihre zugewiesene Bedeutung erkannt.
Im Fall, daß die letztere Alternativ zur Anwendung kommt, kann der Befehlsmodifizierer einen Binärwert umfassen, welcher bestimmt, ob ein dritter Teil des Befehls als Operandenadresse oder als Operandenkennzeichnungsspezifizierer zu verwenden ist. Der Befehlsmodifizierer kann jedoch als Alternative einen Binärwert umfassen, welcher bestimmt, ob die als Antwort auf den Befehl durchgeführte Operation Daten als ein Datenelement verwendet oder aus einer Verkettung von Datenelementen aufgebaut ist, wobei eines in Verbindung mit jedem Datenelement zu verarbeiten ist, das als Teil des Befehlswerts spezifiziert ist, und zwar unter Verwendung der Operandenadressen oder des Operandenkennzeichnungsspezifizierers. Alternativ kann der Befehlsmodifzierer einen Binärwert umfassen, welcher bestimmt, ob mit dem Befehl bereitgestellte Daten unter Verwendung der Kennzeichnungslängenwert-Methode (englisch: "tag-length-value method") codiert werden, um aufeinanderfolgende verkettete Datenelemente zu unterscheiden.
Eine weitere Option ist, daß der Befehlsmodifizierer einen Binärwert umfassen kann, welcher bestimmt, ob die Durchführung der durch den Befehl vorgegebenen Aktion tatsächlich zu einer effektiven Änderung von in der Datenverarbeitungseinheit 5 (Chipkarte) gespeicherten Daten führt oder in von der Datenverarbeitungseinheit 5 berechneten Daten resultiert oder daß das Befehlsresultat Daten sind, welche den Zustand der Einheit im Hinblick auf die Akzeptierbarkeit des Befehls, die diesen begleitenden Daten, die Größe der Daten, welche aus Berechnungen resultieren können, oder andere diverse Attribute wiedergeben.
In Kürze ist die oben eingeführte, insbesondere zur Implementierung bei Chipkarten geeignete neue Technik das Konzept einer gesonderten Ausführungsumgebung. Bei diesem Ansatz werden die Verarbeitungseinrichtung und andere Resourcen in einem Computer zwischen verschiedenen Anwendungen geteilt, so als wenn die Anwendung der einzige Nutzer des Computers wäre. Aufbauend auf dieser neuen Technik bei Chipkartenimplementierungen wird zusätzlich ein Mechanismus bereitgestellt, um Mehrfachzugriffsbedingungen für Daten zu definieren, die sich eine Anzahl verwandter Anwendungen teilen. Eine zweite, durch die gesonderten Ausführungsumgebungen unterstützte und oben eingeführte Technik ist die Möglichkeit, die funktionale Bedeutung von Befehlen in jeder Umgebung so zu definieren, daß bei jeder Interaktion zwischen zwei entsprechenden Datenverarbeitungseinheiten 4, 5 innerhalb eines Datenaustauschsystems eine minimale Zahl von Befehlen erhalten wird. Schließlich ist es mit der neuen Technik möglich, daß Bezeichnungen, die auf gespeicherte Datenelemente verweisen, innerhalb jedes Kontexts gesondert zugewiesen werden. Der Verweis auf gespeicherte Datenelemente als Teil eines von einer der Datenverarbeitungseinheiten 4, 5 erhaltenen Befehls kann so sehr effizient gemacht werden: Aufgrund der sehr kleinen Zahl von Datenelementen und der kleinen Zahl unterschiedlicher Operationen, die in der heutigen Chipkartenpraxis in jeder Umgebung gesondert verwendet werden, werden nur wenige Bits benötigt, um die Bezeichnung und den Anweisungsraum zu codieren. In ähnlicher Weise werden Zugriffsbedingungen, Methoden zu deren Verifikation und zu diesem Zweck verfügbare kryptographische Operationen bei wirklichen Chipkarten zahlenmäßig sehr beschränkt sein, und sie können sehr effizient in der Zweischicht-Hierarchie der in der Anwendungsbeschreibung 18 enthaltenen Interaktionskontextbeschreibungen 19(1) ... ausgedrückt werden.

Claims

1. Datenaustauschsystem mit wenigstens einer tragbaren Datenverarbeitungseinheit (5), welche eine Datenkommunikationseinrichtung (14), eine Verarbeitungseinrichtung (15) sowie eine Speichereinrichtung (16) umfaßt, wobei die letztere ein Ausführungsprogramm (17) umfaßt, dadurch gekennzeichnet, daß die Speichereinrichtung (16) ferner wenigstens einen Interaktionskontext (19(1) ... 19(m)) umfaßt, welcher die folgende kohärente Datenstruktur beinhaltet:

a. einen Satz von Basis-Kommunikationsgrundelementen (A(1) ...), die immer dann akzeptiert werden, wenn die Datenverarbeitungseinheit (5) mit einer entsprechenden Einheit (4) kommuniziert, wobei die Grundelemente zumindest ein Grundelement umfassen, das dazu verwendet wird, selektiv in einen der Interaktionskontexte (19(1) ...) einzusteigen;

b. einen Satz von Prozedurbeschreibungen (C(1) ...), die die in Antwort auf jedes der akzeptierten Kommunikationsgrundelemente (A(1) ...) durchzuführenden Aktionen definieren und zumindest eine erste Prozedurbeschreibung umfassen, die bei Aktivierung des Interaktionskontextes durchzuführen ist, sowie eine letzte Prozedurbeschreibung, die unmittelbar vor Deaktivierung des Kontextes durchzuführen ist;

c. einen möglicherweise leeren Satz von entweder permanent gespeicherten oder berechneten Datenelementen (H(1) ...), die zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen (C(1) ...) definiert sind, durchgeführt werden;

d. einen möglicherweise leeren Satz von Verweisen auf Datenelemente, welche Verweise den Prozedurbeschreibungen (C(1) ...) zugeordnet sind, wobei die Datenelemente auch möglichen weiteren Interaktionskontexten zugänglich sind und zur Verwendung verfügbar sind, wenn Prozeduren, wie sie in den Prozedurbeschreibungen (C(1) ...) definiert sind, durchgeführt werden;

e. eine möglicherweise leere Datenliste mit einer Liste von Verweisen (B(1) ...) auf Datenelemente, die zum expliziten Verweis als Teil eines Kommunikationsgrundelements (A(1) ...) verfügbar sind, um durch die dem Kommunikationsgrundelement zugeordnete Prozeäurbeschreibung (C(1) ...) verwendet zu werden;

f. einen Satz von Zugriffsbedingungen, die den Datenelementen zugeordnet sind, auf welche im Zusammenhang mit den Prozedurbeschreibungen (C(1) ...) verwiesen wird;

g. einen Satz von Zugriffsbedingungen, die der Liste von Datenverweisen (B(1) ...) in der Datenliste zugeordnet sind.

2. Datenaustauschsystem nach Anspruch 1, dadurch gekennzeichnet, daß die Speichereinrichtung (16) ferner mindestens zwei Interaktionskontexte (19(1) ... 19(m)), mindestens eine Anwendungsbeschreibung (18(1) ...) sowie ein Speicherelement (20) umfaßt, das einen Verweis auf den Interaktionskontext speichert, der momentan in Kraft ist, wobei jede Anwendungsbeschreibung umfaßt:

a. eine Datenliste mit Verweisen (E(1) ...) auf Datenelemente, welche Verweise zwei oder mehr Interaktionskontexten (19(1) ...) zugänglich sind und durch zusätzliche Datenelemente erweitert sein können;

b. einen weiteren Satz von Zugriffsbedingungen, die den Verweisen (E(1) ...) oder den zusätzlichen Datenelementen zugeordnet sind und Nutzungsbeschränkungen festlegen.

3. Datenaustauschsystem nach Anspruch 2, dadurch gekennzeichnet, daß jede Anwendungsbeschreibung (18(1) ...) außerdem eine Prozedurbibliothek mit ausführbaren Codeeinheiten (F(1) ...) umfaßt, welche durch Prozedurbeschreibungen (C(1) ...) jedes Interaktionskontextes verwendet werden können, der jeder der Anwendungsbeschreibungen (18(1) ...) zugeordnet ist.

4. Datenaustauschsystem nach Anspruch 2 oder 3, dadurch gekennzeichnet, daß die Speichereinrichtung mindestens zwei Anwendungsbeschreibungen (18(1) ...) und ausführbare Codeeinheiten (G(1) ...) umfaßt, welche durch Prozedurbeschreibungen (C(1) ...) jedes Interaktionskontextes (19(1) ...) innerhalb jeder Anwendungsbeschreibung (18(1) ...) oder durch jede ausführbare Codeeinheit (F(1) ...) jeder Prozedurbibliothek innerhalb jeder Anwendungsbeschreibung (18(1) ...) verwendet werden können.

5. Datenaustauschsystem nach einem der Ansprüche 3 oder 4, dadurch gekennzeichnet, daß die ausführbaren Codeeinheiten in der Prozedurbibliothek dadurch vergrößert sind, daß eine Spezifikation der Verwendung ihrer Operationsparameter in Klassen eingefügt ist, welche sich auf Attribute beziehen, die Datenelemente betreffen, welche als tatsächlicher Wert in einer Berechnung genommen werden können, welche Berechnung nur dann fortschreitet, wenn die Datenattribute und die Parameterklassen zueinander passen.

6. Datenaustauschsystem nach einem der Ansprüche 2 bis 5, dadurch gekennzeichnet, daß das Ausführungsprogramm (17) einen Verweis auf einen Standardinteraktionskontext umfaßt, welcher dazu verwendet wird, das Speicherelement (20) zu initialisieren, das einen Verweis auf den momentan in Kraft befindlichen Interaktionskontext speichert, um eine Endaktion nach einer Erfassung einer internen Inkonsistenz bei einer Wiederaufnahme eines normalen Operationszustands durchzuführen oder wann immer das Ausführungsprogramm (17) aktiv ist und kein expliziter Interaktionskontext durch ein von einer gegenüberliegenden Datenverarbeitungseinheit (4) erhaltenes Kommunikationsgrundelement spezifiziert worden ist.

7. Datenaustauschsystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Speichereinrichtung (16) einen Interaktionskontext umfaßt, dessen Zweck es ist, persönliche Identifizierungsnummern zu umfassen, und daß das Ausführungsprogramm (17) dazu ausgelegt ist, von einem Benutzer des Datenaustauschsystems gelieferte persönliche Identifizierungsnummern zu verifizieren.

8. Datenaustauschsystem nach einem der Ansprüche 2 bis 7, dadurch gekennzeichnet, daß jede Anwendungsbeschreibung (18(1) ...) eine Liste von numerischen Werten umfaßt, die so aufgebaut ist, daß sie Bezeichner für alle Interaktionskontexte (19(1) ...) bereitstellt, und zumindest einen ersten numerischen Wert umfaßt, welcher einen Anwendungstyp angibt, einen zweiten numerischen Wert, welcher eine ausschließliche Bezeichnung des Bereitstellers der Anwendung angibt, einen dritten numerischen Wert, welcher die Art der Anwendungsbeschreibung (18(1) ...) angibt, und weitere Nummern, die sich jeweils ausschließlich auf einen der Anwendungsbeschreibung zugeordneten Interaktionskontext (19(1) ...) beziehen.

9. Datenaustauschsystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Kommunikationseinrichtung (14) so ausgeführt ist, daß sie den Datenaustausch in Datenblöcke strukturiert, welche wenigstens zwei Teile umfassen, wobei ein erster Teil Daten sind, die insofern als operationsrelevant qualifiziert sind, als sie dazu verwendet werden, die Art der Operationen zu beeinflussen, die durch einen Befehl durchgeführt werden, wie er durch ein Kommunikationsgrundelement angegeben ist, oder von Daten, welche aus durchgeführten Operationen resultieren, wobei ein zweiter Teil insofern als sicherheitsrelevant qualifiziert ist, als er dazu verwendet wird, die Eignung zur Durchführung einer Operation oder der Akzeptierbarkeit von Daten in dem operationsrelevanten Teil zu bestimmen, um in der Operation verwendet zu werden, oder die Beendigung der Operation oder die Korrektheit der resultierenden Daten nachzuweisen.

10. Datenaustauschsystem nach Anspruch 9, dadurch gekennzeichnet, daß das Ausführungsprogramm (17) so ausgelegt ist, daß es bei Akzeptierung eines Kommunikationsgrundelements zur Durchführung von in dem momentanen Interaktionskontext (19(1) ...) spezifizierten Operationen jede Operation als Teil einer vorbestimmten und festen Folge von Aktionen durchführt, die jeweils gesondert als Teil einer dem akzeptierten Kommunikationsgrundelement zugeordneten Prozedurbeschreibung spezifiziert sind, welche Aktionen zumindest die folgenden Aktionen umfassen:

a. Authorisierung der Verwendung des Kommunikationsgrundelements;

b. Entschlüsselung der Operationsdaten oder eines Teils derselben;

c. Durchführen eines Befehls mit Eingangsdaten;

d. Verschlüsselung von Operationsdaten, die aus einer durchgeführten Operation resultieren;

e. Berechnung eines Nachweises der Beendigung einer durchgeführten Aktion oder der Korrektheit der resultierenden Daten, um in Sicherheitsberechnungen verwendet zu werden.

11. Datenaustauschsystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Datenverarbeitungseinheit (5) bei Initialisierung des Datentransfers eine zufällige Transaktionsnummer erzeugt, die als Basis für kryptographische Berechnungen dient.

12. Datenaustauschsystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß einem Kommunikationsgrundelement ein spezifizierter Wert zugewiesen ist, der stets als Anforderung interpretiert wird, in einen neuen Interaktionskontext (19(1) ...) einzusteigen.

13. Datenaustauschsystem nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß es eine weitere Datenverarbeitungseinheit (4) umfaßt, welche die gleichen Elemente wie die Datenverarbeitungseinheit (4) umfaßt, die optional in ihrem Speicher eine Anwendungsprogrammiererschnittstelle (10) enthalten kann, welche aus einem Programmcode besteht, der so ausgeführt ist, daß er die Implementierung zusätzlicher Computerprogramme erlaubt, um Benutzern die Kontrolle über die Abfolge ausgetauschter Kommunikationsgrundelemente zu geben oder um die darin transferierten Daten zu beeinflussen oder die beim Austausch erhaltenen Daten zu lernen oder weiterzuverarbeiten.

14. Datenaustauschsystem nach Anspruch 13, dadurch gekennzeichnet, daß das zum Einstieg in einen spezifizierten Interaktionskontext (19(1) ...) verwendete Grundelement numerische Werte umfaßt, die bei Sicherheitsberechnungen in nachfolgenden Kommunikationen zu verwenden sind, einen ersten, durch eine der Verarbeitungseinheiten erzeugten Zufallswert sowie einen zweiten, der Identifizierung dieser einen Verarbeitungseinheit dienenden Wert.

15. Datenaustauschsystem nach Anspruch 13, dadurch gekennzeichnet, daß jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt ist, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer festen Zahl von Binärwerten zusammengesetzt ist, die durch das Ausführungsprogramm (12; 17) jeweils als Verweis auf ein einzelnes Datenelement interpretiert werden.

16. Datenaustauschsystem nach Anspruch 13, dadurch gekennzeichnet, daß jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt ist, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert dazu verwendet wird zu bestimmen, welche der zum externen Verweis in einem aktiven Interaktionskontext (19(1) ...) verfügbaren Datenelemente verwendet werden, während Antwortaktionen in solcher Weise durchgeführt werden, daß ein Datenelement ausgewählt wird, wenn es einen Wert enthält, der mit dem zweiten Wert übereinstimmt.

17. Datenaustauschsystem nach Anspruch 13, dadurch gekennzeichnet, daß jedes Kommunikationsgrundelement aus zwei oder mehr numerischen Werten zusammengesetzt ist, wobei ein erster Wert dazu verwendet wird, auf eine Prozedurbeschreibung einer dem Kommunikationsgrundelement zugeordneten Aktion zu verweisen, wobei ein zweiter Wert aus einer Anzahl von Binärwerten zusammengesetzt ist, denen durch das Ausführungsprogramm (12, 17) spezielle Bedeutungen zugewiesen sind, um bei der Interpretation von Datenformaten in dem Kommunikationsgrundelement und bei der Durchführung von Antwortaktionen verwendet zu werden.