Electronic currency system, method, and program

Abstract

An electronic currency system including a plurality of participant devices, wherein, in a first payment transaction in which a participant who uses a participant device becomes a recipient, the participant device includes: a first generation unit that generates a first temporary public key that is a temporary public key of the participant in the first payment transaction; a second generation unit that generates a first commit of a first Sigma protocol taking information including the first temporary public key as a first problem, and taking information including identification information by which the participant is identifiable as first knowledge; a first transmission unit that transmits the first temporary public key and the first commit to a first other participant device used by a first other participant who is the payer of the first payment transaction; and a first reception unit that receives, from the first other participant device, information representing an electronic currency to be the means of payment in the first payment transaction, information indicating the electronic currency, and a signature including the first temporary public key and the first commit as a message.

Description

Electronic currency system, method and program

[0001] The present disclosure relates to electronic currency systems, methods and programs.

[0002] Research into electronic currency has been conducted for many years, and experiments are being conducted in which legal tender issuing banks such as the Bank of Japan issue electronic currency and circulate it over the Internet through financial institutions.

[0003] For example, Patent Document 1 discloses an electronic currency system that allows transactions to be completed only between users.

[0004] International Publication No. 2022 / 254624

[0005] However, conventional electronic currency systems do not provide anonymity because the public keys of participants (payers and recipients) are exposed during the process (transaction) of paying electronic currency. Furthermore, because these public keys are signed and managed in advance by banks and other institutions, they do not even provide pseudonymity to banks and other institutions.

[0006] The present disclosure has been made in consideration of the above points, and aims to guarantee the anonymity of participants.

[0007] An electronic currency system according to one aspect of the present disclosure is an electronic currency system that includes multiple participant devices each used by multiple participants who will be the payer or recipient of an electronic currency payment transaction, and in a first payment transaction in which a participant using the participant device is the recipient, the participant device has: a first generation unit that generates a first temporary public key that is a temporary public key of the participant in the first payment transaction; a second generation unit that generates a first commit of a first Σ protocol using information including the first temporary public key as a first problem and information including identification information that can identify the participant as first knowledge; a first transmission unit that transmits the first temporary public key and the first commit to a first other participant device used by a first other participant who will be the payer of the first payment transaction; and a first receiving unit that receives from the first other participant device information representing the electronic currency to be paid in the first payment transaction and a signature in which the information representing the electronic currency, the first temporary public key, and the first commit form a message.

[0008] Participants' anonymity will be guaranteed.

[0009] FIG. 1 is a diagram illustrating an example of the overall configuration of an electronic currency system in Example 1. FIG. 2 is a diagram illustrating an example of the hardware configuration of an authentication management device in Example 1. FIG. 3 is a diagram illustrating an example of the hardware configuration of a participant device in Example 1. FIG. 4 is a diagram illustrating an example of the functional configuration of an authentication management device in Example 1. FIG. 5 is a diagram illustrating an example of the functional configuration of a participant device in Example 1. FIG. 6 is a flowchart illustrating an example of the setup process of the authentication management device in Example 1. FIG. 7 is a sequence diagram illustrating an example of the setup process of a participant device in Example 1. FIG. 8 is a flowchart illustrating an example of the receipt process in Example 1. FIG. 9 is a flowchart illustrating an example of the payment process in Example 1. FIG. 10 is a flowchart illustrating an example of the fraudster identification process in Example 1. FIG. 11 is a diagram illustrating an example of the functional configuration of an authentication management device in Example 2. FIG. 12 is a diagram illustrating an example of the functional configuration of a participant device in Example 2. FIG. 13 is a flowchart illustrating an example of the setup process of a participant device in Example 2. FIG. 14 is a flowchart illustrating an example of the receipt process in Example 2. FIG. 15 is a flowchart illustrating an example of the payment process in Example 2. FIG. 16 is a diagram illustrating an example of the functional configuration of a participant device in Example 3. FIG. 17 is a flowchart illustrating an example of the setup process of a participant device in Example 3. FIG. 18 is a flowchart illustrating an example of the receipt process in Example 3. FIG. 19 is a flowchart illustrating an example of the payment process in Example 3.

[0010] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.

[0011] [Preparation] <Digital Signature> Let (Gen, Sign, Verify) be the digital signature, where Gen is the key generation algorithm, Sign is the signature algorithm, and Verify is the verification algorithm.

[0012] Key generation algorithm Gen The key generation algorithm Gen is 1 ｋ is input, and the public key pk and the private key sk are output. That is, (pk, sk)←Gen(1 ｋ ) where k is a security parameter. The public key and private key are sometimes called the "verification key" and "signature key," respectively.

[0013] Signature algorithm Sign The signature algorithm Sign takes a message m to be signed and a private key sk as input, and outputs a signature σ. That is, σ←Sign ｓｋ (m).

[0014] Verification algorithm Verify The verification algorithm Verify receives a message m to be verified, a signature σ, and a public key pk, and outputs 1 or 0. That is, 1 / 0←Verify ｐｋ (m, σ), where 1 means successful verification and 0 means unsuccessful verification.

[0015] <Commitment> Let com be a binding and confidential commitment.

[0016] Commit Phase In the commit phase, the commitment com receives a message x and a random number r as input and outputs a commitment c for the message x. That is, c←com(x;r).

[0017] Public Phase In the public phase, when (x', r') is given, the commitment com outputs 1 if c=com(x'; r'), and 0 otherwise.

[0018] <Σ Protocol> Language L Σ :={x|∃w, (x, w)∈R}. Then, Σ is the problem x∈L Σ Let x be the Σ protocol, which shows that x knows knowledge w of x (Reference 1). Here, R represents a relationship. The Σ protocol is a type of zero-knowledge proof that is completed in 3 moves (first message, second message, third message). Also, x is sometimes called a "proposition," and w is sometimes called a "witness" or "solution."

[0019] Commit (first message) In the first message, problem x, knowledge w, and random number r Σ and as input, commit com Σ That is, com Σ ←Σ. com(x,w;rΣ ) by commit com Σ Here, Σ.com outputs the problem x, knowledge w, and random number r Σ and as input, commit com Σ This is an algorithm that outputs

[0020] ・Challenge (second message) In the second message, challenge chal Σ That is, chal Σ ← ChalSpace Σ Challenge by chal Σ Here, ChalSpace is output (sampled). Σ is a challenge space.

[0021] ・Response (third message) In the third message, commit com Σ And, Challenge chal Σ problem x, knowledge w, and random number r Σ and the response res Σ That is, res Σ ←Σ. res (com Σ , chal Σ , x, w, r Σ ) response res Σ where Σ.res is the commit com Σ And, Challenge chal Σ problem x, knowledge w, and random number r Σ and the response res Σ This is an algorithm that outputs

[0022] ・Verification commit com Σ And the response res Σ Let Σ.Verify be an algorithm that takes as input the problem x and the prover's knowledge w of the problem x and outputs 1 (verification successful) if the prover has knowledge w of the problem x, and 0 (verification failed) if not. That is, 1 / 0←Σ.Verify(com Σ , res Σ , x). Note that Σ.Verify is generally a challengeΣ Although the challenge chal is often taken as an input, in this embodiment Σ is calculated within Σ.Verify, where Σ.Verify is the challenge chal Σ does not take as input.

[0023] ・Extractor problem x and commit com Σ And two challenges Σ , chal Σ ' (However, chal Σ ≠chal Σ ') and two responses res Σ , res Σ Let Ext be the algorithm that takes ' and com as input and outputs knowledge w'. That is, w'←Ext(x,com Σ , chal Σ , chal Σ ', res Σ , res Σ The existence of the extractor Ext is guaranteed by special soundness (SS), which is one of the properties of the Σ protocol.

[0024] <Hash function> H: {0, 1} ＊ → ChalSpace Σ Let be a hash function modeled as a random oracle.

[0025] Based on the above preparations, the following describes Examples 1 to 3 of the electronic currency system 1 that can guarantee the anonymity of participants (users).

