DE69710588T2

DE69710588T2 - In chipkarten gespeicherte tickets

Info

Publication number: DE69710588T2
Application number: DE69710588T
Authority: DE
Inventors: Marco Drupsteen; Frank Muller
Original assignee: Koninklijke KPN NV
Current assignee: Koninklijke KPN NV
Priority date: 1996-08-09
Filing date: 1997-08-07
Publication date: 2002-09-05
Anticipated expiration: 2017-08-08
Also published as: EP0823694A1; CA2262760A1; ES2172809T3; NZ334055A; AU718123B2; US6119945A; AU4118097A; ATE213558T1; CA2262760C; EP0920681B1; EP0920681A1; WO1998007120A1; DE69710588D1

Description

Technischer Hintergrund der Erfindung

Die vorliegende Erfindung betrifft in Chipkarten gespeicherte Tickets sowie Chipkarten zum Speichern von Tickets und ein Verfahren zum Benutzen von Tickets, die auf Chipkarten gespeichert sind. Insbesondere, aber nicht ausschliesslich, bezieht sich die vorliegende Erfindung auch auf das sichere Speichern von "offenen" Tickets in Chipkarten, d. h. Tickets, von denen ein bestimmtes Datum und/oder Zeit der Benutzung offen gelassen wird, wenn das Ticket ausgegeben wird. Insbesondere betrifft die vorliegende Erfindung das sichere Speichern, die Validierung und/oder die Verifizierung von Tickets, die auf Chipkarten gespeichert sind, solche Chipkarten und ein Zahlungssystem, welches diese einsetzt.
Derzeitige Chipkarten bieten eine Vielzahl von Anwendungsmöglichkeiten, von denen eine das elektronische Portemonnaie ist. Andere mögliche Anwendungen sind die Identifikation (Benutzerverifikation), das Speichern von wesentlichen Daten (z. B. medizinischen Daten), das Sammeln von Kundenbindungsprämien und Ähnlichem. Eine solche Anwendung ist das Speichern von Tickets, d. h. von Zugriffsrechten zu Gütern und/oder Dienstleistungen.
Verschiedene Arten von Tickets sind möglich. Eine erste Art von Tickets, welche ausgegeben werden kann, enthält alle wesentlichen Daten, so wie (z. B. im Falle eines Flugtickets), die betreffende Firma (Fluglinie), den Preis, den Reisetag, den Platz und die Abflugzeit sowie Ort und Zeit der Ankunft. Solch ein Ticket ist dann direkt einsetzbar. Eine zweite Art von Ticket ist nicht direkt einsetzbar, da z. B. der Reisetag nach der Ausgabe des Tickets einzufüllen ist. Solch ein "offenes" Ticket muss validiert werden, bevor es eingesetzt werden kann: das Ticket wird validiert, indem der Reisetag und andere notwendige Daten eingefüllt werden. Solch ein "offenes" Ticket kann für einen mehrfachen Einsatz geeignet sein, falls es mehr als einmal validiert werden kann.
Beispiele von Tickets, die auf Chipkarten gespeichert sind, sind aus dem Stand der Technik bekannt. Die holländische Patentanmeldung NL 93 01902, zum Beispiel, beschreibt ein Verfahren zum Erhalt eines Rechtes zu einer Dienstleistung durch eine Chipkarte (IC-Karte). Bei diesem Verfahren nach dem Stand der Technik dient die Karte sowohl als Zahlungsmittel als auch als Registrierungsmittel. Dies bedeutet, dass die Karte eingesetzt wird, um den Beweis der Zahlung für die bezahlte Dienstleistung zu speichern und so aus Papier bestehende Tickets zu ersetzen. Der Einsatz von Mehrfachtickets, d. h. Tickets, die mehr als einmal eingesetzt werden können, wird auch in dieser besagten Patentanmeldung erwähnt.
In dem Verfahren der oben genannten holländischen Patentanmeldung wird ein Ticket auf einer Karte gespeichert, indem auf der Karte ein Zugangscode registriert wird, optional in Kombination mit einem Kartenidentifikationscode. An dem Eingabegerät von z. B. einem Theater wird der Zugangscode und (optional) der Identifikationscode geprüft, woraufhin der Zugangscode von der Karte gelöscht wird. Die Art und Weise, wie Mehrfachtickets umgesetzt werden oder eingesetzt werden, ist nicht beschrieben.
Die oben genannte holländische Patentanmeldung liefert daher kein spezifisches Verfahren zum sicheren Speichern von Tickets auf Chipkarten und insbesondere nicht für Tickets, die nach der Ausgabe validiert werden können.
Die europäische Patentanmeldung EP 0 658 862 beschreibt ein Verfahren und ein System zum Einsatz von mehrfach funktionalen Chipkarten durch das Mittel eines Kommunikationssystems. Dieses Verfahren nach dem Stand der Technik und das System gestatten z. B., dass Flugtickets auf Chipkarten gespeichert werden. Die spezifische Art und Weise, in der Tickets gespeichert werden, ist jedoch nicht beschrieben.
Zusätzlich beschreibt die europäische Patentanmeldung EP 0 380 377 ein System zur elektronischen Bezahlung von Transporten und Dienstleistungen durch das Mittel von Chipkarten. In dem System der besagten Patentanmeldung wird ein Ticket beschrieben, welches Felder hat zum Stempeln des Tickets auf einen bestimmten Tag an einer bestimmten Zeit und Felder zum Speichern von Daten, die darauf hinweisen, dass das Ticket überprüft worden ist. Ausser der Tatsache, dass Ticketdaten gespeichert werden, werden keine weiteren Merkmale beschrieben.
Übliche elektronische Tickets sind leicht betrügerischen Machenschaften zugänglich, indem Ticketdaten unverfolgbar geändert werden können. Wobei solch eine betrügerische Manipulation von Papiertickets oft sichtbar ist oder sehr sorgfältig ausgeführt werden muss, um nicht sichtbar zu sein, liefert die Veränderung von Bits auf einer Chipkarte in der Regel keine Spuren. Insbesondere im Falle von offenen Tickets, wo verschiedene Stationen das Ticket "stempeln" können, um eine Validierung oder eine Verifizierung durchzuführen, besteht das Problem des möglichen Betruges.

