WO2016192842A1 - Endgerät und verfahren für mobiles bezahlen mit trusted execution environment - Google Patents

Endgerät und verfahren für mobiles bezahlen mit trusted execution environment Download PDF

Info

Publication number
WO2016192842A1
WO2016192842A1 PCT/EP2016/000871 EP2016000871W WO2016192842A1 WO 2016192842 A1 WO2016192842 A1 WO 2016192842A1 EP 2016000871 W EP2016000871 W EP 2016000871W WO 2016192842 A1 WO2016192842 A1 WO 2016192842A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
terminal
service provider
psp
transaction
Prior art date
Application number
PCT/EP2016/000871
Other languages
English (en)
French (fr)
Inventor
Udo Schwartz
Kurt Stadler
Mihai Creanga
Original Assignee
Giesecke & 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 & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to US15/578,085 priority Critical patent/US11640596B2/en
Priority to EP16727952.0A priority patent/EP3304466A1/de
Priority to KR1020177034012A priority patent/KR101957840B1/ko
Publication of WO2016192842A1 publication Critical patent/WO2016192842A1/de

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/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/326—Payment applications installed on the mobile 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3226—Use of secure elements separate from 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
    • 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/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • 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/351—Virtual 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/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
    • 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

Definitions

  • the invention relates to a mobile terminal and a method for mobile payment by means of a mobile terminal of a customer to a dealer.
  • Known mobile electronic payment systems include an NFC-enabled (near field communication) mobile terminal (eg mobile telephone, smartphone or similar device) of a customer or potential buyer - in short NFC terminal - an external payment terminal, a payment service provider and bank server of Customer and dealer.
  • the bank servers include a customer bank server on which an account of the customer is kept and a merchant bank server on which a merchant's account is kept.
  • the terminal comprises a payment application (or more) and an NFC controller with antenna.
  • payment applications in the terminal may take the form of virtual electronic payment cards (eCards) or electronic purses (eWallets).
  • a mobile payment from a customer's terminal to the merchant includes the following steps.
  • the merchant creates a payment request from transaction data T (comprising at least the payee (merchant, seller, ...) and amount) and sends it to the payment processor. terminal.
  • the customer holds his terminal to the payment terminal.
  • the payment terminal then sends the transaction data T via the NFC interface to the terminal to issue a payment request to the terminal.
  • the transaction data T received via NFC are forwarded to the payment application (if necessary after selecting one of several payment applications).
  • the payment application presents the transaction data to the customer and authenticates the customer. The successful authentication is interpreted as an authorization or confirmation (by the customer) of the transaction data.
  • the payment application sends on the authorization / confirmation a transaction instruction according to the transaction data to the payment terminal.
  • the payment terminal instructs the payment transaction provider, the payment service provider authorized to the bank servers, to clear the payment at the bank servers.
  • the client and merchant bank servers clear the payment, ie, transfer money from the customer's account to the merchant's account in accordance with the payment.
  • the payment application is implemented in a security element provided in the terminal.
  • the payment application comprises not only the actual application for the payment application associated authentication data (e.g.
  • cryptographic keys and possibly other personalization data or customer data (e.g., (credit) card numbers or bank account data).
  • customer data e.g., (credit) card numbers or bank account data.
  • the authentication can be done for example by means of a signature.
  • This is done in the terminal by means of access data (here in particular by means of a private key of an asymmetric public-private key Key pair) generates a signature on transaction data and from the signed transaction data (ie the signature) and other data (eg the transaction data in plain text) generates a transaction statement.
  • the transaction instruction is sent from the terminal via the NFC interface to the payment terminal.
  • the transaction statement / signature is verified (in particular with the corresponding public key to the private key).
  • the authentication is done by passing between the terminal and the payment terminal using credentials (e.g., cryptographic
  • a secure channel i.e., a cryptographically secured channel through authentication and key derivation
  • the transaction instruction is sent over the secure channel from the terminal to the payment terminal.
  • the authentication is realized via an end-to-end cryptographically secured connection between a terminal-side secure endpoint at the payment terminal and payment-application-side secure endpoint in the security element of the terminal.
  • a secure element can be used, ie the authentication element for the authentication of the terminal in the mobile network.
  • the payment applications are designed as payment applets in the Secure Element.
  • the administration of the Secure Element involves a number of different roles. This makes the management of the Secure Element complex. Even minimal changes in the secure element may require a cooperation of several partners and thus the entire complex infrastructure of the administration. The administrative overhead does not scale with the scope of the changes. Similarly, depending on the type of administrative action, a different level of security is required. When managing the Secure Element, the security level is also non-scalable and always uses the same security infrastructure with the same level of security.
  • the Android operating system for mobile devices provides version 2.3.3 "Gingerbread” programming interfaces for the secure use of NFC technology.Thus NFC can be used in the modes “Reader / Writer” and “Peer-to-Peer” in pure software solutions (without Hardware Secure Element SE)
  • the Android version 4.4 "KitKat” also implemented the Host-based Card Emulation (HCE) system, making the NFC card emulation mode mode a purely software-implemented secure NFC solution HCE is an implemented on the terminal, purely in software realized image of an NFC Smart Card, so an NFC-enabled, equipped with an NFC antenna security element.
  • HCE Host-based Card Emulation
  • two-part run time architectures are known, which can be produced by a security operating system, secure runtime environment, also known as trusted execution environment TEE, and a normal operating system (eg Android) that can be produced.
  • TEE trusted execution environment
  • REE normal operating system
  • REE Rieh Execution Environment
  • such architectures are covered in a number of Global Platform Organization documents.
  • payment applications are typically also divided into two parts, namely a payment rich application that is implemented in the normal runtime environment and a payment trust application that is implemented in the secure runtime environment.
  • the payment trust application carries out safety-critical sub-tasks within the framework of a transaction, such as encryption / decryption, authentication, signature formation and the like.
  • the invention is based on the object of providing a secure, scalable mobile payment system and method with a reduced administrative effort.
  • complexity and security level should be scalable and complexity reduced, in particular by reducing the number of instances involved.
  • the mobile terminal according to claim 1 is in the disposal of a customer who wants to pay mobile with a dealer (seller).
  • the terminal is set up for mobile payment by a payment from the customer to the merchant via a payment service provider, which in turn is arranged to initiate a clearing of payment between customer and merchant bank servers according to transaction data generated by the merchant ,
  • the mobile terminal includes a normal runtime environment and a secure runtime environment.
  • An agent adapted to receive transaction data from a payment terminal, an authorization interface implemented in the terminal adapted to present transaction data received at the agent to the customer for authorization and to accept an authorization entered by the customer at the authorization interface, and forward, as well as a payment application implemented in the terminal, of which at least one secure share, namely a payment trust application, is implemented in the secure runtime environment, and which is set up, an authorization further directed by the authorization interface and to generate and send a transaction statement in response to the opposite authorization.
  • an authorization interface implemented in the terminal adapted to present transaction data received at the agent to the customer for authorization and to accept an authorization entered by the customer at the authorization interface, and forward, as well as a payment application implemented in the terminal, of which at least one secure share, namely a payment trust application, is implemented in the secure runtime environment, and which is set up, an authorization further directed by the authorization interface and to generate and send a transaction statement in response to the opposite authorization.
  • the agent in conjunction with the access data stored in the secure runtime environment, enables the payment trust application implemented in the secure runtime environment to prompt the payment service provider directly from the secure runtime environment with a transaction instruction for clearing.
  • the agent mediates the setup and operation of a single secure transmission link from the payment trust application in the secure runtime environment to the payment service provider.
  • the payment terminal can even be completely eliminated when sending the transaction instruction from the terminal to the payment service provider. Alternatively, the payment terminal merely initiates the transaction statement. In any case, the break of the secure transmission link that occurs at the payment terminal in the prior art is eliminated.
  • the solution does not include a secure element, it still provides a high enough level of security.
  • the secure runtime environment in which the credentials are stored is under the administration of a single instance. Therefore, in contrast to a solution with Secure Element, the access data in the secure runtime environment can be processed comparatively easily. It is not necessary to coordinate with other instances as required by a Secure Element solution. The only instance can, if necessary, even independently determine a certain level of security, depending on the security requirements that have been identified, ie scale the security level. Therefore, according to claim 1, a secure, scalable mobile payment system and method is provided with reduced overhead.
  • the authorization interface is for accepting authentication data of the customer, e.g. a PIN, password or biometric date such as Fingerprint etc. designed.
  • An input of authentication data at the authorization interface in this case causes an (active) authentication of the customer to the terminal, and at the same time an acknowledgment of the transaction by the customer.
  • the authorization interface is designed according to the type of request to be issued to the customer and the authentication data to be entered, e.g. as display (for input), keyboard (for input), touch display (for input and output), fingerprint sensor (for entering biometric fingerprint data), etc ..
  • the agent is designed as a software emulation of a smart card, in particular an Android Host-based Card Emulation HCE.
  • the agent is preferably implemented in the normal execution environment.
  • the emulation or the HCE is able to communicate outwards, out of the terminal.
  • the agent is able to communicate firstly with a payment terminal via the terminal-internal NFC controller, and secondly, to communicate with a payment service provider via a (mobile) network.
  • the emulation or the HCE is able to communicate within the terminal with the trust applications in the secure runtime environment. Two embodiments of this first, card-emulation variant are described below with reference to FIGS. 3 and 5.
  • the agent is designed as a trust application implemented in the secure runtime environment.
  • the agent can be designed as a separate agent trust application that mediates between the payment trust application and the payment service provider.
  • the payment trust application itself is provided as agent trust application. The payment trust application itself can therefore access the access data in order to operate the authentication to the payment service provider.
  • Two embodiments of this second, trust application variant are described below with reference to FIGS. 7 and 9.
  • the access data comprise at least one channel key for establishing and operating a secure channel between the secure runtime environment and the payment service provider.
  • the agent is set up to establish the secure channel according to bl) using the channel key and, in accordance with b2), to send the transaction instruction via the secure channel to the payment service provider.
  • the access data comprise a signature generation key for generating a signature.
  • the transaction instruction can be generated by the payment trust application signing the transaction data (and possibly further data) by means of the signahir generation key.
  • signing more accurately creates a signature over the transaction data, and the signature and other data, in particular the transaction data, are merged into the transaction statement so that the transaction statement is generated.
  • the payment service provider stores the corresponding signature verification key.
  • the agent is configured to send, according to bl) and b2), a transaction statement generated by signing the transaction data with the signature generation key to the payment service provider, so that the transaction data for verifying the signature can be verified for the payment service provider.
  • An inventive mobile payment method for a terminal of a customer is adapted for mobile payment by payment from the customer to a dealer via a payment service provider PSP, according to transaction data generated by the merchant / Merchant M.
  • the mobile terminal includes a normal runtime environment and a secure runtime environment.
  • the terminal further comprises an agent implemented in the terminal; an authorization interface implemented in the terminal; and a payment application implemented in the terminal, of which at least one secure share, namely a payment trust application, is implemented in the secure runtime environment.
  • the agent accepts transaction data from a payment terminal
  • transaction data received by the authorization interface at the agent are presented to the customer for authorization and an authorization entered by the customer at the authorization interface is received and forwarded;
  • an authorization relayed by the authorization interface is accepted by the payment trust application and a transaction instruction is generated and sent in response to the accepted authorization.
  • the method is characterized in that
  • the (some or all) access data itself eg channel key, see below
  • the (some or all) access data generated authentication data eg signature on Transaction data, or transaction statement comprising such a signature, su
  • the payment trust application is able to transmit the transaction statement to the payment service provider in order to trigger an order to clear the payment from the payment service provider.
  • the agent thus acts as an intermediary in the authentication between the payment trust application and the payment service provider.
  • the forwarding of the transaction instruction from the payment service provider for clearing at the bank servers takes place, for example, in a known manner.
  • the agent establishes a secure channel according to feature b1) using access data in the form of a channel key and sends in step b2) the transaction instruction via the secure channel to the payment service provider.
  • the agent sets up the secure channel to the payment service provider directly in accordance with feature b).
  • FIG. 1 An example of the first form with an agent in the form of HCE is shown in FIG.
  • FIG. 1 An example of the first form with an agent in the form of a trust application that connects to the payment service provider via a TEE socket API is shown in FIG.
  • the agent sets up the secure channel to the payment service provider via an NFC payment terminal according to feature b1), which itself does not have the access data (eg channel key, signature key), and especially the transaction instruction only passes.
  • the access data eg channel key, signature key
  • FIG. 1 An example of the second form with an agent in the form of a trust application is shown in FIG.
  • the agent In order to obtain the authorization of the transaction from the customer, it may be necessary for the agent to instruct an input / output application which issues outputs to the customer at an authorization interface of the terminal or disapproves inputs from the customer.
  • the request to the customer and the authorization of the customer are issued or received via a secure authorization interface implemented in the secure runtime environment (input, output, input / output interface).
  • a secure authorization interface implemented in the secure runtime environment (input, output, input / output interface).
  • authorization interfaces can be used to authenticate the customer, which are called directly from the secure runtime environment.
  • FIG. 2 shows a system for mobile payment in the overview, according to an embodiment of the invention
  • FIG. 3 shows a system for mobile payment in structure representation, according to a first embodiment of the invention
  • Fig. 4 is a flowchart for a transaction in a system of Fig. 3; 5 shows a system for mobile payment in structure representation, according to a second embodiment of the invention;
  • Fig. 6 is a flowchart for a transaction in a system of Fig. 5;
  • Fig. 7 is a system for mobile payment in structure representation, according to a third embodiment of the invention.
  • Fig. 8 is a flowchart for a transaction in a system of Fig. 7; 9 shows a system for mobile payment in structure representation, according to a fourth embodiment of the invention.
  • FIG. 10 is a flowchart for a transaction in a system of FIG. 9.
  • Fig. 1 shows a system for mobile payment, according to the prior art.
  • the system comprises a merchant server M of a merchant, a mobile terminal D used by a customer ("Device"), an NFC payment terminal PT (Payment terminal), a payment terminal.
  • the system in the narrower sense is formed by the mobile terminal D, the NFC payment terminal FT and the payment service provider server PSP
  • the merchant server M and the bank servers CB, MB complete the system.
  • the communication channel between the terminal D and the payment service provider server PSP comprises two partial routes, namely a first partial route between the mobile terminal D and the NFC payment terminal PT, and a second partial route between the NFC payment terminal PT and the payment service provider Server PSP.
  • first access data are agreed between the mobile terminal D and the NFC payment terminal PT
  • second, independent access data is agreed between the NFC payment terminal PT and the payment service provider server PSP, independent of the first access data.
  • the authentication by means of the access data can either be designed as a structure and operation of a secure channel between the respective communication partners, or as the generation of a signature at one communication partner and verification of the signature at the other communication partner.
  • the merchant server sends transaction data (or transaction information) T to the NFC currency terminal PT.
  • the core part of the conventional method according to FIG. 1, which is particularly important for the invention, starts at this point at the NFC payment terminal PT.
  • the NFC payment terminal PT sends the transaction data T in an authenticated secure NFC connection to the mobile terminal D.
  • the customer is requested by an output at his terminal D to confirm the transaction data T.
  • the customer authenticates himself with an input on the terminal D and confirmed by his input the transaction data T.
  • the output to the customer for example, by displaying an input mask on the touch screen of the terminal D.
  • the input is made eg by entering the displayed input mask on the touch
  • the type and strength of the authentication is determined by the application, the technical features and capabilities of the terminal D as well as the policies of the payment service provider PSP and is not relevant to the method upon the user's input
  • a transaction statement TR signs it with first access data and sends the signed transaction statement TR over the first leg to the NFC payment terminal PT
  • the NFC payment terminal verifies the signature, re-signs the transaction statement TR itself with second access data and transmits over the second leg the transaction statement TR to the payment service provider server PSP.
  • the terminal D does not have the second access data.
  • the payment service provider server PSP does not have the first access data.
  • the completion of the transaction includes the payment service provider server PSP sending a payment instruction to the customer bank server CN, and the customer bank server CB making the payment according to the payment instruction to the merchant bank server MB.
  • Fig. 2 shows a mobile payment system according to an embodiment of the invention.
  • a payment in the system of Fig. 2 differs in the core part of a payment in the conventional system of Fig. 1.
  • the mobile terminal in contrast to the system of FIG. 1, in the system of FIG. 2, the mobile terminal necessarily has a secure runtime environment TEE.
  • access data have been agreed between terminal D and payment service provider PSP.
  • the NFC payment terminal PT initially sends the transaction data T via an NFC connection to the mobile terminal D as in the conventional method.
  • the terminal D generates a transaction according to the input of the user. onsandorf Signed (T) by the transaction data T and possibly further data with the access data signed and attached to the transaction data in plain text.
  • the transaction statement Signed (T) thus generated now includes the transaction data T in plain text and a signature on the (or some of) the transaction data T.
  • the stock of transaction data T may change in the course of the process, eg by adding or omitting individual elements (eg date-time stamp, customer, reference ID, ...) of transaction data T.
  • the terminal D therefore has the access data and not the payment terminal FT as in FIG.
  • the functional part of the NFC coverage terminal PT involved in the clearing of the bank servers is moved to the terminal D.
  • TR Signed (T)
  • TR Signed (T))
  • an agent is provided in the terminal D for the communication of the terminal D with a payment service provider PSP, which is implemented in the normal runtime environment REE and is designed as Android Host Card Emulation HCE.
  • an agent is provided in the terminal D for the communication of the terminal D with a payment service provider PSP, which is implemented in the secure running time environment TEE as a trusted application. More precisely, the agent according to FIGS. 7 and 9 is integrated into the payment trust application TA.
  • An NFC interface NFC of the terminal D is also implemented in the systems according to FIGS. 7 and 9 under control of the secure runtime environment TEE.
  • a driver for a trusted user interface (touch display of the terminal D) TUI is implemented in the secure runtime environment TEE, ie a variant of a display driver GUI ("Trusted User Interface", TUI) implemented in the secure runtime environment TEE.
  • FIG. 9 the communication between terminal D and payment service provider PSP takes place via a payment terminal FT (which, however, only functions as a transit station).
  • the agent is set up to directly contact the payment service provider PSP.
  • Fig. 3 shows a system for mobile payment in structural representation, according to a first embodiment of the invention.
  • the system comprises a terminal D, a payment terminal PT, a payment service provider PSP and a merchant server M.
  • the terminal D comprises an NFC interface NFC, a normal runtime environment REE and a secure runtime environment TEE.
  • the normal runtime environment REE comprises an agent designed as Android Host Card Emulation HCE and a display driver GUI for controlling a touch display of the terminal D.
  • the agent HCE is used to convey the communication of the NFC interface NFC with instances within the normal Runtime environment REE and also set up in the secure runtime environment TEE.
  • the secure runtime environment TEE is controlled by a security operating system TEE-OS and comprises a payment trust application TA (ie the secure portion of a payment application of the terminal D whose possibly additionally existing unsafe portion is not shown in the normal runtime environment REE is) and personalization data perso to the payment trust application TA or to the entire payment application.
  • the personalization data Perso comprise access data agreed between the terminal D and the payment service provider PSP, which are designed here as cryptographic keys for generating a signature.
  • the merchant server M sends transaction data T to the payment terminal PT and indicates to the customer that he should now pay with his NFC-capable terminal D.
  • 1.1 The customer keeps his terminal D in NFC range to the payment terminal PT and thereby initiates NFC communication between the terminal D and the payment terminal PT.
  • the terminal D in step 1.1 the payment terminal PT the Ap- plication identifier AID of the payment transaction application or payment trust application to be used with.
  • the payment terminal sends the transaction data T (and the application identifier AID, not explicitly shown) to an NFC interface NFC of a terminal D.
  • the transaction data T and the AID can be packaged for the NFC dispatch, for example, in an NFC tag which is unpacked again in the terminal D to extract the transaction data T and the AID.
  • the NFC interface sends the transaction data T (and the AID) (eg in an APDU command) to the agent HCE.
  • the agent HCE first sends the transaction data T to the display driver GUI, which is the customer from the holder of the terminal D, a confirmation of the transaction data T requests.
  • a customer authentication Auth eg PIN, password, fingerprint, etc.
  • the agent HCE sends the confirmed transaction data T and the AID to the payment trust application TA.
  • the payment trust application TA accesses the personalization data Perso, reads the required access data, more precisely the signature generation key, and uses the signature generation key to sign the transaction data T to form a signature.
  • the payment trust application TA further combines the confirmed transaction data T and the signature into a transaction statement Signed (T).
  • the payment trust application TA sends the transaction instruction Signed (T) to the agent HCE.
  • the agent HCE sends the transaction instruction Signed (T) (eg in an APDU command) to the NFC interface, which contains the
  • Transaction instruction Signed (T) continues to the payment terminal PT sends.
  • the payment terminal PT forwards the signed transaction statement Signed (T) without its own processing to the payment service provider PSP.
  • the payment service provider PSP verifies the signature of the trans- action statement Signed (T) and, in the case of positive verification, initiates the clearing of the transaction via the bank servers MB, CB from the merchant and the customer.
  • Step 3 After initiating the clearing, the payment service provider PSP sends to the payment terminal PT a so-called “Approval” A (confirmation from the PSP about the effected transaction) about the effected transaction 3.1: The payment terminal PT forwards the approval A ( T), eg in an acknowledgment R (Receipt), to the merchant server M. 3.2: The payment terminal PT forwards the approval A supplemented by a date and time stamp "dateTime" to the agent HCE for information.
  • FIG. 4 shows a flowchart for a transaction in a system according to FIG. 3, which shows in particular the stock of transaction data T in the course of the method.
  • the transaction data T includes the seller "vendor” (usually this is the merchant) and the amount "amount.”
  • the signature generation key has been read (step 2.4)
  • the transaction data T is supplemented by a designation of the customer "customer.”
  • the transaction data T is signed with the signature generation key
  • the signature generated in this way is "signature” and the supplemented transaction data T. to a transaction statement signed (T), which is sent to the payment service provider PSP (step 2.6).
  • the approval A from the payment terminal PT to the agent HCE in the terminal D includes as transaction data T the seller "vendor", the amount "amount” and a date / time stamp "dateTime”.
  • Fig. 5 shows a system for mobile payment in structural representation, according to a second embodiment of the invention.
  • a plurality of elements is designed as in the first embodiment of FIG. 3, 4 and will not be further described at this point.
  • the agent HCE has additional functionalities in comparison to the agent HCE from FIG. 3, in that it can directly contact the payment service provider PSP.
  • the method begins first as in the first embodiment with steps 1 to 2.5 of FIG. 3.
  • the system is in the status that the agent HCE from the customer and confirmed by the payment trust application TA with access data (signature generation key) signed transaction data T, and hereby a transaction instruction signed (T) has been generated.
  • the agent HCE now sends the transaction instruction Signed (T) directly to the payment service provider PSP.
  • the payment service provider PSP verifies the signature in the transaction statement Signed (T) with the signature verification key and, in the event of a positive verification, initiates the clearing of the transaction via the bank servers MB, CB from the merchant and the customer.
  • the payment service provider PSP sends to the agent HCE of the terminal D a receipt, a so-called "receipt" R.
  • the agent HCE packs the receipt R into an APDU command and, step 2.8, forwards it to the NFC interface NFC, which unpacks the APDU command, extracts the receipt R and forwards the receipt R to the payment terminal PT
  • the payment terminal PT sends the receipt R to the merchant server M for information.
  • FIG. 6 shows, analogously to FIG. 4, a flowchart for a transaction in a system according to FIG. 5, from which in particular the stock of transaction data T emerges in the course of the method.
  • steps 1 to 2.3 include the Transaction data seller "vendor” and amount “amount”.
  • the signature generation key step 2.4
  • the transaction data T is supplemented and signed by the customer "customer.”
  • the signature "signature” is appended to the transaction data T.
  • This generates the transaction statement Signed (T).
  • This is finally sent to the payment service provider PSP (step 2.6).
  • the receipt Receipt R sent by the agent HCE of the terminal D to the payment terminal PT in step 2.8 comprises the transaction data T seller "vendor", amount “amount” and the date and time stamp "dateTime”.
  • step 7 shows a system for mobile payment in structural representation, according to a third embodiment of the invention, wherein the agent is integrated in the secure runtime environment TEE in the payment trust application TA.
  • transaction data T is sent from a merchant server M to a payment terminal PT, and in step 2: the transaction data T and an AID of FIG Payment trust application TA sent to an NFC interface NFC terminal D.
  • the NFC interface NFC is under the control of a safety operating system TEE-OS, by means of which the safe runtime environment TEE is controlled.
  • the reception process 2 at the NFC interface NFC the transaction data T are transferred directly into the secure runtime environment TEE.
  • the transaction data T and the AID are routed (still step 2) through the NFC interface to the payment trust application TA.
  • the payment trust application TA initiates via a secure user interface driver TUI implemented in the secure runtime environment TEE that the customer is authenticated in a suitable manner at the terminal D in order to confirm the transaction.
  • the user interface driver TUI is taking an acknowledgment / authentication A (Auth) entered by the customer and forwards the confirmation / authentication A to the payment trust application TA.
  • Auth acknowledgment / authentication A
  • the payment trust application reads from the personalization data Perso access data "Keys" in the form of a signature generation key, signs the transaction data T, thereby generates a signature and adds transaction data T and signature to a transaction statement Signed (T 2.4:
  • the payment trust application TA sends via a TEE-internal socket API (special Supplementary API) the transaction statement Signed (T) to the payment service provider PSP, the signature from the transaction statement Signed (T) with the verifies the appropriate signature verification key and initiates clearing in good case; and, 2.5 sends back a receipt "Receipt" R to the TEE socket API; continue 2.5: the TEE socket API sends the receipt R on to the payment trust application TA.
  • the payment trust application TA sends the acknowledgment R via the secure NFC driver NFC to the payment terminal PT, which, 3.1, forwards the receipt R to the merchant server M for information.
  • FIG. 8 again illustrates an overview of the transaction and the changeable stock of the transaction data involved. V.
  • the Merchant server M sends transaction data T (at least dealer, amount) to the payment terminal PT inviting the customer to approach the terminal D.
  • the customer keeps the terminal D in NFC range to the payment terminal PT.
  • the Za ungsterrninal PT sends the transaction data T to the terminal D, directly into the secure runtime environment TEE.
  • the payment trust application TA sends the transaction data T to a secure input / output interface, namely a Secure World GUI (Graphical User Interface), called Trusted User Interface TUI, of the terminal D, eg a secure (touch) display whose driver is implemented in the TEE; the- it displays the transaction data (at least dealer, amount) to the customer; the customer authenticates himself at the terminal and thereby confirms the transaction data.
  • a secure input / output interface namely a Secure World GUI (Graphical User Interface), called Trusted User Interface TUI
  • the payment service provider PSP verifies the transaction data T by means of the signature, adds a reference ID to the transaction data T and, 2.5, in the event of positive signature verification, sends back to the payment trust application TA an approval A (ie a confirmation) (T now including dealer, amount, date, time, reference ID).
  • the payment trust application TA sends the approval A to the payment terminal PT, which forwards it, 3.1, to the merchant server for information.
  • FIG. 9 shows a system for mobile payment in structural representation, according to a fourth embodiment of the invention, the agent, as in FIG. 7, being integrated into the payment trust application TA in the secure runtime environment TEE.
  • the fourth embodiment according to FIG. 9 does not use any possibility of transmitting a signed transaction instruction Signed (T) directly to the Payment Service Provider PSP. Accordingly, the TEE socket API of FIG. 7 is missing. Instead, in steps 2.4 + 3, the transaction statement Signed (T) is implemented via the secure NFC interface NFC of the terminal D implemented under control of the security operating system TEE-OS and via the payment terminal PT the payment service provider PSP sent. The steps te 1 to 2.3 take place as in FIG. 7.
  • the transaction data are displayed to the customer at the secure user interface TUI.
  • the customer authenticates himself by means of the authenticators offered and accepted at the terminal D (eg PIN entry etc. via TUI).
  • the TA calculates the signature on the transaction data T by means of the signature generation key stored in the secure area (key was inserted eg in case of personalization).
  • the confirmed and signed transaction Signed (T) is transmitted via the NFC interface to the payment terminal PT.
  • the signed and confirmed transaction Signed (T) is forwarded to the payment service provider PSP, without its own processing in the payment terminal PT.
  • the Payment Service Provider PSP checks the signature and, if successful, sends a Receipt R to the Zoning Monitor PT, completing the payment transaction.
  • the payment terminal PT also sends the receipt to the merchant server M.
  • Fig. 10 shows a flowchart in which communication streams and the varying stock of transaction data T (dealer "vendor”, amount “amount”, date and time stamp “dateTime”, reference ID “ref-ID”) in the course a payment in the system of Fig. 9 are shown.

Landscapes

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

Abstract

Die Erfindung schafft ein mobiles Endgerät (D) eines Kunden, eingerichtet zum mobilen Bezahlen durch eine Zahlung gemäß Transaktionsdaten (T) vom Kunden an einen Händler über einen Payment Service Provider (PSP), der dazu eingerichtet ist, ein Clearing der Zahlung zwischen Bankenservern. Das mobile Endgerät (D) umfasst: - eine normale Laufzeitumgebung (REE) und eine sichere Laufzeitumgebung (TEE); - einen Agenten (HCE; TA); - eine Autorisierungs-Schnittstelle (GUI; TUI), - eine Zahlungs-Applikation, von der zumindest ein sicherer Anteil, nämlich eine Zahlungs-Trust-Applikation (TA), in der sicheren Laufzeitumgebung (TEE) implementiert ist. Das Endgerät ist dadurch gekennzeichnet, dass a) in der sicheren Laufzeitumgebung (TEE) Zugangsdaten für eine Authentisierung zwischen der Zahlungs-Trust-Applikation (TA) und dem Payment Service Provider (PSP) gespeichert sind; und b) der Agent (HCE; TA) weiter dazu eingerichtet ist, b1) anlässlich einer Authentisierung zwischen der Zahlungs-Trust-Applikation (TA) und dem Payment Service Provider (PSP), Zugangsdaten oder unter Verwendung von Zugangsdaten erzeugte Authentisierungsdaten zwischen der sicheren Laufzeitumgebung (TEE) und dem Payment Service Provider (PSP) zu übermitteln, und b2) von der Zahlungs-Trust-Applikation (TA) eine Transaktionsanweisung (Signed(T)) für eine Zahlung gemäß den Transaktionsdaten (T) entgegenzunehmen und an den Payment Service Provider (PSP) zu senden. Ein entsprechendes mobiles Bezahlverfahren für ein Endgerät wird ebenfalls angegeben.

