KR101964254B1 - Person to person trading method and apparatus by using blockchain and distributed hash table - Google Patents

Abstract

According to an aspect of the present invention, there is provided a P2P transaction method comprising: receiving first transaction request information from a sender terminal; requesting a transaction to a receiver terminal identified from first transaction request information; Receiving second transaction request information from the receiver terminal, obtaining a first block chain hash value based on the first transaction request information, and obtaining a second block chain hash value based on the second transaction request information And requesting a transaction from a distributed hash table (DHT) system according to the first and second block chain hash values to allow the deposit and withdrawal to be performed according to the first and second transaction request information.

Description

TECHNICAL FIELD [0001] The present invention relates to a P2P transaction method and apparatus using a block chain and a DHT,

The technical idea of the present invention relates to a P2P transaction, and more particularly, to a P2P transaction method and apparatus using a block chain and a DHT.

This study was conducted as a result of the research project of the future ICT Research Center of the Creation Science Department and the Information and Communication Technology Promotion Center (IITP-2016-R27181600030001002).

As the mobile transaction market has recently grown, various technologies related to the trading market have been attracting attention. Among them, the P2P trading market is attracting attention as a transaction between users and users. In addition to existing banknotes, various online trading companies and IT companies also participate. However, users are experiencing discomfort due to the involvement of various companies and their unique trading methods.

In addition, due to the characteristics of mobile environment, new security threats such as existing mobile security threats are occurring. Therefore, various security technologies should be developed for P2P trading environment. In addition, there is a need for a technique for protecting sensitive personal information such as user's account number and financial transaction information used in the context of financial transactions.

The technical problem to be solved by the P2P transaction method and apparatus using the block chain and the DHT according to the technical idea of the present invention is to block the meson attack and the DDoS attack according to the P2P transaction.

Also, a technical problem of a P2P transaction method and apparatus using a block chain and a DHT according to the technical idea of the present invention is to prevent leakage of sensitive personal information.

The technical problem to be solved by the technical idea of the present invention is not limited to the above-mentioned problems, and other matters not mentioned can be clearly understood by those skilled in the art from the following description.

According to an aspect of the present invention, there is provided a P2P transaction method comprising: receiving first transaction request information from a sender terminal; Requesting a transaction to a receiver terminal identified from the first transaction request information; Receiving second transaction request information from the receiver terminal; Obtaining a first block chain hash value based on the first transaction request information and obtaining a second block chain hash value based on the second transaction request information; And requesting a transaction from a distributed hash table (DHT) system according to the first and second block chain hash values to allow the deposit and withdrawal to be performed according to the first and second transaction request information.

According to an exemplary embodiment, the P2P transaction method may further include receiving a sender secret key from the sender terminal before receiving the first transaction request information from the sender terminal, The receiving of the first transaction request information may include decoding the first transaction request information encrypted with the secret key by the sender terminal using the previously received secret key.

According to an exemplary embodiment, the P2P transaction method may further include exchanging the sender terminal, the sender public key and the central server public key before receiving the first transaction request information from the sender terminal Wherein the receiving of the first transaction request information from the sender terminal comprises comparing the public key received together with the first transaction request information to at least one of the received sender public key and the central server public key And authenticating the sender terminal.

According to an exemplary embodiment, the P2P transaction method may further include receiving a receiver's private key from the receiver terminal before receiving second transaction request information from the receiver terminal, The receiving of the second transaction request information may include decoding the second transaction request information encrypted with the secret key by the receiver terminal with the secret key received.

According to an exemplary embodiment, the P2P trading method may further include exchanging the receiver key public key and the central server public key with the receiver terminal before receiving the second transaction request information from the receiver terminal Wherein the step of receiving the second transaction request information from the receiver terminal further comprises the step of comparing the public key received together with the second transaction request information with at least one of the receiver's public key and the central server public key And authenticating the receiver terminal.

According to an exemplary embodiment of the present invention, the P2P transaction method further comprises: calculating the first transaction request information to obtain account information and remittance information of a sender; And acquiring the account information and the collection information of the receiver by calculating the second transaction request information.

According to an exemplary embodiment, the P2P transaction method may include deserializing the first and second transaction request information.