Zusammenfassung der Erfindung

Es ist ein Ziel der vorliegenden Erfindung, die oben genannten und andere Nachteile des Standes der Technik zu überwinden und eine Chipkarte zu liefern, die es gestattet, dass Tickets in sicherer Weise gespeichert werden.
Es ist ein weiteres Ziel der vorliegenden Erfindung, eine Chipkarte zu liefern, die in virtueller Weise die Möglichkeit der betrügerischen Ausgabe oder Validierung von Tickets vermeidet.
Es ist ein weiteres Ziel der vorliegenden Erfindung, eine Chipkarte zu liefern, die das sichere "Stempeln", d. h. die sichere verfolgbare Verifizierung von Tickets gestattet.
Es ist ein weiteres Ziel der vorliegenden Erfindung, eine Chipkarte einzusetzen, die den Einsatz von sicheren offenen Tickets gestattet, d. h. Tickets, die eine nicht vorbestimmte Gültigkeitsdauer oder -datum oder -Zeit aufweisen.
Es ist ein weiteres Ziel der vorliegenden Erfindung, sowohl ein Verfahren zum sicheren Speichern von Tickets auf Chipkarten als auch ein System anzugeben, in dem dieses Verfahren eingesetzt werden kann.
Demgemäss liefert die vorliegende Erfindung eine Chipkarte mit einem integrierten Schaltkreis mit einem Prozessor und einem Speicher, wobei der Speicher so strukturiert ist, um Tickets zu umfassen, welches Ticket mindestens ein Feld zum Speichern von Daten aufweist, welche sich auf das Ticket beziehen, wobei die Chipkarte Mittel zum Speichern von Daten umfasst, die einen Code umfassen, der eine feste Anzahl von gesetzten Bits pro Bitgruppe umfasst.
Indem ein Code eingesetzt wird, der eine feste Anzahl von gesetzten Bits umfasst, kann in einfacher Weise verifiziert werden (durch das Prüfen der Anzahl der gesetzten Bits des Codes), ob die Daten korrekt sind, womit ein Betrug in effizienter Weise verhindert werden kann. Vorzugsweise umfasst der Code Codewörter mit acht Bits, wobei die Anzahl von gesetzten Bits in jedem Codewort vier ist.
Vorteilhafterweise umfasst das Ticket ein Berechtigungsfeld und ein Validierungsfeld. Indem getrennte Berechtigungs- und Validierungsfelder vorgesehen werden, ist es möglich, ein Ticket in zwei Stufen auszugeben: zuerst wird das Ticket von einem ersten Endgerät ausgegeben, während z. B. das Validitätsdatum offen gelassen wird, und zu einem späteren Zeitpunkt wird das Ticket von einem zweiten Endgerät validiert, z. B. durch Registrierung des Gültigkeitsdatums in dem Validierungsfeld. Bei beiden Arten von Feldern wird der oben genannte Code eingesetzt.
Vorzugsweise umfasst ein Ticket gemäss der vorliegenden Erfindung weiterhin mindestens ein Verifizierungsfeld zum Speichern von Verifizierungsdaten. Ein Verifizierungsfeld liefert die Möglichkeit, Verifizierungsinformationen zu registrieren, die beispielsweise durch ein drittes Endgerät ausgegeben werden können. Obwohl die besagten ersten, zweiten und dritten Endgeräte getrennte Vorrichtungen sein können, werden sie in manchen Anwendungen identisch sein.
In Bezug auf das kodierte Speichern von Ticketdaten ist der integrierte Schaltkreis der Chipkarte in vorteilhafterweise eingerichtet um, wenn das Ticket ausgegeben wird, in exklusiver Weise Daten in dem Validierungsfeld zu speichern, indem ein erster Befehl eingesetzt wird, der nur fähig ist, einen ersten Wert zu speichern (z. B. die logische Null), und um, zum Validieren des Tickets, ausschliesslich Daten im Validierungsfeld zu speichern, unter Einsatz eines zweiten Befehls, der nur fähig ist, einen zweiten unterschiedlichen Wert zu speichern (z. B. eine logische Eins). In dieser Art und Weise ist es unmöglich, die Berechtigung während der Validierung oder während der Verifizierung zu ändern oder die Validierung während der Verifizierung zu ändern.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt in schematischer Weise eine Chipkarte, wie sie beim Verfahren der vorliegenden Erfindung eingesetzt werden kann,
Fig. 2 zeigt in schematischer Weise den integrierten Schaltkreis der Chipkarte nach Fig. 1,
Fig. 3 zeigt in schematischer Weise die Struktur eines Tickets, wie es in einer Chipkarte gespeichert ist,
Fig. 4 zeigt in schematischer Weise die Art und Weise, in der ein Feld eines Tickets gemäss der vorliegenden Erfindung kodiert werden kann,
Fig. 5 zeigt in schematischer Weise ein Diagramm, welches die Ausgabe eines Tickets darstellt,
Fig. 6 zeigt in schematischer Weise ein Diagramm, welches die Validierung eines Tickets darstellt,
Fig. 7 zeigt in schematischer Weise ein Diagramm, welches die Verifizierung eines Tickets darstellt und
Fig. 8 zeigt in schematischer Weise ein System, in dem das Verfahren der vorliegenden Erfindung eingesetzt wird.

