Information processing device, information system, information processing method, and program

Abstract

The present invention provides an information processing device in an information system in which information containing a concatenated plurality of data with pairs of public keys and signatures is transmitted and received between information processing devices, the information processing device comprising: a key generation unit configured to generate a new pair of public and private keys and acquire a certificate for the newly generated public key after a certain period has elapsed after the generation of a pair of public and private keys or after the generated public or private keys have been used a certain number of times; and an information distribution unit configured to transmit or receive information containing the newly generated public key.

Description

Information processing device, information system, information processing method, and program

[0001] The present invention relates to an information processing device, an information system, an information processing method, and a program.

[0002] Electronic cash, which is used in electronic currency systems, an example of information systems, has been studied for many years, and many governments are considering electronic currency.

[0003] For example, Patent Document 1 discloses a token-based electronic currency system in which a signature is placed by the issuing bank for each unit of electronic currency, allowing transactions to be completed only between users.

[0004] International Publication No. 2022 / 254624

[0005] In conventional electronic currency systems, currency data including each user's public key is transmitted between users to circulate the currency. However, in conventional technologies, the public key in the currency data corresponds to a pseudonym, and in general, pseudonym-based systems have the problem that the pseudonym may be used to narrow down individuals.

[0006] The above-mentioned problem is not limited to electronic currency systems and can also occur in various information systems. For example, a problem similar to that in the electronic currency system can occur in an information system that runs a PKI (Public Key Infrastructure) application that distributes information using signatures. The information to be distributed is, for example, electronic value, but is not limited to electronic value.

[0007] The present invention has been made in view of the above points, and has as its object to provide a technique for protecting privacy in an information system.

[0008] According to the disclosed technology, there is provided an information processing device in an information system that transmits and receives information consisting of multiple linked data pieces each having a pair of a public key and a signature between information processing devices, the information processing device comprising: a key generation unit configured to generate a new pair of a public key and a private key and obtain a certificate for the newly generated public key after a certain period of time has passed since the generation of the pair of a public key and a private key, or after the generated public key or private key has been used a certain number of times; and an information distribution unit configured to transmit or receive information including the newly generated public key.

[0009] The disclosed technology provides a technology for protecting privacy in an information system.

[0010] 1 is a diagram for explaining issues and solutions regarding privacy protection. A diagram for explaining issues and solutions regarding privacy protection. A diagram for explaining an NNL tree. A diagram for explaining a method of applying an NNL tree to currency in this embodiment. A diagram showing an example of the system configuration of an electronic currency system. A functional configuration diagram of an issuing bank server. A functional configuration diagram of a root certificate authority server. A functional configuration diagram of a financial institution server. A functional configuration diagram of an intermediate certificate authority server. A functional configuration diagram of a user terminal. A functional configuration diagram of a user terminal. A sequence diagram showing an example of the flow of currency issuance processing. A flowchart for explaining an example of the processing procedure for generating a currency ID when issuing currency. A sequence diagram for explaining an example of the flow of a withdrawal processing. A sequence diagram for explaining an example of the processing procedure for currency division processing. A sequence diagram for showing an example of the flow of a payment processing. A sequence diagram for showing an example of the flow of an exchange processing. A sequence diagram for showing an example of the flow of a credit processing. A sequence diagram for showing an example of the flow of a deposit processing. A sequence diagram for showing an example of the flow of a withdrawal processing. A diagram for explaining an MHTree function of a Merkle tree according to the second embodiment. A first diagram for explaining an MHPath function of a Merkle tree according to the second embodiment. FIG. 10 is a diagram for explaining the MHVer function of a Merkle tree according to the second embodiment. FIG. 11 is a diagram illustrating a state where there are eight currencies. FIG. 12 is a diagram illustrating a state where currency additional information including the same signature is added to eight currencies. FIG. 13 is a diagram illustrating an example of the hardware configuration of a computer.

[0011] Hereinafter, an embodiment of the present invention will be described with reference to the drawings. The embodiment described below is merely an example, and the embodiment to which the present invention is applied is not limited to the following embodiment.

[0012] Hereinafter, as an embodiment of the present invention, a technique for realizing privacy protection in a PKI (Public Key Infrastructure) application that uses signatures to distribute information (for example, electronic value) will be described.

[0013] In the following, a technology for privacy protection according to the present invention will be described, taking an electronic currency system as an example of an information system in a PKI (Public Key Infrastructure) application.

[0014] It should be noted that the electronic currency system is merely one example of a technology to which the present invention can be applied. The present invention can also be applied to various information systems other than electronic currency systems. For example, the present invention can also be applied to information systems that run applications such as ticket sales and distribution, intra-company (and inter-company) business flows, and rights transfer.

[0015] (Overview of First Embodiment) The electronic currency system according to the first embodiment is a system for electronic currency issued by a specific issuing bank. It is proposed that the value of the electronic currency is guaranteed to be the same as that of legal tender. Below, an example of electronic currency with the same value as the Japanese yen will be described, but this is not limiting, and electronic currency with the same value as the legal tender of another country may also be used, or electronic currency that does not have to be the same value as legal tender.

[0016] In the electronic currency system according to the first embodiment, a server managed by an issuing bank issues electronic currency (hereinafter simply referred to as currency) with a signature. Transaction history data is managed by a financial institution other than the issuing bank (e.g., a commercial bank). In transactions between users, the users' terminals communicate directly with each other to execute the transaction processing.

[0017] (Outline of First Embodiment: Issues and Solutions Concerning Privacy Protection) Here, issues and solutions concerning privacy protection will be described using Examples 1 to 4.

[0018] <Example 1> In this embodiment, similar to the technology disclosed in Patent Document 1, the current currency owner (=user terminal 30 having pkUn as a public key) basically holds currency data (which may also be called a currency token) as shown in Fig. 1. The currency data is a concatenation of data having pairs of public keys pk and signatures S of each user who has used the currency.

[0019] For example, if n=2, the current currency owner is the person who has withdrawn the currency from the financial institution server 20, which is a server of a commercial bank. The owner of the currency circulating between user terminals may be a store or an individual user who uses the store.

[0020] Here, it is assumed that the current currency holder is an individual user, and the previous currency holder may be a store or an individual user.

[0021] In Example 1, we assume that the store is (semi-)honest and will not publish the store's public key under its real name, which would have a negative impact on the user's privacy. Such a public key may be called a "pseudonym." Note that "(semi-)honest" means either semi-honest or honest.

[0022] On the other hand, it is highly likely that the public key of the financial institution server 20 will be published under the "real name" of the commercial bank. Therefore, the commercial bank used by the withdrawer can be identified from the commercial bank's public key in the currency data shown in Figure 1.

[0023] Furthermore, if the previous currency holder of the current currency holder is a store, the currency data in FIG. 1 reveals only the pseudonym of the store used by the individual user who is the current currency holder.

[0024] In the above scenario, if an individual user uses the same public key for a long period of time, the following problem may occur.

[0025] Transaction histories with multiple stores (pseudonyms) and banks (real names) can be collected as data linked to the individual user's public key (e.g., pkUn in Figure 1). In other words, the store (pseudonym) with which a transaction was conducted using the public key can collect currency data and thereby determine the transaction history. If the data collected in this way is considered a data set related to an individual, it can be said that the issuing bank holds the entire database (the entire data set) and the market holds a partial database (a partial data set).

[0026] 1 is just an example, and the same problem may occur at stores (Uk+1 and Uk-1) where a general individual user (Uk) makes a transaction. This also applies to Examples 2 to 4 described below.

[0027] To avoid the above problems, in this embodiment, the public keys of stores (and individual users) are pseudonyms, and the public keys of stores and individual users are updated periodically. This reduces the possibility that the public keys in the currency data can be used to narrow down individuals (equivalent to the concept of pseudo-IDs), thereby improving privacy protection.

[0028] As an example of the periodic update, an individual user (and a store) may "(2) use the same public key only once." In other words, after the user terminal 30 uses a public key (or a private key that is a pair of the public key) only once, it no longer uses the public key, but generates a new public key and uses the new public key next time.

[0029] If an individual user uses the same public key only once, the public key cannot be used to narrow down the individual. However, if the same public key can only be used once, the operational burden (certificate issuance, etc.) will increase.

[0030] <Example 2> Figure 2 shows an example of currency data when multiple currency data are used in the same transaction. Here, an individual user with public key pkUn is the current currency owner and the owner of two currencies. The next payment destination store for individual user Un is Un+1.

[0031] In Example 2, we also assume that the store is (semi-)honest and will not disclose the store's public key under its real name, which would have a negative impact on the user's privacy. In this case, if the previous owner of the current currency is a store, then, as in Example 1, the currency data in Figure 2 will reveal only the pseudonym of the store used by the individual user who is the current currency owner.

[0032] In the above scenario, in both cases of "(1) when an individual user uses the same public key for a long period of time" and "(2) when an individual user uses the same public key only once," the next payment destination store Un+1 can simultaneously determine the multiple stores (pseudonyms) with which transactions were made using the public key (pkUn) from the multiple currency data of the target transaction. In particular, in the case of (1), there is a possibility that a frequently used store may collect information about other stores (pseudonyms) used by the individual user.

[0033] As in Example 1, in this embodiment, the public keys of the store (and individual user) are pseudonyms, and the public keys of the individual user and the store are updated periodically, thereby reducing the possibility that currency data can be used to narrow down individuals (equivalent to the concept of a pseudo-ID).

[0034] <Example 3> In Example 3, similar to Example 1, the current currency owner (=user terminal 30 having pkUn as the public key) holds the currency data shown in FIG.

[0035] As in Example 1, it is assumed that the current currency holder is an individual user. The previous currency holder may be a store or an individual user.

[0036] In Example 3, the previous currency owner is a store. The store may mistakenly publish a public key under its "real name." The store may also mistakenly keep its public key the same for a long period of time.

[0037] If the above error occurs, the currency data in FIG. 1 will reveal the real name of the store used by the individual user who is the current currency owner.

[0038] In the above scenario, if an individual user uses the same public key for a long period of time, the following problem may occur.

[0039] Transaction histories of multiple stores (real names) and banks (real names) can be collected as data linked to the individual user's public key (e.g., pkUn in Figure 1). In other words, the store (real name) where a transaction was conducted using the public key can determine the transaction history by collecting currency data. If the data collected in this way is considered a dataset related to an individual, it can be said that the issuing bank holds the entire database (full dataset) and the market holds a partial database (partial dataset). In particular, in the case of (1), this dataset may be used to narrow down the individual (equivalent to the concept of pseudo-ID).

