EP2820600A1 - Authentisierte transaktionsfreigabe - Google Patents

Authentisierte transaktionsfreigabe

Info

Publication number
EP2820600A1
EP2820600A1 EP13707816.8A EP13707816A EP2820600A1 EP 2820600 A1 EP2820600 A1 EP 2820600A1 EP 13707816 A EP13707816 A EP 13707816A EP 2820600 A1 EP2820600 A1 EP 2820600A1
Authority
EP
European Patent Office
Prior art keywords
terminal
transaction
authentication
electronic
document
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.)
Ceased
Application number
EP13707816.8A
Other languages
English (en)
French (fr)
Inventor
Helmut Scherzer
Hermann Sterzinger
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.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient GmbH
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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP2820600A1 publication Critical patent/EP2820600A1/de
Ceased legal-status Critical Current

Links

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/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
    • 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/3278—RFID or NFC 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/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/352—Contactless payments by cards
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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
    • 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/12—Card verification
    • G07F7/122—Online card verification

Definitions

  • the invention relates to a method for the authenticated release of an electronic transaction.
  • a transaction record is provided and displayed on the PC or terminal, through which the transaction is described.
  • the transaction record includes, for example, a destination account to which a monetary amount is to be transferred and the amount of money to be transferred.
  • the user checks the displayed transaction record and makes an input on approval at the PC or terminal, whereby the transaction is confirmed.
  • EP 0 986 275 B1 describes a transaction method for delivery from a service provider to a customer in which order data containing a monetary amount is transmitted to a validation platform by way of short messages and verification of the order data by the validation platform the amount of money is deducted from a cash account of the customer and transferred to a money account of the service provider.
  • authentication is generally additionally required, for example by entering a PIN (personal identification number) or TAN (transaction number) on the PC or terminal.
  • PIN personal identification number
  • TAN transaction number
  • a PIN must be remembered by the user and is therefore often forgotten or handled lightly, e.g. spotted out.
  • the use of a TAN for authentication is much more secure than a PIN.
  • the management of a reliable TAN system is complex.
  • DE 10 2005 003 647 A1 discloses an identification system in which the electronic memory of an electronic identification document (e.g., electronic passport) is accessed by means of a separate authorization document, e.g. an additional card with authorization data.
  • Electronic identification documents such as electronic passports or electronic identity cards such as the new German ID card, have a chip and a contactless interface (e.g., NFC antenna) through which electronic communication with the chip is possible.
  • ARM Trustzone Architecture Under the name ARM Trustzone Architecture a two-part runtime architecture of the company ARM for a microprocessor system is known, which includes two run time environments. A first, “Normal Zone” or “Normal World” called insecure runtime environment is by a Nor- mal operating system controlled. A second "trust zone” or “trusted world” or “secure world” secure or trusted runtime environment is controlled by a security operating system The normal operating system may be, for example, a common operating system such as Android, Windows Phone, Symbian or the like.
  • a security operating system for chips to be implemented in mobile terminals is manufactured and sold under the trade name MOBICORE.
  • WO 2004/053807 AI describes a payment system by means of a dual-slot mobile phone with two smart cards, namely a conventional SIM card for wireless operation and additionally a certificate chip card for transaction confirmation for payment transactions.
  • the certificate chip card contains identification data with which a certificate personalized to a user can be created.
  • an encrypted and signed data packet is generated from transaction data and sent with the mobile phone to a clearing center. This will release the transaction.
  • WO 2004/053807 AI describes a payment system by means of a dual-slot mobile phone with two smart cards, namely a conventional SIM card for wireless operation and additionally a certificate chip card for transaction confirmation for payment transactions.
  • the certificate chip card contains identification data with which a certificate personalized to a user can be created.
  • an encrypted and signed data packet is generated from transaction data and sent with the mobile phone to a clearing center. This will release the transaction.
  • WO 2004/053807 AI describes a payment system by means of a dual-slot mobile phone with two smart cards, namely a conventional SIM card
  • AI manipulation security is sought by the fact that the certification card is contact-based operated directly in the terminal.
  • the invention is based on the object of providing a user-friendly, universally applicable and reliable method for the authenticated release of an electronic transaction.
  • the object is achieved by a method according to claim 1.
  • Advantageous embodiments of the invention are specified in the dependent claims.
  • the inventive method is provided for authenticated release of an electronic transaction.
  • the transaction is completely or partially marked by a transaction record.
  • the transaction record can be complete from the beginning or can be supplemented or extended during the course of the procedure (see below).
  • the transaction is released by means of an electronic terminal to a transaction partner computer, eg a transaction server, which stands for example at a bank or a clearing center or the like.
  • a transaction partner computer eg a transaction server, which stands for example at a bank or a clearing center or the like.
  • the method provides: a transaction record obtained from the transaction partner at the terminal; requested a release of the transaction at the terminal; and at the terminal an authentication date accepted for authentication and causes the authenticated release of the transaction by the authentication date is provided for forwarding to the transaction partner.
  • the authentication date is finally forwarded to the transaction partner, eg transaction server, and usually the transaction record as well.
  • the transaction server performs the transaction or at least initiates the transaction.
  • the method is characterized in that the authentication date is provided in electronic form to the terminal via an electronic connection from a separate from the terminal, structurally independent of the terminal electronic authentication document, which is paired with the terminal.
  • the authentication document and the end device are paired with each other so that the release of the transaction is possible with a paired with the terminal authentication document and that the release of the transaction with an unpaired with the terminal authentication document is not possible.
  • the release of the transaction is secured by an authentication.
  • the authentication document can be operated independently of the terminal, the terminal and the authentication document do not have to be structurally coordinated with one another, as is required, for example, as in the solution from WO 2004/053807 A1.
  • the pairing between the terminal and the authentication document ensures that, despite the independence between the terminal and the authentication document, potentially manipulated, unauthorized authentication documents do not receive any releasing access to the terminal. The user of the terminal and authentication document thus retains the power to release the transaction.
  • the method of claim 1 is considerably more user friendly.
  • a user-friendly, universally applicable and reliable method for the authenticated release of an electronic transaction is provided.
  • a transaction partner computer instead of the already explicitly mentioned transaction server alternatively another / further mobile device may be provided, the transaction confirmation is thus carried out via a peer-to-peer connection between basically equal mobile devices as transaction partners.
  • the pairing is achieved, for example, by storing a characteristic date for the authentication document in the terminal.
  • the pairing is generated, for example, in an upstream initialization step, in which the characteristic date from the authentication document is stored in the terminal.
  • the characteristic date for example, a unique serial number of the authentication document or the like is used, or a (cryptographic) check sum over such a serial number or the like.
  • the ID card number or a (cryptographic) checksum via the ID card number is used as the characteristic date.
  • a checksum is used and not the serial number or identity card number in plain text.
  • the mobile device in a secure environment performs a certificate exchange with the ID card and thus is able to build only with this later a secure channel.
  • the release for such an exchange can be made by entering a PIN with identity card (once).
  • a cryptographic signature generated via the transaction data record is optionally used as the authentication date.
  • the authentication date is generated in the authentication document.
  • a cryptographic signature on the transaction record is more accurately generated as an authentication date.
  • a contactless connection in particular NFC connection, is used as the electronic connection.
  • the transaction data record is transmitted via the electronic connection from the terminal to the authentication document.
  • the generated authentication date eg the signature
  • the transmitted transaction record is stored in the authentication document, optionally volatile, e.g. only to generate the authentication date, e.g. Signature, optional non-volatile.
  • Non-volatile storage makes it possible to continue the transaction later after a temporary failure of the power supply to the terminal.
  • the transaction record stored in the authentication document is deleted from the authentication document again after the authentication date has been provided from the authentication document to the terminal.
  • the authentication date, e.g. Signature also stored in the authentication document (non-volatile) and deleted after transmission to the terminal again.
  • Non-volatile storage and again deletion of transaction data record and authentication date (for example signature) in the authentication document after transmission to the terminal makes the method particularly suitable for ticketing.
  • the deletion corresponds to a validation of the ticket.
  • an electronic identification document is used as the authentication document, in particular an electronic identity card or passport, in particular with a microprocessor and signature function. place, such as the so-called new German identity card nPA.
  • An electronic identification document, in particular identity card is particularly preferred as an authentication document, since the user usually carries it with him anyway.
  • an authentication document in the form of an identification document makes it possible to simply supplement the transaction data record with additional data (see below) in order to facilitate the handling for the user.
  • the transaction record is extended or supplemented by additional data stored in the authentication document.
  • the addition can be made either in the terminal or in Authentif ikations punct.
  • the additional data is transmitted to the terminal and the transaction record in the terminal is supplemented or extended.
  • the transaction data record is transmitted to the authentication document without the additional data and the supplement or extension is carried out there.
  • person-specific data such as e.g. Name and address of the transaction participant to be released, which releases the transaction.
  • an electronic identification document of the releasing transaction participant is provided as the authentication document, this already contains its name and address. Additional data such as Name and address can therefore be automatically included in the transaction record.
  • the terminal is optionally selected from the group of terminals comprising: mobile terminal including in particular mobile phone, smart phone; Computers, in particular desktop computers, notebooks, netbooks; Tablet PC with or without mobile phone interface.
  • mobile terminal including in particular mobile phone, smart phone; Computers, in particular desktop computers, notebooks, netbooks; Tablet PC with or without mobile phone interface.
  • a mobile terminal such as
  • the terminal optionally comprises a secure runtime environment, for example, in a mobile terminal, the trust zone of a Mobicore security operating system of the Applicant of the present patent application.
  • the electronic connection between the authentication document and the terminal is operated at the terminal in the secure runtime environment. This ensures that the pairing remains set to the selected authentication document and can not or can not easily be changed to another authentication document.
  • a payment transaction is provided as a transaction, wherein the transaction record comprises at least one payee and / or one payment amount.
  • a vote reconciliation transaction wherein the transaction record comprises at least one selected election proposal to be elected.
  • the pairing between the terminal and the authentication document is optionally further checked and the release of the transaction is prevented or aborted if, according to the check, the terminal and the authentication document are not paired with one another. This situation can occur if a wrong authentication document or device is used.
  • a user input is accepted at the terminal.
  • the transaction (eg ticket) is transferred to a server (eg the service provider) to use the nPA (authentication document) for identification of the stored transaction in a subsequent verification and failed mobile device (battery empty) and thus a verification to perform the transaction despite a failed mobile device.
  • a server eg the service provider
  • nPA authentication document
  • the method is thus designed in two stages.
  • transaction data of a transaction data record is displayed on the terminal, and a user confirms by an input on the terminal the transaction data displayed on the terminal, for example by keyboard input or input on a touch pad or touch screen display.
  • the authentication date is operated via an electronic connection from a terminal that can be operated independently of the terminal. ren electronic authentication document, which is paired with the terminal, provided in electronic form to the terminal.
  • the authentication date is provided from the electronic authentication document to the terminal that the authentication document is approximated to the terminal, in particular in accordance with a predetermined movement pattern (Gesture) is approximated to the terminal.
  • a confirmation of the transaction data record can be effected by user input in order to prevent unwanted confirmation of transac- tion occurring as a result of a random approach of the authentication document (for example identity card).
  • the user approaches the authentication document to the terminal.
  • the transaction record which is optionally supplemented or extended by additional data, is transmitted from the terminal to the authentication document for signature generation and / or optionally supplemented or extended in the authentication document with additional data.
  • the cryptographic signature is generated in the authentication document.
  • the signature generated in the authentication document is transmitted back to the terminal.
  • a necessary opening mechanism (eg PIN) for the authentication document (eg nPA) can be securely stored on the mobile phone so that a PIN entry required for accessing the authentication document (eg nPA) may not have to be explicitly performed by the user, but instead If necessary, the PIN is transmitted directly, without user intervention, from the mobile phone to the authentication document.
  • FIG. 1 shows a system for illustrating the invention, with a mobile terminal, an electronic identity card and a transaction server;
  • FIG. 2 is a flowchart of a transaction release transaction according to an embodiment of the invention.
  • Fig. 1 shows a system for illustrating the invention, with a mobile terminal 10, an electronic identity card 20 as an authentication document 20 and a transaction server 30.
  • a characteristic date xybf of the holder of the identity card 20 is stored in the electronic identity card 20 .
  • the characteristic date xybf has been stored in an initialization step in the terminal 10 to authorize the transaction release ID card 20 on the mobile terminal 10.
  • the characteristic date xybf can be, for example, the identity card number of the identity card 20, alternatively a certificate of the nPA, or the date of birth of the owner, optionally in combination. with its name, or the like.
  • the characteristic date xybf is preferably unique, therefore, the unique identity card number or the nPA certificate is particularly suitable.
  • FIG. 2 shows a flowchart of a transaction release transaction according to an embodiment of the invention.
  • a mobile terminal 10 with a Mobicore security operating system which includes a secure runtime environment (Trustzone), and with touch-screen display and NFC interface is to be used to pay for a bill according to a transaction record.
  • the transaction record includes a payee and a payable amount to pay.
  • a transaction form is filled out of the trust zone with the transaction data record.
  • the completed transaction form is stored in a transaction memory in the Mobicore Trustzone in the terminal 10.
  • the transaction record is displayed on the display of the terminal 10 so that the terminal user can check the transaction record. 5. If the terminal user does not agree, he does not continue and thus ends the payment process. If the terminal user agrees with the displayed transaction record, he presses an "OK" - touch button, which is displayed on the terminal display.
  • the terminal user approaches his nPA 20, which is paired with the terminal 10, to the terminal 10 to 10 in the NFC detection range of
  • the nPA 20 is activated upon approach by the terminal 10. 8. A secure NFC end-to-end connection between the terminal 10 Mobicore Trustzone and the nPA 20 is established. Optionally, the terminal automatically transmits the PIN of the nPA stored in the trust zone to the nPA.
  • the nPA 20 forms a checksum on the identity card number stored in the nPA and transmits the formed checksum via the secure NFC end-to-end connection to the terminal 10.
  • the transmitted check sum is matched to a value stored in the trust zone Checksum checked.
  • additional data in particular the name and address of the user, are transmitted from the nPA 20 to the terminal 10.
  • the transaction record is supplemented with the additional data.
  • the user must, e.g. Do not enter your name and address manually.
  • the completed transaction record is transmitted to the nPA 20 via the end-to-end connection.
  • the transaction record may be first transferred to the nPA 20 and then supplemented in the nPA 20 with the additional data.
  • the nPA 20 which has a microprocessor, forms a cryptographic signature over the supplemented transaction record. 16. The nPA 20 sends at least the signature, alternatively also the supplemented transaction record, via the secure end-to-end NFC connection to the terminal 10.
  • the terminal 10 sends the completed transaction record and the signature over it over the mobile network to the transaction server 30.
  • Transaction server 30 initiates payment according to the supplemented transaction record.
  • the invention has been described using the example of a payment transaction.
  • the invention is analogously applicable to a eVoting-
  • an election proposal is used as the transaction record to be supplemented.
  • the user supplements the transaction record by his choice, e.g., "YES” or "NO” or a selection of two or more options, optionally by ticking on the terminal display, and optionally by additional data from his nPA, e.g. Name and adress.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Die Erfindung schafft ein Verfahren zur authentisierten Freigabe einer elektronischen Transaktion, die durch einen Transaktionsdatensatz ganz oder teilweise gekennzeichnet ist, mittels eines elektronischen Endgeräts gegenüber einem Transaktionspartner, z.B. -Server. Bei dem Verfahren wird ein Authentisierungsdatum über eine elektronische Verbindung aus einem vom Endgerät unabhängig betreibbaren elektronischen Authentisierungsdokument, das mit dem Endgerät gepaart ist, in elektronischer Form an das Endgerät bereitgestellt.

