KR20130139677A - Data communication method in electronic payment system - Google Patents

Abstract

A data communication method is disclosed. The method according to the present invention comprises the following steps: securing a channel for communicating with a terminal; generating a given signal to block an automated attack if the same data is repeatedly received from the terminal over given times; transmitting the signal to the terminal and receiving the signal; generating a key pair including a public key and a private key using a public key encryption algorithm if request data is transmitted from the terminal within a timeout period; storing the private key in a session; transmitting, to the terminal, the public key which is valid only in a relevant session; receiving the data which is encrypted using the public key; and decoding the data using the private key. [Reference numerals] (11) Control unit;(12) Communication unit;(13) Session storing unit;(14) Profile storing unit

Description

Data communication method in electronic payment system {DATA COMMUNICATION METHOD IN ELECTRONIC PAYMENT SYSTEM}

The present invention relates to data communication, and more particularly, to a data communication method for secure payment in an electronic commerce system.

Due to the proliferation of e-commerce sites, electronic payments using credit cards are increasing. Recently, mobile payments are also increasing due to the spread of smart phones.

Currently, as an electronic payment for a credit card, an authentication method using a password of a credit card (password authentication method), a credit card safe payment (ISP) method, a safe click method, and the like are used.

The password authentication method is a method of inputting a credit card number, a credit card password, and a resident registration number of a credit card holder at the time of electronic payment.

The ISP method is a method of operating based on Active-X or Flash, which has a disadvantage in that the platform is limited.

In addition, the assured click method is an active X-based method, and has a disadvantage that is not suitable for mobile payment due to the pop-up structure.

The conventional electronic payment method as described above was mainly a method of plugging in an Active X to a user terminal and proceeding electronic payment through this. However, such an ActiveX plug-in method has a problem causing inconvenience to the user, and there is a problem that cannot be used in a specific platform such as mobile payment.

Accordingly, a new electronic payment method in which the ActiveX is not driven is implemented in various ways. In this case, since the ActiveX is not driven, it is required to perform secure data communication.

The technical problem to be solved by the present invention is to provide a secure data communication method in an electronic payment system that can be implemented in a plurality of platforms without requiring any plug-in.

In order to solve the technical problem as described above, in order for a user to make a purchase through a terminal at a site provided by the first server, a data communication method of the present invention, in which a second server communicates with the terminal, communicates with the terminal. Securing a channel; When the same data is repeatedly received more than a predetermined number of times from the terminal, generating a predetermined signal for blocking the automated attack, transmitting the predetermined signal to the terminal, and receiving the same; Generating a key pair including a public key and a private key using a public key cryptographic algorithm when request data is transmitted from the terminal within a predetermined timeout time; Storing the private key in a session and transmitting the public key valid only within the session to the terminal; Receiving the data encrypted with the public key and decrypting the data with the private key; And generating a hash data when there is a termination request for the corresponding session from the terminal.

In one embodiment of the present invention, the predetermined signal for blocking the automated attack is preferably a pictogram.

In one embodiment of the invention, the predetermined signal for blocking the automated attack is preferably an audio signal.

In one embodiment of the present invention, it is preferable that the terminal provides a virtual keyboard for the user to input and masks and displays the information input by the user.

In an embodiment of the present invention, the method may further include repeatedly performing the decrypting with the private key.

In one embodiment of the present invention, it is preferable to further include the step of transmitting the generated hash data to the terminal.

In one embodiment of the present invention, the first server receives the hash data transmitted to the terminal, and compares the generated hash data and the hash data received from the terminal, to determine whether the data forgery / forgery It is preferred to further comprise a step.

In one embodiment of the present invention, it is preferable that the first server further comprises transmitting to the terminal whether the data is forged or forged.

The present invention as described above, the present invention as described above, in the electronic payment system that does not require Active X, there is an effect to provide a secure data communication.

1 is a block diagram of an electronic payment system to which the present invention is applied.
2 is a detailed configuration diagram of an embodiment of the payment server of FIG.
3 is a flowchart illustrating an operation of a payment server of FIG. 2.
4 is a flowchart illustrating an embodiment of a data communication method according to the present invention.

While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the invention is not intended to be limited to the particular embodiments, but includes all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

Terms including ordinals such as first, second, etc. may be used to describe various elements, but the elements are not limited by such terms. These terms are used only to distinguish one component from another.

When a component is said to be 'connected' or 'connected' to another component, it may be directly connected to or connected to that other component, but other components may be present in between. It should be understood that. On the other hand, when an element is referred to as being "directly connected" or "directly connected" to another element, it should be understood that there are no other elements in between.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of the present invention. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this application, the terms "comprises", "having", and the like are used to specify that a feature, a number, a step, an operation, an element, a component, or a combination thereof, But do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or combinations thereof.

Hereinafter, a preferred embodiment of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram of an electronic payment system to which the present invention is applied.

As shown in the figure, the system according to the present invention, the payment server 1, credit card company approval server (2), e-commerce server (3), the user terminal 4 used by the user and the mobile terminal possessed by the user (5) is included.

The user connects to the site provided by the e-commerce server 3 via the network using the user terminal 4. In FIG. 1, the user terminal 4 illustrates a personal computer (PC) for convenience of description, but includes a smart phone, a smart pad, a smart TV, a car navigation system, and the like. Obviously, various terminals may be used. The electronic payment method according to the present invention is applicable to such various platforms.

The user terminal 4 is connected to a payment server 1, a credit card company approval server 2 and an e-commerce server 3 via a wired or wireless network, respectively. In FIG. 1, an example of wireless connection is described, but the present invention is not limited thereto. In addition, components other than those shown in FIG. 1 may be included for connection of a wired or wireless network.

The mobile terminal 5 of the user is, for example, a smartphone, but is not limited thereto, and various types of terminals capable of receiving an authentication code from the payment server 1 may be used. In addition, although the user terminal 4 and the mobile terminal 5 is shown as a separate terminal, it is obvious that the same may be performed in the same terminal.

The user can access a site provided by the e-commerce server 3 using the user terminal 4 to purchase a predetermined item or service. The manner in which the e-commerce server 3 provides the goods or services through a predetermined site will be obvious to those of ordinary skill in the art, and thus the detailed description thereof will be omitted. .

If a user purchases goods or services at a site provided by the e-commerce server 3 through the user terminal 4 and wants to make electronic payment at the site, the payment server 1 is linked with the credit card company server 2. To start the electronic payment according to the present invention.

In this case, the credit card company server 2 generally transmits the approval completion message to the user's mobile terminal 5 when the user's credit card is approved. The approval completion message includes a user name, an approved amount, an approved date and time, and merchant information. The user may complete the application for receiving the approval completion message in advance to the credit card company server 2, and when the credit card is approved, the user may receive the approval completion message for the corresponding approval through the mobile terminal 5. .

However, this is just an example, and the method of confirming the authorization amount of the credit card company server 2 used in the present invention, in addition to the text message method, various methods may be used. That is, for example, the user may directly access the page provided by the credit card company server 2 to confirm the authorization amount, or may call the credit card company's call center to confirm the authorization amount. The credit card company server 2 may check the authorization amount sent directly to the user's e-mail account, or if the credit card company server 2 provides a dedicated program for authorization inquiry, the authorization amount may be confirmed through this. Alternatively, after undergoing a certain authentication process between the credit card company server 2 and the user, it may be confirmed in a manner that guides the approval details, such as the authorization amount.

Hereinafter, the detailed configuration of the payment server 1 of the present invention will be described with reference to the drawings.

2 is a detailed configuration diagram of an embodiment of the payment server of FIG.

As shown in the figure, the payment server 1 of the present invention includes a control unit 11, a communication unit 12, a session storage unit 13 and a profile storage unit 14.

The communication unit 12 transmits and receives data with the electronic commerce server 3, the credit card company server 2, the user terminal 4 and the mobile terminal (5). The data transmitted and received by the communication unit 12 will be described later in detail.

When the user completes the purchase of goods or services at a site provided by the e-commerce server 3 and requests a payment, the controller 11 receives a payment request from the e-commerce server 3 through the communication unit 12. Receive. At this time, the e-commerce server 3 simultaneously transmits the user information including the user's mobile terminal 5 information and the payment information including the price of the goods or services.

The controller 11 arbitrarily generates an amount smaller than the price of the goods or services (hereinafter referred to as the 'original transaction amount') (hereinafter referred to as the 'authentication amount') and provides it to the credit card company server 2. This authentication amount is used as an authentication code for user authentication. The control unit 11 provides this authentication amount to the credit card company server 2 through the communication unit 12. The credit card company server 2 transmits the approval completion message including the authentication amount to the mobile terminal 5 of the user.

The control unit 11 requests the user terminal 4 to input the authentication amount as an authentication code through the communication unit 12, and when the authentication amount input by the user and the original transaction amount generated by the control unit 11 itself match. Next, the credit card company server 2 requests the credit card company server 2 to cancel the authorization of the corresponding authentication amount, and the credit card company server 2 requests the credit card company server 2 to approve the transaction.

The credit card company server 2 receiving the request for canceling the authorization may cancel the authorization for the authentication amount and perform the authorization for the original transaction amount. However, since the cancellation of the approval of the authentication amount and the time of approval of the original transaction amount is not determined, the approval cancellation of the authentication amount may be performed first, and then the approval of the original transaction amount may be performed. After the approval of the transaction amount is performed, the approval of the authentication amount may be performed.

On the other hand, the control unit 11 does not have a mobile terminal 5, or the service request for receiving the approval completion message provided by the credit card company server 2 is not completed, the session storage unit (13), so that the user can check it offline.

For example, when the user transmits a signal that the user wants to pay later on the page for payment, the control unit 11 stores the session in the session storage unit 13 and stores a link to the session. You can send it by e-mail.

Subsequently, when the user possesses the mobile terminal 5, or completes an application for receiving the approval completion message, and confirms the authentication amount, or when the user confirms the authentication amount in various manners described above, the control unit 11 Payment can be carried out through the provided session link.

However, the controller 11 may set a time-out for the session, and the user preferably completes the amount authentication within the corresponding time-out.

In addition, when the user authentication is first performed for the corresponding user using the authentication amount, the control unit 11 generates profile information on the payment information and stores it in the profile storage unit 14. The profile information includes user information input from the user at the time of initial authentication from the e-commerce server 3, which is not provided to the e-commerce server 3, and preferably stored by the payment server 1.

Through this, even when a user accesses a site provided by any e-commerce server and purchases an item or a service, the user may complete the payment process without an additional authentication process by the profile information stored in the payment server 1. .

For this purpose, it is preferable that the user first connects to the payment server 1 and registers user information for use of the electronic payment of the present invention.

Hereinafter, the operation of the control unit 11 will be described with reference to the drawings.

FIG. 3 is a flowchart illustrating an operation of the payment server of FIG. 2, and illustrates the operation of the control unit 11 of the payment server 1.

As shown in the figure, the control unit 11 of the payment server 1 of the present invention, when the communication unit 12 receives the payment request data from the e-commerce server 3 (S31), it is included in the payment request data Check the user information and payment information (S32). The user information includes mobile terminal 5 information of a user who purchases goods or services at a site provided by the e-commerce server 3. The settlement information includes the original transaction amount of the goods or services purchased from the site provided by the electronic commerce server 3.

If the profile information for the user is stored in the profile storage unit 14 from the user information, the control unit 11 requests the credit card company server 2 to approve the original transaction amount using the payment information. (S53). In addition, the control unit 11 may notify that the payment is completed in the payment page of the user terminal 4 (S55).

If the profile information for the user is not stored in the profile storage unit 14, an arbitrary amount (authentication amount) (e.g., 239,745 won) is less than the original transaction amount (e.g., 100,000 won). In operation S37, a session including information about the corresponding authentication amount is stored in the session storage unit 13 (S39). This is in case the user does not want to pay at present, the control unit 11 may provide a corresponding session link by the user's e-mail (not shown).

Thereafter, the control unit 11 requests the credit card company server 2 to approve the authentication amount (S41), and the credit card company server 2 completes the approval including the corresponding authentication amount to the user's mobile terminal 5. The message is transmitted (S43). However, as an example, in addition to transmitting the approval completion message to the mobile terminal 5, the authentication amount may be notified to the user in various ways described above.

Thereafter, the control unit 11 transmits a page requesting the user terminal 4 to input the corresponding authentication amount as an authentication code to the user terminal 4 (S45).

The user inputs the authentication amount received by the mobile terminal 5 (or in various ways) into the page transmitted by the control unit 11 (S47), and the control unit 11 inputs the authentication amount input by the user and S41. If the authentication amount provided to the credit card company server (2) is matched (S49), the credit card company server (2) requesting the cancellation of the authorization for the authentication amount (S51), the request for authorization for the original transaction amount again (S53).

Responding to the request for cancellation of authorization for the authentication amount and the request for approval for the original transaction amount, the credit card company server 2 performs the corresponding cancellation and approval. However, as described above, the time after the time is not determined.

Thereafter, the controller 11 of the payment server 1 may notify that the payment is completed in the payment page of the user terminal 4 of the user (S55).

On the other hand, the authentication amount of the present invention is that the control unit 11 generates an arbitrary number less than the original transaction amount. When the original transaction amount decreases, the authentication amount that can be generated also decreases. Inappropriate cases may occur. For example, if the original transaction amount is 3,000 won, the authentication amount is less than that, so 498 won occurs, which is inappropriate as an authentication code.

Therefore, the controller 11 of the present invention may perform authentication twice when the original transaction amount is less than or equal to a predetermined amount. That is, in the case of FIG. 3, the steps S37 to S49 may be repeated a predetermined number of times. For example, it may be performed twice, but the present invention is not limited thereto, and the above may be repeatedly performed for sufficient authentication.

Alternatively, when the original transaction amount is less than or equal to a predetermined amount, the control unit 11 of the present invention may determine the range of the authentication amount in advance (for example, 100,000 won or less), and generate an authentication amount within the range.

In the above, the electronic payment system to which the present invention is applied has been described. The present invention relates to a data communication method between the payment server (1), the electronic commerce server (3) and the user terminal (4) in the electronic payment system as described above.

According to the data communication method of the present invention, it is possible to ensure the same or more stability as the data communication method using the conventional binary plug-in. Since the above description does not mention the communication method related to the present invention, the data communication method of the present invention will be described in detail below.

4 is a flowchart illustrating an embodiment of a data communication method according to the present invention. In the description of the present invention, the terminal used by the user is assumed to be described as the user terminal 4, but the use of the mobile terminal 5 is not excluded.

As shown in the figure, in the communication method of the present invention, the payment server 1 first secures the communication channel using the user terminal 4 and the security protocol (S1). The payment server 1 may, for example, use a security socket layer (SSL) or a transport layer security (TLS), which is one of security protocols, to the payment server 1 and the user terminal 4. In the current user can secure a secure communication channel between the web browser (web browser) in use for e-commerce use. However, the security protocol for securing the communication channel according to the present invention is not limited to SSL or TLS, and does not exclude the use of other security protocols having similar functions.

As such, when the communication channel is secured, the user terminal 4 transmits the payment request data to the payment server 1 as in S31 (S2). However, when establishing a communication channel using SSL or TLS security protocol alone, there are vulnerabilities that are exposed to various attack methods such as robot attack and IMM attack. Through the same flow it is possible to securely communicate data between the user terminal 4 and the payment server (1).

That is, when the payment server 1 receives the requested information from the user terminal 4, the payment server 1 checks whether the transmission of the payment request data (S2) is transmitted within a preset timeout time (S3), and after the corresponding timeout time. If it is transmitted to, the data communication procedure of the present invention is terminated.

If the payment request data is transmitted within the timeout period, if the same data is repeatedly attempted more than once (S4), in order to block the automated attack, a pictogram is generated (S5). By transmitting to the user terminal 4 (S6), the user can check the corresponding pictogram (S7). This is to block the automated attack by the robot by directly inputting the information generated by the specific picture. However, in one embodiment of the present invention, for example, the case of generating a pictogram to block the automated attack, but does not exclude the generation of the audio signal.

Therefore, as long as the glyph input by the user coincides with the glyph generated in S5 (S8), the subsequent steps may be set.

Even in this case, although not shown, when the same pictogram is repeatedly attempted two or more times from the user, transmission of the pictogram repeatedly attempted to block the automated attack may be blocked.

Thereafter, the payment server 4 receiving the payment request data generates a key pair including a private key and a public key using a public key cryptography algorithm (S9). . The public key cryptographic algorithm used by the payment server 1 may be, for example, a Rivest Shamir Adleman (RSA) algorithm or an Elliptic Curve Cryptosystem (ECC), but is not limited thereto.

The payment server 1 stores the generated private key in the corresponding session (S10), and transmits the public key to the user terminal 4 (S11).

S1 to S11 mentioned above are referred to as an initialization step in the present invention. That is, the steps of initializing the user terminal 4 to perform data communication with the payment server 1 will be described.

In the data communication of the present invention, the user terminal 4 can apply a virtual keyboard so that information input by the user is not leaked by malware such as a key logger, and the information displayed on the screen is The user terminal 4 may be masked and displayed to prevent leakage by others watching (S12).

The user terminal 4 receives a public key valid only within the session from the payment server 1, and then encrypts and transmits the data to be transmitted with the public key (S13). The payment server 1, which has received the encrypted data, receives the data by demodulating it with the private key stored in the session (S14).

The encryption transmission (S13) and the decryption (S14) process using the data public key may be repeatedly performed until the reception of data is completed (S15).

In the data communication of the present invention, S12 to S15 are called data transmission steps.

When the user terminal 4 requests the end of the session (S16), the payment server 17 generates hash data based on the processing history (S17). In general, hashing means converting a string to a short-length value or key that directly accesses the address so that it can be found more quickly.

When the hash data is transmitted to the e-commerce server 3 through the user terminal 4 (S18) (S19), the e-commerce server 3 directly generates the hash data and the payment. By comparing the hash data transmitted from the server 1 (S20), it is possible to check whether the data is forged or forged.

The e-commerce server 3 may transmit the forgery / modulation result of such data to the user terminal 4 to safely complete the data communication.

The present invention can be used on all platforms without requiring any plug-in for electronic payment, it is possible to provide a simple electronic payment.

While the invention has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention as defined by the appended claims. Accordingly, the true scope of the present invention should be determined by the following claims.

1: payment server 2: credit card company approval server
3: e-commerce server 4: user terminal
5: mobile terminal 11: control unit
12: communication unit 13: session storage unit
14: profile storage

Claims (8)

In a data communication method in which a second server communicates with the terminal in order for a user to make a purchase through a terminal at a site provided by the first server,
Securing a communication channel with the terminal;
When the same data is repeatedly received more than a predetermined number of times from the terminal, generating a predetermined signal for blocking the automated attack, transmitting the predetermined signal to the terminal, and receiving the same;
Generating a key pair including a public key and a private key using a public key cryptographic algorithm when request data is transmitted from the terminal within a predetermined timeout time;
Storing the private key in a session and transmitting the public key valid only within the session to the terminal;
Receiving the data encrypted with the public key and decrypting the data with the private key; And
And generating a hash data when there is a termination request for the corresponding session from the terminal.
The method of claim 1, wherein the predetermined signal for blocking the automated attack is a pictogram.
The method of claim 1, wherein the predetermined signal for blocking the automated attack is an audio signal.
The method of claim 1, wherein the terminal,
A data communication method for providing a virtual keyboard for a user to input and masking and displaying the information input by the user.
The data communication method of claim 1, further comprising repeatedly performing the decryption with the private key.
The data communication method of claim 1, further comprising transmitting the generated hash data to the terminal.
The method of claim 6, wherein the first server receives the hash data transmitted to the terminal, compares the generated hash data with the hash data received from the terminal, and confirms whether the data is forged or forged. Further comprising a data communication method.
The method of claim 7, wherein the first server further comprises transmitting to the terminal whether data is forged / modulated.

Images