Beschreibung der bevorzugten Ausführungsbeispiele

Die Chipkarte oder IC-Karte 1, die in beispielhafter Weise und nur schematisch in der Fig. 1 dargestellt ist, umfasst ein Substrat 2, in dem ein integrierter Schaltkreis eingelassen ist. Der integrierte Schaltkreis, der weiter unter Bezugnahme auf die Fig. 2 beschrieben werden wird, ist mit Kontakten 3 versehen, zum Kontaktieren eines Kartenlesers oder Ähnlichem. Es ist festzuhalten, dass die vorliegende Erfindung auch im Falle von sogenannten kontaktlosen Chipkarten angewendet werden kann.
Der integrierte Schaltkreis 10, der in schematischer Weise in der Fig. 2 dargestellt ist, umfasst ein Prozessor 11, einen Speicher 12 und einen Eingangs-/Ausgangsschaltkreis 13. Der Speicher kann ein flüchtiges (RAM) Speicherteil zum zeitweisen Speichern von Daten und einen nicht-flüchtigen (ROM) Speicherteil zum permanenten oder semi-permanenten Speichern von Daten aufweisen. Der zuletzt genannte Teil ist vorzugsweise ein EEPROM Speichertyp. Die in dem nicht-flüchtigen Teil gespeicherten Daten können sowohl Programmierdaten (Befehle, Programme) und Zahlungsdaten umfassen, d. h. Daten, die sich auf monetäre Transaktionen beziehen. Es ist wohlverstanden, dass ein getrennter Speicher (der nicht dargestellt ist) vorgesehen sein kann, um den Befehlssatz des Prozessors 11 zu speichern.
Ein Ausführungsbeispiel eines Tickets, wie es in der vorliegenden Erfindung eingesetzt werden kann, ist in schematischer Weise in der Fig. 3 dargestellt. Das Ticket 20 umfasst mehrere Felder, d. h. ein Berechtigungsfeld 21, ein Validierungsfeld 22 und zwei Verifizierungsfelder 23 und 24. In der Praxis kann ein Ticket auch zusätzliche Felder umfassen, die in der Fig. 3 nicht dargestellt sind. Auch kann ein Ticket nur ein Verifizierungsfeld umfassen oder mehr als zwei Verifizierungsfelder, z. B. drei, vier oder zehn.
Es ist wohlverstanden, dass das Ticket 20 implementiert werden kann, indem Speicherorte von dem Speicher 12 den jeweiligen Feldern zugewiesen werden, und dass in aktuellen Umsetzungen die Speicherorte nicht benachbart sein müssen.
Das Berechtigungsfeld 21 umfasst die Beschreibung des Tickets inklusive z. B. der Identität des Ticketausgebers, der Reichweite der Gültigkeit (z. B. ein Verfallsdatum, die maximale Länge der Reise), die Anzahl der Personen, für welche das Ticket gültig ist und ein Startpunkt und ein Ziel einer Reise, obwohl diese Daten und Teile davon auch in dem Validierungsfeld nach der Ausgabe des Tickets eingegeben werden können. Das Berechtigungsfeld 21 kann z. B. 25 Byte umfassen.
Das Validierungsfeld 22 ist für Informationen reserviert, die später dem Ticket hinzugefügt werden können, wie eine Startzeit und/oder ein Gültigkeitsdatum. Das Berechtigungsfeld 21 und das Validierungsfeld 22 zusammengenommen, sollten genügend Daten umfassen, dass das Ticket gültig ist, während die tatsächliche relative Zuordnung von Daten zu diesen zwei Feldern unterschiedlich sein kann. Das Validierungsfeld 22 kann z. B. 12 Byte umfassen.
Die Verifizierungsfelder 23 und 24 sind für Informationen reserviert, die während des Einsatzes des Tickets hinzugefügt werden können, wie z. B. das Datum, die Zeit und eine Endgerätidentifizierung. Ein Code, der ein bestimmtes Transportmittel identifiziert (z. B. einen Zugcode), kann auch hinzugefügt werden. Die Verifizierungsfelder 23 und 24 können z. B. jeweils 22 Byte umfassen.
Das Validierungsfeld 22 macht es somit möglich, ein "offenes" Ticket auszugeben, welches zu einem späteren Zeitpunkt vervollständigt werden kann. Zum Ausgabezeitpunkt werden nur die wesentlichen Daten in das Berechtigungsfeld 21 eingetragen. Zum Zeitpunkt der Validierung wird das Ticket komplettiert durch Eingeben der verbleibenden Daten (sowie z. B. das Gültigkeitsdatum) in dem Validierungsfeld 22. Die Verifizierungsfelder 23 und 24 gestatten eine Prüfung der Verifizierung, welche in das Ticket einzugeben ist (Verifizierungsstempel). Solch ein Beweis der Verifizierung kann den Beweis der Benutzung des Tickets darstellen, den Beweis der Anwesenheit der Karte (Träger) an einem bestimmten Ort oder einem bestimmten Zeitpunkt und so weiter.
Um eine sichere Speicherung zu gewährleisten und virtuell die Möglichkeit einer betrügerischen Änderung von Tickets zu eliminieren, werden die Daten vorzugsweise in den Feldern eines Tickets gespeichert, in denen eine oder mehrere der folgenden Schutzmassnahmen durchgeführt werden:
A. Einsatz eines speziellen Codes zum Speichern von Daten, \
B. Einsatz von verschiedenen Befehlen zum Speichern von Daten, abhängig von dem betreffenden Zeitpunkt der Lieferung eines Tickets (Ausgabe, Verifizierung oder Validierung)
C. Einsatz von verschiedenen Schlüsseln zum Speichern von Daten in unterschiedlichen Feldern, abhängig von dem jeweiligen Zeitpunkt.
Der spezielle Code wird zuerst unter Bezugnahme auf die Fig. 4 beschrieben.
Die Fig. 4 zeigt ein Beispiel einer bevorzugten Darstellung von Daten in den Feldern 21 bis 24 des Tickets 20 der Fig. 3. Das Datenwort 31 umfasst acht Bits, von denen alle eine (logische) Null sind. Demgemäss ist die Summe S der Bits null. Das Datenwort 32 umfasst acht Bits, von denen vier eine (logische) Eins sind (ein sogenannter acht über vier Code). Die Summe S der Bits ist daher ebenfalls vier. In den Tickets der vorliegenden Erfindung werden die Daten in den Feldern 21 bis 24 unter Einsatz eines Codes gespeichert, in dem eine feste Anzahl von Bits gleich Eins ist. Mit anderen Worten, ein Code wird eingesetzt, der z. B. in dem Datenwort 32 enthalten ist, von dem die Summe der Bits fest ist (z. B. S = 4). Dies gestattet eine einfache Feststellung der Veränderung von gespeicherten Daten. Das Datenwort 33 z. B. ist gleich zum Datenwort 32 ausser einem Bit. Die Summe S der Bits des Datenwortes 33 ist gleich fünf statt vier. Falls ein Code eingesetzt wird, in dem alle Datenwörter eine Summe S gleich vier haben, würde die Änderung im Datenwort 33 in einfacher Weise festgestellt werden durch Feststellung der Summe der Bits von jedem Datenwort.
Gemäss dem Beispiel der Fig. 4 können drei Arten von Datenwörtern unterschieden werden, basierend auf der Summe S ihrer Bits. Für einen ersten Typ ist S gleich null: diese Worte sind leer. Für einen dritten Typ ist S gleich vier: diese Wörter enthalten gültige Daten. Für einen zweiten Typ ist 5 weder null noch vier, diese Wörter enthalten ungültige Daten.
Es ist festzuhalten, dass die Anzahl von Einsen und Nullen, die in der Fig. 4 dargestellt sind, nur beispielhaft ist und dass Datenwörter eingesetzt werden können, die z. B. acht oder zehn Bits aufweisen, von denen drei oder fünf jeweils gleich Eins sind.
Vorteilhafterweise wird ein unterschiedlicher Befehl eingesetzt, um Daten in verschiedenen Stufen zu speichern, um ein Ticket herzustellen. Eine Chipkarte unterstützt vorzugsweise einen ersten Schreibbefehl (genannt UPDATE), um Einsen und Nullen in einem Speicherort zu speichern, und einen zweiten Schreibbefehl (genannt WRITE), um nur Einsen zu speichern. Während der Ausgabe von einem Ticket werden die Felder des Tickets unter Einsatz des ersten Befehls (UPDATE) mit Daten beliefert. Zu diesem Zeitpunkt werden in dem Berechtigungsfeld 21 relevante Daten gespeichert, während in dem Validierungsfeld 22 und den Verifizierungsfeldern 23 und 24 nur-Null Codewörter geschrieben werden (als Datenwort 31 in der Fig. 4). Während den Validierungs- und Verifizierungsstufen kann nur der zweite Befehl (WRITE) benutzt werden und daher können nur Einsen geschrieben werden. Dies bedeutet, dass die gültigen Codewörter, die bereits geschrieben worden sind, während der Validierungs- und Verifizierungsstufen nicht geändert werden können, da dies erfordern würde, dass eine Null geschrieben wird. Somit kann durch Gestatten nur des zweiten Befehles (WRITE) während der Validierungs- und Verifizierungsvorgänge das Verändern von Ticketdaten verhindert werden.
Es ist festzustellen, dass ein leeres (d. h. nicht ausgegebenes) Ticket ungültige Daten enthalten sollte, d. h. Daten, die mehr als vier Einsen je Wort aufweisen, falls ein acht über vier Code eingesetzt wird, um zu verhindern, dass ein leeres Ticket "ausgegeben" wird, unter Einsatz eines zweiten Schreibbefehls (WRITE). Vorteilhafterweise enthält ein leeres Ticket nur Einsen.
Um eine weitere Erhöhung der Schutzfunktion zu erreichen, werden vorzugsweise unterschiedliche Schlüssel eingesetzt, um Daten in den verschiedenen Feldern zu speichern, in Abhängigkeit von der besonderen Stufe, in der ein Ticket hergestellt wird. Somit kann ein Ticket ausgegeben werden (Einsatz des ersten Schreibbefehls UPDATE), welches einen ersten Schlüssel K1 benötigt, wobei die Validierung einen zweiten Schlüssel K2 benötigt und die Verifizierung einen dritten Schlüssel K3 benötigt. Eine Chipkarte gemäss der vorliegenden Erfindung ist vorzugsweise so angeordnet, um den Zugriff auf alle Fälle 21 bis 24 eines Tickets 20 zu liefern, wenn der erste Schlüssel K1 eingesetzt wird, während der Schreibzugang zum Validierungsfeld 22 nur geliefert wird, wenn der zweite Schlüssel K2 eingesetzt wird. In ähnlicher Weise liefert der dritte Schlüssel K3 nur den Schreibzugang zu den Verifizierungsfeldern 23 und 24. In optionaler Weise liefert der dritte Schlüssel K3 nur den Speicherzugriff auf das erste Verifizierungsfeld 23, während ein vierter Schlüssel K4 ausschliesslich den Schreibzugriff auf das zweite Verifizierungsfeld 24 liefert. Es ist wohlverstanden, dass alle Schlüssel-Lese-Zugriff auf alle Felder des Tickets 20 ermöglichen.
Der Einsatz von mindestens drei Schlüsseln macht es somit möglich, einen limitierten Zugang auf die verschiedenen Felder zu gestatten und den Einsatz des ersten Schreibbefehls (UPDATE) zu beschränken durch Anforderung des Schlüssels K1.
Das Verfahren gemäss der Erfindung, wie es in schematischer Weise und nur in beispielhafter Art und Weise in den Fig. 5, 6 und 7 dargestellt ist, umfasst das Ausstellen eines Tickets gemäss der vorliegenden Erfindung. Das Verfahren umfasst drei Stufen: eine erste Stufe (Ausgabe), die in der Fig. 5 dargestellt ist, eine zweite Stufe (Validierung), die in der Fig. 6 dargestellt ist, und eine dritte Stufe (Verifizierung), die in der Fig. 7 dargestellt ist. Nachfolgende Vorgänge werden in den Fig. 5 bis 7 von oben nach unten dargestellt. Es wird angenommen, dass der Speicher der Chipkarte zuvor initialisiert worden ist, z. B. durch Ausstellen von leeren Tickets, die nur-Eins Codewörter enthalten.
Wie in der Fig. 5 dargestellt, beginnt die Ausstellungsstufe mit einem ersten Schritt (Startschritt) 50, in dem das Ausgabeendgerät aktiviert wird, z. B. durch Einführung der Karte. Im nachfolgenden Schritt S1 wird der Ticketzähler geprüft, d. h. ob es dem Endgerät erlaubt ist, ein weiteres Ticket auszustellen. Der Ticketzähler kann limitiert werden, z. B. auf eine maximale Anzahl von Tickets je Tag und kann täglich zurückgesetzt werden.
Falls der Ticketzähler nicht überschritten ist, geht das Verfahren mit Schritt S2 weiter, in dem das Endgerät die Karte um eine Zufallszahl anfragt. In Antwort erzeugt die Karte im Schritt S3 eine Zufallszahl (R) durch das Mittel von eingebauten Zufallszahlengeneratoren, vorzugsweise in der Software implementiert. Die Zufallszahl wird an das Endgerät übertragen.
Im Schritt S4 liefert das Endgerät Berechtigungsdaten (ED) sowie einen ersten Nachrichtenauthentifizierungscode (MAC1), der von den Berechtigungsdaten ED und der Zufallszahl R unter Einsatz des ersten Schlüssels K1 abgeleitet wird. Dieser Authentifizierungscode MAC1 wird durch die Karte im Schritt S5 geprüft, z. B. durch Ableiten MAC1 aus dem Berechtigungsdatum ED und der Zufallszahl R und dem Vergleich der empfangenen und abgeleiteten Authentifizierungscodes. Falls der Code MAC1 als ungültig festgestellt wird, kann die Prozedur beendet werden und eine Fehlermeldung wird an das Endgerät gesendet. Es ist festzuhalten, dass die Verifizierung des Authentifizierungscodes MAC1 implizit die Verifizierung des ersten Schlüssels K1 umfasst. Eine nicht gelungene Verifizierung verbietet den Einsatz des ersten Schreibbefehls (UPDATE).
Falls der Code MAC1 gültig festgestellt worden ist, werden die Berechtigungsdaten ED in der Karte in dem Schritt S6 unter Einsatz des ersten Schreibbefehls (UPDATE) gespeichert. Auch die verbleibenden Felder der Tickets (Validierungs- und Verifizierungsfelder) werden unter Einsatz dieses Befehls zurückgesetzt. Eine Bestätigungsnachricht (ACK) wird an das Endgerät gesandt. Auch werden richtige Codes (z. B. alles Einsen) in die Validierungs- und Berechtigungsfelder geschrieben.
Die Ausgabestufe endet im Schritt S7. Eine geeignete Nachricht könnte auf dem Endgerät angezeigt werden.
Wie in der Fig. 6 dargestellt, beginnt die zweite oder Validierungsstufe im Schritt 60, in welcher das Validierungsendgerät aktiviert wird, z. B. durch Einführung der Karte. Das Endgerät sendet einen Lesebefehl an die Karte. Der Lesebefehl kann Daten umfassen, die ein bestimmtes Ticket spezifizieren oder eine bestimmte Art von Tickets. Die Karte liest nachfolgend das oder die spezifizierten Tickets oder in alternativer Weise alle nicht leeren Tickets in einem Schritt 61 aus und sendet die Berechtigungsdaten ED an das Endgerät. In Schritt 62 prüft das Endgerät die Berechtigungsdaten auf ihre Gültigkeit (z. B. Feststellen der Anzahl der gesetzten Bits pro Codewort). Möglicherweise wurden im Schritt 61 auch die Validierungsdaten (VD) des Tickets übersandt. Da diese Validierungsdaten immer noch "leer" sind (d. h. alles Nullen), zu diesem Zeitpunkt, folgt, dass das betreffende Ticket validiert werden muss.
Falls die empfangenen Berechtigungsdaten ED durch das Endgerät in dem Schritt 62 ein Ticket identifizieren, welches zu validieren ist, erzeugt das Endgerät im Schritt 63 einen zweiten Nachrichtenauthentifizierungscode MAC2, unter Einsatz der Validierungsdaten VD und des zweiten Schlüssels K2 und sendet die Daten VD und den Code MAC2 zu der Karte. Im Schritt 64 prüft die Karte die empfangenen Authentifizierungscodes MAC2 wie im Schritt S5. Falls der Authentifizierungscode MAC2 als ungültig festgestellt wird, wird eine Fehlermeldung an das Endgerät gesandt. Falls der Code MAC2 gültig festgestellt wird, werden die Validierungsdaten VD in den betreffenden Tickets im Schritt 65 gespeichert, unter Einsatz des zweiten Schreibbefehls (WRITE) und einem Bestätigungssignal, das an das Endgerät gesandt wird. Der Schritt 66 beendet die Validierungsstufe. Es ist festzustellen, dass das (zweite) Validierungsendgerät nicht den ersten Schlüssel K1 besitzt, so dass es nicht möglich ist, den ersten Schreibbefehl (UPDATE) zu diesem Zeitpunkt zu benutzen.
Die Verifizierungsstufe, die in der Fig. 7 dargestellt ist, beginnt mit Schritt 70, wenn das Endgerät, bevor es aktiviert wird, einen Lesebefehl erzeugt. Wiederum kann dieser Lesebefehl (der nicht identisch zu dem Lesebefehl in Schritt 60 sein muss) ein gewisses Ticket oder eine Art von Ticket anzeigen. Im Schritt 71 liest die Karte die relevanten Berechtigungsdaten ED und Validierungsdaten VD aus dem Speicher in Antwort auf den Lesebefehl und sendet diese Daten zum Endgerät. Das Endgerät verifiziert nachfolgend diese Daten in Schritt 72, wobei basierend auf der Verifizierung oder Prüfdaten CD angezeigt wird, dass die Tickets als gültig angesehen werden (z. B. Abhängigkeit von einer bestimmten Zeit und Datum). Falls das betreffende Ticket als gültig angesehen wird, wird in Schritt 73 ein dritter Nachrichtenidentifizierungscode MAC3 produziert, unter Einsatz der Verifizierungsdaten CD und dem dritten Schlüssel K3. Diese Daten werden zu der Karte gesandt und in Schritt 74 geprüft. Schliesslich werden die Verifizierungsdaten CD in einem Verifizierungsfeld der Karte in Schritt 75 gespeichert, woraufhin die Karte eine Bestätigungsnachricht an das Endgerät sendet. Der Schritt 76, in dem das Verifizierungsendgerät deaktiviert werden kann, endet die Verifizierungsstufe.
Das in der Fig. 8 schematisch dargestellte System umfasst ein erstes Endgerät 81, ein zweites Endgerät 82 und ein drittes Endgerät 83 als auch eine Chipkarte 1. Das erste Endgerät 81 ist ausgerüstet, um Tickets auszugeben. Zu diesem Zweck wird der erste Schlüssel K1 in dem ersten Endgerät 81 gespeichert. Das erste Endgerät 81 umfasst auch einen Ticketzähler zum Begrenzen der Anzahl der ausgestellten Tickets bis hin zu einer vorbestimmten Anzahl.
Das zweite Endgerät 82 ist ausgerüstet zum Validieren von Tickets, während das dritte Endgerät 83 ausgestattet ist, um Tickets zu verifizieren. Die Endgeräte 82 und 83 enthalten jeweils die zweiten Schlüssel K2 und dritten Schlüssel K3. Die Endgeräte empfangen eigene Signale von Benutzern und/oder Operatoren.
Es ist wohlverstanden von Fachleuten, dass die oben beschriebenen Ausführungsbeispiele nur beispielhaft aufgeführt sind und viele Änderungen und Hinzufügungen möglich sind, ohne den Rahmen der vorliegenden Erfindung, wie er in den beigefügten Ansprüchen abgefasst ist, zu verlassen.