The obtaining of the first and second block chain hash values may be performed by hashing the public key received from the sender terminal and the account information of the sender to obtain the first block chain hash value And obtaining the second block chain hash value by hashing the public key received from the receiver terminal and the account information of the receiver.

According to an exemplary embodiment of the present invention, the step of requesting a transaction to the DHT system according to the first and second block chain hash values may include: And transferring a second block chain transaction to the DHT system that is generated based on the transaction and the second block chain hash value and the collection information.

According to an exemplary embodiment, the P2P transaction method may further include transmitting a transaction completion message to the sender terminal and the receiver terminal when the deposit / withdrawal by the DHT system is completed.

According to an exemplary embodiment, the deposit and withdrawal may be performed by first and second nodes corresponding to the first and second block-chain hash values of a plurality of nodes included in the DHT system.

According to another aspect of the present invention, there is provided a central server comprising: a user interlocking unit for receiving first transaction request information from a sender terminal and receiving second transaction request information from a receiver terminal; A central processing unit for obtaining a first block chain hash value based on the first transaction request information and obtaining a second block chain hash value based on the second transaction request information; And a system interworking unit for requesting a transaction from a distributed hash table (DHT) system according to the first and second block chain hash values and performing a deposit and withdrawal according to the first and second transaction request information.

A P2P trading system according to another aspect of the present invention includes a first block chain hash value and a second block transaction value based on first transaction request information received from a sender terminal and second transaction request information received from a receiver terminal, A central server for obtaining a two-block chain hash value and requesting a deposit and withdrawal transaction based on the first and second block chain hash values; And a distributed hash table (DHT) system for performing deposit and withdrawal based on the first and second transaction request information when a transaction request is received from the central server.

The block chain and the P2P transaction method and apparatus using the DHT according to the embodiments of the present invention can prevent a meson attack, a DDoS attack, and the like due to a P2P transaction.

In addition, the P2P transaction method and apparatus using the block chain and the DHT according to the embodiments of the present invention can prevent the leakage of sensitive personal information.

BRIEF DESCRIPTION OF THE DRAWINGS A brief description of each drawing is provided to more fully understand the drawings recited herein.
1 is an exemplary diagram for explaining the structure of a general block chain.
2 is an exemplary diagram showing an address space according to the Chord algorithm of the distributed hash table.
3 is an exemplary diagram showing the Succesor-List according to the Chord algorithm of the distributed hash table and the replication of data using the Succesor-List.
4 is an exemplary diagram for explaining a general P2P transaction method.
FIG. 5 is a diagram illustrating a P2P trading system according to an embodiment of the present invention.
FIG. 6 is a flowchart illustrating a P2P transaction method according to an embodiment of the present invention.
7 is a diagram for explaining a pre-exchange procedure of a key according to an embodiment of the present invention.
FIG. 8 is a view for explaining a P2P transaction method according to an embodiment of the present invention.
9 is a block diagram schematically showing a configuration of a central server according to an embodiment of the present invention.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. However, it should be understood that the technical idea of the present invention is not limited to the specific embodiments but includes all changes, equivalents, and alternatives included in the technical idea of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0027] In the following description of the present invention, a detailed description of known technologies will be omitted when it is determined that the technical idea of the present invention may be unnecessarily obscured. In addition, numerals (e.g., first, second, etc.) used in the description of the present invention are merely an identifier for distinguishing one component from another.

Also, in this specification, when an element is referred to as being " connected " or " connected " with another element, the element may be directly connected or directly connected to the other element, It should be understood that, unless an opposite description is present, it may be connected or connected via another element in the middle.

The terms "to", "to", "to", "to", and "module" in the present specification mean units for processing at least one function or operation, A micro processor, a central processing unit (CPU), a graphics processing unit (GPU), an Accelerate Processor Unit (APU), a digital signal processor (DSP), an application specific integrated circuit (ASIC) (Field Programmable Gate Array), or the like, or a combination of hardware and software.

It is to be clarified that the division of constituent parts in this specification is merely a division by each main function of each constituent part. That is, two or more constituent parts to be described below may be combined into one constituent part, or one constituent part may be divided into two or more functions according to functions that are more subdivided. In addition, each of the constituent units described below may additionally perform some or all of the functions of other constituent units in addition to the main functions of the constituent units themselves, and that some of the main functions, And may be carried out in a dedicated manner.