[0026] In the electronic currency system 1 in the following Examples 1 to 3, when an electronic currency payment transaction is made, the person receiving the electronic currency generates a temporary public key, and this temporary public key is used for the payment. As a result, the public key of the participant (the person receiving the electronic currency) changes with each payment, making it impossible to identify the participant and ensuring anonymity.

[0027] Furthermore, the electronic currency system 1 in the following Examples 1 to 3 uses the Σ protocol during electronic currency payment transactions. As a result, for example, if a person paying electronic currency makes a double payment (i.e., if the same electronic currency is paid to different people), the soundness of the Σ protocol, one of its properties, makes it possible to identify the fraudulent participant who made the double payment.

[0028] [Example 1] Example 1 will be described below.

[0029] <Example of Overall Configuration> An example of the overall configuration of the electronic currency system 1 in the first embodiment will be described with reference to Fig. 1. Fig. 1 is a diagram showing an example of the overall configuration of the electronic currency system 1 in the first embodiment.

[0030] 1, the electronic currency system 1 in the first embodiment includes an authentication management device 10 and a plurality of participant devices 20. The authentication management device 10 and each participant device 20 are communicatively connected via a communication network 30 including, for example, the Internet.

[0031] The authentication management device 10 is an information processing device or information processing system that authenticates participants in the electronic currency system 1 (i.e., guarantees the legitimacy of the participants). An example of the authentication management device 10 is an authentication server such as a certification authority managed by a central bank. However, the authentication management device 10 is not limited to this, and may also be an authentication server such as a certification authority managed by a commercial bank other than a central bank.

[0032] The participant device 20 is an information processing device or information processing system used or managed by a participant (i.e., a user who makes payments or receives electronic currency). The participant device 20 may be a personal computer (PC), smartphone, tablet terminal, wearable device, etc. used or managed by an individual, or may be a general-purpose server or a system configured from such a server managed by a financial institution such as a bank (central bank, commercial bank), a corporation such as a general company, or various organizations.

[0033] Hereinafter, during an electronic currency payment transaction, the participant who receives the electronic currency will be referred to as the "receiver," and the participant who pays the electronic currency will be referred to as the "payer." The participant device 20 used or managed by the receiver will also be referred to as the "receiver device 20," and the participant device 20 used or managed by the payer will also be referred to as the "payer device 20."

[0034] 1 is an example, and the overall configuration of the electronic currency system 1 is not limited to this. For example, the electronic currency system 1 may include multiple authentication management devices 10, and each authentication management device 10 may form a hierarchical structure using a root certification authority, an intermediate certification authority, etc.

[0035] <Hardware Configuration Example> <Authentication Management Device 10> An example of the hardware configuration of the authentication management device 10 according to the first embodiment will be described with reference to Fig. 2. Fig. 2 is a diagram illustrating an example of the hardware configuration of the authentication management device 10 according to the first embodiment.

[0036] 2, the authentication management device 10 in the first embodiment includes an input device 11, a display device 12, an external I / F 13, a communication I / F 14, a random access memory (RAM) 15, a read-only memory (ROM) 16, an auxiliary storage device 17, and a processor 18. Each of these pieces of hardware is connected to each other via a bus 19 so as to be able to communicate with each other.

[0037] The input device 11 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 12 is, for example, a display, a display panel, etc. Note that the authentication management device 10 does not necessarily have to have at least one of the input device 11 and the display device 12, for example.

[0038] The external I / F 13 is an interface with an external device such as a recording medium 13 a. Examples of the recording medium 13 a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

[0039] The communication I / F 14 is an interface for connecting to the communication network 30. The RAM 15 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 16 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 17 is a non-volatile storage device such as a hard disk drive (HDD), a solid state drive (SSD), or a flash memory. The processor 18 is one of various arithmetic devices such as a central processing unit (CPU).

[0040] 2 is an example, and the hardware configuration of the authentication management device 10 is not limited to this. For example, the authentication management device 10 may have multiple auxiliary storage devices 17 or multiple processors 18, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.

[0041] <<Participant Device 20>> An example of the hardware configuration of the participant device 20 in the first embodiment will be described with reference to Fig. 3. Fig. 3 is a diagram illustrating an example of the hardware configuration of the participant device 20 in the first embodiment.

[0042] 3 , the participant device 20 in Example 1 includes an input device 21, a display device 22, an external I / F 23, a communication I / F 24, a RAM 25, a ROM 26, an auxiliary storage device 27, and a processor 28. Each of these pieces of hardware is communicatively connected via a bus 29.

[0043] The input device 21 is, for example, a keyboard, a mouse, a touch panel, a physical button, etc. The display device 22 is, for example, a display, a display panel, etc. Note that the participant device 20 may not have at least one of the input device 21 and the display device 22, for example.

[0044] The external I / F 23 is an interface with an external device such as a recording medium 23a, etc. Examples of the recording medium 23a include a CD, a DVD, an SD memory card, and a USB memory card.

[0045] The communication I / F 24 is an interface for connecting to the communication network 30. The RAM 25 is a volatile semiconductor memory (storage device) that temporarily stores programs and data. The ROM 26 is a non-volatile semiconductor memory (storage device) that can store programs and data even when the power is turned off. The auxiliary storage device 27 is a non-volatile storage device such as an HDD, SSD, or flash memory. The processor 28 is, for example, a CPU or other type of computing device.

[0046] 3 is an example, and the hardware configuration of the participant device 20 is not limited to this. For example, the participant device 20 may have multiple auxiliary storage devices 27 or multiple processors 28, may not have some of the hardware shown in the figure, or may have various hardware other than the hardware shown in the figure.

[0047] <Functional Configuration Example> <Authentication Management Device 10> An example of the functional configuration of the authentication management device 10 in the first embodiment will be described with reference to Fig. 4. Fig. 4 is a diagram illustrating an example of the functional configuration of the authentication management device 10 in the first embodiment.

[0048] 4 , the authentication management device 10 according to the first embodiment includes a master key generation unit 101 and a key registration unit 102. These units are realized, for example, by a process in which one or more programs installed in the authentication management device 10 are executed by a processor 18 or the like. The authentication management device 10 according to the first embodiment also includes a master key storage unit 103 and a registration key storage unit 104. These storage units are realized, for example, by a storage area of ​​the auxiliary storage device 17 or the like. However, for example, at least one of the master key storage unit 103 and the registration key storage unit 104 may be realized by a storage area of ​​a storage device or the like that is communicably connected to the authentication management device 10.

[0049] The master key generation unit 101 generates a master key (mpk, msk) and stores the master key (mpk, msk) in the master key storage unit 103. Hereinafter, mpk will be referred to as the master public key, and msk will be referred to as the master private key. The master public key mpk is made public to each participant.