Claims

1. Chipkarte (1) mit einem integrierten Schaltkreis (10) mit einem Prozessor (11) und einem Speicher (12), wobei der Speicher so strukturiert ist, um Tickets (20) zu umfassen, wobei ein Ticket mindestens ein Feld (21, 22, 23) zum Speichern von Daten aufweist, welche sich auf das Ticket beziehen, dadurch gekennzeichnet, dass die Chipkarte Mittel (11, 12) zum Speichern von Daten in dem mindestens einen Feld in der Gestalt eines Codes umfasst, der eine feste Anzahl von gesetzten Bits pro Bitgruppe umfasst.

2. Chipkarte (1) nach Anspruch 1, dadurch gekennzeichnet, dass der Code Codewörter (32) mit acht Bits aufweist, wobei die Anzahl der gesetzten Bits in jedem gültigen Code gleich vier ist.

3. Chipkarte (1) nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, dass der Prozessor (11) mit einem ersten Befehl (UPDATE) zum Setzen und Zurücksetzen von Bits und mit einem zweiten Befehl (WRITE) zum ausschliesslichen Setzen von Bits versehen ist, wobei der erste Befehl (UPDATE) ausschliesslich in Antwort auf eine Identifikation eines ersten Typs von Endgerät (81) arbeitet.