[0040] To avoid the above problems, in this embodiment, the public keys of stores (and individual users) are pseudonyms, and the public keys of stores and individual users are updated periodically. This reduces the possibility that currency data can be used to narrow down individuals (equivalent to the concept of pseudo-IDs).

[0041] As an example of the periodic update, an individual user (and a store) may use the same public key only once. In other words, after the user terminal 30 uses the public key (or the private key that is a pair of the public key) only once, it no longer uses the public key, but generates a new public key and uses the new public key next time.

[0042] In the case of "(2) when an individual user uses the same public key only once," there is no possibility that the public key can be used to narrow down the individual. However, if the same public key can only be used once, the operational burden (issuing certificates, etc.) will increase.

[0043] <Example 4> In Example 4, similar to Example 2, multiple currency data are used in the same transaction, as shown in Figure 2. Here, an individual user with public key pkUn is the current currency owner and the owner of two currencies. The next payment destination store for individual user Un is assumed to be Un+1.

[0044] In Example 4, the previous multiple currency owners are multiple stores. The multiple stores may mistakenly publish public keys under their "real names." Also, the multiple stores may mistakenly keep the same public keys for a long period of time.

[0045] If the above error occurs, the currency data in FIG. 2 will simultaneously reveal the real names of multiple stores used by the individual user who is the current currency owner.

[0046] In the above scenario, in both cases of "(1) when an individual user uses the same public key for a long period of time" and "(2) when an individual user uses the same public key only once," the next payment destination store Un+1 can simultaneously determine the multiple stores (real names) with which transactions were made using that public key (pkUn) from the multi-currency data of the target transaction. In particular, in the case of (1), there is a possibility that frequently used stores may collect information about other stores (real names) used by the individual user. In both cases (1) and (2), there is a possibility that this information may be used to narrow down individuals, although there are differences in risk (this is equivalent to the concept of pseudo-IDs).

[0047] Therefore, in this embodiment, the public keys of stores and individual users are pseudonyms, and the public keys of individual users and stores are updated regularly, thereby reducing the possibility that currency data can be used to narrow down individuals (equivalent to the concept of pseudo-ID).

[0048] <Summary of Privacy Protection> As explained above using Examples 1 to 4, in this embodiment, in order to protect the privacy of individual users who are customers of stores, the public keys of the individual users and the stores are pseudonyms and restrictions are placed on repeated use.

[0049] Specifically, the usage period of each public key for individual users and stores is set to a short enough period that it does not cause operational problems. Furthermore, especially for stores, updates to public keys can be forced using secure hardware (TEE, SE) on the terminal. In particularly sensitive stores, it is desirable to limit public keys to one-time use. Note that using secure hardware to update public keys and limiting use to one-time use may also be applied to individual users.

[0050] Furthermore, in this embodiment, as will be described later, the NNL tree method (variable face value method) is used to reduce the number of currency notes used in one transaction. This makes it difficult for currency notes received from multiple stores to be mixed into a single transaction, thereby reducing the amount of store information linked to an individual user's public key. As a result, privacy protection can be improved.

[0051] (Outline of the first embodiment: NNL tree method) The above-mentioned NNL tree method will be described. In this embodiment, the amount of currency is expressed as a set of the smallest unit (for example, 1 yen). Decomposition of currency into units smaller than the smallest unit is not permitted. If the smallest unit is 1 yen, a fixed denomination method in 1 yen units is adopted, thereby (effectively) realizing a variable denomination method (token division).

[0052] To guarantee the authenticity of each currency, a signature from the issuing bank's server is affixed to each currency as described above. If currency is represented by a set of 1 yen coins, for example, 10,000 signatures must be issued when issuing 10,000 yen. In this case, the cost of generating and verifying signatures at the time of issuance, payment, etc. becomes unrealistic. Therefore, in this embodiment, the amount of one currency is represented by a single tree structure with the smallest unit (1 yen) as a leaf node, so that signatures are generated and verified only once at the time of issuance, payment, etc.

[0053] In this embodiment, an NNL tree (reference document [1]) is used as such a tree structure, and a signature is issued only once, and the data size is compressed nonlinearly.

[0054] 3 is a diagram for explaining an NNL tree. In FIG. 1, a pseudo-random number generator G: {0, 1} generates a random number twice as long as an input random number for an ID (an n-bit random number in FIG. 3) as a seed. ｎ →{0, 1} ２ｎ In this example, a 2n-bit ID is generated by applying a pseudo-random number generator G to the first n bits and the last n bits of the 2n bits to generate further 2n-bit random numbers, resulting in a total of four n-bit IDs (random numbers).

[0055] According to the NNL tree, anyone can find the four IDs as long as they know the seed, so the information of the four IDs (4n bits) can be transmitted using only n bits of information (seed).

[0056] Although FIG. 3 shows an example in which there are four leaf nodes, the depth of the NNL tree is not limited to a specific one.

[0057] FIG. 4 is a diagram for explaining a method of applying an NNL tree to currencies in this embodiment.

[0058] As described above, in this embodiment, currency amounts are represented by an NNL tree. Specifically, a leaf node of an NNL tree corresponds to the smallest unit (e.g., 1 yen), and the number of leaf nodes belonging to a certain NNL tree determines the currency amount corresponding to the NNL tree. However, assuming that the NNL tree is a binary tree, this allows only amounts in powers of 2 to be expressed. Therefore, the leaf node corresponding to a currency can be specified. Specifically, by making it possible to specify information indicating a range of leaf nodes corresponding to a currency among all leaf nodes of the NNL tree, it is possible to express that the currency corresponding to the NNL tree is the number of all leaf nodes included in the range × 1 yen. In this embodiment, an example is shown in which the start point and end point of the range are used as information indicating such a range. The start point refers to the leaf node that is the start position of the range. The end point refers to the leaf node that is the end position of the range. It is assumed that either the start point or the end point is the leaf node at the end (first or last) in the order of the leaf nodes. However, the information indicating the range is not limited to the start point and the end point. For example, all leaf nodes belonging to the range may be specified, or the start point and the size of the range (i.e., the amount) or the end point and the size of the range may be specified.

[0059] For example, in a binary NNL tree with a depth of 10, the number of leaf nodes is 1024. To represent 1000 yen, for example, the start point can be set to 1 and the end point to 1000.

[0060] As described above, anyone can derive all leaf nodes of an NNL tree if they know the seed and depth. Therefore, in this embodiment, the amount of one currency is expressed by a set of four parameters.

[0061] {Seed of NNL tree, depth of the NNL tree, start point, end point} Hereinafter, a set of these four parameters will be referred to as a "currency ID."

[0062] A signature for a currency (e.g., a signature by an issuer or a divider) is realized by signing in units of seeds in the NNL tree corresponding to the currency. Therefore, the number of signatures can be set per currency (NNL tree) rather than per minimum unit of currency (e.g., 1 yen).

[0063] For example, if the start point of the NNL tree in FIG. 4 is ID1 and the end point is ID8, the NNL tree represents 8 yen. If it is desired to divide 4 yen from ID1 to ID4 from this 8 yen, the ID (random number) corresponding to node n1, which is the ancestor node of all ID1 to ID4, becomes the root node of the subtree (NNL tree) corresponding to the 4 yen after division. Therefore, in this case, the currency ID of the 4 yen currency after division will be as follows: {01110...1, 2, ID1, ID4} By calculating the seed of the root node of the subtree after division, it is possible to reduce the number of times to calculate the random number corresponding to each node of the subtree. In this case, the currency issued by the issuing bank (T, described later) ０ ) can be traced based on the signature history.

[0064] However, the root node of the original NNL tree may be used as the root node of the NNL tree after division. In this case, the currency ID of the 4 yen currency after division will be as follows: {01010...1, 3, ID1, ID4} In this case, the currency issued by the issuing bank (T ０ ) and verifying it is computationally efficient.

[0065] 4, for convenience, random numbers corresponding to each node are shown, but the random numbers corresponding to each node do not need to be managed until the currency (NNL tree) is divided. In other words, when dividing, the random number of the seed after division may be calculated from the seed of the NNL tree before division.

[0066] Furthermore, the NNL tree is not limited to a binary tree, but may be a 2-, 5-, or 10-ary tree. By repeating 2-branch / 5-branch..., it is possible to generate an NNL tree whose number of leaf nodes exactly matches the amount of cash in everyday life, such as 5,000 yen / 1,000 yen. In this case, at the 5-branch point, the pseudo-random number generator G ５ : {0, 1} ｎ→{0, 1} ５ｎ At the 10-branch point, a pseudorandom number generator G １０ : {0, 1} ｎ →{0, 1} １０ｎ Just use

[0067] The configuration and operation of the first embodiment will be described below.

[0068] (Details of the First Embodiment) Figure 5 is a diagram showing an example of the system configuration of an electronic currency system. The electronic currency system 1 according to the first embodiment includes an issuing bank server 10, a root certificate authority server 11, a financial institution server 20, an intermediate certificate authority server 25, and a user terminal 30. These devices are connected to each other so as to be able to communicate with each other via a communication network such as the Internet.

[0069] The issuing bank server 10 is an information processing device managed by the issuing bank that issues the currency. The issuing bank server 10 adds signature data to message data indicating the issuance of currency and transmits the message data to the financial institution server 20. The issuing bank server 10 also has a function to accept a refund request from the financial institution server 20.

[0070] The root certification authority server 11 is an information processing device that has the function of a root certification authority in cryptographic communication. The root certification authority server 11 may be realized by the same hardware as the issuing bank server 10, and is assumed to be managed by the issuing bank, but is not limited to this.

[0071] As a preparation step for issuing currency, the root certification authority server 11 generates a root certification key, issues a root certificate, and transmits it to the intermediate certification authority server 12. The root certification authority server 11 also authenticates each financial institution, generates financial institution public key certificate issuance information, and transmits the generated financial institution public key certificate issuance information to the issuing bank server 10.

[0072] The financial institution server 20 is an information processing device managed by a financial institution (for example, a commercial bank). The financial institution server 20 is authenticated by the root certification authority server 11 and receives a request for currency issuance from the issuing bank server 10.

[0073] The financial institution server 20 also accepts transaction requests such as withdrawals, currency exchange, deposits, and credit from the user terminal 30. Furthermore, the financial institution server 20 requests the issuing bank server 10 to make a refund.