[0050] In response to a registration request from a participant device 20, the key registration unit 102 generates a signature σ for a user private key usk, which is the private key of the participant who uses or manages the participant device 20. ｕｓｋ and generate a signed user private key (usk, σ ｕｓｋ ) is stored in the registration key storage unit 104. The key registration unit 102 also stores the signed user private key (usk, σ ｕｓｋ The participant device 20 transmits the registration result including the registration information 22 to the participant device 20.

[0051] The master key storage unit 103 stores a master key (mpk, msk) which is a key pair of a master public key mpk and a master secret key msk.

[0052] The registration key storage unit 104 stores the user private key usk of each participant and the corresponding signature σ ｕｓｋ and (usk, σ ｕｓｋ ) is memorized.

[0053] <<Participant Device 20>> An example of the functional configuration of the participant device 20 in the first embodiment will be described with reference to Fig. 5. Fig. 5 is a diagram illustrating an example of the functional configuration of the participant device 20 in the first embodiment.

[0054] 5 , the participant device 20 in Example 1 includes a user key generation unit 201, a registration request unit 202, a receiving unit 203, a payment unit 204, and a fraudster identification unit 205. Each of these units is implemented, for example, by a processor 28 or the like executing one or more programs installed in the participant device 20. The participant device 20 in Example 1 also includes a user key storage unit 206 and a token storage unit 207. Each of these storage units is implemented, for example, by a storage area of ​​the auxiliary storage device 27 or the like. However, for example, at least one of the user key storage unit 206 and the token storage unit 207 may be implemented by a storage area of ​​a storage device or the like communicatively connected to the participant device 20.

[0055] The user key generation unit 201 generates a user secret key usk of the participant who uses or manages the participant device 20 .

[0056] The registration request unit 202 transmits a registration request for the user private key usk to the authentication management device 10. When the registration request unit 202 receives a registration result in response to the registration request, the registration request unit 202 transmits the signed user private key (usk, σ ｕｓｋ ) is stored in the user key storage unit 206.

[0057] When the participant using or managing the participant device 20 is a receiver (i.e., when the participant device 20 is a receiver device 20), the receiver 203 executes receiver-side processing (hereinafter referred to as "receiving processing") during an electronic currency payment transaction. More specifically, the receiver 203 generates a temporary public key upk from the user private key usk by commitment, and generates a commit com by the Σ protocol. Σ Generate (upk, com Σ ) to the payer device 20. When the receiving unit 203 receives a payment response to the payment request, the receiving unit 203 sends the payment request including the signature Σ Ｓ After verifying the token T included in the payment response, Ｓ and signature Σ Ｓ The token history T is updated by the signature Σ, and the updated token history T is stored in the token storage unit 207. Ｓis represented by a set of commit and response in the Σ protocol, and is information for identifying a fraudulent payer when a double spend occurs. Ｓ and signature Σ Ｓ The token history T is, for example, the history of a token T representing electronic currency. Ｓ （０） If n payments have been made since the issuance of Ｓ and signature Σ Ｓ The set of (T Ｓ （ｉ） , Σ Ｓ （ｉ） ), then T = {(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )} where T Ｓ （０） is a token representing a certain unit of electronic currency (e.g., 1000 yen), Σ Ｓ （０） is the token T Ｓ （０） The signature of the entity that issued T (e.g., a central bank). Ｓ （ｉ） :=(upk （ｉ） , H １ (T Ｓ （ｉ－１） )), Σ Ｓ （ｉ） :=(com Σ （ｉ） , res Σ （ｉ） ) In addition, upk （ｉ） is the temporary public key generated by the recipient who receives the token history T when the i-th payment is made. １ represents a predetermined hash function.

[0058] If the participant using or managing the participant device 20 is a payer (i.e., if the participant device 20 is a payer device 20), the payment unit 204 executes the payer's processing (hereinafter referred to as payment processing) during the electronic currency payment transaction. More specifically, the payment unit 204 executes the processing (upk', com Σ ') and a new token T added to the token history T of the electronic currency to be paid. Ｓ and the commit com generated when receiving the token history T Σ Using the Σ protocol, challenge chal Σ After generating the response res Σ Then, the payment unit 204 generates the token T Ｓ Signature for Σ Ｓ = (com Σ , res Σ ), and (T Ｓ , Σ Ｓ , T) to the receiver device 20.

[0059] The fraudster identification unit 205 executes processing to identify a fraudulent payer (hereinafter also referred to as a fraudster) who has made a double payment. More specifically, the fraudster identification unit 205 identifies the fraudster's user private key usk using the extractor Ext.

[0060] The user key storage unit 206 stores the signed user private key (usk, σ) of the participant who uses or manages the participant device 20. ｕｓｋ ) is memorized.

[0061] The token storage unit 207 stores the token history T of the electronic currency held by the participant who uses or manages the participant device 20. The token history T is expressed as T={(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )}, and the electronic currency T Ｓ（０） and signature Σ Ｓ History and Electronic Currency T Ｓ （０） and the history of the recipient's temporary public key upk.

[0062] <Operation Example> An operation example of the electronic currency system 1 in the first embodiment will be described below.

[0063] <<Setup Processing of the Authentication Management Device 10>> An example of the setup processing of the authentication management device 10 in the first embodiment will be described with reference to Fig. 6. Fig. 6 is a flowchart showing an example of the setup processing of the authentication management device 10 in the first embodiment.

[0064] First, the master key generation unit 101 of the authentication management device 10 performs the following operation: (mpk, msk)←Gen(1 ｋ ) to generate a master key (mpk, msk) (step S101).

[0065] Then, the master key generation unit 101 of the authentication management device 10 stores the master key (mpk, msk) in the master key storage unit 103 (step S102). Note that the master public key mpk is made public to each participant by any method.

[0066] <<Setup Process of Participant Device 20>> An example of the setup process of the participant device 20 in Example 1 will be described with reference to Fig. 7. Fig. 7 is a sequence diagram showing an example of the setup process of the participant device 20 in Example 1. The following describes the setup process of a certain participant device 20. Note that, in the following, it is assumed that the setup process of the authentication management device 10 has been completed.

[0067] First, the user key generation unit 201 of the participant device 20 generates a user private key usk←{0, 1} of the participant who uses or manages the participant device 20. λ is generated (step S201), where λ is a security parameter.

[0068] Next, the registration request unit 202 of the participant device 20 transmits a registration request including the user secret key usk to the authentication management device 10 (step S202).

[0069] When the key registration unit 102 of the authentication management device 10 receives a registration request from the participant device 20, the key registration unit 102 generates a signature σ for the user private key usk included in the registration request. ｕｓｋ ←Sign ｍｓｋ (usk) is generated (step S203).

[0070] Next, the key registration unit 102 of the authentication management device 10 registers the signed user private key (usk, σ ｕｓｋ ) is stored in the registration key storage unit 104 (step S204). As a result, the user secret key usk of the participant who uses or manages the participant device 20 is registered in the authentication management device 10.

[0071] Next, the key registration unit 102 of the authentication management device 10 registers the signed user private key (usk, σ ｕｓｋ ) is transmitted to the participant device 20 (step S205).

[0072] When the registration request unit 202 of the participant device 20 receives the registration result from the authentication management device 10, the registration request unit 202 ｕｓｋ ) is stored in the user key storage unit 206 (step S206).

[0073] In the setup process shown in FIG. 7, the participant device 20 generates the user private key usk in step S201 above, but the user private key usk may also be generated by the authentication management device 10, for example.

[0074] <Receiving Process> An example of the receiving process in Example 1 will be described with reference to Fig. 8. Fig. 8 is a flowchart showing an example of the receiving process in Example 1. Below, a receiving process will be described in which a certain participant device 20 is the receiver device 20 and another certain participant device 20 is the payer device 20, and the receiver device 20 receives electronic currency from the payer device 20. It is assumed that the setup process of the receiver device 20 has been completed.

[0075] First, the receiving unit 203 of the receiver device 20 receives the temporary public key upk←com(usk;r ｕｐｋ ) is generated (step S301). ｕｐｋis the random number used in the commitment.

[0076] Next, the receiving unit 203 of the receiver device 20 Σ ←Σ. com((mpk, upk), (usk, σ ｕｓｋ , r ｕｐｋ ) ; r Σ ) is generated (step S302). Σ is a random number used when generating the first message of the Σ protocol. usk is the user private key of the participant (receiver) who uses or manages the receiver device 20, σ ｕｓｋ is its signature.

[0077] Next, the receiving unit 203 of the receiver device 20 receives the Σ ) is transmitted to the payer device 20 (step S303).

[0078] Next, the receiving unit 203 of the receiver device 20 Ｓ , Σ Ｓ , T) from the payer device 20 (step S304). Ｓ = (upk, H １ (T Ｓ （ｎ） )), Σ Ｓ = (com Σ ', res Σ '), T = {(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） ))

[0079] Next, the receiving unit 203 of the receiver device 20 receives the signature Σ Ｓ (Step S305). That is, the receiving unit 203 verifies Σ.Verify(com Σ ', res Σ ', (mpk, upk （ｎ）)) Signed by Σ Ｓ In Σ.Verify, the signature Σ Ｓ （ｎ） = (com Σ （ｎ） , res Σ （ｎ） ) and chal Σ '=H(T Ｓ ,upk,com Σ ,com Σ （ｎ） ) Challenge chal Σ ' is generated.

[0080] Next, the receiving unit 203 of the receiver device 20 receives the signature Σ Ｓ It is determined whether the verification is successful (step S306).

