WO2017175926A1

WO2017175926A1 - Electronic payment method and electronic device using id-based public key cryptography

Info

Publication number: WO2017175926A1
Application number: PCT/KR2016/009224
Authority: WO
Inventors: 차완파라슈람; 알베스 마틴스파울로 세르지오
Original assignee: 삼성전자 주식회사
Priority date: 2016-04-05
Filing date: 2016-08-22
Publication date: 2017-10-12

Abstract

Provided are an electronic payment method and an electronic device which use an ID-based public key cryptography. Provided is an electronic payment method comprising the steps of: receiving, from a key management service server for storing personal information of a user, the user's private key generated according to an identity-based public key cryptography (IDPKC) protocol; encrypting payment information by using a public key of a payment device generated according to the IDPKC protocol and encrypting order information by using a public key of a seller device generated according to the IDPKC protocol; generating a double signature of the payment information encrypted and the order information encrypted by using the private key according to the IDPKC protocol; transmitting a transaction request including the payment information and the order information that was doubly signed to the seller device; and receiving, from the seller device, an answer to the transaction request.

Description

Electronic payment method and electronic device using ID-based public key encryption

An electronic payment method, an electronic device and computer program instructions used in an electronic payment system. In particular, the present invention relates to an electronic payment method and an electronic device using ID-based public key cryptography (IDPKC) in an electronic payment system.

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.

Various protocols have been developed for card-based electronic payment systems. For example, in early payment systems that used Secure Sockets Layer (SSL) or Transport Layer Security (TLS) security, merchants kept certificates and their corresponding public / private key pairs. The cardholder used the certificate to verify the merchant and establish a secure channel through which the card information can be transmitted. Only the cardholder and the merchant could use the card number. However, since merchants have direct access to payment card details, the cardholder had to trust that the merchant would not steal the card number, after which a number of so-called cyber attacks involving the credit card details stored by the merchant were stolen. Concerns about these payment systems were raised as the incident occurred.

Under the Secure Electronic Transaction (SET) protocol, cardholders send encrypted bank account details to merchants using certificates, unencrypted order details, and gateway public keys. In SET, OI (Order Information) means order details and PI (Payment Information) means card holder's bank account details. The merchant then requests payment authorization by forwarding the cardholder's encrypted PI and encrypted OI to the gateway. In the SET protocol, "dual signature" is used to link two messages for the other two recipients, an OI for the merchant and a PI for the gateway. Under the SET system, 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, however, is that a public-key infrastructure (PKI) is required to handle the cardholder's certificate, which must be signed by a Certificate Authority (CA). As a result, there is a problem of increased cost on the merchant side and a complicated authentication process when compared to the initial payment system.

Receiving a user's private key generated according to an identity-based public key cryptography (IDPKC) protocol from a key management service (KMS) server that stores the user's personal information step; 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.

1 is a flow diagram of an electronic payment system, according to one embodiment.

2 is a diagram of an electronic payment system, according to one embodiment.

3 is a flow diagram of a method for transmitting a series of messages during a key provisioning process, according to one embodiment.

4 is a flowchart of a method performed by a cardholder device during the key provisioning process of FIG. 3, according to one embodiment.

5 is a flowchart of a method performed by a key management service (KMS) during the key provisioning process of FIG. 3, according to an embodiment.

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.

7 is a flowchart of a method performed by a cardholder during the transaction process of FIG. 6, according to one embodiment.

8 is a flowchart of a method performed by a merchant during the transaction process of FIG. 6, according to one embodiment.

9 is a flowchart of a method performed by a payment gateway during the approval process of FIG. 6, according to one embodiment.

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. 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.

In addition, a second aspect of the present disclosure, 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.

DETAILED DESCRIPTION Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. In the drawings, parts irrelevant to the description are omitted in order to clearly describe the present invention, and duplicate descriptions are omitted by attaching similar reference numerals to similar parts throughout the specification.

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. In the first step, 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. At that stage, the funds are "held" and deducted from the cardholder's account, but are not transferred to the merchant. In the second stage, known as the "payment" stage, 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.

In this specification, the merchant device may include a merchant server, and the payment device may include a payment server.

In the method of performing a secure transaction in an electronic payment system, in step 101, 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. In step 102, 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. In step 103, the cardholder device generates a dual signature of encrypted payment information and encrypted order information using the private key, according to the IDPKC protocol. In step 104, the cardholder device sends a transaction request to the merchant device that includes the dual signed payment information and the order information. In step 105, the cardholder device receives a response to the transaction request from the merchant device.

2 is a diagram illustrating an electronic payment system according to an embodiment. 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. 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. In one embodiment, 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.

Memory

201a, 202a, 203a, 221a, 222a, and may further include suitable processing means 201b, 202b, 203b, 221b, 222b for executing stored computer program instructions. 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. According to the identity-based public key cryptography (IDPKC) protocol, 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. In one embodiment, the certificate of issuer KMS 221 is securely provisioned to cardholder device 201, and 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.

In one embodiment, 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. When transmitting a KMS certificate over a network, a transport key obtained through a bootstrapping process may be used.

In existing SET-based systems, 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. On the other hand, in embodiments of the present disclosure, by utilizing IDPKC, entities do not share a certificate signed by a CA during electronic transactions, and thus do not use a PKI. For example, when 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. If the merchant device 202 and the payment gateway 203 have been provisioned by the takeover KMS 222, 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.

According to one embodiment, Sakai-Kasahara Key Encryption (SAKKE) and Elliptic Curve-based Certificateless Signatures for Identity-based Encryption (ECCSI) may be used. SAKKE and ECCSI are described as an example and other embodiments may use other IDPKC protocols than SAKKE and ECCSI.

According to one embodiment, 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. In addition, in one embodiment, 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. For example, all merchant identifiers may be prefixed with "merchant" and all gateway identifiers may be prefixed with "gateway". By clearly distinguishing the identifiers of the merchants and gateways in the above manner, it is possible to prevent the cardholder from transmitting an account information to the merchant.

In one embodiment, the cardholder device 201 may be assigned a unique identifier that is encrypted and linked to the cardholder device 201. For example, 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. . 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. . In another embodiment, 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. In order to establish a secure communication channel, 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.

In one embodiment, 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.

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, and FIG. 5 is performed by an issuer KMS during a key provisioning process. A flowchart of the method. 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. In step 401, 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. In one embodiment, the registration request may include a time stamp and a card identifier that can uniquely identify the payment card to be registered. In one embodiment, 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. In step 401, the generated registration request is signed with the public / private key pair that the cardholder device 201 is holding. In one embodiment, the public / private key pair may be stored in the TEE.

In step 402, 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. For example, the first symmetric key can be sealed using ElGamal encryption. In one embodiment, 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. In one embodiment, 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.

In step 403, an encrypted REG_FORM_REQ message and an encrypted first symmetric key are sent to the issuer KMS 221.

In one embodiment, the data to be shared, such as the REG_FORM_REQ message, 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). In another embodiment, the REG_FORM_REQ message may be directly encrypted with asymmetric encryption, in which case step 402 shown in FIG. 4 is omitted.

In step 404, the cardholder device 201 receives a request for additional registration information (REG_FORM_RES). In one embodiment, 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.

In step 406, the cardholder device 201 fills in the requested information in the registration form. In one embodiment, 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. In one embodiment, 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.

In step 407, 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. In one embodiment, the IDPKC protocol may be SAKKE. In addition, in one embodiment the registration form, random number, and second symmetric key may be signed using the private key of the cardholder device 201.

By using a second symmetric key for encrypting the KEY_PROV_REQ message, even if the first symmetric key is stolen, important account information can be kept secret and security can be enhanced. In another embodiment, 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.

In 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. After the request has been processed by the issuer KMS 221, in step 409 the cardholder device 201 receives a key provisioning (KEY_PROV) message containing the required security information.

In one embodiment, issuer KMS 221 encrypts the KEY_PROV message using the public key of the public / private key pair held in cardholder device 201. In one embodiment, the public / private key pair may be stored in the TEE and signed by the issuer KMS 221. When the signature verification of the KMS is completed, the cardholder device 201 decrypts the KEY_PROV message and stores the security information, thereby completing the card registration process. In one embodiment, the security information is securely stored in the cardholder device 201. For example, 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. In one embodiment, 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.

In some embodiments, 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.

Hereinafter, a description will be given of how the issuer KMS 221 shown in FIG. 5 processes the received registration request.

In step 501, issuer KMS 221 receives a REG_FORM_REQ message from cardholder device 201. In one embodiment, 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. In 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. In 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.

In step 505, 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.

In step 507, the issuer KMS 221 receives a KEY_PROV_REQ message that includes the completed registration form. In one embodiment, 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. In step 508, issuer KMS 221 generates the required security information including the private key corresponding to the cardholder's identifier.

In step 508, 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. For example, the card identifier may be a 16 digit card number. The issuer KMS 221 generates a signature for the generated output. In one embodiment, the security information includes security information including an individual key, a new random number, a certificate storage location of a signed and trusted KMS. In one embodiment, the security information is signed and encrypted using a second symmetric key. In step 509, the security information including the private key, i.e. the resulting message KEY_PROV, is sent to the cardholder device 201.

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. In one embodiment, REG_FORM_REQ, REG_FORM_RES, KEY_PROV_REQ, and KEY_PROV messages are sent via an online banking application. In other embodiments, other secure communication methods may be used during the key provisioning process.

In one embodiment, 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. In other embodiments, the form may be agreed in advance in the same manner as defined by industry standards. In this case, 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. For example, 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. For the merchant device 202, 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. In contrast to the cardholder device 201, where only the personal signature key was required, the merchant device 202 is also provisioned with the personal decryption key as well as the personal signature key. In one embodiment, when 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. As shown in FIG. 6, 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. In one embodiment, the transaction process can be in two stages, approval and settlement, similar to the SET system. In other embodiments, the payment step may be omitted and payment may be automatically transferred during the approval step.

When the cardholder selects the goods or services to purchase at the agreed price, the transaction begins. In step 701, 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. In one embodiment, 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.

In step 702, the cardholder device 201 receives a response INIT_RES from the merchant device 202. In one embodiment, 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.

In one embodiment, the merchant and gateway identifiers have different formats. For example, merchant identifiers may be prefixed with "merchant" and gateway identifiers may be prefixed with "gateway". In step 703, 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.

In one embodiment, 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. For example, if the cardholder previously purchased goods or services from the merchant, the cardholder will already have the public identifiers of the merchant and gateway. If the cardholder has public identifiers of the merchant and gateway, the cardholder may skip the initiation step and immediately begin generating and encrypting the PI and OI of step 705.

In 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.

In step 705, 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). Thus, the PI can only read by the payment gateway 203 and the OI can only read by the merchant device 202. In one embodiment, 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. In one embodiment, 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.

In step 706, 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. Through the IDPKC protocol, the merchant device 202 and the payment gateway 203 can verify the signature using the cardholder's public identifier. In one embodiment, 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.

In 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. .

In step 708, the cardholder device 201 sends a PURCH_REQ message to the merchant device 202. In one embodiment, 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. In one embodiment, 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.

As shown in FIG. 6, 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.

8 is a flowchart of a method performed by an affiliate device 202 during an approval process, according to one embodiment. At 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.

At step 803, merchant device 202 uses the received OI to determine a payment amount to be approved. In one embodiment, 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.

At step 804, 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. In one embodiment, the same computationally efficient two layer encryption scheme as described in

steps

402, 407 and 707 is used. In particular, 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. In one embodiment, a SAKKE encryption scheme may be used, and in other embodiments, another IDPKC protocol scheme may be selected.

At step 805, merchant device 202 signs encrypted transaction information using IDPKC. In one embodiment, ECCSI signatures may be used, and in other embodiments, other signature schemes may be selected. In step 806, 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. In embodiments in which a two-layer encryption scheme is used, an encrypted fourth symmetric key may be included in the grant request AUTH_REQ.

After the authorization request is sent, in step 807 an authorization response (AUTH_RES) is received. The authorization response AUTH_RES tells whether the payment has been approved by the issuer 211. In one embodiment, 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. In one embodiment, 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.

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. At step 809, the merchant device 202 determines whether to complete the transaction based on the approval.

In another embodiment, merchant device 202 may send a transaction response message (PURCH_RES) prior to the approval process. In this case, the cardholder device 201 may then send a query message for the approval result to the merchant device 202.

9 is a flowchart of a method performed by a payment gateway during an approval process, according to an embodiment. In step 901, the payment gateway receives the grant request. In step 902, payment gateway 203 decrypts the PI and transaction information using IDPKC. In one embodiment, 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. To decrypt the PI, 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.

In step 903, 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. For example, the payment gateway 203 may use IDPKC encryption and signatures when communicating with the issuer 211, or may use other types of encrypted protocols.

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. In embodiments where the payment and authorization process are independent, the AUTH_RES message may further include a payment token. In one embodiment, 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. At step 905, an encrypted AUTH_RES message containing the enclosed symmetric key is sent to the merchant device 202.

10 is a block diagram illustrating a configuration of an electronic device according to an embodiment. 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. In addition, 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. However, the configuration of the electronic device 1000 is not limited thereto.

In some embodiments, if the authorization and payment process is performed independently, a two step process is applied. In one embodiment, 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. In one embodiment, 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. In one embodiment, 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. In one embodiment, 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.

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. In one embodiment, 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. In one embodiment, 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.

Although one embodiment describes a single payment request, in another embodiment multiple transactions may be included in a single payment request message. Also, in another embodiment, if the system is set to send payment during the approval process, a separate payment process may be omitted. For example, in another embodiment, 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.

In the above various embodiments, a method of encrypting and / or signing data using IDPKC during online transactions has been described. Certain encryption and / or signing steps described above may be omitted, depending on the security requirements of the particular system. Further, in other embodiments, the IDPKC based secure transaction procedures described above may be applied to offline transactions. For example, the IDPKC-based secure transaction described in the case where merchants perform basic checks, such as checking the cardholder's signature to prevent the use of counterfeit credit cards, and subsequently submit data for authorization and payment requests. Procedures may apply. In addition, 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, the method 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. In addition, 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. According to the IDPKC protocol, 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.

When the merchant device 202 encrypts the payment information with the payment gateway's public key, 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. In addition, in accordance with IDPKC, 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). According to the IDPKC, 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. In addition, 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. In addition, 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.

Some embodiments may also be embodied in the form of a recording medium containing instructions executable by a computer, such as program modules executed by the computer. 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. In addition, 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.

The foregoing description of the present invention is intended for illustration, and it will be understood by those skilled in the art that the present invention may be easily modified in other specific forms without changing the technical spirit or essential features of the present invention. will be. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope of the present invention is shown by the following claims rather than the above description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present invention. do.

Claims

Receive the user's private key generated according to an identity-based public key cryptography (IDPKC) protocol from a key management service (KMS) server that stores the user's personal information Doing;

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 the encrypted payment information and the encrypted order information using the private key according to an IDPKC protocol;

Sending a transaction request to the merchant device comprising the double signed payment information and order information; And

Receiving an answer to the transaction request from the merchant device.
The method of claim 1,

Receiving the private key,

Receiving a KMS server certificate from the KMS server;

Authenticating the KMS server using the certificate; And

Receiving the private key from the authenticated KMS server;

Including;

And the certificate includes a master public key of the KMS server, a unique resource identifier (URI) of the KMS server, and a validity period of the master public key.
The method of claim 1,

Receiving the private key,

Generating a registration request including an identifier of the card;

Encrypting the registration request using a first symmetric key and encrypting the first symmetric key using a public key of the KMS server according to IDPKC;

Sending the encrypted registration request and the encrypted first symmetric key to the KMS server; And

Receiving the private key;

Electronic payment method comprising a.
The method of claim 3, wherein

Encrypting the first symmetric key using the public key of the KMS server according to IDPKC,

Receiving and storing in the memory one or more KMS server public keys corresponding to the one or more KMS servers;

Receiving an identifier of a KMS server used by the merchant device;

Retrieving from the memory the KMS server public key corresponding to the identifier of the KMS server; And

Encrypting the first symmetric key using the retrieved KMS server public key according to IDPKC;

Electronic payment method comprising a.
The method of claim 3, wherein

Sending the encrypted registration request to the KMS server,

In response to the transmitted registration request, receiving an additional registration information request signed by the KMS server from the KMS server;

Checking a signature of the KMS server to determine whether the additional registration information request is authenticated;

In response to determining that the additional registration information request has been authenticated, encrypting the additional registration information using a second symmetric key and encrypting the second symmetric key using a public key of the KMS server according to IDPKC; And

Transmitting the encrypted additional registration information and the encrypted second symmetric key to the KMS server;

Electronic payment method comprising more.
The method of claim 5,

The transmitting of the encrypted registration request or the encrypted additional registration information to the KMS server may include:

Generating a first random number; And

Transmitting the registration request or the additional registration information including the generated first random number to the KMS server,

Wherein the first random number is used to link the identifier of the card to an account identifier that has accumulated funds accessible through the card.
The method of claim 1,

Receiving the private key,

A server signature that encrypts and links the user's public identifier with an account identifier of an account associated with the user's card,

A first random number, a second random number concatenated with the user's public identifier and the account identifier, and

Further includes at least one of the storage locations of one or more trusted server certificates,

Wherein the first random number is used to link the identifier of the card to an account identifier that has accumulated funds accessible through the card, and wherein the second random number is generated from the KMS server.
The method of claim 1,

And wherein the private key is encrypted and linked with the user's public identifier and then used to generate the double signature of the encrypted payment information and the encrypted order information in accordance with IDPKC.
The method of claim 1,

Generating the double signature,

Generating the payment information and the order information;

Obtaining a public key of the payment device and a public key of the merchant device from each of the public identifier of the payment device and the public identifier of the merchant device;

Encrypting the payment information using the public key of the payment device according to IDPKC, and encrypting the order information using the public key of the merchant device according to IDPKC; And

Generating a double signature of the encrypted payment information and the encrypted order information using the private key according to IDPKC;

Electronic payment method comprising a.
The method of claim 9,

Encrypting the payment information with the public key of the payment device according to IDPKC,

Encrypting the payment information and the account identifier using a third symmetric key, encrypting the third symmetric key using a public key of the payment device according to IDPKC,

And the encrypted third symmetric key is included in the transaction request.
The method of claim 9,

Acquiring the public key,

Sending an initiation request to initiate a secure transaction;

Receiving a public identifier of the payment device and a public identifier of the merchant device;

Determining that the format of the received public identifiers matches the expected format for a payment device identifier and a merchant device identifier; And

Obtaining a public key of the payment device and the public key of the merchant device corresponding to a format of the received public identifiers determined to match the predicted format;

Electronic payment method comprising a.
The method of claim 1,

Receiving a response to the transaction request,

Displaying the received answer;

Electronic payment method comprising more.
A memory in which at least one program is stored; And

A processor for executing a secure transaction in an electronic payment system by executing at least one program stored in the memory;

The at least one program,

Receiving a private key of a cardholder generated according to the IDPKC protocol from a KMS server storing personal information of the user;

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 the encrypted payment information and the encrypted order information using the private key according to an IDPKC protocol;

Sending a transaction request to the merchant device comprising the double signed payment information and order information; And

Receiving an answer to the transaction request from the merchant device;

And instructions for executing the.
The method of claim 13,

The at least one program,

Receiving a KMS server certificate from the KMS server;

Authenticating the KMS server using the certificate; And

Receiving the private key from the authenticated KMS server;

Further includes instructions for executing,

And the KMS server certificate comprises a master public key of the KMS server, a URI of the KMS server and a validity period of the master public key.
The method of claim 13,

The at least one program,

Generating a registration request including an identifier of the card;

Encrypting the registration request using a first symmetric key and encrypting the first symmetric key using a public key of the KMS server according to IDPKC;

Sending the encrypted registration request and the encrypted first symmetric key to the KMS server; And

Receiving the private key;

And instructions for executing the.
The method of claim 15,

The at least one program,

Encrypting the first symmetric key using the public key of the KMS server according to IDPKC,

Receiving and storing in the memory one or more KMS server public keys corresponding to the one or more KMS servers;

Receiving an identifier of a KMS server used by the merchant device;

Retrieving from the memory the KMS server public key corresponding to the identifier of the KMS server; And

Encrypting the first symmetric key using the retrieved KMS server public key according to IDPKC;

And instructions for executing the.
The method of claim 15,

The at least one program,

In response to the transmitted registration request, receiving an additional registration information request signed by the KMS server from the KMS server;

Checking a signature of the KMS server to determine whether the additional registration information request is authenticated;

In response to determining that the additional registration information request has been authenticated, encrypting the additional registration information using a second symmetric key and encrypting the second symmetric key using a public key of the KMS server according to IDPKC; And

Transmitting the encrypted additional registration information and the encrypted second symmetric key to the KMS server;

And instructions for executing the.
The method of claim 13,

And wherein the private key is encrypted and linked with the user's public identifier and then used to generate the double signature of the encrypted payment information and the encrypted order information in accordance with IDPKC.
The method of claim 13,

And a display for displaying the received answer.
A computer-readable recording medium having recorded thereon a program for executing the method of any one of claims 1 to 12.