[0074] In the following description, when distinguishing between the financial institution servers 20, the financial institution servers 20 will be referred to as financial institution server 20-1, financial institution server 20-2, and so on.

[0075] The intermediate certification authority server 25 is an information processing device that has the function of an intermediate certification authority in cryptographic communication. The intermediate certification authority server 25 may be realized by the same hardware as the financial institution server 20, and is assumed to be managed by the financial institution, but is not limited to this.

[0076] As a preparation step for issuing the currency, the intermediate certificate authority server 25 generates an intermediate authentication key, issues an intermediate certificate, and transmits it to the user terminal 30. The intermediate certificate authority server 25 also authenticates each user and generates user public key certificate issuance information.

[0077] In the following description, when distinguishing between the intermediate certification authority servers 25, the intermediate certification authority servers 25 will be referred to as intermediate certification authority server 25-1, intermediate certification authority server 25-2, and so on.

[0078] The user terminal 30 is an information processing device used by users (individual consumers, stores, etc.) who use currency. Before starting a transaction, the user terminal 30 is authenticated by the intermediate certificate authority server 25. The user terminal 30 also requests transactions such as withdrawals, currency exchanges, deposits, and credit from the financial institution server 20.

[0079] In the following description, when distinguishing between the user terminals 30, the user terminals 30 will be referred to as user terminal 30-1, user terminal 30-2, and so on.

[0080] A user terminal 30 (e.g., user terminal 30-1) requests payment from another user terminal 30 (e.g., user terminal 30-2) or accepts a payment request. Here, a payment request means a request to accept execution of a "payment" transaction in which a user pays a counterparty, but does not mean a request from the counterparty to make payment to the user.

[0081] (Example of Functional Configuration of Each Device According to First Embodiment) Next, an example of the functional configuration of each device according to the first embodiment will be described.

[0082] 6 is a functional block diagram of the issuing bank server 10. The issuing bank server 10 includes a currency issuance key generation unit 101, a currency issuance certificate issuance unit 102, a financial institution public key certificate issuance information acquisition unit 103, a currency issuing unit 104, a refund acceptance unit 105, a currency issuance key storage unit 106, and a refunded currency storage unit 107.

[0083] The currency issuance key generation unit 101 generates cryptographic key data (hereinafter referred to as a currency issuance key) for verifying the validity of message data indicating the issuance of currency (hereinafter referred to as a currency issuance message). The currency issuance key includes a private key and a public key.

[0084] The currency issuance certificate issuing unit 102 generates data indicating a certificate for certifying the public key of the currency issuance key (hereinafter referred to as the currency issuance certificate), and transmits the generated currency issuance certificate to each financial institution server 20 and each user terminal 30.

[0085] The financial institution public key certificate issuance information acquisition unit 103 acquires financial institution public key certificate issuance information from the root certification authority server 11. The financial institution public key certificate issuance information will be described later.

[0086] The currency issuing unit 104 generates a currency issuance message using the currency issuance key and the financial institution public key certificate issuance information, and transmits the generated currency issuance message to the financial institution server 20 .

[0087] The refund receiving unit 105 receives refunds from the financial institution server 20 and stores the refunded currency in the refunded currency storage unit 107. A refund is a transaction in which each financial institution deposits currency that it will not use for the time being with the issuing bank and returns it to circulation.

[0088] The currency issuing key storage unit 106 stores the currency issuing key generated by the currency issuing key generation unit 101 .

[0089] The refunded currency storage unit 107 stores the currency for which the refund acceptance unit 105 has accepted the refund (hereinafter referred to as the refunded currency).

[0090] 7 is a functional configuration diagram of the root certification authority server 11. The root certification authority server 11 includes a root certification key generation unit 111, a root certificate issuance unit 112, a financial institution authentication unit 113, a financial institution public key certificate issuance information transmission unit 114, a root certification key storage unit 115, and a financial institution public key certificate issuance information storage unit 116.

[0091] The root certification key generator 111 generates encryption key data (hereinafter referred to as a root certification key) for verifying the legitimacy of the root certification authority. The root certification key includes a private key and a public key.

[0092] The root certificate issuance unit 112 issues certificate data (hereinafter referred to as a root certificate) for verifying the legitimacy of certificate data (hereinafter referred to as an intermediate certificate) for verifying the legitimacy of an intermediate certification authority, and transmits the certificate data to each intermediate certification authority server 25.

[0093] The financial institution authentication unit 113 receives encryption key data (hereinafter referred to as the financial institution key) for verifying the legitimacy of each financial institution from the financial institution server 20 and accepts an authentication request. The financial institution authentication unit 113 then generates data indicating a certificate for certifying the public key of the financial institution key (hereinafter referred to as the financial institution public key certificate) and transmits the generated financial institution public key certificate to the financial institution server 20 that requested authentication. Furthermore, the financial institution authentication unit 113 generates information indicating the issuance of the financial institution public key certificate (hereinafter referred to as the financial institution public key certificate issuance information).

[0094] Financial institution public key certificate issuance information transmitter 114 transmits the generated financial institution public key certificate issuance information to issuing bank server 10. Note that if issuing bank server 10 and root certification authority server 11 are realized by the same hardware, financial institution public key certificate issuance information transmitter 114 is not necessary.

[0095] The root authentication key storage unit 115 stores the root authentication key generated by the root authentication key generation unit 111 .

[0096] The financial institution public key certificate issuance information storage unit 116 stores the financial institution public key certificate issuance information generated by the financial institution authentication unit 113 .

[0097] 8 is a functional block diagram of the financial institution server 20. The financial institution server 20 includes a currency issuance certificate issuance acceptance unit 201, a financial institution key generation unit 202, a financial institution authentication request unit 203, a currency issuance acceptance unit 204, a withdrawal acceptance unit 205, an update processing unit 206, a currency exchange / deposit acceptance unit 207, a payment request unit 208, a payment acceptance unit 209, a credit acceptance unit 210, a refund request unit 211, a currency issuance certificate storage unit 212, a financial institution key storage unit 213, a financial institution public key certificate storage unit 214, an unused currency storage unit 215, a currency in use storage unit 216, an updated currency storage unit 217, and a used currency storage unit 218.

[0098] The currency issuance certificate issuance reception unit 201 receives a request for the issuance of a currency issuance certificate from the issuing bank server 10 .

[0099] The financial institution key generation unit 202 generates a financial institution key, which includes a private key and a public key.

[0100] The financial institution authentication request unit 203 transmits the financial institution key to the root certification authority server 11 to request authentication of the financial institution, and receives a financial institution public key certificate from the root certification authority server 11 .

[0101] The currency issuance reception unit 204 receives a currency issuance request from the issuing bank server 10. Specifically, the currency issuance reception unit 204 receives a currency issuance message from the issuing bank server 10 and verifies the signature of the received currency issuance message using the public key included in the currency issuance certificate.

[0102] The withdrawal acceptance unit 205 accepts a withdrawal request from the user terminal 30 and transmits currency to the user terminal 30 .

[0103] The update processing unit 206 updates used currency (hereinafter referred to as used currency) as necessary in response to a withdrawal request from the user terminal 30. Specifically, the update processing unit 206 deletes information (currency additional information) added to the used currency. The currency additional information is added by a payment transaction, which will be described later. The withdrawal acceptance unit 205 transmits unused currency (hereinafter referred to as unused currency) or the currency updated by the update processing unit 206 to the user terminal 30.

[0104] The currency exchange / deposit reception unit 207 accepts requests for currency exchange or deposits from the user terminal 30. Specifically, when the currency exchange / deposit reception unit 207 accepts a request for currency exchange from the user terminal 30, the payment reception unit 209 accepts payment of the amount to be exchanged, and the payment request unit 208 requests multiple payments that total the amount to be exchanged. Also, when the currency exchange / deposit reception unit 207 accepts a request for deposit, the payment reception unit 209 accepts payment of the amount to be deposited.

[0105] The credit acceptance unit 210 accepts a credit request by receiving currency from the user terminal 30. The credit acceptance unit 210 determines whether the currency is a currency in use (hereinafter referred to as a currency in use) and transmits the determination result to the user terminal 30.

[0106] The refund request unit 211 sends the currency to the issuing bank server 10 to request a refund.

[0107] The currency issuance certificate storage unit 212 stores the currency issuance certificate whose issuance has been accepted by the currency issuance certificate issuance acceptance unit 201 .

[0108] The financial institution key storage unit 213 stores the financial institution key generated by the financial institution key generation unit 202 .

[0109] The financial institution public key certificate storage unit 214 stores the financial institution public key certificate that the financial institution authentication request unit 203 receives from the root certification authority server 11 .

[0110] The unused currency storage unit 215 stores the currency accepted for issuance by the currency issuance acceptance unit 204 as unused currency.

[0111] The currency in use storage unit 216 stores the currency for which the withdrawal acceptance unit 205 accepts a withdrawal as a currency in use.

[0112] The updated currency storage unit 217 stores the currency updated by the update processing unit 206 (hereinafter referred to as updated currency) in the state before the update.

[0113] The used currency storage unit 218 stores currencies that have been used but are not currently in use. Specifically, the used currency storage unit 218 stores, as used currency, the currency that is received when the exchange / deposit receiving unit 207 receives a request for exchange or deposit and the payment receiving unit 209 receives payment.

[0114] 9 is a functional block diagram of the intermediate certification authority server 25. The intermediate certification authority server 25 includes an intermediate authentication key generation unit 251, an intermediate certificate issuance unit 252, a user authentication unit 253, an intermediate authentication key storage unit 254, and a user public key certificate issuance information storage unit 255.

[0115] The intermediate authentication key generation unit 251 generates encryption key data (hereinafter referred to as intermediate authentication key) for verifying the legitimacy of the intermediate certificate authority. The intermediate authentication key includes a private key and a public key.

[0116] The intermediate certificate issuing unit 252 issues an intermediate certificate and transmits it to each user terminal 30 .

[0117] The user authentication unit 253 receives encryption key data (hereinafter referred to as user key) for verifying the legitimacy of each user from the user terminal 30 and accepts an authentication request. The user authentication unit 253 then generates data indicating a certificate for certifying the public key of the user key (hereinafter referred to as user public key certificate) and transmits the generated user public key certificate to the user terminal 30 that requested authentication. Furthermore, the user authentication unit 253 generates information indicating the issuance of the user public key certificate (hereinafter referred to as user public key certificate issuance information).

