WO2017175926A1 - Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité - Google Patents

Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité Download PDF

Info

Publication number
WO2017175926A1
WO2017175926A1 PCT/KR2016/009224 KR2016009224W WO2017175926A1 WO 2017175926 A1 WO2017175926 A1 WO 2017175926A1 KR 2016009224 W KR2016009224 W KR 2016009224W WO 2017175926 A1 WO2017175926 A1 WO 2017175926A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
key
idpkc
kms
encrypted
Prior art date
Application number
PCT/KR2016/009224
Other languages
English (en)
Korean (ko)
Inventor
차완파라슈람
알베스 마틴스파울로 세르지오
Original Assignee
삼성전자 주식회사
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
Priority claimed from GB1605829.9A external-priority patent/GB2549118B/en
Application filed by 삼성전자 주식회사 filed Critical 삼성전자 주식회사
Priority to US16/091,838 priority Critical patent/US11182783B2/en
Priority to EP16898030.8A priority patent/EP3422275A4/fr
Publication of WO2017175926A1 publication Critical patent/WO2017175926A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management

Definitions

  • An electronic payment method, an electronic device and computer program instructions used in an electronic payment system relates to an electronic payment method and an electronic device using ID-based public key cryptography (IDPKC) in an electronic payment system.
  • IDPKC ID-based public key cryptography
  • Electronic payment systems allow users to pay using a payment card, such as a credit or debit card.
  • Transactions using a payment card include the following parties. (1) Cardholder, the holder of the payment card registration, (2) Issuer, the financial institution that issued the payment card, (3) Merchant, the goods or goods provider, and (4) Payment on behalf of the merchant Acquirer, which is a financial institution that authorizes, and (5) Payment Gateway, which is an electronic device that processes merchant payment messages.
  • SET Secure Electronic Transaction
  • OI Order Information
  • PI Payment Information
  • the merchant requests payment authorization by forwarding the cardholder's encrypted PI and encrypted OI to the gateway.
  • "dual signature" is used to link two messages for the other two recipients, an OI for the merchant and a PI for the gateway.
  • merchants do not have access to the cardholder's bank account details, thereby protecting the cardholder's personal information.
  • the main drawback of the SET protocol is that a public-key infrastructure (PKI) is required to handle the cardholder's certificate, which must be signed by a Certificate Authority (CA).
  • PKI public-key infrastructure
  • CA Certificate Authority
  • IDPKC identity-based public key cryptography
  • KMS key management service
  • IDPKC identity-based public key cryptography
  • FIG. 1 is a flow diagram of an electronic payment system, according to one embodiment.
  • FIG. 2 is a diagram of an electronic payment system, according to one embodiment.
  • FIG. 3 is a flow diagram of a method for transmitting a series of messages during a key provisioning process, according to one embodiment.
  • FIG. 4 is a flowchart of a method performed by a cardholder device during the key provisioning process of FIG. 3, according to one embodiment.
  • KMS key management service
  • FIG. 6 is a flowchart of a method in which a series of messages are transmitted during a transaction in the electronic payment system of FIG. 2, according to one embodiment.
  • FIG. 7 is a flowchart of a method performed by a cardholder during the transaction process of FIG. 6, according to one embodiment.
  • FIG. 8 is a flowchart of a method performed by a merchant during the transaction process of FIG. 6, according to one embodiment.
  • FIG. 9 is a flowchart of a method performed by a payment gateway during the approval process of FIG. 6, according to one embodiment.
  • FIG. 10 is a block diagram illustrating a configuration of a cardholder device, according to an embodiment.
  • a first aspect of the present disclosure is generated according to an identity-based public key cryptography (IDPKC) protocol from a key management service (KMS) server that stores personal information of a user.
  • IDPKC identity-based public key cryptography
  • KMS key management service
  • Receiving a private key of an authorized user Encrypting payment information using the public device's public key generated according to the IDPKC protocol and encrypting the order information using the public key of the merchant device generated according to the IDPKC protocol ; Generating a dual signature of encrypted payment information and encrypted order information using a private key according to the IDPKC protocol; Sending a transaction request to the merchant device, wherein the transaction request includes dual signed payment information and order information; And receiving an answer to the transaction request from the merchant device.
  • IDPKC identity-based public key cryptography
  • a memory that stores at least one program; And a processor for executing a secure transaction in the electronic payment system by executing at least one program stored in the memory, wherein the at least one program is a card generated in accordance with the IDPKC protocol from a KMS server storing personal information of the user Receiving a holder's private key; Encrypting payment information using the public key of the payment device, generated according to the IDPKC protocol, and encrypting the order information using the public key of the merchant device, generated according to the IDPKC protocol; Generating a double signature of encrypted payment information and encrypted order information using the private key according to the IDPKC protocol; Sending a transaction request to the merchant device, wherein the transaction request includes dual signed payment information and order information; And receiving an answer to the transaction request from the seller device.
  • the electronic device may include instructions for executing the transaction.
  • the third aspect of the present disclosure may also include a computer readable recording medium having recorded thereon a program for executing the method of the first aspect on a computer.
  • the electronic payment system described below may be a card based electronic payment system, but in addition it may be an electronic payment system based on any suitable payment means.
  • Transactions through a card-based electronic payment system are usually carried out in accordance with regulations established by the Cards Association, which usually takes two steps.
  • the cardholder provides the merchant with details of the payment card and the merchant submits an authorization request to the gateway.
  • the Payment Gateway forwards the request to the issuer, which verifies that the cardholder's account is valid and that sufficient funds are available to pay the transaction.
  • the funds are "held” and deducted from the cardholder's account, but are not transferred to the merchant.
  • the merchant typically submits the approved transactions to the gateway in batches on the last business day.
  • the merchant creates and sends a payment request to the gateway, and the gateway sends the payment request to the card association, and the card association withdraws the payment from the issuer and sends it to the acquirer.
  • the acquirer then receives the remittance from the issuer and pays it to the merchant.
  • the merchant device may include a merchant server
  • the payment device may include a payment server
  • FIG. 1 is a flow diagram of an electronic payment system, according to one embodiment.
  • the cardholder device receives an ID-based public key cryptography method from a key management service (KMS) server that stores a user's personal information. Receive a user's private key generated according to the public key cryptography (IDPKC) protocol.
  • IDPKC public key cryptography
  • the cardholder device encrypts the Payment Information using the public key of the payment device (hereinafter referred to as Payment Gateway), generated according to the IDPKC protocol, and generates a merchant device (hereinafter referred to as IDPKC protocol).
  • the order information is encrypted using the public key of the affiliated device.
  • the cardholder device generates a dual signature of encrypted payment information and encrypted order information using the private key, according to the IDPKC protocol.
  • the cardholder device sends a transaction request to the merchant device that includes the dual signed payment information and the order information.
  • the cardholder device receives a response to the transaction request from the merchant device.
  • An electronic payment system is a card-based payment system in which a cardholder can use a payment card, such as a debit or credit card, to purchase goods or services from a merchant.
  • a payment card such as a debit or credit card
  • One embodiment of an electronic payment system includes a cardholder device 201, merchant device 202, payment gateway 203, issuer 211, and acceptor 212 as an electronic device.
  • the cardholder device 201 may be a suitable electronic device such as a smart phone, tablet, laptop or desktop.
  • the electronic payment system can further include a KMS, which is one or more key management entities.
  • KMS can be a server.
  • Each of the issuer 211 and the acquirer 212 use separate KMS, which can communicate securely with each other.
  • a single KMS entity may perform the functions of both issuer KMS 221 and acquirer KMS 222.
  • the issuer KMS 221 and the acquirer KMS 222 may securely distribute the private key material to other electronic devices in the electronic payment system.
  • Each of the cardholder device 201, the merchant device 202, the payment gateway 203, the issuer KMS 221 and the takeover KMS 222 are in the form of a computer readable recording medium on which computer program instructions may be stored.
  • the processing means may comprise one or more processors. Instructions may be adapted in accordance with an embodiment such that the methods disclosed in an electronic device on which computer program instructions are executed may be practiced.
  • the cardholder device 201, the merchant device 202, and the payment gateway 203 may be provided with a KMS certificate, which is public information in the form of a signed digital document for the KMS.
  • Information that may be included in the KMS certificate may be a master public key of the KMS, a unique resource identifier (URI) of the KMS, and a validity period of the master public key.
  • URI unique resource identifier
  • a KMS public key may be used to encrypt information during a transaction.
  • the information in the KMS certificate allows the entity to communicate with the KMS to obtain a private key element, which is then used to conduct secure transactions.
  • the certificate of issuer KMS 221 is securely provisioned to cardholder device 201
  • the certificate of acquirer KMS 222 is also securely provisioned to merchant device 202 and payment gateway 203.
  • the KMS certificate may be distributed through any suitable mechanism that fully ensures the integrity and integrity of the KMS certificate. Since the KMS certificate does not need to be shared with third parties after the KMS certificate has been provisioned on the electronic device, the KMS certificate does not need to be signed by a CA.
  • methods that can be used to distribute KMS certificates include the following methods.
  • a method of transmitting a KMS certificate via an online banking application a method of pre-loading a KMS certificate on the cardholder device 201, the merchant device 202, and the payment gateway 203, or the merchant device 202.
  • the KMS certificate may be distributed in such a way that the KMS certificate is included in the software securely transmitted and installed in the payment gateway 203.
  • a transport key obtained through a bootstrapping process may be used.
  • a copy of a cardholder's certificate is sent to the merchant when the cardholder orders the goods or services.
  • the certificate must be signed by a CA in order for a third party, such as a merchant or payment gateway, to verify that the cardholder's certificate has been authenticated.
  • a third party such as a merchant or payment gateway
  • entities do not share a certificate signed by a CA during electronic transactions, and thus do not use a PKI.
  • merchant device 202 receives a message that is correctly signed with IDPKC from cardholder device 201, merchant device 202 indicates that cardholder device 201 has been provisioned by issuer KMS 221. You can see that.
  • the message may include public parameters of issuer KMS 221.
  • the cardholder device 201 only decrypts the merchant device 202 and the payment gateway 203 using IDPKC and sends a message. You can verify that they can be signed.
  • Sakai-Kasahara Key Encryption SAKKE
  • Elliptic Curve-based Certificateless Signatures for Identity-based Encryption ECCSI
  • SAKKE and ECCSI are described as an example and other embodiments may use other IDPKC protocols than SAKKE and ECCSI.
  • merchant device 202 and payment gateway 203 establish a secure communication channel with acquirer KMS 222, merchant device 202 and payment gateway 203 authenticate, and authenticate the certificate of KMS.
  • the private key element is provisioned at the merchant device 202 and the payment gateway 203 by authenticating the takeover KMS 222.
  • the merchant device 202 is not only provisioned with a private key element, but also provided with information about the identifier of the payment gateway 203.
  • a predefined format is applied to all merchant device identifiers and all payment gateway identifiers, thereby making it possible to clearly distinguish between merchants and gateways.
  • all merchant identifiers may be prefixed with "merchant” and all gateway identifiers may be prefixed with "gateway".
  • the cardholder device 201 may be assigned a unique identifier that is encrypted and linked to the cardholder device 201.
  • the cardholder device 201 may include a smartphone that includes a Trusted Execution Environment (TEE), which includes public / private key pairs and other security elements provided by KMS.
  • TEE Trusted Execution Environment
  • the cardholder device 201 may also include a smart card with a tamper suppression module including a public / private key pair and a KMS signature that links the unique identifier of the cardholder device 201 to the public key.
  • software with a unique identifier and public / private key pair may be securely provided to issuer 211 and installed in cardholder device 201.
  • An IDPKC private key element can be provisioned in the cardholder device 201 by establishing a secure communication channel between the cardholder device 201 and the issuer KMS 221.
  • the issuer KMS 221 uses a public / private key pair to authenticate itself, authenticates the cardholder in a suitable way such as a fixed password or one-time-password (OTP). Further, the issuer KMS 221 may be authenticated using the certificate of the issuer KMS 221.
  • provisioning an IDPKC private key using a public / private key pair coupled to a cardholder device may be compatible with electronic devices that include public / private key pairs based on other cryptographic schemes. Other methods may be applied in other embodiments, for example, an IDPKC private key element may be coupled directly to the cardholder device 201.
  • FIGS. 3, 4 and 5 are diagrams illustrating a key provisioning process used in the system shown in FIG. 2 according to an embodiment.
  • 3 is a flowchart of a procedure in which a series of messages are sent during a key provisioning process
  • FIG. 4 is a flowchart of a method performed by a cardholder device during a key provisioning process
  • FIG. 5 is performed by an issuer KMS during a key provisioning process.
  • the methods shown in FIGS. 3, 4 and 5 allow essential security elements such as private key elements and KMS certificates to be securely provisioned to the cardholder device 201 when using the electronic payment system.
  • the cardholder device 201 generates a registration request REG_FORM_REQ for registering a payment card with the issuer KMS 221 and the key provisioning process begins.
  • the registration request may include a time stamp and a card identifier that can uniquely identify the payment card to be registered.
  • the card identifier may be a 16 digit card number of a credit or debit card.
  • the card identifier may be an identifier different from the identifier of the card owner.
  • the issuer KMS 221 may use the payment card to verify that the registration request is valid, and the time stamp may be used to avoid a replay attack.
  • the generated registration request is signed with the public / private key pair that the cardholder device 201 is holding.
  • the public / private key pair may be stored in the TEE.
  • the signed registration request is encrypted using the first symmetric key and the first symmetric key is encrypted using the public key of the issuer KMS 221.
  • the first symmetric key can be sealed using ElGamal encryption.
  • the first symmetric key is randomly generated, but in another embodiment the first symmetric key may be selected from a list of predetermined symmetric keys.
  • encrypting the first symmetric key using the public key of the KMS receives and stores in the memory one or more KMS public keys corresponding to the one or more KMS according to the IDPKC protocol, and the KMS used by the merchant By receiving an identifier of, the KMS public key corresponding to the KMS identifier may be retrieved from the memory. The retrieved KMS public key may be used to encrypt the first symmetric key.
  • step 403 an encrypted REG_FORM_REQ message and an encrypted first symmetric key are sent to the issuer KMS 221.
  • the data to be shared such as the REG_FORM_REQ message
  • the data to be shared is encrypted with symmetric key encryption, instead of being computed expensively asymmetric key encryption (public key encryption). Therefore, after encrypting data using symmetric key encryption, it is more efficient to encrypt the symmetric key asymmetrically using a public key encryption key (KEK).
  • the REG_FORM_REQ message may be directly encrypted with asymmetric encryption, in which case step 402 shown in FIG. 4 is omitted.
  • the cardholder device 201 receives a request for additional registration information (REG_FORM_RES).
  • REG_FORM_RES a request for additional registration information
  • the REG_FORM_RES message is signed by the issuer KMS 221, and at step 405 the cardholder device 201 verifies the signature of the KMS to determine if the signed message is authentic. If the signature is not verified to be valid, the process ends. If the signature is verified to be valid, the process proceeds to step 406 and the cardholder device 201 completes the registration form.
  • the cardholder device 201 fills in the requested information in the registration form.
  • the requested information may be appropriate to be considered necessary to identify the name of the payment card holder, the expiration date of the payment card, the billing source of the payment card, and / or the requester, such as a password, OTP, or a valid card holder. May contain additional information.
  • the cardholder device 201 may generate a random number that the issuer KMS 221 will use to link the cardholder's identifier to an account where funds accessible through the payment card have accumulated.
  • the completed registration form and generated random number are encrypted using a randomly generated second symmetric key, and the second symmetric key is encrypted using the public key of the issuer KMS 221 according to the appropriate IDPKC protocol.
  • the IDPKC protocol may be SAKKE.
  • the registration form, random number, and second symmetric key may be signed using the private key of the cardholder device 201.
  • a first symmetric key which is the same key used to encrypt the REG_FORM_REQ message, may be used to encrypt the KEY_PROV_REQ message.
  • step 408 the cardholder device 201 sends a key provisioning request (KEY_PROV_REQ) message to the issuer KMS 221, which includes the second symmetric key and encrypted additional registration information.
  • the cardholder device 201 receives a key provisioning (KEY_PROV) message containing the required security information.
  • issuer KMS 221 encrypts the KEY_PROV message using the public key of the public / private key pair held in cardholder device 201.
  • the public / private key pair may be stored in the TEE and signed by the issuer KMS 221.
  • the cardholder device 201 decrypts the KEY_PROV message and stores the security information, thereby completing the card registration process.
  • the security information is securely stored in the cardholder device 201.
  • the security information may be stored in a TEE or tamperproof module.
  • the KEY_PROV message may include security information needed for the cardholder device 201 to participate in a transaction made in the electronic payment system.
  • the KEY_PROV message contains the IDPKC private key of the cardholder device 201.
  • the security information may include a signature for an account security element that links the cardholder's identifier to an account associated with the payment card, and is executed by the cardholder device 201 in a series of payment card numbers, step 406.
  • the generated random number may further include a random number generated by the publisher KMS 221.
  • the cardholder identifier may be any suitable public identifier, such as the cardholder's email address or phone number.
  • the received security information may further include one or more KMS certificates.
  • Each KMS certificate may include information required for communicating with a particular KMS, such as the KMS's master public key, and the KMS's Unique Resource Identifier (URI) and / or the validity of the master public key.
  • Received KMS certificates may be stored in the KMS certificate store in the cardholder device 201.
  • step 501 issuer KMS 221 receives a REG_FORM_REQ message from cardholder device 201.
  • the REG_FORM_REQ message is signed by the cardholder device 201 and encrypted with a symmetric key encryption scheme, and the symmetric key is encrypted using the ElGamal public key of the issuer KMS 221.
  • step 502 the issuer KMS 221 decrypts the sealed symmetric key and uses the decrypted symmetric key in step 503 to decrypt the remaining encrypted content in the REG_FORM_REQ message.
  • step 504 the issuer KMS 221 checks whether the signature and identifier of the cardholder device 201 are valid. If the signature and identifier are invalid, the process ends. If the signature and identifier are valid, flow proceeds to step 505. Steps 502 to 504 may be omitted or changed depending on the encryption method of the cardholder device 201 and whether the REG_FORM_REQ message is digitally signed.
  • the issuer KMS 221 may identify the issuer from the information contained in the REG_FORM_REQ message. For example, for debit or credit cards, the first six or eleven digits of the card number can be used to identify the issuer. After the issuer is identified, issuer KMS 221 selects a registration form appropriate for the issuer. In step 506, the issuer KMS 221 digitally signs the form and sends a REG_FORM_RES message containing the signed form to the cardholder device 201. For example, issuer KMS 221 may sign the form using an Elliptic Curve Digital Signature Algorithm (ECDSA) or other suitable digital signature scheme.
  • EDSA Elliptic Curve Digital Signature Algorithm
  • step 507 the issuer KMS 221 receives a KEY_PROV_REQ message that includes the completed registration form.
  • issuer KMS 221 decrypts the digital envelope to obtain a second symmetric key and verifies the signature of the message. The decrypted second symmetric key is used to decrypt the rest of the message.
  • the issuer KMS 221 may communicate with the issuer to verify the information in the registration request. If the signature is valid and the information is verified from the issuer, issuer KMS 221 proceeds to step 508.
  • issuer KMS 221 generates the required security information including the private key corresponding to the cardholder's identifier.
  • issuer KMS 221 generates a new random number concatenated with the random number in the completed registration form provided from cardholder device 201, the cardholder's identifier, and the card identifier.
  • the card identifier may be a 16 digit card number.
  • the issuer KMS 221 generates a signature for the generated output.
  • the security information includes security information including an individual key, a new random number, a certificate storage location of a signed and trusted KMS.
  • the security information is signed and encrypted using a second symmetric key.
  • the security information including the private key, i.e. the resulting message KEY_PROV is sent to the cardholder device 201.
  • FIGS. 3, 4 and 5 A key provisioning process that can be used to provide the cardholder device 201 with an identifier of a payment card and a private key encrypted and linked is shown in FIGS. 3, 4 and 5.
  • REG_FORM_REQ, REG_FORM_RES, KEY_PROV_REQ, and KEY_PROV messages are sent via an online banking application.
  • other secure communication methods may be used during the key provisioning process.
  • the issuer KMS 221 sends a REG_FORM_RES message to inform the cardholder device 201 of the correct form for sending the required information of the payment card to be registered.
  • the form may be agreed in advance in the same manner as defined by industry standards.
  • the REG_FORM_REQ and REG_FORM_RES messages shown in FIG. 3 may be omitted, and the cardholder device 201 may generate a KEY_PROV_REQ message as an initial registration request message.
  • Private key elements can be provisioned at the merchant device 202 in a manner similar to that shown in FIGS.
  • the merchant device 202 may have the first private / public key pair embedded in the software provided by the acquirer 212.
  • the built-in initial private / public key pair can be used to encrypt and sign messages during the key provisioning process.
  • the takeover KMS 222 may verify the information included in the KEY_PROV_REQ message provided from the takeover 212 rather than the issuer 211.
  • the merchant device 202 is also provisioned with the personal decryption key as well as the personal signature key.
  • the acceptor 212 uses a method suitable for provisioning the required private key element to the payment gateway, the method shown in FIGS. 3-5 may be used, but is not limited thereto.
  • the private keys provided to the cardholder device 201, the merchant device 202 and the payment gateway 203 may then be used during a secure transaction involving a payment card.
  • 6-9 illustrate an IDPKC based secure transaction process, according to one embodiment.
  • the cardholder device 201, the merchant device 202, and the payment gateway 203 exchange a series of messages with each other during a secure transaction.
  • the steps performed by the cardholder device 201, the merchant device 202, and the payment gateway 203 are shown in flow charts in FIGS. 7, 8, and 9, respectively.
  • the transaction process can be in two stages, approval and settlement, similar to the SET system.
  • the payment step may be omitted and payment may be automatically transferred during the approval step.
  • a new transaction is initiated when the cardholder device 201 generates an initial request (INIT_REQ) to initiate a secure transaction.
  • the INIT_REQ message is sent to the merchant device 202 to request the IDPKC identifiers of the merchant device 202 and the payment gateway 203 and the KMS identifiers of each of the merchant device 202 and the payment gateway 203.
  • merchant device 202 and payment gateway 203 both use the same acceptor KMS 222. In other embodiments, merchant device 202 and payment gateway 203 may use different KMS.
  • the cardholder device 201 receives a response INIT_RES from the merchant device 202.
  • the INIT_RES message may include the unique transaction identifier provided from the merchant device 202 as well as the identifiers of the merchant device 202, the payment gateway 203 and the takeover KMS 222.
  • the merchant and gateway identifiers have different formats.
  • merchant identifiers may be prefixed with "merchant” and gateway identifiers may be prefixed with "gateway”.
  • the cardholder device 201 checks if the public identifier of the received payment gateway 203 matches the predicted payment gateway format. Also at step 703, the cardholder device 201 may verify the format of the received merchant ID. However, in general, verifying the format of the merchant identifier may be less important than verifying the payment gateway identifier, in that the information encrypted by the merchant identifier is less sensitive information than the information encrypted by the gateway identifier. If the INIT_RES message is signed by the merchant device 202, the signature can also be verified.
  • the trading process is initiated by the exchange of the Initiation Request INIT_REQ and Response INIT_RES messages, although in other embodiments the Initiation messages may be omitted.
  • the cardholder may skip the initiation step and immediately begin generating and encrypting the PI and OI of step 705.
  • step 703 if the payment gateway identifier and / or signature is not verified, the process ends. If so, the process proceeds to step 704 where the cardholder device 201 obtains the IDPKC public keys of the merchant device 202 and the payment gateway 203.
  • the cardholder device 201 encrypts payment information (PI) using the public key of the payment gateway 203, according to the IDPKC protocol, and uses the public key of the merchant device 202. Encrypt OI (order information).
  • PI payment information
  • OI order information
  • the PI can only read by the payment gateway 203 and the OI can only read by the merchant device 202.
  • a unique transaction identifier provided by the merchant device 202 may be included in both the PI and the OI to allow the payment gateway 203 to link the PI and the OI in the approval step.
  • the OI may include information linking communication and transaction requests between the cardholder device 201 and the merchant device 202 in a previous purchase and order process.
  • the OI does not include purchase information, such as a description of the purchased item or service or purchase conditions. Instead, purchase information is exchanged between the cardholder device 201 and the merchant device 202 in the shopping phase before the transaction start message INIT_REQ is sent.
  • the PIs provide financial information that is important for the financial network or issuer 211 to process the authorization from the cardholder device 201 to the payment gateway 203. In one embodiment, a secret random number is obtained during the key provisioning process.
  • the cardholder device 201 generates a double signature of the encrypted PI and encrypted OI using the cardholder's public identifier and the encrypted private key linked to it according to the IDPKC protocol.
  • the merchant device 202 and the payment gateway 203 can verify the signature using the cardholder's public identifier.
  • a double signature is generated by generating a message digest of both OI and PI, and signing a series of digests using ECCSI. The message digests of the OI and PIs are then sent in a transaction request message (PURCH_REQ) with a double signature.
  • step 707 the cardholder device 201 performs an additional encryption step before sending the PURCH_REQ message.
  • the cardholder device 201 generates any symmetric encryption key (hereafter third symmetric key).
  • the third symmetric key is used to encrypt the double signed PIs and account number, and the third symmetric key is sealed in a similar manner as in steps 402 and 407 of FIG. 4 using the public key of the payment gateway 203. .
  • the cardholder device 201 sends a PURCH_REQ message to the merchant device 202.
  • the PURCH_REQ message may include a double signed OI, an encrypted cipher text of a double signed PI, an account number, and an encrypted third symmetric key.
  • the PURCH_REQ message may include a KMS signature that links the cardholder identifier to the account number in the manner described in step 508 of FIG.
  • the cardholder device 201 then receives a confirmation in the form of a signed PURCH_RES message that the authorization has been granted.
  • the cardholder device 201 may verify the signature of the merchant and perform an action such as displaying a message to the cardholder based on the contents of the PURCH_RES message.
  • Merchants can independently complete cardholder orders by delivering contracted items or performing services.
  • step 801 the merchant device 202 receives the PURCH_REQ message and at step 802 decrypts the message using the IDPKC private key of the merchant device 202. Since the PI in the PURCH_REQ message is encrypted using the public key of the payment gateway 203, the merchant device 202 cannot read the contents of the PI.
  • merchant device 202 uses the received OI to determine a payment amount to be approved.
  • the OI may include the amount to be authorized, and merchant device 202 may use the information contained in the OI to identify the amount agreed to by the cardholder in the past purchase process.
  • Merchant device 202 may obtain a unique transaction identifier from the OI.
  • merchant device 202 may encrypt the transaction information using the public key of payment gateway 203 in accordance with the IDPKC protocol.
  • the transaction information may include a payment amount and a transaction identifier to be approved.
  • the same computationally efficient two layer encryption scheme as described in steps 402, 407 and 707 is used.
  • the transaction information is encrypted using the fourth symmetric key, and the fourth symmetric key is encrypted using the public key of the payment gateway 203 according to the IDPKC protocol.
  • a SAKKE encryption scheme may be used, and in other embodiments, another IDPKC protocol scheme may be selected.
  • merchant device 202 signs encrypted transaction information using IDPKC.
  • ECCSI signatures may be used, and in other embodiments, other signature schemes may be selected.
  • an authorization request (AUTH_REQ) containing the signed encrypted transaction information and the received encrypted payment information is sent to the payment gateway 203.
  • the authorization request (AUTH_REQ) may include the received encrypted PI and encrypted transaction information, and may further include a KMS signature that links the cardholder's identifier to the account.
  • an encrypted fourth symmetric key may be included in the grant request AUTH_REQ.
  • an authorization response (AUTH_RES) is received.
  • the authorization response AUTH_RES tells whether the payment has been approved by the issuer 211.
  • the AUTH_RES message may include a symmetric key encrypted using the public key of the merchant device 202.
  • the merchant device 202 may decrypt the symmetric key and use the decrypted symmetric key to decrypt other encrypted content in the AUTH_RES message.
  • the AUTH_RES message may be signed by the payment gateway 203. If the signature is valid, the authorization has been made and the merchant device 202 stores the authorization response.
  • the AUTH_RES message may further include a payment token to be used when making a payment through a payment request, and the payment token may be stored in the merchant device 202.
  • step 808 merchant device 202 After receiving the AUTH_RES message, at step 808, merchant device 202 generates a transaction reply message (PURCH_RES).
  • the transaction reply message PURCH_RES is digitally signed using ECCSI and sent to the cardholder device 201.
  • the merchant device 202 determines whether to complete the transaction based on the approval.
  • merchant device 202 may send a transaction response message (PURCH_RES) prior to the approval process.
  • the cardholder device 201 may then send a query message for the approval result to the merchant device 202.
  • step 901 the payment gateway receives the grant request.
  • step 902 payment gateway 203 decrypts the PI and transaction information using IDPKC.
  • the payment gateway 203 uses the private key of the payment gateway 203 to decrypt the fourth symmetric key included in the received AUTH_REQ message.
  • the payment gateway 203 decrypts the transaction information using the decrypted fourth symmetric key and verifies the signature of the merchant device 202.
  • the payment gateway 203 decrypts the envelope of the cardholder to obtain another symmetric key, and uses the obtained symmetric key to decrypt the PI.
  • the payment gateway 203 may verify the dual signature to verify that the PI was signed using the cardholder's private key and that the PI was not forged.
  • the payment gateway 203 may verify the KMS signature to verify that the identifier represents the cardholder's account.
  • the payment gateway 203 may check that the transaction identifier and the amount presented by the merchant device 202 match the values in the PI.
  • the payment gateway 203 communicates with the issuer 211 identified by the payment information to determine if the payment amount presented in the transaction information can be accepted.
  • the payment gateway 203 can use any suitable method for communicating with the issuer 211.
  • the payment gateway 203 may use IDPKC encryption and signatures when communicating with the issuer 211, or may use other types of encrypted protocols.
  • the payment gateway 203 After receiving the authorization response from the issuer 211, in step 904, the payment gateway 203 generates an authorization response message (AUTH_RES) using its identifier and digitally signs it using ECCSI.
  • the AUTH_RES message informs the merchant device 202 if the issuer 211 has approved payment of the requested amount.
  • the AUTH_RES message may further include a payment token.
  • the AUTH_RES message may be encrypted using the symmetric key enclosed with the identifier of the merchant device 202, and a SAKKE encryption scheme may be used.
  • an encrypted AUTH_RES message containing the enclosed symmetric key is sent to the merchant device 202.
  • the electronic device 1000 may be a card holder device 201 and a merchant device 202.
  • the electronic device 1000 may include a memory 1100 and a processor 1200, and may include a display 1300 that displays the received answer.
  • the electronic device 1000 may include a user interface 1400, and the electronic device 1000 may perform the processes described above based on a user input through the user interface 1400.
  • the configuration of the electronic device 1000 is not limited thereto.
  • the payment process proceeds as follows. After a certain period of time (eg, the last business day) and the ordering phase, the merchant device 202 requests a payment by generating a payment request and digitally signing the payment request using an IDPKC signature.
  • the IDPKC signature scheme may be ECCSI.
  • the payment request may include the final amount of the transaction and the transaction identifier, and may also include other information about the transaction.
  • the payment request may be enclosed using a randomly generated symmetric key, which is a symmetric key enclosed using an IDPKC encryption scheme by a payment gateway identifier.
  • the IDPKC encryption scheme may be SAKKE.
  • the merchant device 202 sends the payment request message CLEAR_REQ including the encrypted payment request and the encrypted token to the payment gateway 203.
  • the payment gateway 203 When the payment gateway 203 receives the CLEAR_REQ message, the payment gateway 203 decrypts the enclosed symmetric key and decrypts the payment request using the decrypted symmetric key. In one embodiment, the payment gateway 203 may verify the signature signed by the merchant device 202 to verify that the payment request was signed using the merchant's private key. The payment gateway 203 may use the information contained in the payment request and payment token to generate a request to be sent over the financial network with the issuer 211. In response to the request from the payment gateway 203, the issuer 211 transfers funds to the acquirer 212.
  • the payment gateway 203 generates and digitally signs a payment reply message CLEAR_RES using an IDPKC signature such as ECCSI.
  • the IDPKC signature scheme may be ECCSI.
  • the payment answer message CLEAR_RES may be encrypted using a randomly generated symmetric key, which is enclosed by an identifier of the merchant device 202 in IDPKC encryption.
  • the IDPKC encryption scheme may be SAKKE.
  • the signed encrypted CLEAR_RES message is sent to the merchant device 202, which can decrypt the symmetric key contained in the SAKKE envelope and the rest of the content in the CLEAR_RES message. After verifying the signature, the merchant device 202 may store a CLEAR_RES message that will be used to settle the transfer received from the takeover 212.
  • one embodiment describes a single payment request
  • multiple transactions may be included in a single payment request message.
  • a separate payment process may be omitted.
  • the payment specified in the approval request may be transferred from issuer 211 to takeover 212 as soon as issuer 211 receives the approval request.
  • the IDPKC based secure transaction procedures described above may be applied to offline transactions.
  • the embodiments described above may be applied even when purchasing in a store by replacing an existing credit card now terminal with electronic devices compatible with the IDPKC based protocols described above.
  • a method of performing a secure transaction in an electronic payment system comprising: receiving security information including a private key of a cardholder from a KMS, encrypting payment information using a payment gateway's public key, and using a merchant's public key Encrypt order information, generate a double signature of encrypted payment information and encrypted order information using a private key, send a transaction request containing the double signed payment information and order information to the merchant, request a transaction from the merchant You may receive an answer to.
  • the merchant device 202 receives a transaction request that includes encrypted payment information encrypted according to the IDPKC protocol and double signing of the encrypted order information, and decrypts the order information using the merchant private key, according to the IDPKC protocol. Can be.
  • an approval request including the received encrypted payment information and the encrypted transaction information may be transmitted to the payment gateway, and after receiving the approval response, it may be determined whether to complete the requested transaction based on the received approval response.
  • the received encrypted payment information may include a payment amount to be approved.
  • the merchant device 202 may also obtain transaction information, including the payment amount to be approved, from the received order information.
  • transaction information can be encrypted with the payment gateway's public key and the encrypted payment information can be signed.
  • An authorization request is generated that includes the signed transaction information and the received payment information, and the generated authorization request is sent to the payment gateway.
  • the transaction information can be encrypted using the fourth symmetric key, and according to IDPKC, the fourth symmetric key can be encrypted using the payment gateway's public key. have.
  • the encrypted fourth symmetric key can be included in the authorization request.
  • the payment gateway 203 may receive an authorization request that includes encrypted payment information and encrypted transaction information.
  • the account holding entity identified by the payment information is used to decrypt payment information and transaction information using the payment gateway's private key and to verify that the payment amount included in the transaction information can be accepted. entity).
  • an authorization request including information on whether the payment is authorized using the merchant's public key may be encrypted, and an authorization response may be transmitted to the merchant.
  • the merchant device 202 that processes the secure transaction in the electronic payment system may include a non-transitory computer readable store for storing computer program instructions.
  • the merchant device 202 receives a transaction request that includes double signing of encrypted payment information and encrypted order information according to IDPKC, decrypts the order information using the merchant private key according to IDPKC, Stored computer program instructions for sending an authorization request, including encrypted payment information and encrypted transaction information, to the payment gateway, receiving an authorization response, and determining whether to complete the requested transaction based on the received authorization response. It may include one or more processors for execution.
  • the payment gateway 203 which processes secure transactions in an electronic payment system, may include a non-transitory computer readable store for storing computer program instructions.
  • the payment gateway receives an authorization request including encrypted payment information and encrypted transaction information, decrypts the payment information and the transaction information using a payment gateway private key according to IDPKC, and includes the payment information in the payment information. Encrypts the authorization request with the account holding entity identified by the payment information to ensure that the payment amount received can be accepted, and includes information as to whether the payment was authorized using the merchant's public key, according to IDPKC And one or more processors to execute the stored computer program instructions that enable the sending of an authorization response to the merchant.
  • a KMS providing a private key in an electronic payment system may include a non-transitory computer readable store for storing computer program instructions. Also, receive a registration request and a symmetric key including a cardholder's public identifier, generate a private key linked to the cardholder's public identifier according to IDPKC, encrypt the private key with the symmetric key, and encrypt the And one or more processors for executing the stored computer program instructions that transmit security information including the private key.
  • the electronic payment system can include a cardholder device 201, a merchant device 202, a payment gateway 203, and KMS 221, 222.
  • Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media.
  • Computer readable media may include both computer storage media and communication media.
  • Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • Communication media typically includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, or other transmission mechanism, and includes any information delivery media.