4. Chipkarte (1) nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass ein in der Chipkarte gespeichertes Ticket (20) ein Berechtigungsfeld (21) zum Speichern von Daten in Bezug auf die Berechtigung des Tickets und ein Validierungsfeld (22) zum Speichern von Daten in Bezug auf die Gültigkeit des Tickets aufweist.

5. Chipkarte (1) nach Anspruch 4, dadurch gekennzeichnet, dass ein Ticket (20) weiterhin mindestens ein Verifizierungsfeld (23; 24) zum Speichern von Daten in Bezug auf eine Überprüfung der Gültigkeit des Tickets aufweist.

6. Chipkarte (1) nach Anspruch 4 oder Anspruch 5, dadurch gekennzeichnet, dass der integrierte Schaltkreis (10) einen ersten Schlüssel (K1) zum Authentifizieren von Berechtigungsdaten und einen zweiten Schlüssel (K2) zum Authentifizieren von Validierungsdaten aufweist.

7. Chipkarte (1) nach Anspruch 5 und Anspruch 6, dadurch gekennzeichnet, dass der integrierte Schaltkreis (10) weiterhin einen dritten Schlüssel (K3) zum Authentifizieren von Überprüfungsdaten aufweist.

8. Chipkarte (1) nach Anspruch 7, dadurch gekennzeichnet, dass der zweite (K2) und der dritte (K3) Schlüssel gleich sind.