[0118] The intermediate authentication key storage unit 254 stores the intermediate authentication key generated by the intermediate authentication key generation unit 251 .

[0119] The user public key certificate issuance information storage unit 255 stores the user public key certificate issuance information generated by the user authentication unit 253 .

[0120] 10 is a functional configuration diagram of user terminal 30. User terminal 30 includes currency issuance certificate issuance acceptance unit 301, intermediate certificate issuance acceptance unit 302, user key generation unit 303, user authentication request unit 304, withdrawal request unit 305, payment request unit 306, payment acceptance unit 307, exchange / deposit request unit 308, credit request unit 309, currency issuance certificate storage unit 310, intermediate certificate storage unit 311, user key storage unit 312, user public key certificate storage unit 313, and user currency storage unit 314.

[0121] The currency issuance certificate issuance acceptance unit 301 accepts the issuance of a currency issuance certificate from the issuing bank server 10 .

[0122] The intermediate certificate issuance acceptance unit 302 accepts the issuance of an intermediate certificate from the intermediate certificate authority server 25 .

[0123] The user key generation unit 303 generates a user key, which includes a private key and a public key.

[0124] The user authentication request unit 304 transmits the user key to the intermediate certification authority server 25 to request authentication of the user, and receives the user public key certificate from the intermediate certification authority server 25 .

[0125] The withdrawal request unit 305 specifies the face value and requests a withdrawal from the financial institution server 20. The withdrawal request unit 305 receives the withdrawn currency from the financial institution server 20.

[0126] The payment request unit 306 transmits the currency to be paid and requests payment from the financial institution server 20 or another user terminal 30 .

[0127] The payment acceptance unit 307 receives the currency to be paid and accepts the payment from the financial institution server 20 or another user terminal 30 .

[0128] The exchange / deposit request unit 308 requests exchange or deposit from the financial institution server 20. Specifically, when the exchange / deposit request unit 308 requests exchange and the financial institution server 20 accepts the request, the payment request unit 306 transmits the currency of the face value to be exchanged and requests payment from the financial institution server 20, and the payment acceptance unit 307 accepts from the financial institution server 20 a plurality of payments whose total is the face value to be exchanged. Furthermore, when the exchange / deposit request unit 308 requests a deposit and the financial institution server 20 accepts the request, the payment request unit 306 transmits the currency to be deposited and requests payment from the financial institution server 20.

[0129] The credit request unit 309 transmits currency to request credit from the financial institution server 20 and receives the credit result.

[0130] The currency issuance certificate storage unit 310 stores the currency issuance certificate whose issuance has been accepted by the currency issuance certificate issuance acceptance unit 301 .

[0131] The intermediate certificate storage unit 311 stores the intermediate certificate whose issuance has been accepted by the intermediate certificate issuance acceptance unit 302 .

[0132] The user key storage unit 312 stores the user key generated by the user key generation unit 303 .

[0133] The user public key certificate storage unit 313 stores the user public key certificate received by the user authentication request unit 304 .

[0134] The user currency storage unit 314 stores the currency currently used by the user. Specifically, the user currency storage unit 314 stores the currency that the withdrawal request unit 305 received from the financial institution server 20 and the currency that the payment acceptance unit 307 received from the financial institution server 20 or another user terminal 30.

[0135] (Configuration Example of User Terminal 30 Involving Public Key Update) As described above, in this embodiment, whether the user terminal 30 belongs to an individual user or a store, the public key, which is a pseudonym, is updated, for example, periodically. In this embodiment, this update is performed on secure hardware (TEE, SE, etc.). An example configuration of the user terminal 30 from this perspective is shown in FIG. 11.

[0136] It should be noted that a device that uses a periodically updated public key to execute the circulation of electronic currency is not limited to a device called a "user terminal." A device that uses a periodically updated public key to execute the circulation of electronic currency may also be called a "currency processing device." For this reason, the term "currency processing device" is written in parentheses in FIG. 11.

[0137] As mentioned above, the scope of application of the privacy protection technology according to the present invention is not limited to electronic currency systems but also includes various information systems. From this perspective, a "currency processing device" may also be called an "information processing device."

[0138] 11, the user terminal 30 includes a secure processing unit 330 and a currency distribution unit 340. The secure processing unit 330 includes a key generation unit 320. The currency distribution unit 340 may also be called an information distribution unit 340.

[0139] The secure processing unit 330 is, for example, a Secure Element or TrustZone (registered trademark), but is not limited to a specific type. Information (tables, programs, data, etc.) held in the secure processing unit 330 cannot be tampered with from the outside.

[0140] The secure processing unit 330 may be called secure hardware. The secure processing unit 330 itself can be realized using various conventional technologies.

[0141] For example, in the user terminal 30, by completely separating the processing unit (including a CPU, memory, etc.) that requires secure processing from the general processing unit (including a CPU, memory, etc.) in hardware, the processing unit that requires secure processing can be realized as the secure processing unit 330.

[0142] Furthermore, although a processing unit requiring secure processing and a general processing unit share some hardware, the processing unit that realizes secure processing in software may be called the secure processing unit 330 .

[0143] The key generation unit 320 generates a pair of a public key and a private key, and also updates the pair of a public key and a private key. Note that "updating a pair of a public key and a private key" means generating a new pair of a public key and a private key after generating a pair of a public key and a private key. The public key generated by the key generation unit 320 is a pseudonym, not a real name indicating the user (individual user, store, etc.) of the user terminal 30.

[0144] More specifically, the key generation unit 320 includes a user key generation unit 303, a user authentication request unit 304, a user key storage unit 312, and a user public key certificate storage unit 313, and when generating a pair of a public key and a private key, performs the user key generation (S108), user authentication request (S109), and acquisition of a user public key certificate (S111) in the sequence shown in Fig. 12, which will be described later. The key generation unit 320 may also perform a signature using the private key at the time of issuance, payment, etc.

[0145] For example, the key generation unit 320 generates a new public key and private key pair (i.e., updates the existing pair) immediately after a predetermined period of time has elapsed since the previous pair was generated. After the update, the new public key and private key pair is used.

[0146] Furthermore, for example, after generating a certain public key / private key pair, the key generation unit 320 generates a new public key / private key pair (i.e., updates the pair) immediately after the generated public key or private key has been used a predetermined number of times. After the update, the new public key / private key pair is used.

[0147] "The generated public key or private key is used" means that the private key is used for signing, the public key (or data including the public key) is sent to another device, and so on.

[0148] The period is set to be short enough to cause no operational problems. The number of times is set to be small enough to cause no operational problems. For example, the number of times may be "1."

[0149] Furthermore, the key generation unit 320 (or the currency circulation unit 340) may use a one-time signature to sign using a private key at the time of payment, etc. This "one-time" means that one private key can sign only one piece of data. The key generation unit 320 updates the pair of public key and private key immediately after executing the one-time signature. In other words, by using a one-time signature, it is possible to forcibly update the keys. Furthermore, fraud can be identified when the second signature is executed.

[0150] The currency circulation unit 340 has a function of executing circulation of currency data including the public key generated by the key generation unit 312. The currency data is data in which multiple data pieces each having a pair of a public key and a signature are linked together. The currency circulation unit 340 can also execute circulation of currency using a variable denomination method using an NNL tree.

[0151] More specifically, the currency circulation unit 340 includes a currency issuance certificate issuance acceptance unit 301, an intermediate certificate issuance acceptance unit 302, a withdrawal request unit 305, a payment request unit 306, a payment acceptance unit 307, an exchange / deposit request unit 308, a credit request unit 309, a currency issuance certificate memory unit 310, an intermediate certificate memory unit 311, and a user currency memory unit 314.

[0152] Note that the functional units included within the secure processing unit 330 and the functional units located outside the secure processing unit 330 are not limited to the above example. For example, as described above, the key generation unit 320 of the secure processing unit 330 may perform the signature process using a private key. Also, for example, all of the components shown in Fig. 10 may be included in the secure processing unit 330. In other words, the currency circulation unit 340 in Fig. 11 may be included in the secure processing unit 330.

[0153] (Operation of the Electronic Currency System According to the First Embodiment) Next, the operation of the electronic currency system 1 according to the first embodiment will be described. ０ , each financial institution B ｉ (B ０ , B １ , ...), root certification authority A ０ , each intermediate certification authority A ｉ (A０ , A １ , ...), each user is a U ｊ (U ０ , U １ The concept will be explained using symbols such as , ....

[0154] 12 is a sequence diagram showing an example of the flow of currency issuing processing. The currency issuing processing is started periodically or in response to an operation by a person in charge.

[0155] The currency issuing key generation unit 101 of the issuing bank server 10 generates a currency issuing key (step S101). Specifically, the currency issuing key generation unit 101 generates a currency issuing key pair (secret key skB ０ｖｙ and the public key pkB ０ｖｙ ) to generate the

[0156] Then, the currency issuance certificate issuing unit 102 issues the public key pkB ０ｖｙ Certificate of issuance of currency CERT (pkB) ０ｖｙ ) to each financial institution server 20 (step S102), and then to each user terminal 30 (step S103). The currency issuance certificate issuance acceptance unit 201 of each financial institution server 20 sends the currency issuance certificate CERT(pkB ０ｖｙ ) and stores it in the currency issuance certificate storage unit 212. In addition, the currency issuance certificate issuance reception unit 301 of each user terminal 30 receives the currency issuance certificate CERT(pkB ０ｖｙ ) and stores it in the currency issuance certificate storage unit 310.

[0157] The issuance amount v is a multiple of the smallest unit (for example, 1 yen). For example, when issuing currency of 10,000 yen in 2021, the currency issuance certificate issuing unit 102 issues a currency issuance certificate CERT(pkB ０（１００００円）（２０２１年） ) to each financial institution server 20 and each user terminal 30.

[0158] The currency issuance certificate issuing unit 102 issues the currency issuance certificate CERT(pkB ０ｖｙ) does not have to be sent directly to each financial institution server 20 and each user terminal 30, but may be uploaded to a server device or the like that is publicly available on a communication network, and then downloaded to each financial institution server 20 and each user terminal 30.

[0159] Next, the root authentication key generation unit 111 of the root authentication authority server 11 generates a root authentication key (step S104). ０ and the public key pkA ０ Next, the root certificate issuing unit 112 generates the private key skA. ０ and sign it as root certificate Auth(pkA ０ ) and transmits it to each financial institution server 20 (step S105).