Hereinafter, the related arts will be described, and then the embodiments according to the technical idea of the present invention will be described in detail.

In the case of P2P transactions supported by existing banknotes, banks have different databases. Transactions between users must go through a bank server, a mediation server, or a government agency, and also require communication between bank databases. The risk of exposure to information increases as more sensitive information is required for financial transactions.

The block chain technology, which is attracting attention from the financial sector in recent years, is a technology in which all participants in the network jointly verify, record and store transaction information. In addition, there is an advantage in that it can not be operated unless all the computers are hacked because the transaction book is stored in a distributed manner. In addition, attacks such as DDoS that downsize the server by sending information exceeding the capacity that the server can handle safe.

Distributed hash table (DHT) technology is a technique for placing data and servers in the same address space. It has a good lookup performance for finding a server that manages data without a central server. , As well as extremely large nodes.

In an embodiment of the present invention, a P2P transaction method with high availability and high security is proposed through a block chain and a distributed hash table considering the problems of the existing P2P transaction method.

Block chain

Block Chain technology is a technology developed for Bitcoin, a technique to prevent hacking that may occur when trading with virtual currency. At present, it is used in various forms depending on the usage, but the basic structure is similar.

The block chain can be classified into a public block chain, a private block chain, and a hybrid or consortium block chain.

The public block chain can participate in an unspecified number of users and operates through a public network. There is a disadvantage that the transaction speed is slow because many users participate. Typically, there are virtual coins such as bit coin and etherium.

In the case of a private block chain, in the form of a personalized block chain, unlike a public block chain, a subject is a block chain of a type with full authority, and all users involved in the transaction need permission from the central authority. A typical example is the Nasdaq Chain.

Next, in the case of a consortium block chain, it is a half-center type block chain in which a public block chain and a private block chain are mixed. Only N subjects that have been negotiated or selected in advance participate in the block chain, and proof of the block is achieved through agreed rules between the subjects. Compared to the public block chain, there is an advantage that the network is easy to expand and the transaction speed is fast.

In the block chain technology, transaction record and confirmation mechanism corresponding to forgery and falsification exists due to the characteristics of disclosure and dispersibility, and there are five kinds.

The first is a proof-of-work structure that is often used in public block chains such as bit coins. To create a block, the user solves the hash algorithm to prove it, brokers it to the entire block chain node, and concatenates the block it proves to the last block. The proof-of-work process has to go through one more time in order to forge and modify the block.

Second, it is a system to supplement the shortcomings of proof-of-work with a proof-of-stake structure. In case of proof-of-work structure, if there is a person or group monopolizing more than 50% of the entire network, problems such as increase in commission and deliberate transaction record may occur. In the case of a proof-of-stake structure, the owner proves his or her own assets.

The third is Consensus-by-bet structure. The structure is a structure that approves the transactions of the block chain through the consent of the people participating in the network, and it is a structure that one person or organization can not monopolize the network. At this time, the nodes participating in the approval are obliged to deposit the bond, to participate in the approval, and if the approval is given to the wrong place, such as the double transaction, the bond can not be returned.

Fourth, we use the Trust method, assuming that only people who are trusted by the network are basically involved. Users do not trust the entire network, but selectively trust the node that they believe is trustworthy. It adopts a consensus scheme based on the Byzantine agreement protocol, and approves transactions in the block chain through voting and agreement of nodes participating in the network.

Finally, the fifth method is to use when a single entity or a plurality of entities that manage the network in a membership method is clear. Basically, only authorized nodes participate in the approval process, so it is possible to restrict the action to the contractual relationship.

1, a block chain is composed of a block header 11 composed of a hash value of a previous block header, a Merkle root, an electronic signature, a hash value of a current block, a time stamp, etc., a block header 12 composed of a Merkle Root, Consists of. As mentioned above, the block chain can be used in various forms depending on the usage, and the method of calculating the value of the block and the method of calculating the block hash can be variously modified.

DHT (Distributed hash table)