9. Chipkarte (1) nach Anspruch 6, 7 oder 8, dadurch gekennzeichnet, dass die Identifizierung eines ersten Typs von Endgerät den ersten Schlüssel (K1) einsetzt.

10. Verfahren des Registrierens von Tickets (20) auf einer Chipkarte (1) mit einem Speicher (12), wobei das Verfahren die Schritte umfasst:

- Erzeugen eines Tickets (20) in dem Speicher (12), wobei das Ticket mindestens ein Feld umfasst (z. B. 21),

- Ausgeben des Tickets (20) durch Speichern von Daten in dem Feld (21), die ein Recht identifizieren, welches dem Ticket zugestanden wird,

dadurch gekennzeichnet, dass das Speichern von Daten in dem mindestens einen Feld (21) in Gestalt eines Codes vorliegt, der eine feste Anzahl von gesetzten Bits pro Bitgruppe umfasst.

11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass der Code Codewörter (32) mit acht Bits aufweist, wobei die Anzahl der gesetzten Bits in jedem gültigen Code gleich vier ist.

12. Verfahren nach Anspruch 10 oder Anspruch 11, dadurch gekennzeichnet, dass der Schritt des Ausgebens des Tickets (20) den Einsatz eines ersten Befehls (UPDATE) zum Setzen und Zurücksetzen von Bits und eines zweiten Befehls (WRITE) zum ausschliesslichen Setzen von Bits umfasst, wobei der erste Befehl (UPDATE) ausschliesslich in Antwort auf eine Identifikation eines ersten Typs von Endgerät (81) arbeitet.