[0160] The root certificate issuing unit 112 directly issues the root certificate Auth(pkA ０ ) does not have to be transmitted to each financial institution server 20, but may be uploaded to a server device or the like that is publicly available on a communication network and then downloaded to each financial institution server 20.

[0161] Next, the intermediate authentication key generation unit 251 of the intermediate authentication authority server 25 generates an intermediate authentication key (step S106). ｉ and the public key pkA ｉ Includes.

[0162] Next, the intermediate certificate issuing unit 252 issues the private key skA ｉ and the root certificate Auth(pkA ０ ) to authenticate the intermediate certificate Auth(pkA ｉ , pkA ０ ) is generated. ｉ , pkA ０ ) is Auth(pkA ｉ Then, the intermediate certificate issuance unit 252 generates the intermediate certificate Auth(pkA ｉ ) to each user terminal 30 (step S107). The intermediate certificate issuance acceptance unit 302 of each user terminal 30 transmits the intermediate certificate Auth(pkA ｉ) and stores it in the intermediate certificate storage unit 311.

[0163] The intermediate certificate issuing unit 252 directly issues the intermediate certificate Auth(pkA ｉ ) does not have to be transmitted to each user terminal 30, but may be uploaded to a server device or the like that is publicly available on a communication network, and then downloaded to each user terminal 30.

[0164] Next, the user key generation unit 303 of the user terminal 30 generates a user key (step S108). ｊ and the public key pkU ｊ Next, the user authentication request unit 304 receives the public key pkU ｊ to request user authentication from the intermediate certification authority server 25 (step S109).

[0165] The user authentication unit 253 of the intermediate certificate authority server 25 authenticates the root certificate Auth(pkA ０ ) and intermediate certificate Auth(pkA ｉ ) to obtain the user public key certificate Auth(pkU ｊ , pkA ｉ , pkA ０ ) is generated (step S110). Hereinafter, the user public key certificate Auth(pkU ｊ , pkA ｉ , pkA ０ ) is Auth(pkU ｊ The user authentication unit 253 generates the user public key certificate Auth(pkU ｊ ) to the user terminal 30 (step S111). ｊ and the public key pkU ｊ and the user public key certificate Auth(pkU ｊ ) is held.

[0166] Furthermore, the user authentication unit 253 receives user public key certificate issuance information (U ｊ , pkU ｊ , Auth(pkU ｊ )) and store it in the user public key certificate issuance information storage unit 255. ｊ, pkU ｊ , Auth(pkU ｊ )) is the personal information of the user ｊ Contains:

[0167] Next, the financial institution key generation unit 202 of the financial institution server 20 generates a financial institution key (step S112). ｉ and the public key pkB ｉ Next, the financial institution authentication request unit 203 receives the public key pkB ｉ to request financial institution authentication from the root certification authority server 11 (step S113).

[0168] The financial institution authentication unit 113 of the root certificate authority server 11 receives the root certificate Auth(pkA ０ ) to obtain the financial institution public key certificate Auth(pkB ｉ , pkA ０ ) is generated (step S114). ｉ , pkA ０ ) is Auth(pkB ｉ The financial institution authentication unit 113 generates the financial institution public key certificate Auth(pkB ｉ ) to the financial institution server 20 (step S115). ｉ and the public key pkB ｉ and financial institution public key certificate Auth(pkB ｉ ) is held.

[0169] Furthermore, the financial institution authentication unit 113 receives financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) is generated and stored in the financial institution public key certificate issuance information storage unit 116. ｉ , pkB ｉ , Auth(pkB ｉ )) is the institution information B about financial institutions ｉ Then, the financial institution public key certificate issuance information sending unit 114 sends the financial institution public key certificate issuance information (B ｉ , pkB ｉ, Auth(pkB ｉ )) is sent to the issuing bank server 10 (step S116).

[0170] The financial institution public key certificate issuance information acquisition unit 103 of the issuing bank server 10 acquires the financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) and stores it in the financial institution public key certificate issuance information storage unit 116.

[0171] The order of the processes from step S108 to step S111 and the processes from step S112 to step S116 is merely an example, and may be reversed. The processes from step S108 to step S111 are executed individually by each user terminal 30. The processes from step S112 to step S116 are executed individually by each financial institution server 20.

[0172] In addition, the user terminal 30 may execute the processes from step S108 to step S111 multiple times to add a user key. As described above, the user terminal 30 executes the processes from step S108 to step S111 when updating the public key and private key after a predetermined period (or number of times) has expired.