The distributed hash table is a proposed lookup scheme for uniformly distributing pairs of data key values and IDs generated through hashing to all the nodes constituting the system. All nodes and data are allocated to the same address space by using key value and ID of data, so it is easy to manage information of data and nodes at once, and there is no need of management because it enables automatic system update. Representative DHT algorithms include Chord, Pastry, and CAN, but the Chord algorithm is described in this specification.

The Chord algorithm is a method of assigning a key value of each node and data to a m-bit (0 to 2 ^m -1) circular address space in a way that was created by the University of Berkeley. A hash function is used to map to the address space. A node that is greater than or equal to the data key k in the address space is called a successor of k and is used to increase routing efficiency. 2 shows a 3-bit address space constituting the Chord network.

Referring to FIG. 2, three nodes 0, 1, and 3 are present in the network and participate in the system as successors of data keys 1, 2, and 6. In the Chord algorithm, each node has a routing information holding space whose size varies according to the size of the address space called the finger table. The finger table is composed of m rows when m-bit. In each row, successor information of data corresponding to ²ⁿ (1? ⁿ ? m) is stored based on the position of the current node.

Each node has predecessor and successor information in order to handle the participation of a new node and the departure of an existing node, and can automatically handle participation and departure of the node through the corresponding information.

In the DHT used in the embodiment described herein, the Chord algorithm is used and the Chord algorithm uses a reliability improvement technique called a Successor-List. Successor-List is a data structure described in Chord, which stores r successors. By distributing the data to the r successors in the Successor-List, even if one successor fails, information is obtained from the nearest successor in the list, The system can be configured. 3 is a diagram showing Successor-List and data replication using the Successor-List.

Typical P2P transaction method

The existing P2P trading method can be divided into three types according to the types of participating entities: NONBANK-CENTRIC P2P, BANK-CENTRIC P2P, and BANK-CENTRIC P2P (Consortium Model). One embodiment proposed in this specification takes a form similar to the BANK-CENTRIC P2P (Consortium Model), so it describes the BANK-CENTRIC P2P (Consortium Model).

The BANK-CENTRIC P2P (Consortium Model) consists of entities such as a transaction requester, a transaction requester, a bank of a transaction requester, a bank of a transaction requester, a consortium, and a government entity.

Step 1. Payer connects to the bank's web site, asks Payee to send one million won through P2P service, and enters Payee's name, email address and mobile number.

Step 2. At Payer's bank, make sure the Payer has enough money.

Step 3. Transfer the transaction information to the consortium at Payer's bank.

Step 4. The consortium confirms that there is an account with the consortium's bank through the e-mail address or cell phone number of the payee and sends the information to the bank of the payee if there is an account.

Step 5. The consortium sends an e-mail or a message to inform Payee about the transaction.

Step 6. Payee accesses the bank's website, agrees to the transaction, selects the account to be deposited, and informs him that he is waiting for the transaction to be completed.

Step 7. Payee's bank notifies the consortium that Payee has agreed to the transaction and sends Payee's account information.

Step 8. The consortium will forward the message from the Payee's bank to Payer's bank.

Step 9. The consortium informs Payer via email or message that Payee has agreed to the transaction.

Step 10. Payer's bank tells Payer to withdraw.

Step 11. The bank of Payer sends the information and ACH file to the Fed to the Payee's account information received through the consortium.

Step 12. The Fed informs the Payee's bank to pay the Payee's bank account and sends the ACH file.

Step 13. The Fed withdraws money from Payer's bank account and reserves the money to Payee's bank account.

Step 14. At the Payee's bank, tell Payee that you have been credited to your account.

The problems of the consortium model can be divided into efficiency and safety. In terms of efficiency, the safety and credibility of direct bank-to-bank transactions deteriorate. Therefore, we want to pursue safety and reliability by sending and receiving ACH files through highly reliable Feds. However, as a result, the number of transactions is increasing and transactions are slowed down by sending and receiving ACH files through the Fed.

When introducing the P2P transaction method, the safety aspect should be analyzed. In the case of the above consortium model, financial transaction information, which can be considered important personal information, is transferred between the user-bank, the bank-consortium, and the bank-Fed. As important personal information is frequently transmitted and received, there is a risk of exposure of important personal information through the capture of intermediaries and the risk of forgery and alteration of ACH and financial information between the Fed and the bank.

