DE60104411T2 - Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung - Google Patents

Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung Download PDF

Info

Publication number
DE60104411T2
DE60104411T2 DE60104411T DE60104411T DE60104411T2 DE 60104411 T2 DE60104411 T2 DE 60104411T2 DE 60104411 T DE60104411 T DE 60104411T DE 60104411 T DE60104411 T DE 60104411T DE 60104411 T2 DE60104411 T2 DE 60104411T2
Authority
DE
Germany
Prior art keywords
terminal
message
payment terminal
payment
identification
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60104411T
Other languages
English (en)
Other versions
DE60104411D1 (de
Inventor
Levente Buttyan
Edwin Wiedmer
Eric Lauper
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Swisscom AG
Original Assignee
Swisscom Mobile AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Swisscom Mobile AG filed Critical Swisscom Mobile AG
Application granted granted Critical
Publication of DE60104411D1 publication Critical patent/DE60104411D1/de
Publication of DE60104411T2 publication Critical patent/DE60104411T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/20—Point-of-sale [POS] network systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04K—SECRET COMMUNICATION; JAMMING OF COMMUNICATION
    • H04K1/00—Secret communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/50—Secure pairing of devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/80—Services using short range communication, e.g. near-field communication [NFC], radio-frequency identification [RFID] or low energy communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Description

  • Die vorliegende Erfindung betrifft ein elektronisches Zahlungsverfahren für Waren und Dienstleistungen. Insbesondere betrifft die vorliegende Erfindung ein Verfahren zur Durchführung von elektronischen Zahlungen mittels Smartcards und drahtloser Kommunikationstechnologien im Nahbereich.
  • Mit dem dramatischen Zuwachs von Kommunikationsnetzwerken (Computer sowie Telekommunikationsnetzwerke) wird e-Kommerz zu einer immer beliebteren Idee für Benutzer auf Wirtschafts- und Haushaltsebene. Ein Aspekt von e-Kommerz betrifft die elektronische Bezahlung von Waren und Dienstleistungen. Elektronische Zahlungssysteme versprechen mehr Bequemlichkeit und mehr Sicherheit. Letztere basiert auf die Anwendung starker Kryptographie, um Betrug zu verhindern.
  • Die Verwendung von Smartcards für die Benutzerauthentifizierung erlaubt die Einführung einer starken, auf kryptographischen Techniken basierenden Authentifizierung, da die Smartcard kryptographische Operationen durchführen und kryptographische Schlüssel für den Benutzer in einer verfälschungssicheren Zone speichern kann. Die Verwendung von Smartcards verlangt jedoch, dass Smartcardleser an den Authentifizierungsstellen installiert werden und dass die Benutzer eine Smartcard vorweisen und in einer nicht-vertrauten Vorrichtung einfügen.
  • Smartcards können auch in einen Smartcardslot einer Mobilvorrichtung, beispielsweise eines Personal Digital Assistants (PDA) oder eines Mobiltelefons, eines Benutzers eingefügt werden, um eine sichere Authentifizierung in einem Telekommunikationsnetzwerk, beispielsweise in einem mobilen Telekommunikationsnetzwerk, zu bieten. Um die Sitzungen über das mobile Netzwerk zu sichern kann die Smartcard kryptographische Rechenmittel umfassen, beispielsweise einen Prozessor und einen Speicher beinhaltend ein Programm, das vom Prozessor für die Berechnung von kryptographischen Funktionen durchgeführt werden kann. Mobilstationen, welche eine drahtlose Schnittstele im Nahbereich einschliessen, beispielsweise eine Funk- oder Infrarotschnittstelle, sind bekannt, die eine Datenübermittlung und/oder -synchronisierung zwischen der Mobilstation und anderen Endgeräten oder Computern in der Umgebung erlauben. Eine entsprechende Anordnung wird in WO-A-9944114 beschrieben.
  • Die Verwendung des Endgerätes des Benutzers, beispielsweise des Mobiltelephons des Benutzers, als Smartcardleser, welcher mit festen und öffentlichen Endgeräten (z.B. PC oder POS-Endgerät in einem Laden) über eine drahtlose Schnittstelle im Nahbereich verbunden ist, weist die folgenden Vorteile auf:
    • – Im Allgemeinen erlaubt die persönliche Mobilvorrichtung des Benutzers Letzterem, mit seiner Smartcard direkt zu kommunizieren (die Mobilvorrichtung verfügt über eine Tastatur und eine Anzeige); wenn herkömmliche Smartcardleser verwendet werden, muss der Benutzer auf der Tastatur des Endgerätes tippen und die Smartcard kann Meldungen nur auf der Anzeige des Endgerätes anzeigen, so dass ein böswilliges Endgerät die Kommunikation zwischen dem Benutzer und der Smartcard ändern kann;
    • – Insbesondere wird die Smartcard nie in eine nicht-vertrauten Vorrichtung eingefügt, welche versuchen könnte, mehr Daten aus der Smartcard abzurufen als sie sollte; und
    • – Der PIN-Code oder das Geheimnis, welches der Smartcard zugeteilt wird, wird nie in eine nicht-vertraute Vorrichtung eingetippt, welche sie missbrauchen oder stehlen kann;
    • – Ferner ist es nicht nötig, überall Smartcardleser zu installieren und sie an den verschiedenen Kartenformaten anzupassen.
  • Die Verwendung einer Mobilstation, die über eine drahtlose Schnittstelle mit einem Zahlungsendgerät verbunden ist, führt zu einigen neuen Sicherheitsproblemen. Das Hauptproblem liegt in der gegenseitigen Authentifizierung zwischen der Smartcard und dem festen Endgerät in der Anwesenheit von anderen, potentiell böswilligen Benutzern. Andere Sicherheitsprobleme (z.B. Probleme bezüglich der Integrität, der Vertraulichkeit und der Persönlichkeit) können auch auftreten.
  • Das technologische Hauptproblem ist, dass der Kommunikationskanal zwischen der persönlichen Mobilvorrichtung (Smartcardleser) und dem Zahlungsendgerät (Authentifizierungsstelle) nicht sicher ist. Wenn der Kartenleser in einem festen Zahlungsendgerät eingebaut oder damit physisch (mit einem kurzen Draht) verbunden ist, beispielsweise an einer Verkaufsstelle, können die zwischen der Karte und dem Endgerät gesandten Meldungen und Zahlungsbefehle nicht von einem Angreifer abgehört, geändert, wiedergegeben usw. werden. Dies setzt einen physischen Zugang zum Endgerät, zum Kartenleser oder zum sie verbindenden Draht voraus. Zudem, nach anfänglicher gegenseitiger Authentifizierung, können die Karte und das Endgerät sicher sein, dass die von ihnen während der übrigen Sitzung erhaltenen Meldungen von der anderen Partei stammen. Wenn die Kommunikation zwischen der Smartcard und dem Endgerät auf drahtlosen Technologien basiert, könnte ein Angreifer Meldungen oder Zahlungsbefehle zwischen ihnen abhören und wiedergeben, und die Smartcard und das Endgerät können nie sicher sein, ob die von ihnen erhaltenen Meldungen von der anderen Partei oder von anderen möglicherweise anwesenden Smartcards und Endgeräten stammen.
  • Die vorliegende Erfindung betrifft Lösungen für die sichere Verwendung der Mobilvorrichtung des Benutzers (wie beispielsweise des Mobiltelefons oder eines Personal Digital Assistants) als Smartcardleser, oder genereller als kryptographische Rechenmittel zur Authentifizierung des Benutzers, wenn er ein Zahlungsendgerät benutzen will. Insbesondere betrifft die vorliegende Erfindung Lösungen für die Verbindung der Mobilstation des Benutzers mit Zahlungsendgeräten mittels drahtloser Kommunikation im Nahbereich (z.B. Bluetooth, HomeRF oder Infrarot), welche die vorher erwähnten Nachteile vermeiden.
  • Gemäss der Erfindung werden die Sicherheitsprobleme des Stands der Technik mit einem neuen Protokoll gelöst, welches einen sicheren (authentischen und/oder vertraulichen) logischen Kanal zwischen den kryptographischen Rechenmitteln auf der mobilen Benutzerseite, dem Zahlungsendgerät und ferner zum Verrechnungsserver aufbaut. Der gesicherte logische Kanal basiert auf einem Geheimnis, welches exklusiv von der Smartcard in der Mobilvorrichtung und vom Endgerät geteilt wird, sowie auf der Anwendung von kryptographischen Techniken. Die Hauptfunktion des erfindungsgemässen Protokolls ist die sichere Herstellung dieses geteilten Geheimnisses durch Einbezug des Benutzers als authentischer Kanal zwischen dem Endgerät und der Mobilstation.
  • Das erfindungsgemässe Protokoll nimmt drei Wirtschaftsrollen an: die des Benutzers, die des Händlers und die des Verrechnungsservers. Jeder Benutzer ist bei mindestens einem Verrechnungsserver registriert, welcher einen Verrechnungskonto für den Benutzer verwaltet. Der Benutzer ist mobil, d.h. er bewegt sich körperlich und besucht verschiedene Handelsorte (z.B. Läden). Der Benutzer kann Waren oder Dienstleistungen vom Händler kaufen. Anstelle einer sofortigen Zahlung an den Händler wird der entsprechende Betrag einem Verrechnungskonto des Benutzers belastet. Der Verrechnungsserver sammelt Belastungsaktualisierungen von den Händlern und erstellt regelmässig (z.B. am Ende jedes Monats) für jeden Benutzer eine einzige Rechnung mit allen Käufen dieses Benutzers. In einer Variante belastet der Verrechnungsserver Geld von einem elektronischen Konto in der Smartcard des Benutzers. Der Verrechnungsserver verteilt dann die entsprechenden Anteile den Händlern.
  • Dies läuft nicht viel anders ab als die Bezahlung heutzutage mit Kreditkarte. Die Neuheit der Methode liegt in der Verwendung von drahtloser Kommunikationstechnologie im Nahbereich für die Kommunikation zwischen dem Benutzer (Smartcard in der Mobilvorrichtung des Benutzers) und dem Händler (Zahlungsendgerät, z.B. Verkaufsstelle POS). In der herkömmlichen Kreditkartenbezahlung wird die Karte oft dem Händler übergeben, der alle Informationen auf der Karte lesen kann und sie potentiell missbrauchen kann. In der erfindungsgemässen Methode ist die Karte in der persönlichen Mobilstation des Benutzers eingefügt und lediglich die mit dem aktuellen Kauf verbundene Zahlungsinformation wird dem Händler mitgeteilt. Ein anderer Vorteil ist, dass während in traditionellen Kreditkartensystemen die Verrechnung von Banken und Kreditkartenfirmen durchgeführt wird, in der vorliegenden Erfindung jedermann ein Verrechnungsdienstanbieter werden kann, insbesondere jede Telko-Firma mit der Kompetenz zum Verrechnen und dem Ruf (was meistens Vertrauen bedeutet).
  • Gemäss einem Aspekt der Erfindung werden eine neue einmalige Transaktionsidentifizierung und der Endgerätname auf der Anzeige besagtes Endgerätes oder der Mobilvorrichtung angezeigt und vom Benutzer auf die Eingabemittel des/der anderen von benannten Zahlungsendgeräten oder Mobilvorrichtungen eingegeben. Der Endgerätname und die Transaktionsidentifizierung werden für die Herstellung eines gesicherten Kanals zwischen der Mobilvorrichtung und dem Zahlungsendgerät verwendet.
  • Gemäss einem anderen Aspekt der Erfindung ist der hergestellt gesicherte Kanal ein authentischer Kanal. Dies bedeutet, dass die Kommunikationsparteien sicher sein können, dass eine auf diesem Kanal empfangene Meldung von der anderen Partei stammt und keine falsche, von einem Angreifer gesandte Meldung ist. Das Protokoll kann auch verwendet werden, um das Abhören zu verhindern (d.h. um einen authentischen und vertraulichen Kanal herzustellen).
  • Gemäss einem anderen Aspekt der Erfindung hat der Benutzer eine Smartcard und eine persönliche Mobilvorrichtung, in welcher die Smartcard eingefügt werden kann und welche drahtlose Kommunikationsfähigkeiten im Nahbereich besitzt. Das erfindungsgemässe Verfahren könnte jedoch gleich gut funktionieren, wenn der Benutzer einen Personal Digital Assistant (PDA) hat, welcher drahtlose Kommunikationsfähigkeiten im Nahbereich besitzt. Somit besteht kein wirklicher Bedarf für Smartcards. Ein PDA kann die Smartcard ersetzen, denn er kann den Benutzer unterstützen, indem er kryptographische Operationen gleich wie eine Smartcard durchführt.
  • Gemäss einem anderen Aspekt der Erfindung werden die Probleme des Stands der Technik gelöst durch ein Verfahren zur Übertragung von Zahlungsinformationen zwischen einer Mobilstation und einem Zahlungsendgerät (11) über eine drahtlose Schnittstelle im Nahbereich (101), umfassend:
    • – das Anzeigen einer Identifizierung auf der Anzeige (110) des besagten Zahlungsendgerätes (11),
    • – das manuelle Eingeben besagter Identifizierung auf den Eingabemitteln (103) der besagten Mobilstation,
    • – das Verwenden besagter Identifizierung in einer ersten Meldung, um einen authentischen und vertraulichen Kanal zwischen besagter Mobilstation und besagtem Zahlungsendgerät (11) aufzubauen,
    wobei besagter Kanal dazu verwendet wird, um vertrauliche Zahlungsinformationen zwischen besagtem Zahlungsendgerät und besagter Mobilstation auszutauschen.
  • Ein wichtiges Merkmal eines elektronischen Zahlungssystems ist, ob es online oder offline ist. In einem online Zahlungssystem kontaktiert der Händler die Bank des Benutzers bei jedem Kauf, um die Solvenz des Benutzers zu überprüfen. In einem offline Zahlungssystem wird die Bank nur offline (z.B. einmal pro Tag) kontaktiert, um die Belastungsinformation des Benutzers zu aktualisieren. Online-Systeme werden für Hochwertzahlungen verwendet und wenn der Händler dem Benutzer nicht traut. Für Niederwertzahlungen und wenn der Händler dem Benutzer traut, sind Offline-Systeme effizienter. Die erfindungsgemässe Lösung kann mit beiden Arten von Anwendungen verwendet werden und lässt den Händler auswählen, ob eine Online-Überprüfung der Solvenz nötig ist oder nicht.
  • Die Erfindung wird besser verstanden anhand der nachfolgenden Beschreibung, welche als Beispiel angegeben und durch die Figuren illustriert wird. Es zeigen:
  • 1 die Beteiligten und die Kanäle eines Systems mit einer in einem Mobiltelefon oder PDA eingefügten Smartcard, einem Zahlungsendgerät und einem Verrechnungsserver.
  • 2 die Meldungen, welche zwischen zwei Partnern gemäss dem ISO/IEC 9798-3 Protokoll ausgetauscht werden.
  • 3 die Meldungen und Schlüssel, welche zwischen zwei Partnern in einer modifizierten Form des ISO/IEC 9798-3 Protokolls ausgetauscht werden.
  • 4 die Meldungen, welche zum Autorisieren eines Geldtransfers ausgetauscht werden.
  • 5 die Meldungen, welche zwischen den Beteiligten über die verschiedenen Kanäle in einer bevorzugten Ausführungsform der Erfindung ausgetauscht werden.
  • Beteiligte, Kanäle und Ziele
  • 1 zeigt die Beteiligten und die Kanäle zwischen ihnen.
  • Die Beteiligten sind:
    • – U: der mobile Benutzer 1
    • – C: dessen Smartcard 100, z.B. eine SIM-Karte (Subscriber Identification Card), WIM-Karte (WAP Identification Card) oder UIM-Karte (UMTS Identification Card). Die Smartcard wird eingefügt oder kann ein Teil einer Mobilvorrichtung sein, z.B. ein Mobiltelefon oder ein PDA (nicht gezeigt). Die Mobilvorrichtung einschliesslich Smartcard wird Mobilstation genannt.
    • – T: das Zahlungsendgerät 11 (Point-Of-Sale) des Händlers.
    • – S: der Verrechnungsserver 7, der vom Mobilnetzwerkbetreiber oder von einer Drittpartei betrieben werden kann.
  • Die physischen Kanäle sind:
    • – md: die Anzeige 102 der Mobilvorrichtung beinhaltend die Karte (C → U)
    • – mk: die Tastatur 103 der Mobilvorrichtung beinhaltend die Karte (U → C)
    • – td: die Anzeige 110 des Zahlungsendgerätes 11 (T → U)
    • – wl: die drahtlose Verbindung 101 zwischen der in der Mobilvorrichtung eingefügten Smartcard 100 und dem Zahlungsendgerät 11 (C ↔ T)
    • – net: das feste Netzwerk 70 zwischen dem Zahlungsendgerät 11 und dem Verrechnungsserver 7 (T ↔ S)
  • Die logischen Kanäle sind:
    • – SigU: der Kanal, der durch die digitale Signatur mit dem privaten Schlüssel des Benutzers 1 realisiert wird.
    • – KU: der Kanal, der durch die Verschlüsselung mit dem öffentlichen Schlüssel des Benutzers 1 implementiert wird.
    • – SigT: der Kanal, der durch die digitale Signatur mit dem privaten Schlüssel des Zahlungsendgerätes 11 realisiert wird.
    • – KT: der Kanal, der durch die Verschlüsselung mit dem öffentlichen Schlüssel des Zahlungsendgerätes 11 implementiert wird.
  • Da der Benutzer 1 normalerweise die Tastatur des Zahlungsendgerätes 11 des Händlers benutzen kann, gibt es keinen physischen Kanal vom Benutzer zum Endgerät 11.
  • Wir machen die folgenden Annahmen bezüglich der Kanäle:
    • – Die Anzeige 102 md der Mobilvorrichtung ist authentisch und echtzeitig. Authentizität bedeutet, dass, wenn die Mobilvorrichtung eine Meldung anzeigt und angibt, diese Meldung stamme von der Smartcard 100, die Meldung tatsächlich von der Smartcard 100 stammt. Echtzeitigkeit bedeutet, dass die Mobilvorrichtung nicht böswillig Meldungen, welche aus der Smartcard 100 stammen, verzögert sondern sie anzeigt, sobald die Karte sie erzeugt. Dies bedeutet selbstverständlich, dass der Mobilvorrichtung vertraut wird: der Benutzer glaubt, dass sie von niemandem verfälscht wurde und dass sie sich korrekt verhält.
    • – Die Tastatur 103 mk der Mobilvorrichtung ist authentisch und echtzeitig. Wir nehmen an, dass nur der Benutzer 1 der Smartcard 100 Meldungen an die Smartcard über die Tastatur 103 der Mobilvorrichtung versenden kann. Die Notwendigkeit für den Benutzer 1, den der Smartcard 100 zugeteilten PIN einzugeben, wenn die Karte in die Mobilvorrichtung eingefügt wird oder bevor eine Zahlungstransaktion gestartet wird, kann dies garantieren. Ferner nehmen wir an, dass die Mobilvorrichtung die Eingabe vom Benutzer 1 nicht böswillig verzögert, sondern sie an die Karte 100 liefert, sobald der Benutzer sie eingibt.
    • – Die Endgerätanzeige 110 td ist authentisch und echtzeitig. Dies bedeutet, dass Meldungen, welche auf der Anzeige 110 des Endgerätes 11 angezeigt werden, vom Endgerät zur Zeit, wo sie angezeigt werden, stammen.
    • – Die drahtlose Verbindung 101 wl zwischen der Mobilvorrichtung und dem festen Endgerät 11 ist nicht gesichert. Wir nehmen an, dass passive Angriffe (Abhören) sowie aktive Angriffe (Meldungsänderung, -erzeugung und -wiedergabe) auf die drahtlose Verbindung zwischen der Mobilstation und dem Endgerät möglich sind.
    • – SigU ist ein authentischer Kanal aus der Smartcard 100, da nur die Smartcard den privaten Schlüssel des Benutzers 1 kennt; somit kann man sicher sein, dass mit diesem privaten Schlüssel signierte Meldungen von der Smartcard 100 stammen.
    • – KU ist ein vertraulicher Kanal zur Smartcard 100, da nur die Smartcard Meldungen entschlüsseln kann, die mit dem öffentlichen Schlüssel des Benutzers 1 verschlüsselt sind. Zu beachten ist, dass weder SigU noch KU echtzeitige Kanäle sind, da weder die digitale Signatur noch die Verschlüsselung alleine Ungebrauchtheitsgarantien liefert.
    • – net ist gesichert. Wir nehmen an, dass das Zahlungsendgerät 11 und der Verrechnungsserver 7 über die Mittel verfügen, sich gegenseitig zu authentifizieren und gesichert miteinander über das Netzwerk zu kommunizieren. Dieser Schutz kann auf anderen bekannten kryptographischen Protokollen und Mechanismen basieren, welche in dieser Beschreibung nicht angesprochen werden.
    • – SigT ist ein authentischer Kanal vom Endgerät 11, da nur das Endgerät Meldungen erzeugen kann, die mit dem privaten Schlüssel des Endgerätes signiert werden.
    • – KT ist ein vertraulicher Kanal zum Endgerät, da nur das Endgerät Meldungen entschlüsseln kann, die mit dem öffentlichen Schlüssel des Endgeräts verschlüsselt sind.
  • Ein Zweck der Erfindung ist es, ein Protokoll zu finden zur Herstellung eines authentischen und vertraulichen logischen Kanals zwischen dem Endgerät 11 und der Smartcard 100 (um Zahlungsinformation von Abhörern zu verheimlichen) und ferner zum Verrechnungszentrum 7, wobei nur die oben beschriebenen schon existierenden physischen und logischen Kanäle verwendet werden, sowie ein Protokoll zu finden, in welchem der Benutzer 1 dem Verrechnungsserver 7 erlaubt, den Händler für die gelieferten Waren oder Dienstleistungen zu bezahlen und den entsprechenden Betrag dem Verrechnungskonto zu belasten.
  • Das erweiterte ISO/IEC 9798-3 Protokoll
  • 2 zeigt das standardisierte gegenseitige Authentifizierungsprotokoll ISO/IEC 9798-3. 3 zeigt eine erfinderische Erweiterung dieses Protokolls mit Schlüsselherstellungsfunktionen. Das ISO/IEC 9798-3 Protokoll basiert auf der Kryptographie mit öffentlichen Schlüsseln und nimmt an, dass beide teilnehmenden Parteien A, B ein öffentliches Schlüssel-Zertifikat besitzen. Dies ist konsistent mit unseren Annahmen über die existierenden Kanäle zwischen der Smartcard und dem Endgerät.
  • Das gegenseitigen Authentifizierungsprotokoll ISO/IEC 9798-3 wird in 2 illustriert: A → B: rA.
  • Der Initiator des Protokolls A erzeugt eine ungebrauchte Zufallszahl ra, und sendet sie an den Antwortenden B. B → A : certB, rB, A, Sigb(rB, rA, A)
  • B erzeugt auch eine ungebrauchte Zufallszahl ra und signiert digital rB, rA und A (die Identifizierung von A). Dann sendet er an A eine Mitteilung, welche das öffentliche Schlüsselzertifikat certB von B, die Zufallszahl rb, die Identifizierung von A, und die digitale Signatur SigB(rB, rA, A) enthält. Beim Erhalt dieser Meldung überprüft A das Zertifikat und die digitale Signatur von B. Wenn die Überprüfungen erfolgreich sind, wird B authentifiziert. Die Überlegung ist, dass eine gültige Signatur nur durch jemanden erzeugt werden kann, der den entsprechenden privaten Schlüssel kennt (d.h. B) und die Daten, auf Grund deren die Signatur erzeugt wurde, ungebraucht sind (da sie die Zufallszahl rA enthalten). A → B : certA, B, SigA(rA, rB, B)
  • Dann signiert A digital rA, rB und B, und sendet an B eine Meldung, welche das öffentliche Schlüsselzertifikat von A enthält, die Identifizierung von B und die digitale Signatur Siga(rA, rB, B). Beim Erhalt dieser Meldung überprüft B das Zertifikat und die digital Signatur von A. Wenn die Überprüfungen erfolgreich sind, wird A aus ähnlichen Gründen wie vorher authentifiziert.
  • Um dieses Protokoll mit Schlüsselherstellungsfunktionen zu erweitern, wird nur die letzte Meldung des Protokolls geändert. Bevor die letzte Meldung gesandt wird, erzeugt A zufällig einen symmetrischen Sitzungsschlüssel k, und verschlüsselt ihn mit dem öffentlichen Schlüssel Kb von B. Nur der Beantwortende B wird in der Lage sein, diese Verschlüsselung zu entschlüsseln. A signiert dann digital die Zufallsnummern rA und rB, die Identifizierung von B und den Sitzungsschlüssel k. Beim Erhalt dieser Meldung entschlüsselt B zuerst den verschlüsselten Teil und überprüft dann das Zertifikat und die Signatur von A. Wenn die Überprüfungen erfolgreich sind, wird A authentifiziert. Ferner haben A und B ein geteiltes Geheimnis k erstellt, welches einen authentischen und vertraulichen Kanal zwischen ihnen darstellt. Das modifizierte Protokoll ist in 3 illustriert.
  • Wenn die Signierungsoperation so ist, dass sie die signierten Daten aufzeigt, so erfordern wir, dass zuerst ein kryptographischer Hash-Wert aus den Daten berechnet wird und dass dieser Hash-Wert dann mit der Signierungsoperation signiert wird. Auf diese Weise wird k für Abhörer nicht angezeigt.
  • Das Zahlungsprotokoll
  • Die Auslegung des Zahlungsprotokolls basiert auf der Beobachtung, dass Bezahlung gleichbedeutend mit Authentifizierung ist, wenn Geld durch Konten dargestellt wird. Dies bedeutet, dass im erfindungsgemässen Protokoll die Bezahlung einen authentischen Befehl des Bezahlers (d.h. des Benutzers) darstellt, worin Letzterer erklärt, dass er bereit ist, einen bestimmten Betrag von seinem Konto zum Konto des Bezahlten (d.h. des Händlers) zu überweisen. Die Authentizität des Befehls wird durch den Bezahlten sowie durch die Kontoverwaltungsstelle (d.h. den Verrechungsserver) überprüft. Das Protokoll wird in 4 dargestellt und wie folgt beschrieben: msg1 : A → B : certA, A, B, T-info, P-info, SigA (A, B, T-info, P-info).
  • Der Bezahler (Smartcard 100 des Benutzers) A signiert digital seine Identifizierung A, die Identifizierung B des Bezahlten B (Zahlungsendgerät 11), die Transaktionsinformation T-info, und die Bezahlungsinformation P-info. Es wird nicht explizit spezifiziert, was T-info und P-info sind. Typischerweise enthält T-info eine einzigartige Transaktionsidentifizierung, die Identifizierung der erbrachten Dienstleistung, das Datum und die Zeit der Lieferung, den Einheitspreis, usw. P-info enthält die Identifizierung des Verrechnungsservers, den zu zahlenden Betrag, die Fälligkeit für die Unterbreitung dieser Meldung an den Verrechnungsserver, usw. Beim Erhalt der ersten Meldung überprüft B das Zertifikat und die digitale Signatur von A. msg2 : B → A : certB, SigB(h(msg1))
  • B erzeugt eine Zahlungsquittung, indem ein kryptographischer Hash-Wert h(msg1) der ersten Meldung berechnet wird und eine digitale Signatur auf dem Resultat erzeugt wird. Er sendet dann sein Zertifikat und die Signatur an A. msg3 : B → S : certA, A, B, T-info, P-info, SigA(A, B, T-info, P-info)
  • Schlussendlich kontaktiert B den Verrechnungsserver S (7) und sendet ihm die erste Meldung (d.h. die Zahlungseinwilligung von A). S überprüft die Signatur und ob die Zahlung nicht vorher schon bearbeitet wurde. Dann wird der entsprechende Betrag an B überwiesen und das Verrechnungskonto von A wird aktualisiert. S bucht die Bezahlung in eine interne Datenbank zwecks weiterer Überprüfungen.
  • Integrierte Lösung - Bezahlung über die drahtlose Schnittstelle im Nahbereich
  • Beschreibung des Protokolls
  • Indem das erweiterte Protokoll ISO/IEC 9798-3 und das obige Bezahlungsprotokoll zusammengestellt werden, erreicht man die folgende, in 5 illustrierte Lösung: T → U : T, T-info
  • Das Zahlungsendgerät T (11) zeigt die Identifizierung T des Endgerätes und die Transaktionsinformation T-info auf der Anzeige 102 des Endgerätes an. Die Transaktionsinformation enthält eine (mindestens bezüglich dieses Endgerätes) einzigartige Transaktionsidentifikation T-id, die Identifizierung der erbrachten Dienstleistung, das Datum und die Zeit der Lieferung, den Preis, usw. U → C : T, T-id.
  • Der Benutzer U (1) tippt die Identifizierung des Endgerätes T und die Transaktionsidentifikation T-id auf die Tastatur 103 der Mobilvorrichtung ein, welche diese Information an die Smartcard C (100) sendet. C → T : T, T-id, rC.
  • Die Smartcard 100 erzeugt eine ungebrauchte Zufallszahl rC, und sendet sie an das Zahlungsendgerät 11 zusammen mit T und T-id über die drahtlose Verbindung 101. Das Endgerät 11 kann mehrere Meldungen von anderen, sich in seiner Kommunikationsreichweite befindenden Endgeräten 11 und Smartcards 100 empfangen, während es auf diese Meldung der Smartcard wartet. Es bearbeitet nur die Meldung, welche seine Identifizierung T und die gültige Transaktionsidentifikation T-id enthält. Alle anderen Meldungen werden ignoriert. T → C : certT, rT, SigT(rT, rC, T, T-id)
  • Das Zahlungsendgerät 11 erzeugt eine zweite ungebrauchte Zufallszahl rT. Es signiert die Zufallszahl der Smartcard rC, zusammen mit der eigenen Zufallszahl rT, der eigenen Identifizierung T, und der Transaktionsidentifikation T-i d. Es sendet dann sein Zertifikat certT, seine Zufallszahl rT, und die digitale Signatur an die Smart card 100. Die Smartcard überprüft das Zertifikat und die Signatur des Endgerätes. Neben einer gültigen Signatur sollte das Zertifikat die Endgerätidentifizierung T enthalten, welche vom Benutzer auf die Tastatur der Mobilvorrichtung eingetippt wurde. Wenn die Überprüfungen alle erfolgreich waren, wird das Zahlungsendgerät 11 authentifiziert. C → T : certU, {k}KT, SigU(rC, rT, T, T-id, k)
  • Die Smartcard 100 erzeugt zufällig einen symmetrischen Schlüssel k und verschlüsselt ihn mit dem öffentlichen Schlüssel KT des Zahlungsendgerätes 11. Dieser öffentliche Schlüssel wird vom Zertifikat des Endgerätes gewonnen. Die Smartcard 100 signiert die Zufallszahlen rT und rC, die Identifizierungen T und T-id, und den gerade erzeugten symmetrischen Schlüssel k. Sie sendet dann das Zertifikat des Benutzers certU, den verschlüsselten symmetrischen Schlüssel und die digitale Signatur an das Endgerät. Wenn die Signatur die signierten Daten nicht verheimlicht, können dann in einer anderen Ausführungsform die signierten Daten mit einer kryptographischen Hash-Funktion, bevor sie signiert werden, gehasht werden. Das Endgerät entschlüsselt den verschlüsselten Teil und überprüft das Zertifikat und die Signatur der Smartcard 100. Wenn diese Überprüfungen erfolgreich sind, wird die Smartcard des Benutzers gegenüber dem Endgerät authentifiziert. Ferner haben die Smartcard und das Zahlungsendgerät einen geteilten symmetrischen Sitzungsschlüssel k erstellt. T → C : {T, T-info}k
  • Das Zahlungsendgerät 11 sendet seine Identifizierung und die Transaktionsinformation, die dem Benutzer auf der Anzeige 110 des Zahlungsendgeräts 11 angezeigt wurde, an die Smartcard 100. Diese Meldung wir mit dem geteilten Sitzungsschlüssel k verschlüsselt. Da nur das Zahlungsendgerät 11 diesen Schlüssel kennt (ausser der Smartcard 100, selbstverständlich), glaubt die Smartcard, dass diese Meldung vom Endgerät gesandt wurde. C → U : T, T-info
  • Die Smartcard 100 zeigt die empfangene Information auf der Anzeige 102 der Mobilvorrichtung an. Der Benutzer 1 überprüft sie und vergleicht sie mit der Information, welche vom Zahlungsendgerät 11 auf deren Anzeige 110 angezeigt wird. U → C : confirmation
  • Wenn die von der Mobilvorrichtung angezeigte Information mit der vom Endgerät 11 angezeigten Information übereinstimmt, bestätigt der Benutzer 1 (z.B. durch Drücken auf der OK-Taste der Mobilvorrichtung). C → T : {U, T, T-info, P-info, SigU(U, T, T-info, P-info)}k
  • Die Smartcard 100 generiert die Zahlungsmeldung, welche die Identifizierungen des Benutzers und des Händlerzahlungsgerätes, die Transaktionsinformation und die Zahlungsinformation enthält, und welche von der Smartcard 100 mit dem privaten Schlüssel des Benutzers digital signiert wird. Wenn die Signatur die signierten Daten nicht verheimlicht, so verlangen wir, dass zuerst die Daten mit einer kryptographischen Hash-Funktion gehasht werden und dass der Hash-Wert mit dem privaten Schlüssel des Benutzers signiert wird. Die Zahlungsmeldung wird mit dem Sitzungsschlüssel k verschlüsselt und dem Endgerät gesandt. Diese Verschlüsselung verheimlicht die Zahlungsinformation vor Angreifern. Beim Erhalt dieser Meldung wird Letztere vom Endgerät 11 entschlüsselt und die digitale Signatur überprüft, T → S : verification
  • Wenn der Händler dem Benutzer 1 nicht traut oder die Zahlung eine Hochwertzahlung ist, kann nun das Endgerät 11 den Verrechnungsserver 7 oder einen Zertifikatwiderrufslistenserver kontaktieren, um die Solvenz des Benutzers 1 zu überprüfen (Online-Solvenzprüfung). T → C : {SigT(h(U, T, T-info, P-info, SigU(U, T, T-info, P-info)))}k
  • Das Endgerät 11 erzeugt eine Zahlungsquittung, indem der kryptographische Hash-Wert der Zahlungsmeldung (ohne die Verschlüsselung) unter Verwendung eines öffentlich bekannten kryptographischen Hash-Werts h berechnet wird, und der Hash-Wert signiert wird. Die Zahlungsquittung ist mit dem Sitzungsschlüssel k verschlüsselt und wird an die Smartcard 100 gesandt. T → S : certU, U, T, T-info, P-info, SigU(U, T, T-info, P-info)
  • Schlussendlich kontaktiert das Endgerät 11 den Verrechnungsserver 7 und präsentiert die Zahlungsmeldung, die sie vom Benutzer 1 erhalten hat. Diese Meldung wird über einem Kanal 70 (net) gesandt, dessen Sicherheit durch Mittel gewährleistet wird, die ausserhalb des Rahmens dieses Berichts fallen. Der Verrechnungsserver 7 überprüft das Zertifikat und die Signatur des Benutzers. Er prüft dann, ob diese Zahlung nicht schon vorher bearbeitet wurde, indem er seine interne Logdatenbank kontrolliert. Wenn die Überprüfungen erfolgreich sind, überweist der Verrechnungsserver den entsprechenden Betrag an den Händler und aktualisiert das Verrechnungskonto des Benutzers. Er prorokolliert auch die Transaktion in seine interne Logdatenbank.
  • Zertifikatverwaltung
  • Öffentlicher Schlüssel Infrastruktur
  • Das Verfahren verwendet vorzugsweise eine unterliegende Infrastruktur mit öffentlichem Schlüssel. Zertifikate mit öffentlichen Schlüsseln können von Zertifizierungsorganen (Certification Authority, CA) herausgegeben werden, welche hierarchisch organisiert werden können. Widerrufene Zertifikate können auf einer Zertifikatwiderrufsliste (Certificate Revocation List, CRL) aufgelistet werden.
  • In einer bevorzugten Ausführungsform wird das folgende Schema verwendet:
    • – Für Hochwertzahlungen überprüft der Benutzer das Zertifikat des Händlers anhand der CRL;
    • – Für Niederwertzahlungen führt der Benutzer keine Widerrufsüberprüfung durch;
    • – Für Hochwertzahlungen und Niederwertzahlungen, bei denen der Händler dem Benutzer nicht traut, überprüft der Händler das Zertifikat des Benutzers anhand der Online-CRL über das feste Netzwerk;
    • – Für Niederwertzahlungen, bei denen der Händler dem Benutzer traut, überprüft der Händler seine lokale Kopie der regelmässig anhand des Online-CRL-Servers aktualisierten CRL.
  • Erzielte Ergebnisse
  • Das Endgerät 11 (die Smartcard 100) glaubt, dass die Smartcard 100 (das Endgerät 11) kürzlich eine Meldung gesandt hat (Wiederholung Zufallszahl), was bedeutet, dass beide anwesend sein sollten (Authentifizierung). Die Smartcard und das Endgerät glauben, dass k ein geteilter geheimer Schlüssel zwischen ihnen ist (Schlüsselherstellung). Das Endgerät 11 und der Verrechnungsserver 7 glauben, dass der Benutzer 1 die Bezahlung erlaubt hat. Es gibt einen subtilen Unterschied: Das Endgerät 11 glaubt, dass die Erlaubnis des Benutzers ungebraucht ist (da sie mit dem ungebrauchten geheimen Schlüssel verschlüsselt ankommt), aber der Verrechnungsserver 7 kann über die Ungebrauchtheit dieser Erlaubnis nicht sicher sein. Deshalb verlangen wir, dass der Server 7 seine interne Logdatenbank konsultiert und überprüft, ob diese Erlaubnis noch nie bearbeitet wurde.
  • Schlussfolgerung
  • In diesem Abschnitt haben wir ein Zahlungsprotokoll vorgestellt, das verwendet werden kann, um elektronische Zahlungen über eine drahtlose Schnittstelle im Nahbereich zu tätigen. Das Protokoll hat zwei Phasen: (1) es erstellt einen authentischen und vertraulichen Kanal zwischen der Smartcard des Benutzers und dem Zahlungsendgerät des Händlers, und (2) es liefert die Mittel, Geldüberweisungen vom Konto des Benutzers zum Konto des Händlers zu bewilligen. Die Konten werden von einer vertrauten Drittpartei, Verrechnungsserver genannt, verwaltet.
  • Implementierungsrichtlinien
  • Die drahtlose Verbindung 101 zwischen der Smartcard 100 in der Benutzervorrichtung und dem Endgerät 11 kann auf Funk- oder Infrarotkommunikation basieren. Wir haben die Existenz eines geeigneten Adressierungsschemas vorausgesetzt, was das Senden einer Meldung direkt an einen beabsichtigten Empfänger, wenn dessen Adresse bekannt ist, ermöglicht, und eines geeigneten MAC (Multiple Access Channel) Algorithmus, welcher den Zugang zum geteilten Funkkanal regelt. Wir haben jedoch nicht angenommen, dass eine Partei die MAC Adresse einer anderen Partei kennt, wenn sie eine Transaktion mit ihr beginnt. Wir haben das Protokoll so ausgelegt, dass es Adressenauflösungsfunktionen nahtlos durchführen kann. Aus diesen Gründen ist die erste über die drahtlose Verbindung 101 gesandte Meldung eine Broadcast-Meldung, welche von jedem Zahlungsendgerät 11 innerhalb der Kommunikationsreichweite der Mobilvorrichtung des Benutzers 1 empfangen wird. Diese erste Meldung enthält immer genug Information, damit ein Empfänger 11 entscheiden kann, ob er sie bearbeiten muss oder ob die Meldung für jemanden anders bestimmt ist. Der beabsichtigte Empfänger kann somit erkennen, welche Broadcast-Meldung an ihn gesandt wird und darauf antworten. Da die Broadcast-Meldung die MAC Adresse des Absenders enthalten kann, kann der Empfänger die Antwort direkt dem Absender schicken. Die Antwort kann auch die MAC Adresse ihres Absenders enthalten (die MAC Adresse des beabsichtigen Empfängers der Broadcast-Meldung). Somit, nach dem ersten Meldungsaustausch kennen beide Parteien die Adresse der anderen und können Meldungen direkt an einander senden.
  • Das Protokoll kann mit Software im Endgerät 11 und in der mit gängigen kryptographischen Bibliotheken implementierten Smartcard 100 implementiert werden. Auf Seite des Endgerätes ist als Beispiel die ABA JCE Bibliothek zu nennen, welche eine reine JAVA Implementierung der von Sun Microsystems Inc definierten JCE (Java Cryptography Extension) Schnittstelle ist. Auf Seite der Smartcard ist als Beispiel eine Implementierung der Java Card Schnittstelle zu nennen.
  • Zufallszahlerzeugung
  • Sowohl die Smartcard 100 wie auch das Zahlungsendgerät 11 müssen ungebrauchte Zufallszahlen erzeugen. Diese Zahlen sollten vom Pseudo-Zufallszahlerzeuger (Pseudo-Random Number Generator, PRNG), erhältlich in der kryptographischen Bibliothek, erzeugt werden. Dieser PRNG wird durch die SecureRandom-Klasse dargestellt, welche Teil der JCE Schnittstelle ist. Da die Sicherheit des Verfahrens von der Qualität der Zufallszahl abhängig ist, muss das Seeding des PNGs vorsichtig gelöst werden.
  • Das Seeding des PRNGs kann ein Problem auf der Smartcard darstellen, da Multithreading auf den meisten Karten nicht erlaubt ist (d.h. Self-Seeding kann nicht gebraucht werden) und das Einfangen von zufälligen Ereignissen scheint auch nicht einfach zu sein. Eine Lösung wäre es, dass die Mobilvorrichtung das Seeding vielleicht unter Verwendung von durch den Benutzer erzeugten zufälligen Ereignissen kreiert.
  • Wahl des Schemas für asymmetrischen Schlüssel
  • Diese Wahl wird von der Anzahl der von der Smartcard durchgeführten öffentlichen und privaten Schlüssel Operationen bestimmt. Die Smartcard 100 führt 1 Verschlüsselung mit öffentlichem Schlüssel, 3 Digitalsignaturüberprüfungen, und 2 Digitalsignaturerzeugungen durch. Dies bedeutet 4 Operationen mit öffentlichem Schlüssel und 2 mit privatem Schlüssel. Demzufolge schlagen wir ein Schema vor, in welchem die Operationen mit öffentlichem Schlüssel weniger Berechnungen als mit privatem Schlüssel erfordern. Ein solches Schema ist RSA, das sowohl für Verschlüsselung wie auch für Digitalsignierung verwendet werden kann und welches in der kryptographischen Bibliothek erhältlich ist. Für die Digitalsignierung schlagen wir vor, MD5 mit RSA zu verwenden, welches die zu signierenden Daten verheimlicht.
  • Wahl des Verschlüsselungsalgorithmus mit symmetrischem Schlüssel
  • Das Protokoll verwendet Verschlüsselung mit symmetrischem Schlüssel, um die Zahlungsinformation vor Abhörern zu schützen. Jede Art von Blockverschlüsselungsalgorithmen kann dafür gebraucht werden. Wir schlagen vor, IDEA im CBC-Modus zu verwenden.
  • Wir werden nun ein Beispiel vom Pseudo-Code beschreiben, der von den Berechnungsmitteln in der Smartcard 100 und vom Zahlungsendgerät 11 durchgeführt werden kann, um dieses Zahlungsprotokoll durchzuführen. Der Fachmann wird in der Lage sein, in der Smartcard und im Endgerät 11 die nötigen Module zu schreiben, die diesen Pseudo-Codes entsprechen.
  • Von der Smartcard 100 durchgeführter Pseudo-Code
  • OneTime Setup: Initialisierung vom PRNG mit einem echt zufälligen Seed.
    • 1. Endgerät-Identifikation und Transaktions-Identifikation auf der Tastatur 103 der Mobilvorrichtung eingeben: T, T-id
    • 2. Nächste Zufallszahl vom PRNG holen: rC
    • 3. Broadcast T, T-i d, rC
    • 4. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Meldung eintrifft: M2
    • 5. Wenn M2 = cert, r, sig (M2 hat das richtige Format), dann GOTO Schritt 6, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M2 mit dem erwarteten Format eintrifft. Falls ein Timeout vor Erhalt von M2 eintritt, Ausnahme auslösen und stoppen.
    • 6. Wenn cert das Zertifikat von T ist und korrekt ist, dann GOTO Schritt 7, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M2 mit einem korrekten Zertifikat eintrifft. Falls ein Timeout vor Erhalt von M2 eintritt, Ausnahme auslösen und stoppen.
    • 7. Wenn sig = SigT(rT, rC, T, T-id), dann rüber zu Schritt 8, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M2 mit einer korrekten Signatur eintrifft. Falls ein Timeout vor Erhalt von M2 eintritt, Ausnahme auslösen und stoppen.
    • 8. Nächste Zufallszahl vom PRNG holen: k
    • 9. Öffentlichen Schlüssel aus cert extrahieren: KT
    • 10. Verschlüsselung k mit KT: {k}KT
    • 11 . Signieren von rC, r, T, T-i d, k : SigU(rC, rT, T, T-id, k)
    • 12 . Senden von certU, {k}KT, SigU(rC, rT, T, T-id, k) an den Absender von M2
    • 13. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Meldung eintrifft: M4
    • 14. Versuche, M4 mit k zu entschlüsseln: P4
    • 15. wenn P4 = T, T-info, dann GOTO zu Schritt 16, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M4 mit dem erwarteten Format eintrifft. Falls ein Timeout vor Erhalt von M4 eintritt, Ausnahme auslösen und stoppen.
    • 16. Anzeige von T, T-info auf der Anzeige 102 der Mobilvorrichtung.
    • 17. Warten, bis der Benutzer 1 auf der Tastatur 103 antwortet: resp
    • 18. Wenn resp = yes, dann GOTO zu Schritt 19, ELSE GOTO zu Schritt 25
    • 19. Signieren von U, T, T-info, P-info: SigU(U, T, T-info, P-info)
    • 20. Verschlüsselung P5 = U, T, T-info, P-info, SigU(U, T, T-info, P-info) mit k
    • 21. Senden von {U, T, T-info, P-info, SigU(U, T, T-info, P-info)}k an den Absender von M4
    • 22. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Meldung eintrifft: M6
    • 23. Versuche, M6 mit k zu entschlüsseln: P6
    • 24. Wenn P6 = SigT(h(P5)) , dann P6 speichern und GOTO Schritt 25, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M6 mit dem erwarteten Format eintrifft. Falls ein Timeout vor Erhalt von M6 eintritt, Ausnahme auslösen und stoppen.
    • 25. Ende vom Protokoll
  • Von dem Zahlungsendgerät 11 durchgeführter Pseudo-Code
  • OneTime Setup: Initialisierung vom PRNG mit einem echt zufälligen Seed.
    • 1. Anzeigen der Endgerätidentifizierung und der Transkationsinformation auf der Anzeige 110
    • 2. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Broadcast-Meldung eintrifft: M1
    • 3. Wenn M1 = T, T-id, r, wo T die Endgerätidentifizierung und T-id die aktuelle Transaktionsidentifikation ist, dann GOTO Schritt 4, ELSE GOTO Schritt 2
    • 4. Nächste Zufallszahl vom PRNG holen: rT
    • 5. Signieren von rT, rC, T, T-id : SigT(rT, r, T, T-id)
    • 6. Senden von certT, rT, SigT (rT, rC, T, T-id) an den Absender von M1
    • 7. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Meldung eintrifft: M3
    • 8. Wenn M3 = cert, C, sig (M3 hat das richtige Format), dann GOTO Schritt 9, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M3 mit dem erwarteten Format eintrifft. Falls ein Timeout vor Erhalt von M3 eintritt, Ausnahme auslösen und stoppen.
    • 9. Wenn cert korrekt ist, dann GOTO Schritt 10, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M3 mit dem korrekten Zertifikat eintrifft. Falls ein Timeout vor Erhalt von M3 eintritt, Ausnahme auslösen und stoppen.
    • 10. Entschlüsseln von C mit dem privaten Schlüssel des Zahlungsendgerätes 11: k
    • 11. Wenn sig = SigU(r, rT, T, T-i d, k), dann GOTO Schritt 12, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M3 mit der korrekten Signatur eintrifft. Falls ein Timeout vor Erhalt von M3 eintritt, Ausnahme auslösen und stoppen.
    • 12. Verschlüsseln der Endgerätidentifizierung und der Transaktionsinformation mit k: {T, T-info}k
    • 13. Senden von {T, T-info}k an den Absender M3
    • 14. Auf der drahtlosen Schnittstelle 101 zuhören bis eine Meldung eintrifft: M5
    • 15. Versuche, M5 mit k zu entschlüsseln: P5
    • 16. Wenn P5 = U, T, T-info, P-info, sig, dann GOTO Schritt 17, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M5 mit dem erwarteten Format eintrifft. Falls ein Timeout vor Erhalt von M5 eintritt, Ausnahme auslösen und stoppen.
    • 18. Wenn sig = SigU(U, T, T-info, P-info), dann GOTO Schritt 19, ELSE weiter auf die drahtlose Schnittstelle zuhören, bis eine Meldung M5 mit der korrekten Signatur eintrifft. Falls ein Timeout vor Erhalt von M5 eintritt, Ausnahme auslösen und stoppen.
    • 19. Solvenz des Benutzers überprüfen, indem wenn nötig den Verrechnungsserver 7 kontaktiert wird.
    • 20. Berechne den Hash-Wert von P5 und signiere ihn: SigT(h(P5))
    • 21. Verschlüsselung der Signatur mit k: {SigT(h(P5) )}k
    • 22. Senden von {SigT(h(P5))}k an den Absender von M5
    • 23. Ende vom Protokoll Offline: Senden von certU, U, T, T-info, P-info, SigU(U, T, T-info, P-info) an den Verrechnungsserver.
  • In der beschriebenen Ausführungsform wird ein authentischer und vertraulicher Kanal zwischen der Mobilvorrichtung des Benutzers und dem Zahlungsendgerät aufgebaut, indem zuerst der Endgerätname und eine neue einzigartige Transaktionsidentifikation auf der Anzeige des Zahlungsendgerätes angezeigt werden und dann der Endgerätname und die Transaktionsidentifikation auf der Tastatur der Mobilvorrichtung eingegeben werden. Der Fachmann wird jedoch verstehen, dass wenn der Benutzer Zugang zur Tastatur oder zu anderen Eingabemitteln des Zahlungsendgerätes hat, ein authentischer und vertraulicher Kanal aufgebaut werden kann, indem die einzigartige Transaktionsidentifikation auf der Anzeige der Mobilvorrichtung angezeigt wird und dann die Mobil-Identifizierung und Transaktionsidentifikation in das Zahlungsendgerät manuell eingegeben werden.
  • Obwohl die anhand der Zeichnungen beschriebenen Ausführungsformen der Erfindung Vorrichtungen wie Endgeräte, Smartcards und Mobilvorrichtungen, sowie in oder von solchen Vorrichtungen durchgeführte Verfahren, enthalten, erstreckt sich die Erfindung auch auf Computerprogramme, insbesondere Computerprogramme auf oder in einem Datenträger, welche geeignet sind, die Erfindung in die Praxis umzusetzen. Das Programm ist möglich in der Form von SourceCode, ObjectCode, Zwischencode zwischen Source- und ObjectCode wie in teilweise kompilierter Form oder in jeglicher anderer geeigneten Form für die Verwendung in der Implementierung der Verfahren und Protokollen gemäss der Erfindung. Der Träger kann jede Einheit oder Vorrichtung sein, die das Programm tragen kann.
  • Beispielsweise kann der Träger ein Speichermedium umfassen, wie ROM, z.B. CD-ROM, oder Halbleiter ROM, z.B. EEPROM, oder ein magnetisches oder optisches Aufnahmemedium, z.B. Diskette, Festplatte oder Smartcard. Ferner kann der Träger ein übertragbarer Träger sein, z.B. ein elektrisches oder optisches Signal, das über elektrische oder optische Kabel oder über Funk oder andere Mittel übermittelt werden kann.
  • Wenn das Programm in einem Signal verkörpert wird, das über Kabel oder andere Vorrichtungen oder Mittel übertragen werden kann, kann der Träger aus einem solchen Kabel oder anderer Vorrichtung oder anderen Mitteln bestehen. Als Alternative kann der Träger ein integrierter Schaltkreis sein, in welchem das Programm eingebettet ist, beispielsweise ein Speicher im Endgerät 11, in der Mobilvorrichtung oder in der Smartcard 100.

Claims (19)

  1. Verfahren zur Übertragung einer Zahlungsinformation zwischen einer mobilen Vorrichtung und einem Zahlungsendgerät (11) über eine drahtlose Schnittstelle im Nahbereich (101), umfassend: – das Anzeigen einer Identifizierung auf der Anzeige (110) des besagten Zahlungsendgerätes (11), – das manuelle Eingeben besagter Identifizierung auf den Eingabemitteln (103) der besagten mobilen Vorrichtung, – das Verwenden besagter Identifizierung in einer ersten Meldung (M1), um einen authentischen und vertraulichen Kanal zwischen besagter mobilen Vorrichtung und besagtem Zahlungsendgerät (11) aufzubauen, wobei besagter Kanal dadurch verwendet wird, um vertrauliche Zahlungsinformation zwischen besagtem Zahlungsendgerät und besagter mobilen Vorrichtung auszutauschen.
  2. Verfahren gemäss Anspruch 1, wobei besagte Identifizierung benutzt wird, um ein von besagtem Zahlungsendgerät später gesandtes elektronisches Zertifikat zu überprüfen.
  3. Verfahren gemäss dem vorhergehenden Anspruch, worin besagte Identifizierung den Namen des Zahlungsendgerätes und/oder eine Transaktionsidentifikation umfasst.
  4. Verfahren gemäss dem vorhergehenden Anspruch, worin besagte Transaktionsidentifikation (T-id) im besagten Zahlungsendgerät (11) erzeugt wird, wobei besagte erste mit besagter Transaktionsidentifikation identifizierte Meldung eine erste Zufallszahl (rC) umfasst, wobei besagte erste Zufallszahl die Ungebrauchtheit in einem gegenseitigen Authentifizierungsaustausch zwischen besagter mobilen Vorrichtung und besagtem Zahlungsendgerät (11) gewährleistet, um einen authentifizierten symmetrischen Sitzungsschlüssel (k) auszutauschen, wobei besagter Schlüssel für die Verschlüsselung besagter Zahlungsinformation verwendet wird.
  5. Verfahren gemäss dem vorhergehenden Anspruch, ferner umfassend: – das Vorbereiten im besagten Zahlungsendgerät (11) einer zweiten Meldung (M2), welche die besagte Transaktionsidentifikation (T-id) und eine Endgerätzufallszahl (rT) beinhaltet, und das Signieren derselben mit dem privaten Schlüssel des Zahlungsendgerätes (SigT), – das Senden dieser Meldung an besagte mobile Vorrichtung über besagte drahtlose Schnittstelle im Nahbereich (101), – das Überprüfen in besagter mobilen Vorrichtung der besagten Transaktionsidentifikation (T-id) und der Signatur (SigT) des besagten Zahlungsendgerätes (11) mit besagter Identifizierung, – das Benutzen besagter Endgerätzufallszahl (rT) zur Überprüfung der Ungebrauchtheit von mindestens einer nachfolgenden Meldung aus besagter mobilen Vorrichtung an besagtes Zahlungsendgerät (11).
  6. Verfahren gemäss dem vorhergehenden Anspruch, worin besagte nachfolgende Meldung, die mit besagter Endgerätzufallszahl (rT) authentifiziert ist, den besagten symmetrischen Sitzungsschlüssel (k) umfasst.
  7. Verfahren gemäss einem der Ansprüche 5 oder 6, worin besagte von besagter Zahlungsvorrichtung gesandte Meldung ferner besagte erste in besagter mobilen Vorrichtung erzeugte Zufallszahl (rC) umfasst.
  8. Verfahren gemäss einem der vorhergehenden Ansprüche, ferner umfassend einen Schritt, während welchem der öffentliche Schlüssel des Benutzers mit einer Benutzerwiderrufsliste überprüft wird.
  9. Verfahren gemäss Anspruch 1, worin besagter authentischer und vertraulicher Kanal mit den folgenden Schritten aufgebaut wird: – das Erzeugen in besagter mobilen Vorrichtung eines ersten Zufallsworts (rC), – das Senden eines ersten Zufallsworts (rC) an besagtes Zahlungsendgerät, – das Erzeugen im besagten Zahlungsendgerät (11) eines zweiten Zufallsworts (rT), – das Erzeugen im besagten zweiten Zahlungsendgerät (11) einer ersten Signatur des besagten ersten Zufallsworts, des besagten zweiten Zufallsworts, der Identifikation besagtes zweiten Zahlungsendgerätes (T) und der Transaktionsidentifikation (T-id), – das Senden an besagte mobile Vorrichtung eines Zertifikats des besagten Endgerätes (certT), des besagten zweiten Zufallsworts (rT) und der besagten ersten Signatur, – das Erzeugen in besagter mobilen Vorrichtung eines Sitzungsschlüssels (k) und das Verschlüsseln desselben mit dem öffentlichen Schlüssel des besagten Endgerätes (kT), – das Erzeugen in besagter mobilen Vorrichtung einer zweiten Signatur des besagten ersten Zufallsworts (rC), des besagten zweiten Zufallsworts (rT), der Identifikation besagtes zweiten Zahlungsendgerätes (T), der Transaktionsidentifikation (T-id) und des besagten Sitzungsschlüssels (k), – das Senden des besagten verschlüsselten Sitzungsschlüssels, der zweiten Signatur und eines Benutzerzertifikats (certU) an besagtes Endgerät, – das Entschlüsseln besagtes Sitzungsschlüssels im besagten Zahlungsendgerät (11), – das Überprüfen im besagten Zahlungsendgerät des besagten Zertifikats und der Signatur des Benutzers, – wenn die Oberprüfungen erfolgreich sind, das Verwenden des besagten Sitzungsschlüssels (k) als geteilter symmetrischer Sitzungsschlüssel, um spätere Meldungen zwischen besagter mobilen Vorrichtung und besagtem Zahlungsendgerät (11) zu sichern.
  10. Smartcard (100) beinhaltend ein Computerprogramm, das Instruktionen enthält, welche von Verarbeitungsmitteln in besagter Smartcard ausgeführt werden, um die Smartcard dazu zu veranlassen, ein Verfahren durchzuführen, das mindestens die folgenden Schritte umfasst: – abwarten, bis eine Identifikation (beispielsweise T, T-id) vom Zahlungsendgerät angezeigt wird und danach manuell in die mobile Vorrichtung, welche die Smartcard enthält, eingegeben und an die Smartcard geleitet wird, – das Vorbereiten einer Instruktion, um eine erste die besagte Identifikation enthaltende Meldung (M1) über eine drahtlose Schnittstelle im Nahbereich (101) zu senden, – das Abwarten einer zweiten über besagte drahtlose Schnittstelle empfangene Meldung (M2), – überprüfen, ob ein in besagter zweiten Meldung enthaltenes Zertifikat (certT) besagte Identifikation enthält.
  11. Smartcard gemäss dem vorhergehenden Anspruch, worin besagte zweite Meldung (M2) ferner eine erste Zufallszahl (rC) umfasst, welche für die Überprüfung der Ungebrauchtheit von nachfolgend erhaltenen Meldungen verwendet wird.
  12. Smartcard gemäss dem vorhergehenden Anspruch, worin besagtes Verfahren ferner umfasst: – das Erzeugen eines zufälligen Sitzungsschlüssels (k), – das Verschlüsseln besagtes Sitzungsschlüssels mit dem öffentlichen Schlüssel des Zahlungsendgerätes, welcher im besagten Zahlungsendgerätzertifikat enthalten ist, – das Vorbereiten einer Instruktion, um eine dritte Meldung (M3), die besagten verschlüsselten Sitzungsschlüssel enthält, über besagte drahtlose Schnittstelle im Nahbereich zu senden.
  13. Smartcard gemäss dem vorhergehenden Anspruch, wobei besagte dritte Meldung ferner ein Zertifikat (certU) des Benutzers besagter Smartcard enthält.
  14. Smartcard gemäss dem vorhergehenden Anspruch, wobei besagte dritte Meldung (M3) ferner die Signatur besagter Antwort umfasst.
  15. Smartcard gemäss einem der Ansprüche 10 bis 14, ferner einen GSM-Teil umfassend.
  16. Computerprogramm auf einem Datenträger und der Instruktionen enthält, welche durch einen Computer ausgeführt werden können, um ein Endgerät (11) einschliesslich einer drahtlosen Schnittstelle im Nahbereich (101) dazu zu veranlassen, ein Verfahren durchzuführen, welches die folgenden Schritte umfasst: – das Erzeugen einer Transaktionsidentifikation (T-id), – das Anzeigen besagter Transaktionsidentifikation, – das Abwarten einer ersten Meldung (M1), welche besagte Transaktionsidentifikation (T-id) enthält, über besagte drahtlose Schnittstelle im Nahbereich, – das Senden einer zweiten Meldung (M2), welche ein Zertifikat besagtes Endgerätes an den Sender besagter Antwort (M1) enthält.
  17. Computerprogramm auf einem Datenträger gemäss dem vorhergehenden Anspruch, wobei besagtes Verfahren ferner umfasst: – das Extrahieren einer ersten Zufallszahl (rC) aus besagter ersten Meldung (M1), – das Verwenden besagter ersten Zufallszahl in einem gegenseitigen Authentifizierungsaustausch über besagte drahtlose Schnittstelle im Nahbereich, – das Extrahieren eines authentifizierten symmetrischen Sitzungsschlüssels (k) aus einer nachfolgenden Meldung, wobei besagter Schlüssel für das Verschlüsseln von Zahlungsbefehlen, die über besagte drahtlose Schnittstelle im Nahbereich ausgetauscht werden, verwendet wird.
  18. Computerprogramm auf einem Datenträger gemäss dem vorhergehenden Anspruch, worin besagte zweite Meldung (M2) ferner eine zweite Zufallszahl (rT), besagte erste Zufallszahl (rC), besagte zweite Zufallszahl (rT) und besagte Transaktionsidentifikation (T-id) umfasst, wobei besagte zweite Meldung signiert wird.
  19. Computerprogramm auf einem Datenträger gemäss einem der Ansprüche 16 bis 18, worin besagtes Verfahren ferner umfasst: – das Senden von mit besagtem Sender ausgetauschter Zahlungsinformation an ein Berechnungszentrum (7).
DE60104411T 2000-04-28 2001-04-23 Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung Expired - Lifetime DE60104411T2 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP00109220 2000-04-28
EP00109220 2000-04-28
PCT/EP2001/004579 WO2001084763A2 (en) 2000-04-28 2001-04-23 Method for transmitting payment information between a terminal and a third equipment

Publications (2)

Publication Number Publication Date
DE60104411D1 DE60104411D1 (de) 2004-08-26
DE60104411T2 true DE60104411T2 (de) 2005-09-22

Family

ID=8168586

Family Applications (2)

Application Number Title Priority Date Filing Date
DE60044586T Expired - Lifetime DE60044586D1 (de) 2000-04-28 2000-09-18 Verfahren zur sicherung der kommunikation zwischen einem endgerät und einer zusätzlichen benutzervorrichtung
DE60104411T Expired - Lifetime DE60104411T2 (de) 2000-04-28 2001-04-23 Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung

Family Applications Before (1)

Application Number Title Priority Date Filing Date
DE60044586T Expired - Lifetime DE60044586D1 (de) 2000-04-28 2000-09-18 Verfahren zur sicherung der kommunikation zwischen einem endgerät und einer zusätzlichen benutzervorrichtung

Country Status (6)

Country Link
US (1) US7409552B2 (de)
EP (2) EP1277299B1 (de)
AT (2) ATE472208T1 (de)
AU (2) AU2000275203A1 (de)
DE (2) DE60044586D1 (de)
WO (2) WO2001084761A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006028938B3 (de) * 2006-06-23 2008-02-07 Siemens Ag Verfahren zur Übertragung von Daten

Families Citing this family (96)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6816968B1 (en) * 1998-07-10 2004-11-09 Silverbrook Research Pty Ltd Consumable authentication protocol and system
JP2003534585A (ja) 2000-03-15 2003-11-18 マスターカード インターナシヨナル インコーポレーテツド コンピュータネットワークを越える安全な支払い方法およびそのシステム
US7409543B1 (en) * 2000-03-30 2008-08-05 Digitalpersona, Inc. Method and apparatus for using a third party authentication server
US6824064B2 (en) * 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
US7975139B2 (en) * 2001-05-01 2011-07-05 Vasco Data Security, Inc. Use and generation of a session key in a secure socket layer connection
US7444513B2 (en) 2001-05-14 2008-10-28 Nokia Corporiation Authentication in data communication
US20040218762A1 (en) * 2003-04-29 2004-11-04 Eric Le Saint Universal secure messaging for cryptographic modules
US8209753B2 (en) * 2001-06-15 2012-06-26 Activcard, Inc. Universal secure messaging for remote security tokens
US7571257B2 (en) 2001-07-31 2009-08-04 Guthery Scott B Communications network with smart card
US7362869B2 (en) 2001-12-10 2008-04-22 Cryptomathic A/S Method of distributing a public key
AU2003211960B2 (en) * 2002-02-13 2009-12-10 Passlogy Co., Ltd. User authentication method and user authentication system
AU2003226976A1 (en) * 2002-03-08 2003-09-22 Sony Ericsson Mobile Communications Ab Security protection for data communication
JP2005521332A (ja) * 2002-03-19 2005-07-14 マスターカード インターナシヨナル インコーポレーテツド 近接装置を使用してトランザクションを実行する方法およびシステム
DE10216601A1 (de) * 2002-04-15 2003-10-30 Giesecke & Devrient Gmbh Programmsicherungsverfahren
EP1397014A1 (de) * 2002-09-04 2004-03-10 SCHLUMBERGER Systèmes WIM (WAP Identification module) Anwendungsprozeduren für Beförderung das secure socket layer protocol (SSL)
US7574731B2 (en) * 2002-10-08 2009-08-11 Koolspan, Inc. Self-managed network access using localized access management
US7325134B2 (en) 2002-10-08 2008-01-29 Koolspan, Inc. Localized network authentication and security using tamper-resistant keys
US7607015B2 (en) * 2002-10-08 2009-10-20 Koolspan, Inc. Shared network access using different access keys
US7853788B2 (en) 2002-10-08 2010-12-14 Koolspan, Inc. Localized network authentication and security using tamper-resistant keys
US7895443B2 (en) * 2002-11-05 2011-02-22 Safenet, Inc. Secure authentication using hardware token and computer fingerprint
ATE383613T1 (de) * 2002-11-08 2008-01-15 Nokia Corp Software-integritätstest bei einem mobiltelefon
US20040156367A1 (en) * 2003-02-11 2004-08-12 Magis Networks, Inc. Hierarchically distributed scheduling apparatus and method
WO2004092864A2 (en) * 2003-04-14 2004-10-28 Matsushita Electric Industrial Co., Ltd. Client-server authentication using the challenge-response principle
US20050021940A1 (en) * 2003-06-13 2005-01-27 Kenneth Ma Authentication mechanism for wireless communication devices
US8270609B2 (en) * 2003-06-13 2012-09-18 Broadcom Corporation Mechanism for secure transmission of signals in wireless communication devices
US7934005B2 (en) * 2003-09-08 2011-04-26 Koolspan, Inc. Subnet box
US7725933B2 (en) * 2003-10-07 2010-05-25 Koolspan, Inc. Automatic hardware-enabled virtual private network system
WO2005057507A2 (en) * 2003-12-02 2005-06-23 Koolspan, Inc Remote secure authorization
KR100661313B1 (ko) * 2003-12-03 2006-12-27 한국전자통신연구원 평생 번호를 사용한 이동성 제공이 가능한 ｓｉｐ 기반의멀티미디어 통신 시스템 및 이동성 제공 방법
US7409715B2 (en) * 2003-12-10 2008-08-05 Alcatel Lucent Mechanism for detection of attacks based on impersonation in a wireless network
US8060745B2 (en) * 2003-12-16 2011-11-15 Seiko Epson Corporation Security for wireless transmission
US7549048B2 (en) * 2004-03-19 2009-06-16 Microsoft Corporation Efficient and secure authentication of computing systems
US7853793B2 (en) * 2004-05-03 2010-12-14 Piotr Cofta Trusted signature with key access permissions
US8352380B2 (en) * 2004-05-19 2013-01-08 France Telecom Method and system for generating a list signature
EP1622333A1 (de) * 2004-07-29 2006-02-01 Sun Microsystems France S.A. Methode und Gerät zur einfachen und schnellen Authentifizierung
WO2006027430A1 (fr) * 2004-08-16 2006-03-16 France Telecom Procede d’authentification entre entites communiquant entre elles au travers d’un reseau de telecommunications
JP4736398B2 (ja) * 2004-10-22 2011-07-27 日本電気株式会社 近接する端末間における認証方法、秘匿情報の配送方法、装置、システム、及び、プログラム
US8117452B2 (en) * 2004-11-03 2012-02-14 Cisco Technology, Inc. System and method for establishing a secure association between a dedicated appliance and a computing platform
JP2006155045A (ja) 2004-11-26 2006-06-15 Sony Corp 電子価値情報伝送システム及び電子価値情報伝送方法
JPWO2006082907A1 (ja) * 2005-02-04 2008-06-26 ソフトバンクＢｂ株式会社 電子マネー決済システムおよび電子マネー決済方法
CN101120351B (zh) * 2005-02-18 2010-10-06 Rsa安全公司 派生种子的分发方法
US8316416B2 (en) 2005-04-04 2012-11-20 Research In Motion Limited Securely using a display to exchange information
US9143323B2 (en) * 2005-04-04 2015-09-22 Blackberry Limited Securing a link between two devices
US7356539B2 (en) 2005-04-04 2008-04-08 Research In Motion Limited Policy proxy
DE602005000716T2 (de) * 2005-04-04 2007-12-06 Research In Motion Ltd., Waterloo Sicherung einer Kommunikationsverbindung zwischen Geräten.
US7827376B2 (en) * 2005-06-27 2010-11-02 Lenovo (Singapore) Pte. Ltd. System and method for protecting hidden protected area of HDD during operation
US7836306B2 (en) * 2005-06-29 2010-11-16 Microsoft Corporation Establishing secure mutual trust using an insecure password
EP1752937A1 (de) * 2005-07-29 2007-02-14 Research In Motion Limited System und Verfahren zur verschlüsselten Eingabe einer persönlichen Identifizierungsnummer für eine Chipkarte
GB2435951A (en) * 2006-02-23 2007-09-12 Barclays Bank Plc System for PIN servicing
US8670566B2 (en) * 2006-05-12 2014-03-11 Blackberry Limited System and method for exchanging encryption keys between a mobile device and a peripheral output device
US7958368B2 (en) * 2006-07-14 2011-06-07 Microsoft Corporation Password-authenticated groups
US20080046739A1 (en) * 2006-08-16 2008-02-21 Research In Motion Limited Hash of a Certificate Imported from a Smart Card
US8341411B2 (en) 2006-08-16 2012-12-25 Research In Motion Limited Enabling use of a certificate stored in a smart card
FR2910666B1 (fr) * 2006-12-26 2013-02-08 Oberthur Card Syst Sa Dispositif electronique portable et procede de securisation d'un tel dispositif
US8307411B2 (en) * 2007-02-09 2012-11-06 Microsoft Corporation Generic framework for EAP
KR100858146B1 (ko) 2007-02-21 2008-09-10 주식회사 케이티프리텔 이동통신 단말기 및 가입자 식별 모듈을 이용한 개인 인증방법 및 장치
US20100293379A1 (en) * 2007-05-31 2010-11-18 Beijing Transpacific Ip Technology Development Ltd method for secure data transmission in wireless sensor network
US7907735B2 (en) 2007-06-15 2011-03-15 Koolspan, Inc. System and method of creating and sending broadcast and multicast data
US8348155B2 (en) * 2007-09-21 2013-01-08 Telefonaktiebolaget L M Ericsson (Publ) All in one card
US8001381B2 (en) 2008-02-26 2011-08-16 Motorola Solutions, Inc. Method and system for mutual authentication of nodes in a wireless communication network
CA2630388A1 (en) * 2008-05-05 2009-11-05 Nima Sharifmehr Apparatus and method to prevent man in the middle attack
EP2160030B1 (de) * 2008-08-27 2016-12-21 Irdeto B.V. Herstellerneutrales System mit bedingtem Zugang
ES2365887B1 (es) * 2009-05-05 2012-09-03 Scytl Secure Electronic Voting S.A. Metodo de verificacion de procesos de descifrado
DE102009027681A1 (de) * 2009-07-14 2011-01-20 Bundesdruckerei Gmbh Verfahren und Lesen von Attributen aus einem ID-Token
US8819792B2 (en) 2010-04-29 2014-08-26 Blackberry Limited Assignment and distribution of access credentials to mobile communication devices
EP2589001A4 (de) * 2010-06-29 2014-01-22 Ericsson Telefon Ab L M Verfahren, server, händlervorrichtung, computerprogramme und computerprogrammprodukte zur herstellung einer kommunikation
US8644515B2 (en) * 2010-08-11 2014-02-04 Texas Instruments Incorporated Display authenticated security association
DE102010035098A1 (de) * 2010-08-23 2012-02-23 Giesecke & Devrient Gmbh Verfahren zum Authentisieren eines portablen Datenträgers
US8839357B2 (en) * 2010-12-22 2014-09-16 Canon U.S.A., Inc. Method, system, and computer-readable storage medium for authenticating a computing device
US8690051B1 (en) 2011-04-07 2014-04-08 Wells Fargo Bank, N.A. System and method for receiving ATM deposits
US9292840B1 (en) * 2011-04-07 2016-03-22 Wells Fargo Bank, N.A. ATM customer messaging systems and methods
US9589256B1 (en) 2011-04-07 2017-03-07 Wells Fargo Bank, N.A. Smart chaining
US20140173287A1 (en) * 2011-07-11 2014-06-19 Takeshi Mizunuma Identifier management method and system
FI20115945A0 (fi) * 2011-09-28 2011-09-28 Onsun Oy Maksujärjestelmä
US10263782B2 (en) * 2011-10-12 2019-04-16 Goldkey Corporation Soft-token authentication system
EP2611070A1 (de) * 2011-12-28 2013-07-03 Gemalto SA Verfahren zur Erstellung einer sicheren Kartenhistorie und -überprüfung zur Eigentumsübergabe
US9642005B2 (en) * 2012-05-21 2017-05-02 Nexiden, Inc. Secure authentication of a user using a mobile device
US20130311382A1 (en) 2012-05-21 2013-11-21 Klaus S. Fosmark Obtaining information for a payment transaction
JP2014048414A (ja) * 2012-08-30 2014-03-17 Sony Corp 情報処理装置、情報処理システム、情報処理方法及びプログラム
US9398448B2 (en) * 2012-12-14 2016-07-19 Intel Corporation Enhanced wireless communication security
CN103208151B (zh) * 2013-04-03 2016-08-03 天地融科技股份有限公司 处理操作请求的方法及系统
JP6187251B2 (ja) * 2013-12-27 2017-08-30 富士通株式会社 データ通信方法、およびデータ通信装置
CN103987037A (zh) * 2014-05-28 2014-08-13 大唐移动通信设备有限公司 一种保密通信实现方法及装置
FR3026875B1 (fr) * 2014-10-01 2016-11-25 Avencis Procedes de configuration d'un peripherique de type terminal connecte a un reseau afin de permettre une authentification forte d'un utilisateur
US9609512B2 (en) * 2014-10-09 2017-03-28 Userstar Information System Co., Ltd. Wireless authentication system and wireless authentication method
US9317845B1 (en) 2014-12-23 2016-04-19 Mastercard International Incorporated Flexible electronic payment transaction process
EP3048776B2 (de) * 2015-01-22 2021-03-17 Nxp B.V. Verfahren zur Verwaltung von Inhalt, Computerprogrammprodukte und sicheren Elementen
DE102015006751A1 (de) * 2015-05-26 2016-12-01 Giesecke & Devrient Gmbh Verfahren zur Bereitstellung eines persönlichen Identifikationscodes eines Sicherheitsmoduls
DE102015225792B3 (de) * 2015-12-17 2017-04-13 Volkswagen Aktiengesellschaft Verfahren und ein System zur geschützten Kommunikation zwischen einer mit einem Smartphone gekoppelten mobilen Einheit und einem Server
US10084797B2 (en) * 2016-10-03 2018-09-25 Extreme Networks, Inc. Enhanced access security gateway
US10313134B2 (en) * 2016-10-27 2019-06-04 Denso Corporation System and method for authenticating and authorizing devices
CN106533669B (zh) * 2016-11-15 2018-07-13 百度在线网络技术（北京）有限公司 设备识别的方法、装置和系统
US11010482B2 (en) 2018-04-10 2021-05-18 Visa International Service Association System and method for secure device connection
KR102009863B1 (ko) * 2018-12-05 2019-08-12 주식회사 후본 보안카드와 모바일 단말을 이용한 출입 보안 시스템 및 그 보안 방법
FR3092414B1 (fr) * 2019-02-01 2021-01-08 Idemia Identity & Security France Procédé d’authentification, serveur et dispositif électronique d’identité
WO2020228976A1 (en) * 2019-05-10 2020-11-19 NEC Laboratories Europe GmbH Method and system for device identification and monitoring

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4637051A (en) * 1983-07-18 1987-01-13 Pitney Bowes Inc. System having a character generator for printing encrypted messages
US5001752A (en) * 1989-10-13 1991-03-19 Fischer Addison M Public/key date-time notary facility
PL178218B1 (pl) * 1994-10-27 2000-03-31 Ibm Sposób i urządzenie do bezpiecznej identyfikacji ruchomego użytkownika w sieci komunikacyjnej
US6000607A (en) * 1995-12-08 1999-12-14 Hitachi, Ltd. IC card reader/writer and method of operation thereof
FI980427A (fi) * 1998-02-25 1999-08-26 Ericsson Telefon Ab L M Menetelmä, järjestely ja laite todentamiseen
US6173400B1 (en) * 1998-07-31 2001-01-09 Sun Microsystems, Inc. Methods and systems for establishing a shared secret using an authentication token

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102006028938B3 (de) * 2006-06-23 2008-02-07 Siemens Ag Verfahren zur Übertragung von Daten

Also Published As

Publication number Publication date
ATE271733T1 (de) 2004-08-15
US20030041244A1 (en) 2003-02-27
EP1277301A2 (de) 2003-01-22
ATE472208T1 (de) 2010-07-15
EP1277299A1 (de) 2003-01-22
AU2000275203A1 (en) 2001-11-12
DE60104411D1 (de) 2004-08-26
DE60044586D1 (de) 2010-08-05
EP1277301B1 (de) 2004-07-21
WO2001084763A3 (en) 2002-03-28
WO2001084763A2 (en) 2001-11-08
EP1277299B1 (de) 2010-06-23
WO2001084761A1 (en) 2001-11-08
US7409552B2 (en) 2008-08-05
AU6589701A (en) 2001-11-12

Similar Documents

Publication Publication Date Title
DE60104411T2 (de) Verfahren zur übertragung einer zahlungsinformation zwischen einem endgerät und einer dritten vorrichtung
US10333721B2 (en) Secure information transmitting system and method for personal identity authentication
EP1216587B1 (de) Verfahren, um die authentizität von durch eine zertifizierungsinstanz herausgegebenen elektronischen zertifikaten in einem mobilgerät zu verifizieren und entsprechendes identifizierungsmodul
DE69830902T2 (de) Zweiweg-authentifizierung-protokoll
DE60312911T2 (de) System für mobile Authentifizierung mit reduzierten Authentifizierungsverzögerung
DE60114895T2 (de) System und verfahren zum laden einer temporären infrastruktur mit öffentlichen schlüsseln aus einer zellularen telekommunikationsauthentifizierungs- und abrechnungsinfrastruktur
DE69838003T2 (de) Verfahren zum etablieren des vertrauenswürdigkeitgrades eines teilnehmers während einer kommunikationsverbindung
EP2962439B1 (de) Lesen eines attributs aus einem id-token
DE60209809T2 (de) Verfahren zur digitalen unterschrift
DE102019002731A1 (de) Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
EP1002302A2 (de) Verfahren zum sicheren umgang mit elektronischen zahlungsmitteln und zur sicheren abwicklung von geschäftlichen vorgängen sowie vorrichtung zur durchführung des verfahrens
WO2021170645A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP1142194A1 (de) Verfahren und vorrichtung zur ausführung einer digitalen signatur
DE10392788T5 (de) Nichtablehnung von Dienstvereinbarungen
EP1588295A2 (de) Verfahren zum erbringen von diensten in einem datenübertragungsnetz und zugehörige komponenten
DE60203041T2 (de) Verfahren und vorrichtung zum beglaubigen einer transaktion
WO2010089049A1 (de) Mobiles zahlungsverfahren und vorrichtungen
EP3641369B1 (de) Absicherung einer p2p-kommunikation
EP2381712B1 (de) Sicheres Auslesen von Daten aus einem Funkgerät mit festintegriertem TPM
EP1047028A1 (de) Kommunikationssytem und Verfahren zur effizienten Durchführung von elektronischen Transaktionen in mobilen Kommunikationsnetzen
EP1579396A1 (de) Verfahren und system zur daten bertragung
JP4148465B2 (ja) 電子価値流通システムおよび電子価値流通方法
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
CN114548980A (zh) 一种基于数字证书的双离线交易即时确认方法及系统

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8327 Change in the person/name/address of the patent owner

Owner name: SWISSCOM AG, BERN, CH