Description

Authentisierte Transaktionsfreigabe
Die Erfindung betrifft ein Verfahren zur authentisierten Freigabe einer elektronischen Transaktion.
Es ist verbreitet, ausgehend von PCs und mobilen Endgeräten wie Mobiltelefonen, Smartphones und dergleichen Transaktionen wie beispielsweise Zahlungsverkehrtransaktionen zu tätigen. Dabei wird einem Nutzer, der die Transaktion tätigen möchte, am PC bzw. Endgerät ein Transaktionsdatensatz bereitgestellt und angezeigt, durch den die Transaktion beschrieben ist. Der Transaktionsdatensatz umfasst beispielsweise ein Zielkonto, auf das ein Geldbetrag überwiesen werden soll, und den zu überweisenden Geldbetrag. Der Nutzer überprüft den angezeigten Transaktionsdatensatz und macht bei Zustimmung am PC bzw. Endgerät eine Eingabe, wodurch die Transaktion bestätigt wird.
Beispielsweise beschreibt auf diesem Gebiet EP 0 986 275 Bl ein Transaktionsverfahren, für Lieferung von einem Dienstanbieter an einen Kunden, bei dem Bestellungsdaten, in welchen ein Geldbetrag enthalten ist, mittels Kurzmeldungen an eine Validationsplattform übermittelt werden und auf Grund der Überprüfung der Bestellungsdaten durch die Validationsplattform der Geldbetrag einem Geldkonto des Kunden abgezogen wird und auf ein Geldkonto des Dienstanbieters überwiesen wird. Zur Freigabe und schließlich Veranlassung einer Transaktion wird in der Regel zusätzlich eine Authentisierung gefordert, beispielsweise durch Eingabe einer PIN (persönliche Identifikationsnummer) oder TAN (Transaktionsnummer) am PC bzw. Endgerät. Anlässlich der erfolgreichen Authentisierung wird die Transaktion freigegeben und schließlich bei einer Validie- rungszentrale oder Clearing Center zur Durchführung gebracht, z.B. indem Geld von einem Konto abgezogen und auf ein anderes Konto aufgebucht wird.
Eine PIN muss sich der Nutzer merken und wird daher häufig vergessen oder leichtfertig gehandhabt, z.B. ausspähbar notiert. Die Verwendung einer TAN für die Authentisierung ist gegenüber einer PIN deutlich sicherer. Die Verwaltung eines zuverlässigen TAN-Systems ist aufwändig.
Wünschenswert wäre ein benutzerfreundliches und zuverlässiges Verfahren zur authentisierten Freigabe einer elektronischen Transaktion.
DE 10 2005 003 647 AI offenbart ein Identifizierungssystem, bei dem auf den elektronischen Speicher eines elektronischen Identifikationsdokuments (z.B. elektronischen Reisepasses) mittels eines gesonderten Autorisierungsdoku- ments zugegriffen wird, z.B. einer Zusatzkarte mit Autorisierungsdaten. Elektronische Identifikationsdokumente, wie beispielsweise elektronische Reisepässe oder elektronische Personalausweise wie der neue deutsche Personalausweis nPA haben einen Chip und eine Kontaktlosschnittstelle (z.B. NFC- Antenne), über die elektronische Kommunikation mit dem Chip mög- lieh ist.
Aus dem Stand der Technik prinzipiell bekannt ist es, zwei elektronische Geräte miteinander in Funkkontakt zu bringen, z.B. über NFC oder Bluetooth.
Unter der Bezeichnung ARM Trustzone Architektur ist eine zweigeteilte Lauf zeit- Architektur der Firma ARM für ein Mikroprozessorsystem bekannt, die zwei Lauf Zeitumgebungen umfasst. Eine erste,„Normal Zone" oder „Normal World" genannte unsichere Laufzeitumgebung ist durch ein Nor- malbetriebssystem gesteuert. Eine zweite,„Trustzone" oder„Trusted World" oder„Secure World" genannte gesicherte oder vertrauenswürdige Lauf zeitumgebung ist durch ein Sicherheitsbetriebssystem gesteuert. Das Normalbetriebssystem kann beispielsweise ein gängiges Betriebssystem wie Android, Windows Phone, Symbian oder dergleichen sein.
Durch die Anmelderin der vorliegenden Patentanmeldung wird unter der Markenbezeichnung MOBICORE ein Sicherheitsbetriebssystem für in mobile Endgeräte zu implementierende Chips hergestellt und vertrieben.
WO 2004/053807 AI beschreibt ein Zahlungssystem mittels eines Dual-Slot Mobiltelefons mit zwei Chipkarten, nämlich einer herkömmlichen SIM-Karte für den Funkbetrieb und zusätzlich einer Zertifikats-Chipkarte zur Transak- tionsbestätigung für Zahlungsvorgänge. Die Zertifikats-Chipkarte enthält Identifizierungsdaten, mit denen ein auf einen Nutzer personalisiertes Zertifikat erstellt werden kann. Zur Bestätigung einer Zahlungsverkehrstransaktion wird aus Transaktionsdaten ein verschlüsseltes und signiertes Datenpaket erzeugt und mit dem Mobiltelefon an ein Clearingcenter gesendet. Hier- durch wird die Transaktion freigegeben. Bei der Lösung aus WO 2004
/ 053807 AI wird Manipulationssicherheit dadurch angestrebt, dass die Zertifizierungskarte kontaktbehaftet unmittelbar im Endgerät betrieben wird.
Das in WO 2004/ 053807 AI angegebene Verfahren benötigt zwingend ein Dual-Slot-Mobil telefon und ist somit nur eingeschränkt einsetzbar.
Der Erfindung liegt die Aufgabe zu Grunde ein benutzerfreundliches, universal einsetzbares und zuverlässiges Verfahren zur authentisierten Freigabe einer elektronischen Transaktion anzugeben. Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Das erfindungsgemäße Verfahren ist zur authentisierten Freigabe einer elektronischen Transaktion vorgesehen. Die Transaktion ist durch einen Transaktionsdatensatz ganz oder teilweise gekennzeichnet. Insbesondere kann der Transaktionsdatensatz von Anfang an komplett vorliegen oder im Lauf des Verfahrens ergänzt oder erweitert werden (vgl. weiter unten). Die Transaktion wird mittels eines elektronischen Endgeräts gegenüber einem Transaktionspartner-Computer, z.B. einem Transaktionsserver, der z.B. bei einer Bank oder einem Clearing-Center oder Ähnlichem steht, freigegeben. Bei dem Verfahren wird: ein vom Transaktionspartner erhaltener Transaktions- datensatz am Endgerät bereitgestellt; am Endgerät eine Freigabe der Transaktion gefordert; und am Endgerät ein Authentisierungsdatum zur Authen- tisierung entgegengenommen und die authentisierte Freigabe der Transaktion veranlasst, indem das Authentisierungsdatum zur Weiterleitung an den Transaktionspartner bereitgestellt wird. Standardmäßig wird schließlich das Authentisierungsdatum an den Transaktionspartner, z.B. Transaktionsserver, weitergeleitet, und in der Regel auch der Transaktionsdatensatz. Durch den Transaktionsserver wird die Transaktion durchgeführt oder zumindest die Durchführung veranlasst. Das Verfahren zeichnet sich dadurch aus, dass das Authentisierungsdatum über eine elektronische Verbindung aus einem vom Endgerät getrennten, baulich vom Endgerät unabhängigen elektronischen Authentisierungsdo- kument, das mit dem Endgerät gepaart ist, in elektronischer Form an das Endgerät bereitgestellt wird. Das Authentisierungsdokument und das End- gerät sind dahingehend miteinander gepaart, dass die Freigabe der Transaktion mit einem mit dem Endgerät gepaarten Authentisierungsdokument möglich ist und dass die Freigabe der Transaktion mit einem mit dem Endgerät nicht gepaarten Authentisierungsdokument nicht möglich ist.
Die Freigabe der Transaktion erfolgt abgesichert durch eine Authentisierung. Dadurch, dass das Authentisierungsdokument vom Endgerät unabhängig betreibbar ist, müssen Endgerät und Authentisierungsdokument baulich nicht aufeinander abgestimmt sein, wie es etwa wie bei der Lösung aus WO 2004/053807 AI erforderlich ist. Durch die Paarung zwischen Endgerät und Authentisierungsdokument ist andererseits sichergestellt, dass trotz der Unabhängigkeit zwischen Endgerät und Authentisierungsdokument potentiell manipulierte, unberechtigte Authentisierungsdokumente keinen freigebenden Zugriff auf das Endgerät bekommen. Der Nutzer des Endgeräts und Authentisierungsdokuments behält somit die Handlungsgewalt über die Freigabe der Transaktion.
Im Vergleich zu einem PIN- oder TAN-authentisierten Freigabeverfahren ist das Verfahren nach Anspruch 1 erheblich benutzerfreundlicher.
Daher ist gemäß Anspruch 1 ein benutzerfreundliches, universal einsetzbares und zuverlässiges Verfahren zur authentisierten Freigabe einer elektronischen Transaktion geschaffen. Als Transaktionspartner-Computer kann anstelle des bereits ausdrücklich angeführten Transaktionsservers alternativ ein anderes/ weiteres mobiles Endgerät vorgesehen sein, wobei die Transaktionsbestätigung also über eine Peer-to-Peer- Verbindung zwischen grundsätzlich gleichberechtigten mobilen Endgeräten als Transaktionspartnern durchgeführt wird. Die Paarung wird z.B. dadurch erreicht, dass ein für das Authentifizierungs- dokument charakteristisches Datum in dem Endgerät abgespeichert ist. Die Paarung wird beispielsweise in einem vorgelagerten Initialisierungsschritt erzeugt, in dem das charakteristische Datum aus dem Authentifizierungsdo- kument in dem Endgerät abgespeichert wird. Als das charakteristische Datum wird beispielsweise eine eindeutige Seriennummer des Authentisie- rungsdokuments oder dergleichen verwendet, oder eine (kryptographische) Prüfsumme über eine solche Seriennummer oder dergleichen. Bei einem Per- sonalausweis (vgl. weiter unten) wird z.B. die Personalausweisnummer oder eine (kryptographische) Prüfsumme über die Personalausweisnummer als das charakteristische Datum verwendet. Vorzugsweise wird eine Prüfsumme verwendet und nicht die Seriennummer bzw. Personalausweisnummer im Klartext.
Um die Paarung zu erzeugen ist es aber auch möglich, dass das Mobilgerät in gesicherter Umgebung einen Zertifikataustausch mit dem Personalausweis vollzieht und damit in der Lage ist, nur mit diesem später einen sicheren Kanal aufzubauen. Die Freigabe für einen solchen Austausch kann durch die Eingabe einer PIN mit Personalausweis (einmalig) erfolgen.
Für die Durchführung der Transaktion wird als Authentisierungsdatum wahlweise eine über den Transaktionsdatensatz erzeugte kryptographische Signatur verwendet. Wahlweise wird das Authentisierungsdatum in dem Authentisierungsdokument erzeugt. Wahlweise wird genauer in dem Au- thentisierungsdokument, das einen Mikroprozessor hat, als Authentisierungsdatum eine kryptographische Signatur über den Transaktionsdatensatz erzeugt. Wahlweise wird als elektronische Verbindung eine kontaktlose Verbindung, insbesondere NFC- Verbindung, verwendet. Insbesondere wird z.B. der Transaktionsdatensatz über die elektronische Verbindung aus dem Endgerät an das Authentisierungsdokument übermittelt. Wahlweise wird das erzeug- te Authentisierungsdatum, z.B. die Signatur, über eine kontaktlose elektronische Verbindung, z.B. NFC, aus dem elektronischen Authentisierungsdokument an das Endgerät bereitgestellt.
Wahlweise wird der übermittelte Transaktionsdatensatz in dem Authentisie- rungsdokument abgespeichert, wahlweise flüchtig, z.B. nur zur Erzeugung des Authentisierungsdatums, z.B. Signatur, wahlweise nicht-flüchtig. Nichtflüchtige Speicherung ermöglicht es, nach einem vorübergehenden Ausfall der Energieversorgung am Endgerät später die Transaktion fortzusetzen. Wahlweise wird der im Authentisierungsdokument gespeicherte Transaktionsdatensatz aus dem Authentisierungsdokument wieder gelöscht, nachdem das Authentisierungsdatum aus dem Authentisierungsdokument an das Endgerät bereitgestellt worden ist. Wahlweise wird das Authentisierungsdatum, z.B. Signatur, ebenfalls im Authentisierungsdokument (nicht-flüchtig) abgespeichert und nach Übertragung an das Endgerät wieder gelöscht.
Nicht-flüchtiges Speichern und wieder Löschen von Transaktionsdatensatz und Authentisierungsdatum (z.B. Signatur) im Authentisierungsdokument nach Übertragung an das Endgerät macht das Verfahren insbesondere ein- setzbar für Ticketting. Das Löschen entspricht einem Entwerten des Tickets.
Wahlweise wird als Authentisierungsdokument ein elektronisches Identifikationsdokument verwendet, insbesondere ein elektronischer Personalausweis oder Reisepass, insbesondere mit Mikroprozessor und Signaturfunkti- ort, so wie z.B. der sogenannte neue deutsche Personalausweis nPA. Ein elektronisches Identifikationsdokument, insbesondere Personalausweis, ist als Authentisierungsdokument besonders bevorzugt, da der Nutzer es ohnehin meistens mit sich führt. Zudem ermöglicht gerade ein Authentisie- rungsdokument in Gestalt eines Identifikationsdokuments die einfache Ergänzung des Transaktionsdatensatzes mit Zusatzdaten (vgl. nachfolgend), zur Erleichterung der Handhabung für den Nutzer.
Wahlweise wird der Transaktionsdatensatz durch in dem Authentifikations- dokument abgespeicherte Zusatzdaten erweitert oder ergänzt. Die Ergänzung kann wahlweise im Endgerät oder im Authentif ikationsdokument erfolgen. Im ersten Fall werden die Zusatzdaten an das Endgerät übermittelt und wird der Transaktionsdatensatz im Endgerät ergänzt bzw. erweitert. Im zweiten Fall wird der Transaktionsdatensatz ohne die Zusatzdaten an das Authentisierungsdokument übermittelt und die Ergänzung bzw. Erweiterung dort durchgeführt.
Als Zusatzdaten können wahlweise personenspezifische Daten wie z.B. Name und Adresse des Transaktionsteilnehmers vorgesehen sein, der die Transaktion freigibt. Insbesondere falls als Authentisierungsdokument ein elektronisches Identifikationsdokument des freigebenden Transaktionsteilnehmers vorgesehen ist, enthält dieses bereits dessen Name und Adresse. Zusatzdaten wie z.B. Name und Adresse können daher automatisch in den Transaktionsdatensatz aufgenommen werden.
Das Endgerät ist wahlweise aus der Gruppe von Endgeräten gewählt, die umfasst: mobiles Endgerät umfassend insbesondere Mobiltelefon, Smart Phone; Computer, insbesondere Desktop-PC, Notebook, Netbook; Tablet-PC mit oder ohne Mobiltelefon-Schnittstelle. Wahlweise ist insbesondere als Endgerät ein mobiles Endgerät wie z.B.
Smart Phone, Mobiltelefon etc. vorgesehen und als Authentisierungsdokument ein elektronisches Identifikationsdokument, insbesondere elektroni- scher Personalausweis, vorgesehen. Mobiltelefon und Personalausweis führen viele Personen ständig mit sich. Somit entsteht durch die Erfindung kein Zusatzaufwand für den Nutzer. Dadurch, dass das z.B. eigene mobile Endgerät und der z.B. eigene elektronische Personalausweis miteinander gepaart sind, kann der Nutzer nur durch das eigene mobile Endgerät in Kombinati- on mit dem eigenen Personalausweis eine Transaktion freigeben. Die miss- bräuchliche unbemerkte Freigabe einer Transaktion durch einen in der Nähre anwesenden Dritten mit einem anderen Personalausweis ist auf Grund der Paarung ausgeschlossen. Das Endgerät umfasst wahlweise eine gesicherte Laufzeitumgebung, beispielsweise bei einem mobilen Endgerät die Trustzone eines Mobicore Sicherheitsbetriebssystems der Anmelderin der vorliegenden Patentanmeldung. Wahlweise wird die elektronische Verbindung zwischen dem Authentisierungsdokument und dem Endgerät beim Endgerät in der gesicherten Laufzeitumgebung betrieben. Hierdurch ist sichergestellt, dass die Paarung auf das gewählte Authentisierungsdokument eingestellt bleibt und nicht o- der nicht ohne weiteres auf ein anderes Authentisierungsdokument geändert werden kann. Wahlweise ist als Transaktion eine Zahlungsverkehrstransaktion vorgesehen, wobei der Transaktionsdatensatz zumindest einen Zahlungsempfänger und/ oder einen Zahlungsbetrag umfasst. Wahlweise ist als Transaktion eine Wahlabstimmungs-Transaktion vorgesehen, wobei der Transaktionsdatensatz zumindest einen ausgewählten, zu wählenden Wahlvorschlag umfasst. Bei dem erfindungsgemäßen Verfahren wird wahlweise weiter die Paarung zwischen dem Endgerät und dem Authentisierungsdokument überprüft und die Freigabe der Transaktion verhindert oder abgebrochen, falls gemäß der Überprüfung das Endgerät und das Authentisierungsdokument nicht miteinander gepaart sind. Diese Situation kann auftreten, falls ein falsches Au- thentisierungsdokument oder ein falsches Endgerät verwendet wird.
Wahlweise wird weiter - zusätzlich zum, vorzugsweise vor dem, Entgegennehmen des Authentisierungsdatums am Endgerät - am Endgerät eine Nutzereingabe entgegengenommen.
Wahlweise wird bei der Übertragung der Transaktion die Transaktion (z.B. Ticket) an einen Server (z.B. des Serviceanbieters) übergeben um bei einer nachfolgenden Verifizierung und ausgefallenem Mobilgerät (Batterie leer) den nPA (Authentisierungsdokument) zur Identifikation der hinterlegten Transaktion zu benutzen und somit eine Verifizierung der Transaktion trotz ausgefallenen Mobilgerätes durchzuführen.
Beispielsweise ist das Verfahren also zweistufig gestaltet. In einer ersten Stufe werden Transaktionsdaten eines Transaktionsdatensatzes am Endgerät angezeigt und bestätigt ein Nutzer durch eine Eingabe am Endgerät die am Endgerät angezeigten Transaktionsdaten, z.B. durch Tastatureingabe oder Eingabe auf einem Touch-Pad oder Touch-Screen-Display. In einer zweiten Stufe wird, gemäß der Erfindung, das Authentisierungsdatum über eine elektronische Verbindung aus einem vom Endgerät unabhängig betreibba- ren elektronischen Authentisierungsdokument, das mit dem Endgerät gepaart ist, in elektronischer Form an das Endgerät bereitgestellt.
Wahlweise wird das Authentisierungsdatum dadurch aus dem elektroni- sehen Authentisierungsdokument an das Endgerät bereitgestellt, dass das Authentisierungsdokument an das Endgerät angenähert wird, insbesondere gemäß einem vorbestimmten Bewegungsmuster (Gesture) an das Endgerät angenähert wird. Der Gesamtablauf kann also wie folgt sein. Zunächst kann eine Bestätigung des Transaktionsdatensatzes durch Nutzereingabe erfolgen, um zu verhindern, dass durch eine zufällige Annäherung des Authentisierungsdoku- ments (z.B. Personalausweises) ungewollte Transakionsbestätigung erfolgt. Dann nähert der Nutzer das Authentisierungsdokument an das Endgerät an. Optional erfolgt wieder eine Nutzereingabe. Der - optional um Zusatzdaten bereits ergänzte oder erweiterte - Transaktionsdatensatz wird zur Signaturerzeugung vom Endgerät an das Authentisierungsdokument übermittelt und/ oder ggf. im Authentisierungsdokument mit Zusatzdaten ergänzt oder erweitert. Die kryptographische Signatur wird im Authentisierungsdoku- ment erzeugt. Die im Authentisierungsdokument erzeugte Signatur wird an das Endgerät zurück übertragen.
Wahlweise kann ein notwendiger Öffnungsmechanismus (z.B. PIN) für das Authentisierungsdokument (z.B. nPA) auf dem Mobiltelefon sicher hinter- legt werden, so dass eine zum Zugriff auf das Authentisierungsdokument (z.B. nPA) erforderliche PIN Eingabe wahlweise nicht vom Benutzer explizit durchgeführt werden muss, sondern bei Bedarf die PIN direkt, ohne Nutzereinwirkung, vom Mobiltelefon an das Authentisierungsdokument übermittelt wird. Wahlweise ist also ein Bereitstellen eines Identifikationsdatums, z.B. PIN- Eingabe, an das Authentisierungsdokument erforderlich, damit das Authen- tisierungsdatum aus dem elektronischen Authentisierungsdokument ausge- lesen werden kann, und wobei das Identifikationsdatum (z.B. PIN) im Endgerät sicher abgespeichert ist, z.B. in der Trustzone unter Mobicore, und durch das Endgerät an das Authentisierungsdokument bereitgestellt wird, bevor das Authentisierungsdatum aus dem elektronischen Authentisie- rungsdokumen an das Endgerät bereitgestellt wird.
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen:
Fig. 1 ein System zur Veranschaulichung der Erfindung, mit einem mobilen Endgerät, einem elektronischen Personalausweis und einem Transaktionsserver;
Fig. 2 ein Ablaufdiagramm einer Transaktion mit Transaktionsfreigabe gemäß einer Ausführungsform der Erfindung. Fig. 1 zeigt ein System zur Veranschaulichung der Erfindung, mit einem mobilen Endgerät 10, einem elektronischen Personalausweis 20 als Authentisierungsdokument 20 und einem Transaktionsserver 30. Im elektronischen Personalausweis 20 ist ein charakteristisches Datum xybf des Inhabers des Personalausweises 20 abgespeichert. Das charakteristische Datum xybf ist in einem Initialisierungsschritt in das Endgerät 10 gespeichert worden, um den Personalausweis 20 zur Transaktionsfreigabe auf dem mobilen Endgerät 10 zu autorisieren. Das charakteristische Datum xybf kann beispielsweise die Personalausweisnummer des Personalausweises 20 sein, alternativ ein Zertifikat des nPA, oder das Geburtsdatum des Inhabers, wahlweise in Verbin- dung mit dessen Namen, oder dergleichen. Das charakteristische Datum xybf ist vorzugsweise eindeutig, daher ist die eindeutige Personalausweisnummer oder das nPA Zertifikat besonders geeignet. Fig. 2 zeigt ein Ablaufdiagramm einer Transaktion mit Transaktionsfreigabe gemäß einer Ausführungsform der Erfindung.
1. Ein mobiles Endgerät 10 mit einem Mobicore Sicherheitsbetriebssystem, das eine gesicherte Laufzeitumgebung (Trustzone) umfasst, und mit Touch-Screen-Display und NFC-Interface soll zur Bezahlung einer Rechnung gemäß einem Transaktionsdatensatz verwendet werden. Der Transaktionsdatensatz umfasst einen Zahlungsempfänger und einen zu zahlenden Zahlungsbetrag.
2. Am Endgerät 10 wird aus der Trustzone heraus ein Transaktionsformu- lar mit dem Transaktionsdatensatz befüllt.
3. Das ausgefüllte Transaktionsformular wird in einem Transaktionsspeicher in der Mobicore Trustzone im Endgerät 10 abgespeichert.
4. Der Transaktionsdatensatz wird am Display des Endgeräts 10 angezeigt, so dass der Endgerät-Nutzer den Transaktionsdatensatz prüfen kann. 5. Ist der Endgerät-Nutzer nicht einverstanden, fährt er nicht fort und beendet somit den Zahlungsvorgang. Ist der Endgerät-Nutzer mit dem angezeigten Transaktionsdatensatz einverstanden, drückt er einen„OK"- Touch-Button, der auf dem Endgerät-Display angezeigt wird.
6. Der Endgerät-Nutzer nähert seinen nPA 20, der mit dem Endgerät 10 gepaart ist, an das End gerät 10 an, bis in den NFC-Erfassungsbereich des
Endgeräts 10.
7. Der nPA 20 wird auf die Annäherung hin durch das Endgerät 10 aktiviert. 8. Eine sichere NFC Ende-zu-Ende Verbindung zwischen der Endgerät 10 Mobicore Trustzone und dem nPA 20 wird hergestellt. Optional überträgt das Endgerät dabei automatisch die PIN des nPA, die in der Trustzone abgelegt ist, an den nPA.
9. Der nPA 20 bildet eine Prüfsumme über die im nPA abgespeicherte Personalausweisnummer und überträgt die gebildete Prüfsumme über die sichere NFC Ende-zu-Ende Verbindung an das Endgerät 10. Im Endgerät 10 wird die übertragene Prüf summe auf Übereinstimmung mit einer in der Trustzone hinterlegten Prüfsumme überprüft.
10. Falls keine Übereinstimmung zwischen den Prüfsummen besteht, wird die Transaktion abgebrochen. Falls die Prüfsummen übereinstimmen, wird der Vorgang weitergeführt wie folgt.
11. Über die Ende-zu-Ende Verbindung werden Zusatzdaten, insbesondere Name und Adresse des Nutzers, aus dem nPA 20 an das Endgerät 10 übertragen. Der Transaktionsdatensatz wird mit den Zusatzdaten ergänzt. Somit muss der Nutzer z.B. Name und Adresse nicht händisch eintragen.
12. Der nun ergänzte Transaktionsdatensatz wird am Display des Endgeräts 10 angezeigt.
13. Ist der Endgerät-Nutzer nicht einverstanden, fährt er nicht fort und beendet somit den Zahlungsvorgang. Ist der Endgerät-Nutzer mit dem angezeigten ergänzten Transaktionsdatensatz einverstanden, drückt er einen„OK"-Touch-Button, der auf dem Endgerät-Display angezeigt wird.
14. Der ergänzte Transaktionsdatensatz wird über die Ende-zu-Ende Ver- bindung an den nPA 20 übertragen. Alternativ kann der Transaktionsdatensatz zuerst an den nPA 20 übertragen werden und anschließend im nPA 20 mit den Zusatzdaten ergänzt werden.
15. Der nPA 20, der einen Mikroprozessor hat, bildet eine kryptographische Signatur über den ergänzten Transaktionsdatensatz. 16. Der nPA 20 sendet zumindest die Signatur, alternativ auch den ergänzten Transaktionsdatensatz, über die sichere Ende-zu-Ende NFC Verbindung an das Endgerät 10.
17. Das Endgerät 10 sendet den ergänzten Transaktionsdatensatz und die Signatur darüber über das Mobilfunknetz an den Transaktionsserver 30.
18. Der Transaktionsserver 30 veranlasst die Bezahlung gemäß dem ergänzten Transaktionsdatensatz.
Die Erfindung wurde am Beispiel einer Zahlungsverkehr-Transaktion be- schrieben. Die Erfindung ist analog anwendbar bei einem eVoting-
Verfahren, bei dem elektronisch über einen Wahl Vorschlag abgestimmt wird. In diesem Fall wird als noch zu ergänzender Transaktionsdatensatz ein Wahlvorschlag verwendet. Der Nutzer ergänzt den Transaktionsdatensatz um seine Wahl, z.B.„JA" oder„NEIN" oder eine Auswahl aus zwei oder mehr Optionen, wahlweise durch Ankreuzen am Endgerät-Display, und ggf. durch Zusatzdaten aus seinem nPA, z.B. Name und Adresse.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur authentisierten Freigabe einer elektronischen Transaktion, die durch einen Transaktionsdatensatz ganz oder teilweise gekennzeichnet ist, mittels eines elektronischen Endgeräts (10) gegenüber einem Transaktionspartner (30), wobei
- ein vom Transaktionspartner (30) erhaltener Transaktionsdatensatz am Endgerät (10) bereitgestellt wird,
- am Endgerät (10) eine Freigabe der Transaktion gefordert wird, und - am Endgerät (10) ein Authentisierungsdatum zur Authentisierung entgegengenommen wird und die authentisierte Freigabe der Transaktion veranlasst wird, indem das Authentisierungsdatum zur Weiterleitung an den Transaktionspartner (30) bereitgestellt wird,
dadurch gekennzeichnet, dass
das Authentisierungsdatum über eine elektronische Verbindung aus einem vom Endgerät (10) getrennten, baulich vom Endgerät (10) unabhängigen elektronischen Authentisierungsdokument (20), das mit dem Endgerät (10) gepaart ist, in elektronischer Form an das Endgerät (10) bereitgestellt wird.
2. Verfahren nach Anspruch 1, wobei als Authentisierungsdatum eine über den Transaktionsdatensatz erzeugte kryptographische Signatur verwendet wird.
3. Verfahren nach Anspruch 1 oder 2, wobei das Authentisierungsdatum in dem Authentisierungsdokument (20) erzeugt wird.
4. Verfahren nach einem der Ansprüche 1 bis 3, wobei als elektronische Verbindung eine kontaktlose Verbindung, insbesondere NFC- Verbindung, verwendet wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, wobei der Transaktionsdatensatz in dem Authentisierungsdokument (20) abgespeichert wird.
6. Verfahren nach Anspruch 5, wobei nach dem Bereitstellen des Authenti- sierungsdatums aus dem Authentisierungsdokument (20) an das Endgerät
(10) der im Authentisierungsdokument (20) gespeicherte Transaktionsdatensatz aus dem Authentisierungsdokument (20) wieder gelöscht wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, wobei als Authentisierungs- dokument (20) ein elektronisches Identifikationsdokument verwendet wird, insbesondere ein elektronischer Personalausweis oder Reisepass, insbesondere mit Mikroprozessor und Signaturfunktion.
8. Verfahren nach einem der Ansprüche 1 bis 7, wobei der Transaktionsda- tensatz durch in dem Authentifikationsdokument (20) abgespeicherte Zusatzdaten erweitert oder ergänzt wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, wobei das Endgerät (10) aus der Gruppe von Endgeräten gewählt ist, die umfasst: mobiles Endgerät um- fassend insbesondere Mobil telefon, Smart Phone; Computer, insbesondere Desktop-PC, Notebook, Netbook; Tablet-PC mit oder ohne Mobiltelefon- Schnittstelle.
10. Verfahren nach einem der Ansprüche 1 bis 9, wobei das Endgerät (10) eine gesicherte Laufzeitumgebung (Mobicore Trustzone) umfasst, und wobei die elektronische Verbindung zwischen dem Authentisierungsdokument (20) und dem Endgerät (10) beim Endgerät (10) in der gesicherten Laufzeitumgebung (Mobicore Trustzone) betrieben wird.
11. Verfahren nach einem der Ansprüche 1 bis 10, wobei als Transaktion eine Zahlungsverkehrstransaktion vorgesehen ist, und wobei der Transaktionsdatensatz zumindest einen Zahlungsempfänger und/ oder einen Zahlungsbetrag umfasst.
12. Verfahren nach einem der Ansprüche 1 bis 10, wobei als Transaktion eine Wahlabstimmungs-Transaktion vorgesehen ist, und wobei der Transaktionsdatensatz zumindest einen ausgewählten, zu wählenden Wahlvorschlag umfasst.
13. Verfahren nach einem der Ansprüche 1 bis 12, wobei weiter die Paarung zwischen dem Endgerät (10) und dem Authentisierungsdokument (20) überprüft wird und die Freigabe der Transaktion verhindert oder unterbrochen oder abgebrochen wird, falls gemäß der Überprüfung das Endgerät (10) und das Authentisierungsdokument (20) nicht miteinander gepaart sind.
14. Verfahren nach einem der Ansprüche 1 bis 13, wobei weiter - zusätzlich zum, vorzugsweise vor dem, Entgegennehmen des Authentisierungsdatums am End gerät (10) - am Endgerät (10) eine Nutzereingabe entgegengenom- men wird.
15. Verfahren nach einem der Ansprüche 1 bis 14, wobei, damit das Authen- tisierungsdatum aus dem elektronischen Authentisierungsdokument (20) ausgelesen werden kann, ein Bereitstellen eines Identifikationsdatums (PIN) an das Authentisierungsdokument (20) erforderlich ist, und wobei das Identifikationsdatum (PIN) im Endgerät sicher abgespeichert ist und durch das Endgerät (10) an das Authentisierungsdokument (20) bereitgestellt wird, bevor das Authentisierungsdatum aus dem elektronischen Authentisie- rungsdokumen (20) an das Endgerät (10) bereitgestellt wird.
EP13707816.8A 2012-02-28 2013-02-26 Authentisierte transaktionsfreigabe Ceased EP2820600A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102012003885 2012-02-28
PCT/EP2013/000560 WO2013127520A1 (de) 2012-02-28 2013-02-26 Authentisierte transaktionsfreigabe