13. Verfahren nach einem der Ansprüche 10, 11 oder 12, dadurch gekennzeichnet, dass Daten, die ein durch das Ticket zugestandene Recht identifizieren, in einem Berechtigungsfeld (21) gespeichert sind, wobei das Verfahren die zusätzlichen Schritte umfasst:

- Validieren des Tickets (20) durch Speichern von Daten in Bezug auf die Gültigkeit des Tickets in dem Validierungsfeld (22), und.

- Verifizieren des Tickets (20) durch Speichern von Daten in Bezug auf eine Überprüfung des Tickets in einem Verifizierungsfeld (23; 24).

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass der Schritt des Verifizierens des Tickets (20) das Überprüfen der Anzahl der gesetzten Bits des Codes umfasst.

15. Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass die in dem Berechtigungsfeld (21) gespeicherten Daten eine Identifikation der Ausgabestelle des Tickets umfasst.

16. Verfahren nach Anspruch 13, 14 oder 15, dadurch gekennzeichnet, dass die in dem Validierungsfeld (22) gespeicherten Daten das Gültigkeitsdatum des Tickets und/oder eine Endgeräte- Identifikation umfassen.

17. Verfahren nach einem der Ansprüche 13 bis 16, dadurch gekennzeichnet, dass die in dem mindestens einen Verifizierungsfeld (23; 24) gespeicherten Daten ein Datum, eine Zeit und/oder eine Endgeräte-Identifikation umfassen.