Description

ENDGERÄT UND VERFAHREN FÜR MOBILES BEZAHLEN MIT TRUSTED EXECUTION ENVIRONMENT
Gebiet der Erfindung
Die Erfindung betrifft ein mobiles Endgerät und ein Verfahren zum mobilen Bezahlen mittels eines mobilen Endgeräts eines Kunden an einen Händler.
Stand der Technik
Bekannte mobile elektronische Bezahlsysteme umfassen ein NFC-fähiges (Near Field Communication) mobiles Endgerät (z.B. Mobiltelefon, Smart- phone oder ähnliches Device) eines Kunden oder potentiellen Käufers - kurz NFC-Endgerät - , ein externes Zahlungsterminal, einen Payment Service Provider sowie Bankenserver von Kunde und Händler. Die Bankenserver umfassen einen Kunden-Banken-Server, auf dem ein Konto des Kunden geführt wird, und einen Händler-Bankenserver, auf dem ein Konto des Händ- lers geführt wird. Das Endgerät umfasst eine Zahlungs- Applikation (oder mehrere) und einem NFC-Controller mit Antenne. Zahlungs-Applikationen im Endgerät können beispielsweise die Form virtueller elektronischer Zahlungskarten (eCards) oder elektronischer Geldbörsen (eWallets) haben. Der NFC-Controller ermöglicht eine NFC- Verbindung zwischen dem Endgerät und dem externen Zahlungsterminal (z.B. POS = Point of Sale).
In dieser Anmeldung wird der Begriff des Kunden für einen Zahlungsleister einer Zahlung und der Begriff des Händlers für einen Zahlungsempfänger der Zahlung im weitesten Sinn verstanden. Aspekte wie z.B. der, in welcher Rolle und Form Kunde und Händler tätig sind, z.B. privat oder gewerblich, sind dagegen unerheblich.
Im Gesamtüberblick umfasst eine mobile Zahlung vom Endgerät eines Kunden an den Händler folgende Schritte. Der Händler erstellt aus Transakti- onsdaten T (umfassend zumindest Zahlungsempfänger (Händler, Verkäufer, ...) und Betrag) eine Zahlungsaufforderung und sendet sie an das Zahlungs- terminal. Der Kunde hält sein Endgerät an das Zahlungsterminal. Das Zahlungsterminal sendet daraufhin die Transaktionsdaten T über die NFC- Schnittstelle an das Endgerät, um eine Zahlungsaufforderung an das Endgerät auszugeben. Im Endgerät werden die über NFC empfangenen Transakti- onsdaten T an die Zahlungs- Applikation geleitet (ggf. nach Auswahl einer von mehreren Zahlungs- Applikationen). Die Zahlungs- Applikation präsentiert die Transaktionsdaten dem Kunden und authentisiert den Kunden. Die erfolgreiche Authentisierung wird als Autorisierung oder Bestätigung (seitens des Kunden) der Transaktionsdaten interpretiert. Die Zahlungs- Applikation sendet auf die Autorisierung / Bestätigung hin eine Transaktionsanweisung entsprechend den Transaktionsdaten an das Zahlungsterminal. Das ZaWungsterminal wiederum beauftragt, sich berufend auf die Transaktionsanweisung, den gegenüber den Bankenservern autorisierten Payment Service Provider mit dem Clearing der Zahlung bei den Banken- Servern. Die Bankenserver von Kunde und Händler führen schließlich das Clearing der Zahlung durch, d.h. bewirken, dass Geld gemäß der Zahlung vom Konto des Kunden auf das Konto des Händlers übertragen wird.
Bekannte mobile Zahlungen werden durch Authentisierung gegen Manipu- lation geschützt. Um die Authentisierung zu ermöglichen, ist die Zahlungs- Applikation in einem im Endgerät vorgesehenen Sicherheitselement implementiert. Die Zahlungs- Applikation umfasst neben der eigentlichen Applikation zur Zahlungs- Applikation gehörige Authentisierungsdaten (z.B.
kryptographische Schlüssel), und ggf. weitere Personalisierungsdaten oder Kundendaten (z.B. (Kredit-) Kartennummern oder Bankkonto-Daten).
Technisch kann die Authentisierung beispielsweise mittels einer Signatur erfolgen. Hierbei wird im Endgerät mittels Zugangsdaten (hier insbesondere mittels eines privaten Schlüssels eines asymmetrischen public-private Key Schlüsselpaares) eine Signatur über Transaktionsdaten erzeugt und aus den signierten Transaktionsdaten (d.h. der Signatur) und weiteren Daten (z.B. den Transaktionsdaten in Klartext) eine Transaktionsanweisung erzeugt. Die Transaktionsanweisung wird vom Endgerät über die NFC Schnittstelle an das Zahlungsterminal gesendet. Im Zahlungsterminal wird die Transaktionsanweisung / Signatur verifiziert (insbesondere mit dem entsprechenden öffentlichen Schlüssel zum privaten Schlüssel).
Alternativ erfolgt die Authentisierung, indem zwischen dem Endgerät und dem Zahlungsterminal mittels Zugangsdaten (z.B. kryptographischer
Schlüssel) ein Secure Channel (d.h. ein durch Authentisierung und Schlüsselableitung kryptographisch gesicherter Kanal) eingerichtet wird und die Transaktionsanweisung über den Secure Channel vom Endgerät an das Zahlungsterminal gesendet wird.
Die Authentisierung wird über eine Ende-zu-Ende kryptographisch gesicherte Verbindung zwischen einem Terminal-seitigen sicheren Endpunkt beim Zahlungsterminal und Zahlungs-Applikations-seitigen sicheren Endpunkt im Sicherheitselement des Endgeräts realisiert.
Als Sicherheitselement kann beispielsweise ein Secure Element verwendet werden, d.h. das Authentisierungselement zur Authentisierung des Endgeräts im Mobilfunknetz. Als Secure Element ist z.B. ein UICC (Universal Inte- grated Circuit Card), eine SIM-Karte (SIM = Subscriber Identity Module) o- der ein eUICC (embedded UICC) vorgesehen. Die Zahlungs- Applikationen sind im Secure Element als Zahlungs- Applets gestaltet. Bei der Verwaltung des Secure Element sind eine Vielzahl von unterschiedlichen Stellen beteiligt. Dies gestaltet die Verwaltung des Secure Element komplex. Auch minimale Änderungen im Secure Element benötigen unter Umständen eine Kooperation von mehreren Partnern und damit die gesamte komplexe Infrastruktur der Verwaltung. Der Verwaltungsaufwand skaliert hierbei also nicht mit dem Umfang der Änderungen. Ähnlich ist in Abhängigkeit von der Art einer Verwaltungsmaßnahme ein unterschiedliches Maß an Sicherheit erforderlich. Bei der Verwaltung des Secure Element ist auch das Sicherheitsniveau nicht skalierbar, sondern es wird stets dieselbe Sicherheits- Infrastruktur mit demselben Sicherheitsniveau verwendet.
Das Android Betriebssystem für mobile Endgeräte stellt seit Version 2.3.3 „Gingerbread" Programmierschnittstellen zur sicheren Nutzung der NFC Technologie bereit. Damit kann NFC in den Betriebsarten„ Reader/ Writer" und„Peer-to-Peer" in reinen Software-Lösungen (ohne Hardware Secure Element SE) genutzt werden. Mit der Android Version 4.4„KitKat" wurde zudem das System der Host-based Card Emulation (HCE) implementiert, wodurch die NFC Betriebsart„Card Emulation Mode" für eine rein in Software verwirklichte sichere NFC-Lösung verfügbar wird. HCE ist ein auf dem Endgerät implementiertes, rein in Software verwirklichtes Abbild einer NFC Smart Card, also eines NFC-fähigen, mit einer NFC- Antenne ausgestatteten Sicherheitselements.
Für mobile Endgeräte sind zweigeteilte Lauf Zeitarchitekturen bekannt, die eine durch ein Sicherheitsbetriebssystem herstellbare sichere Lauf zeitumge- bung, auch Trusted Execution Environment TEE genannt, und eine durch ein Normalbetriebssystem (z.B. Android) herstellbare normale Laufzeitum- gebung, auch Rieh Execution Environment REE genannt, umfassen. Solche Architekturen sind beispielsweise in einer Reihe von Dokumenten der Global Platform Organisation behandelt. In einem mobilen Endgerät mit sicherer Laufzeitumgebung sind Zahlungs-Applikationen typischerweise eben- falls zweigeteilt, nämlich in eine Zahlungs-Rich- Applikation, die in der normalen Laufzeitumgebung implementiert ist, und eine Zahlungs-Trust- Applikation, die in der sicheren Laufzeitumgebung implementiert ist. Die Zahlungs-Trust- Applikation führt sicherheitskritische Teil- Aufgaben im Rahmen einer Transaktion durch, wie Ver-/ Entschlüsselung, Authentisie- rung, Signaturbildung und dergleichen.
Zusammenfassung der Erfindung
Der Erfindung liegt die Aufgabe zu Grunde, ein sicheres, skalierbares mobiles Bezahlsystem und -verfahren mit einem verringerten Verwaltungsauf - wand zu schaffen. Insbesondere sollen Aufwand und Sicherheitslevel skalierbar sein und die Komplexität verringert sein, insbesondere durch Verringerung der Anzahl von beteiligten Instanzen.
Die Aufgabe wird gelöst durch ein Endgerät nach Anspruch 1. Vorteilhafte Ausgestalrungen der Erfindung sind in abhängigen Ansprüchen angegeben.
Das mobile Endgerät nach Anspruch 1 ist in der Verfügung eines Kunden, der damit bei einem Händler (Verkäufer) mobil bezahlen möchte. Das Endgerät ist eingerichtet zum mobilen Bezahlen durch eine Zahlung vom Kun- den an den Händler über einen Payment Service Provider, der wiederum dazu eingerichtet ist, ein Clearing der Zahlung zwischen Bankenservern von Kunde und Händler zu veranlassen, gemäß Transaktionsdaten, die vom Händler generiert werden. Das mobile Endgerät umf asst eine normale Laufzeitumgebung und eine sichere Lauf zeitumgebung. Es umf asst weiter einen Agenten, der dazu eingerichtet ist, Transaktionsdaten von einem Zahlungsterminal entgegenzunehmen, eine im Endgerät implementierte Autorisierungs-Schnittstelle, die dazu eingerichtet ist, am Agenten empfangene Transaktionsdaten an den Kunden zur Autorisierung zu präsentieren und eine vom Kunden an der Autorisierungs-Schnittstelle eingegebene Autorisierung entgegenzunehmen und weiterzuleiten, sowie eine im Endgerät implementierte Zahlungs- Applikation, von der zumindest ein sicherer Anteil, nämlich eine Zahlungs-Trust- Applikation, in der sicheren Laufzeitumgebung implementiert ist, und die dazu eingerichtet ist, eine von der Autorisie- rungs-Schnittstelle weiter geleitete Autorisierung entgegenzunehmen und in Reaktion auf die entgegengenommeine Autorisierung eine Transaktionsanweisung zu erzeugen und zu senden.
Das Endgerät ist dadurch gekennzeichnet, dass:
a) in der sicheren Laufzeitumgebung Zugangsdaten für eine Authentisie- rung zwischen der Zahlungs-Trust- Applikation (Trustlet) und dem Payment Service Provider gespeichert sind; und
b) der Agent dazu eingerichtet ist,
bl) anlässlich einer Authentisierung zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider, entweder die Zugangsdaten selbst (oder zumindest manche der Zugangsdaten), oder alternativ unter Verwendung der Zugangsdaten (oder zumindest mancher der Zugangsdaten) erzeugte Authentisierungsdaten zwischen der sicheren Laufzeitumgebung und dem Payment Service Provider zu übermitteln, und
b2) von der Zahlungs-Trust- Applikation eine Transaktionsanweisung für eine Zahlung gemäß den Transaktionsdaten entgegenzunehmen und an den Payment Service Provider zu senden. Beim Stand der Technik bedeutet das Senden einer Transaktionsanweisung vom Endgerät an das Zahlungsterminal stets, dass die Transaktionsanweisung die sichere Laufzeitumgebung verlässt. Folglich muss die Transaktionsanweisung kryptographisch abgesichert sein, z.B. in einem Kryptogramm verschlüsselt. Der erfindungsgemäße Agent in Verbindung mit den in der sicheren Laufzeitumgebung abgespeicherten Zugangsdaten ermöglicht dagegen der in der sicheren Laufzeitumgebung implementierten Zahlungs- Trust- Applikation, den Payment Service Provider direkt aus der sicheren Laufzeitumgebung heraus mit einer Transaktionsanweisung zum Clearing aufzufordern. Dabei vermittelt der Agent den Aufbau und Betrieb einer einzelnen sicheren Übertragungsstrecke von der Zahlungs-Trust- Applikation in der sicheren Laufzeitumgebung bis hin zum Payment Service Provider. Das ZaWungsterminal kann beim Senden der Transaktionsanweisung vom Endgerät an den Payment Service Provider sogar vollständig entfallen. Alterna- tiv leitet das Zahlungsterminal die Transaktionsanweisung lediglich durch. In jedem Fall entfällt der Bruch der sicheren Übertragungsstrecke, der beim Stand der Technik am Zahlungsterminal auftritt. Obwohl die Lösung kein Secure Element umfasst, wird dennoch ein ausreichend hohes Niveau an Sicherheit erreicht. Die sichere Laufzeitumgebung, in der die Zugangsdaten abgespeichert sind, steht unter Verwaltung einer einzigen Instanz. Daher können im Unterschied zu einer Lösung mit Secure Element die Zugangsdaten in der sicheren Lauf zeitumgebung vergleichsweise einfach bearbeitet werden. Eine Abstimmung mit anderen Instanzen, wie sie bei einer Secure Element Lösung erforderlich ist, ist nicht erforderlich. Die einzige Instanz kann bedarfsweise sogar, abhängig von festgestellten Sicherheitsanforderungen, eigenständig ein bestimmtes Sicherheitsniveau festlegen, also das Sicherheitsniveau skalieren. Daher ist gemäß Anspruch 1 ein sicheres, skalierbares mobiles Bezahlsystem und -verfahren mit einem verringerten Verwaltungsaufwand geschaffen.
Die Autorisierungs-Schnittstelle ist zur Entgegennahme von Authentisie- rungsdaten des Kunden wie z.B. einer PIN, eines Passworts oder eines biometrischen Datums wie z.B. Fingerabdrucks etc. gestaltet. Eine Eingabe von Authentisierungsdaten an der Autorisierungs-Schnittstelle bewirkt hierbei eine (aktive) Authentisierung des Kunden gegenüber dem Endgerät, und gleichzeitig eine Bestätigung der Transaktion durch den Kunden. Die Auto- risierungs-Schnittstelle ist entsprechend der Art der an den Kunden auszugebenden Aufforderung und der einzugebenden Authentisierungsdaten gestaltet, z.B. als Display (für Eingabe), Tastatur (für Eingabe), Touch-Display (für Aus- und Eingabe), Fingerabdrucksensor (für Eingabe biometrischer Finger abdruckdaten), etc..
Gemäß einer ersten Ausführungs- Variante ist der Agent als eine Software- Emulation einer Smartcard, insbesondere eine Android Host-based Card Emulation HCE, gestaltet. Bei dieser Ausführungs- Variante ist der Agent vorzugsweise in der normalen Ausführungsumgebung implementiert. Die Emulation bzw. der HCE ist einerseits in der Lage, nach außen, nach aus dem Endgerät heraus, zu kommunizieren. Nach außen vermag der Agent genauer erstens über den Endgerät-internen NFC-Controller mit einem Zahlungsterminal zu kommunizieren, und zweitens mit einem Payment Service Provider über ein (mobiles) Netzwerk zu kommunizieren. Andererseits ist die Emulation bzw. der HCE in der Lage, innerhalb des Endgeräts mit der Trust- Applikationen in der sicheren Laufzeitumgebung zu kommunizieren. Zwei Ausführungsbeispiele dieser ersten, Card-Emulations- Variante sind weiter unten anhand von Fig. 3 und Fig. 5 beschrieben. Gemäß einer zweiten Ausführungs- Variante ist der Agent als eine in der sicheren Laufzeitumgebung implementierte Trust- Applikation gestaltet. Der Agent kann dabei als gesonderte Agenten-Trust- Applikation gestaltet sein, die zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider vermittelt. Alternativ ist als Agenten-Trust- Applikation die Zahlungs-Trust-Applikation selbst vorgesehen. Die Zahlungs-Trust- Applikation selbst kann also auf die Zugangsdaten zugreifen, um die Authentisierung zum Payment Service Provider zu betreiben. Zwei Ausführungsbeispiele dieser zweiten, Trust- Applikations- Variante sind weiter unten anhand von Fig. 7 und Fig. 9 beschrieben.
Die Zugangsdaten umfassen gemäß einer ersten Ausführungs- Variante der Authentisierung zumindest einen Channel-Schlüssel zum Aufbau und Betrieb eines Secure Channel zwischen der sicheren Laufzeitumgebung und dem Payment Service Provider. Hierbei ist der Agent dazu eingerichtet, gemäß bl) unter Verwendung des Channel-Schlüssels den Secure Channel einzurichten und gemäß b2) die Transaktionsanweisung über den Secure Channel an den Payment Service Provider zu senden. Gemäß einer zweiten Ausführungs- Variante der Authentisierung umfassen die Zugangsdaten einen Signatur-Erzeugungsschlüssel zum Erzeugen einer Signatur. Hierbei ist die Transaktionsanweisung erzeugbar, indem die Zahlungs-Trust-Applikation die Transaktionsdaten (und evtl. weitere Daten) mittels des Signahir-Erzeugungsschlüssels signiert. Vorzugsweise wird durch das Signieren genauer eine Signatur über die Transaktionsdaten erzeugt, und die Signatur und weitere Daten, insbesondere die Transaktionsdaten, werden zu der Transaktionsanweisung zusammengefügt, so dass die Transaktionsanweisung erzeugt wird. Beim Payment Service Provider ist der entsprechende Signatur- Verifizierungsschlüssel gespeichert. Der Agent ist dazu eingerichtet, gemäß bl) und b2) eine mit Signieren der Transaktionsdaten mit dem Signatur-Erzeugungsschlüssels erzeugte Transaktionsanweisung an den Payment Service Provider zu senden, so dass für den Payment Service Provider die Transaktionsdaten über die Verifizierung der Signatur verifizierbar sind.
Ein erfindungsgemäßes mobiles Bezahlverfahren für ein Endgerät eines Kunden nach Anspruch 7 ist eingerichtet zum mobilen Bezahlen durch Zahlung vom Kunden an einen Händler über einen Payment Service Provider PSP, gemäß Transaktionsdaten die vom Händler /Merchant M erzeugt werden. Das mobile Endgerät umfasst eine normale Laufzeitumgebung und eine sichere Laufzeitumgebung. Das Endgerät umfasst weiter einen im Endgerät implementierten Agenten; eine im Endgerät implementierte Autorisierung- Schnittstelle; und eine im Endgerät implementierte Zahlungs- Applikation, von der zumindest ein sicherer Anteil, nämlich eine Zahlungs-Trust- Applikation, in der sicheren Lauf zeitumgebung implementiert ist.
Bei dem Verfahren sind die Schritte vorgesehen, dass:
- durch den Agenten Transaktionsdaten von einem Zahlungsterminal entge- gengenommen werden;
- durch die Autorisierungs-Schnittstelle am Agenten empfangene Transaktionsdaten an den Kunden zur Autorisierung präsentiert werden und eine vom Kunden an der Autorisierungs-Schnittstelle eingegebene Autorisierung entgegengenommen und weitergeleitet wird;
- durch die Zahlungs-Trust- Applikation eine von der Autorisierungs- Schnittstelle weitergeleitete Autorisierung entgegengenommen wird und in Reaktion auf die entgegengenommene Autorisierung eine Transaktionsanweisung erzeugt wird und gesendet wird. Das Verfahren ist dadurch gekennzeichnet, dass
a) zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider eine Authentisierung unter Verwendung von in der sicheren Lauf zeit- umgebung gespeicherten Zugangsdaten durchgeführt wird; und
b) durch den Agenten:
bl) anlässlich der Authentisierung zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider, die (manche oder alle) Zugangsdaten selbst (z.B. Channel-Schlüssel, s.u.) oder unter Verwendung der (mancher oder aller) Zugangsdaten erzeugte Authentisierungsdaten (z.B. Signatur über Transaktionsdaten, bzw. Transaktionsanweisung umfassend eine solche Signatur, s.u.) zwischen der sicheren Laufzeitumgebung und dem Payment Service Provider übermittelt werden; und
b2) die von der Zahlungs-Trust- Applikation gesendete Transaktionsanweisung entgegengenommen wird und an den Payment Service Provider ge- sendet wird.
Mit Unterstützung des Agenten vermag die Zahlungs-Trust- Applikation die Transaktionsanweisung gesichert zum Payment Service Provider zu übermitteln, um beim Payment Service Provider einen Auftrag zum Clearing der Zahlung auszulösen. Der Agent agiert somit als Vermittler in der Authentisierung zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider. Die Weiterleitung der Transaktionsanweisung vom Payment Service Provider zum Clearing bei den Bankenservern erfolgt dabei beispielsweise auf bekannte Weise.
Gemäß einer ersten Ausführungs-Variante der Authentisierung richtet der Agent gemäß Merkmal bl) unter Verwendung von Zugangsdaten in Gestalt eines Channel-Schlüssels einen Secure Channel ein und sendet in Schritt b2) die Transaktionsanweisung über den Secure Channel an den Payment Service Provider.
Gemäß einer ersten Form der ersten Ausführungs- Variante der Authentisie- rung richtet der Agent gemäß Merkmal b ) den Secure Channel zum Payment Service Provider direkt ein. In der Figurenbeschreibung ist ein Beispiel der ersten Form mit einem Agenten in Gestalt einer HCE in Fig. 5 gezeigt. Ein Beispiel der ersten Form mit einem Agenten in Gestalt einer Trust- Applikation, die über eine TEE Socket API eine Verbindung zum Payment Service Provider herstellt, ist in Fig. 7 gezeigt.
Gemäß einer zweiten Form der ersten Ausführungs- Variante der Authenti- sierung richtet der Agent gemäß Merkmal bl) den Secure Channel zum Payment Service Provider über ein NFC Zahlungsterminal ein, das selbst nicht über die Zugangsdaten (z.B. Channel-Schlüssel, Signaturschlüssel) verfügt, und insbesondere die Transaktionsanweisung lediglich durchleitet. In der Figurenbeschreibung ist ein Beispiel der zweiten Form mit einem Agenten in Gestalt einer HCE in Fig. 3 gezeigt. Ein Beispiel der zweiten Form mit einem Agenten in Gestalt einer Trust- Applikation ist in Fig. 9 gezeigt.
Um die Autorisierung der Transaktion vom Kunden einzuholen, kann bedarf s weise vorgesehen sein, dass der Agent eine Ein-/ Ausgabe- Applikation beauftragt, welche an einer Autorisierungs-Schnittstelle des Endgeräts Ausgaben an den Kunden ausgibt bzw. Eingaben des Kunden entgegermimmt.
Wahlweise werden die Aufforderung an den Kunden und die Autorisierung des Kunden über eine in der sicheren Laufzeitumgebung implementierte sichere Autorisierungs-Schnittstelle (Eingabe-, Ausgabe-, Ein-/ Ausgabe- Schnittstelle) ausgegeben bzw. entgegengenommen. Hierbei kann insbeson- dere vorgesehen sein, dass durch den Agenten eine in der sicheren Laufzeitumgebung implementierte Trusted Applikation mit der Steuerung der Benutzerschnittstelle beauftragt wird. Wahlweise können zur Authentisierung des Kunden Autorisierungs-Schnittstellen eingesetzt werden, die direkt aus der sicheren Laufzeitumgebung aufgerufen werden.
Kurze Beschreibung der Zeichnungen
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnungen näher erläutert, in der zeigen:
Fig. 1 ein System zum mobilen Bezahlen in der Übersicht, nach dem Stand der Technik;
Fig. 2 ein System zum mobilen Bezahlen in der Übersicht, nach einer Aus- führungsform der Erfindung;
Fig. 3 ein System zum mobilen Bezahlen in Struktur-Darstellung, nach einer ersten Ausführungsform der Erfindung;
Fig. 4 ein Ablaufschema für eine Transaktion in einem System nach Fig. 3; Fig. 5 ein System zum mobilen Bezahlen in Struktur-Darstellung, nach einer zweiten Ausführungsform der Erfindung;
Fig. 6 ein Ablaufschema für eine Transaktion in einem System nach Fig. 5; Fig. 7 ein System zum mobilen Bezahlen in Struktur-Darstellung, nach einer dritten Ausführungsform der Erfindung;
Fig. 8 ein Ablauf schema für eine Transaktion in einem System nach Fig. 7; Fig. 9 ein System zum mobilen Bezahlen in Struktur-Darstellung, nach einer vierten Ausführungsform der Erfindung.
Fig. 10 ein Ablauf schema für eine Transaktion in einem System nach Fig. 9.
Detaillierte Beschreibung von Ausführungsbeispielen Fig. 1 zeigt ein System zum mobilen Bezahlen, nach dem Stand der Technik. Das System umfasst einen Händler-Server M eines Händlers (englisch„Mer- chant"), ein durch einen Kunden („Customer") verwendetes mobiles Endgerät D („Device"), ein NFC Zahlungsterminal PT (payment terminal), einen Payment-Service-Provider-Server (oder Zahlungsabwickler-Server) PSP, einen Kundenbank-Server CB („Customer Bank") und einen Händlerbank- Server MB („Merchant Bank"). Das System im engeren Sinn ist gebildet durch das mobile Endgerät D, das NFC Zahlungsterminal FT und den Pay- ment-Service-Provider-Server PSP. Der Händler-Server M und die Banken- Server CB, MB komplettieren das System.
Der Kommunikationskanal zwischen dem Endgerät D und dem Payment Service Provider Server PSP umfasst zwei Teilstrecken, nämlich eine erste Teilstrecke zwischen dem mobilen Endgerät D und dem NFC Zahlungster- minal PT, und eine zweite Teilstrecke zwischen dem NFC Zahlungsterminal PT und dem Payment-Service-Provider-Server PSP. Um den Kommunikationskanal durch Authentisierung abzusichern, müssen die zwei Teilstrecken jeweils gesondert durch Authentisierung abgesichert werden. Hierzu sind zwischen dem mobilen Endgerät D und dem NFC Zahlungsterminal PT ers- te Zugangsdaten vereinbart und zwischen dem NFC Zahlungsterminal PT und dem Payment-Service-Provider-Server PSP zweite, von den ersten Zugangsdaten unterschiedliche und unabhängige Zugangsdaten vereinbart. Die Authentisierung mittels der Zugangsdaten kann entweder als Aufbau und Betrieb eines Secure Channel zwischen den jeweiligen Kommunikati- onspartnern gestaltet sein, oder als Erzeugung einer Signatur beim einen Kommunikationspartner und Verifizierung der Signatur beim anderen Kommunikarionspartner . Bei einer Zahlung nach dem Stand der Technik in einem System nach Fig. 1 sendet zur Veranlassung der Zahlung der Händler-Server Transaktionsdaten (oder Transaktionsinformation) T an das NFC ZaWungsterrninal PT. Der für die Erfindung besonders bedeutsame Kernteil des herkömmlichen Verfahrens nach Fig. 1 beginnt an dieser Stelle beim NFC-Zahlungsterminal PT. Das NFC Zahlungsterminal PT sendet die Transaktionsdaten T in einer durch Authentisierung abgesicherten NFC Verbindung an das mobile Endgerät D. Der Kunde wird durch eine Ausgabe an seinem Endgerät D aufge- fordert, die Transaktionsdaten T zu bestätigen. Der Kunde authentisiert sich mit einer Eingabe am Endgerät D und bestätigt durch seine Eingabe die Transaktionsdaten T. Die Ausgabe an den Kunden erfolgt z.B. durch Anzeige einer Eingabemaske am Touch-Display des Endgeräts D. Die Eingabe erfolgt z.B. durch Eingaben in die angezeigte Eingabemaske am Touch-Display des Endgeräts D. Die Art und Stärke der Authentisierung wird durch die Applikation, die technischen Eigenschaften und Möglichkeiten des Endgeräts D sowie Vorgaben („Policies") des Payment Service Providers PSP bestimmt und ist nicht relevant für das Verfahren. Das Endgerät D erzeugt auf die Eingaben des Nutzers hin eine Transaktionsanweisung TR, signiert diese mit ersten Zugangsdaten und sendet die signierte Transaktionsanweisung TR über die erste Teilstrecke an das NFC Zahlungsterminal PT. Das NFC- Zahlungsterminal verifiziert die Signatur, signiert die Transaktionsanweisung TR selbst neu mit zweiten Zugangsdaten und sendet über die zweite Teilstrecke die Transaktionsanweisung TR an den Payment-Service- Provider-Server PSP. Das Endgerät D verfügt hierbei nicht über die zweiten Zugangsdaten. Der Payment-Service-Provider-Server PSP verfügt nicht über die ersten Zugangsdaten. Durch die im Kernteil des Verfahrens ablaufenden Schritte ist die Transaktion dem Kunden-Endgerät D zum Bestätigung vorgelegt worden und nach Bestätigung des Kunden am Payment-Service- Provider-Server PSP zum Clearing im Banken-Hintergrundsystem fertig gestellt.
Die Vollendung der Transaktion umfasst, dass der Payment-Service- Provider-Server PSP an den Kundenbank-Server CN eine Zahlungsanweisung sendet und der Kundenbank-Server CB die Zahlung gemäß der Zahlungsanweisung an den Händlerbank-Server MB veranlasst.
Fig. 2 zeigt ein System zum mobilen Bezahlen, nach einer Ausführungsform der Erfindung. Eine Zahlung im System aus Fig. 2 unterscheidet sich im Kernteil von einer Zahlung im herkömmlichen System aus Fig. 1. Das vor dem Kernteil erfolgende Senden von Transaktionsdaten (oder Transaktionsinformation) T vom Händler-Server M an das NFC Zahlungsterminal PT, sowie das nach dem Kernteil erfolgende Clearing über die Bankenserver von Kunde und Händler erfolgen dagegen wie in Fig. 1. Ebenfalls im Unterschied zum System aus Fig. 1 hat im System aus Fig. 2 das mobile Endgerät notwendigerweise eine sichere Laufzeitumgebung TEE. Weiter im Unterschied zum Stand der Technik sind zwischen Endgerät D und Payment Service Provider PSP Zugangsdaten vereinbart.
Im Kernteil einer Zahlung in System nach Fig. 2 sendet das NFC Zahlungsterminal PT, zunächst noch wie beim herkömmlichen Verfahren, die Transaktionsdaten T über eine NFC Verbindung an das mobile End gerät D. Der Kunde authentisiert sich am Endgerät durch Eingabe einer Autorisierung C(T)=Auth(), z.B. durch Eingaben in angezeigte Eingabemasken am Touch- Display des Endgeräts D, und bestätigt hiermit am Endgerät D die Transaktionsdaten T (die Art und Stärke der Authentisierung richtet sich nach den technischen Möglichkeiten des Endgeräts D und den Vorgaben des PSP). Das Endgerät D erzeugt auf die Eingaben des Nutzers hin eine Transakti- onsanweisung Signed(T), indem es die Transaktionsdaten T und evtl. weitere Daten mit den Zugangsdaten signiert und an die Transaktionsdaten im Klartext anhängt. Die so erzeugte Transaktionsanweisung Signed(T) umfasst nun also die Transaktionsdaten T im Klartext sowie eine Signatur über die (oder manche der) Transaktionsdaten T. Der Bestand an Transaktionsdaten T kann sich im Verlauf des Verfahrens ändern, z.B. durch Hinzunahme oder Weglassen von einzelnen Elementen (z.B. Datum-Zeit-Stempel, Kunde, Refe- renz-ID, ...) von Transaktionsdaten T. Das Endgerät sendet die erzeugte Transaktionsanweisung TR=Signed(T) direkt an den Payment-Service- Provider-Server PSP. Über die Zugangsdaten verfügt also das Endgerät D, und nicht wie in Fig. 1 das Zahlungsterminal FT. Somit ist derjenige funktionelle Teil des NFC Zarüungsterminals PT, der mit der Veranlassung des Clearings bei den Bankenservern befasst ist, in das Endgerät D hinein verlagert. Insgesamt ist also das komplette Teilverfahren von der Bestätigung der Transaktionsdaten T durch den Kunden bis hin zur Veranlassung des Clearing in das geschlossene System des Endgeräts D hinein verlagert. Das Zahlungsterminal PT ist für den Versand von Transaktionsanweisungen TR = Signed(T), d.h. bestätigten/ autorisierten (C(T) = Auth(T)) und signierten (TR= Signed(T)) Transaktionsdaten T, vom Endgerät D zum Clearing nicht mehr erforderlich, kann aber als reine Durchleitungs-Station noch vorhanden sein (vgl. nachfolgend beschriebene detaillierte Ausführungsformen). Bei Ausführungsformen mit dem ZaWungsterminal PT als Durchleitungs- Station fließen die Kommunikationsströme auf den ersten Blick wie in Fig. 1. Allerdings wird im Unterschied zu Fig. 1 ein durchgängiger gesicherter Kommunikationskanal vom Endgerät D zum Payment-Service-Provider PSP betrieben, durch das Zahlungsterminal PT hindurch.
Fig. 3, 5, 7 und 9 zeigen die Struktur der Systeme zum mobilen Bezahlen in Strukturdarstellung, nach einer ersten, zweiten, dritten bzw. vierten Ausfüh- rungsform der Erfindung. In der Strukturdarstellung ist das Endgerät D strukturell aufgelöst dargestellt.
Bei den Systemen gemäß Fig. 3 und 5 ist im Endgerät D ein zur Kommunika- tion des Endgeräts D mit einem Payment Service Provider PSP eingerichteter Agent vorgesehen, der in der normalen Laufzeitumgebung REE implementiert ist und als Android Host Card Emulation HCE gestaltet ist.
Bei den Systemen gemäß Fig. 7 und 9 ist im Endgerät D ein zur Kommunika- tion des Endgeräts D mit einem Payment Service Provider PSP eingerichteter Agent vorgesehen, der in der sicheren Lauf Zeitumgebung TEE als Trusted Applikation implementiert ist. Genauer ist der Agent gemäß Fig. 7 und 9 in die Zahlungs-Trust- Applikation TA integriert. Eine NFC-Schnittstelle NFC des Endgeräts D ist bei den Systemen gemäß Fig. 7 und 9 ebenfalls unter Steuerung der sicheren Laufzeitumgebung TEE implementiert. Weiter ist in der sicheren Lauf zeitumgebung TEE ein Treiber für ein Trusted User Interface (Touch-Display des Endgeräts D) TUI implementiert, also eine in der sicheren Laufzeitumgebung TEE implementierte Variante eines Display- Treibers GUI („Trusted User Interface", TUI).
Bei den Ausführungsformen gemäß Fig. 3, Fig. 9 erfolgt die Kommunikation zwischen Endgerät D und Payment Service-Provider PSP über ein Zahlungsterminal FT (das aber nur als Durchleitungs-Station fungiert). Bei den Ausführungsformen gemäß Fig. 5, Fig. 7 ist der Agent dazu eingerichtet, den Payment Service Provider PSP direkt zu kontaktieren.
In den Figuren sind Verfahrensschritte mit Ziffern wie 1, 1.1, 1.2, 2, 2.1, 3 etc. bezeichnet. Fig. 3 zeigt ein System zum mobilen Bezahlen in Strukturdarstellung, nach einer ersten Ausführungsform der Erfindung. Das System umfasst ein Endgerät D, ein ZaMungsterminal PT, einen Payment Service Provider PSP und einen Händler-Server M. Das Endgerät D umfasst eine NFC-Schnittstelle NFC, eine normale Laufzeitumgebung REE und eine sichere Laufzeitumgebung TEE. Die normale Laufzeitumgebung REE umfasst einen als Android Host Card Emulation HCE gestalteten Agenten und eine Display-Treiber GUI zur Ansteuerung eines Touch-Display des Endgeräts D. Der Agent HCE ist zur Vermittlung der Kommunikation der NFC-Schnittstelle NFC mit In- stanzen innerhalb der normalen Lauf zeitumgebung REE und auch in der sicheren Laufzeitumgebung TEE eingerichtet. Die sichere Laufzeitumgebung TEE ist gesteuert durch ein Sicherheitsbetriebssystem TEE-OS und umfasst eine Zahlungs-Trust- Applikation TA (d.h. den sicheren Anteil einer Zahlungsverkehrs-Applikation des Endgeräts D, deren evtl. zusätzlich vorhan- dener unsicherer Anteil in der normalen Laufzeitumgebung REE nicht dargestellt ist) und Personalisierungsdaten Perso zu der Zahlungs-Trust- Applikation TA bzw. zur gesamten Zahlungsverkehrs- Applikation. Die Personalisierungsdaten Perso umfassen Zugangsdaten, die zwischen dem Endgerät D und dem Payment Service Provider PSP vereinbart sind, und die hier gestaltet sind als kryptographische Schlüssel zur Signaturerzeugung.
Im Folgenden werden an Hand von Fig. 3 und Fig. 4 Kommunikations- Ströme im Zusammenhang mit einer Transaktion im System aus Fig. 3 beschrieben. 1: Der Händler-Server M sendet Transaktionsdaten T an das Zah- lungsterminal PT und zeigt dem Kunden an, dass er nun mit seinen NFC- fähigen Endgerät D bezahlen soll. 1.1: Der Kunde hält sein Endgerät D in NFC-Reichweite an das Zahlungsterminal PT und initiiert hierdurch NFC- Kommunikation zwischen dem Endgerät D und dem Zahlungsterminal PT. Zudem teilt das Endgerät D in Schritt 1.1 dem Zahlungsterminal PT den Ap- plication Identifier AID der zu verwendenden Zahlungsverkehrs- Applikation bzw. Zahlungs-Trust- Applikation mit. 2: Das Zahlungsterminal sendet die Transaktionsdaten T (und den Application Identifier AID, nicht ausdrücklich dargestellt) an eine NFC-Schnittstelle NFC eines Endgeräts D. Die Transaktionsdaten T und der AID können dabei für den NFC- Versand z.B. in ein NFC-Tag verpackt sein, das im Endgerät D wieder entpackt wird, um die Transaktionsdaten T und den AID zu extrahieren. 2.0: Die NFC- Schnittstelle sendet die Transaktionsdaten T (und den AID) (z.B. in einem APDU-Kommando) an den Agenten HCE. 2.1: Der Agent HCE sendet die Transaktionsdaten T zunächst an den Display-Treiber GUI, welcher vom Kunden, also vom Halter des Endgeräts D, eine Bestätigung der Transaktionsdaten T anfordert. Schritt 2.2: Der Display-Treiber GUI nimmt die vom Kunden in Form einer Kunden-Authentisierung Auth() (z.B. PIN, Passwort, Fingerabdruck etc.) eingegebene Bestätigung entgegen und leitet sie an den Agenten HCE weiter. 2.3: Der Agent HCE sendet die bestätigten Transaktionsdaten T und den AID an die Zahlungs-Trust- Applikation TA. 2.4: Die Zahlungs-Trust- Applikation TA greift auf die Personalisierungsdaten Perso zu, liest die benötigten Zugangsdaten aus, genauer den Signatur-Erzeugungsschlüssel, und signiert mit dem Signatur-Erzeugungsschlüssel die Transaktionsdaten T zu einer Signatur. Die Zahlungs-Trust- Applikation TA fügt weiter die bestätigten Transaktionsdaten T und die Signatur zu einer Transaktionsanweisung Signed(T) zusammen. 2.5: Die Zahlungs-Trust- Applikation TA sendet die Transaktionsanweisung Signed(T) an den Agenten HCE. 2.6: Der Agent HCE sendet die Transaktionsanweisung Signed(T) (z.B. in einem APDU-Kommando) an die NFC-Schnittstelle, welche die
Transaktionsanweisung Signed(T) weiter an das Zahlungsterminal PT sendet. 2.7: Das ZaWungsterminal PT leitet die signierte Transaktionsanweisung Signed(T) ohne eigene Bearbeitung an den Payment Service Provider PSP durch. Der Payment Service Provider PSP verifiziert die Signatur der Trans- aktionsanweisung Signed(T) und veranlasst im Gutfall positiver Verifizierung das Clearing der Transaktion über die Bankenserver MB, CB von Händler und Kunde. Schritt 3: Nach Veranlassen des Clearing sendet der Payment Service Provider PSP an das Zahlungsterminal PT ein sogenanntes„Approval" A (Bestätigung seitens des PSP über die erfolgte Transaktion) über die erfolgte Transaktion. 3.1: Das ZaWungsterrninal PT leitet zur Information das Approval A(T), z.B. in einer Quittung R (Receipt), an den Händler-Server M weiter. 3.2: Das ZaWungsterminal PT leitet das um einen Datums- und Zeitstempel„dateTime" ergänzte Approval A zur Information an den Agenten HCE weiter.
Fig. 4 zeigt ein Ablaufschema für eine Transaktion in einem System nach Fig. 3, aus dem insbesondere der Bestand an Transaktionsdaten T im Verlauf des Verfahrens hervorgeht. In Schritten 1 bis 2.3 umfassen die Transaktionsdaten T den Verkäufer„vendor" (in der Regel ist dies der Händler) und der Betrag „amount". Nach Auslesen des Signatur-Erzeugungsschlüssels (Schritt 2.4) werden die Transaktionsdaten T um eine Bezeichnung des Kunden„custo- mer" ergänzt. Die Transaktionsdaten T werden mit dem Signatur-Erzeugungsschlüssels signiert. Die so erzeugte Signatur„signature" und die ergänzten Transaktionsdaten T werden zu einer Transaktionsanweisung Sig- ned(T) zusammengefügt, die an den Payment Service Provider PSP versendet wird (Schritt 2.6). Das Approval A vom Zahlungsterminal PT an den Agenten HCE im Endgerät D umfasst als Transaktionsdaten T den Verkäufer „vendor", den Betrag„amount" und einen Datum-/ Zeitstempel„dateTime".
Fig. 5 zeigt ein System zum mobilen Bezahlen in Strukturdarstellung, nach einer zweiten Ausführungsform der Erfindung. Eine Vielzahl von Elementen ist wie bei der ersten Ausführungsform gemäß Fig. 3, 4 gestaltet und wird an dieser Stelle nicht weiter beschrieben. Im Unterschied zum System aus Fig. 3 hat im System aus Fig. 5 der Agent HCE zusätzliche Funktionalitäten im Vergleich zum Agenten HCE aus Fig. 3, dahingehend, dass er den Payment Service Provider PSP direkt kontaktieren kann.
Im Folgenden werden an Hand von Fig. 5 und Fig. 6 Kommunikations- Ströme im Zusammenhang mit einer Transaktion im System aus Fig. 5 beschrieben. Das Verfahren beginnt zunächst wie im ersten Ausführungsbeispiel mit den Schritten 1 bis 2.5 aus Fig. 3. Das System ist im Status, dass dem Agenten HCE vom Kunden bestätigte und von der Zahlungs-Trust- Applikation TA mit Zugangsdaten (Signatur-Erzeugungsschlüssel) signierte Transaktionsdaten T vorliegen, und hiermit eine Transaktionsanweisung Sig- ned(T) erzeugt worden ist. Im Unterschied zur ersten Ausführungsform sendet in einem Schritt 2.6 nun der Agent HCE die Transaktionsanweisung Signed(T) unmittelbar an den Payment Service Provider PSP. Der Payment Service Provider PSP verifiziert die Signatur in der Transaktionsanweisung Signed(T) mit dem Signatur- Verifizierungsschlüssel und veranlasst im Gutfall positiver Verifizierung das Clearing der Transaktion über die Bankenserver MB, CB von Händler und Kunde. 2.7: Nach Veranlassen des Clearing sendet der Payment Service Provider PSP an den Agenten HCE des Endgeräts D eine Quittung, ein sogenanntes„Receipt" R. Der Agent HCE packt das Receipt R in ein APDU-Kommando und, Schritt 2.8, leitet es an die NFC- Schnittstelle NFC, welche das APDU-Kommando entpackt, das Receipt R extrahiert und das Receipt R an das das Zahlungsterminal PT leitet. 2.9: Das Zahlungsterminal PT sendet das Receipt R zur Information an den Händler- Server M.
Fig. 6 zeigt, analog zu Fig. 4, ein Ablaufschema für eine Transaktion in einem System nach Fig. 5, aus dem insbesondere der Bestand an Transaktionsdaten T im Verlauf des Verfahrens hervorgeht. In Schritten 1 bis 2.3 umfassen die Transaktionsdaten Verkäufer„vendor" und Betrag„amount". Nach dem Auslesen des Signatur- Erzeugungsschlüssels (Schritt 2.4) werden die Transaktionsdaten T um den Kunden„customer" ergänzt und signiert. Die Signatur„ signa ture" wird an die Transaktionsdaten T angehängt. Hierdurch wird die Transaktionsanweisung Signed(T) erzeugt. Diese wird schließlich an den Payment Service Provider PSP versendet (Schritt 2.6). Die in Schritt 2.8 vom Agenten HCE des Endgeräts D an das Zahlungsterminal PT versendete Quittung Receipt R umfasst die Transaktionsdaten T Verkäufer„vendor", Betrag „amount" und den Datums- und Zeitstempel„dateTime".
Fig. 7 zeigt ein System zum mobilen Bezahlen in Strukturdarstellung, nach einer dritten Ausführungsform der Erfindung, wobei der Agent in der sicheren Laufzeitumgebung TEE in die Zahlungs-Trust- Applikation TA integriert ist. Zunächst werden, wie bei der ersten und zweiten Ausführungsform ge- mäß Fig. 3, Fig. 5, in Schritt 1: Transaktionsdaten T von einem Händler- Server M an ein ZaWungsterminal PT gesendet und in Schritt 2: die Transaktionsdaten T und ein AID der Zahlungs-Trust- Applikation TA an eine NFC- Schnittstelle NFC des Endgeräts D gesendet. Die NFC-Schnittstelle NFC steht unter Steuerung eines Sicherheitsbetriebssystems TEE-OS, durch wel- ches die sichere Laufzeitumgebung TEE gesteuert ist. Durch den Empfangsvorgang 2 an der NFC-Schnittstelle NFC werden die Transaktionsdaten T unmittelbar in die sichere Laufzeitumgebung TEE überführt. Immer noch unter Steuerung des Sicherheits-Betriebssystems TEE-OS werden (weiterhin Schritt 2) die Transaktionsdaten T und der AID durch die NFC-Schnittstelle an die Zahlungs-Trust- Applikation TA geleitet. 2.1: Die Zahlungs-Trust- Applikation TA veranlasst über einen in der sicheren Laufzeitumgebung TEE implementierten sicheren User-Schnittstellen-Treiber TUI, dass der Kunde auf geeignete Weise am Endgerät D authentifiziert wird, um die Transaktion zu bestätigen. 2.2 Der User-Schnittstellen-Treiber TUI nimmt eine vom Kunden eingegebene Bestätigung / Authentisierung A (Auth) entgegen und leitet die Bestätigung / Authentisierung A an die Zahlungs-Trust- Applikation TA. 2.3: Die Zahlungs-Trust- Applikation liest aus den Persona- lisierungsdaten Perso Zugangsdaten„Keys" in Form eines Signaturerzeu- gungs-Schlüssels aus, signiert die Transaktionsdaten T, erzeugt hierdurch eine Signatur und fügt Transaktionsdaten T und Signatur zu einer Transaktionsanweisung Signed(T) zusammen. 2.4: Die Zahlungs-Trust- Applikation TA sendet über eine TEE-interne Socket API (spezielle Supplementary API) die Transaktionsanweisung Signed(T) an den Payment Service Provider PSP, der die Signatur aus der Transaktionsanweisung Signed(T) mit dem passenden Signatur- Verifizierungs-Schlüssel verifiziert und im Gutfall das Clearing veranlasst und, 2.5, an die TEE Socket API eine Quittung„Receipt" R zurück sendet; weiter 2.5: die TEE Socket API sendet die Quittung R weiter an die Zahlungs-Trust- Applikation TA. 3: Die Zahlungs-Trust- Applikation TA sen- det die Quittung R über den sicheren NFC-Treiber NFC an das Zahlungsterminal PT, welches, 3.1, die Quittung R zur Information an den Händler- Server M weiterleitet.
Fig. 8 verdeutlicht nochmals einen Transaktionsablauf im Überblick und den veränderlichen Bestand der dabei beteiligten Transaktionsdaten. V. Der
Händler-Server M sendet Transaktionsdaten T (zumindest Händler, Betrag) an das Zahlungsterminal PT, das den Kunden einlädt, das Endgerät D anzunähern. 1.1: Der Kunde hält das Endgerät D in NFC-Reichweite an das Zahlungsterminal PT. 2: Das Za ungsterrninal PT sendet die Transaktionsdaten T an das Endgerät D, direkt in die sichere Laufzeitumgebung TEE. 2.1: Die Zahlungs-Trust- Applikation TA sendet die Transaktionsdaten T an eine sichere Ein-/ Ausgabeschnittstelle, nämlich ein Secure World GUI (Graphical User Interface), genannt Trusted User Interface TUI, des Endgeräts D, z.B. ein sicheres (Touch-) Display, dessen Treiber im TEE implementiert ist; die- ses zeigt die Transaktionsdaten (zumindest Händler, Betrag) dem Kunden an; der Kunde authentifiziert sich am Endgerät und bestätigt damit die Transaktionsdaten. 2.2: Die vom Kunden eingegebene Transaktionsbestätigung, ggf. mit Eingabe einer PIN, Passwort, Fingerabdruck etc., wird in der sicheren Laufzeitumgebung TEE entgegengenommen. 2.3: Die Zahlungs- Trust- Applikation TA ergänzt die Transaktionsdaten um einen Datums- und Zeitstempel dateTime, signiert die ergänzten Transaktionsdaten T zu einer Signatur, erzeugt aus Signatur und Klartext-Transaktionsdaten T die Transaktionsanweisung SignedTransaction() = Signed(T) und, 2.4., sendet die Transaktionsanweisung Signed(T) an den Payment Service Provider PSP. Der Payment Service Provider PSP verifiziert mittels der Signatur die Transaktionsdaten T, fügt den Transaktionsdaten T eine Referenz-ID hinzu und, 2.5, sendet im Gutfall positiver Signatur- Verifizierung zurück an die Zahlungs-Trust-Applikation TA ein Approval A (d.h. eine Bestätigung) (T nun umfassend Händler, Betrag, Datum, Uhrzeit, Referenz-ID). 3: Die Zahlungs- Trust- Applikation TA sendet das Approval A an das Zahlungsterminal PT, welches es, 3.1, zur Information an den Händler-Server weiterleitet.
Fig. 9 zeigt ein System zum mobilen Bezahlen in Strukturdarstellung, nach einer vierten Ausführungsform der Erfindung, wobei der Agent, wie bei Fig. 7, in der sicheren Laufzeitumgebung TEE in die Zahlungs-Trust- Applikation TA integriert ist. Im Unterschied zur dritten Ausführungsform aus Fig. 7 nutzt die vierte Ausführungsform gemäß Fig. 9 keine Möglichkeit, eine signierte Transaktionsanweisung Signed(T) direkt an den Payment Service Pro- vider PSP zu übermitteln. Entsprechend fehlt die TEE Socket API aus Fig. 7. Stattdessen wird in Schritten 2.4+3 die Transaktionsanweisung Signed(T) über die unter Steuerung des Sicherheits-Betriebssystems TEE-OS implementierte sichere NFC-Schnittstelle NFC des Endgeräts D und über das Zahlungsterminal PT an den Payment Service Provider PSP gesendet. Die Schrit- te 1 bis 2.3 erfolgen wie bei Fig. 7. 2.1: Die Transaktionsdaten werden dem Kunden an der sicheren Nutzerschnittstelle TUI angezeigt. 2.2: Der Kunde authentifiziert sich mittels der am Endgerät D angebotenen und akzeptierten Authentikatoren (z.B. PIN Eingabe etc. über TUI). 2.3: Die TA berechnet nach erfolgter Authentifizierung und Bestätigung die Signatur über die Transaktionsdaten T mittels des im sicheren Bereich gespeicherten Signatur- Erzeugungs-Schlüssels (Schlüssel wurde z.B. bei Personalisierung eingebracht). 2.4: Die bestätigte und signierte Transaktion Signed(T) wird über die NFC Schnittstelle an das Payment Terminal PT übertragen. 3: Von dort wird die signierte und bestätigte Transaktion Signed(T) an den Payment Service Provider PSP weitergeleitet, ohne eigene Bearbeitung im Zahlungsterminal PT. 3.1: Der Payment Service Provider PSP prüft die Signatur und sendet bei Erfolg ein Receipt R an das ZaWungsterrninal PT, wodurch die Zahlungs- Transaktion abgeschlossen wird. 3.2: Zur Information sendet das Zahlungsterminal PT das Receipt auch an den Händler-Server M.
Fig. 10 zeigt ein Ablauf diagramm, in welchem Kommunikations-Ströme und der variierende Bestand an Transaktionsdaten T (Händler„vendor", Betrag „amount", Datum- und Zeitstempel„dateTime", Referenz-ID„ref-ID") im Verlauf einer Zahlung im System aus Fig. 9 dargestellt sind.

Claims

P a t e n t a n s p r ü c h e
1. Mobiles Endgerät (D) eines Kunden, eingerichtet zum mobilen Bezahlen durch eine Zahlung gemäß Transaktionsdaten (T) vom Kunden an einen Händler über einen Payment Service Provider (PSP), der dazu eingerichtet ist, ein Clearing der Zahlung zwischen Bankenservern (CB, MB) von Kunde und Händler zu veranlassen,
wobei das mobile Endgerät (D) umfasst:
- eine normale Laufzeitumgebung (REE) und eine sichere Laufzeitumgebung (TEE);
- einen Agenten (HCE; TA), der dazu eingerichtet ist, Transaktionsdaten (T) von einem Zahlungsterminal (PT) entgegenzunehmen;
- eine im Endgerät (D) implementierte Autorisierungs-Schnittstelle (GUI; TUI), die dazu eingerichtet ist, am Agenten (HCE; TA) entgegengenommene Transaktionsdaten (T) an den Kunden zur Autorisierung zu präsentieren und eine vom Kunden an der Autorisierungs-Schnittstelle (GUI; TUI) eingegebene Autorisierung (Auth) entgegenzunehmen und weiterzuleiten;
- eine im Endgerät implementierte Zahlungs- Applikation, von der zumindest ein sicherer Anteil, nämlich eine Zahlungs-Trust- Applikation (TA), in der sicheren Laufzeitumgebung (TEE) implementiert ist, und die dazu eingerichtet ist, eine von der Autorisierungs-Schnittstelle (GUI; TUI) weitergeleitete Autorisierung (Auth) entgegenzunehmen und in Reaktion auf die entgegengenommeine Autorisierung (Auth) eine Transaktionsanweisung (Signed (T)) zu erzeugen und zu senden;
dadurch gekennzeichnet, dass
a) in der sicheren Lauf zeitumgebung (TEE) Zugangsdaten für eine Authenti- sierung zwischen der Zahlungs-Trust- Applikation (TA) und dem Payment Service Provider (PSP) gespeichert sind; und
b) der Agent (HCE; TA) weiter dazu eingerichtet ist:
bl) anlässlich einer Authentisierung zwischen der Zahlungs-Trust- Applikation (TA) und dem Payment Service Provider (PSP): Zugangsdaten oder unter Verwendung von Zugangsdaten erzeugte Authentisierungsdaten zwischen der sicheren Lauf zeitumgebung (TEE) und dem Payment Service Provider (PSP) zu übermitteln; und
b2) von der Zahlungs-Trust- Applikation (TA) eine Transaktionsanweisung (Signed(T)) für eine Zahlung gemäß den Transaktionsdaten (T) entgegenzunehmen und an den Payment Service Provider (PSP) zu senden.
2. Endgerät nach Anspruch 1, wobei der Agent (HCE) als eine Software- Emulation einer Smartcard, insbesondere eine Android Host-based Card Emulation HCE, gestaltet ist.
3. Endgerät nach Anspruch 1, wobei der Agent (TA) als eine in der sicheren Lauf zeitumgebung (TEE) implementierte Trust- Applikation gestaltet ist oder in eine solche Trust- Applikation integriert ist.
4. Endgerät nach Anspruch 1, wobei der Agent als Zahlungs-Trust- Applikation (TA) gestaltet ist oder in die Zahlungs-Trust- Applikation (TA) integriert ist.
5. Endgerät nach einem der Ansprüche 1 bis 4, wobei die Zugangsdaten einen Channel-Schlüssel zum Aufbau und Betrieb eines Secure Channel zwischen der sicheren Lauf zeitumgebung (TEE) und dem Payment Service Provider (PSP) umfassen und der Agent (HCE; TA) dazu eingerichtet ist, gemäß bl) unter Verwendung des Channel-Schlüssels den Secure Channel einzurichten und
gemäß b2) die Transaktionsanweisung (Signed(T)) über den Secure Channel an den Payment Service Provider (PSP) zu senden.
6. Endgerät nach einem der Ansprüche 1 bis 4, wobei die Zugangsdaten einen Signatur-Erzeugungsschlüssel zum Erzeugen einer Signatur umfassen, wobei mit Signieren der Transaktionsdaten (T) mittels des Signatur- Erzeugungsschlüssels die Transaktionsanweisung (Signed(T)) erzeugbar ist, wobei beim Payment Service Provider (PSP) der entsprechende Signatur- Verifizierungsschlüssel gespeichert ist, und der Agent (HCE; TA) dazu eingerichtet ist,
gemäß bl) und b2) eine mit Signieren der Transaktionsdaten (T) mit dem Signatur-Erzeugungsschlüssels erzeugte Transaktionsanweisung (Signed(T)) an den Payment Service Provider (PSP) zu senden, so dass für den Payment Service Provider (PSP) die Transaktionsdaten (T) verifizier bar sind.
7. Mobiles Bezahlverfahren für ein Endgerät (D) eines Kunden, eingerichtet zum mobilen Bezahlen durch Zahlung gemäß Transaktionsdaten (T) vom Kunden an einen Händler über einen Payment Service Provider (PSP), der dazu eingerichtet ist, ein Clearing der Zahlung zwischen Bankenservern (CB, MB) von Kunde und Händler zu veranlassen,
wobei das mobile Endgerät (D) umfasst:
- eine normale Laufzeitumgebung (REE) und eine sichere Laufzeitumgebung (TEE); einen im Endgerät (D) implementierten Agenten (HCE; TA); eine im End gerät (D) implementierte Autorisierungs-Schnittstelle (GUI; TUI); und eine im Endgerät implementierte Zahlungs- Applikation, von der zumindest ein sicherer Anteil, nämlich eine Zahlungs-Trust- Applikation (TA), in der sicheren Laufzeitumgebung (TEE) implementiert ist;
wobei bei dem Verfahren:
- durch den Agenten (HCE; TA): Transaktionsdaten (T) von einem Zahlungsterminal (PT) entgegengenommen werden;
- durch die Autorisierungs-Schnittstelle (GUI; TUI): beim Agenten (HCE; TA) empfangene Transaktionsdaten (T) an den Kunden zur Autorisierung präsentiert werden und eine vom Kunden an der Autorisierungs- Schnittstelle (GUI; TUI) eingegebene Autorisierung (Auth) entgegengenommen und weitergeleitet wird;
- durch die Zahlungs-Trust- Applikation (TA): eine von der Autorisierungs- Schnittstelle (GUI; TUI) weitergeleitete Autorisierung (Auth) entgegengenommen wird und in Reaktion auf die entgegengenommene Autorisierung (Auth) eine Transaktionsanweisung (Signed(T)) erzeugt wird und gesendet wird; dadurch gekennzeichnet, dass
a) zwischen der Zahlungs-Trust- Applikation (TA) und dem Payment Service Provider (PSP) eine Authentisierung unter Verwendung von in der sicheren Lauf zeitumgebung (TEE) gespeicherten Zugangsdaten durchgeführt wird; und
b) durch den Agenten (HCE; TA)):
bl) anlässlich der Authentisierung zwischen der Zahlungs-Trust- Applikation (TA) und dem Payment Service Provider (PSP) Zugangsdaten oder unter Verwendung von Zugangsdaten erzeugte Authentisierungsdaten (Signed(T)) zwischen der sicheren Laufzeitumgebung (TEE) und dem Payment Service Provider (PSP) übermittelt werden; und
b2) die von der Zahlungs-Trust- Applikation (TA) gesendete Transaktionsanweisung (Signed(T)) entgegengenommen wird und an den Payment Service Provider (PSP) gesendet wird.
8. Bezahlverfahren nach Anspruch 7, wobei die Zugangsdaten zumindest einen Channel-Schlüssel zum Aufbau und Betrieb eines Secure Channel zwischen der Zahlungs-Trust- Applikation und dem Payment Service Provider umfassen, und wobei der Agent
in Schritt bl) unter Verwendung des Channel-Schlüssels den Secure Channel einrichtet und in Schritt b2) die Transaktionsanweisung über den Secure Channel an den Payment Service Provider sendet.
9. Bezahlverfahren nach Anspruch 8, wobei der Agent in Schritt bl) den Secure Channel zum Payment Service Provider direkt einrichtet.
10. Bezahlverfahren nach Anspruch 8, wobei der Agent den Secure Channel zum Payment Service Provider über ein NFC Zahlungsterminal einrichtet, das nicht über die Zugangsdaten verfügt, und insbesondere die Transaktionsanweisung lediglich durchleitet.
11. Bezahlverfahren nach Anspruch 7, wobei die Zugangsdaten einen Signatur-Erzeugungsschlüssel zum Erzeugen einer Signatur zur Verifizierung der Transaktionsdaten (T) umfassen, wobei beim Payment Service Provider (PSP) der entsprechende Signatur- Verifizierungsschlüssel gespeichert ist, und wobei durch die Zahlungs-Trust- Applikation (TA) die Transaktionsanweisung (Signed(T)) erzeugt wird, wobei die Transaktionsdaten (T) mit dem Signatur-Erzeugungsschlüssel signiert werden;
und wobei der Agent, gemäß bl) und b2) die erzeugte Transaktionsanweisung (Signed(T)) an den Payment Service Provider (PSP) sendet, so dass für den Payment Service Provider (PSP) die Transaktionsdaten (T) mit dem Signatur-Verifizierungsschlüssel verifizierbar sind.
PCT/EP2016/000871 2015-05-29 2016-05-25 Endgerät und verfahren für mobiles bezahlen mit trusted execution environment WO2016192842A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US15/578,085 US11640596B2 (en) 2015-05-29 2016-05-25 Terminal and method for mobile payment with trusted execution environment
EP16727952.0A EP3304466A1 (de) 2015-05-29 2016-05-25 Endgerät und verfahren für mobiles bezahlen mit trusted execution environment
KR1020177034012A KR101957840B1 (ko) 2015-05-29 2016-05-25 신뢰된 실행 환경을 갖춘 이동 결제 단말 및 방법

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102015006907.1A DE102015006907A1 (de) 2015-05-29 2015-05-29 Endgerät und Verfahren für mobiles Bezahlen
DE102015006907.1 2015-05-29