[0173] Next, the currency issuing unit 104 of the issuing bank server 10 issues the financial institution public key certificate issuance information (B ｉ , pkB ｉ , Auth(pkB ｉ )) and the currency ID based on the issued amount v. ０ , Issue year y, Financial institution B ｉ A currency issuance message (id ０ , y, B ｉ , pkB ｉ ) (step S117). The structure of the currency ID is as explained in FIG. 4, and the method of generating the currency ID will be described later. Here, the currency issuing unit 104 generates the private key skB of the currency issuing key stored in the currency issuing key storage unit 106. ０ｖｙ Using (id ０, y, B ｉ , pkB ｉ The currency issuing unit 104 signs the signature S ０ The currency issuance message (id ０ , y, B ｉ , pkB ｉ ) to the financial institution server 20 (step S118). As will be apparent from the following description, the currency issuance message is used to generate the currency to be issued. Therefore, generating the currency issuance message essentially corresponds to issuing the currency.

[0174] The currency issuance acceptance unit 204 of the financial institution server 20 issues the signature S ０ The currency issuance message (id ０ , y, B ｉ , pkB ｉ ) and stores the currency issuance certificate CERT(pkB ０ｖｙ ) public key pkB ０ｖｙ Use the signature S ０ Then, the currency issuance acceptance unit 204 verifies the currency T ０ :=(id ０ , y, B ｉ , pkB ｉ , S ０ ) is generated and stored in the unused currency storage unit 215.

[0175] The generation of the currency ID in the generation of the currency issuance message in step S117 will be described.

[0176] FIG. 13 is a flowchart illustrating an example of a processing procedure for generating a currency ID when issuing currency.

[0177] In step S121, the currency issuing unit 104 calculates the depth of the smallest NNL tree that includes leaf nodes equal to or greater than the number corresponding to the issuance amount v. Calculating this depth essentially corresponds to generating the structure of the NNL tree. Leaf nodes equal to or greater than the number corresponding to the issuance amount v refer to leaf nodes whose number can represent the issuance amount v, and refer to leaf nodes whose number is equal to or greater than the value obtained by dividing the issuance amount v by the smallest unit (e.g., 1 yen). If the smallest unit is 1 yen and v = 8 yen, eight leaf nodes are required. If the NNL tree is a binary tree, the depth of a binary tree that can include eight leaf nodes is 3 or greater. Therefore, 3, the smallest value among values ​​equal to or greater than 3, becomes the depth of the NNL tree.

[0178] Next, the currency issuing unit 104 generates a random number to be used as a seed for the NNL tree (S122).

[0179] Next, the currency issuing unit 104 determines the start point and end point of a leaf node corresponding to the issuance amount v among the leaf nodes of the NNL tree (S123). The start point and end point are determined so that one of the start point and end point is a leaf node at the end of the NNL tree, and the set of consecutive leaf nodes from the start point to the end point matches the issuance amount v. Note that the values ​​of the start point and end point may be expressed by values ​​indicating the order in the leaf nodes of the NNL tree. In other words, random numbers corresponding to the start point and end point in the NNL tree do not need to be calculated.

[0180] Next, the currency issuing unit 104 generates a set of {Seed, depth, start point, end point} as a currency ID (S124).

[0181] FIG. 14 is a sequence diagram showing an example of the flow of a withdrawal process. ｊ The process is started in response to an operation instructing withdrawal of the card.

[0182] The withdrawal request unit 305 of the user terminal 30 receives the denomination information indicating the denomination v of the withdrawal and the public key pkU of the user key stored in the user key storage unit 312. ｊ and requests the financial institution server 20 to withdraw the money (step S201).

[0183] The withdrawal acceptance unit 205 of the financial institution server 20 accepts the withdrawal (step S202). Specifically, the withdrawal acceptance unit 205 receives unused currency T ０ and obtain the currency additional information T １ :=(id １ , pkU ｊ , S １ ) added to the currency in use (T １ , T ０ ) and stored in the currency-in-use storage unit 216. １ is the private key skB of the financial institution key ｉ (id １ , pkU ｊ , T ０ ) is a signature for id １ is the currency in use (T １ , T ０ Currency ID of the currency to be transferred, based on the face value of the currency T ０ If id matches the value v, １ The value of is the currency T ０ id, which is the currency ID of ０ Also, multiple currencies T ０ If the set of currencies T ０ Currency (T １ , T ０ ) can be generated. １ ID １ The value of the corresponding id １ It can be the same as above.

[0184] On the other hand, currency T ０ If the face value of v exceeds the face value of v, or if multiple currencies T ０ If the set of currency T exceeds the face value v, the withdrawal acceptance unit 205 ０ Part of the currency (T １ , T ０ For example, if the face value v is 1000 yen and the currency T ０ is 5,000 yen, the withdrawal acceptance unit 205 ０ Divide 1000 yen from the amount and make 1000 yen currency (T １ , T ０) is generated. For example, if the face value v is 7000 yen, ０ is 5,000 yen, the withdrawal acceptance unit 205 ０ Divide 2000 yen from one of the two and get 2000 yen currency (T １ , T ０ ) to generate the currency T ０ The division of the currency T ０ Contains id ０ This is realized by dividing the NNL tree as follows: ∑ ...

[0185] In this way, each time currency is transferred by withdrawal, payment, etc., currency additional information signed by the transfer source is cumulatively added to the currency. Therefore, the currency additional information can be said to be information indicating the history of currency transfers.

[0186] Next, the withdrawal acceptance unit 205 receives the current currency (T １ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the current currency (T １ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) and verify the currency in use (T １ , T ０ ) is stored in the user currency storage unit 314. １ , T ０ ) may be called unused currency.

[0187] In step S202, the withdrawal acceptance unit 205 may use used currency stored in the used currency storage unit 218 instead of unused currency stored in the unused currency storage unit 215, as necessary. In this case, the update processing unit 206 updates the used currency to a currency from which the currency additional information has been deleted. The withdrawal acceptance unit 205 determines whether to use used currency in accordance with predetermined conditions. For example, the withdrawal acceptance unit 205 may use used currency when the amount of data of used currency reaches or exceeds a threshold.

[0188] For example, the withdrawal acceptance unit 205 receives the used currency (T ｎ , ..., T ０ ) is used for withdrawal, the update processing unit 206 updates the currency before the update (T ｎ , ..., T ０ ) in the updated currency storage unit 217. Then, the update processing unit 206 stores the used currency (T ｎ , ..., T ０ ) and currency additional information (T ｎ , ..., T １ ) has been removed from the currency T ０ Then, the withdrawal acceptance unit 205 updates the updated currency T ０ Currency information added to T ｎ＋１ :=(id ｎ＋１ , pkU ｊ , S ｎ＋１ ) added to the currency in use (T ｎ＋１ , T ０ ) is stored in the currency in use storage unit 216. ｎ＋１ The value (content) of T ｎ The currency ID may be the same as that included in

[0189] Next, the withdrawal acceptance unit 205 receives the current currency (T ｎ＋１ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the current currency (T ｎ＋１ , T ０ ) currency data and financial institution public key certificate Auth(pkB ｉ) and verify the currency in use (T ｎ＋１ , T ０ ) is stored in the user currency storage unit 314.

[0190] The update processing unit 206 may also update a currency that has already been updated one or more times. In this case, the update processing unit 206 updates the currency (T ｎ , ...T １ , T ０ ) to the currency before this update (T ｎ＋ｋ , ..., T ｎ＋１ , T ０ ) combined currency (T ｎ＋ｋ , ..., T １ , T ０ ) is stored in the updated currency storage unit 217.

[0191] The currency division process executed when currency division is necessary in step S202 will be described in detail below with reference to a flowchart of FIG.

[0192] In step S211, the withdrawal receiving unit 205 calculates the depth of the smallest NNL tree (hereinafter referred to as the "destination NNL tree") that contains leaf nodes in a number equal to or greater than the withdrawal denomination v. The method for calculating the depth is the same as in step S121 of FIG.

[0193] Next, the withdrawal acceptance unit 205 determines a node to be the root node of the split NNL tree from among the nodes of the NNL tree (hereinafter referred to as the "original NNL tree") that serves as the currency ID of the currency to be split (S212). Here, the original NNL tree is a subtree of the original NNL tree. Since the depth of the original NNL tree has been calculated, it is possible to identify which layer of the original NNL tree the root node of the split NNL tree belongs to. The withdrawal acceptance unit 205 determines the node located at the end of the layer (the ancestor of the starting point of the original NNL tree) as the root node of the split NNL tree. For example, if the split described in FIG. 4 is performed, node N2 in FIG. 4 is determined to be the root node of the split NNL tree.

[0194] Next, the withdrawal acceptance unit 205 calculates a random number corresponding to the root node (i.e., the seed of the NNL tree to be split) based on the seed of the original NNL tree (S213). Specifically, as described in Figure 3, the seed of the NNL tree to be split can be calculated by recursively applying the pseudo-random number generator G to the seed of the original NNL tree.

[0195] Next, the withdrawal reception unit 205 determines the start and end points of the leaf nodes of the NNL tree to be split, which correspond to the face value v (S214). The method for determining such leaf nodes may be the same as the method described in step S123 of Figure 13.

[0196] Next, the withdrawal acceptance unit 205 transfers the set of {Seed of the NNL tree to be divided, depth of the NNL tree to be divided, start point, end point} to the currency ID of the currency to be divided (i.e., the currency additional information T １ :=(id １ , pkU ｊ , S １ ) id １ (S215).

[0197] Next, the withdrawal acceptance unit 205 receives the currency from which the money is to be divided (the T ０ ) corresponds to the balance (amount minus face value v), the next leaf node that is the end point of the currency to be divided is identified in the original NNL tree (S215).

[0198] Next, the withdrawal acceptance unit 205 associates {Seed of the original NNL tree, depth of the original NNL tree, the next leaf node, and end point of the original NNL tree} with the original currency as a temporary currency ID (S217). This temporary currency ID is used as the currency ID of the currency additional information when the remaining amount of the original currency is transferred by withdrawal, payment, etc.

[0199] FIG. 16 is a sequence diagram showing an example of the flow of payment processing (transmission processing from the remitter to the recipient) according to the first embodiment. ｊ User U on the receiving side ｋ It is initiated in response to an operation instructing payment to.

[0200] The user terminal 30-1 is a user U ｊ The user terminal 30-2 is operated by the user U ｋ The payment request unit 306 of the user terminal 30-1 receives a payment amount v or more in a currency (T ｎ－１ , ..., T ０ ) from the currency T ０ And, T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ), and the user public key certificate Auth(pkU ｊ ) to request payment from the user terminal 30-2 (step S301). ０ is the currency (T ｎ－１ , ..., T ０ It does not represent the current face value of the currency (T ｎ－１ , ..., T ０ )'s current face value is T ｎ－１ ID ｎ－１ It can be derived from the start and end points of the NNL tree as:

[0201] The payment acceptance unit 307 of the user terminal 30-2 accepts the payment (step S302). ０ And, T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ) S ｎ－１ and the user public key certificate Auth(pkU ｊ ) is verified. Here, the payment acceptance unit 307 verifies the signature data included in the currency when verifying the currency. For example, the payment acceptance unit 307 verifies the signature data included in the currency. ０ :=(id ０ , y, B ｉ , pkB ｉ , S ０ ) signature S ０ In addition, the payment acceptance unit 307 verifies T ｎ－１ = (id ｎ－１ , pkU ｊ , S ｎ－１ ) S ｎ－１ wo pkUｊ Verify using:

[0202] Next, the payment acceptance unit 307 receives the public key pkU of the user key stored in the user key storage unit 312 of the user terminal 30-2. ｋ The payment request unit 306 of the user terminal 30-1 sends the id as a currency ID to the user terminal 30-1 (step S303). ｎ Generate an id ｎ and the received public key pkU ｋ and currency data (e.g., T ｎ－１ , or T ｎ－１ The information including the hash value of the user key skU is stored in the user key storage unit 312 of the user terminal 30-1. ｊ Sign using ｎ ) and calculate the currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ ) is generated (step S304). The currency additional information may be called currency data. ｎ is the currency that will be generated (T ｎ , ..., T ０ ) is a currency ID based on the face value of the currency (T ｎ－１ , ..., T ０ ) matches the payment amount v, then id ｎ The value of is the currency (T ｎ－１ , ..., T ０ ) T ｎ－１ id, which is the currency ID of ｎ－１ It can be the same as multiple currencies (T ｎ－１ , ..., T ０ ) matches the payment amount v, the payment request component 306 ｎ－１ , ..., T ０ ) for each currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ In this case, the id of each Tn ｎ The value of the corresponding id ｎ－１ The same as the currency (T ｎ , ..., T ０) is the currency (T ｎ－１ , ..., T ０ ) is generated every

[0203] On the other hand, currency (T ｎ－１ , ..., T ０ ) exceeds the payment amount v, or multiple currencies (T ｎ－１ , ..., T ０ ) ０ If the set of ｎ－１ , ..., T ０ ) and divide it into id ｎ That is, in this case, the id ｎ is the currency (T ｎ－１ , ..., T ０ ) in ｎ－１ id, which is the currency ID of ｎ－１ The NNL tree {Seed, depth, start point, end point} of the NNL tree obtained by dividing the payment amount v by the payment request unit 306 using the NNL tree as the division source. The processing procedure for executing such division is as explained in FIG. 15. That is, in step S304, the payment request unit 306 executes the processing procedure of FIG. 15 to obtain id ｎ Generate.

[0204] The payment request unit 306 receives the currency additional information (T ｎ－１ , ..., T １ ) and the generated currency additional information T ｎ :=(id ｎ , pkU ｋ , S ｎ ) and currency additional information (T ｎ , ..., T １ ) to the user terminal 30-2 (step S305).

[0205] The payment acceptance unit 307 of the user terminal 30-2 receives the currency additional information (T ｎ , ..., T １ Specifically, the payment acceptance unit 307 verifies the public key pkU ｊ Using S ｎThe payment acceptance unit 307 may verify each signature data included in the currency additional information. For example, the payment acceptance unit 307 verifies the currency additional information T ｎ :=(id ｎ , pkU ｊ , S ｎ ) signature S ｎ The payment acceptance unit 307 verifies the received currency T ０ Currency information added to ｎ , ..., T １ ) added to the currency (T ｎ , ..., T ０ ) is stored in the user currency storage unit 314 of the user terminal 30-2.

[0206] FIG. 17 is a sequence diagram showing an example of the flow of a currency exchange process. ｊ The process is initiated in response to an operation instructing the exchange of currency.

[0207] The exchange / deposit request unit 308 of the user terminal 30 receives face value information indicating the face value v of the exchange and the public key pkU of the user key stored in the user key storage unit 312. ｊ and requests the financial institution server 20 to exchange money (step S401).

[0208] The exchange / deposit acceptance unit 207 of the financial institution server 20 accepts the exchange (step S402). The exchange / deposit acceptance unit 207 transmits exchange acceptance information indicating the acceptance of the exchange to the user terminal 30 (step S403).

[0209] When the exchange / deposit request unit 308 of the user terminal 30 receives the exchange acceptance information, the payment request unit 306 requests payment from the financial institution server 20 according to the payment process shown in FIG. 16 (step S404).

[0210] The payment request unit 208 of the financial institution server 20 calculates the amount v that totals up to the exchange amount v. １ , ..., v ｘ When exchanging to v １ , ..., v ｘ For each of the above, payment is requested from the user terminal 30 in accordance with the payment process shown in FIG. 16 (steps S405-1, S405-2).

[0211] FIG. 18 is a sequence diagram showing an example of the flow of the credit processing. ｊ The process is initiated in response to an operation instructing the credit of the customer.

[0212] The credit request unit 309 of the user terminal 30 receives the currency T whose availability is to be confirmed. ０ The credit acceptance unit 210 of the financial institution server 20 then accepts the credit request (step S502). ０ is searched from the currency in use storage unit 216, and T ０ Records containing, for example, (T １ , T ０ ) exists, the credit result indicating the credit success ack is transmitted to the user terminal 30 (step S503).

[0213] FIG. 19 is a sequence diagram showing an example of the flow of a deposit process. ｊ The deposit is initiated in response to an operation instructing the deposit of

[0214] The exchange / deposit request unit 308 of the user terminal 30 receives face value information indicating the face value v of the deposit and the public key pkU of the user key stored in the user key storage unit 312. ｊ and requests the financial institution server 20 to exchange money (step S601).

[0215] The exchange and deposit acceptance unit 207 of the financial institution server 20 accepts the deposit (step S602). The exchange and deposit acceptance unit 207 transmits deposit acceptance information indicating the acceptance of the deposit to the user terminal 30 (step S603).

[0216] When the exchange / deposit request unit 308 of the user terminal 30 receives the deposit acceptance information, the payment request unit 306 requests payment from the financial institution server 20 according to the payment process shown in FIG. 13 (step S604).

[0217] FIG. 20 is a sequence diagram showing an example of the flow of the refund process. ｉ It is initiated in response to an operation instructing the withdrawal of

[0218] The refund request unit 211 of the financial institution server 20 transmits the currency data to be refunded and requests a refund from the issuing bank server 10 (step S701). The currency data to be refunded may be unused currency or used currency. When refunding unused currency, the refund request unit 211 sends the unused currency T ０ from the unused currency storage unit 215 and transmits it to the issuing bank server 10.

[0219] In addition, when refunding used currency, the refund request unit 211 returns the used currency (T ｎ , ..., T ０ ) is extracted from the used currency storage unit 218 and transmitted to the issuing bank server 10. ｍ , ..., T ｋ＋１ , T ０ ) has been updated, the refund request unit 211 retrieves the pre-update currency additional information (T ｋ , ..., T １ ) and read out the used currency (T ｍ , ..., T ｋ＋１ , T ０ ) and combine it with the combined currency (T ｍ , ..., T ０ ) is sent to the issuing bank server 10.