Hereinafter, a P2P transaction method according to an embodiment of the present invention will be described with reference to FIGS. 5 to 9. FIG.

5 is an exemplary diagram illustrating a P2P trading system in accordance with an embodiment of the present invention.

The remitter terminal 510 is a terminal used by the remitter to remit a certain amount of money to the receiver, and the remitter terminal 530 is a terminal used by the remitter to receive a predetermined amount of money from the remitter. 5 shows that the sender terminal 510 is a smartphone and the receiver terminal 530 is a desktop PC. However, the sender terminal 510 and the receiver terminal 530 are connected to these smartphones and desktop PCs And may include various types of terminal devices having a network connection function such as a tablet PC, a notebook, a PDA, and a wearable device.

The central server 550 may include, for example, a web server. The sender terminal 510 accesses the central server 550 to make a transaction request with the receiver terminal 530 and the central server 550 receives information according to the transaction request from the receiver terminal 530. The central server 550 makes a deposit / withdrawal transaction request to the DHT system 570 based on the information received from the sender terminal 510 and the information received from the receiver terminal 530.

In one embodiment of the present invention, the DHT system 570 comprises a node 575 such as a bank server or a securities company server that maintains account information of a user. The nodes 575 share the role of the node according to the DHT and the role of the block chain node, and store the information such as the account and the amount of the user's bank in the distributed hash table.

The sender terminal 510, the central server 550, the receiver terminal 530, and the DHT system 570 can communicate with each other through a secure channel.

6 is a flowchart illustrating a P2P transaction method according to an embodiment of the present invention.