Publications (1)

Publication Number Publication Date
EP2820600A1 true EP2820600A1 (de) 2015-01-07

Family

ID=47833024

Family Applications (1)

Application Number Title Priority Date Filing Date
EP13707816.8A Ceased EP2820600A1 (de) 2012-02-28 2013-02-26 Authentisierte transaktionsfreigabe

Country Status (2)

Country Link
EP (1) EP2820600A1 (de)
WO (1) WO2013127520A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013021935A1 (de) * 2013-12-20 2015-06-25 Giesecke & Devrient Gmbh Verfahren und Vorrichtungen zum Verwenden eines Sicherheitselements mit einem mobilen Endgerät
CN108256999B (zh) * 2018-01-19 2020-08-14 阿里巴巴集团控股有限公司 资金流转方法及装置、电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100203870A1 (en) * 2008-01-04 2010-08-12 Logomotion, S.R.O. Systems and methods for contactless payment authorization
US20110313922A1 (en) * 2009-06-22 2011-12-22 Mourad Ben Ayed System For NFC Authentication Based on BLUETOOTH Proximity
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0986275B1 (de) 1998-09-10 2009-09-09 Swisscom AG Verfahren zum Kaufen von Waren oder Dienstleistungen mit einem Mobiltelefon
AU2002225768A1 (en) * 2000-11-28 2002-06-11 Rcd Technology, Inc. Replacing stored code with user inputting code on the rf id card
DE10258119A1 (de) 2002-12-06 2004-07-15 Deutsche Telekom Ag Zahlungssystem mittels Funktelefon
GB2396472A (en) * 2002-12-18 2004-06-23 Ncr Int Inc System for cash withdrawal
DE102005003647A1 (de) 2005-01-26 2006-08-17 Giesecke & Devrient Gmbh Identifizierungssystem
DE102006037879A1 (de) * 2006-08-11 2008-02-14 Bundesdruckerei Gmbh Lesegerät für ein Dokument, Verfahren zum Lesen eines Datenobjekts und Computerprogrammprodukt
WO2009039419A1 (en) * 2007-09-21 2009-03-26 Wireless Dynamics, Inc. Wireless smart card and integrated personal area network, near field communication and contactless payment system
EP2182493A1 (de) * 2008-11-04 2010-05-05 Gemalto SA Remote-Benutzerauthentifizierung mit NFC
SK288521B6 (sk) * 2009-07-08 2017-12-04 Smk Corporation Spôsob a systém zadávania PIN kódu pri bezhotovostných platbách, nosič PIN kódu
GB2476989A (en) * 2010-01-19 2011-07-20 Proxama Ltd Activation of secure function in mobile computing device using authentication tag

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100203870A1 (en) * 2008-01-04 2010-08-12 Logomotion, S.R.O. Systems and methods for contactless payment authorization
US20110313922A1 (en) * 2009-06-22 2011-12-22 Mourad Ben Ayed System For NFC Authentication Based on BLUETOOTH Proximity
DE102010030590A1 (de) * 2010-06-28 2011-12-29 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Zertifikats

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2013127520A1 *