[0220] The refund acceptance unit 105 of the issuing bank server 10 accepts the refund (step S702). Specifically, the refund acceptance unit 105 stores the received currency data in the refunded currency storage unit 107. At this time, the refund acceptance unit 105 may verify the validity of the currency for which the refund has been accepted by verifying the signature included in each currency additional information. For example, when the currency additional information T ｎ The signature S contained in ｎ is the currency additional information T ｎ－１ It can be verified using the public key contained in

[0221] (Effects of the First Embodiment) As described above, according to the first embodiment, it is possible to suppress the disclosure of information relating to privacy that may arise from currency data (currency tokens, signature chains).

[0222] Specifically, by restricting the use of the public keys of each store and individual user (for example, limiting use to one time or a small number of times), it is possible to prevent narrowing down individuals using pseudonyms (public keys) across multiple transactions. Also, individual users can prevent their transaction history from being revealed to their counterparty stores.

[0223] In addition, by adopting an NNL tree, the number of currencies used in one transaction can be reduced, and as a result, it is possible to prevent individuals from being narrowed down by pseudonyms (public keys) assigned to multiple currency data within the same transaction.

[0224] Furthermore, by adopting the NNL tree, it is possible to efficiently realize a variable denomination system. Specifically, while the minimum unit of currency is fixed, it is possible to issue currency in multiples of the minimum unit, making it possible to sign and verify in currency units rather than in units of the minimum unit. Furthermore, by adopting the NNL tree system, it is possible to reduce the number of hash operations.

[0225] Second Embodiment Next, a second embodiment will be described. In the second embodiment, differences from the first embodiment will be described. Points not specifically mentioned in the second embodiment may be the same as those in the first embodiment.

[0226] In the first embodiment, when currency is transferred by withdrawal, payment, etc., verification must be performed on a currency-by-currency basis. Therefore, for example, if a user who has two 2,000 yen currency wishes to pay 3,000 yen, they can pay two currencies: one 2,000 yen currency and the other 1,000 yen currency divided from the 2,000 yen currency. In this case, however, the payer must generate a signature for each currency, and the payment recipient must verify each currency. The greater the number of currencies traded, the greater the burden of such signatures and verifications. In the second embodiment, a method for reducing this burden is disclosed.

[0227] The second embodiment differs from the first embodiment in that a hash tree of currencies is generated and the root of the hash tree is signed to sign all of the target currencies together. In the following description of the second embodiment, components having the same functional configuration as those in the first embodiment are assigned the same reference numerals as those used in the description of the first embodiment, and descriptions thereof will be omitted.

[0228] (Basic Technology Used in the Second Embodiment) First, the basic technology used in this embodiment will be described. In this embodiment, four functions MHTree, MHPath, and MHVer that utilize a hash tree called a Merkle tree (Reference [2]) are used.

[0229] 21 is a diagram for explaining the MHTree function of a Merkle tree according to the second embodiment. The MHTree function is a function that generates a hash tree from a data set.

[0230] Specifically, the MHTree function is a function that inputs a dataset D and outputs a hash tree L={(leaf_id, leaf_val)}, which is a binary tree generated by associating the hash value of each piece of data that makes up D with a leaf node. Here, the vertex h is called the root. Hereinafter, it will be described as MHTree(D)->L. Note that FIG. 21 shows a dataset where n=6. The value of each leaf node is the hash value of the data that corresponds to that leaf node. The seventh and eighth leaf nodes are complemented with "00" to enable the construction of a binary tree.

[0231] 22 is a first diagram illustrating the MHPath function of a Merkle tree according to the second embodiment. The MHPath function is a function that generates a path required to authenticate a partial data set.

[0232] Specifically, the MHPath function is a function that inputs a partial data set D' to be authenticated (in the case of FIG. 22, D'={d0, d4, d5}) and outputs the authentication path AP (h001, h01, h11 in FIG. 19) and route h required for that authentication. Hereinafter, it is written as MHPath(D', L)->(AP, h).

[0233] 23 is a diagram illustrating the MHVer function of a Merkle tree according to the second embodiment. The MHVer function is a function that performs verification using an authentication path of a partial data set.

[0234] Specifically, the MHVer function is a function that verifies sub-data D' (D' = {d0, d4, d5} in the case of FIG. 23) from the path AP (h001, h01, h11 in FIG. 23) required for authentication and the route h. Hereinafter, it is written as MHver(AP, h, D') -> T or F. The MHver function outputs T if the verification is successful (if D' is correct), and outputs F if the verification fails (if D' is incorrect). D' being correct means that none of the data belonging to D' has been tampered with.

[0235] (Example of Operation of Electronic Currency System According to Second Embodiment) Here, in step S202 of FIG. 14, a set T of multiple currencies that matches the face value v is selected. ０ :=(T ０ _t):=((id ０ _t, y_t, B ｉ , pkB ｉ , S ０ _t), t = 1, ..., s, Σv_t = v). Note that v_t is T ０ The t-th currency T ０ For example, if each v_t is 10,000 yen and a withdrawal of 80,000 yen is accepted, then s = 8. ０ 15 shows a state in which there are eight T_t. For example, if there is no 10,000 yen x 8 currency, such as if there is only 100,000 yen currency in the unused currency storage unit 215 of the financial institution server 20, the withdrawal acceptance unit 205 can divide the existing 100,000 yen into eight 10,000 yen coins by executing the process of FIG. 15. In the second embodiment, each T ０ _t is not limited to a currency immediately after issuance, but may be a currency that has been transferred after issuance (i.e., currency additional information has been added). In this case, it may be a currency that has been divided (i.e., the NNL tree of the currency ID has been divided) during the transfer process.

[0236] The withdrawal acceptance unit 205 of the financial institution server 20 calculates the hash tree L １ =MHTree({T ０ _t}{t=1,...,s}) and generate a private key skB ｉ Using the hash tree L １ The hash value RH (RootHash) of the root node and pkU ｊ Signature S for the set １ That is, a hash tree L １ For that leaf node, T ０ Each T constituting ０ The withdrawal receiving unit 205 generates a hash tree by assigning T ０ For each _t, ０ Currency additional information T for _t １ _t:=(id １ _t, pkU ｊ ,RH,AP_t,S １ ) to add the currency in use (T １ _t, T ０ _t) is generated and stored in the currency-in-use storage unit 216. Here, AP_t is the MHPath(T ０ _t, L １ ) -> (AP_t, RH) is the path required for authenticating the RH. １ The value of _t is the corresponding id ０ This state is shown in Figure 25. １ The signature that _t contains is the same as S １ Below, we can see that the currency (T １ _t, T ０ _t) set (here, 8 sets) １ , T ０ ) should be written.