Landscapes

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

Abstract

L'invention concerne un procédé de paiement électronique et un dispositif électronique qui utilisent une cryptographie à clé publique basée sur l'identité. L'invention concerne un procédé de paiement électronique comprenant les étapes consistant : à recevoir, en provenance d'un serveur de service de gestion de clé permettant de stocker des informations personnelles d'un utilisateur, la clé privée de l'utilisateur générée selon le protocole de cryptographie à clé publique basée sur l'identité (IDPKC) ; à crypter des informations de paiement à l'aide d'une clé publique d'un dispositif de paiement généré selon le protocole IDPKC et à crypter des informations de commande à l'aide d'une clé publique d'un dispositif de vendeur généré conformément au protocole IDPKC ; à générer une double signature des informations de paiement cryptées et des informations de commande cryptées à l'aide de la clé privée selon le protocole IDPKC ; à transmettre une demande de transaction comprenant les informations de paiement et les informations de commande qui ont été doublement signées au dispositif de vendeur ; et à recevoir, en provenance du dispositif de vendeur, une réponse à la demande de transaction.
PCT/KR2016/009224 2016-04-05 2016-08-22 Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité WO2017175926A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/091,838 US11182783B2 (en) 2016-04-05 2016-08-22 Electronic payment method and electronic device using ID-based public key cryptography
EP16898030.8A EP3422275A4 (fr) 2016-04-05 2016-08-22 Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GB1605829.9 2016-04-05
GB1605829.9A GB2549118B (en) 2016-04-05 2016-04-05 Electronic payment system using identity-based public key cryptography
KR10-2016-0105583 2016-08-19
KR1020160105583A KR102621116B1 (ko) 2016-04-05 2016-08-19 Id 기반 공개 키 암호화를 이용한 전자 지불 방법 및 전자 디바이스