Also Published As

Publication number Publication date
WO2013127520A1 (de) 2013-09-06

Similar Documents

Publication Publication Date Title
WO2016192842A1 (de) Endgerät und verfahren für mobiles bezahlen mit trusted execution environment
EP3559883A1 (de) System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement
DE10296888T5 (de) System und Verfahren zur sicheren Eingabe und Authentifikation von verbraucherzentrierter Information
EP2080147B1 (de) Verfahren zum ausführen einer applikation mit hilfe eines tragbaren datenträgers
EP2715684A1 (de) Elektronisches system zur raschen und sicheren abwicklung von transaktionen mit mobilen geräten
WO2013067561A1 (de) Verfahren und vorrichtung zum durchführen von bargeldlosen zahlungen
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
DE102017122799A1 (de) Verfahren und Anordnung zur Übermittlung von Transaktionsdaten unter Nutzung eines öffentlichen Datennetzes
EP3811584A1 (de) Smartcard als sicherheitstoken
EP3428866A2 (de) Datenübertragungs- und -verarbeitungsanordnung und datenübertragungs- und -verarbeitungsverfahren zur bezahlung einer ware oder leistung
WO2013011043A1 (de) Mobiles system für finanztransaktionen
CN105956839A (zh) 应用于智能家居平台的支付方法和装置
WO2013127520A1 (de) Authentisierte transaktionsfreigabe
WO2014206660A1 (de) Elektronisches transaktionsverfahren und computersystem
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP2916252B1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013212646A1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102010036037A1 (de) Verfahren zur Durchführung bargeldioser Zahlungstransaktionen und Transaktionsystem zur Durchführung des Verfahrens
DE102008047639A1 (de) Verfahren und Vorrichtung zum Zugriff auf ein maschinenlesbares Dokument
EP3561753A1 (de) Datenübertragungs- und verarbeitungsverfahren und anordnung hierfür
EP2696319B1 (de) Verfahren zur Freigabe einer Transaktion
DE102013022434B3 (de) Elektronisches Transaktionsverfahren und Computersystem
WO2023046237A1 (de) Verfahren zum digitalen austauschen von informationen
EP2840757B1 (de) Individuelle zentrale verwaltung von chipkarten
DE102011077770A1 (de) Bezahlsystem zur Bezahlung von Waren und Dienstleistungen sowie Verfahren hierfür

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20140929

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20160216

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20191025