Publications (1)

Publication Number Publication Date
WO2016192842A1 true WO2016192842A1 (de) 2016-12-08

Family

ID=56116386

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/000871 WO2016192842A1 (de) 2015-05-29 2016-05-25 Endgerät und verfahren für mobiles bezahlen mit trusted execution environment

Country Status (5)

Country Link
US (1) US11640596B2 (de)
EP (1) EP3304466A1 (de)
KR (1) KR101957840B1 (de)
DE (1) DE102015006907A1 (de)
WO (1) WO2016192842A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107066888A (zh) * 2017-04-21 2017-08-18 北京豆荚科技有限公司 可扩展的可信用户接口、方法和电子设备
CN109872148A (zh) * 2017-12-01 2019-06-11 北京握奇智能科技有限公司 基于tui的可信数据处理方法、装置以及移动终端
CN111383015A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 交易安全处理方法、装置及终端设备
US11443323B2 (en) 2018-03-07 2022-09-13 Samsung Electronics Co., Ltd. System and method for secure transactions with a trusted execution environment (TEE)

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10937025B1 (en) 2015-01-15 2021-03-02 Wells Fargo Bank, N.A. Payment services via application programming interface
US10997654B1 (en) 2015-01-15 2021-05-04 Wells Fargo Bank, N.A. Identity verification services through external entities via application programming interface
US10990974B1 (en) 2015-01-15 2021-04-27 Wells Fargo Bank, N.A. Identity verification services and user information provision via application programming interface
US10621658B1 (en) 2015-01-15 2020-04-14 Wells Fargo Bank, N.A. Identity verification services with identity score through external entities via application programming interface
KR102453705B1 (ko) * 2015-09-25 2022-10-11 삼성전자주식회사 호스트의 정당성 여부에 따라 선택적으로 결제 기능을 온(on)하는 결제 장치의 동작 방법
US10776777B1 (en) * 2017-08-04 2020-09-15 Wells Fargo Bank, N.A. Consolidating application access in a mobile wallet
US11416852B1 (en) * 2017-12-15 2022-08-16 Worldpay, Llc Systems and methods for generating and transmitting electronic transaction account information messages
US11676126B1 (en) 2017-12-28 2023-06-13 Wells Fargo Bank, N.A. Account open interfaces
US11106515B1 (en) 2017-12-28 2021-08-31 Wells Fargo Bank, N.A. Systems and methods for multi-platform product integration
US11995619B1 (en) 2017-12-28 2024-05-28 Wells Fargo Bank, N.A. Account open interfaces
CN109191131B (zh) * 2018-08-16 2022-06-10 沈阳微可信科技有限公司 一种基于可信环境和双安全芯片的安全人脸识别装置
US11379850B1 (en) 2018-12-10 2022-07-05 Wells Fargo Bank, N.A. Third-party payment interfaces
CN109784891A (zh) * 2019-01-14 2019-05-21 重庆唯哲科技有限公司 移动支付进程启动方法及系统
CN116934332A (zh) * 2019-05-30 2023-10-24 创新先进技术有限公司 物联网设备的费用支付方法和装置
US11044246B1 (en) 2019-06-21 2021-06-22 Wells Fargo Bank, N.A. Secure communications via third-party systems through frames
US20210042732A1 (en) * 2019-08-08 2021-02-11 Mastercard International Incorporated Secure qr code transactions

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9218601B2 (en) * 2010-11-10 2015-12-22 Paypal, Inc. Secure in-line payments for rich internet applications
DE102011116489A1 (de) * 2011-10-20 2013-04-25 Giesecke & Devrient Gmbh Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
KR20140010295A (ko) * 2012-07-16 2014-01-24 브이피 주식회사 결제 방법 및 이를 이용한 이동 단말기
CA2830260C (en) * 2012-10-17 2021-10-12 Royal Bank Of Canada Virtualization and secure processing of data
WO2015009765A1 (en) * 2013-07-15 2015-01-22 Visa International Service Association Secure remote payment transaction processing
KR102552606B1 (ko) * 2013-08-15 2023-07-06 비자 인터네셔널 서비스 어소시에이션 보안 요소를 이용한 보안 원격 지불 거래 처리
US10664833B2 (en) * 2014-03-05 2020-05-26 Mastercard International Incorporated Transactions utilizing multiple digital wallets
US20160253652A1 (en) * 2015-02-27 2016-09-01 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operation method thereof
WO2016137277A1 (en) * 2015-02-27 2016-09-01 Samsung Electronics Co., Ltd. Electronic device providing electronic payment function and operating method thereof
CN105930040A (zh) * 2015-02-27 2016-09-07 三星电子株式会社 包含电子支付系统的电子装置及其操作方法

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
ANONYMOUS: "Authentication - Wikipedia, the free encyclopedia", 14 May 2015 (2015-05-14), XP055288322, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Authentication&oldid=662289918> [retrieved on 20160713] *
ANONYMOUS: "Digital signature - Wikipedia, the free encyclopedia", 27 May 2015 (2015-05-27), XP055288319, Retrieved from the Internet <URL:https://en.wikipedia.org/w/index.php?title=Digital_signature&oldid=664241568> [retrieved on 20160713] *
ANONYMOUS: "Host-based Card Emulation | Android Developers", 12 May 2015 (2015-05-12), XP055286583, Retrieved from the Internet <URL:https://web.archive.org/web/20150512180542/http://developer.android.com/guide/topics/connectivity/nfc/hce.html> [retrieved on 20160707] *
CLARKSVILLE RD: "Smart Card Alliance A SMART CARD ALLIANC E MOBILE & NFC COUNCIL WHITE PAPER", 31 August 2014 (2014-08-31), XP055286731, Retrieved from the Internet <URL:http://www.smartcardalliance.org/downloads/HCE-101-WP-FINAL-081114-clean.pdf> [retrieved on 20160707] *
GLOBALPLATFORM INC.: "GlobalPlatform Device Technology TEE System Architecture", 31 December 2011 (2011-12-31), XP055286561, Retrieved from the Internet <URL:http://www.globalplatform.org/> [retrieved on 20160707] *
GLOBALPLATFORM INC.: "GlobalPlatform Device Technology Trusted User Interface API", 30 June 2013 (2013-06-30), XP055286563, Retrieved from the Internet <URL:http://www.globalplatform.org/> [retrieved on 20160707] *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107066888A (zh) * 2017-04-21 2017-08-18 北京豆荚科技有限公司 可扩展的可信用户接口、方法和电子设备
CN107066888B (zh) * 2017-04-21 2020-04-21 北京豆荚科技有限公司 可扩展的可信用户接口、方法和电子设备
CN109872148A (zh) * 2017-12-01 2019-06-11 北京握奇智能科技有限公司 基于tui的可信数据处理方法、装置以及移动终端
US11443323B2 (en) 2018-03-07 2022-09-13 Samsung Electronics Co., Ltd. System and method for secure transactions with a trusted execution environment (TEE)
CN111383015A (zh) * 2018-12-29 2020-07-07 华为技术有限公司 交易安全处理方法、装置及终端设备
CN111383015B (zh) * 2018-12-29 2023-11-03 华为技术有限公司 交易安全处理方法、装置及终端设备
US12001596B2 (en) 2018-12-29 2024-06-04 Huawei Technologies Co., Ltd. Transaction security processing method and apparatus, and terminal device for using a trusted application in association with an audio file