[0237] Next, the withdrawal acceptance unit 205 receives the current currency set (T １ , T ０ ) currency dataset and financial institution public key certificate Auth(pkB ｉ ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 transmits the in-use currency set (T １ , T ０) currency dataset and financial institution public key certificate Auth(pkB ｉ ) and verify the currency set in use (T １ , T ０ ) is stored in the user currency storage unit 314. At this time, the withdrawal request unit 305 stores the currency set (T １ , T ０ Regarding the verification of (T １ , T ０ ) one of the currencies (T １ _t, T ０ Specifically, it is necessary to verify only one of T １ MHver(AP_t, RH, T ０ ) is T, and １ _t contains S １ The withdrawal request unit 305 verifies the other T １ For _t, the T that was the subject of verification １ Same as _t １ You just need to make sure it includes.

[0238] The user of the user terminal 30 withdraws the currency set (T １ , T ０ ) that constituted each (T １ _t, T ０ _t) can be used individually (separately). １ _t indicates the history of the currency owner (circulation process) in the same way as the currency additional information in the first embodiment, except that it includes RH and AP_t to reduce the signing and verification costs of the currency set, and the authenticity of each currency is guaranteed individually.

[0239] The above-described processing is also executed in steps S304 and S305 in FIG. 16 when a payment is made in a set of multiple coins.

[0240] It is also executed in the process of FIG. 16 called from FIG. 17 (when exchanging money) and FIG. 19 (when depositing money).

[0241] 16 can be applied to all other phases (such as when issuing or redeeming). For example, when redeeming, it is possible to efficiently transfer the currency to be redeemed in one lump sum.

[0242] As described above, in addition to the effects described in the first embodiment, the second embodiment has the effect of reducing the signature costs and verification costs when transferring multiple currencies.

[0243] (Hardware Configuration Example) An example of a hardware configuration common to the first and second embodiments will be described. Each part of each device provided in the electronic currency system 1 (and the information processing device provided in the information system) can be realized, for example, by having a computer execute a program that describes the processing content described in this embodiment. Note that this "computer" may be a physical machine or a virtual machine on the cloud. When a virtual machine is used, the "hardware" described here is virtual hardware.

[0244] The program can be stored and distributed by recording it on a computer-readable recording medium (such as a portable memory device).The program can also be provided via a network such as the Internet or email.

[0245] Fig. 26 is a diagram showing an example of the hardware configuration of the computer. The computer in Fig. 26 includes a drive device 1000, an auxiliary storage device 1002, a memory device 1003, a CPU 1004, an interface device 1005, a display device 1006, an input device 1007, an output device 1008, and the like, all of which are interconnected via a bus B.

[0246] The program that realizes the processing on the computer is provided by a recording medium 1001, such as a CD-ROM or a memory card. When the recording medium 1001 storing the program is set in the drive device 1000, the program is installed from the recording medium 1001 to the auxiliary storage device 1002 via the drive device 1000. However, the program does not necessarily have to be installed from the recording medium 1001, but may be downloaded from another computer via a network. The auxiliary storage device 1002 stores the installed program as well as necessary files, data, etc.

[0247] The memory device 1003 reads and stores a program from the auxiliary storage device 1002 when a program startup instruction is received. The CPU 1004 implements functions related to the device in accordance with the program stored in the memory device 1003. The interface device 1005 is used as an interface for connecting to a network. The display device 1006 displays a program-based graphical user interface (GUI), etc. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, etc., and is used to input various operational instructions. The output device 1008 outputs calculation results. Note that the computer may include a GPU (Graphics Processing Unit) or a TPU (Tensor Processing Unit) instead of the CPU 1004, or may include a GPU or TPU in addition to the CPU 1004. In this case, processing may be shared, such as processing requiring special calculations such as neural networks being performed by the GPU or TPU, and other processing being performed by the CPU 1004.

[0248] Regarding the above embodiment, the following Supplementary Notes 1 and 2 are further disclosed.

[0249] <Supplementary Note 1> (Supplementary Item 1) An information processing device in an information system that transmits and receives information, in which a plurality of data pieces each having a pair of a public key and a signature are linked, between information processing devices, comprising: a memory; and at least one processor connected to the memory, wherein the processor generates a new pair of public key and private key after a certain period of time has passed since generating the pair of public key and private key, or after the generated public key or private key has been used a certain number of times, and obtains a certificate for the newly generated public key, and transmits or receives information including the newly generated public key. (Supplementary Item 2) The information processing device according to Supplementary Item 1, wherein the owner of the information processing device is a store, and the public key generated by the key generation unit is a public key indicating a pseudonym for the store. (Supplementary Item 3) The information processing device according to Supplementary Item 1 or 2, wherein the processor and memory are configured with secure hardware. (Supplementary Item 4) The information processing device according to any one of Supplementary Items 1 to 3, wherein the processor generates a new pair of public key and private key after a one-time signature is performed using the private key. (Supplementary Item 5) An information system including the information processing device according to any one of Supplementary Items 1 to 5 and a server that generates the certificate. (Supplementary Item 6) An information processing method executed by an information processing device in an information system in which information formed by concatenating multiple pieces of data, each having a pair of public key and signature, is transmitted and received between information processing devices, the information processing method comprising: a key generation step of generating a new pair of public key and private key and obtaining a certificate for the newly generated public key after a certain period of time has elapsed since the generation of the pair of public key and private key, or after the generated public key or private key has been used a certain number of times; and an information distribution step of transmitting or receiving information including the newly generated public key. (Supplementary Item 7) A non-transitory storage medium storing a program for causing a computer to function as each unit of the information processing device according to any one of Supplementary Items 1 to 5.

[0250] <Supplementary Note 2> (Supplementary Note 1) A currency processing device comprising: a memory; and at least one processor connected to the memory, wherein the processor: calculates the depth of an NNL tree including leaf nodes whose number is equal to or greater than a value obtained by dividing the amount to be transferred by the smallest unit of electronic currency; determines a root node of a second NNL tree which is a subtree of the first NNL tree based on the depth in the first NNL tree attached to the first electronic currency; calculates a random number corresponding to the root node based on a seed of the first NNL tree; determines a range of leaf nodes among the leaf nodes to correspond to the amount; and generates information indicating the random number, the depth, and the range as information to be attached to the second electronic currency. (Supplementary Item 2) A currency processing device comprising: a memory; and at least one processor connected to the memory, wherein the processor calculates the depth of an NNL tree including leaf nodes in a number equal to or greater than a value obtained by dividing the amount of electronic currency to be issued by the smallest unit of the electronic currency, generates a random number to serve as a seed for the NNL tree, determines a range of the leaf nodes to correspond to the amount, and generates information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued. (Supplementary Item 3) A currency processing device comprising: a memory; and at least one processor connected to the memory, wherein the processor generates a Merkle tree based on hash values ​​of each of a plurality of electronic currencies to be transferred, and adds the hash value of the root node of the Merkle tree and a signature for the hash value to each of the plurality of electronic currencies.(Supplementary clause 4) A currency processing method executed by a computer, comprising: a depth calculation procedure for calculating the depth of an NNL tree including leaf nodes whose number is equal to or greater than the value obtained by dividing the amount to be transferred by the smallest unit of electronic currency; a root node determination procedure for determining the root node of a second NNL tree, which is a subtree of the first NNL tree, based on the depth in a first NNL tree attached to a first electronic currency; a random number calculation procedure for calculating a random number corresponding to the root node based on a seed of the first NNL tree; a leaf node determination procedure for determining a range of leaf nodes among the leaf nodes to correspond to the amount; and a currency additional information generation procedure for generating information indicating the random number, the depth, and the range as information to be attached to the second electronic currency. (Supplementary Item 5) A currency processing method executed by a computer, comprising: a depth calculation procedure for calculating the depth of an NNL tree including leaf nodes whose number is equal to or greater than the value obtained by dividing the amount of electronic currency to be issued by the smallest unit of the electronic currency; a random number generation procedure for generating a random number to serve as the seed of the NNL tree; a leaf node determination procedure for determining a range of leaf nodes among the leaf nodes to correspond to the amount; and a currency additional information generation procedure for generating information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued. (Supplementary Item 6) A currency processing method executed by a computer, comprising: a Merkle tree generation procedure for generating a Merkle tree based on hash values ​​of each of multiple electronic currencies to be transferred; and an attachment procedure for attaching a hash value of the root node of the Merkle tree and a signature for the hash value to each of the multiple electronic currencies. (Supplementary Item 7) A non-transitory storage medium storing a program causing a computer to execute the currency processing method according to any one of Supplementary Item 4 to 6.

[0251] (References) [1] Revocation and Tracing Schemes for Stateless Receivers, Dalit Naor, Moni Naor, and Jeff Lotspiech, CRYPTO2001 [2] Jakobsson M., Leighton T., Micali S., Szydlo M. (2003) Fractal Merkle Tree Representation and Traversal. In: Joye M. (eds) Topics in Cryptology - CT-RSA 2003. CT-RSA 2003. Lecture Notes in Computer Science, vol 2612. Springer, Berlin, Heidelberg. Although the embodiments of the present invention have been described in detail above, the present invention is not limited to such specific embodiments, and various modifications and changes are possible within the scope of the gist of the present invention as defined in the claims.

[0252] 1 Electronic currency system 10 Issuing bank server 11 Root certification authority server 20 Financial institution server 25 Intermediate certification authority server 30 User terminal 101 Currency issuance key generation unit 102 Currency issuance certificate issuance unit 103 Financial institution public key certificate issuance information acquisition unit 104 Currency issuance unit 105 Withdrawal acceptance unit 106 Currency issuance key storage unit 107 Withdrawn currency storage unit 111 Root certification key generation unit 112 Root certificate issuance unit 113 Financial institution authentication unit 114 Financial institution public key certificate issuance information transmission unit 115 Root certification key storage unit 116 Financial institution public key certificate issuance information storage unit 201 Currency issuance certificate issuance acceptance unit 202 Financial institution key generation unit 203 Financial institution authentication request unit 204 Currency issuance acceptance unit 205 Withdrawal acceptance unit 206 Update processing unit 207 Currency exchange / deposit acceptance unit 208 Payment request unit 209 Payment acceptance unit 210 Credit acceptance unit 211 Refund request unit 212 Currency issuance certificate storage unit 213 Financial institution key storage unit 214 Financial institution public key certificate storage unit 215 Unused currency storage unit 216 Currency in use storage unit 217 Updated currency storage unit 218 Used currency storage unit 251 Intermediate authentication key generation unit 252 Intermediate certificate issuance unit 253 User authentication unit 254 Intermediate authentication key storage unit 255 User public key certificate issuance information storage unit 301 Currency issuance certificate issuance acceptance unit 302 Intermediate certificate issuance acceptance unit 303 User key generation unit 304 User authentication request unit 305 Withdrawal request unit 306 Payment request unit 307 Payment acceptance unit 308 Exchange / deposit request unit 309 Credit request unit 310 Currency issuance certificate storage unit 311 Intermediate certificate storage unit 312 User key storage unit 313 User public key certificate storage unit 314 User currency storage unit 320 Key generation unit 330 Secure processing unit 340 Currency circulation unit 1000 Drive device 1001 Recording medium 1002 Auxiliary storage device 1003 Memory device 1004 CPU 1005 Interface device 1006 Display device 1007 Input device 1008 Output device

Claims

1. An information processing device in an information system that transmits and receives information consisting of multiple linked pieces of data each having a pair of a public key and a signature between information processing devices, the information processing device comprising: a key generation unit configured to generate a new pair of public key and private key and obtain a certificate for the newly generated public key after a certain period of time has passed since the generation of the pair of public key and private key, or after the generated public key or private key has been used a certain number of times; and an information distribution unit configured to transmit or receive information including the newly generated public key.

2. The information processing device according to claim 1, wherein the owner of the information processing device is a store, and the public key generated by the key generation unit is a public key indicating a pseudonym of the store.

3. The information processing device according to claim 1, wherein the key generation unit is provided within a secure processing unit.

4. The information processing device according to claim 1, wherein the key generation unit generates a new pair of a public key and a private key after a one-time signature is performed using the private key.

5. An information system comprising the information processing device according to any one of claims 1 to 4 and a server that generates the certificate.

6. An information processing method executed by an information processing device in an information system in which information consisting of multiple linked data pieces each having a pair of a public key and a signature is transmitted and received between information processing devices, comprising: a key generation step of generating a new pair of public key and private key and obtaining a certificate for the newly generated public key after a certain period of time has elapsed since the generation of the pair of public key and private key, or after the generated public key or private key has been used a certain number of times; and an information distribution step of transmitting or receiving information including the newly generated public key.

7. A program for causing a computer to function as each part of the information processing device according to any one of claims 1 to 4.

Images