DE60216056T2

DE60216056T2 - Verfahren und anordnung in einem kommunikationssystem

Info

Publication number: DE60216056T2
Application number: DE60216056T
Authority: DE
Inventors: Fredrik Almgren
Original assignee: SmartTrust AB
Current assignee: Giesecke and Devrient GmbH
Priority date: 2001-03-16
Filing date: 2002-02-27
Publication date: 2007-06-28
Anticipated expiration: 2022-02-28
Also published as: WO2002076078A1; ATE345643T1; EP1368959B1; ES2276909T3; EP1368959A1; SE518725C2; SE0100917D0; DE60216056D1; SE0100917L

Description

GEBIET DER ERFINDUNG
Die vorliegende Erfindung betrifft ein Verfahren und ein System in einem Datenübertragungssystem gemäß den Oberbegriffen der unabhängigen Ansprüche. Sie betrifft insbesondere die sichere Handhabung elektronischer Tickets in einem elektronischen Ticketingsystem.
HINTERGRUND DER ERFINDUNG
Elektronische Tickets werden in immer stärkerem Maße verwendet. Beispielhafte Gebiete sind Tickets für Filmvorführungen, Konzerte, Flugreisen usw. Bei einigen Ticketsystemen bucht der Nutzer ein Ticket online, er muss jedoch in jedem Fall zu einer Ticketverkaufsstelle gehen, um zu bezahlen und die Ausgabe des Tickets zu fordern. Bei einem weiteren Beispiel des Verkaufssystems geht der Nutzer zunächst zu der Ticketverkaufsstelle, um ein vorausbezahltes elektronisches Ticket (Karte) zu kaufen. Der Nachteil bei den gegenwärtigen Verkaufssystemen ist die Unannehmlichkeit für den Nutzer, der zu der Ticketverkaufsstelle gehen muss, um zu bezahlen und das Ticket zu erhalten.
In dem europäischen Patentdokument EP 1 030 273 ist wie auch in EP 1 030 272 versucht worden, die oben erwähnten Nachteile zu überwinden. Dieses. Dokument zeigt ein elektronisches Vermögensgüternutzungssystem, das ein festes Terminal, ein mobiles Terminal und einen Server enthält, um eine Gebühr für die Ausgabe eines elektronischen Vermögensguts oder einen Auftrag für ein elektronisches Vermögensgut zu bezahlen. Das feste Terminal, das mobile Terminal und der Server sind mit einem Datenübertragungsnetz verbunden. Nachdem der Server einen Auftrag für ein elektronisches Vermögensgut, wie etwa ein elektronisches Ticket, empfangen und den Auftrag erledigt hat, sendet der Server das elektronische Vermögensgut an ein festgelegtes Terminal. Beim Empfang einer Anforderung für einen Dienst führt der Server ferner eine Verarbeitungsoperation in Bezug auf die Dienstanforderung aus und sendet den auf diese Weise angeforderten Dienst an ein festgelegtes Terminal.
Das Dokument WO 00/25248 betrifft ein Ticketingverfahren für interaktive Netzereignisse. Es enthält Anrufe für Nutzer, um Reservierungen für ein derartiges Ereignis von einem zentralen Datenbankserver anzufordern. Der Nutzer muss auf eine Bestätigungsnachricht reagieren, um für eine Teilnahme autorisiert zu werden. Der Nutzer erhält ein elektronisches Ticket für den Zugang mit einem Code und einem einmalig verwendbaren Schlüssel.
Dieses Dokument erwähnt jedoch nichts über die Handhabung eines Tickets, das während eines Zeitintervalls oder für eine begrenzte Anzahl von Malen gültig ist.
Vor der Erläuterung dieses Problems wird eine bestimmte Terminologie, die in diesem Dokument verwendet wird, definiert.
Ein Ereignisticket ist ein Ticket, das einmalig gültig ist. Das Ereignis kann beliebig sein: Filmvorführung, Konzert, Flugreise usw.
Ein Mehrfachereignisticket ist ein Ticket, das bei mehreren Gelegenheiten verwendet werden kann, wobei jedoch die Anzahl der Ereignisse und nicht die Zeit die Gültigkeit des Tickets begrenzt.
Ein Saisonticket ist ein Ticket, das während eines Zeitintervalls gültig ist. Dieses Intervall kann Stunden, Tage, Wochen, Monate usw. betragen.
Ein Ticketausgeber ist eine Entität, die ein Ticket als Folge einer Kauftransaktion mit dem Nutzer erzeugt.
Ein Nutzer ist die Entität, die das Ticket kauft und nutzt. Ein Ticketempfänger ist die Entität, die das Ticket vom Nutzer einsammelt, wenn der Nutzer versucht, anhand des Tickets Zugang zu erlangen.
Ein Saisonticket und ein Mehrfachereignisticket unterscheiden sich von einem Ereignisticket, da sie nicht zum Zeitpunkt der Nutzung widerrufen werden. Das Saisonticket wird widerrufen, wenn eine im Voraus definierte Zeitbegrenzung überschritten wird. Saisontickets können unterschiedliche Gültigkeitszeitspannen haben. Sie können Tagespässe, Wochenpässe, Monatspässe usw. sein. Jede beliebige Zeitspanne ist möglich. Bei einem Mehrfachereignisticket begrenzt die Anzahl der Gelegenheiten anstelle der Zeit die Gültigkeit des Tickets. Bei diesen beiden Tickettypen wird der Tickettyp durch das Verhalten in Bezug auf den Widerruf definiert. Diese beiden Tickettypen sind daher empfindlicher als Ereignistickets. Ein Ereignisticket kann als gültig für ein bestimmtes Ereignis erkannt werden. Nachdem ein Ticketempfänger das Ticket akzeptiert hat, kann es automatisch widerrufen werden. Dieses System stellt selbst einen Schutz gegen einen Kopierangriff dar. Wenn es irgendjemandem gelingt, sein Ticket nachzubilden, wird lediglich die erste Benutzung akzeptiert. Bei den Fällen von Saison- und Mehrfachereignistickets kann man sich auf diesen Mechanismus nicht verlassen. Der Besitzer des Ticketsystems fordert eine Sicherheit, damit das Nachbilden von ausgegebenen Tickets verhindert wird.
Um in offenen Netzwerken eine Sicherheit zu erreichen, sind verschiedene Sicherheitslösungen aufgetaucht. Ein Beispiel ist die Public-Key-Infrastruktur (PKI). PKI ist ein System, das verwendet wird, um öffentliche Schlüssel, die zum Authentifizieren von Nutzern verwendet werden können, zu verteilen und zu prüfen, Informationen zu signieren oder Informationen zu verschlüsseln. In einem PKI-System werden zwei entsprechende Schlüssel (die auch als asymmetrisch bezeichnet werden) in Verbindung mit dem Schutz von Informationen verwendet. Informationen, die mit einem der beiden Schlüssel verschlüsselt sind, können lediglich mit dem anderen Schlüssel entschlüsselt werden. Ein wichtiges Merkmal von PKI-Systemen besteht darin, dass es rechentechnisch unmöglich ist, die Kenntnis von einem der Schlüssel zu verwenden, um den anderen Schlüssel abzuleiten. In einem typischen PKI-System besitzt jedes der Systeme einen Satz aus zwei derartigen Schlüsseln. Einer der Schlüssel wird geheim gehalten, während der andere frei veröffentlicht wird.
Eine PKI verteilt einen oder mehrere öffentliche Schlüssel und legt fest, ob auf einen bestimmten öffentlichen Schlüssel für eine bestimmte Nutzung vertraut werden kann. Ein wichtiges Konzept von Infrastrukturen, die auf Public-Key-Kryptografie aufgebaut sind, ist die der Zertifizierungsbehörde (Certification Autority, CA). Obwohl es erwünscht ist, dass die öffentlichen Schlüssel für alle Nutzer leicht verfügbar sind, besteht die Schwachstelle in einem Public-Key-System darin, dass sichergestellt werden muss, dass es wirklich bekannt ist, dass ein bestimmter öffentlicher Schlüssel tatsächlich zu dem Nutzer gehört, mit dem man gerade kommuniziert. Dafür wird die CA verwendet. Sie verwendet ihren guten Namen, um die Korrektheit eines öffentlichen Schlüssels zu garantieren, indem sie einen Schlüssel signiert.
Des Weiteren wird eine Möglichkeit der Verwendung der PKI in einem elektronischen Ticketingsystem benötigt.
ZUSAMMENFASSUNG DER ERFINDUNG
Es ist die Aufgabe der vorliegenden Erfindung, ein elektronisches Ticketingsystem mit einer verbesserten Sicherheit zu schaffen.
Die oben erwähnte Aufgabe wird gelöst durch ein Verfahren und ein System gemäß dem kennzeichnenden Teil der unabhängigen Ansprüche.
Das durch die vorliegende Erfindung geschaffene Verfahren, das die folgenden Schritte umfasst:
– Übermitteln des öffentlichen Schlüssels des Nutzerterminals an eine Ticket-Issuing-Unit;
– Kombinieren des öffentlichen Schlüssels mit einem Ticket, welcher kombinierte Schlüssel und das Ticket ein Ticket-Datenpaket bilden;
– Signieren des Ticket-Datenpakets durch die Ticket-Issuing-Unit;
– Versenden des signierten Ticket-Datenpakets durch die Ticket-Issuing-Unit an das Nutzerterminal;
– Versenden des signierten Ticket-Datenpakets durch das Nutzerterminal an eine Ticket-Receiving-Unit;
– Erhalten des im empfangenen signierten Ticket-Datenpaket enthaltenen öffentlichen Schlüssels durch die Ticket-Receiving-Unit;
– Verschlüsselung der Challenge-Daten mittels des öffentlichen Schlüssels;
– Versendung der Challenge-Daten an das Nutzerterminal zur Verifizierung des Nutzerterminals;
– Entschlüsselung der verschlüsselten Challenge-Daten durch das Nutzerterminal mit dem privaten Schlüssel des Nutzerterminals;
– Versendung der entschlüsselten Challenge-Daten an die Ticket-Receiving-Unit; und
– Akzeptieren des Tickets durch die Ticket-Receiving-Unit, falls die erhaltenen entschlüsselten Challenge-Daten dieselben sind wie die Challenge-Daten vor der Verschlüsselung derselben, und falls das Ticket gültig ist,
ermöglicht eine sicherere Handhabung elektronischer Tickets.
Das durch die vorliegende Erfindung geschaffene Nutzerterminal, das ein Schlüsselpaar aufweist, d. h. einen privaten Schlüssel und einen öffentlichen Schlüssel, und Mittel umfasst, um seinen öffentlichen Schlüssel an eine Ticket-Issuing-Unit zu übermitteln, ermöglicht, dass die Ticket-Issuing-Unit ein Ticket, das ausgegeben werden soll, mit dem öffentlichen Schlüssel kombiniert sowie ein System mit erhöhter Sicherheit zu erreichen.
Die durch die vorliegende Erfindung geschaffene Ticket-Issuing-Unit, die Mittel, um den öffentlichen Schlüssel des Nutzerterminals zu erhalten, und Mittel zum Kombinieren des öffentlichen Schlüssels mit einem Ticket, um ein Ticket-Datenpaket zu bilden, umfasst, ermöglicht, dass die Ticket-Issuing-Unit das Ticket-Datenpaket signiert und dieses an das Nutzerterminal ausgibt sowie ein System mit höherer Sicherheit zu erreichen.
Die durch die vorliegende Erfindung geschaffene Ticket-Receiving-Unit, die Mittel zum Empfangen des signierten Datenpakets vom Nutzerterminal umfasst, ermöglicht, dass die Ticket-Receiving-Unit den enthaltenen öffentlichen Schlüssel auf sichere Weise empfängt, da dieser in den Ticketdaten enthalten ist, die durch die Ticket-Issuing-Unit signiert wurden, und die Verwendung den enthaltenen öffentlichen Schlüssels des Nutzerterminals, um zu verifizieren, dass das Nutzerterminal dasjenige ist, das es vorgibt zu sein, sowie ein System mit höherer Sicherheit zu erreichen.
Ein Vorteil besteht bei der vorliegenden Erfindung darin, dass es für einen Nutzer nahezu unmöglich ist, ein Ticket nachzubilden, und deswegen ist die vorliegende Erfindung besonders geeignet für Saisontickets und Mehrfachereignistickets.
Bevorzugte Ausführungsformen sind in den abhängigen Ansprüchen dargestellt.
Gemäß einer ersten Ausführungsform der vorliegenden Erfindung ist in einer Nachricht, die durch die Ticket-Receiving-Unit gesendet wird, ein Zertifikat der Issuing-Unit enthalten, um das Nutzerterminal aufzufordern, ein Ticket zu übermitteln.
Ein Vorteil der ersten Ausführungsform besteht darin, dass sie dem Nutzer ermöglicht, die Ticket-Receiving-Unit zu verifizieren, bevor ein Ticket übermittelt wird, und dass sich ein kleinerer Umfang der Ticketdaten ergibt, die zum Zeitpunkt der Ticketausgabe übertragen und gespeichert werden müssen.
Ein weiterer Vorteil der ersten Ausführungsform besteht darin, dass zum Zeitpunkt des Kaufs nicht festgelegt ist, wo das Ticket verwendet werden kann. Dadurch können während der Gültigkeitsdauer des Tickets mehrere Ticketempfänger hinzugefügt werden.
Gemäß einer zweiten Ausführungsform der vorliegenden Erfindung ist eine Liste von gültigen Ticket-Receiving-Units in dem ausgegebenen Ticket-Datenpaket enthalten.
Ein Vorteil besteht bei der zweiten Ausführungsform darin, dass es für den Nutzer möglich ist, die Ticket-Receiving-Unit zu verifizieren, bevor ein Ticket an sie übermittelt wird, und dass die Liste von Ticketempfängern zum Zeitpunkt des Kaufs festgeschrieben ist.
KURZBESCHREIBUNG DER ZEICHNUNGEN
1 ist ein Blockschaltplan, der ein beispielhaften elektronisches Ticketingsystem veranschaulicht;
2 ist eine Darstellung einer Signalisierungsabfolge, die ein Beispiel der Ticketausgabeabläufe zeigt;
3 ist eine Darstellung einer Signalisierungsabfolge, die ein Beispiel der Ticketnutzungsabläufe zeigt; und
4 ist eine Darstellung einer Signalisierungsabfolge, die ein Beispiel der Ticketwiderrufabläufe zeigt.
GENAUE BESCHREIBUNG BEVORZUGTER AUSFÜHRUNGSFORMEN
1 ist ein Blockschaltplan, der ein beispielhaftes elektronisches Ticketingsystem veranschaulicht. Das Ticketingsystem kann eine beliebige Art von Ticketingsystem sein, wie z. B. bei einer Filmgesellschaft, die Kinotickets verkauft, eine Bustransportgesellschaft, die Bustickets verkauft, eine Luftfahrtgesellschaft, die Flugtickets verkauft, usw. Demzufolge können die Tickets eine beliebige Art von Ereignistickets sein, wie etwa Kinotickets, Flugtickets, Bustickets usw.
Das Ticketingsystem ist für Ticketsysteme geeignet, die Tickets, die während eines Zeitintervalls gültig sind, so genannte Saisontickets oder Tickets, die für eine Anzahl von Ereignissen gültig sind, so genannte Mehrereignistickets, handhaben, es kann jedoch für jede Art von Ticketingsystem verwendet werden, bei dem ein Anspruch auf eine hohe Sicherheit besteht.
Das Ticketingsystem basiert auf Public-Key-Kryptografie, d. h. auf der Public-Key-Infrastruktur (PKI), um in dem System Sicherheit zu erreichen.
Das System umfasst eine Ticket-Issuing-Unit 101, eine Ticket-Receiving-Unit 103, eine berechtigte Signiereinheit 104 und ein Nutzerterminal 105, das von einem Nutzer 107 verwendet wird.
Nutzerterminal 105
Das Nutzerterminal 105 ist die Entität, die das Ticket von dem Aussteller empfängt und es verwendet, indem sie es an den Ticketempfänger übermittelt. Das Nutzerterminal 105 kann ein Mobiltelefon, ein persönlicher digitaler Assistent (PDA), ein Laptop usw. sein. Ein Beispiel eines Nutzers 107 ist eine Person, die in einem Filmtheater einen Spielfilm sehen möchte. Das Nutzerterminal 105 umfasst einen Nutzeragenten, der elektronische Ticketdaten handhaben und speichern kann. Das Nutzerterminal 105 besitzt ein PKI-Schlüsselpaar, d. h. einen privaten und einen öffentlichen Schlüssel. Um das System vor einem Kopierangriff zu schützen, sollte es für den Nutzer angeraten sein, den privaten Schlüssel nicht zu verbreiten. Deswegen kann dieses System einen Schlüssel mit einer bestimmten Wichtigkeit für den Nutzer verwenden, wobei vorzugsweise ein Zertifikat erforderlich ist. Der private Schlüssel sollte mit einem Zertifikat gekoppelt sein, das durch eine Entität ausgegeben wird, der das System für die Ausgabe von Nutzerzertifikaten vertraut. Das Zertifikat wäre vorzugsweise das gleiche Zertifikat wie jenes, das zum Identifizieren des Nutzers verwendet wird. Das würde es für den Nutzer äußerst unbequem machen, einen Kopierangriff zu machen, da er dann einen vollständigen Zugang auf alle Informationen über ihn ermöglicht, unabhängig davon, an welchen Freund er den privaten Schlüssel gibt.
Berechtigte Signiereinheit 104
Eine berechtigte Signiereinheit 104 ist eine Entität, die Teil des elektronischen Ticketingsystems ist. Die berechtigte Signiereinheit 104 ist dem System zugeordnet, um Zertifikate zu signieren, die ausgegeben werden sollen und denen durch die Einheiten im System vertraut werden soll, d. h. die berechtigte Signiereinheit 104 bildet ein vertauenswürdiges Basiselement in dem System. Sie kann eine separate Einheit sein und gemeinsam mit der Ticket-Issuing-Unit 101 oder der Ticket-Receiving-Unit 103 angeordnet sein.
Es gibt eine vertrauensvolle Beziehung zwischen der Ticket-Issuing-Unit 101 und der Ticket-Receiving-Unit 103. Die Ticket-Receiving-Unit 103 muss den öffentlichen Schlüssel der Ticket-Issuing-Unit 101 besitzen. Dies kann erreicht werden, indem an die Ticket-Receiving-Unit 103 ein Zertifikat bereitgestellt wird, das von der berechtigten Signiereinheit 104 signiert ist, wobei das Zertifikat den öffentlichen Schlüssel der Ticket-Issuing-Unit 101 enthält oder den signierten öffentlichen Schlüssel tatsächlich in die Ticket-Receiving-Unit 103 programmiert.
Ticket-Issuing-Unit 101
Die Ticket-Issuing-Unit 101 ist die Entität, die ein Ticket erzeugt.
Es ist für den Nutzer 107 wichtig zu wissen, dass die Ticket-Receiving-Unit 103 eine vertrauenswürdige Einheit ist, insbesondere dann, wenn der Nutzer 107 sein Saison- oder Mehrfach ereignisticket, das ausgelaufen ist, durch die Ticket-Receiving-Unit 103 ungültig machen lässt. Gemäß einer ersten Ausführungsform der vorliegenden Erfindung wird dies dadurch gewährleistet, dass die Ticket-Issuing-Unit 101 ein Zertifikat besitzt, das durch die berechtigte Signiereinheit 104 signiert ist. Die Ticket-Receiving-Unit 103 besitzt Mittel auf, um dieses Zertifikat anhand des signierten Schlüssels zu verifizieren.
Gemäß einer zweiten Ausführungsform der vorliegenden Erfindung speichert die Ticket-Issuing-Unit 101 Kennungen für die gültigen Ticket-Receiving-Units, in denen in den Ticketdaten ein bestimmtes Ticket empfangen werden können. Wie dies verwendet wird, wird später beschrieben.
Ticket-Receiving-Unit Die Ticket-Receiving-Unit 103 ist die Entität, die die Tickets vom Nutzerterminal 105 sammelt, wenn der Nutzer 107 versucht, auf der Grundlage des Tickets Zugang zu erlangen. Zwischen der Ticket-Receiving-Unit 103 und dem Nutzerterminal 105 ist ein gegenseitiger Zugriff jeweils über ein Lokalnetz, z. B. über ein Lokalverbindungsprotokoll 109 möglich. Dies ist typischerweise ein drahtloser Zugriff. Ein Bus kann z. B. eine derartige Ticket-Receiving-Unit 103 nahe am Eingang des Busses aufweisen, so dass ein Nutzer 107, der auf den Bus gelangt, auf die Ticket-Receiving-Unit 103 zugreifen kann, um das Ticket zu übermitteln.
Der Nutzer 107 möchte ermitteln, ob das Nutzerterminal 105 irgendein relevantes Ticket hat, um es an die Ticket-Receiving-Unit 103 zu übermitteln. Deswegen wird die Ticket-Receiving-Unit 103 in Übereinstimmung mit der ersten Ausführungsform mit dem Zertifikat der Ticket-Issuing-Unit 101 versehen, wie oben erwähnt wurde. Wie dies verwendet wird, wird später beschrieben.
Die Ticket-Receiving-Unit 103 ist ferner mit einem eigenen Zertifikat versehen, das durch die berechtigte Signiereinheit 104 signiert ist. Die Ticket-Receiving-Unit 103 hat Mittel zum Empfangen eines Ticket-Datenpakets von einem Nutzerterminal 105, wobei das Ticket-Datenpaket den öffentlichen Schlüssel des Nutzerterminals 105 umfasst. Die Ticket-Receiving-Unit 103 muss verifizieren, dass das Nutzerterminal Zugriff auf den privaten Schlüssel hat, der zu diesem öffentlichen Schlüssel passt. Wenn die Ticket-Receiving-Unit 103 dies erreichen kann, weiß sie, dass das Nutzerterminal 105 beide Seiten des Schlüssels besitzt und dasjenige Nutzerterminal ist, das es vorgibt zu sein. Dies wird durch einen Challenge-Response-Mechanismus realisiert, durch den die Ticket-Receiving-Unit 103 Mittel zur Ausführung besitzt. Wie dies ausgeführt wird, wird ebenfalls später beschrieben.
Das System handhabt Daten, die über ein Großflächennetz, das typischerweise das Internet ist, durch ein Nutzerterminal 105 empfangen werden für den Zweck einer Übertragung dieser Daten zu einem späteren Zeitpunkt z. B. über ein Lokalverbindungsprotokoll an die Ticket-Receiving-Unit 103. Dies kann typischerweise in mobilen Terminals realisiert sein und den Ticketinganwendungen zur Verfügung gestellt werden.
Ticket-Issuing (Ticketausgabe)
Ein Beispiel der Ticket-Issuing-Abläufe wird im Folgenden unter Bezugnahme auf die in 2 gezeigte Darstellung der Signalisierungsabfolge beschrieben. Die Abläufe enthalten die folgenden Schritte:

201. Das Nutzerterminal 105 greift auf die Ticket-Issuing-Unit 101 zu und fordert ein Ticket an. Alternativ kann die Ticket-Issuing-Unit 101 die Auslösung bewirken.
202. Die Ticket-Issuing-Unit 101 baut eine geschützte Verbindung zu dem Nutzerterminal 105 auf. In diesem Kanal soll die Transaktion stattfinden. Die Ticket-Issuing-Unit 101 fordert von dem Nutzeragenten in dem Nutzerterminal 105 den öffentlichen Schlüssel an.
203. Der Nutzeragent in dem Nutzerterminal 105 sendet den öffentlichen Schlüssel an die Ticket-Issuing-Unit 101.
204. Die Ticket-Issuing-Unit 101 verifiziert die Korrektheit der Ticketanforderung. Sie erzeugt dann ein Ticket mit Daten, die beim Kauf festgelegt wurden, z. B. die Zeitdauer, für die das Ticket gültig ist, oder die Anzahl von Ereignissen, für die das Ticket gültig ist. Die Daten können einen Klartextteil und einen verschlüsselten Teil enthalten. Der Sinn des Klartextteils besteht darin, dass eine gute Nutzerschnittstelle am Nutzerterminal geschaffen werden kann. Gemäß der zweiten Ausführungsform enthalten die Daten ferner eine Liste von Kennungen, die einigen oder allen gültigen Ticket-Receiving-Units, in denen das Ticket verwendet werden kann, zugeordnet sind. Die Ticket-Issuing-Unit 101 fügt den öffentlichen Schlüssel des Nutzers an das Ticket an, wodurch ein Ticket-Datenpaket gebildet wird, das den öffentlichen Schlüssel des Nutzers und das Ticket umfasst. Die Ticket-Issuing-Unit 101 signiert anschließend das Ticket-Datenpaket und sendet das signierte Ticket-Datenpaket an das Nutzerterminal 105. Das bedeu tet, dass die Ticket-Issuing-Unit 101 als eine lokale Zertifikat-Behörde (CA) für das Ticketingsystem wirkt.
205. Das Nutzerterminal 105 erhält die signierten Ticketdaten und sendet eine Bestätigungsnachricht an die Ticket-Issuing-Unit 101.