18. Verfahren nach einem der Ansprüche 13 bis 17, dadurch gekennzeichnet, dass das Speichern von Daten in dem Berechtigungsfeld (21) den Einsatz eines ersten Schlüssels (K1) erfordert, während das Speichern von Daten in dem Validierungsfeld (22) einen zweiten Schlüssel (K2) erfordert.

19. Verfahren nach Anspruch 18, dadurch gekennzeichnet, dass das Speichern von Daten in einem Verifizierungsfeld (23; 24) den Einsatz eines dritten Schlüssels (K3) erfordert

20. Verfahren nach Anspruch 19, dadurch gekennzeichnet, dass der zweite Schlüssel (K2) und der dritte Schlüssel (K3) gleich sind.

21. System zum Schaffen eines Zuganges zu Diensten, wobei das System Chipkarten (1) und Endgeräte (81, 82, 83) umfasst, wobei jede Chipkarte (1) mit einem Speicher zum Speichern von Tickets (20) versehen ist, der mindestens ein Feld (z. B. 21) aufweist, wobei ein Endgerät (81) ausgestattet ist, um in dem Feld (21) Daten zu speichern, die das Recht auf den Zugang zu einem Dienst darstellen, dadurch gekennzeichnet, dass Daten in dem zumindest einen Feld (21) in der Gestalt eines Codes gespeichert werden, der eine feste Anzahl von gesetzten Bits pro Bitgruppe umfasst.

22. System nach Anspruch 21, dadurch gekennzeichnet, dass der Code Codewörter (32) mit acht Bits aufweist, wobei die Anzahl der gesetzten Bits in jedem gültigen Code gleich vier ist.

23. System nach Anspruch 21 oder Anspruch 22, dadurch gekennzeichnet, dass die Chipkarte (1) mit einem ersten Befehl (UPDATE) zum Setzen und Zurücksetzen von Bits und mit einem zweiten Befehl (WRITE) zum ausschliesslichen Setzen von Bits versehen ist, wobei der erste Befehl (UPDATE) ausschliesslich in Antwort auf eine Identifikation eines ersten Typs von Endgerät (81) arbeitet.

24. System nach einem der Ansprüche 21, 22 oder 23, dadurch gekennzeichnet, dass jedes Ticket (20) ein Berechtigungsfeld (21) und ein Validierungsfeld (22) aufweist, wobei ein Validierungsendgerät (82) ausgestattet ist, um in einem Validierungsfeld (22) Daten zu speichern, die das jeweilige Ticket (20) validieren.

25. System nach Anspruch 24, dadurch gekennzeichnet, dass ein Ticket (20) weiterhin mindestens ein Verifizierungsfeld (23; 24) aufweist, wobei ein Verifizierungsendgerät (83) ausgestattet ist, um in einem Verifizierungsfeld (23; 24) Daten zu speichern, die sich auf eine Verifizierung des Tickets (20) beziehen.

26. System nach einem der Ansprüche 21 bis 25, dadurch gekennzeichnet, dass ein Ausgabeendgerät (81) einen Ticketzähler aufweist, um die Anzahl der ausgegebenen Tickets zu begrenzen.