Publications (1)

Publication Number Publication Date
WO2017175926A1 true WO2017175926A1 (fr) 2017-10-12

Family

ID=60000520

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2016/009224 WO2017175926A1 (fr) 2016-04-05 2016-08-22 Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité

Country Status (1)

Country Link
WO (1) WO2017175926A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020097257A1 (fr) * 2018-11-08 2020-05-14 Paypal, Inc. Gestionnaire de stockage de carte pour le suivi de stockage de données de carte sur l'ensemble des plateformes de fournisseurs de services
CN112202561A (zh) * 2020-09-29 2021-01-08 福州东方智慧网络科技有限公司 一种基于分布式终端的自主结算方法
CN113592484A (zh) * 2021-07-16 2021-11-02 支付宝(杭州)信息技术有限公司 一种账户的开立方法、系统及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002514839A (ja) * 1998-05-05 2002-05-21 シー． チェン，ジェイ 電子商取引用の暗号のシステムおよび方法
JP2009526321A (ja) * 2006-02-08 2009-07-16 イマジニア・ソフトウェア，インコーポレーテッド 変化する識別子を使用して販売時点情報管理端末において取引を実行するためのシステム
KR20100035366A (ko) * 2008-09-26 2010-04-05 고려대학교 산학협력단 전자상거래에서의 전자 지불 시스템 및 방법과 이에 사용되는 기록매체
KR20140039400A (ko) * 2012-09-21 2014-04-02 주식회사 유아이디에스 밴사 서버와의 키교환을 이용한 스마트폰 카드결제 시스템 및 그 방법
KR20140074732A (ko) * 2012-12-10 2014-06-18 주식회사 엘지유플러스 모바일 결제 시스템 및 방법

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002514839A (ja) * 1998-05-05 2002-05-21 シー． チェン，ジェイ 電子商取引用の暗号のシステムおよび方法
JP2009526321A (ja) * 2006-02-08 2009-07-16 イマジニア・ソフトウェア，インコーポレーテッド 変化する識別子を使用して販売時点情報管理端末において取引を実行するためのシステム
KR20100035366A (ko) * 2008-09-26 2010-04-05 고려대학교 산학협력단 전자상거래에서의 전자 지불 시스템 및 방법과 이에 사용되는 기록매체
KR20140039400A (ko) * 2012-09-21 2014-04-02 주식회사 유아이디에스 밴사 서버와의 키교환을 이용한 스마트폰 카드결제 시스템 및 그 방법
KR20140074732A (ko) * 2012-12-10 2014-06-18 주식회사 엘지유플러스 모바일 결제 시스템 및 방법