[0081] In step S306 above, the signature Σ Ｓ If it is determined that the verification of the token T is successful, the receiving unit 203 of the receiver device 20 Ｓ and signature Σ Ｓ The receiving unit 203 updates the token history T by the token history T, and stores the updated token history T in the token storage unit 207 (step S307). Ｓ （ｎ＋１） ←T Ｓ , Σ Ｓ （ｎ＋１） ←Σ Ｓ As such, (T Ｓ （ｎ＋１） , Σ Ｓ （ｎ＋１） ) to the end of the token history T, and stores the updated token history T in the token storage unit 207. At this time, the receiving unit 203 associates the token history T with the random number r ｕｐｋ and r Σ is also stored in the token storage unit 207.

[0082] On the other hand, in step S306 above, the signature Σ Ｓ If it is determined that the verification is not successful, the receiving unit 203 of the recipient device 20 rejects the payment response received from the payer device 20 (step S308).

[0083] However, the signature Σ in step S305 above Ｓ For example, when the electronic currency is withdrawn, the server of the bank that withdraws the currency may verify each signature Σ Ｓ This also applies to the receiving process in the second and third embodiments described later.

[0084] <Payment Processing> An example of the payment processing in Example 1 will be described with reference to FIG. 9. FIG. 9 is a flowchart showing an example of the payment processing in Example 1. In the following, a certain participant device 20 that executed the above-mentioned receiving processing is referred to as the payer device 20, and another certain participant device 20 is referred to as the receiver device 20. The payment processing will be described in which the payer device 20 pays electronic currency to the receiver device 20. Note that, hereinafter, the token storage unit 207 of the payer device 20 stores token history T={(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )} is assumed to be stored.

[0085] In the first embodiment, the language L of the Σ protocol Σ is defined below.

[0086] L Σ :={(mpk, upk) | ∃(usk, σ ｕｓｋ , r ｕｐｋ ), com(usk,;r ｕｐｋ ) = upk ∧ Verify ｍｐｋ (usk, σ ｕｓｋ )=1} The above definition is that (mpk, upk)∈L Σ For 1 = Σ.Verify(com Σ , res Σ , (mpk, upk)), the participant who generated the temporary public key upk is com(usk,;r ｕｐｋ ) = upk, and Verifyｍｐｋ (usk, σ ｕｓｋ ) = 1 (usk, σ ｕｓｋ , r ｕｐｋ ) is shown to have.

[0087] First, the payment unit 204 of the payer device 20 Σ The payment request including the upk' and com' is received from the receiver device 20 (step S401). Σ ' are the temporary public key and the commit generated in the receiving process executed by the recipient device 20, respectively.

[0088] Next, the payment unit 204 of the payer device 20 receives the challenge chal Σ ←H (T Ｓ ,upk',com Σ ',com Σ ) is generated (step S402). Ｓ =(upk', H １ (T Ｓ （ｎ） ))com Σ =com Σ （ｎ） is.

[0089] Next, the payment unit 204 of the payer device 20 returns a response res Σ ←Σ. res (com Σ , chal Σ , (mpk, upk), (usk, σ ｕｓｋ , r ｕｐｋ ), r Σ ) is generated (step S403). （ｎ） , r ｕｐｋ is the random number used to generate the temporary public key upk, and r Σ is commit com Σ usk is the user private key of the participant (payer) who uses or manages the payer device 20, σ ｕｓｋ is the signature for the user private key usk.

[0090] Then, the payment unit 204 of the payer device 20 calculates (T Ｓ , Σ Ｓ, T) to the receiver device 20 (step S404). Ｓ = (com Σ , res Σ ) Note that this Σ Ｓ (T Ｓ ,upk',com Σ ') as the message.

[0091] <Fraudster Identification Process> An example of fraudster identification process in the first embodiment will be described with reference to FIG. 10. FIG. 10 is a flowchart showing an example of fraudster identification process in the first embodiment. For example, a participant such as a bank can execute the fraudster identification process when withdrawing electronic currency, and identify a fraudster who has made a double payment. In the following, ０ , M ０ ,com Σ０ （ｉ） , res Σ０ （ｉ） ), (x １ , M １ ,com Σ１ （ｊ） , res Σ１ （ｊ） ) is given, it is determined whether or not it corresponds to double spending, and if it corresponds to double spending, the cheater is identified. ０ = (mpk, upk ０ ), x １ = (mpk, upk １ ), M ０ = (T Ｓ，０ , upk ０ ,com Σ０ （ｉ－１） ), M １ = (T Ｓ，１ , upk １ ,com Σ１ （ｊ－１） ) where M ０ ≠M １ Let's say.

[0092] First, the fraudster identification unit 205 of the participant device 20 ０ , x １ , M ０ , M １ ,com Σ０（ｉ） ,com Σ１ （ｊ） , res Σ０ （ｉ） , res Σ１ （ｊ） is input (step S501).

[0093] Next, the fraudster identification unit 205 of the participant device 20 ０ ≠x １ It is determined whether or not this is the case (step S502).

[0094] In step S502 above, x ０ ≠x １ If it is determined that the transaction is a double-spending transaction, the fraudulent identification unit 205 of the participant device 20 terminates the process, assuming that the transaction is not a double-spending transaction.

[0095] On the other hand, in step S502 above, x ０ = x １ If it is determined that the Σ０ （ｉ） and com Σ１ （ｊ） At least one of the following is not valid, or Σ０ （ｉ） ≠com Σ１ （ｊ） It is determined whether or not com Σ０ （ｉ） is valid if 1 = Σ.Verify(com Σ０ （ｉ） , res Σ０ （ｉ） , x ０ ) Similarly, com Σ０ （ｊ） is valid if 1 = Σ.Verify(com Σ１ （ｊ） , res Σ１ （ｊ） , x １ ) means that

[0096] In step S503 above, Σ （ｉ） ０ and com Σ１（ｊ） At least one of the following is not valid, or Σ０ （ｉ） ≠com Σ１ （ｊ） If it is determined that the transaction is a double-spending transaction, the fraudulent identification unit 205 of the participant device 20 terminates the process, assuming that the transaction is not a double-spending transaction.

[0097] On the other hand, in step S503 above, Σ０ （ｉ） and com Σ１ （ｊ） At least one of the following is not valid, or Σ０ （ｉ） ≠com Σ１ （ｊ） If it is not determined that Σ０ （ｉ） and com Σ１ （ｊ） Both are valid and com Σ０ （ｉ） =com Σ１ （ｊ） If so, the fraudster identification unit 205 of the participant device 20 Σ :=com Σ０ （ｉ） =com Σ１ （ｊ） (step S504).

[0098] Next, the fraudster identification unit 205 of the participant device 20 receives the challenge chal Σ０ = H (M ０ ,com Σ ) and Challenge chal Σ１ = H (M １ ,com Σ ) is generated (step S505). ０ ≠M １ Therefore, chal Σ０ ≠chal Σ１ is.

[0099] Then, the fraudster identification unit 205 of the participant device 20 calculates the knowledge w←Ext(x ０ ,com Σ , chal Σ０ , chal Σ１ , res Σ０（ｉ） , res Σ１ （ｊ） ) to generate knowledge w (step S506). As a result, knowledge w=(usk, σ) including the user private key usk of the fraudster is generated. ｕｓｋ , r ｕｐｋ ) is obtained, and the fraudster is identified.

[0100] Summary of Example 1 As described above, in the electronic currency system 1 of Example 1, the recipient of electronic currency generates a temporary public key upk through commitment. As a result, the recipient's public key changes with each payment, making it impossible to identify participants and ensuring anonymity.

[0101] In addition, in the electronic currency system 1 in the first embodiment, the Σ protocol is used to Ｓ and the recipient's temporary public key upk' and commit com Σ ' and sign it as a message Σ Ｓ = (com Σ , res Σ ) so that the next payment of that electronic currency will have a challenge Σ When generating the hash function H, the fourth argument is the commit com Σ ', it is necessary to specify the ', and as a result, it becomes possible to identify a fraudulent payer who has made a double payment. Σ '), (upk'', com Σ ''), each payer will receive the same token T Ｓ If you make a payment with , the token T Ｓ Commit com corresponding to Σ against (chal Σ ', res Σ '), (chal Σ '', res Σ '') is generated. At this time, chal Σ '≠chal Σ ', the soundness of the Σ protocol means that the payer's (usk, σ ｕｓｋ , r ｕｐｋ ) can be calculated in polynomial time by anyone.

[0102] [Example 2] Example 2 will be described below. In Example 1, the user private key usk can be extracted outside the participant device 20, but in Example 2, a case will be described in which the user private key usk cannot be extracted outside the participant device 20. This makes it possible to further improve security while being less efficient than Example 1.

[0103] In the second embodiment, differences from the first embodiment will be mainly described, and descriptions of components that may be the same as those in the first embodiment will be omitted as appropriate.

[0104] <Functional Configuration Example> <Authentication Management Device 10> An example of the functional configuration of the authentication management device 10 in the second embodiment will be described with reference to Fig. 11. Fig. 11 is a diagram illustrating an example of the functional configuration of the authentication management device 10 in the second embodiment.

[0105] 11 , the authentication management device 10 of the second embodiment has a key registration unit 102A instead of the key registration unit 102 of the first embodiment. The key registration unit 102A is realized, for example, by a process in which one or more programs installed in the authentication management device 10 are executed by the processor 18 or the like. Furthermore, the authentication management device 10 of the second embodiment has a registration key storage unit 104A instead of the registration key storage unit 104 of the first embodiment. The registration key storage unit 104A is realized, for example, by a storage area of ​​the auxiliary storage device 17 or the like. However, for example, the registration key storage unit 104A may also be realized by a storage area of ​​a storage device or the like that is communicably connected to the authentication management device 10.

[0106] In response to a registration request from a participant device 20, the key registration unit 102A generates a signature σ for a user public key upk, which is the public key of the participant who uses or manages the participant device 20. ｕｐｋ and generate a signed user public key (upk, σ ｕｐｋ ) is stored in the registration key storage unit 104A. The key registration unit 102A also stores the signed user public key (upk, σ ｕｐｋ The participant device 20 transmits the registration result including the registration information 22 to the participant device 20.

[0107] The registration key storage unit 104A stores the user public key upk of each participant and the corresponding signature σｕｐｋ and (upk, σ ｕｐｋ ) is memorized.

[0108] <<Participant Device 20>> An example of the functional configuration of the participant device 20 in the second embodiment will be described with reference to Fig. 12. Fig. 12 is a diagram illustrating an example of the functional configuration of the participant device 20 in the second embodiment.

[0109] 12 , the participant device 20 in Example 2 includes a user key generation unit 201A, a registration request unit 202A, a receiving unit 203A, a payment unit 204A, and a fraudster identification unit 205A. Each of these units is implemented, for example, by a processor 28 or the like executing one or more programs installed in the participant device 20. The participant device 20 in Example 2 also includes a user key storage unit 206A and a token storage unit 207A. Each of these storage units is implemented, for example, by a storage area of ​​the auxiliary storage device 27 or the like. However, for example, at least one of the user key storage unit 206A and the token storage unit 207A may be implemented by a storage area of ​​a storage device or the like communicatively connected to the participant device 20.

[0110] The user key generation unit 201A generates a user private key usk of the participant who uses or manages the participant device 20, and also generates a user public key upk by commitment. The user public key upk may also be called a "long-term public key" or a "user long-term public key", etc.

[0111] The registration request unit 202A transmits a registration request for the user public key upk to the authentication management device 10. When the registration request unit 202A receives a registration result in response to the registration request, the registration request unit 202A transmits the signed user public key (upk, σ ｕｐｋ ), the user private key usk, and the random number r used in generating the user public key upk. ｕｐｋ The user key information USK including the above is stored in the user key storage unit 206A.

[0112] The receiving unit 203A executes the receiving process when the participant using or managing the participant device 20 is the recipient. More specifically, the receiving unit 203A generates a temporary public key tpk from the user private key usk by the commitment, and also generates a commitment com by the Σ protocol. Σ Generate (tpk, com Σ ) to the payer device 20. When the receiving unit 203A receives a payment response to the payment request, the receiving unit 203A sends the payment request including the signature Σ Ｓ After verifying the token T included in the payment response, Ｓ and signature Σ Ｓ The token history T is updated by the above and the updated token history T is stored in the token storage unit 207A.

[0113] The payment unit 204A executes the payment process when the participant using or managing the participant device 20 is the payer. More specifically, the payment unit 204A executes the payment process when the participant using or managing the participant device 20 is the payer. Σ ') and a new token T added to the token history T of the electronic currency to be paid. Ｓ and the commit com generated when receiving the token history T Σ Using the Σ protocol, challenge chal Σ After generating the response res Σ Then, the payment unit 204A generates the token T Ｓ Signature for Σ Ｓ = (com Σ , res Σ ), and (T Ｓ , Σ Ｓ , T) to the receiver device 20.

[0114] The fraudster identifying unit 205A executes the fraudster identifying process, except that the fraudster identifying unit 205A executes the fraudster identifying process using a temporary public key tpk instead of the temporary public key upk of the first embodiment.

[0115] The user key storage unit 206A stores user key information USK=(upk, usk, r ｕｐｋ , σ ｕｐｋ ) is memorized.

[0116] The token storage unit 207A stores the token history T of the electronic currency held by the participant who uses or manages the participant device 20. The token history T is expressed as T={(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )} where, for i ≥ 1, T Ｓ （ｉ） :=(tpk （ｉ） , H １ (T Ｓ （ｉ－１） )) In addition, TPK （ｉ） is the temporary public key generated by the recipient who receives the token history T when the i-th payment is made.

[0117] <Example of Operation> An example of operation of the electronic currency system 1 in the second embodiment will be described below.

[0118] <<Setup Process of the Authentication Management Device 10>> Since this is the same as in the first embodiment, a description thereof will be omitted.

[0119] <<Setup Process of Participant Device 20>> An example of the setup process of the participant device 20 in Example 2 will be described with reference to Fig. 13. Fig. 13 is a flowchart showing an example of the setup process of the participant device in Example 2. The following describes the setup process of a certain participant device 20. Note that, in the following, it is assumed that the setup process of the authentication management device 10 has been completed.

[0120] First, the user key generation unit 201A of the participant device 20 generates a user private key usk←{0, 1} of the participant who uses or manages the participant device 20. λ is generated (step S601), where λ is a security parameter.

[0121] Next, the user key generation unit 201A of the participant device 20 generates the user public key upk←com(usk;r ｕｐｋ ) is generated (step S602). ｕｐｋ is a random number used in the commitment to generate the user public key upk.

[0122] Next, the registration request unit 202A of the participant device 20 transmits a registration request including the user public key upk to the authentication management device 10 (step S603).

[0123] When the key registration unit 102A of the authentication management device 10 receives a registration request from the participant device 20, the key registration unit 102A generates a signature σ for the user public key upk included in the registration request. ｕｐｋ ←Sign ｍｓｋ (upk) is generated (step S604).

[0124] Next, the key registration unit 102A of the authentication management device 10 registers the signed user public key (upk, σ ｕｐｋ ) is stored in the registration key storage unit 104A (step S605). As a result, the user public key upk of the participant who uses or manages the participant device 20 is registered in the authentication management device 10.

[0125] Next, the key registration unit 102A of the authentication management device 10 registers the signed user public key (upk, σ ｕｐｋ ) is transmitted to the participant device 20 (step S606).

[0126] When the registration request unit 202A of the participant device 20 receives the registration result from the authentication management device 10, the registration request unit 202A of the participant device 20 ｕｐｋ , σ ｕｐｋ ) is stored in the user key storage unit 206A (step S607).

[0127] <Receiving Process> An example of the receiving process in Example 2 will be described with reference to Fig. 14. Fig. 14 is a flowchart showing an example of the receiving process in Example 2. Below, we will describe the receiving process in which a certain participant device 20 is the receiver device 20 and another certain participant device 20 is the payer device 20, and the receiver device 20 receives electronic currency from the payer device 20. It is assumed that the setup process of the receiver device 20 has been completed.

[0128] First, the receiving unit 203A of the receiver device 20 receives (upk, usk, r ｕｐｋ , σ ｕｐｋ )←Parse as USK (step S701).

[0129] Next, the receiving unit 203A of the receiver device 20 receives the temporary public key tpk←com(usk;r ｔｐｋ ) is generated (step S702). ｔｐｋ is a random number used in the commitment to generate the temporary public key tpk.

[0130] Next, the receiving unit 203A of the receiver device 20 Σ ←Σ. com((mpk, tpk), (upk, usk, σ ｕｐｋ , r ｔｐｋ , r ｕｐｋ ) ; r Σ ) is generated (step S703). Σ is a random number used when generating the first message of the Σ protocol.

[0131] Next, the receiving unit 203A of the receiver device 20 receives (tpk, com Σ ) is transmitted to the payer device 20 (step S704).

[0132] Next, the receiving unit 203A of the receiver device 20 Ｓ , Σ Ｓ , T) from the payer device 20 (step S705). Ｓ = (tpk, H １ (T Ｓ （ｎ） )), Σ Ｓ= (com Σ ', res Σ '), T = {(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） ))

[0133] Next, the receiving unit 203A of the receiver device 20 receives the signature Σ Ｓ (Step S706). That is, the receiving unit 203A verifies Σ.Verify(com Σ ', res Σ ', (mpk, tpk （ｎ） )) Signed by Σ Ｓ In Σ.Verify, the signature Σ Ｓ （ｎ） = (com Σ （ｎ） , res Σ （ｎ） ) and chal Σ '=H(T Ｓ ,tpk,com Σ ,com Σ （ｎ） ) Challenge chal Σ ' is generated.

[0134] Next, the receiving unit 203A of the receiver device 20 receives the signature Σ Ｓ It is determined whether the verification has been successful (step S707).

[0135] In step S707 above, the signature Σ Ｓ If it is determined that the verification of the token T is successful, the receiving unit 203A of the receiver device 20 Ｓ and signature Σ Ｓ The receiving unit 203A updates the token history T by the token history T, and stores the updated token history T in the token storage unit 207A (step S708). Ｓ（ｎ＋１） ←T Ｓ , Σ Ｓ （ｎ＋１） ←Σ Ｓ As such, (T Ｓ （ｎ＋１） , Σ Ｓ （ｎ＋１） ) to the end of the token history T, and stores the updated token history T in the token storage unit 207A. At this time, the receiving unit 203A associates the token history T with the random number r ｔｐｋ and r Σ is also stored in the token storage unit 207A.

[0136] On the other hand, in step S707 above, the signature Σ Ｓ If it is determined that the verification is not successful, the receiving unit 203A of the receiver device 20 rejects the payment response received from the payer device 20 (step S709).

[0137] <Payment Processing> An example of the payment processing in the second embodiment will be described with reference to FIG. 15. FIG. 15 is a flowchart showing an example of the payment processing in the second embodiment. In the following, a certain participant device 20 that executed the above-mentioned receiving processing is defined as the payer device 20, and another certain participant device 20 is defined as the receiver device 20. The payment processing will be described in which the payer device 20 pays electronic currency to the receiver device 20. Note that the token storage unit 207A of the payer device 20 stores token history T={(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )} is assumed to be stored.

[0138] In the second embodiment, the language L of the Σ protocol Σ is defined below.

[0139] L Σ :={(mpk, tpk) | ∃(upk, usk, σ ｕｐｋ , r ｔｐｋ, r ｕｐｋ ), com(usk,;r ｔｐｋ )=tpk∧com(usk,;r ｕｐｋ ) = upk ∧ Verify ｍｐｋ (upk, σ ｕｐｋ )=1} The above definition is (mpk, tpk)∈L Σ For 1 = Σ.Verify(com Σ , res Σ , (mpk, tpk)), the participant who generated the temporary public key tpk is com(usk,;r ｔｐｋ ) = tpk, and com(usk,;r ｕｐｋ ) = upk, and Verify ｍｐｋ (upk, σ ｕｐｋ ) = 1 (upk, usk, σ ｕｐｋ , r ｔｐｋ , r ｕｐｋ ) is shown to have.

[0140] First, the payment unit 204A of the payer device 20 calculates (upk, usk, r ｕｐｋ , σ ｕｐｋ )←Parse as USK (step S801).

[0141] Next, the payment unit 204A of the payer device 20 calculates (tpk',com Σ The payment request including tpk' and com' is received from the receiver device 20 (step S802). Σ ' are the temporary public key and the commit generated in the receiving process executed by the recipient device 20, respectively.

[0142] Next, the payment unit 204A of the payer device 20 receives the challenge chal Σ ←H (T Ｓ ,tpk',com Σ ',com Σ ) is generated (step S803). Ｓ =(tpk',H １ (T Ｓ （ｎ） ))com Σ =com Σ （ｎ） is.

[0143] Next, the payment unit 204A of the payer device 20 returns a response res Σ ←Σ. res (com Σ , chal Σ , (mpk, tpk), (upk, usk, σ ｕｐｋ , r ｔｐｋ , r ｕｐｋ ), r Σ ) is generated (step S804). （ｎ） , r ｔｐｋ is a random number used to generate the temporary public key tpk, upk is the user public key of the participant (payer) who uses or manages the payer device 20, σ ｕｐｋ is the signature for the user public key upk.

[0144] Then, the payment unit 204A of the payer device 20 calculates the Ｓ , Σ Ｓ , T) to the receiver device 20 (step S805). Ｓ = (com Σ , res Σ ) is (T Ｓ ,tpk',com Σ ') as the message.

[0145] <<Terrier Identification Processing>> The fraudster identification processing in the second embodiment is ０ = (mpk, tpk ０ ), x １ = (mpk, tpk １ ), M ０ = (T Ｓ，０ , tpk ０ ,com Σ０ （ｉ－１） ), M １ = (T Ｓ，１ , tpk １ ,com Σ１ （ｊ－１） ) is the same as the fraudster identification process in the first embodiment, so the description thereof will be omitted.

[0146] Summary of Second Embodiment As described above, in the electronic currency system 1 according to the second embodiment, the signature σ is applied to the user public key upk instead of the user private key usk. ｕｐｋAfter this, the recipient of the electronic currency generates a temporary public key tpk through the commitment. This makes it impossible to identify the participant, and the user private key usk is not extracted outside the participant device 20. Therefore, while efficiency is lower than in the first embodiment, security can be improved.

[0147] [Example 3] Example 3 will be described below. In Examples 1 and 2, when a double payment is made, it is possible to determine the user private key usk of a fraudster. However, for example, it is also possible to determine the user private key usk of a participant who unintentionally made a double payment, which poses a problem of a lack of protection for such participants. In addition, there is a possibility that a fraudster or a further fraudster who uses the user private key usk of a participant who unintentionally made a double payment may appear. Therefore, in Example 3, a case will be described in which, instead of the user private key usk, when a double payment is made, it is possible to identify the user public key upk, which is public information.

[0148] In the third embodiment, differences from the second embodiment will be mainly described, and descriptions of components that may be the same as those in the second embodiment will be omitted as appropriate.

[0149] <Functional Configuration Example> <Participant Device 20> An example of the functional configuration of the participant device 20 in the third embodiment will be described with reference to Fig. 16. Fig. 16 is a diagram illustrating an example of the functional configuration of the participant device 20 in the third embodiment.

[0150] 16 , the participant device 20 in Example 3 has a user key generation unit 201B, a registration request unit 202B, a receiving unit 203B, and a payment unit 204B. Each of these units is realized, for example, by a process in which one or more programs installed in the participant device 20 are executed by the processor 28 or the like. The participant device 20 in Example 3 also has a user key storage unit 206B. The user key storage unit 206B is realized, for example, by a storage area of ​​the auxiliary storage device 27 or the like. However, the user key storage unit 206B may also be realized, for example, by a storage area of ​​a storage device or the like communicatively connected to the participant device 20.

[0151] The user key generation unit 201B generates a user secret key usk and a user public key upk using a digital signature key generation algorithm Gen.

[0152] The registration request unit 202B transmits a registration request for the user public key upk to the authentication management device 10. When the registration request unit 202B receives a registration result in response to the registration request, the registration request unit 202B transmits the signed user public key (upk, σ ｕｐｋ ) and user secret key usk, and user key information USK containing the user secret key usk is stored in the user key storage unit 206B.

[0153] The receiving unit 203B executes a receiving process when the participant using or managing the participant device 20 is a recipient. More specifically, the receiving unit 203B receives the temporary public key tpk and its signature σ ｔｐｋ and generate a commit com by the Σ protocol. Σ Generate (tpk, com Σ ) to the payer device 20. When the receiving unit 203B receives a payment response to the payment request, the receiving unit 203B sends the payment request including the signature Σ Ｓ After verifying the token T included in the payment response, Ｓ and signature Σ Ｓ The token history T is updated by the above and the updated token history T is stored in the token storage unit 207A.

[0154] The payment unit 204B executes the payment process when the participant using or managing the participant device 20 is the payer. More specifically, the payment unit 204B executes the payment process when the participant using or managing the participant device 20 is the payer. Σ ') and a new token T added to the token history T of the electronic currency to be paid. Ｓ and the commit com generated when receiving the token history T Σ Using the Σ protocol, challenge chal Σ After generating the response res Σ At this time, the payment unit 204B further generates a response res Σ When generating ｔｐｋ , σ ｕｐｋ) and Σ.res gives the response res Σ Then, the payment unit 204B generates the token T Ｓ Signature for Σ Ｓ = (com Σ , res Σ ), and (T Ｓ , Σ Ｓ , T) to the receiver device 20.

[0155] The user key storage unit 206B stores user key information USK=(upk, usk, σ ｕｐｋ ) is memorized.

[0156] <Example of Operation> An example of operation of the electronic currency system 1 in the third embodiment will be described below.

[0157] <<Setup Process of the Authentication Management Device 10>> Since this is the same as in the second embodiment, a description thereof will be omitted.

[0158] <<Setup Process of Participant Device 20>> An example of the setup process of the participant device 20 in Example 3 will be described with reference to Fig. 17. Fig. 17 is a flowchart showing an example of the setup process of the participant device in Example 3. The following describes the setup process of a certain participant device 20. Note that, in the following, it is assumed that the setup process of the authentication management device 10 has been completed.

[0159] First, the user key generation unit 201B of the participant device 20 generates (upk, usk)←Gen(1 ｋ ) to generate a user public key upk and a user secret key usk (step S901), where k is a security parameter.

[0160] Next, the registration request unit 202B of the participant device 20 transmits a registration request including the user public key upk to the authentication management device 10 (step S902).

[0161] When the key registration unit 102A of the authentication management device 10 receives a registration request from the participant device 20, the key registration unit 102A generates a signature σ for the user public key upk included in the registration request. ｕｐｋ ←Sign ｍｓｋ(upk) is generated (step S903).

[0162] Next, the key registration unit 102A of the authentication management device 10 registers the signed user public key (upk, σ ｕｐｋ ) is stored in the registration key storage unit 104A (step S904). As a result, the user public key upk of the participant who uses or manages the participant device 20 is registered in the authentication management device 10.

[0163] Next, the key registration unit 102A of the authentication management device 10 registers the signed user public key (upk, σ ｕｐｋ ) is transmitted to the participant device 20 (step S905).

[0164] When the registration request unit 202B of the participant device 20 receives the registration result from the authentication management device 10, the registration request unit 202B of the participant device 20 sets the user key information USK←(upk, usk, σ ｕｐｋ ) is stored in the user key storage unit 206B (step S906).

[0165] <Receiving Process> An example of the receiving process in Example 3 will be described with reference to Fig. 18. Fig. 18 is a flowchart showing an example of the receiving process in Example 3. Below, we will describe the receiving process in which a certain participant device 20 is the receiver device 20 and another certain participant device 20 is the payer device 20, and the receiver device 20 receives electronic currency from the payer device 20. It is assumed that the setup process of the receiver device 20 has been completed.

[0166] First, the receiving unit 203B of the receiver device 20 calculates (upk, usk, σ ｕｐｋ )←Parse as USK (step S1001).

[0167] Next, the receiving unit 203B of the receiver device 20 receives the temporary public key tpk←{0, 1} λ (step S1002), where λ is a security parameter.

[0168] Next, the receiving unit 203B of the receiver device 20 generates a signature σ for the temporary public key tpk. ｔｐｋ ←Sign ｕｓｋ (tpk) is generated (step S1003).

[0169] Next, the receiving unit 203B of the receiver device 20 Σ ←Σ. com((mpk, tpk), (upk, σ ｔｐｋ , σ ｕｐｋ ) ; r Σ ) is generated (step S1004). Σ is a random number used when generating the first message of the Σ protocol.

[0170] Next, the receiving unit 203B of the receiver device 20 receives (tpk, com Σ ) is transmitted to the payer device 20 (step S1005).

[0171] Next, the receiving unit 203B of the receiver device 20 Ｓ , Σ Ｓ , T) from the payer device 20 (step S1006). Ｓ = (tpk, H １ (T Ｓ （ｎ） )), Σ Ｓ = (com Σ ', res Σ '), T = {(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） ))

[0172] Next, the receiving unit 203B of the receiver device 20 receives the signature Σ Ｓ (Step S1007). That is, the receiving unit 203B verifies Σ.Verify(com Σ ', res Σ ', (mpk, tpk （ｎ） )) Signed by Σ Ｓ In Σ.Verify, the signature Σ Ｓ （ｎ） = (com Σ（ｎ） , res Σ （ｎ） ) and chal Σ '=H(T Ｓ ,tpk,com Σ ,com Σ （ｎ） ) Challenge chal Σ ' is generated.

[0173] Next, the receiving unit 203B of the receiver device 20 receives the signature Σ Ｓ It is determined whether the verification is successful (step S1008).

[0174] In step S1008 above, the signature Σ Ｓ If it is determined that the verification of the token T is successful, the receiving unit 203B of the receiver device 20 Ｓ and signature Σ Ｓ The receiving unit 203B updates the token history T by the token history T, and stores the updated token history T in the token storage unit 207A (step S1009). Ｓ （ｎ＋１） ←T Ｓ , Σ Ｓ （ｎ＋１） ←Σ Ｓ As such, (T Ｓ （ｎ＋１） , Σ Ｓ （ｎ＋１） ) to the end of the token history T, and stores the updated token history T in the token storage unit 207A. At this time, the receiving unit 203B associates the signature σ ｔｐｋ and the random number r Σ is also stored in the token storage unit 207A.

[0175] On the other hand, in step S1008 above, the signature Σ Ｓ If it is determined that the verification is not successful, the receiving unit 203B of the recipient device 20 rejects the payment response received from the payer device 20 (step S1010).

[0176] <Payment Processing> An example of the payment processing in Example 3 will be described with reference to FIG. 19. FIG. 19 is a flowchart showing an example of the payment processing in Example 3. In the following, a certain participant device 20 that executed the above-mentioned receiving processing is defined as the payer device 20, and another certain participant device 20 is defined as the receiver device 20. The payment processing will be described in which the payer device 20 pays electronic currency to the receiver device 20. Note that the token storage unit 207A of the payer device 20 stores token history T={(T Ｓ （０） , Σ Ｓ （０） ), (T Ｓ （１） , Σ Ｓ （１） ), ..., (T Ｓ （ｎ） , Σ Ｓ （ｎ） )} is assumed to be stored.

[0177] Here, in the third embodiment, the language L of the Σ protocol Σ is defined below.

[0178] L Σ :={(mpk, tpk) | ∃(upk, σ ｔｐｋ , σ ｕｐｋ ), Verify ｕｐｋ (tpk, σ ｔｐｋ ) = 1 ∧ Verify ｍｐｋ (upk, σ ｕｐｋ )=1} The above definition is (mpk, tpk)∈L Σ For 1 = Σ.Verify(com Σ , res Σ , (mpk, tpk)), the participant who generated the temporary public key tpk executes Verify ｕｐｋ (tpk, σ ｔｐｋ ) = 1, and Verify ｍｐｋ (upk, σ ｕｐｋ ) = 1 (upk, σ ｔｐｋ , σ ｕｐｋ ) is shown to have.

[0179] First, the payment unit 204B of the payer device 20 calculates (upk, usk, σ ｕｐｋ)←Parse as USK (step S1101).

[0180] Next, the payment unit 204B of the payer device 20 calculates (tpk',com Σ The payment request including tpk' and com' is received from the receiver device 20 (step S1102). Σ ' are the temporary public key and the commit generated in the receiving process executed by the recipient device 20, respectively.

[0181] Next, the payment unit 204B of the payer device 20 receives the challenge chal Σ ←H (T Ｓ ,tpk',com Σ ',com Σ ) is generated (step S1103). Ｓ =(tpk',H １ (T Ｓ （ｎ） ))com Σ =com Σ （ｎ） is.

[0182] Next, the payment unit 204B of the payer device 20 returns a response res Σ ←Σ. res (com Σ , chal Σ , (mpk, tpk), (upk, σ ｔｐｋ , σ ｕｐｋ ), r Σ ) is generated (step S1104). （ｎ） , upk is the user public key of the participant (payer) who uses or manages the payer device 20, σ ｕｐｋ is the signature for the user public key upk.

[0183] Then, the payment unit 204A of the payer device 20 calculates the Ｓ , Σ Ｓ , T) to the receiver device 20 (step S1105). Ｓ = (com Σ , res Σ ) is (T Ｓ ,tpk',com Σ ') as the message.

[0184] <Fraudster Identification Processing> The fraudster identification processing in the third embodiment is the same as that in the second embodiment, and therefore the description thereof will be omitted. Note that in the fraudster identification processing in the third embodiment, when it is determined that a double spend has occurred, knowledge w=(upk, σ ｔｐｋ , σ ｕｐｋ ) is obtained, but the user private key usk of the fraudster is not obtained.

[0185] Summary of Example 3 As described above, in the electronic currency system 1 according to Example 3, the signature σ ｕｐｋ and a signature σ for the temporary public key tpk. ｔｐｋ Then, for (mpk, tpk), (upk, σ ｔｐｋ , σ ｕｐｋ ) is configured. This makes it impossible to identify participants, and when a participant makes a double spend, it becomes possible to identify the participant's user public key upk. On the other hand, unlike in Examples 1 and 2, the user private key usk of the participant who made the double spend cannot be identified, so it is possible, for example, to protect participants who unintentionally made double spends and to prevent the emergence of further fraudsters who misuse the user private key usk of the participant who made the double spend.

[0186] The present invention is not limited to the above-described specifically disclosed embodiments, and various modifications, changes, and combinations with known technologies are possible without departing from the scope of the claims.

[0187] [References] Reference 1: Ivan Damgard, "On Σ-protocols", CPT 2010, v.2.

[0188] 1 Electronic currency system 10 Authentication management device 11 Input device 12 Display device 13 External I / F 13a Recording medium 14 Communication I / F 15 RAM 16 ROM 17 Auxiliary storage device 18 Processor 19 Bus 20 Participant device 21 Input device 22 Display device 23 External I / F 23a Recording medium 24 Communication I / F 25 RAM 26 ROM 27 Auxiliary storage device 28 Processor 29 Bus 30 Communication network 101 Master key generation unit 102, 102A Key registration unit 103 Master key storage unit 104, 104A Registration key storage unit 201, 201A, 201B User key generation unit 202, 202A, 202B Registration request unit 203, 203A, 203B Receiving unit 204, 204A, 204B Payment unit 205, 205A Malicious person identification unit 206, 206A, 206B User key storage unit 207, 207A Token storage unit

Claims

1. An electronic currency system including a plurality of participant devices respectively used by a plurality of participants who are payers or recipients in payment transactions of electronic currency. In a first payment transaction where the participant using the participant device is a recipient, the participant device includes: a first generation unit that generates a first temporary public key which is a temporary public key of the participant in the first payment transaction; a second generation unit that generates a first commitment of a first Σ protocol using information including the first temporary public key as a first problem and information including identification information capable of identifying the participant as a first knowledge; a first transmission unit that transmits the first temporary public key and the first commitment to a first other participant device used by a first other participant who is a payer in the first payment transaction; and a first reception unit that receives information representing the electronic currency to be the payment target in the first payment transaction and a signature using, as a message, the information representing the electronic currency, the first temporary public key, and the first commitment. An electronic currency system having the above components.

2. In a second payment transaction where the participant using the participant device is a payer for the electronic currency received in the first payment transaction, the participant device includes: a second reception unit that receives a second commitment of a second Σ protocol and a second temporary public key which is a temporary public key of the second other participant in the second payment transaction from a second other participant device used by a second other participant who is a recipient in the second payment transaction; and a first transmission unit that transmits information representing the electronic currency to be the payment target in the second payment transaction and a signature using, as a message, the information representing the electronic currency, the second temporary public key, and the second commitment to the second other participant device. The electronic currency system according to claim 1 having the above components.

3. In the second payment transaction, the participant device further includes: a third generation unit that generates a first challenge of the first Σ protocol based on the information representing the electronic currency, the second temporary public key, the second commitment, and the first commitment; and a fourth generation unit that generates a first response of the first Σ protocol based on the first commitment, the first challenge, the first problem, and the first knowledge. The first transmission unit transmits the first commitment and the first response to the second other participant device as the signature. The electronic currency system according to claim 2.

4. The electronic currency system according to any one of claims 1 to 3, wherein the first generation unit generates a commitment of the secret key or the public key of the participant, which is signed by an authentication device that authenticates the participant device, as the first temporary public key.

5. In the first problem, the public key of the authentication device and the first temporary public key are included, and in the first knowledge, the secret key or the public key is included as the identification information. The electronic currency system according to claim 4.

6. The electronic currency system according to claim 5, wherein the participant device further includes a calculation unit that calculates knowledge for the problem by an extractor, with the problem of the Σ protocol, the commitment of the Σ protocol, two different challenges of the Σ protocol, and two responses of the Σ protocol as inputs.

7. A method used in an electronic currency system including a plurality of participant devices respectively used by a plurality of participants who are payers or recipients in payment transactions of electronic currency. In a first payment transaction where the participant using the participant device is a recipient, the participant device: performs a first generation procedure for generating a first temporary public key that is a temporary public key of the participant in the first payment transaction; performs a second generation procedure for generating a first commitment of a first Σ protocol, using information including the first temporary public key as a first problem and information including identification information capable of identifying the participant as a first knowledge; performs a first transmission procedure for transmitting the first temporary public key and the first commitment to a first other participant device used by a first other participant who is the payer in the first payment transaction; and performs a first reception procedure for receiving, from the first other participant device, information representing electronic currency that is the payment target in the first payment transaction and a signature using, as a message, the information representing the electronic currency, the first temporary public key, and the first commitment.

8. A program used in an electronic currency system including a plurality of participant devices respectively used by a plurality of participants who are payers or recipients in payment transactions of electronic currency. In a first payment transaction where the participant using the participant device is a recipient, the program causes the participant device to: perform a first generation procedure for generating a first temporary public key that is a temporary public key of the participant in the first payment transaction; perform a second generation procedure for generating a first commitment of a first Σ protocol, using information including the first temporary public key as a first problem and information including identification information capable of identifying the participant as a first knowledge; perform a first transmission procedure for transmitting the first temporary public key and the first commitment to a first other participant device used by a first other participant who is the payer in the first payment transaction; and perform a first reception procedure for receiving, from the first other participant device, information representing electronic currency that is the payment target in the first payment transaction and a signature using, as a message, the information representing the electronic currency, the first temporary public key, and the first commitment.

Images