Also Published As

Publication number Publication date
US20180150826A1 (en) 2018-05-31
US11640596B2 (en) 2023-05-02
DE102015006907A1 (de) 2016-12-01
KR20170139658A (ko) 2017-12-19
EP3304466A1 (de) 2018-04-11
KR101957840B1 (ko) 2019-03-13

Similar Documents

Publication Publication Date Title
WO2016192842A1 (de) Endgerät und verfahren für mobiles bezahlen mit trusted execution environment
DE60308385T2 (de) Verfahren zur Unterstützung bargeldloser Zahlung
DE102011100144B4 (de) Sicheres drahtloses Zahlungssystem und Verfahren zu dessen Anwendung
DE10296888T5 (de) System und Verfahren zur sicheren Eingabe und Authentifikation von verbraucherzentrierter Information
EP3559883A1 (de) System zum offline-bezahlen mit e-geld mit mobilem gerät mit kurzer transaktionszeit und abschliessendem settlement
DE10296919T5 (de) System und Verfahren zur sicheren Rückzahlung
WO2012164036A1 (de) Elektronisches system zur raschen und sicheren abwicklung von transaktionen mit mobilen geräten
AT512070A1 (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
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP2393032A1 (de) Verfahren zum Ausführen einer Applikation mit Hilfe eines tragbaren Datenträgers
WO2010089049A1 (de) Mobiles zahlungsverfahren und vorrichtungen
DE102010017861A1 (de) Verfahren zur Handhabung von elektronischen Tickets
DE112012005291T5 (de) Sichere finanzielle Transaktionen unter Verwendung mehrerer Kommunikationstechnologien
EP3428866A2 (de) Datenübertragungs- und -verarbeitungsanordnung und datenübertragungs- und -verarbeitungsverfahren zur bezahlung einer ware oder leistung
DE102011079317A1 (de) Mobiles system für finanztransaktionen
DE19936226A1 (de) Verfahren und Vorrichtungen zur Zugangskontrolle eines Benutzers eines Benutzerrechners zu einem Zugangsrechner
DE10297517T5 (de) Automatisiertes digitales Rechte-Management und Zahlungssystem mit eingebettetem Inhalt
WO2013127520A1 (de) Authentisierte transaktionsfreigabe
DE112020005586T5 (de) Verfahren zum Unterstützen des OTP-Dienstes durch Identifizierung von Benutzern mithilfe eines persönlichen URL-Mediums, Passwortes oder anderer Informationen
EP3035270A1 (de) Kartenbasierte offline-token generierung
EP3561753A1 (de) Datenübertragungs- und verarbeitungsverfahren und anordnung hierfür
EP2790145A1 (de) Verfahren und System zum bargeldlosen Bezahlen oder Geldabheben mit einem mobilen Kundenterminal
EP3361436B1 (de) Verfahren zur freigabe einer transaktion
EP1274971A2 (de) Verfahren zur sicheren bezahlung von lieferungen und leistungen in offenen netzwerken

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16727952

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20177034012

Country of ref document: KR

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 15578085

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE