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.
• 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.
• 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
• 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 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 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.
• 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.
• 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.
• 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)
• General Business, Economics & Management (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (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)

Applications Claiming Priority (2)

Publications (1)

Family

ID=56116386

Family Applications (1)

Country Status (5)

Families Citing this family (20)

Family Cites Families (10)

• 2015
  • 2015-05-29 DE DE102015006907.1A patent/DE102015006907A1/de not_active Withdrawn
• 2016
  • 2016-05-25 KR KR1020177034012A patent/KR101957840B1/ko active IP Right Grant
  • 2016-05-25 EP EP16727952.0A patent/EP3304466A1/de not_active Ceased
  • 2016-05-25 WO PCT/EP2016/000871 patent/WO2016192842A1/de active Application Filing
  • 2016-05-25 US US15/578,085 patent/US11640596B2/en active Active

Also Published As

Similar Documents

Legal Events