In step S610, the central server 550 receives the first transaction request information from the remitter terminal 510. [ The first transaction request information may include an account number of the sender, a remittance amount, and receiver information.

In step S620, the central server 550 makes a transaction request to the receiver terminal 530 identified from the first transaction request information.

In step S630, the central server 550 receives the second transaction request information from the receiver terminal 530. [ The second transaction request information may include the account number of the receiver, the amount of the collection, and the sender information.

In step S640, the central server 550 obtains the first block chain hash value based on the first transaction request information, and obtains the second block chain hash value based on the second transaction request information. The first block chain hash value corresponds to the address of the node 575 that manages the account of the sender and the second block chain hash value may correspond to the address of the node 575 that manages the account of the receiver.

In step S650, the central server 550 requests a transaction from the DHT system 570 according to the first block chain hash value and the second block chain hash value.

Each node 575 of the DHT system 570 forwards the transaction request information to the nodes corresponding to the first block chain hash value and the second block chain hash value according to the transaction request of the central server 550, A node corresponding to a hash value of one block chain and a node corresponding to a hash value of a second block chain perform deposit and withdrawal in response to a transaction request and maintain the integrity by sharing the updated distributed hash table with other nodes have.

Meanwhile, the central server 550 can perform a pre-key exchange procedure with the remitter terminal 510 and the receiver terminal 530, which will be described with reference to FIG. The definitions of symbols used in FIG. 7 and FIG. 8 to be described later are shown in Table 1 below.

7 is a diagram for explaining a procedure of exchanging a key with the central server 550 and a user terminal (a sender terminal 510 and a receiver terminal 530)

In step S710, the user terminal 700 generates an electronic signature key pair (pkA ^{, s} _sig , sk ^{A, s} _sig ) and a secret key (sk ^{A, s} _enc ).

In step S720, the user terminal 700 transmits the public key pk ^{A, s} _sig and the secret key sk ^{A, s} _enc to the central server 550.

In step S730, the central server 550 generates an electronic signature key pair (pk ^{s, A} _sig , sk ^{s, A} _sig ).

In step S740, the central server 550 transmits the public keys pk ^{s and A} _sig among the generated digital signature key pairs to the user terminal 700.

Thus, the user terminal 700 transmits the digital signature key pair (pkA ^{, s} _sig , sk ^{A, s} _sig ) generated by the user terminal 700, the private key (sk ^{A, s} _enc ) key (pk ^{s, a} _sig) and holding, the central server 550 is released received from the digital signature key pair that it generates (pk ^{s, a} _sig, sk ^{s, a} _sig), the user terminal 700, Key (pk ^{A, s} _sig ) and a secret key (sk ^{A, s} _enc ).

The key exchange procedure may be performed after the user logs in the web site of the central server 550 to use the P2P transaction service. All communication after login is done through SSL (secure socket layer).

FIG. 8 is a view for explaining a concrete operation of the sender terminal 510, the receiver terminal 530, the central server 550 and the DHT system 570 according to an embodiment of the present invention.

7, when the sender terminal 510 accesses the central server 550, the sender terminal 510 encrypts the first transaction request information C _A with its own secret key (sk ^{A, s} _enc ) (Ska ^{, s} _enc (C _A )), its identifier (ID _A ) and any one public key (pk ^kA _sig ) it holds, to the center To the server 550 (S810). The first transaction request information C _A is generated by serializing the account information (account _A ) and the remittance information (c _A ) by the sender terminal 510.

The central server 550 is first received public key a public key that he or she is holding the (pk ^kA _sig) (that is, public he has created a public key and the sender receives from the terminal 510, key) (pk ^{s, A} _sig , pk ^{A, s} _sig ) (S 815) to authenticate the sender terminal 510.

The central server 550 decrypts the encrypted first transaction request information C _A with the decryption keys sk ^{A and S} _enc received from the sender terminal 510 to obtain the first transaction request information C _A (S820).

The central server 550 transmits the identifier of the sender (ID _A ) to the receiver terminal 530 identified from the first transaction request information (C _A ) and makes a transaction request (S825).

Receiver terminal 530, the second transaction request information (C _B) and then encrypted (S830) as his private key (sk ^{B, s} _enc), the encrypted second transaction request information (sk ^{B, s} _enc ( C _B ), its own identifier (ID _B ), and any public key (pk ^kB _sig ) it holds, to the central server 550 (S835). The second transaction request information C _B is generated by serializing the account information account _B and the collection information c _{B by the} receiver terminal 530.

The central server 550 stores the received public key pk ^kB _sig in its own public key (i.e., the public key generated by itself and the public key received from the receiver terminal 530) (pk ^{s, B} _sig , pk ^{B, and s} _sig ) (S840), and authenticates the receiver terminal 530.

The central server 550 decodes the encrypted second transaction request information C _B into the decryption keys sk ^{B and S} _enc received from the receiver terminal 530 and outputs the second transaction request information C _B (S845).

The central server 550 transmits the identifier (ID _B ) of the receiver to the sender terminal 510 to inform that the transaction has been approved by the receiver (S850).

The central server 550 deserializes the first transaction request information C _A to obtain the account information _A and the transfer information C _{A of the} sender and obtains the second transaction request information C _B , And obtains account information (account _B ) and collection information C _{B of the} receiver (S855). The account information (account _A ) of the sender may include a bank name and an account number used by the sender, and the transfer information (c _A ) may include remittance amount information and receiver information (for example, an identifier of the receiver) . The account information (account _B ) of the receiver may include a bank name and an account number used by the receiver, and the collection information (c _B ) may include the collection amount information and the sender information (for example, the identifier of the sender) .

The central server 550 is obtained after serializing a public key (pk ^kA _sig) received by the account information (account _A) parties remittance and S810, hashing (hashing) to the first block chain hash value (H _A), and after serialization of a public key (pk ^kB _sig) received by the collection's account information (account _B) and the step S835 will be hashed to obtain a second block chain hash value (H _B) (S860). As described above, the first block chain hash value H _A corresponds to the address of the node managing the sender's account, and the second block chain hash value H _B corresponds to the address of the node managing the account of the receiver And thus it may be easier to search for a particular node in the DHT system 570 in that the address of each node is generated from the hash value of the account information.

Next, the central server 550 generates a first block chain transaction L [H _A ] based on the first block chain hash value H _A and the hash value of the transfer information c _A , The second block chain transaction L [H _B ] is generated based on the hash value of the block chain hash value H _B and the transfer information c _B (S865).

The central server 550 is the DHT system 570, the first block chain transactions (L [H _A]) and the second block chain transaction by sending an (L [H _B]), transfer the hash value of the information (c _A) (h _(a c)) and receiving information requests so that the receipt and payout processing based on the hash value (h (c _B)) of (c _B) (S870).

Each node of the DHT system 570 transmits a first block chain transaction L [H _A ] and a second block chain transaction L [H _B ] to the next node existing in the list by referring to the Successor_list, The hash value h (c _A ) of the transfer information c _A is transferred to the node (for example, a node) corresponding to the first block chain hash value H _A , and the second block chain hash value such that (h _b) nodes (e.g., node b) the hash value (h _(b c)) of receiving information (c _b) transmitted to the corresponding on. each a node and b node modifies or updates the distributed hash table based on the hash value (h (c _B)) of the hash value (h (c _A)), and receiving information (c _B) of the transfer information (c _A) (S875). The modified or updated distributed hash table is shared by other nodes. Further, according to the modification of the distributed hash table by the node a and the modification of the distributed hash table by the node b, a certain amount is transferred from the account of the sender to the account of the receiver.

The DHT system 570 transmits a modification completion message of the distributed hash table to the central server 550 in step S880 and the central server 550 transmits a transaction completion message to the sender terminal 510 and the receiver terminal 530 (S885).

9 is a block diagram showing a configuration of a central server 550 according to an embodiment of the present invention.

9, the central server 550 according to an exemplary embodiment of the present invention may include a user interaction unit 551, a system interaction unit 553, an authentication unit 555, and a central processing unit 557 . The user interlocking unit 551, the system interlocking unit 553, the authentication unit 555, and the central processing unit 557 may be implemented by at least one processor and may operate according to a program stored in a memory (not shown).

The user interlocking unit 551 is interlocked with the remitter terminal 510 and the receiver terminal 530. Specifically, the user interaction unit 551 performs key exchange in advance with the sender terminal 510 and the receiver terminal 530, receives the first transaction request information from the sender terminal 510, Lt; RTI ID = 0.0 > 530 < / RTI >

The system interworking unit 553 interlocks with the DHT system 570. Specifically, the system interworking unit 553 requests the DHT system 570 for deposit and withdrawal processing based on the first block chain hash value and the second block chain hash value generated by the central processing unit 557.

The authentication unit 555 compares the public key received from the sender terminal 510 and the public key received from the receiver terminal 530 with the public key held in advance, and transmits the public key to the sender terminal 510 and the receiver terminal 530. [ And decrypts the first transaction request information encrypted by the sender terminal 510 and the second transaction request information encrypted by the receiver terminal 530 with the decryption key.

The central processing unit 557 deserializes the decrypted first transaction request information and the decrypted second transaction request information to obtain the account information, the remittance information, and the collection information, and based on the acquired information and the public key, And obtains a block chain hash value and a second block chain hash value.

In addition, the central processing unit 557 generates a first block chain transaction based on the first block chain hash value and the hashed transfer information, and generates a second block chain transaction based on the second block chain hash value and the hashed receipt information .

The first block chain transaction and the second block chain transaction are transmitted to the DHT system 570 via the system interworking unit 553 so that the transfer between the sender and the receiver can be processed as described above.

According to the P2P transaction method according to the embodiment of the present invention, it can be very effective in defending the meson attack and the DDoS attack.

The intermediary attack is an attack that may occur from the moment the transaction proceeds. In an embodiment of the present invention, the intermediary attack is performed from the moment the sender terminal 510 accesses (or logs in) the central server 550 to use the P2P transaction service, And all transaction information exchanged between the user terminal and the central server 550 is encrypted and protected through the secret key exchanged in the pre-key exchange procedure. Since the communication between the central server 550 and the DHT system 570 is a request for viewing and modifying the DHT, and the information transmitted from the DHT to the viewing and modifying request is the hash value of the user account information, The ACH file or the financial transaction information can not be forged and tampered with, and the personal information such as the account and the telephone number of the user can not be taken.

Also, even if the information stored in the DHT system 570 is stolen, the attacker can obtain only the hash value, which is safe against the man-in-the-middle attack.

In addition, since each bank in the DHT system 570 functions as a node of the DHT as a node of a closed consortium block chain, even if a DDoS attack occurs in the A bank, Services will be available without infringement.

While the present invention has been described in connection with what is presently considered to be practical exemplary embodiments, it is to be understood that the invention is not limited to the disclosed embodiments, but, on the contrary, Various modifications and variations are possible.

510: Sender terminal
530:
550: central server
551: user interlocking part
553: system interlocking part
555:
557:
570: DHT system
575: Node

Claims (13)

Receiving first transaction request information from a sender terminal;
Requesting a transaction to a receiver terminal identified from the first transaction request information;
Receiving second transaction request information from the receiver terminal;
Obtaining a first block chain hash value based on the first transaction request information and obtaining a second block chain hash value based on the second transaction request information; And
Requesting a transaction from a distributed hash table (DHT) system in accordance with the first and second block chain hash values and transmitting a hash value corresponding to each of the first and second block chain hash values among a plurality of nodes included in the DHT system Causing the first and second nodes to perform a deposit and withdrawal;
The P2P transaction method comprising:
The method according to claim 1,
The P2P transaction method comprises:
And receiving the sender's private key from the sender terminal before receiving the first transaction request information from the sender terminal,
Wherein the receiving of the first transaction request information from the sender terminal comprises:
And decrypting the first transaction request information encrypted with the secret key by the sender terminal with the previously received secret key.
The method according to claim 1,
The P2P transaction method comprises:
Exchanging the sender terminal with the sender public key and the central server public key before receiving the first transaction request information from the sender terminal,
Wherein the receiving of the first transaction request information from the sender terminal comprises:
And authenticating the sender terminal by comparing the public key received together with the first transaction request information with at least one of the previously received sender public key and the central server public key, .
The method according to claim 1,
The P2P transaction method comprises:
Receiving the receiver's private key from the receiver terminal before receiving the second transaction request information from the receiver terminal,
Wherein the receiving of the second transaction request information from the receiver terminal comprises:
And decoding the second transaction request information encrypted with the secret key by the receiver terminal with the previously received secret key.
The method according to claim 1,
The P2P transaction method comprises:
Exchanging the receiver key public key and the central server public key with the receiver terminal before receiving the second transaction request information from the receiver terminal,
Wherein the receiving of the second transaction request information from the receiver terminal comprises:
And authenticating the receiver terminal by comparing the public key received together with the second transaction request information with at least one of the previously received receiver's public key and the central server public key, .
The method according to claim 1,
The P2P transaction method comprises:
Calculating the first transaction request information to obtain account information and remittance information of a sender; And
Calculating the second transaction request information to obtain account information and collection information of the receiver;
The P2P transaction method further comprising:
The method according to claim 6,
The P2P transaction method comprises:
And deserializing the first and second transaction request information.
The method according to claim 6,
Wherein the obtaining of the first and second block chain hash values comprises:
A hash value obtained by hashing the public key received from the sender terminal and the account information of the sender to obtain the first block chain hash value, hashing the public key received from the receiver terminal and the account information of the receiver, And obtaining a block chain hash value.
The method according to claim 6,
The step of requesting a transaction to the DHT system according to the first and second block chain hash values comprises:
A first block chain transaction generated based on the first block chain hash value and the transfer information and a second block chain transaction generated based on the second block chain hash value and the collection information to the DHT system A P2P transaction method, comprising:
The method according to claim 1,
The P2P transaction method comprises:
And transferring a transaction completion message to the sender terminal and the receiver terminal when the deposit and withdrawal by the DHT system is completed.
delete A user interlocking unit for receiving first transaction request information from a sender terminal and receiving second transaction request information from a receiver terminal;
A central processing unit for obtaining a first block chain hash value based on the first transaction request information and obtaining a second block chain hash value based on the second transaction request information; And
Requesting a transaction from a distributed hash table (DHT) system in accordance with the first and second block chain hash values and transmitting a hash value corresponding to each of the first and second block chain hash values among a plurality of nodes included in the DHT system A system interlocking unit for causing the first and second nodes to perform the deposit and withdrawal;
And a central server.
Acquiring a first block chain hash value and a second block chain hash value based on first transaction request information received from a sender terminal and second transaction request information received from a receiver terminal, A central server for requesting a deposit and withdrawal transaction based on a chain hash value; And
A distributed hash table (DHT) system for performing a deposit / withdrawal by a first node and a second node corresponding to the first and second block chain hash values, respectively, of a plurality of nodes when receiving a transaction request from the central server;
The P2P transaction system.

Images