DE102013212646B4 - Elektronisches Transaktionsverfahren und Computersystem - Google Patents
Elektronisches Transaktionsverfahren und Computersystem Download PDFInfo
- Publication number
- DE102013212646B4 DE102013212646B4 DE102013212646.8A DE102013212646A DE102013212646B4 DE 102013212646 B4 DE102013212646 B4 DE 102013212646B4 DE 102013212646 A DE102013212646 A DE 102013212646A DE 102013212646 B4 DE102013212646 B4 DE 102013212646B4
- Authority
- DE
- Germany
- Prior art keywords
- computer system
- user
- token
- transaction
- request
- 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.)
- Active
Links
Images
Classifications
-
- 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/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
- G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
-
- 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
- G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
-
- 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/401—Transaction verification
- G06Q20/4014—Identity check for transactions
-
- G—PHYSICS
- G07—CHECKING-DEVICES
- G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
- G07C9/00—Individual registration on entry or exit
- G07C9/20—Individual registration on entry or exit involving the use of a pass
- G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
- G07C9/25—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition
- G07C9/257—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition electronically
Abstract
- Anzeige eines optisch lesbaren Musters auf einem Bildschirm (188) eines Terminals (186), wobei in dem optisch lesbaren Muster eine Information codiert ist, die zumindest eine logische Adresse eines Dienst-Computersystems (150) und Transaktionsdaten beinhaltet,
- Erfassung des Musters mithilfe eines optischen Sensors (190) des Nutzer-Computersystems und Decodierung des Musters durch das Nutzer-Computersystem,
- Übertragung einer Transaktionsanforderung (158) von dem Nutzer-Computersystem an die logische Adresse des Dienst-Computersystems über das Netzwerk, wobei die Transaktionsanforderung die Transaktionsdaten beinhaltet,
- Übertragung eines Request (166) von dem Dienst-Computersystem über das Nutzer-Computersystems (100) an ein ID-Provider-Computersystem (136), wobei die Übertragung über das Netzwerk erfolgt, wobei der Request eine Attributspezifikation der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute beinhaltet,
- Authentifizierung des Nutzers gegenüber dem ID-Token,
- Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk,
- unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers und des ID-Provider-Computersystems gegenüber dem ID-Token, Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider-Computersystem aus dem ID-Token über das Netzwerk mit Ende-zu-Ende-Verschlüsselung,
- Übertragung einer Response (174) von dem ID-Provider-Computersystem über das Nutzer-Computersystem an das Dienst-Computersystem, wobei die Übertragung der Response über das Netzwerk erfolgt, wobei die Response das oder die ausgelesenen Attribute beinhaltet, und wobei die Response von dem ID-Provider-Computersystem signiert ist,
- Durchführung der Transaktion mithilfe der Transaktionsdaten und des oder der Attribute durch das Dienst-Computersystem,
wobei die Transaktionsdaten einen Zahlungsbetrag beinhalten und wobei die Transaktion von dem Dienst-Computersystem initiiert wird, um eine finanzielle Transaktion in Höhe des Zahlungsbetrags durchzuführen,
wobei es sich bei dem Terminal um einen Verkaufsautomat handelt, wobei es sich bei dem Zahlungsbetrag um einen Verkaufspreis für ein von dem Verkaufsautomat abgebbares Produkt handelt, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um ein Konto des Benutzers in Höhe des Zahlungsbetrags zu belasten, woraufhin das Dienst-Computersystem ein Bestätigungssignal an den Verkaufsautomat überträgt, und der Verkaufsautomat aufgrund des Empfangs des Bestätigungssignals das Produkt abgibt.
Description
- Die Erfindung betrifft ein elektronisches Transaktionsverfahren sowie ein Computersystem.
- Für den elektronischen Handel, das heißt den sogenannten eCommerce, sind verschiedene Transaktionsverfahren bekannt. Dazu gehören übliche Zahlungsverfahren wie zum Beispiel eine papiergebundene Überweisung oder die Zahlung per Nachnahme sowie elektronische Zahlungsverfahren, wie zum Beispiel Kreditkartenzahlung, die Zahlung per Online-Banking, Inkasso/Billing-Systeme, Factory-Systeme, elektronische Lastschrift, Prepaidverfahren, Zahlung per Telefonrechnung sowie Handy-Payment-Systeme. Solche Zahlungsverfahren werden zum Teil auch für eGovernment Anwendungen eingesetzt.
- Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein verbessertes elektronisches Transaktionsverfahren sowie ein entsprechendes Computersystem zu schaffen.
- Die der Erfindung zugrunde liegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche erfüllt. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
- Aus dem Stand der Technik bekannt sind ein informationsverarbeitendes Gerät mit optischem Datenleser, Server, und ein Verfahren zum elektronischen Handel (
US 2003/0120555 A1 - Die technische Richtlinie TR-03110, Ver. 2.05, des Bundesamts für Sicherheit in der Informationstechnik beschreibt erweiterte Sicherheitsmechanismen für maschinenlesbare Reisedokumente.
- Unter einer „Transaktion“ wird hier eine finanzielle Transaktion, wie zum Beispiel die Bezahlung eines Bezahlbetrags durch Vornahme einer Überweisung, eines Lastschrifteinzugs oder Belastung einer Kreditkarte, ein Bestellvorgang zur Bestellung und Lieferung eines physischen Gutes oder von Daten sowie andere logistische, Handels- und/oder Finanztransaktionen und/oder eine Datenbanktransaktion z.B. zur Speicherung eines Werts, wie z.B. eines Verbrauchswerts, eines Guthaben, oder eines Zahlungsbetrags verstanden.
- Unter einem „Terminal“ wird hier eine Vorrichtung verstanden, die ein Display, d.h. einen Bildschirm, zur Anzeige eines optischen Musters hat. Das Terminal kann lediglich Informationen erfassen und über das Display ausgeben oder es kann eine Nutzerschnittstelle zur Eingabe einer Auswahl eines Nutzers aufweisen.
- Erfindungsgemäß ist das Terminal als Verkaufsautomat ausgebildet. Der Nutzer kann eine Anforderung in das Terminal eingeben, d.h. zum Kauf eines bestimmten Produkts, wie zum Beispiel eines Getränks. Der Automat zeigt auf diese Nutzeranforderung hin ein optisch erfassbares Muster, wie zum Beispiel einen QR-Code, auf seinem Bildschirm an, wobei das Muster eine Information beinhaltet, um die Durchführung der Transaktion zu initiieren. Hierbei kann es sich um den Kaufpreis des Produkts handeln.
- Unter einem „Muster“ wird hier ein statisches optisches Muster verstanden, das auf dem Display des Terminals ausgegeben wird, und in das Informationen codiert sind, beispielsweise ein Barcode, insbesondere ein eindimensionaler, zweidimensionaler, high capacity color Barcode, MaxiCode, QR-Code oder DataMatrix-Code, oder eine zeitliche Reihenfolge mehrerer Muster, wobei durch die Muster und deren zeitliche Reihenfolge eine Information codiert ist, wie das z.B. bei einem Flickercode der Fall ist. Der „Flickercode“ ist an sich für das sogenannte chipTAN-comfort oder Smart-TAN-optic online Banking Verfahren der Sparkassen bzw. Volksbanken bekannt.
- Unter einer „Session“ wird hier eine temporäre Kommunikationsverbindung, das heißt eine sog. Communication Session, verstanden, die sich gemäß OSI-Schichtmodell auf die Transportschicht („transport layer“) oder die Anwendungsschicht („application layer“) beziehen kann. Insbesondere kann es sich bei einer Session um eine http-Session oder um eine https-Session handeln, wobei bei letzterer der Transportlayer durch eine symmetrische Verschlüsselung geschützt ist.
- Unter einem „ID-Token“ wird hier insbesondere ein tragbares elektronisches Gerät verstanden, weiches zumindest einen Datenspeicher zur Speicherung des zumindest einen Attributs und eine Kommunikations-Schnittstelle zum Auslesen des Attributs aufweist. Vorzugsweise hat der ID-Token einen gesicherten Speicherbereich zur Speicherung des zumindest einen Attributs, um zu verhindern, dass das in dem Speicherbereich gespeicherte Attribut in unerlaubter Weise verändert oder ohne die dafür erforderliche Berechtigung ausgelesen wird.
- Insbesondere kann es sich bei dem ID-Token um einen USB-Stick handeln oder ein Dokument, insbesondere ein Wert- oder Sicherheitsdokument. Unter einem „Dokument“ werden erfindungsgemäß papierbasierte und/oder kunststoffbasierte Dokumente verstanden, insbesondere elektronische hoheitliche Dokumente, wie zum Beispiel elektronische Ausweisdokumente, insbesondere Reisepässe, Personalausweise, Visa sowie Führerscheine, Fahrzeugscheine, Fahrzeugbriefe, Firmenausweise, Gesundheitskarten oder andere ID-Dokumente sowie auch Chipkarten, Zahlungsmittel, insbesondere Banknoten, Bankkarten und Kreditkarten, Frachtbriefe oder sonstige Berechtigungsnachweise, wie zum Beispiel eine Eintrittskarte, in die ein Datenspeicher zur Speicherung des zumindest einen Attributs integriert ist.
- Bei dem ID-Token kann es sich um einen Hardwaretoken handeln oder um einen Softtoken, wenn dieser kryptografisch an einen Hardwaretoken, das heißt beispielsweise an ein sogenanntes Secure Element, gebunden ist.
- Insbesondere kann ein solcher kryptografisch an ein Secure Element gebundener Softtoken gemäß
DE 10 2011 082 101 erzeugt werden. - Unter einem „ID-Provider-Computersystem“ wird hier ein Computersystem verstanden, welches dazu ausgebildet ist, zumindest ein Attribut aus dem ID-Token eines Nutzers auszulesen. Vorzugsweise wird das ID-Provider-Computersystem in einem sogenannten Trustcenter betrieben, um ein möglichst hohes Maß an Sicherheit zu schaffen.
- Unter einem „Dienst-Computersystem“ wird hier ein Computersystem verstanden, welches über eine Netzwerk-Schnittstelle zur Verbindung mit dem Netzwerk verfügt, sodass mithilfe eines Internetbrowsers oder eines anderen Anwendungsprogramms auf von dem Dienst-Computersystem gespeicherte oder generierte Internetseiten zugegriffen werden kann. Insbesondere kann es sich bei dem Dienst-Computersystem um einen Internetserver zur Verfügungstellung einer eCommerce- oder eGovernment-Anwendung handeln, insbesondere einen Onlineshop oder einen Behördenserver.
- Unter einem „Nutzer-Computersystem“ wird hier ein Computersystem verstanden, auf welches der Nutzer Zugriff hat. Hierbei kann es sich zum Beispiel um einen Personal Computer (PC), ein Tablet PC oder ein Mobilfunkgerät, insbesondere ein Smartphone, mit einem üblichen Internetbrowser, wie zum Beispiel Microsoft Internet Explorer, Safari, Google Chrome, Firefox oder einem anderen Anwendungsprogramm zum Zugriff auf das Dienst-Computersystem handeln. Das Nutzer-Computersystem hat eine Schnittstelle zur Verbindung mit dem Netzwerk, wobei es sich bei dem Netzwerk um ein privates oder öffentliches Netzwerk handeln kann, insbesondere das Internet.
- Nach einer Ausführungsform der Erfindung handelt es sich bei der Anforderung des Dienst-Computersystems um einen SAML-Request und bei der Antwort des ID-Provider-Computersystems hierauf um eine SAML-Response (vgl. Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, 25. März 2008).
- Nach einer Ausführungsform der Erfindung hat das ID-Provider-Computersystem ein Zertifikat, in dem die Leserechte für die Durchführung des Lesezugriffs spezifiziert sind.
- Unter einem „Zertifikat“ wird hier ein digitales Zertifikat verstanden, welches auch als Public-Key-Zertifikat bezeichnet wird. Bei einem Zertifikat handelt es sich um strukturierte Daten, die dazu dienen, einen öffentlichen Schlüssel eines asymmetrischen Kryptosystems einer Identität, wie zum Beispiel einer Person oder einer Vorrichtung, zuzuordnen. Beispielsweise kann das Zertifikat dem Standard X.509 oder einem anderen Standard entsprechen. Vorzugsweise handelt es sich bei dem Zertifikat um ein Card Verifiable Certificate (CVC).
- In dem Zertifikat kann spezifiziert sein, für welches Attribut oder welche Attribute des Nutzers, die in dem geschützten Speicherbereich des ID-Tokens gespeichert sind, das ID-Provider-Computersystem zur Durchführung des Lesezugriffs berechtigt ist. Bei diesen Attributen kann es sich um persönliche Attribute des Nutzers handeln, wie zum Beispiel seinen Namen, Wohnort und sein Alter. Diese Attribute können in ihrer Kombination als Nutzererkennung verwendet werden, um auf die Bezahlinformation des registrierten Nutzers zuzugreifen. Alternativ oder zusätzlich kann auch ein Pseudonym des Nutzers, welches zumindest temporär von dem ID-Token gespeichert wird, als Nutzerkennung verwendet werden.
- Ausführungsformen der Erfindung sind besonders vorteilhaft, da ein universell und auch für eCommerce- und eGovernment-Anwendungen geeignetes computerimplementiertes Bezahlverfahren geschaffen wird, welches gleichzeitig flexibel, bequem in der Handhabung und sicher ist. Dies wird insbesondere dadurch ermöglicht, dass das Bezahlverfahren auf einem ID-Token basiert, wobei Voraussetzung für die Durchführung eines Bezahlvorgangs sowohl die Authentifizierung des Nutzers gegenüber dem ID-Token als auch die Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token ist.
- Nach Ausführungsformen der Erfindung handelt es sich bei dem Terminal um eine Vorrichtung zum Verkauf eines Produkts, wie zum Beispiel einer Fahrkarte, einer Eintrittskarte oder eines Nahrungs- oder Genussmittels. Über eine Nutzerschnittstelle des Verkaufsautomaten kann der Nutzer ein gewünschtes Produkt auswählen. Der Verkaufsautomat zeigt dann auf seinem Display ein optisches Muster an, in dem der Kaufpreis des von dem Nutzer ausgewählten Produkts codiert ist sowie auch eine Kontoinformation desjenigen Kontos, auf welches die Zahlung dieses Kaufpreises zu leisten ist. Ferner beinhaltet das optische Muster die Angabe einer logischen Adresse, insbesondere einer URL, des Dienst-Computersystems.
- Der Nutzer erfasst dieses optische Muster mit einem optischen Sensor seines Nutzer-Computersystems, beispielsweise mithilfe der Kamera seines Smartphones. Das optische Muster wird dann decodiert und es wird eine Transaktionsanforderung generiert, die den Kaufpreis und die Kontoinformation des Zahlungsempfängers beinhaltet. Diese Transaktionsanforderung wird von dem Nutzer-Computersystem an das Dienst-Computersystem übertragen, und zwar mithilfe der logischen Adresse des Dienst-Computersystems.
- Das Dienst-Computersystem generiert daraufhin einen Request mit einer Attributspezifikation der für die Abgabe des von dem Nutzer gewählten Produkts erforderlichen Attribute. Beispielsweise handelt es sich um ein Produkt, das nur an Volljährige abzugeben ist, wie zum Beispiel Alkohol oder Zigaretten. In diesem Fall beinhaltet die Attributspezifikation das Attribut „Alter“. Aufgrund dieser Anforderung erhält das Dienst-Computersystem von dem ID-Provider-Computersystem eine Response, die diese Altersangabe beinhaltet. Das Dienst-Computersystem prüft dann, ob die Altersangabe ein vorgegebenes Kriterium erfüllt, beispielsweise also die Volljährigkeit, und wenn dies der Fall ist, führt das Dienst-Computersystem die Transaktion durch, indem hier beispielsweise der Kaufpreis von dem Konto des Nutzers auf das Konto des Zahlungsempfängers überwiesen wird. Anschließend gibt das Dienst-Computersystem ein Bestätigungssignal an den Verkaufsautomaten ab, woraufhin dieser dann das von dem Nutzer zuvor ausgewählte Produkt abgibt.
- Besonders vorteilhaft ist, wenn das Terminal eine Netzwerk-Schnittstelle zur Kommunikation über das Netzwerk aufweist. In diesem Fall kann das Bestätigungssignal von dem Dienst-Computersystem über das Netzwerk an den Automat übertragen werden. Eine andere Möglichkeit ist, dass das Bestätigungssignal von dem Dienst-Computersystem an das Nutzer-Computersystem gesendet wird. Das Nutzer-Computersystem kann daraufhin auf einem Display des Nutzer-Computersystems ein optisches Muster anzeigen, in welches dieses Bestätigung codiert ist. Dieses optische Muster kann dann von dem Terminal, der ebenfalls einen optischen Sensor hat, erfasst werden. Diese Ausführungsform hat den Vorteil, dass das Terminal nicht mit dem Netzwerk verbunden zu sein braucht, was sicherheitstechnische Vorzüge hat.
- Nach einer weiteren Ausführungsform der Erfindung ist das Dienst-Computersystem mit dem Terminal über einen von dem Netzwerk verschiedenen Kommunikationskanal verbunden, wie zum Beispiel ein internes Firmennetzwerk oder ein Virtual Private Network, über welches das Bestätigungssignal von dem Dienst-Computersystem an das Terminal übertragen wird.
- Nach Ausführungsformen der Erfindung wird zunächst eine erste Session zwischen dem Internetbrowser des Nutzer-Computersystems und dem Dienst-Computersystem über das Internet aufgebaut, wobei es sich bei der ersten Session um eine http-Session oder eine https-Session handeln kann. Der Nutzer kann eine Transaktionsanforderung in den Internetbrowser eingeben, beispielsweise zur Veranlassung eines Bezahlvorgangs. Beispielsweise hat der Nutzer zuvor über das Dienst-Computersystem eine Ware bestellt und möchte diese bestellte Ware bezahlen, wozu der Nutzer die entsprechende Transaktionsanforderung in den Internetbrowser eingibt, weiche an das Dienst-Computersystem über die erste Session übertragen wird.
- Das Dienst-Computersystem erzeugt daraufhin eine Anforderung, d.h. einen Request eines Request-Response Protokolls. Der Request kann eine vordefinierte oder standardisierte Struktur haben. Beispielsweise kann der Request textbasiert sein, eine XML, ASN.1 oder binär-Struktur aufweisen oder als SAML-Request ausgebildet sein. Der Request, beispielsweise also der SAML-Request, beinhaltet eine Attributspezifikation, welche die aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute spezifiziert. Hierbei kann es sich um Attribute handeln, welche den Nutzer, der dem ID-Token zugeordnet ist, identifizieren und/oder die eine Bezahlinformation angeben, wie zum Beispiel eine Kontoverbindung oder Kreditkarteninformationen, und/oder Attribute, welche den ID-Token selbst betreffen, wie zum Beispiel dessen Gültigkeitsdauer, Ausstellungsdatum und/oder die ausstellende Organisation oder Behörde.
- Nach Ausführungsformen der Erfindung wird der Request von dem Dienst-Computersystem über das Nutzer-Computersystem an das ID-Provider-Computersystem übertragen. Aufgrund des Empfangs des Request durch das Nutzer-Computersystem wird der weitere Ablauf zur Erzeugung der Response, einschließlich der Authentisierung des Nutzers und des ID-Provider-Computersystems, ausgelöst.
- Insbesondere kann die Attributspezifikation das Geburtsdatum des Nutzers beinhalten, falls zum Beispiel die Volljährigkeit des Nutzers als Voraussetzung für die Durchführung der Transaktion von dem Dienst-Computersystem zu prüfen ist. Der Request beinhaltet ferner Transaktionsdaten zur Spezifizierung der Transaktion, das heißt zum Beispiel einen Bezahlbetrag sowie Kontoinformationen, insbesondere die Kontoverbindung des Dienst-Computersystems, auf welche die Zahlung zu leisten ist. Ferner beinhaltet der Request einen Uniform Ressource Locator (URL) des ID-Provider-Computersystems, welches die Attribute aus dem ID-Token auslesen soll, sowie eine URL des Dienst-Computersystems zur Angabe eines Empfängers für die Response, die aufgrund der Request von dem ID-Provider-Computersystem zu generieren ist.
- Das Dienst-Computersystem erzeugt für den Request eine Kennung, die den Request eindeutig identifiziert, wie z.B. einen globally unique identifier (GUID). Der Request beinhaltet diese Kennung.
- Der Request wird von dem Dienst-Computersystem signiert, und zwar mithilfe eines privaten Schlüssels eines kryptografischen Schlüsselpaars, welches dem Dienst-Computersystem zugeordnet ist.
- Aufgrund der Transaktionsanforderung wird über die erste Session eine Webseite von dem Dienst-Computersystem an das Nutzer-Computersystem übertragen und durch den Internetbrowser bzw. das Anwendungsprogramm, insbesondere eine sog. App, angezeigt. Zusammen mit der Webseite wird der Request übertragen, der jedoch nicht angezeigt wird.
- Die Webseite hat zumindest ein Eingabefeld zur Eingabe von Zusatzinformationen, welche für die Durchführung der Transaktion benötigt werden. Bei dieser Zusatzinformation kann es sich zum Beispiel um eine Kontoverbindung oder Kreditkarteninformationen des Nutzers handeln und/oder um eine Authentifizierungsinformation, um den Nutzer gegenüber dem Dienst-Computersystem zu authentifizieren. Zum Beispiel kann es sich bei der Authentifizierungsinformation um ein One-Time Password (OTP) handeln. Vorzugsweise wird die Zusatzinformation mithilfe des öffentlichen Schlüssels des Dienst-Computersystems durch das Nutzer-Computersystem verschlüsselt, sodass nur die verschlüsselte Zusatzinformation anschließend über eine zweite Session von dem Internetbrowser bzw. dem Anwendungsprogramm an das ID-Provider-Computersystem über das Netzwerk weitergeleitet wird.
- Über diese zweite Session wird auch der Request weitergeleitet. Der Aufbau der zweiten Session erfolgt durch Aufruf der URL des ID-Provider-Computersystems, welche in dem Request beinhaltet ist. Die zweite Session wird dabei als geschützte Kommunikationsverbindung aufgebaut, und zwar mit einer verschlüsselten Transportschicht, das heißt mit Transport Layer Security (TLS), die auch als Secure Sockets Layer (SSL) bezeichnet wird, insbesondere als https-Session.
- Nach Ausführungsformen der Erfindung erzeugt das ID-Provider-Computersystem aufgrund des Empfangs des Requests über die zweite Session einen Identifikator für eine noch aufzubauende dritte Session, d.h. eine sog. Session-ID. Das ID-Provider-Computersystem speichert den Request sowie die zusammen mit dem Request über die zweite Session empfangene Zusatzinformation mit der Session-ID für die dritte Session.,
- Das ID-Provider-Computersystem sendet dann eine Nachricht über die zweite Session, welche eine logische Adresse des ID-Provider-Computersystems und beispielsweise auch die Session-ID der dritten Session beinhaltet. Von dieser logischen Adresse kann der Internetbrowser bzw. das Anwendungsprogramm zu einem späteren Zeitpunkt die Response auf den zuvor weitergeleiteten Request abrufen. Bei der logischen Adresse kann es sich um einen uniform resource locator (URL) handeln, durch den die Response abrufbar ist.
- Anschließend wird die dritte Session auf dem Application Layer zwischen einem Programm des Nutzer-Computersystems und dem ID-Provider-Computersystem aufgebaut, und zwar über den gesicherten Transportlayer der zweiten Session. Bei dem Programm kann es sich zum Beispiel um ein Browser-Plug-in des Internetbrowsers oder ein von dem Internetbrowser verschiedenes Anwendungsprogramm handeln.
- Das ID-Provider-Computersystem überträgt dann diejenigen Informationen über die dritte Session an das Programm, die für das Auslesen des oder der Attribute aus dem ID-Token benötigt werden. Diese Informationen beinhalten zumindest ein Zertifikat des ID-Provider-Computersystems, welches eine Angabe von Leserechten des ID-Provider-Computersystems zum Lesen von einem oder mehrerer Attribute beinhaltet.
- Das Programm des Nutzer-Computersystems prüft dann, ob die in dem Zertifikat angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-Computersystems auf das oder die gemäß der Attributspezifikation des Requests zu lesenden Attribute zuzulassen. Wenn die Leserechte des ID-Provider-Computersystems ausreichend sind, werden die folgenden weiteren Schritte durchgeführt:
- a) Es wird eine lokale Verbindung zwischen dem Lesegerät des Nutzer-Computersystems und dem ID-Token aufgebaut. Bei einem ID-Token mit einer kontaktbehafteten Schnittstelle, beispielsweise einer Chipkarten-Schnittstelle, kann dies durch Einführen des ID-Tokens in das Lesegerät erfolgen. Bei einem ID-Token mit einer kontaktlosen Schnittstelle, wie zum Beispiel einer RFID oder einen NFC-Schnittstelle, kann dies dadurch erfolgen, dass der ID-Token auf das Lesegerät gelegt wird. Hier sind auch Token mit USB, BlueTooth oder microSD-Karten möglich sowie auch virtuelle Smart-Cards.
- b) Der Nutzer authentifiziert sich gegenüber dem ID-Token, beispielsweise durch Eingabe seiner Personal Identification Number (PIN) oder durch Eingabe einer anderen Information, wie zum Beispiel der Erfassung eines biometrischen Merkmals des Nutzers. Bei der Authentifizierung des Nutzers gegenüber dem ID-Token wird ein Session Key vereinbart. Insbesondere kann die Vereinbarung eines Session Keys mithilfe eines Diffie-Hellman-Protokolls erfolgen.
- c) Anschließend wird eine vierte Session auf dem Application Layer aufgebaut, und zwar zwischen einem Programm des ID-Tokens und dem ID-Provider-Computersystem, wobei diese vierte Session über die lokale Verbindung und die dritte Session verläuft und auf dem Application Layer eine zusätzliche Ende-zu-Ende Verschlüsselung mithilfe des in Schritt b vereinbarten Session Keys erfolgt.
- d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems, beispielsweise mithilfe eines Challenge-Response-Protokolls.
- e) Das oder die Attribute gemäß der Attributspezifikation, welche das ID-Provider-Computersystem mit dem Request empfangen hat, werden nun über die vierte Session von dem ID-Provider-Computersystem aus dem ID-Token ausgelesen. Dies setzt die erfolgreiche Authentifizierung des Nutzers in Schritt b sowie die erfolgreiche gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems in Schritt d) voraus und erfolgt verschlüsselt über die vierte Session, sodass ein Maximum an Sicherheit und Vertrauenswürdigkeit hinsichtlich des oder der ausgelesenen Attribute gegeben ist.
- Das ID-Provider-Computersystem erzeugt dann eine Response, die das oder die ausgelesenen Attribute und die Kennung des Request und/oder die Zusatzinformation beinhaltet und zwar gemäß dem Request-Response Protokoll, dem der Request unterliegt. Bei einer SAML-Request wird also dementsprechend eine SAML-Response erzeugt. Über die Kennung des Request, die auch in der Response beinhaltet ist, wird hier die logische Zuordnung von Request und Response, d.h. das sog. Binding, hergestellt.
- Die Response wird von dem ID-Provider-Computersystem signiert und zum Abrufen von der zuvor dem Nutzer-Computersystem über die Nachricht mitgeteilten logischen Adresse gespeichert.
- Das Nutzer-Computersystem liest dann diese Response von dem ID-Provider-Computersystem mit Hilfe der logischen Adresse, beispielsweise der URL, und leitet die Response über die erste Session an das Dienst-Computersystem weiter. Mithilfe der Kennung der Response wird diese dem Request und damit der angeforderten Transaktion zugeordnet und dann wird die Transaktion von dem Dienst-Computersystem ausgeführt, das heißt der Bezahlvorgang ausgelöst und das bestellte Produkt geliefert, wenn dies der Inhalt der Response erlaubt.
- Nach einer Ausführungsform der Erfindung handelt es sich bei dem Programm des Nutzer-Computersystems um ein Browser-Plug-in des Internetbrowsers, wobei es sich bei dem Internetbrowser um ein übliches Browserprogramm, wie zum Beispiel Microsoft Internet Explorer, Safari, Google Chrome oder Firefox handeln kann. Alternativ kann es sich bei dem Programm des Nutzer-Computersystems um ein von dem Internetbrowser separates Anwendungsprogramm handeln.
- Nach einer Ausführungsform der Erfindung handelt es sich bei der von dem Nutzer eingegebenen Zusatzinformation um eine Bezahlinformation, wie zum Beispiel eine Kontoverbindung des Nutzers von der der in dem Request angegebene Bezahlbetrag abgebucht oder eingezogen werden soll.
- Das sogenannte Clearing, das heißt die Prüfung der Bonität des Kunden, sowie die Veranlassung des Zahlvorgangs kann dann durch das ID-Provider-Computersystem veranlasst werden, welches die Durchführung der Bezahlung mit der Response dem Dienst-Computersystem bestätigt. Dies hat den Vorteil, dass das Dienst-Computersystem keine Kenntnis hinsichtlich der Bezahlinformation des Nutzers, das heißt insbesondere seiner Kontoverbindung, erlangen muss.
- Alternativ kann der Nutzer seine Bezahlinformation mit dem öffentlichen Schlüssel des Dienst-Computersystems verschlüsseln, sodass nur die verschlüsselte Bezahlinformation des Nutzers an das ID-Provider-Computersystem übertragen wird. Das ID-Provider-Computersystem leitet dann die verschlüsselte Bezahlinformation mit der Response an das Dienst-Computersystem weiter, welches die Bezahlinformation entschlüsselt, und dann das Clearing durchführt sowie den Zahlbetrag von dem Konto des Nutzers gemäß der Bezahlinformation einzieht. Dies hat den Vorteil, dass das ID-Provider-Computersystem keine Kenntnis von den Bezahlinformationen des Nutzers erlangt.
- Zu dem erfindungsgemäßen Computersystem gehört ein Terminal, welches erfindungsgemäß als Verkaufsautomat ausgebildet ist. Der Nutzer kann eine Anforderung in den Automat eingeben, d.h. zum Kauf eines bestimmten Produkts, wie zum Beispiel eines Getränks. Der Automat zeigt auf diese Nutzeranforderung hin ein optisch erfassbares Muster, wie zum Beispiel einen QR-Code, auf seinem Bildschirm an, das eine Information beinhaltet, um die Durchführung der Transaktion zu initiieren.
- Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert.
- Es zeigen:
-
1 ein Blockdiagramm eines ID-Tokens, -
2 eine Anordnung eines Computersystems zur Durchführung eines erfindungsgemäßen Verfahrens. - Elemente der nachfolgenden Figuren, die zueinander identisch sind oder einander entsprechen, sind jeweils mit denselben Bezugszeichen gekennzeichnet.
- Die
1 zeigt einen ID-Token106 , bei dem es sich zum Beispiel um einen elektronischen Personalausweis handeln kann. - Der geschützte Speicherbereich
120 des ID-Token106 dient zur Speicherung eines Referenzwerts, der für die Authentifizierung eines Nutzers102 gegenüber dem ID-Token106 benötigt wird. Bei diesem Referenzwert handelt es sich beispielsweise um eine Kennung, insbesondere eine so genannte Personal Identification Number (PIN), oder um Referenzdaten für ein biometrisches Merkmal des Nutzers102 , welches für die Authentifizierung des Nutzers gegenüber dem ID-Token106 verwendet werden kann. - Der geschützte Bereich
122 dient zur Speicherung eines privaten Schlüssels und der geschützte Speicherbereich124 dient zur Speicherung von Attributen, zum Beispiel des Nutzers102 , wie zum Beispiel dessen Name, Wohnort, Geburtsdatum, Geschlecht, und/oder von Attributen, die den ID-Token selbst betreffen, wie zum Beispiel die Institution, die den ID-Token erstellt oder ausgegeben hat, die Gültigkeitsdauer des ID-Tokens, einen Identifikator des ID-Tokens, wie zum Beispiel eine Passnummer oder eine Kreditkartennummer. - Der elektronische Speicher
118 kann ferner einen Speicherbereich126 zur Speicherung eines Zertifikats aufweisen. Das Zertifikat beinhaltet einen öffentlichen Schlüssel, der dem in dem geschützten Speicherbereich122 gespeicherten privaten Schlüssel zugeordnet ist. Das Zertifikat kann nach einem Public Key Infrastruktur (PKI) Standard erstellt worden sein, beispielsweise nach dem X.509 Standard. - Das Zertifikat muss nicht zwangsläufig in dem elektronischen Speicher
118 des ID-Tokens106 gespeichert sein. Alternativ oder zusätzlich kann das Zertifikat auch in einem öffentlichen Verzeichnisserver gespeichert sein. - Der ID-Token
106 hat einen Prozessor128 . Der Prozessor128 dient zur Ausführung von Programminstruktionen130 ,132 und134 . Die Programminstruktionen130 dienen zur Nutzerauthentifizierung, d.h. zur Authentifizierung des Nutzers102 gegenüber dem ID-Token. - Bei Verwendung einer PIN gibt der Nutzer
102 seine PIN zu seiner Authentifizierung in den ID-Token106 ein, beispielsweise über das Nutzer-Computersystem100 . Durch Ausführung der Programminstruktionen130 wird dann auf den geschützten Speicherbereich120 zugegriffen, um die eingegebene PIN mit dem dort gespeicherten Referenzwert der PIN zu vergleichen. Für den Fall, dass die eingegebene PIN mit dem Referenzwert der PIN übereinstimmt, gilt der Nutzer102 als authentifiziert. - Alternativ wird ein biometrisches Merkmal des Nutzers
102 erfasst. Beispielsweise hat der ID-Token106 hierzu einen Fingerabdrucksensor oder ein Fingerabdrucksensor ist an das Nutzer-Computersystem100 angeschlossen. Die von dem Nutzer102 erfassten biometrischen Daten werden durch Ausführung der Programminstruktionen130 mit den in dem geschützten Speicherbereich120 gespeicherten biometrischen Referenzdaten verglichen. Bei hinreichender Übereinstimmung der von dem Nutzer102 erfassten biometrischen Daten mit den biometrischen Referenzdaten gilt der Nutzer102 als authentifiziert. - Die Programminstruktionen
134 dienen zur Ausführung der den ID-Token106 betreffenden Schritte eines kryptographischen Protokolls zur Authentifizierung eines ID-Provider-Computersystems136 gegenüber dem ID-Token106 . Bei dem kryptographischen Protokoll kann es sich um ein Challenge-Response-Protokoll basierend auf einem symmetrischen Schlüssel oder einem asymmetrischen Schlüsselpaar handeln. - Beispielsweise wird durch das kryptographische Protokoll ein Extended Access Control-Verfahren implementiert, wie es für maschinenlesbare Reisedokumente (machine-readable travel documents - MRTD) von der internationalen Luftfahrtbehörde (ICAO) spezifiziert ist. Durch erfolgreiche Ausführung des kryptographischen Protokolls authentifiziert sich das ID-Provider-Computersystem
136 gegenüber dem ID-Token und weist dadurch seine Leseberechtigung zum Lesen der in dem geschützten Speicherbereich124 gespeicherten Attribute nach. Die Authentifizierung kann auch gegenseitig sein, d.h. auch der ID-Token106 muss sich dann gegenüber dem ID-Provider-Computersystem136 nach demselben oder einem anderen kryptographischen Protokoll authentifizieren. - Die Programminstruktionen
132 dienen zur Ende-zu-Ende-Verschlüsselung von zwischen dem ID-Token106 und einem ID-Provider-Computersystem136 (vgl.2 ) übertragenen Daten, zumindest aber der von dem ID-Provider-Computersystem136 aus dem geschützten Speicherbereich124 ausgelesenen Attribute. Für die Ende-zu-Ende-Verschlüsselung kann ein symmetrischer Schlüssel verwendet werden, der beispielsweise anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token106 und dem ID-Provider-Computersystem136 vereinbart wird. - Der ID-Token
106 hat eine Schnittstelle108 zur Kommunikation mit einer entsprechenden Schnittstelle104 eines Nutzer-Computersystems100 (vergleiche2 ). Die Schnittstelle kann kontaktlos oder kontaktbehaftet ausgebildet sein. Insbesondere kann es sich um eine RFID- oder um eine NFC-Kommunikationsschnittstelle handeln. - Der Zugriff auf den geschützten Speicherbereich
124 zum Lesen einer oder mehrerer der Attribute kann nur über den Prozessor128 des ID-Tokens106 erfolgen, da der geschützte Speicherbereich124 sowie auch die weiteren geschützten Speicherbereiche 120, 122 nicht unmittelbar zum Beispiel über ein Bussystem mit der Schnittstelle108 verbunden sind, sondern nur mit dem Prozessor128 , das heißt ein Zugriff über die Schnittstelle108 unmittelbar auf den geschützten Speicherbereich124 ist bereits schaltungstechnisch ausgeschlossen. Allein der Prozessor128 kann also lesend auf den geschützten Speicherbereich124 zugreifen, um dann gegebenenfalls die ausgelesenen Attribute über die Schnittstelle108 auszugeben. - Die
2 zeigt ein Nutzer-Computersystem100 des Nutzers102 . Bei dem Nutzer-Computersystem100 kann es sich um einen Personal-Computer (PC), einen tragbaren Computer, wie zum Beispiel einen Laptop, Notebook oder Tablet-Computer, ein mobiles Telekommunikationsgerät, insbesondere ein Smartphone handeln. - Das Nutzer-Computersystem hat zumindest einen Prozessor
110 zur Ausführung eines Anwendungsprogramms112 . Das Anwendungsprogramm112 ist dazu ausgebildet, über eine Netzwerk-Schnittstelle114 des Nutzer-Computersystems100 über ein Netzwerk116 zu kommunizieren. Beispielsweise handelt es sich bei dem Anwendungsprogramm um einen Internet-Browser oder ein anderes spezialisiertes Anwendungsprogramm, welches über das Netzwerk116 kommunizieren kann, insbesondere ein HTML-fähiges Anwendungsprogramm. - Der Prozessor
110 dient zur Ausführung eines weiteren Programms113 , bei dem es sich beispielsweise um ein Plug-in für das Anwendungsprogramm112 handeln kann, beispielsweise um ein Browser-Plug-in, wenn das Anwendungsprogramm112 als Internet-Browser ausgebildet ist, oder um ein von dem Anwendungsprogramm separates Programm. - Bei dem Netzwerk kann es sich um ein Computernetzwerk, wie zum Beispiel das Internet, handeln. Insbesondere kann das Netzwerk
116 auch ein Mobilfunknetzwerk beinhalten. - Das ID-Provider-Computersystem
136 hat eine Netzwerk-Schnittstelle138 zur Kommunikation über das Netzwerk116 . Das ID-Provider-Computersystem136 hat ferner einen Speicher140 mit einem geschützten Speicherbereich141 , in dem ein privater Schlüssel142 des ID-Provider-Computersystems136 gespeichert ist, sowie auch das entsprechende Zertifikat144 . Auch bei diesem Zertifikat kann es sich beispielsweise um ein Zertifikat nach einem PKI-Standard, wie zum Beispiel X.509 handeln. - Das ID-Provider-Computersystem
136 hat ferner zumindest einen Prozessor145 zur Ausführung von Programminstruktionen146 und148 . Durch Ausführung der Programminstruktionen146 werden die das ID-Provider-Computersystem136 betreffende Schritte des kryptographischen Protokolls ausgeführt. Insgesamt wird also das kryptographische Protokoll durch Ausführung der Programminstruktionen134 durch den Prozessor128 des ID-Tokens106 sowie durch Ausführung der Programminstruktionen146 durch den Prozessor145 des ID-Provider-Computersystems136 implementiert. - Die Programminstruktionen
148 dienen zur Implementierung der Ende-zu-Ende-Verschlüsselung auf Seiten des ID-Provider-Computersystems136 , beispielsweise basierend auf dem symmetrischen Schlüssel, der anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token106 und dem ID-Provider-Computersystem136 vereinbart worden ist. Prinzipiell kann jedes an sich vor bekannte Verfahren zur Vereinbarung des symmetrischen Schlüssels für die Ende-zu-Ende-Verschlüsselung verwendet werden, wie zum Beispiel ein Diffie-Hellman-Schlüsselaustausch. - Das ID-Provider-Computersystem
136 befindet sich vorzugsweise in einer besonders geschützten Umgebung, insbesondere in einem so genannten Trust-Center, sodass das ID-Provider-Computersystem136 in Kombination mit der Notwendigkeit der Authentifizierung des Nutzers102 gegenüber dem ID-Token106 den Vertrauensanker für die Authentizität der aus dem ID-Token106 ausgelesenen Attribute bildet. - Ein Dienst-Computersystem
150 kann zur Entgegennahme einer Bestellung oder eines Auftrags für eine Dienstleistung oder ein Produkt, insbesondere eine Online-Dienstleistung, ausgebildet sein. Beispielsweise kann der Nutzer102 online über das Netzwerk116 ein Konto bei einer Bank eröffnen oder eine andere Finanz- oder Bankdienstleistung in Anspruch nehmen. Das Dienst-Computersystem150 kann auch als Online-Warenhaus ausgebildet sein, sodass der Nutzer102 beispielsweise online ein Mobiltelefon oder dergleichen erwerben kann. Ferner kann das Dienst-Computersystem150 auch zur Lieferung von digitalen Inhalten ausgebildet sein, beispielsweise für den Download von Musik- und/oder Videodaten. - Das Dienst-Computersystem
150 hat hierzu eine Netzwerk-Schnittstelle152 zur Verbindung mit dem Netzwerk116 . Ferner hat das Dienst-Computersystem150 zumindest einen Prozessor154 zur Ausführung von Programminstruktionen156 . Durch Ausführung der Programminstruktionen156 werden beispielsweise dynamische HTML-Seiten generiert, über die der Nutzer102 seinen Auftrag oder seine Bestellung eingeben kann, sowie Transaktionen durchgeführt. - Je nach der Art des beauftragten oder bestellten Produkts oder der Dienstleistung muss das Dienst-Computersystem
150 ein oder mehrere Attribute des Nutzers102 und/oder dessen ID-Token106 anhand eines oder mehrerer vorgegebener Kriterien überprüfen. Nur wenn diese Prüfung bestanden wird, wird die Bestellung oder der Auftrag des Nutzers102 entgegengenommen und/oder ausgeführt. - Zur Durchführung einer elektronischen Transaktion kann wie folgt vorgegangen werden:
- - Der Nutzer
102 startet das Anwendungsprogramm112 des Nutzer-Computersystems, wobei im Weiteren ohne Beschränkung der Allgemeinheit davon ausgegangen wird, dass es sich hierbei um einen Internet-Browser handelt. Der Nutzer102 gibt eine URL des Dienst-Computersystems150 in den Internet-Browser ein, so dass daraufhin eine erste Session 201 zwischen dem Internet-Browser112 und dem Dienst-Computersystem150 über das Netzwerk116 aufgebaut wird. Der Nutzer kann dann über die erste Session 201 einen von dem Dienst-Computersystem150 angebotenen Dienst anfordern, wie zum Beispiel ein Produkt bestellen, Daten zum Download anfordern oder die Durchführung einer finanziellen Transaktion anfordern. Hierzu wird von dem Internet-Browser112 eine entsprechende Transaktionsanforderung158 an das Dienst-Computersystem150 gesendet, die diese Anforderung signalisiert. - - Das Dienst-Computersystem empfängt also von dem Internet-Browser über die erste Session eine Transaktionsanforderung
158 des Nutzers102 . - - Aufgrund des Empfangs der Transaktionsforderung
158 über die erste Session 201 erzeugt das Dienst-Computersystem150 einen Request166 . Der Request166 beinhaltet (i) eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute. Bei diesen Attributen kann es sich um persönliche Angaben zu dem Nutzer102 und/oder Daten betreffend den ID-Token106 selbst oder ein Pseudonym des Nutzers102 , welches von dem ID-Token106 verfügbar ist, handeln. Der Request beinhaltet ferner (ii) die Transaktionsdaten zur Spezifizierung der Transaktion, wie zum Beispiel einen Bezahlbetrag, der für den Kauf des bestellten Produkts oder die Durchführung des bestellten Dienstes an das Dienst-Computersystem150 oder einen Dritten zu entrichten ist, und/oder andere Transaktionsdaten, die die durchzuführende Transaktion spezifizieren. Der Request beinhaltet ferner (iii) eine Kennung180 des Requests, beispielsweise eine GUID, die für das sogenannte Binding des Requests und einer daraufhin empfangenen Response174 erforderlich ist. Für die Erzeugung der Kennung kann das Dienst-Computersystem150 einen GUID-Generator aufweisen. Die Request beinhaltet ferner (iv) eine URL des ID-Provider-Computersystems136 und (v) eine URL des Dienst-Computersystems150 selbst. Der Request wird von dem Dienst-Computersystem150 signiert, nämlich mit Hilfe eines privaten Schlüssels des Dienst-Computersystems150 . Bei dem Request166 kann es sich um einen SAML-Request oder einen anderen Request eines Request-Response-Protokolls handeln. - - Als Antwort auf die Transaktionsanforderung
158 sendet dann das Dienst-Computersystem150 eine Webseite160 über die erste Session201 an das Nutzer-Computersystem100 , wobei die Webseite160 ein Eingabefeld162 zur Eingabe einer Zusatzinformation durch den Nutzer102 für die Transaktion aufweist und ferner ein Eingabeelement164 , das der Nutzer102 zum Beispiel durch Anklicken selektieren kann, wenn die Webseite160 durch den Internet-Browser112 wiedergegeben wird, um die Weiterteitung des Request166 zu erlauben. Zusammen mit der Webseite160 wird auch der Request166 über die erste Session 201 zu dem Internet-Browser112 übertragen. - - Aufgrund des Empfangs der Webseite
160 und des Requests166 wird die Webseite160 durch den Internet-Browser112 wiedergegeben, so dass der Nutzer102 die Zusatzinformation in das Eingabefeld162 eingeben kann. Beispielsweise handelt es sich bei der Zusatzinformation um eine Kontoverbindung des Nutzers102 , eine Kreditkartennummer des Nutzers102 oder andere ergänzende Transaktionsdaten und/oder um eine Authentifizierungsinformation zum Nachweis der Berechtigung des Nutzers102 für die Durchführung der Transaktion, wozu der Nutzer102 beispielsweise ein One-Time-Passwort (OTP) in das Eingabefeld162 eingibt. Vorzugsweise wird die von dem Nutzer102 eingegebene Zusatzinformation168 mit dem öffentlichen Schlüssel des Dienst-Computersystems150 durch das Nutzer-Computersystem100 verschlüsselt, um ein entsprechendes Chiffrat zu erhalten. - - Anschließend wird eine zweite Session
202 zwischen dem Internet-Browser112 und dem ID-Provider-Computersystem136 über das Netzwerk116 aufgebaut, und zwar mit Hilfe der URL des ID-Provider-Computersystems136 , die das Nutzer-Computersystem100 mit dem Request166 empfangen hat. Die zweite Session 202 wird mit einem gesicherten Transportlayer aufgebaut, beispielsweise als https-Session. - - Über die zweite Session 202 werden der Request
166 und die Zusatzinformation168 oder nur das mit Hilfe des öffentlichen Schlüssels des Dienst-Computersystems150 gewonnene Chiffrat der Zusatzinformation168 von dem Nutzer-Computersystem100 an das ID-Provider-Computersystem136 weitergeleitet. - - Aufgrund des Empfangs des Requests
166 durch das ID-Provider-Computersystem136 erzeugt dieses durch Ausführen seiner Programminstruktionen170 eine Session-ID für eine noch aufzubauende dritte Session 203. Der Request166 und die Zusatzinformation168 werden in dem Speicher140 des ID-Provider-Computersystems136 gespeichert. - - Das ID-Provider-Computersystem
136 generiert dann eine Nachricht172 , die die Session-ID für den Aufbau der dritten Session203 und eine logische Adresse beinhaltet. Mit Hilfe der logischen Adresse kann die von dem ID-Provider-Computersystem136 aufgrund des Request166 zu erzeugende Response174 abgerufen werden. Insbesondere kann die logische Adresse als eine URL ausgebildet sein. Die Nachricht172 wird über die zweite Session202 von dem ID-Provider-Computersystem136 an den Internet-Browser112 gesendet. - - Aufgrund des Empfangs der Nachricht
172 wird die dritte Session203 zwischen dem Programm113 des Nutzer-Computersystems100 und dem ID-Provider-Computersystem136 über den gesicherten Transportlayer der zweiten Session202 aufgebaut. Beispielsweise handelt es sich bei dem Programm113 um ein Browser-Plug-in des Internet-Browsers112 . Alternativ kann es sich bei dem Programm113 auch um ein weiteres Anwendungsprogramm handeln. Es ist dabei auch möglich, die Funktionalitäten des Internet-Browsers112 und die des Programms113 in einem Programm zu implementieren. - - Über die dritte Session
203 wird dann zumindest das Zertifikat144 an das Programm113 übertragen. - - Durch das Programm
113 wird dann geprüft, ob die in dem Zertifikat144 angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-Computersystems136 auf das oder die gemäß der Attributspezifikation, die in dem Request166 beinhaltet ist, zu lesenden Attribute zuzulassen. Nur dann, wenn diese Leserechte ausreichend sind, werden die folgenden Schritte durchgeführt:- a) Es wird eine lokale Verbindung
176 zwischen den Schnittstellen104 und108 aufgebaut. Beispielsweise erscheint auf dem Bildschirm des Nutzer-Computersystems100 eine Aufforderung für den Nutzer102 zum Einführen des ID-Tokens106 in ein Lesegerät des Nutzer-Computersystems100 , welches die Schnittstelle104 aufweist oder zum Auflegen des ID-Tokens106 auf eine kontaktlos ausgebildete Schnittstelle104 . - b) Der Nutzer
102 authentifiziert sich dann gegenüber dem ID-Token beispielsweise durch Eingabe seiner PIN in das Nutzer-Computersystem100 bzw. dessen Lesegerät. Die Authentifizierung des Nutzers kann mit Hilfe eines kryptographischen Protokolls erfolgen, beispielsweise mittels eines Challenge-Response-Protokolls oder basierend auf einem Diffie-Helman-Schlüsselaustausch, wobei im Rahmen der Authentifizierung des Nutzers ein Session-Key vereinbart wird. - c) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers wird eine vierte Session
204 zwischen dem ID-Token106 und dem ID-Provider-Computersystem136 aufgebaut, und zwar über die lokale Verbindung176 und die dritte Session203 . Die vierte Session204 wird mit einer Ende-zu-Ende-Verschlüsselung mit Hilfe des Session-Keys, der bei der Authentifizierung des Nutzers in dem Schritt b) vereinbart worden ist, geschützt. - d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens
106 und des ID-Provider-Computersystems136 mit Hilfe der jeweiligen privaten Schlüssel, das heißt den in dem geschützten Speicherbereich122 gespeicherten privaten Schlüssels des ID-Tokens106 und dem privaten Schlüssels142 des ID-Provider-Computersystems136 . Für diese gegenseitige Authentifizierung können die Zertifikate des ID-Tokens106 aus dem Speicherbereich126 (vergleiche1 ) sowie das Zertifikat144 des ID-Provider-Computersystems136 über die vierte Session ausgetauscht werden. - e) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers gegenüber dem ID-Token und der erfolgreichen gegenseitigen Authentifizierung des ID-Tokens
106 und des ID-Provider-Computersystems136 liest dann das ID-Provider-Computersystem136 das oder die Attribute gemäß der Attributspezifikation aus dem ID-Token106 aus, wobei die Attribute durch die Ende-zu-Ende-Verschlüsselung bei der Übertragung von dem ID-Token106 zu dem ID-Provider-Computersystem136 geschützt werden. Hierzu sendet das ID-Provider-Computersystem über die vierte Session204 ein Lesekommando über die vierte Session an den ID-Token106 . Das Lesekommando182 beinhaltet die Attributspezifikation, das heißt die Auswahl derjenigen Attribute, die aus dem geschützten Speicherbereich124 des ID-Tokens106 ausgelesen werden sollen.
178 wird dann von dem ID-Provider-Computersystem136 die Response174 , beispielsweise ein SAML-Response, auf dem Request166 erzeugt. Die Response178 beinhaltet die zuvor über die vierte Session240 aus dem ID-Token106 ausgelesenen Attribute, die Zusatzinformation168 oder - alternativ - nicht die Zusatzinformation168 , sondern nur das Chiffrat der Zusatzinformation168 , sowie die Kennung180 , die das Dienst-Computersystem150 initial für den Request166 vergeben hat. Die Response174 wird von dem ID-Provider-Computersystem136 mit Hilfe des privaten Schlüssels142 signiert und dann in dem Speicher140 gespeichert, so dass die Request166 von der logischen Adresse abrufbar ist. - a) Es wird eine lokale Verbindung
- - Das Nutzer-Computersystem
100 , wie zum Beispiel dessen Internet-Browser112 , liest dann mit Hilfe der logischen Adresse die Response174 beispielsweise über die zweite Session202 aus dem Speicher140 . - - Die Response
174 wird dann von dem Nutzer-Computersystem100 , beispielsweise von dem Internet-Browser112 , über die erste Session201 an das Dienst-Computersystem150 weitergeleitet. Hierbei kann vorgesehen sein, dass der Nutzer102 von dem Internet-Browser112 zur Eingabe einer Bestätigung aufgefordert wird, bevor die Response174 an das Dienst-Computersystem weitergeleitet wird. Dabei kann ferner vorgesehen sein, dass von dem Internet-Browser der Inhalt der Response174 ganz oder teilweise angezeigt wird, insbesondere die aus dem ID-Token ausgelesenen Attribute und/oder die Zusatzinformation168 , damit sich der Nutzer102 von der Richtigkeit dieser Daten überzeugen kann, bevor sie an das Dienst-Computersystem150 zur Durchführung der Transaktion weitergeleitet werden. - - Das Dienst-Computersystem
150 ordnet die empfangene Response174 dem Request166 anhand der übereinstimmenden Kennungen180 des Requests166 und der Response174 zu. - - Das Dienst-Computersystem
150 prüft dann die Signatur der Response166 und liest das oder die erforderlichen Attribute aus der Response174 aus. Anhand der Attribute wird dann geprüft, ob die angeforderte Transaktion durchgeführt werden kann, indem das oder die Attribute mit einem oder mehreren vorgegebenen Kriterien verglichen wird. Bei diesen Kriterien kann es sich zum Beispiel um das Alter oder die Kreditwürdigkeit des Nutzers102 handeln. Bei dem Attribut kann es sich auch um ein Pseudonym des Nutzers102 handeln, mit Hilfe dessen das Dienst-Computersystem150 dann ein in einer Datenbank des Dienst-Computersystems150 gespeichertes Attribut des Nutzers102 , wie zum Beispiel eine Lieferadresse ausliest. Das Prüfkriterium ist hierbei, ob ein Nutzer mit dem in der Response174 beinhalteten Pseudonym seitens des Dienst-Computersystems150 registriert ist. - Beispielsweise handelt es sich bei dem Programm
113 um einen Browser-Plug-in, das in einer Registry eines Betriebssystems des Nutzer-Computersystems mit einer Plug-in-Kennung registriert ist, wobei es sich bei dem Betriebssystem zum Beispiel um ein Windows-Betriebssystem, Android oder iOS handeln kann. In diesem Fall beinhaltet die Nachricht172 von dem ID-Provider-Computersystem an den Internet-Browser112 diese Plug-in-Kennung184 , so dass das Plug-in113 aufgrund des Empfangs der Nachricht gestartet wird. - In einem weiteren Beispiel handelt es sich bei dem Programm
113 ein von dem Internet-Browser112 separates Anwendungsprogramm, wie zum Beispie! eine sogenannte Bürger-App oder Ausweis-App. Dieses Anwendungsprogramm113 wird von dem Internet-Browser112 durch Aufruf einer lokalen URL gestartet, wobei die lokale URL eine fest vorgegebener Portnummer gemäß dem TCP-Protokoll beinhaltet. Diese lokale URL wird zusammen mit der Webseite160 von dem Dienst-Computersystem150 an das Nutzer-Computersystem100 übertragen und zwar über die erste Session201 , um das Starten des Anwendungsprogramms113 mit Hilfe der lokalen URL durch den Internet-Browser112 zu bewirken. - Für den Fall, dass nur das Chiffrat der Zusatzinformation
168 , nicht aber die Zusatzinformation168 selbst über die zweite Session202 von dem Nutzer-Computersystem100 an das ID-Provider-Computersystem136 übertragen wird, beinhaltet auch die Response174 nur dieses Chiffrat, nicht aber die Zusatzinformation168 selbst. In diesem Fall entschlüsselt das Dienst-Computersystem150 das Chiffrat mit Hilfe des privaten Schlüssels des Dienst-Computersystems150 , um dann mit Hilfe der Zusatzinformation168 die angeforderte Transaktion durchzuführen. Hierbei kann es sich zum Beispiel um die Durchführung einer finanziellen Transaktion, wie zum Beispiel die Durchführung einer Überweisung in der Höhe des Bezahlbetrags handeln, der in der Zusatzinformation168 angegeben ist. - Alternativ ist es aber auch möglich, dass die Durchführung der Zahlung seitens des ID-Provider-Computersystems
136 ausgelöst wird. Dies kann so erfolgen, dass das ID-Provider-Computersystem136 die hierfür erforderlichen Transaktionsdaten über den Request166 und die Zusatzinformationen168 empfängt und dann die Zahlung durchführt oder veranlasst. Die Response174 beinhaltet dann eine Bestätigung des ID-Provider-Computersystems136 , dass die Zahlung erfolgt ist. - Eine Übermittlung der Zusatzinformation
168 an das Dienst-Computersystem150 kann dann unterbleiben, was zum Schutz der Vertraulichkeit dieser Zusatzinformationen168 vorteilhaft ist, denn diese Zusatzinformationen168 müssen dann nur gegenüber dem vertrauenswürdigen ID-Provider-Computersystem136 offengelegt werden. Die eigentliche Transaktion, z.B. die Lieferung des bestellten Produkts, wird dann nach Empfang der Zahlungsbestätigung, die in der Response174 beinhaltet ist, von dem Dienst-Computersystem150 veranlasst. - Beispielsweise beinhaltet die Zusatzinformation
168 ein OTP. Das Dienst-Computersystem150 prüft dann als zusätzliche Voraussetzung für die Durchführung der Transaktion, ob das OTP gültig ist. Vorzugsweise wird das OTP durch das Nutzer-Computersystem100 mit dem öffentlichen Schlüssel des Dienst-Computersystems150 verschlüsselt und dann von dem Dienst-Computersystems150 nach dem Empfang der Zusatzinformation mit dem verschlüsselten OTP entschlüsselt, um dann dessen Validität zu prüfen. - Zu dem Computersystem gehört ein Terminal
186 , bei dem es sich zum Beispiel um einen Automat, insbesondere einen Bankautomat oder Verkaufsautomat, handeln kann. Beispielsweise kann der Nutzer102 in das Terminal186 einen Geldbetrag eingeben, um Bargeld von seinem Konto abzuheben. Auf einem Display188 des Automat wird dann ein optisch erfassbares Muster angezeigt, wie zum Beispiel ein QR-Code, der ein URL des Dienst-Computersystems150 sowie den von dem Nutzer102 gewünschten Geldbetrag beinhaltet. - Dieses optische Muster wird von dem Display
188 mit Hilfe einer Kamera190 des Nutzer-Computersystems100 erfasst. Das Nutzer-Computersystem100 erzeugt dann die Transaktionsanforderung158 , die diesen Geldbetrag angibt. Die erste Session201 wird hier mit Hilfe der aus dem optischen Muster erfassten URL des Dienst-Computersystems150 aufgebaut und die Transaktionsanforderung158 mit dem gewünschten Geldbetrag wird über diese erste Session201 an das Dienst-Computersystem150 übermittelt. Das Dienst-Computersystem150 erzeugt dann einen entsprechenden Request166 , um die für die Auszahlung des gewünschten Geldbetrags erforderlichen Attribute und Zusatzinformationen168 abzufragen. - Dann wird entweder durch das ID-Provider-Computersystem
136 oder durch das Dienst-Computersystem150 die Belastung eines Kontos des Nutzers102 , welches dieser zum Beispiel in der Zusatzinformation168 angegeben hat, veranlasst. Aufgrund des Empfangs der Response174 und der Veranlassung der Zahlung empfängt dann das Terminal186 ein Signal zur Ausgabe des gewünschten Geldbetrags zum Beispiel in Form von Bargeld oder zur Aufladung einer Cash-Card des Nutzers102 . Dies kann so erfolgen, dass das Terminal186 unmittelbar mit dem Dienst-Computersystem150 verbunden ist oder über das Netzwerk116 . - Alternativ kann es sich bei dem Terminal
186 auch um einen Verkaufsautomat handeln, wobei dann kein Bargeld, sondern ein gewünschtes Produkt, wie zum Beispiel eine Getränkedose oder eine Zigarettenschachtel von dem Verkaufsautomaten abgegeben wird, nachdem die Durchführung der Zahlung von dem Dienst-Computersystem150 signalisiert worden ist. - In einer weiteren Anwendung kann es sich bei dem Terminal
186 um ein mobiles Telekommunikationsgerät, insbesondere ein Smartphone handeln. Wenn der Nutzer102 von dem Inhaber des Terminals186 etwas kaufen möchte, so gibt der Inhaber des Terminals186 den entsprechenden Kaufpreis in das Terminal186 ein, so dass dann auf dem Display188 in Form des optisch erfassbaren Musters wiederum dieser Kaufpreis als Bezahlbetrag sowie die URL des Dienst-Computersystems150 ausgegeben wird. Nach Beendigung der Transaktion empfängt das Terminal186 von dem Dienst-Computersystem150 ein Signal, welches anzeigt, dass der Bezahlvorgang erfolgt ist und der Inhaber des Terminals186 gibt dann die Ware an den Nutzer102 ab. Dies kann auch in dem Kassensystem zum Beispiel eines Supermarkts implementiert sein. Eine weitere Anwendung ist ein Taxameter, welches Taxigebühren erfasst oder ein anderer Verbrauchszähler, wie zum Beispiel ein Verbrauchszähler für den Strom- oder Gasverbrauch eines Haushalts, insbesondere ein sog. Smartmeter. - Bezugszeichenliste
-
- 100
- Nutzer-Computersystem
- 102
- Nutzer
- 104
- Schnittstelle
- 106
- ID-Token
- 108
- Schnittstelle
- 110
- Prozessor
- 112
- Anwendungsprogramm/Internet-Browser
- 113
- Programm/Anwendungsprogramm
- 114
- Netzwerk-Schnittstelle
- 116
- Netzwerk
- 118
- elektronischer Speicher
- 120
- geschützter Speicherbereich
- 122
- geschützter Speicherbereich
- 124
- geschützter Speicherbereich
- 126
- Speicherbereich
- 128
- Prozessor
- 130
- Programminstruktionen
- 132
- Programminstruktionen
- 134
- Programminstruktionen
- 136
- ID-Provider-Computersystem
- 138
- Netzwerk-Schnittstelle
- 140
- Speicher
- 141
- geschützter Speicherbereich
- 142
- privater Schlüssel
- 144
- Zertifikat
- 145
- Prozessor
- 146
- Programminstruktionen
- 148
- Programminstruktionen
- 150
- Dienst-Computersystem
- 152
- Netzwerk-Schnittstelle
- 154
- Prozessor
- 156
- Programminstruktionen
- 158
- Transaktionsanforderung
- 160
- Webseite
- 162
- Eingabefeld
- 164
- Eingabeelement
- 166
- Request
- 168
- Zusatzinformation
- 170
- Programminstruktionen
- 172
- Nachricht
- 174
- Response
- 176
- lokale Verbindung
- 178
- Programminstruktionen
- 180
- Kennung
- 182
- Lesekommando
- 184
- Kennung
- 186
- Terminal
- 188
- Display
- 190
- Kamera
Claims (16)
- Elektronisches Transaktionsverfahren unter Verwendung eines ID-Tokens (106), der einem Nutzer (102) zugeordnet ist, wobei der ID-Token einen elektronischen Speicher (118) mit einem geschützten Speicherbereich (124) aufweist, in dem ein oder mehrere Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor (128) des ID-Tokens möglich ist, und wobei der ID-Token eine Kommunikations-Schnittstelle (108) zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems (100) aufweist, mit folgenden Schritten: - Anzeige eines optisch lesbaren Musters auf einem Bildschirm (188) eines Terminals (186), wobei in dem optisch lesbaren Muster eine Information codiert ist, die zumindest eine logische Adresse eines Dienst-Computersystems (150) und Transaktionsdaten beinhaltet, - Erfassung des Musters mithilfe eines optischen Sensors (190) des Nutzer-Computersystems und Decodierung des Musters durch das Nutzer-Computersystem, - Übertragung einer Transaktionsanforderung (158) von dem Nutzer-Computersystem an die logische Adresse des Dienst-Computersystems über das Netzwerk, wobei die Transaktionsanforderung die Transaktionsdaten beinhaltet, - Übertragung eines Request (166) von dem Dienst-Computersystem über das Nutzer-Computersystems (100) an ein ID-Provider-Computersystem (136), wobei die Übertragung über das Netzwerk erfolgt, wobei der Request eine Attributspezifikation der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute beinhaltet, - Authentifizierung des Nutzers gegenüber dem ID-Token, - Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk, - unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers und des ID-Provider-Computersystems gegenüber dem ID-Token, Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider-Computersystem aus dem ID-Token über das Netzwerk mit Ende-zu-Ende-Verschlüsselung, - Übertragung einer Response (174) von dem ID-Provider-Computersystem über das Nutzer-Computersystem an das Dienst-Computersystem, wobei die Übertragung der Response über das Netzwerk erfolgt, wobei die Response das oder die ausgelesenen Attribute beinhaltet, und wobei die Response von dem ID-Provider-Computersystem signiert ist, - Durchführung der Transaktion mithilfe der Transaktionsdaten und des oder der Attribute durch das Dienst-Computersystem, wobei die Transaktionsdaten einen Zahlungsbetrag beinhalten und wobei die Transaktion von dem Dienst-Computersystem initiiert wird, um eine finanzielle Transaktion in Höhe des Zahlungsbetrags durchzuführen, wobei es sich bei dem Terminal um einen Verkaufsautomat handelt, wobei es sich bei dem Zahlungsbetrag um einen Verkaufspreis für ein von dem Verkaufsautomat abgebbares Produkt handelt, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um ein Konto des Benutzers in Höhe des Zahlungsbetrags zu belasten, woraufhin das Dienst-Computersystem ein Bestätigungssignal an den Verkaufsautomat überträgt, und der Verkaufsautomat aufgrund des Empfangs des Bestätigungssignals das Produkt abgibt.
- Verfahren nach
Anspruch 1 , mit dem weiteren Schritt der Prüfung, ob das oder die Attribute ein vorgegebenes Kriterium erfüllen durch das Dienst-Computersystem, wobei die Transaktion nur durchgeführt wird, wenn das Kriterium erfüllt ist. - Verfahren nach einem der vorhergehenden Ansprüche, wobei das Bestätigungssignal über das Netzwerk von dem Dienst-Computersystem gesendet wird.
- Verfahren nach
Anspruch 3 , wobei das Bestätigungssignal an das Nutzer-Computersystem gesendet und von dem Nutzer-Computersystem als optisches Muster ausgegeben wird, wobei das Terminal zur Erfassung des optischen Musters von dem Nutzer-Computersystem ausgebildet ist. - Verfahren nach einem der vorhergehenden Ansprüche, mit folgenden Schritten: - Aufbau einer ersten Session (201) zwischen einem Anwendungsprogramm (112) des Nutzer-Computersystems und dem Dienst-Computersystem (150) über das Netzwerk (116), - Empfang der Transaktionsanforderung (158) über die erste Session durch das Dienst-Computersystem von dem Anwendungsprogramm (112), - Erzeugung eines Request (166) durch das Dienst-Computersystem aufgrund des Empfangs der Transaktionsanforderung, wobei der Request von dem Dienst-Computersystem signiert wird und der Request eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute, Transaktionsdaten zur Spezifizierung der Transaktion, eine Kennung (180) des Request, eine URL eines ID-Provider-Computersystems und eine URL des Dienst-Computersystems beinhaltet, - Übertragung einer Webseite (160) und des Request über die erste Session von dem Dienst-Computersystem an das Nutzer-Computersystem, wobei die Webseite ein Eingabefeld (162) zur Eingabe einer Zusatzinformation (168) für die Durchführung der Transaktion aufweist, - Anzeige der Webseite durch das Anwendungsprogramm und Eingabe der Zusatzinformation durch den Nutzer in das Eingabefeld, - Aufbau einer zweiten Session (202) zwischen dem Anwendungsprogramm (112) und dem ID-Provider-Computersystem über das Netzwerk mithilfe der URL des ID-Provider-Computersystems, wobei die zweite Session mit einem gesicherten Transportlayer aufgebaut wird, - Weiterleitung des Request und der Zusatzinformation von dem Anwendungsprogramm an das ID-Provider-Computersystem über die zweite Session, - aufgrund des Empfangs des Request, Erzeugung einer Session-ID für eine dritte Session (203) durch das ID-Provider-Computersystem und Speicherung des Request sowie der Zusatzinformation durch das ID-Provider-Computersystem, - Senden einer Nachricht von dem ID-Provider-Computersystem an das Anwendungsprogramm (112) mit der Session-ID der dritten Session und einer logischen Adresse über die zweite Session, - Aufbau der dritten Session zwischen einem Programm (113) des Nutzer-Computersystems und dem ID-Provider-Computersystem über den gesicherten Transportlayer der zweiten Session, wobei das Programm von dem Anwendungsprogramm (112) verschieden sein kann, - Übertragung zumindest eines Zertifikats (144) des ID-Provider-Computersystems an das Programm (113), wobei das Zertifikat eine Angabe von Leserechten des ID-Provider-Computersystems zum Lesen von einem oder mehreren der in dem ID-Token gespeicherten Attribute beinhaltet, wobei die Übertragung des Zertifikats über die dritte Session erfolgt, - Prüfung durch das Programm (113), ob die in dem Zertifikat angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-Computersystems auf das oder die gemäß der Attributspezifikation zu lesenden Attribute zu zulassen, und nur wenn die Leserechte ausreichend sind: a) Aufbau einer lokalen Verbindung (176) zwischen dem Lesegerät des Nutzer-Computersystems und dem ID-Token, b) Authentifizierung des Nutzers gegenüber dem ID-Token, wobei ein Session-Key vereinbart wird, c) Aufbau einer vierten Session (204) zwischen dem ID-Token und dem ID-Provider-Computersystem über die lokale Verbindung und die dritte Session mit einer Ende-zu-Ende Verschlüsselung mithilfe des Session-Key, d) Gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems über die vierte Session, e) Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider-Computersystem über die vierte Session aus dem ID-Token. - Erzeugung der Response (174), die das oder die ausgelesenen Attribute und zumindest die Kennung (180) des Request beinhaltet, und die von dem ID-Provider-Computersystem signiert wird, - Speicherung der Response zum Abrufen mit Hilfe der logischen Adresse, - Lesen der Response von dem ID-Provider-Computersystem durch das Nutzer-Computersystem durch Abruf der Response mittels eines Lesekommandos von der logischen Adresse über das Netzwerk, - Weiterleitung der Response durch das Nutzer-Computersystem über die erste Session an das Dienst-Computersystem, - Zuordnung der Response zu dem Request mit Hilfe der Kennung, die in der Response beinhaltet ist, durch das Dienst-Computersystem, - Durchführung der Transaktion mithilfe der Response durch das ID-Provider-Computersystem.
- Verfahren nach
Anspruch 5 , wobei es sich bei dem Anwendungsprogramm um einen Internetbrowser handelt, und das weitere Programm ein Plug-in des Internetbrowsers ist, wobei das Plug-in in einer Registry eines Betriebssystems des Nutzer-Computersystems mit einer Plug-in-Kennung (184) registriert ist, wobei die Nachricht von dem ID-Provider-Computersystem an den Internetbrowser die Plug-in-Kennung beinhaltet, sodass das Plug-in aufgrund des Empfangs der Nachricht gestartet wird. - Verfahren nach
Anspruch 5 oder6 , wobei es sich bei dem Programm um ein weiteres Anwendungsprogramm handelt, welches von dem Internetbrowser durch einen Aufruf einer lokalen URL gestartet werden kann, wobei die lokale URL eine fest vorgegebene Portnummer gemäß dem TCP-Protokoll beinhaltet, wobei die lokale URL zusammen mit der Webseite von dem Dienst-Computersystem an das Nutzer-Computersystem übertragen wird, um das Starten des weiteren Anwendungsprogramms mithilfe der lokalen URL durch den Internetbrowser zu bewirken. - Verfahren nach
Anspruch 5 ,6 oder7 , wobei es sich bei der Zusatzinformation um eine Bezahlinformation des Nutzers handelt. - Verfahren nach
Anspruch 8 , wobei die Zusatzinformation durch das Nutzer-Computersystem mithilfe des öffentlichen Schlüssels des Dienst-Computersystems verschlüsselt wird und nur die verschlüsselte Zusatzinformation an das ID-Provider-Computersystem über die zweite Session weitergeleitet wird, wobei die verschlüsselte Zusatzinformation in die Response eingeht und die verschlüsselte Zusatzinformation nach Empfang der Response durch das Dienst-Computersystem mithilfe des privaten Schlüssels des Dienst-Computersystems entschlüsselt wird. - Verfahren nach einem der vorhergehenden
Ansprüche 5 bis9 , wobei der Request eine Bezahlinformation des Dienst-Computersystems beinhaltet und wobei die Zusatzinformation eine Bezahlinformation des Nutzers beinhaltet, und wobei die Transaktionsdaten des Request einen Zahlungsbetrag beinhalten, wobei die Zahlung durch das ID-Provider-Computersystem veranlasst wird, und die Response nicht die Bezahlinformation des Nutzers beinhaltet. - Verfahren nach einem der vorhergehenden
Ansprüche 5 bis10 , wobei der Request eine Bezahlinformation des Dienst-Computersystems beinhaltet und wobei die Zusatzinformation eine Bezahlinformation des Nutzers beinhaltet, und wobei die Transaktionsdaten des Request einen Zahlungsbetrag beinhalten, wobei die Zahlung durch das Dienst-Computersystem veranlasst wird, und die Response die mit dem öffentlichen Schlüssel des Dienstcomputersystems verschlüsselte Bezahlinformation des Nutzers beinhaltet. - Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem Muster um einen eindimensionalen, zweidimensionalen, High Capacity Color Barcode, Maxicode, QR-Code oder Data Matrix-Code oder eine zeitliche Reihenfolge mehrerer solcher Codes handelt.
- Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem ID-Token um ein Wert- oder Sicherheitsdokument handelt.
- Verfahren nach einem der vorhergehenden Ansprüche, wobei die Response auch die Zusatzinformationen beinhaltet.
- Verfahren nach
Anspruch 14 , wobei die Zusatzinformation ein OTP beinhaltet und das Dienst-Computersystem (150) die Validität des OTP prüft, wobei die Transaktion nur durchgeführt wird, wenn das OTP valide ist. - Computersystem mit einem Terminal (186), einem Dienst-Computersystem (150), einem Nutzer-Computersystem (100) einem ID-Provider-Computersystem (136) und einem ID-Token (106), der einem Nutzer (102) zugeordnet ist, wobei der ID-Token einen elektronischen Speicher (118) mit einem geschützten Speicherbereich (124) aufweist, in dem ein oder mehrere Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor (128) des ID-Tokens möglich ist, und wobei der ID-Token eine Kommunikations-Schnittstelle (108) zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems (100) aufweist, wobei der Terminal, das Dienst-Computersystem, das Nutzer-Computersystem, das ID-Provider-Computersystem und der ID-Token zur Durchführung der folgenden Schritte ausgebildet sind: - Anzeige eines optisch lesbaren Musters auf einem Bildschirm (188) eines Terminals (186), wobei in dem optisch lesbaren Muster eine Information codiert ist, die zumindest eine logische Adresse eines Dienst-Computersystems (150) und Transaktionsdaten beinhaltet, - Erfassung des Musters mithilfe eines optischen Sensors (190) des Nutzer-Computersystems und Decodierung des Musters durch das Nutzer-Computersystem, - Übertragung einer Transaktionsanforderung (158) von dem Nutzer-Computersystem an die logische Adresse des Dienst-Computersystems über das Netzwerk, wobei die Transaktionsanforderung die Transaktionsdaten beinhaltet, - Übertragung eines Request (166) von dem Dienst-Computersystem über das Nutzer-Computersystems (100) an ein ID-Provider-Computersystem (136), wobei die Übertragung über das Netzwerk erfolgt, wobei der Request eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute beinhaltet, - Authentifizierung des Nutzers gegenüber dem ID-Token, - Authentifizierung des ID-Provider-Computersystems gegenüber dem ID-Token über das Netzwerk, - unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers und des ID-Provider-Computersystems gegenüber dem ID-Token, Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider-Computersystem aus dem ID-Token über das Netzwerk mit Ende-zu-Ende-Verschlüsselung, - Übertragung einer Response (174) von dem ID-Provider-Computersystem über das Nutzer-Computersystem an das Dienst-Computersystem, wobei die Übertragung der Response über das Netzwerk erfolgt, wobei die Response das oder die ausgelesenen Attribute beinhaltet, und wobei die Response von dem ID-Provider-Computersystem signiert ist, - Durchführung der Transaktion mithilfe der Transaktionsdaten und des oder der Attribute durch das Dienst-Computersystem, wobei die Transaktionsdaten einen Zahlungsbetrag beinhalten und wobei die Transaktion von dem Dienst-Computersystem initiiert wird, um eine finanzielle Transaktion in Höhe des Zahlungsbetrags durchzuführen, wobei es sich bei dem Terminal um einen Verkaufsautomat handelt, wobei es sich bei dem Zahlungsbetrag um einen Verkaufspreis für ein von dem Verkaufsautomat abgebbares Produkt handelt, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um ein Konto des Benutzers in Höhe des Zahlungsbetrags zu belasten, woraufhin das Dienst-Computersystem ein Bestätigungssignal an den Verkaufsautomat überträgt, und der Verkaufsautomat aufgrund des Empfangs des Bestätigungssignals das Produkt abgibt.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102013212646.8A DE102013212646B4 (de) | 2013-06-28 | 2013-06-28 | Elektronisches Transaktionsverfahren und Computersystem |
EP14726573.0A EP3014540A1 (de) | 2013-06-28 | 2014-05-22 | Elektronisches transaktionsverfahren und computersystem |
PCT/EP2014/060540 WO2014206659A1 (de) | 2013-06-28 | 2014-05-22 | Elektronisches transaktionsverfahren und computersystem |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
DE102013212646.8A DE102013212646B4 (de) | 2013-06-28 | 2013-06-28 | Elektronisches Transaktionsverfahren und Computersystem |
Publications (2)
Publication Number | Publication Date |
---|---|
DE102013212646A1 DE102013212646A1 (de) | 2014-12-31 |
DE102013212646B4 true DE102013212646B4 (de) | 2018-11-22 |
Family
ID=50828891
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
DE102013212646.8A Active DE102013212646B4 (de) | 2013-06-28 | 2013-06-28 | Elektronisches Transaktionsverfahren und Computersystem |
Country Status (3)
Country | Link |
---|---|
EP (1) | EP3014540A1 (de) |
DE (1) | DE102013212646B4 (de) |
WO (1) | WO2014206659A1 (de) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102016117134A1 (de) | 2016-09-13 | 2018-03-15 | Martin Schwemmer | Verfahren zum bargeldlosen Bezahlen an einem Bezahlterminal und Bezahlterminal |
CN106875162B (zh) * | 2016-12-30 | 2020-12-04 | 朗新科技集团股份有限公司 | 数据抓取方法、数据抓取装置、软收银对接接口及终端 |
CN111192036B (zh) * | 2019-08-01 | 2023-06-20 | 腾讯科技(深圳)有限公司 | 账号资源更新方法、装置、计算机设备以及存储介质 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030120555A1 (en) | 2000-03-09 | 2003-06-26 | Takashi Kitagawa | Information processing apparatus with optical data reader, servers, and electronic commerce method |
DE102011082101A1 (de) | 2011-09-02 | 2013-03-07 | Bundesdruckerei Gmbh | Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2005115665A (ja) * | 2003-10-08 | 2005-04-28 | Oki Electric Ind Co Ltd | 自動取引装置情報提供システム |
DE102008000067C5 (de) * | 2008-01-16 | 2012-10-25 | Bundesdruckerei Gmbh | Verfahren zum Lesen von Attributen aus einem ID-Token |
AU2011348061B2 (en) * | 2010-12-23 | 2015-12-10 | Paypal, Inc. | Mobile phone atm processing methods and systems |
DE102011089580B3 (de) * | 2011-12-22 | 2013-04-25 | AGETO Innovation GmbH | Verfahren zum Lesen von Attributen aus einem ID-Token |
-
2013
- 2013-06-28 DE DE102013212646.8A patent/DE102013212646B4/de active Active
-
2014
- 2014-05-22 EP EP14726573.0A patent/EP3014540A1/de active Pending
- 2014-05-22 WO PCT/EP2014/060540 patent/WO2014206659A1/de active Application Filing
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030120555A1 (en) | 2000-03-09 | 2003-06-26 | Takashi Kitagawa | Information processing apparatus with optical data reader, servers, and electronic commerce method |
DE102011082101A1 (de) | 2011-09-02 | 2013-03-07 | Bundesdruckerei Gmbh | Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem |
Non-Patent Citations (3)
Title |
---|
BSI TR-03130, Technische Richtlinie eID-Server. Bundesamt für Sicherheit in der Informationstechnik, Ver. 1.6, 20.04.2012, Seiten 1-100 * |
Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents - EAC, PACE, RI. Bundesamt für Sicherheit in der Informationstechnik, Ver. 2.05, 14.10.2010, Seiten 1-111 * |
Technical Guideline TR-03112-7 eCard-API-Framework - Protocols. Bundesamt für Sicherheit in der Informationstechnik, Ver. 1.1.2, 28.2.2012, Seiten 1-98 * |
Also Published As
Publication number | Publication date |
---|---|
WO2014206659A1 (de) | 2014-12-31 |
EP3014540A1 (de) | 2016-05-04 |
DE102013212646A1 (de) | 2014-12-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2949094B1 (de) | Verfahren zur authentisierung eines nutzers gegenüber einem automat | |
DE102011082101B4 (de) | Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem | |
DE102012219618B4 (de) | Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem | |
EP3089061B1 (de) | Verfahren zum lesen von attributen aus einem id-token | |
EP2454703B1 (de) | Verfahren zum lesen von attributen aus einem id-token | |
EP2454705B1 (de) | Verfahren zum lesen von attributen aus einem id-token und one-time passwort generator | |
EP2817758B1 (de) | Computerimplementiertes bezahlverfahren | |
DE102013212627B4 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013212646B4 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
EP2879073B1 (de) | Elektronisches transaktionsverfahren und computersystem | |
EP2752785B1 (de) | Verfahren zur Personalisierung eines Secure Elements (SE) und Computersystem | |
DE102013022436B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022434B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022433B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
EP2916252B1 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
EP2893483B1 (de) | Verfahren zur personalisierung eines secure elements (se) und computersystem | |
DE102013022445B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022438B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022447B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
EP2819079B1 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022435B3 (de) | Elektronisches Transaktionsverfahren und Computersystem | |
DE102013022448B3 (de) | Elektronisches Transaktionsverfahren und Computersystem |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
R012 | Request for examination validly filed | ||
R016 | Response to examination communication | ||
R130 | Divisional application to |
Ref document number: 102013022447 Country of ref document: DE Ref document number: 102013022443 Country of ref document: DE Ref document number: 102013022444 Country of ref document: DE Ref document number: 102013022446 Country of ref document: DE Ref document number: 102013022437 Country of ref document: DE Ref document number: 102013022436 Country of ref document: DE Ref document number: 102013022438 Country of ref document: DE Ref document number: 102013022445 Country of ref document: DE Ref document number: 102013022441 Country of ref document: DE |
|
R018 | Grant decision by examination section/examining division | ||
R020 | Patent grant now final |