Ticketnutzung
Ein Beispiel der Ticketnutzungsabläufe wird im Folgenden unter Bezugnahme auf die in 3 gezeigte Darstellung der Signalisierungsabfolge beschrieben. Die Abläufe enthalten die folgenden Schritte:

301. Wenn sich der Nutzer 107 und das Nutzerterminal 105 in Reichweite der Ticket-Receiving-Unit 103 befinden, sendet die Ticket-Receiving-Unit 103 eine Aufforderungsnachricht für die Ticketnutzung, wobei diese Nachricht das oben erwähnte Zertifikat der Ticket-Receiving-Unit 103 umfasst. Das Zertifikat sollte verwendet werden, um die Identität der Ticket-Receiving-Unit 103 nachzuweisen. Gemäß der ersten Ausführungsform der vorliegenden Erfindung umfasst diese Nachricht ferner das oben erwähnte Zertifikat der Ticket-Issuing-Unit 101. Alternativ kann das Nutzerterminal 105 die Auslösung bewirken.
302. Der Client des Nutzerterminals 105 verwendet gemäß der ersten Ausführungsform das Zertifikat der Ticket-Issuing-Unit 101, um nach passenden Tickets zu suchen. Gemäß der zweiten Ausführungsform der vorliegenden Erfindung wird die Identität der Ticket-Receiving-Unit 103 in Bezug auf die Liste von gültigen Ticketempfän gern, die in dem Ticket enthalten ist, für gültig erklärt. In beiden Ausführungsformen wird das erhaltene Zertifikat der Ticket-Receiving-Unit 103 verwendet, um die Identität der Ticket-Receiving-Unit 103 nachzuweisen. Wenn das Nutzerterminal 105 relevante Daten aufweist, d. h. ein Ticket, das zu übermitteln ist, und festgestellt wird, dass die Ticket-Receiving-Unit 103 vertrauenswürdig ist, wird die Datenübertragung fortgesetzt. Andernfalls wird die Datenübertragung an dieser Stelle beendet. Wenn die Datenübertragung fortgesetzt wird, überträgt der Client anschließend das durch die Ticket-Issuing-Unit signierte Ticket-Datenpaket, das das Ticket und den öffentlichen Schlüssel des Nutzerterminals 105 enthält, an die Ticket-Receiving-Unit 103. Die Übertragung des Ticket-Datenpakets an den Ticketempfänger kann automatisch erfolgen oder in der Weise konfiguriert sein, dass eine Nutzerbestätigung erforderlich ist. Die Ticket-Receiving-Unit 103 verifiziert die durch die Ticket-Issuing-Unit 101 erzeugte Signatur. Der öffentliche Schlüssel des Nutzers in nun auf sichere Weise empfangen worden. Da er in den Ticketdaten enthalten war, die durch die Ticket-Issuing-Unit 101 signiert wurden, wird verifiziert, dass er der gleiche öffentliche Schlüssel ist wie derjenige, der durch das Nutzerterminal 105 an die Ticket-Issuing-Unit 101 bereitgestellt wurde, als das Ticket ausgegeben wurde. Die Ticket-Receiving-Unit 103 muss nun verifizieren, dass das Nutzerterminal Zugriff auf den privaten Schlüssel hat, der zu diesem öffentlichen Schlüssel passt. Wenn die Ticket-Receiving-Unit 103 dies erreichen kann, weiß sie, dass das Nutzerterminal 105 beide Seiten des Schlüssels besitzt und deswegen das Nutzerterminal sein sollte, das es vorgibt zu sein. Dies wird durch einen Challenge-Response-Mechanismus realisiert. Der Challenge-Teil bedeutet, dass die Ticket-Receiving-Unit 103 eine Challenge in Form eines Zufallsdatenpakets, z. B. eine Zahl oder eine. Ziffernfolge erzeugt und möglicherweise weitere Daten, z. B. das Datum und die Uhrzeit daran anfügt. Die Ticket-Receiving-Unit 103 verschlüsselt diese Daten mit dem erhaltenen öffentlichen Schlüssel des Nutzers und sendet sie an das Nutzerterminal 105.
303. Der Response-Teil bedeutet, dass das Nutzerterminal 105 diese Daten empfängt und die Challenge unter Verwendung seines privaten Schlüssels entschlüsselt und die entschlüsselten Daten an die Ticket-Receiving-Unit 103 zurücksendet.
304. Wenn die Ticket-Receiving-Unit 103 verifiziert, dass die Response die gleichen Daten enthält, die in verschlüsselter Form in der Challenge gesendet wurden, ist die Nutzeridentität festgestellt worden. Die Ticket-Receiving-Unit 103 verifiziert die Ticketdaten. Wenn das Ticket noch gültig ist, wird dem Nutzer anhand des Tickets Zugang gewährt und sie sendet eine Ticketannahmebestätigung an das Nutzerterminal 105.

Ticketwiderruf eines Saison- oder Mehrfachereignistickets
Ein Beispiel von Ticketwiderrufabläufen wird im folgenden unter Bezugnahme auf die in 4 gezeigte Darstellung der Signalisierungsabfolge beschrieben. Ein Saisonticket ist gültig, bis eine bestimmte Zeitgrenze abgelaufen ist. Wie oben angegeben wurde, könnte es sich dabei um Stunden, Tage oder dergleichen handeln. Ein Mehrfachereignisticket ist gültig für eine vorgegebene Anzahl von Ereignissen. Wenn das Ticket ausgelaufen ist, d. h. die Zeitgrenze oder die Anzahl von Ereignissen wurde überschritten, wird der Ticketempfänger das Ticket nicht mehr akzeptieren. Wenn die Tickets nicht widerrufen werden, besteht ein mögliches Problem darin, dass die Ticket-Speicherungseinrichtung des Nutzers mit ausgelaufenen Tickets gefüllt wird, sowie in der erhöhten Komplexität bei mehreren passenden Tickets für einen Ticketempfänger, wovon lediglich einige Tickets oder ein Ticket gültig wären.
Es wird angenommen, dass der Nutzer versucht, in die U-Bahn zu gelangen und seine Ticket-Speicherungseinrichtung eine Anzahl von ausgelaufenen Tickets enthält. Da der Client nicht sicher sein kann, die korrekte Angabe der aktuellen Zeit zu haben, kann er wirklich nicht entscheiden, ob ein Ticket ausgelaufen ist. Im äußersten Fall müsste der Client dann fortgesetzt verschiedene Tickets versuchen, ob sie mit dem Ticketempfänger übereinstimmen, um festzustellen, ob eines von ihnen gültig ist. Es wäre viel einfacher, wenn der Ticketempfänger dem Client mitteilen würde, wann das Ticket ausgelaufen ist.
Es wird angenommen, dass der Nutzer für die Erneuerung seines Tickets verantwortlich ist. Das bedeutet, dass der Nutzer wissen würde, wann es Zeit ist, ein neues Ticket für das bestimmte Ereignis, z. B. für die U-Bahn zu kaufen. Der Nutzer kann ein neues Ticket kaufen, wann immer er möchte und muss nicht darauf warten, dass das alte Ticket ausgelaufen ist. Es wird außerdem angenommen, dass die Tätigkeit des Kaufs eines neuen Tickets nicht darin besteht, einfach die Gültigkeit des vorhandenen Tickets zu verlängern.
Um Konsistenz zu bewahren, können die folgenden Widerrufabläufe nach der Ausführung der oben beschriebenen Schritte 301-306 verwendet werden:

401. Die Ticket-Receiving-Unit 103 hat nun die Identität des Nutzers verifiziert. Die Ticket-Receiving-Unit 103 verifiziert die Ticketdaten. Diesmal stellt die Ticket-Receiving-Unit 1203 fest, dass das Ticket ausgelaufen ist. Sie sendet deswegen eine Ticket-Widerrufsnachricht an das Nutzerterminal 105.
402. Das Nutzerterminal 105 gibt die Tatsache bekannt, dass das Ticket ausgelaufen ist, und sendet eine Ticket-Ungültigkeitsbestätigung an die Ticket-Receiving-Unit 103. Das Nutzerterminal 105 kann das Ticket als ungültig kennzeichnen und es in eine sekundäre Datei alter Tickets verschieben, die der Nutzer als Referenz führen kann, oder es einfach löschen.
403. Die Ticket-Receiving-Unit 103 fordert das Nutzerterminal 105 auf, ein gültiges Ticket vorzulegen.
404. Das Nutzerterminal 105 versucht dann, ein weiteres Ticket an die Ticket-Receiving-Unit 103 zu senden, und wenn dieses Ticket gültig ist, wird die Prozedur ab dem oben beschriebenen Schritt 307 fortgesetzt.

Das Verfahren wird mittels eines Computerprogrammprodukts, das Softwarecodemittel zum Ausführen der Schritte des Verfahrens enthält, implementiert. Das Computerprogrammprodukt läuft in dem elektronischen Ticketingsystem auf einem Computer ab, der in einem Nutzerterminal, einer Ticket-Issuing-Unit und einer Ticket-Receiving-Unit enthalten ist. Das Computerprogramm wird direkt oder von einem computerlesbaren Medium, wie etwa eine Diskette, eine CD, das Internet usw. geladen.
Die vorliegende Erfindung ist nicht auf die oben beschriebenen bevorzugten Ausführungsformen beschränkt. Verschiedene Alternativen, Modifikationen und Entsprechungen können verwendet werden. Deswegen sollten die oben genannten Ausführungsformen nicht als Einschränkung des Umfangs der Erfindung betrachtet werden, der durch die beigefügten Ansprüche definiert ist.

Claims

Verfahren zur Handhabung eines elektronischen Tickets in einem elektronischen Ticketingsystem, welches System Public-Key-Kryptografie anwendet und welches System ein Nutzerterminal (105) umfasst, das einen miteinander verbundenen privaten Schlüssel und einen öffentlichen Schlüssel hat, welches Verfahren die folgenden Schritte umfasst: – Übermittlung des öffentlichen Schlüssels des Nutzerterminals (105) an eine Ticket-Issuing-Unit (101); – Kombinieren des öffentlichen Schlüssels durch die Ticket-Issuing-Unit (101) mit einem Ticket, welcher kombinierte Schlüssel und das Ticket ein Ticket-Datenpaket bilden; – Signieren des Ticket-Datenpakets durch die Ticket-Issuing-Unit (101) – Versenden des signierten Ticket-Datenpakets durch die Ticket-Issuing-Unit (101) an das Nutzerterminal; – Versenden des signierten Ticket-Datenpakets durch das Nutzerterminal (105) an eine Ticket-Receiving-Unit (103); – Erhalten des im empfangenen signierten Ticket-Datenpaket enthaltenen öffentlichen Schlüssels durch die Ticket-Receiving-Unit (103); – Verschlüsselung der Challenge-Daten mittels des öffentlichen Schlüssels; – Versendung der Challenge-Daten an das Nutzerterminal (105) zur Verifizierung des Nutzerterminals (105); – Entschlüsselung der verschlüsselten Challenge-Daten durch das Nutzerterminal (105) mit dem privaten Schlüssel des Nutzerterminals (105); – Versendung der entschlüsselten Challenge-Daten an die Ticket-Receiving-Unit (103); und – Akzeptieren des Tickets durch die Ticket-Receiving-Unit, falls die entschlüsselten Challenge-Daten dieselben sind wie die Challenge-Daten vor der Verschlüsselung derselben, und falls das Ticket gültig ist.
Verfahren nach Patentanspruch 1, wobei die Ticket-Receiving-Unit (103) ein von einer autorisierten Signiereinheit (104) signiertes Zertifikat hat, welches Verfahren als weiterer Schritt, der vor dem Schritt durchgeführt werden soll, in dem das Nutzerterminal (105) das signierte Ticket-Datenpaket an eine Ticket-Receiving-Unit (103) versendet, folgendes umfasst: – Versendung einer Einladungsnachricht durch die Ticket-Receiving-Unit an das Nutzerterminal (105), welche Nachricht das Zertifikat der Ticket-Receiving-Unit (103) umfasst.
Verfahren nach Patentanspruch 2, wobei das Nutzerterminal (105) das erhaltene Zertifikat der Ticket-Receiving-Unit (103) zur Verifikation der Identität der Ticket-Receiving-Unit (103) benutzt.
Verfahren nach einem der Patentansprüche 1-3, wobei die Einladungsnachricht ferner ein Zertifikat der Ticket-Issuing-Unit (101) umfasst.
Verfahren nach Patentanspruch 4, das als weiteren, durch das Nutzerterminal (105) vorzunehmenden Schritt umfasst: – Kontrollieren anhand des erhaltenen Zertifikats der Ticket-Issuing-Unit (101), ob es ein relevantes Ticket zur Abgabe an die Ticket-Receiving-Unit (103) hat.
Verfahren nach einem der Patentansprüche 2-3, wobei das Ticket-Datenpaket ferner eine Liste mit gültigen Ticket-Receiving-Units umfasst, in denen das Ticket empfangen werden kann.
Verfahren nach Patentanspruch 6, das als weiteren, durch das Nutzerterminal (105) vorzunehmenden Schritt umfasst: – Kontrollieren des Zertifikats der Ticket-Receiving-Unit (103) anhand der Liste von gültigen Ticket-Receiving-Units, um die Ticket-Receiving-Unit (103) zu identifizieren.
Verfahren nach einem der Patentansprüche 1-7, das als weiteren, durch die Ticket-Receiving-Unit (103) vorzunehmenden Schritt umfasst: – Versendung einer Ticket-Widerrufsnachricht an das Nutzerterminal (105), wenn es sich herausstellt, dass das Ticket ausgelaufen ist.
Verfahren nach Patentanspruch 8, das als weiteren Schritt umfasst: – Markieren des Tickets als ungültig; und – Ablegen des ungültigen Tickets in einer Datei für ungültige Tickets innerhalb des Nutzerterminals.
Verfahren nach einem der Patentansprüche 8-9, das als weiteren Schritt umfasst: – Versendung einer Nachricht an das Nutzerterminal (105), die eine Einladung enthält, ein gültiges Ticket vorzuweisen.
Computerprogramm-Produkt, das direkt in den internen Speicher eines Computers geladen werden kann innerhalb einer Ticket-Issuing-Unit, einer Ticket-Receiving-Unit und eines Nutzerterminals in einem elektronischen Ticketing-Systemsystem, das die Software-Codemittel zur Durchführung der Schritte nach einem der Patentansprüche 1-10 umfasst.
Computerprogramm-Produkt, gespeichert auf einem Computer-benutzbaren Medium, das ein lesbares Programm umfasst, um einen Computer ein einer Ticket-Issuing-Unit, einer Ticket-Receiving-Unit und einem Nutzerterminal in einem elektronischen Ticketingsystem zur Kontrolle einer Durchführung der Schritte nach einem der Patentansprüche 1-10 zu veranlassen.
Elektronisches, Public-Key-Kryptografie anwendendes Ticketingsystem, welches System ein Nutzerterminal (105) aufweist, bei dem ein privater Schlüssel und ein öffentlicher Schlüssel einander zugeordnet sind, eine Ticket-Issuing-Unit, die mit dem Nutzerterminal kommuniziert, um ein Ticket an das Nutzerterminal abzugeben, und eine Ticket-Receiving-Unit, die mit dem Nutzerterminal kommuniziert, um. ein Ticket vom Nutzerterminal zu empfangen, dadurch gekennzeichnet, dass das Nutzerterminal (105) Mittel umfasst zur Ablieferung des öffentlichen Schlüssels an die Ticket-Issuing-Unit (101) und Mittel zur Versendung des signierten Datenpakets an die Ticket-Receiving-Unit (103), welches Nutzerterminal (105) ferner Mittel umfasst, um verschlüsselte Challenge-Daten mit dem privaten Schlüssel des Nutzerterminals (105) zu entschlüsseln, der von der Ticket-Receiving-Unit (103) erhalten wurde, und Rücksendung der entschlüsselten Challenge-Daten zurück an die Ticket-Receiving-Unit, wobei die Ticket-Issuing-Unit (101) Mittel zum Erhalten eines öffentlichen Schlüssels des Nutzerterminals (105) und Mittel zum Kombinieren des öffentlichen Schlüssels mit einem Ticket umfasst, welcher kombinierte Schlüssel und das Ticket ein Ticket-Datenpaket bilden, und ferner Mittel umfasst zum Signieren des Datenpakets und Versendung desselben an das Nutzerterminal (105) die Ticket-Receiving-Unit (103) Mittel zum Empfangen eines signierten Ticket-Datenpakets vom Nutzerterminal (105) und Mittel zum Erhalten des im empfangenen signierten Ticket-Datenpaket enthaltenen öffentlichen Schlüssels umfasst, welches Datenpaket das mit dem öffentlichen Schlüssel des Nutzerterminals (105) kombinierte Ticket umfasst und das Datenpaket von der Ticket-Issuing-Unit (101) signiert ist, welche Ticket-Receiving-Unit ferner Mittel zur Benutzung des den öffentlichen Schlüssels zur Verschlüsselung von Challenge-Daten und Versendung der verschlüsselten Challenge-Daten an das Nutzerterminal (105) umfasst, um zu kontrollieren, ob das Nutzerterminal (105) einen privaten Schlüssel hat, der die Challenge zu entschlüsseln vermag, und Mittel fürs Akzeptieren des Tickets, falls die erhaltenen entschlüsselten Challenge-Daten dieselben sind wie die Challenge-Daten vor der Verschlüsselung derselben, und ob das Ticket gültig ist.
System nach Patentanspruch 13, wobei das Nutzerterminal (105) ferner Mittel fürs Erhalten eines Ticket-Datenpakets von der Ticket-Issuing-Unit (101) umfasst, welches Ticket-Datenpaket das mit dem gelieferten öffentlichen Schlüssel kombinierte Ticket umfasst und das Ticket-Datenpaket von der Ticket-Issuing-Unit (101) signiert ist.
System nach Patentanspruch 14, wobei das Nutzerterminal (105) Mittel zum Erhalten einer Nachricht umfasst, die eine Einladung enthält, das. Ticket an eine Ticket-Receiving-Unit (103) abzuliefern.
System nach Patentanspruch 15, wobei die Einladungsnachricht ferner ein Zertifikat der Ticket-Receiving-Unit (103) umfasst.
System nach Patentanspruch 16, wobei das Nutzerterminal (105) ferner Mittel zur Benutzung eines erhaltenen Zertifikats der Ticket-Receiving-Unit (103) zur Verifikation der Identität der Ticket-Receiving-Unit (103) umfasst.
System nach Patentanspruch 15, wobei das Nutzerterminal (105) ferner Mittel umfasst, um mittels eines erhaltenen Zertifikats der Ticket-Issuing-Unit (101), das in einer Einladungsnachricht von einer Ticket-Receiving-Unit (103) enthalten ist, zu kontrollieren, ob es ein relevantes Ticket zur Ablieferung an die Ticket-Receiving-Unit (103) hat.
System nach Patentanspruch 14-16, wobei das Nutzerterminal (105) ferner Mittel umfasst, um anhand einer Liste von gültigen Ticket-Receiving-Units, die in einem erhaltenen Ticket-Datenpaket enthalten ist, das Zertifikat der Ticket-Receiving-Unit (103) zu überprüfen, um die Ticket-Receiving-Unit (103) zu identifizieren.
System nach einem der Patentansprüche 14-19, wobei das Nutzerterminal (105) ferner Mittel umfasst, um eine Ticket-Widerrufsnachricht von der Ticket-Receiving-Unit (103) zu erhalten, wenn ein abgeliefertes Ticket ausgelaufen ist.
System nach einem der Patentansprüche 14-20, wobei das Nutzerterminal (105) ferner Mittel umfasst, um ein ungültiges Ticket als ungültig zu markieren.
System nach einem der Patentansprüche 14-21, wobei das Nutzerterminal (105) ferner eine Datei umfasst, die zur Speicherung eines ungültigen Tickets vorgesehen ist.
System nach einem der Patentansprüche 14-22, wobei die Ticket-Issuing-Unit (101) ferner Mittel umfasst, um das Datenpaket zu signieren und um es an das Nutzerterminal (105) zu versenden.
System nach einem der Patentansprüche 14-23, wobei die Ticket-Issuing-Unit (101) ferner eine Liste mit gültigen Ticket-Receiving-Units umfasst, in denen ein Ticket empfangen werden kann.
System nach einem der Patentansprüche 14-24, wobei die Ticket-Issuing-Unit (101) ferner Mittel umfasst, um die Liste in ein Ticket-Datenpaket einzubeziehen.
System nach einem der Patentansprüche 14-25, wobei die Ticket-Receiving-Unit (103) ferner Mittel umfasst zum Empfangen von durch das Nutzerterminal (103) entschlüsselten Challenge-Daten und Akzeptieren des Tickets, falls die empfangenen, entschlüsselten Challenge-Daten dieselben sind wie die Challenge-Daten vor der Verschlüsselung derselben, und falls das Ticket gültig ist.
System nach einem der Patentansprüche 14-26, wobei die Ticket-Receiving-Unit (103) ferner Mittel zur Versendung einer Nachricht an ein Nutzerterminal (105) umfasst, welche Nachricht eine Einladung umfasst, das Ticket an die Ticket-Receiving-Unit (103) abzuliefern.
System nach Patentanspruch 27, wobei die Einladungsnachricht ferner ein Zertifikat der Ticket-Receiving-Unit (103) umfasst.
System nach einem der Patentansprüche 27-29, wobei die Ticket-Receiving-Unit Kenntnis von einem Zertifikat der Ticket-Issuing-Unit (101) hat, welche Ticket-Issuing-Unit Tickets abgibt, die von der Ticket-Receiving-Unit (103) empfangen werden können, und wobei es ferner Mittel umfasst, um das Zertifikat der Ticket-Issuing-Unit (101) in die Einladungsnachricht einzubeziehen.
System nach einem der Patentansprüche 14-29, wobei die Ticket-Receiving-Unit (103) ferner Mittel umfasst zur Kontrolle, ob das empfangene Ticket ausgelaufen ist.
System nach Patentanspruch 30, wobei die Einladungsnachricht ferner Mittel umfasst zur Versendung einer Ticket-Widerrufsnachricht an das Nutzerterminal (105), wenn ein empfangenes Ticket ausgelaufen ist.
System nach einem der Patentansprüche 30-31, wobei die Ticket-Receiving-Unit (103) ferner Mittel zur Versendung einer Nachricht an das Nutzerterminal (105) aufweist, welche Nachricht. eine Einladung enthält, ein gültiges Ticket vorzuweisen.