Non-Patent Citations (1)

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

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020097257A1 (fr) * 2018-11-08 2020-05-14 Paypal, Inc. Gestionnaire de stockage de carte pour le suivi de stockage de données de carte sur l'ensemble des plateformes de fournisseurs de services
US11176539B2 (en) 2018-11-08 2021-11-16 Paypal, Inc. Card storage handler for tracking of card data storage across service provider platforms
CN112202561A (zh) * 2020-09-29 2021-01-08 福州东方智慧网络科技有限公司 一种基于分布式终端的自主结算方法
CN113592484A (zh) * 2021-07-16 2021-11-02 支付宝(杭州)信息技术有限公司 一种账户的开立方法、系统及装置

Similar Documents

Publication Publication Date Title
KR102621116B1 (ko) Id 기반 공개 키 암호화를 이용한 전자 지불 방법 및 전자 디바이스
US10666428B2 (en) Efficient methods for protecting identity in authenticated transmissions
CN108292330B (zh) 安全令牌分发
US7490069B2 (en) Anonymous payment with a verification possibility by a defined party
CA2914956C (fr) Systeme et procede de chiffrement
US20100153273A1 (en) Systems for performing transactions at a point-of-sale terminal using mutating identifiers
AU2014306440A1 (en) Secure remote payment transaction processing using a secure element
WO2024109551A1 (fr) Procédé et appareil de traitement de paiement numérique, ainsi que dispositif, système et support
CN112074835A (zh) 执行安全操作的技术
WO2017175926A1 (fr) Procédé de paiement électronique et dispositif électronique utilisant une cryptographie à clé publique basée sur l'identité
CN114548986A (zh) 支付方法和支付安全码生成方法、装置、设备与存储介质
JP2023540739A (ja) 分散型台帳上の、匿名性取消を伴う、セキュアな、トレース可能な、および、プライバシー保護の、デジタル通貨送金のための方法
EP3675013A1 (fr) Procédé et dispositif pour des paiements push sécurisés
WO2023085802A1 (fr) Procédé d'authentification did utilisant une carte intelligente et dispositif de carte intelligente
JP4148465B2 (ja) 電子価値流通システムおよび電子価値流通方法
KR101129168B1 (ko) 모바일 안전 결제 방법 및 시스템
CN115310976A (zh) 非接触式交易处理方法、装置及系统
CN115689559A (zh) 数字钱包设备及其双离线交易方法
CN117997560A (zh) 企业身份验证方法及设备
JP3250610B2 (ja) 資金移動先情報取得方法
KR20060019928A (ko) 전자지불 인증방법
Islam et al. A PKI Enabled Authentication Protocol for Secure E-Payment Framework
GB2510793A (en) Method and apparatus for electronic payment authorization

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 2016898030

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2016898030

Country of ref document: EP

Effective date: 20180925

NENP Non-entry into the national phase

Ref country code: DE

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

Ref document number: 16898030

Country of ref document: EP

Kind code of ref document: A1