WO2025094278A1 - Information processing device, information system, information processing method, and program - Google Patents

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

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

Research has been ongoing for many years into electronic cash, which is used in electronic currency systems, an example of an information system. Governments around the world are also considering electronic currency.

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

International Publication No. 2022/254624

In conventional electronic currency systems, currency data including the public key of each user is sent between users to circulate the currency. However, in conventional technologies, the public key in the currency data corresponds to a pseudonym, and generally, there is an issue with pseudonym-based methods in that the pseudonym could be used to narrow down individuals.

The above-mentioned issues are not limited to electronic currency systems, and can also occur in various information systems. For example, issues similar to those in the electronic currency system can occur in information systems that run PKI (Public Key Infrastructure) applications that use signatures to distribute information. Information that is the subject of distribution can be, for example, electronic value, but is not limited to electronic value.

The present invention has been made in consideration of the above points, and aims to provide technology for protecting privacy in information systems.

According to the disclosed technology, there is provided an information processing device in an information system in which information in which a plurality of linked pieces of data each having a pair of a public key and a signature are transmitted and received 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 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 unit configured to transmit or receive information including the newly generated public key.

The disclosed technology provides a technique for protecting privacy in information systems.

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

Below, an embodiment of the present invention (present embodiment) 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 applicable is not limited to the embodiment described below.

Below, as an embodiment of the present invention, a technology for realizing privacy protection in a PKI (Public Key Infrastructure) application that uses signatures to distribute information (e.g., electronic value) will be described.

Below, we will explain the privacy protection technology related to the present invention by taking an electronic currency system as an example of an information system in a PKI (Public Key Infrastructure) application.

Note that an 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.

(Overview of the 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 be used, or electronic currency that does not have to be the same value as the legal tender.

In the electronic currency system according to the first embodiment, a server managed by the issuing bank issues electronic currency (hereafter simply called currency) with a signature. Furthermore, transaction history data is managed by a financial institution other than the issuing bank (e.g. a commercial bank). Furthermore, when transactions occur between users, the users' terminals communicate directly with each other to execute the processing required for the transaction.

(Overview of the first embodiment: issues and solutions regarding privacy protection)
Here, problems and solutions regarding privacy protection will be described using Examples 1 to 4.

<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 be called a currency token) as shown in Fig. 1. The currency data is a concatenation of data having a pair of the public key pk and signature S of each user who has used the currency.

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

Here, we assume that the current currency owner is an individual user. The previous currency owner may have been a store or an individual user.

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 privacy of users. Such a public key may be called a "pseudonym." Note that "(semi-)honest" can mean either semi-honest or honest.

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 public key in the currency data shown in Figure 1 indicates which commercial bank the withdrawer is using.

Also, if the previous currency owner of the current currency owner is a store, the currency data in Figure 1 will only reveal the pseudonym of the store used by the individual user who is the current currency owner.

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

Transaction history with multiple stores (pseudonyms) and banks (real name) 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 transactions were conducted using the public key can determine the transaction history by collecting currency data. 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 DB (full data set) and the market holds a partial DB (part of the data set).

Note that Figure 1 is just one example, and similar problems can also occur at stores (Uk+1 and Uk-1) where a general individual user (Uk) makes transactions. This also applies to Examples 2 to 4 described below.

To avoid the above problems, in this embodiment, the public keys of stores (and individual users) are pseudonyms, and the store's public keys and the individual user's public keys are updated periodically. This reduces the possibility that the public keys in the currency data can be used to narrow down individuals (corresponding to the idea of pseudo-IDs), and improves privacy protection.

As an example of the periodic updates mentioned above, individual users (and stores) may "(2) use the same public key only once." In other words, once the user terminal 30 has used a public key (or a private key that is a pair of the public key) only once, it will no longer use that public key, but will instead generate a new public key and use that new public key next time.

If 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 users. However, if the same public key can only be used once, the operational burden (issuing certificates, etc.) will be large.

<Example 2>
An image of currency data when multiple currency data are used in the same transaction is shown in Figure 2. Here, an individual user with a public key pkUn is assumed to be 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.

In Example 2, we also 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. In this case, if the previous owner of the current currency is a store, then just like 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.

In the above scenario, in both cases (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) that were traded with that 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.

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 users and stores are updated periodically, reducing the possibility that currency data can be used to narrow down individuals (corresponding to the idea of a pseudo-ID).

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

As in Example 1, assume that the current currency owner is an individual user. The previous currency owner may be a store or an individual user.

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

If the above error occurs, the currency data in Figure 1 will reveal the real names of the stores used by the individual user who is the current currency owner.

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

The transaction history of multiple stores (real names) and banks (real names) can be collected as data linked to the public key of the individual user (e.g., pkUn in Figure 1). In other words, the store (real name) where the 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 data set related to an individual, it can be said that the issuing bank holds the entire DB (full data set) and the market holds a partial DB (partial data set). In particular, in the case of (1), this data set can be used to narrow down the individual (= equivalent to the idea of a pseudo-ID).

To avoid the above problems, in this embodiment, the public keys of stores (and individual users) are pseudonyms, and the store's public keys and the individual user's public keys are updated periodically. This reduces the possibility that currency data can be used to narrow down individuals (corresponding to the idea of pseudo-IDs).

As an example of the periodic updates mentioned above, an individual user (and a store) may use the same public key only once. In other words, once the user terminal 30 has used a public key (or a private key that is a pair of the public key) once, it will no longer use that public key, but will instead generate a new public key and use that new public key next time.

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 individuals. However, if the same public key can only be used once, the operational burden (issuing certificates, etc.) will be large.

<Example 4>
In Example 4, similar to Example 2, multiple currency data are used in the same transaction as shown in Fig. 2. Here, an individual user having a public key pkUn is assumed to be 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.

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

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

In the above scenario, in both cases (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 multiple stores (real names) that were traded with that public key (pkUn) can be simultaneously determined from the multi-currency data of the target transaction from the perspective of the next payment destination store Un+1. In particular, in the case of (1), there is a possibility that information on other stores (real names) used by the individual user may be collected by frequently used stores. In both cases (1) and (2), although there are differences in risk, there is a possibility that this information may be used to narrow down individuals (= equivalent to the idea of pseudo-ID).

In this embodiment, the public keys of stores and individual users are pseudonyms, and the public keys of individual users and stores are updated periodically, reducing the possibility that currency data can be used to narrow down individuals (corresponding to the idea of a pseudo-ID).

<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 given pseudonyms and restrictions are placed on repeated use.

Specifically, the usage period of the public keys of individual users and stores is set to be short enough that it does not interfere with operations. In particular, for stores' public keys, it is possible to force updates using secure hardware (TEE, SE) on the terminal. In particularly sensitive stores, it is desirable to limit public keys to one-time use only. Note that using secure hardware to update public keys and limiting use to one-time use may also be applied to individual users.

In addition, in this embodiment, as described below, the NNL tree method (variable face value method) is used to reduce the number of currency notes used in one transaction. This makes it less likely that currency received from multiple stores will be mixed into a single transaction, making it possible to reduce the amount of store information linked to an individual user's public key. As a result, the effectiveness of privacy protection can be improved.

(Overview 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 face value method in 1 yen units is adopted to (effectively) realize a variable face value method (token division).

To guarantee the authenticity of each currency, a signature is added to each currency by the issuing bank's server as described above. If currency is represented by a collection of 1 yen coins, for example, 10,000 signatures must be made when issuing 10,000 yen. In this case, the cost of generating and verifying signatures at the time of issuance and payment 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 the leaf node, so that signatures are generated and verified only once at the time of issuance and payment.

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

Fig. 3 is a diagram for explaining an NNL tree. In Fig. 1, a pseudorandom number generator G: {0,1} ⁿ → {0,1} ²ⁿ that generates a random number twice as long as an input random number is applied to an ID (n-bit random number in Fig. 3) as a seed to generate a 2n-bit ID. An example is shown in which a pseudorandom number generator G is applied to the first n bits and the second n bits of the 2n bits to generate further 2n-bit random numbers, generating a total of four n-bit IDs (random numbers).

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

Note that while Figure 3 shows an example with four leaf nodes, the depth of the NNL tree is not limited to any particular value.

Figure 4 is a diagram to explain how to apply an NNL tree to currency in this embodiment.

As described above, in this embodiment, the amount of currency is represented by an NNL tree. Specifically, the leaf node of the NNL tree corresponds to the smallest unit (for example, 1 yen), and the amount of currency corresponding to a certain NNL tree is determined by the number of leaf nodes belonging to that NNL tree. However, if it is assumed that the NNL tree is a binary tree, in this state, only amounts in powers of 2 can be expressed. Therefore, it is made possible to specify the leaf node corresponding to the currency. Specifically, by making it possible to specify information indicating the range of leaf nodes corresponding to the 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 end point. For example, all leaf nodes that belong 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.

For example, if you have a binary NNL tree with a depth of 10, the number of leaf nodes is 1024. If you want to represent 1000 yen, you can specify the start point as 1 and the end point as 1000.

Also, as mentioned above, anyone can derive all the leaf nodes of an NNL tree if they know the seed and depth. Therefore, in this embodiment, the amount of one currency is represented by a set of four parameters.

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

Signatures for currencies (e.g., signatures by the issuer or splitter) are realized by signing in units of seeds in the NNL tree corresponding to the currency. Therefore, the number of signatures can be determined per number of currencies (NNL trees) rather than per smallest unit of the currency (e.g., 1 yen).

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

However, the root node of the original NNL tree may be 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, there is an advantage that the calculation efficiency for verifying by tracing back to the currency issued by the issuing bank (T ₀ described later) is good.

Note that for convenience, Figure 4 shows random numbers corresponding to each node, but the random numbers corresponding to each node do not need to be managed until the currency (NNL tree) is split. In other words, when splitting, the random number of the seed after splitting can be calculated from the seed of the original NNL tree.

Furthermore, the NNL tree is not limited to a binary tree, and 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 that of 5,000 yen/1,000 yen, which are close to everyday cash. In this case, a pseudorandom number generator _G5 : {0,1} ⁿ →{0,1} ⁵ⁿ is used at the 5-branch location, and a pseudorandom number generator _G10 : {0,1} ⁿ →{0,1} ¹⁰ⁿ is used at the 10-branch location.

The configuration and operation of the first embodiment are described below.

(Details of the First Embodiment)
5 is a diagram showing an example of the system configuration of the 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.

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 the currency and transmits it to the financial institution server 20. In addition, the issuing bank server 10 has a function of accepting a withdrawal request from the financial institution server 20.

The root certification authority server 11 is an information processing device that has the functionality 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.

As a preparation step for issuing currency, the root certification authority server 11 generates a root certification key, issues a root certificate, and sends 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 sends the generated financial institution public key certificate issuance information to the issuing bank server 10.

The financial institution server 20 is an information processing device managed by a financial institution (e.g., a commercial bank). The financial institution server 20 is authenticated by the root certification authority server 11 and accepts the issuance of currency from the issuing bank server 10.

The financial institution server 20 also accepts requests for transactions such as withdrawals, currency exchange, deposits, and credit from the user terminal 30. Furthermore, the financial institution server 20 requests refunds from the issuing bank server 10.

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

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.

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

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

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 authentication authority server 25. In addition, the user terminal 30 requests transactions such as withdrawals, currency exchanges, deposits, and credit from the financial institution server 20.

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

A user terminal 30 (e.g., user terminal 30-1) requests payment from another user terminal 30 (e.g., user terminal 30-2) and accepts a payment request. Here, a payment request is a request to accept the execution of a "payment" transaction in which the user makes payment to the other party, and is not a request for the other party to make payment to the user.

(Example of functional configuration of each device according to the first embodiment)
Next, an example of the functional configuration of each device according to the first embodiment will be described.

FIG. 6 is a functional block diagram of the issuing bank server. 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.

The currency issuance key generation unit 101 generates cryptographic key data (hereafter referred to as the currency issuance key) for guaranteeing the validity of message data indicating the issuance of currency (hereafter referred to as the currency issuance message). The currency issuance key includes a private key and a public key.

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.

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.

The currency issuance unit 104 uses the currency issuance key and the financial institution public key certificate issuance information to generate a currency issuance message and transmits the generated currency issuance message to the financial institution server 20.

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 be using for the time being with the issuing bank, returning it to circulation.

The currency issuance key storage unit 106 stores the currency issuance key generated by the currency issuance key generation unit 101.

The refunded currency storage unit 107 stores the currency that has been accepted for refund by the refund acceptance unit 105 (hereinafter referred to as refunded currency).

FIG. 7 is a functional block diagram of the root certification authority server. 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.

The root authentication key generation unit 111 generates cryptographic key data (hereinafter referred to as the root certification key) for verifying the legitimacy of the root certification authority. The root certification key includes a private key and a public key.

The root certificate issuing unit 112 issues certificate data (hereafter referred to as a root certificate) for verifying the validity of certificate data (hereafter referred to as an intermediate certificate) for verifying the validity of an intermediate certification authority, and transmits it to each intermediate certification authority server 25.

The financial institution authentication unit 113 receives encryption key data (hereinafter referred to as the financial institution key) for guaranteeing 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).

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

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

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.

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

The currency issuance certificate issuance reception unit 201 receives the issuance of a currency issuance certificate from the issuing bank server 10.

The financial institution key generation unit 202 generates a financial institution key. The financial institution key includes a private key and a public key.

The financial institution authentication request unit 203 sends a 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.

The currency issuance reception unit 204 accepts the issuance of currency 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.

The withdrawal reception unit 205 accepts withdrawal requests from the user terminal 30 and transmits currency to the user terminal 30.

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 addition information) added to the used currency. Note that currency addition 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.

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. In addition, when the currency exchange/deposit reception unit 207 accepts a request for a deposit, the payment reception unit 209 accepts payment of the amount to be deposited.

The credit acceptance unit 210 receives currency from the user terminal 30 and accepts a credit request. 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.

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

The currency issuance certificate storage unit 212 stores the currency issuance certificate that has been accepted for issuance by the currency issuance certificate issuance acceptance unit 201.

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

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.

The unused currency storage unit 215 stores the currency that is accepted for issuance by the currency issuance acceptance unit 204 as unused currency.

The currency in use memory unit 216 stores the currency for which the withdrawal acceptance unit 205 accepts a withdrawal as the currency in use.

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

The used currency storage unit 218 stores currency that has been used but is not currently in use. Specifically, the used currency storage unit 218 stores as used currency the currency that is received when the exchange/deposit reception unit 207 receives a request for exchange or deposit and the payment reception unit 209 receives the payment.

FIG. 9 is a functional configuration diagram of the intermediate certification authority server. 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.

The intermediate authentication key generation unit 251 generates cryptographic key data (hereinafter referred to as intermediate authentication key) for guaranteeing the legitimacy of the intermediate certification authority. The intermediate authentication key includes a private key and a public key.

The intermediate certificate issuing unit 252 issues an intermediate certificate and sends it to each user terminal 30.

The user authentication unit 253 receives encryption key data (hereinafter referred to as user key) for guaranteeing 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).

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

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.

FIG. 10 is a functional block diagram of the user terminal 30. The user terminal 30 comprises a currency issuance certificate issuance acceptance unit 301, an intermediate certificate issuance acceptance unit 302, a user key generation unit 303, a user authentication request unit 304, 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 storage unit 310, an intermediate certificate storage unit 311, a user key storage unit 312, a user public key certificate storage unit 313, and a user currency storage unit 314.

The currency issuance certificate issuance reception unit 301 receives the issuance of a currency issuance certificate from the issuing bank server 10.

The intermediate certificate issuance reception unit 302 receives the issuance of an intermediate certificate from the intermediate certification authority server 25.

The user key generation unit 303 generates a user key. The user key includes a private key and a public key.

The user authentication request unit 304 sends a user key to the intermediate certification authority server 25 to request authentication of the user, and receives a user public key certificate from the intermediate certification authority server 25.

The withdrawal request unit 305 requests a withdrawal from the financial institution server 20 by specifying the face value. The withdrawal request unit 305 receives the currency withdrawn from the financial institution server 20.

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.

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.

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 it, 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 multiple payments from the financial institution server 20 that total the face value to be exchanged. Also, when the exchange/deposit request unit 308 requests a deposit and the financial institution server 20 accepts it, the payment request unit 306 transmits the currency to be deposited and requests payment from the financial institution server 20.

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

The currency issuance certificate storage unit 310 stores the currency issuance certificate that has been accepted for issuance by the currency issuance certificate issuance acceptance unit 301.

The intermediate certificate storage unit 311 stores intermediate certificates that have been accepted for issuance by the intermediate certificate issuance acceptance unit 302.

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

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

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

(Example of the configuration of the user terminal 30 involved in updating the public key)
As described above, in this embodiment, the public key, which is a pseudonym, is updated, for example, periodically, regardless of whether the user terminal 30 belongs to an individual user or a store. In this embodiment, this update is performed on secure hardware (TEE, SE, etc.). An example of the configuration of the user terminal 30 from this perspective is shown in FIG. 11.

Note that a device that uses a regularly 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 regularly updated public key to execute the circulation of electronic currency may be called a "currency processing device." For this reason, the "currency processing device" is written in parentheses in Figure 11.

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

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

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.) stored in the secure processing unit 330 cannot be tampered with from the outside.

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

For example, in the user terminal 30, the processing unit requiring secure processing (including a CPU, memory, etc.) can be completely separated from the general processing unit (including a CPU, memory, etc.) in hardware, so that the processing unit requiring secure processing can be realized as the secure processing unit 330.

In addition, some hardware is shared between processing units that require secure processing and general processing units, but the processing unit that realizes secure processing in software may be called the secure processing unit 330.

The key generation unit 320 generates a public key and private key pair, and also updates the public key and private key pair. Note that "updating a public key and private key pair" means generating a new public key and private key pair after generating a public key and private key pair. 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.

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 user key generation (S108), user authentication request (S109), and acquisition of a user public key certificate (S111) in the sequence of FIG. 12 described below. The key generation unit 320 may also perform signing using the private key at the time of issuance, payment, etc.

For example, the key generation unit 320 generates a new public key and private key pair (i.e., updates) immediately after a predetermined period of time has elapsed since generating a public key and private key pair. After updating, the new public key and private key pair is used.

In addition, for example, after generating a pair of public key and private key, the key generating unit 320 generates a new pair of public key and private key (i.e., updates) immediately after the generated public key or private key has been used a predetermined number of times. After updating, the new pair of public key and private key is used.

"The generated public key or private key is used" means using the private key for signing, sending the public key (or data including the public key) to another device, etc.

The above period is set, for example, to be short enough that it does not cause any operational problems. Also, the above number of times is set to be small enough that it does not cause any operational problems. For example, the above number of times may be "1".

In addition, 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 only sign one piece of data. The key generation unit 320 updates the public key and private key pair immediately after executing the one-time signature. In other words, the use of a one-time signature makes it possible to forcibly update the keys. Furthermore, fraud can be identified at the time the second signature is made.

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

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 storage unit 310, an intermediate certificate storage unit 311, and a user currency storage unit 314.

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

(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. Below, the concept will be explained using symbols such as _B0 for the issuing bank, _Bi for each financial institution ( _B0 , _B1 , ...), _A0 for the root certificate authority, _Ai for each intermediate certificate authority ( _A0 , _A1 , ...), and _Uj for each user ( _U0 , _U1 , ...).

FIG. 12 is a sequence diagram showing an example of the flow of the currency issuance process. The currency issuance process is started periodically or in response to an operation by a person in charge.

The currency issuance key generation unit 101 of the issuing bank server 10 generates a currency issuance key (step S101). Specifically, the currency issuance key generation unit 101 generates a currency issuance key pair (private key skB _0vy and public key pkB _0vy ) corresponding to an issuance year y and an issuance amount v.

Then, the currency issuance certificate issuing unit 102 transmits the currency issuance certificate CERT (pkB _0vy ) certifying the public key pkB _0vy to each financial institution server 20 (step S102), and transmits it to each user terminal 30 (step S103). The currency issuance certificate issuance acceptance unit 201 of each financial institution server 20 receives the currency issuance certificate CERT (pkB _0vy ) and stores it in the currency issuance certificate storage unit 212. Also, the currency issuance certificate issuance acceptance unit 301 of each user terminal 30 receives the currency issuance certificate CERT (pkB _0vy ) and stores it in the currency issuance certificate storage unit 310.

The issuance amount v is a multiple of the smallest unit (e.g., 1 yen). For example, when issuing currency of 10,000 yen in the year 2021, the currency issuance certificate issuing unit 102 transmits the currency issuance certificate CERT(pkB _{0(10,000 yen)(2021)} ) to each financial institution server 20 and each user terminal 30.

It should be noted that the currency issuance certificate issuing unit 102 does not have to transmit the currency issuance certificate CERT(pkB _0vy ) directly to each financial institution server 20 and each user terminal 30. For example, it may upload the currency issuance certificate CERT(pkB 0vy) to a server device or the like that is publicly available on a communication network, and then have it downloaded to each financial institution server 20 and each user terminal 30.

Next, the root certification key generation unit 111 of the root certification authority server 11 generates a root certification key (step S104). The root certification key includes a private key skA ₀ and a public key pkA _0. Next, the root certificate issuance unit 112 generates a root certificate Auth(pkA ₀ ) by signing with the private key skA ₀ and transmits it to each financial institution server 20 (step S105).

In addition, the root certificate issuing unit 112 does not have to directly send the root certificate Auth(pkA ₀ ) to each financial institution server 20. For example, it may upload it to a server device or the like that is publicly available on a communication network, and then have it downloaded to each financial institution server 20.

Next, the intermediate authentication key generating unit 251 of the intermediate authentication authority server 25 generates an intermediate authentication key (step S106). The intermediate authentication key includes a secret key skA _i and a public key pkA _i .

Next, the intermediate certificate issuance unit 252 signs with the private key skA _i and generates an intermediate certificate Auth(pkA _i , pkA ₀ ) using the root certificate Auth(pkA 0 ). Hereinafter, the intermediate certificate Auth(pkA _i , pkA ₀ ) is written as Auth(pkA _i ). Then, the intermediate certificate issuance unit 252 transmits the generated intermediate certificate Auth(pkA _i ) to each user terminal 30 (step S107). _The intermediate certificate issuance acceptance unit 302 of each user terminal 30 receives the intermediate certificate Auth(pkA _i ) and stores it in the intermediate certificate storage unit 311.

In addition, the intermediate certificate issuance unit 252 does not have to directly transmit the intermediate certificate Auth(pkA _i ) to each user terminal 30. For example, it may upload the intermediate certificate Auth(pkA i ) to a server device or the like that is publicly available on a communication network, and then have the intermediate certificate Auth(pkA i ) downloaded to each user terminal 30.

Next, the user key generation unit 303 of the user terminal 30 generates a user key (step S108). The user key includes a secret key _skUj and a public key _pkUj . Next, the user authentication request unit 304 transmits the public key _pkUj to request user authentication from the intermediate certification authority server 25 (step S109).

The user authentication unit 253 of the intermediate certification authority server 25 generates a user public key certificate Auth(pkUj, _pkAi , _pkA0 ) using the root certificate Auth( _pkA0 ) and the intermediate certificate Auth( _pkAi ) (step S110 ₎ . Hereinafter, the user public key certificate Auth( _pkUj , _pkAi , _pkA0 ) will be written as Auth(pkUj ₎ . The user authentication unit 253 transmits the generated user public key certificate Auth( _pkUj ) to the user terminal 30 (step S111). The user terminal 30 holds the private key _skUj , the public key _pkUj , and the user public key certificate Auth( _pkUj ).

Furthermore, the user authentication unit 253 generates user public key certificate issuance information ( _Uj , _pkUj , Auth( _pkUj )) and stores it in the user public key certificate issuance information storage unit 255. The user public key certificate issuance information ( _Uj , _pkUj , Auth( _pkUj )) includes personal information _Uj of the user.

Next, the financial institution key generation unit 202 of the financial institution server 20 generates a financial institution key (step S112). The financial institution key includes a private key _skBi and a public key _pBi . Next, the financial institution authentication request unit 203 transmits the public key _pBi to request financial institution authentication from the root certification authority server 11 (step S113).

The financial institution authentication unit 113 of the root certification authority server 11 generates a financial institution public key certificate Auth(pkB _i , pkA ₀ ) using the root certificate Auth(pkA ₀ ) (step S114). Hereinafter, the financial institution public key certificate Auth(pkB _i , pkA ₀ ) will be referred to as Auth(pkB _i ). The financial institution authentication unit 113 transmits the generated financial institution public key certificate Auth(pkB _i ) to the financial institution server 20 (step S115). The financial institution server 20 holds the private key skB _i , the public key pkB _i and the financial institution public key certificate Auth(pkB _i ).

Furthermore, the financial institution authentication unit 113 generates financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) and stores it in the financial institution public key certificate issuance information storage unit 116. The financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) includes institution information B _i about the financial institution. Then, the financial institution public key certificate issuance information transmission unit 114 transmits the financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) to the issuing bank server 10 (step S116).

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 _i , pkB _i , Auth(pkB _i )) and stores it in the financial institution public key certificate issuance information storage unit 116 .

Note that the order of the processes from step S108 to step S111 and the processes from step S112 to step S116 is just 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.

The user terminal 30 may also execute the process from step S108 to step S111 multiple times to add a user key. As described above, the user terminal 30 executes the process from step S108 to step S111 when updating the public key and private key when a predetermined period (or number of times) has expired.

Next, the currency issuing unit 104 of the issuing bank server 10 uses the financial institution public key certificate issuance information (B _i , pkB _i , Auth(pkB _i )) stored in the financial institution public key certificate issuance information storage unit 116 to generate a currency issuance message (id ₀ , y, B _i , pkB _i ) that specifies the currency ID id ₀ based on the issuance amount v, the issuance year y, and the financial institution B _i (step S117). Note that the structure of the currency ID is as described in FIG. 4, and the method of generating it will be described later. Here, the currency issuing unit 104 signs (id ₀ , y, B _i , pkB _i ) using the private key skB _0vy of the currency issuance key stored in the currency issuance key storage unit 106. The currency issuing unit 104 transmits the currency issuance message (id ₀ , y, B _i , pkB _i ) with the signature S ₀ attached 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, the generation of the currency issuance message essentially corresponds to the issuance of the currency.

The currency issuance acceptance unit 204 of the financial institution server 20 receives the currency issuance message (id ₀ , y, B _i , pkB _i ) with the signature S ₀ added, and verifies the signature S ₀ using the public key pkB _0vy included in the currency issuance certificate CERT (pkB _0vy ) stored in the currency issuance certificate memory unit 212. Then, the currency issuance acceptance unit 204 generates currency T ₀ := (id ₀ , y, B _i , pkB _i , S ₀ ) and stores it in the unused currency memory unit 215.

The following describes how the currency ID is generated when generating the currency issuance message in step S117.

FIG. 13 is a flowchart illustrating an example of the processing steps for generating a currency ID when issuing currency.

In step S121, the currency issuing unit 104 calculates the depth of the smallest NNL tree that contains leaf nodes equal to or greater than the issuance amount v. The calculation of the depth essentially corresponds to the generation of the structure of the NNL tree. A leaf node equal to or greater than the issuance amount v means a number of leaf nodes that can express the issuance amount v, and refers to a number of leaf nodes 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, then 8 leaf nodes are required. If the NNL tree is a binary tree, the depth of a binary tree that can contain 8 leaf nodes is 3 or greater. Therefore, 3, the smallest value among 3 or greater, becomes the depth of the NNL tree.

Next, the currency issuing unit 104 generates a random number that will become the seed of the NNL tree (S122).

Then, the currency issuing unit 104 determines the start point and end point of the leaf node of the NNL tree that corresponds to the issuance amount v (S123). One of the start point and end point is a leaf node at the end of the NNL tree, and the start point and end point are determined so that the set of consecutive leaf nodes from the start point to the end point matches the issuance amount v. The values of the start point and end point may be expressed by values that indicate 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.

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

14 is a sequence diagram showing an example of the flow of a withdrawal process, which is started in response to an operation of a user _Uj instructing a withdrawal.

The withdrawal request unit 305 of the user terminal 30 transmits denomination information indicating the denomination v of the withdrawal and the public key pkU _j of the user key stored in the user key storage unit 312 to request a withdrawal from the financial institution server 20 (step S201).

The withdrawal acceptance unit 205 of the financial institution server 20 accepts the withdrawal (step S202). Specifically, the withdrawal acceptance unit 205 acquires unused currency _T0 of face value v from the unused currency storage unit 215, and stores it in the currency storage unit 216 as the currency in use ( _T1 , _T0 ) to which currency additional information _T1 :=( _id1 , _pkUj , _S1 ) is added. _S1 is a signature for ( _id1 , _pkUj , _T0 ) using the private key _skBi of the financial institution key. In addition, _id1 is the currency ID of the currency to be transferred based on the face value of the currency in use ( _T1 , _T0 ). When the currency _T0 matches the face value v, the value of _id1 may be the same as _id0 , which is the currency ID of the currency _T0 . Also, when a set of multiple currencies _T0 matches the face value v, the withdrawal acceptance unit 205 may generate a currency ( _T1 , _T0 ) for each of these currencies _T0 . In this case, the value of _id1 of each _T1 may be the same as the corresponding _id1 .

On the other hand, when the currency _T0 exceeds the face value v, or when the set of multiple currencies _T0 exceeds the face value v, the withdrawal acceptance unit 205 divides a part of the currency _T0 to generate a currency ( _T1 , _T0 ). For example, when the face value v is 1000 yen and the currency _T0 is 5000 yen, the withdrawal acceptance unit 205 divides 1000 yen from the currency _T0 to generate a currency ( _T1 , _T0 ) of 1000 yen. Also, for example, when the face value v is 7000 yen and each currency _T0 is 5000 yen, the withdrawal acceptance unit 205 divides 2000 yen from one of the two currencies _T0 to generate a currency ( _T1 , _T0 ) of 2000 yen. The division of the currency _T0 is realized by dividing the NNL tree as the _id0 included in the currency _T0 . This is because the NNL tree also expresses the amount of the currency. The process of dividing such currency is described below.

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, currency additional information can be said to be information that indicates the history of currency transfers.

Next, the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T ₁ , T ₀ ) and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data of the currency in use (T ₁ , T ₀ ) and the financial institution public key certificate Auth(pkB _i ), and stores the currency in use (T ₁ , T ₀ ) in the user currency storage unit 314. (T ₁ , T ₀ ) may be called unused currency.

In step S202, the withdrawal acceptance unit 205 may use the used currency stored in the used currency storage unit 218 instead of the 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 decides whether to use the used currency in accordance with predetermined conditions. For example, the withdrawal acceptance unit 205 may use the used currency when the data volume of the used currency reaches or exceeds a threshold value.

For example, when the withdrawal acceptance unit 205 uses used currency (T _n , ..., T ₀ ) for withdrawal, the update processing unit 206 stores the currency (T _n , ..., T ₀ ) in the state before the update in the updated currency storage unit 217. Then, the update processing unit 206 updates the used currency (T _n , ..., T ₀ ) to currency T ₀ from which the currency additional information (T _n , ..., T ₁ ) has been deleted. Then, the withdrawal acceptance unit 205 stores the currency in use (T n+1 , T ₀ ) obtained by adding currency additional information T _n+1 := (id _{n +1} , pkU _j , S _n+1 ) to the updated currency T ₀ in the currency in use storage unit 216. At this time, the value (contents) of id _n+1 may be the same as the currency ID included in T _n .

Next, the withdrawal acceptance unit 205 transmits the currency data of the currency in use (T _n+1 , T ₀ ) and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data of the currency in use (T _n+1 , T ₀ ) and the financial institution public key certificate Auth(pkB _i ), and stores the currency in use (T _n+1 , T ₀ ) in the user currency storage unit 314.

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 stores in the updated currency storage unit 217 a currency (Tn+ _k , ..., _T1 , _T0 ) that is obtained by combining a currency (Tn _, ..., _T1 , _T0 ) in a state before the previous update with a currency (Tn _+k , ..., Tn ₊₁ , _T0 ) in a state before the current update.

The details of the currency split process that is executed in step S202 when currency splitting is necessary will be described. Figure 15 is a flowchart for explaining an example of the processing procedure for currency splitting.

In step S211, the withdrawal reception unit 205 calculates the depth of the smallest NNL tree (hereinafter referred to as the "destination NNL tree") that contains at least the number of leaf nodes corresponding to the denomination v of the withdrawal. The method of calculating the depth is the same as in step S121 of FIG. 13.

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

Then, the withdrawal reception 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 FIG. 3, the seed of the NNL tree to be split can be calculated by recursively applying the pseudorandom number generator G to the seed of the original NNL tree.

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

Next, the withdrawal acceptance unit 205 generates a set of {Seed of the NNL tree to be divided, depth of the NNL tree to be divided, start point, end point} as the currency ID of the currency to be divided (i.e., id ₁ of the currency additional information T ₁ := (id ₁ , pkU _j , S ₁ ) in step S202) (S215).

Next, the withdrawal acceptance unit 205 identifies the next leaf node in the original NNL tree that is the end point of the destination currency in order to match the original currency (T ₀ in S202) with the balance (amount minus the face value v) (S215).

Then, the withdrawal reception 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 addition information when the remaining amount of the original currency is transferred by withdrawal, payment, etc.

16 is a sequence diagram showing an example of the flow of payment processing (transmission processing from a remitter to a recipient) according to the first embodiment. The payment processing is started in response to an operation by a remitter user _Uj to instruct a payment to a recipient user _Uk .

The user terminal 30-1 is the user terminal 30 operated by the remittance user _Uj . The user terminal 30-2 is the user terminal 30 operated by the remittance user _Uk . The payment request unit 306 of the user terminal 30-1 transmits the currency T0, which is the currency data excluding the currency additional information from the currencies (Tn _{-1 ,} ..., _T0 ) whose payment amount is equal to or greater than v, Tn _-1 = (idn _-1 , _pkUj , Sn _-1 ), and the user public key certificate Auth( _pkUj ) to request payment from the user terminal 30-2 (step S301). Note that the currency _T0 does not indicate the current face value of the currencies (Tn _-1 , ..., _T0 ). The current denomination of a currency (T _n-1 , . . . , T ₀ ) can be derived from the start and end points of the NNL tree as id _n-1 of T _n-1 .

The payment acceptance unit 307 of the user terminal 30-2 accepts the payment (step S302). Specifically, the payment acceptance unit 307 verifies the currency T ₀ , S _n-1 of T n-1 = (id _n-1 , pkU _j , S _{n- 1} ), and the user public key certificate Auth(pkU _j ). Here, in verifying the currency, the payment acceptance unit 307 verifies the signature data included in the currency. For example, the payment acceptance unit 307 verifies the signature S ₀ of the currency T ₀ := (id ₀ , y, B _i , pkB _i , S ₀ ). In addition, the payment acceptance unit 307 verifies S n _-1 of T _n-1 = (id _n-1 , pkU _j , S _n-1 ) using pkU _j .

Next, the payment acceptance unit 307 transmits the public key pkU _k of the user key stored in the user key storage unit 312 of the user terminal 30-2 to the user terminal 30-1 (step S303). The payment request unit 306 of the user terminal 30-1 generates id _n as a currency ID, calculates a signature (S _n ) using the private key skU j of the user key stored in the user key storage unit 312 of the user terminal 30-1 for information including id n, the received public key pkU _k , and currency data (for example, T _{n -1 or} the hash value of T n _-1 ), and generates currency additional information T _n := (id _n , pkU _k , S _n ) (step S304). The currency additional information may be called currency data. Here, id _n is a currency ID based on the face value of the currency (T _n , ..., T ₀ ) to be generated. When a currency (T _n-1 , ..., T ₀ ) matches the payment amount v, the value of id _n may be the same as id _n-1 , which is the currency ID of T _n-1 of the currency (T _n-1 , ..., T ₀ ). Also, when a set of multiple currencies (T _n -1 , ..., T ₀ ) matches the payment amount v, the payment request unit 306 may generate currency additional information T _n := (id _n , pkU _k , S _n ) for each of these currencies ( _{T n-1} , ..., T ₀ ). In this case, the value of id _n for each Tn may be the same as the corresponding id _n-1 , and the currency (T _n , ..., T ₀ ) described below is generated for each currency (T _n-1 , ..., T ₀ ).

On the other hand, if the currency (T _n-1 , ..., T ₀ ) exceeds the payment amount v, or if the set of multiple currencies (T _n-1 , ..., T ₀ ) ₀ exceeds the payment amount v, the payment request unit 306 divides a part of the currency (T _n-1 , ..., T _{0 )} to generate id _n . That is, id _n in this case is {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 id _n-1 , which is the currency ID of T _n-1 in the currency (T n-1 , ..., T 0 ), as the division source. The processing procedure for executing such division is as described in FIG. 15. That is, in step S304, the payment request unit 306 generates id _n by executing the processing procedure of FIG. 15.

The payment request unit 306 sends the currency additional information (T _n , ..., T ₁ ) obtained by adding the generated currency additional information T _n := (id _n , pkU _k , S _n ) to the currency additional information (T _n -1 , ..., T ₁ ) to the user terminal 30-2 (step S305).

The payment acceptance unit 307 of the user terminal 30-2 verifies the currency additional information (T _n , ..., T ₁ ). Specifically, the payment acceptance unit 307 verifies S _n using the public key pkU _j . 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 signature S _n of the currency additional information T _n := (id _n , pkU _j , S _n ). The payment acceptance unit 307 stores the currency (T _n , ..., T ₀ ) obtained by adding the currency additional information (T _n , ..., T ₁ ) to the received currency T ₀ in the user currency storage unit 314 of the user terminal 30-2.

17 is a sequence diagram showing an example of the flow of a currency exchange process. The currency exchange process is started in response to an operation of a user _Uj instructing currency exchange.

The exchange/deposit request unit 308 of the user terminal 30 transmits denomination information indicating the denomination v of the exchange and the public key pkU _j of the user key stored in the user key memory unit 312 to request an exchange from the financial institution server 20 (step S401).

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

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

In addition, when exchanging amounts _v1 , ..., _vx that total to an exchange amount v, the payment request unit 208 of the financial institution server 20 requests payment from the user terminal 30 for each of _v1 , ..., _vx in accordance with the payment process shown in FIG. 16 (steps S405-1, S405-2).

18 is a sequence diagram showing an example of the flow of a credit process. The credit process is started in response to an operation of a user _Uj instructing credit.

The credit request unit 309 of the user terminal 30 transmits the currency _T0 for which the availability of the currency is to be confirmed, and requests credit from the financial institution server 20 (step S501). The credit acceptance unit 210 of the financial institution server 20 accepts the credit (step S502). Specifically, the credit acceptance unit 210 searches for the currency _T0 in the currently used currency storage unit 216, and if a record including _T0 , for example ( _T1 , _T0 ), exists, the credit acceptance unit 210 transmits a credit result indicating a credit success ack to the user terminal 30 (step S503).

19 is a sequence diagram showing an example of the flow of a deposit process. The deposit process is started in response to an operation of a user _Uj instructing a deposit.

The currency exchange/deposit request unit 308 of the user terminal 30 transmits face amount information indicating the face amount v of the deposit and the public key pkU _j of the user key stored in the user key memory unit 312 to request currency exchange from the financial institution server 20 (step S601).

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

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

20 is a sequence diagram showing an example of the flow of the refund process. The refund process is started in response to an operation of the financial institution _Bi to instruct a refund.

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 extracts unused currency _T0 from the unused currency storage unit 215 and transmits it to the issuing bank server 10.

Furthermore, when refunding used currency, the refund request unit 211 extracts the used currency (T _n , ..., T ₀ ) from the used currency storage unit 218 and transmits it to the issuing bank server 10. Furthermore, if the used currency (T _m , ..., T _k+1 , T ₀ ) has been updated, the refund request unit 211 reads out the currency additional information (T _k , ..., T ₁ ) before the update from the updated currency storage unit 217, combines it with the used currency (T _m , ..., T _k+1 , T ₀ ), and transmits the combined currency (T _m , ..., T ₀ ) to the issuing bank server 10.

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 confirm the validity of the currency for which the refund has been accepted by verifying the signature included in each currency additional information. For example, the signature S _n included in the currency additional information T _n can be verified using the public key included in the currency additional information T _n-1 .

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

Specifically, by placing restrictions on 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 individuals from being narrowed down by using pseudonyms (public keys) across multiple transactions. In addition, individual users can prevent their transaction history from being revealed to stores with which they do business.

In addition, by adopting an NNL tree, it is possible to reduce the number of coins used in one transaction, which in turn makes it possible to prevent individuals from being narrowed down by pseudonyms (public keys) assigned to multiple currency data in the same transaction.

Furthermore, by adopting the NNL tree, it is possible to efficiently realize a floating 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 units of currency rather than in units of the minimum unit. Furthermore, by adopting the NNL tree method, it is also possible to reduce the number of hash calculations.

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.

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 deposits wishes to pay 3,000 yen, they can pay two currencies: one 2,000 yen deposit and one 1,000 yen deposit divided from the other 2,000 yen deposit. In this case, 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.

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 the target currencies at once. In the following description of the second embodiment, components having the same functional configuration as those in the first embodiment are given the same reference numerals as those used in the description of the first embodiment, and descriptions of these components are omitted.

(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 document [2]) are used.

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

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. Below, it is written as MHTree(D)->L. Note that Figure 21 shows a dataset with 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.

FIG. 22 is a first diagram for explaining 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.

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

FIG. 23 is a diagram for explaining the MHVer function of a Merkle tree according to the second embodiment. The MHVer function is a function that performs verification using the authentication path of a partial data set.

Specifically, the MHVer function is a function that verifies sub-data D' (D' = {d0, d4, d5} in the case of Figure 23) from the path AP required for authentication (h001, h01, h11 in Figure 23) and the route h. Below, 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.

(Example of operation of electronic currency system according to the second embodiment)
Here, in step S202 of FIG. 14, it is assumed that the currency matching the face value v is a set of multiple currencies T ₀ :=(T ₀ _t ):=((id ₀ _t, y_t, B _i , pkB _i , S ₀ _t), t=1, ..., s, Σv_t=v). Note that v_t is the amount of the t-th currency T ₀ _t among the currency sets constituting T _0. For example, if each v_t is 10,000 yen and a withdrawal of 80,000 yen is accepted, then s=8. FIG. 24 shows a state in which there are eight T ₀ _t, each of which is 10,000 yen. Note that if there is no 10,000 yen x 8 currency, such as, for example, 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 execute the process of FIG. 15 to divide the eight 10,000 yen coins from the existing 100,000 yen. 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, the currency may be a currency that has been divided (i.e., the NNL tree of the currency ID has been divided) during the transfer process.

The withdrawal acceptance unit 205 of the financial institution server 20 generates a hash tree _L1 = MHTree ({ _{T0_t} } {t = 1, ..., s}) and generates a signature _S1 for the set of the hash value RH (RootHash) of the root node of the hash tree _L1 and _pkUj using the private key skB _i . In other words, the hash tree _L1 is a hash tree generated by assigning each _{T0_t} constituting _T0 to its leaf nodes. For each _{T0_t} , the withdrawal acceptance unit 205 generates a currency in use ( _{T1_t} , _{T0_t} ) by adding currency additional information _{T1_t} : = ( _{id1_t} , _pkUj , RH, _{AP_t} , _S1 ) to the T0_t, and stores it in the currency in use memory unit 216. Here, AP_t is a path required for authenticating RH obtained by MHPath(T ₀ _t, L ₁ )->(AP_t, RH). The value of each id ₁ _t may be the same as the corresponding id ₀ _t. This state is shown in FIG. 25. It can be seen that each T ₁ _t contains the same signature S _1. Hereinafter, a set of currencies (T ₁ _t, T ₀ _t) (here, a set of eight) is written as (T ₁ , T ₀ ).

Next, the withdrawal acceptance unit 205 transmits the currency data set of the currency set (T ₁ , T ₀ ) in use and the financial institution public key certificate Auth(pkB _i ) to the user terminal 30 (step S203). The withdrawal request unit 305 of the user terminal 30 verifies the currency data set of the currency set (T ₁ , T ₀ ) in use and the financial institution public key certificate Auth(pkB _i ), and stores the currency set (T ₁ , T ₀ ) in use in the user currency storage unit 314. At this time, the withdrawal request unit 305 needs to verify only one of the currencies (T _{1 _t} , T _{0 _t} ) in (T ₁ , T ₀ ) when verifying the currency set (T ₁ , T ₀ ). Specifically, for any one of T ₁ _t, MHver(AP_t, RH, T ₀ ) is verified to be T, and S ₁ included in the T ₁ _t is verified. For other T ₁ _t, the withdrawal request unit 305 only needs to confirm that they include the same S ₁ as the verified T ₁ _t.

The user of the user terminal 30 can use each of (T ₁ _t, T _{0 _t} ) that constituted the withdrawn currency set (T ₁ , T 0 ) individually (separately). This is because T ₁ _t indicates the history of the currency owner (circulation process) like the currency additional information in the first embodiment, except that it includes RH and AP_t to reduce the signature and verification costs of the currency set, and the authenticity of each currency is guaranteed individually.

The above process is also performed in steps S304 and S305 in FIG. 16 when a payment is made using a set of multiple coins.

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

Furthermore, the process in FIG. 16 can be applied in all other phases (such as when issuing and when redeeming). For example, when redeeming, it is possible to efficiently transfer the currency to be redeemed in one lump sum.

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

(Hardware configuration example)
An example of a hardware configuration common to the first and second embodiments will be described. Each part of each device (and information processing device) included in the electronic currency system 1 can be realized, for example, by having a computer execute a program describing the processing contents 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.

The above program can be recorded on a computer-readable recording medium (such as a portable memory) and stored or distributed. The above program can also be provided via a network, such as the Internet or e-mail.

FIG. 26 is a diagram showing an example of the hardware configuration of the computer. The computer in FIG. 26 has 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, etc., all of which are interconnected via a bus B.

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 via the drive device 1000 into the auxiliary storage device 1002. 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.

When an instruction to start a program is received, the memory device 1003 reads out and stores the program from the auxiliary storage device 1002. The CPU 1004 realizes the functions related to the device according to 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 GUI (Graphical User Interface) or the like according to a program. The input device 1007 is composed of a keyboard, mouse, buttons, a touch panel, or the like, and is used to input various operation instructions. The output device 1008 outputs the results of calculations. Note that the above computer may be equipped with a GPU (Graphics Processing Unit) or TPU (Tensor processing unit) instead of the CPU 1004, or may be equipped with a GPU or TPU in addition to the CPU 1004. In that case, the processes may be shared and executed, for example, the GPU or TPU executes processes that require special calculations such as neural networks, and the CPU 1004 executes other processes.

With respect to the above embodiment, the following Supplementary Notes 1 and 2 are further disclosed.

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

<Appendix 2>
(Additional Note 1)
Memory,
at least one processor coupled to the memory;
Including,
The processor,
Calculate the depth of the NNL tree that includes 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;
determining 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 added to the first electronic currency;
Calculating a random number corresponding to the root node based on a seed of the first NNL tree;
determining a range of leaf nodes to be associated with the amount among the leaf nodes;
generating information indicating said random number, said depth, and said range as information to be added to the second electronic currency.
(Additional Note 2)
Memory,
at least one processor coupled to the memory;
Including,
The processor,
Calculate 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 the electronic currency to be issued by the smallest unit of the electronic currency;
Generate random numbers to be seeds of the NNL tree;
determining a range of leaf nodes to be associated with the amount among the leaf nodes;
a currency processing device that generates information indicating said random number, said depth, and said range as information to be added to said electronic currency to be issued.
(Additional Note 3)
Memory,
at least one processor coupled to the memory;
Including,
The processor,
A Merkle tree is generated based on the hash values of each of the multiple electronic currencies to be transferred;
a hash value of a root node of the Merkle tree and a signature for the hash value, the hash value being added to each of the plurality of electronic currencies.
(Additional Note 4)
a depth calculation step 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 step for determining a 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 added to the first electronic currency;
a random number calculation step for calculating a random number corresponding to the root node based on a seed of the first NNL tree;
a leaf node determination step for determining a range of leaf nodes to be associated with the amount among the leaf nodes;
a currency additional information generating step of generating information indicating the random number, the depth, and the range as information to be added to the second electronic currency;
A computer implemented currency processing method.
(Additional Note 5)
a depth calculation step of 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 random numbers to be seeds of the NNL tree;
a leaf node determination step for determining a range of leaf nodes to be associated with the amount among the leaf nodes;
a currency additional information generating step of generating information indicating the random number, the depth, and the range as information to be added to the electronic currency to be issued;
A computer implemented currency processing method.
(Additional Note 6)
A Merkle tree generation step of generating a Merkle tree based on hash values of each of a plurality of electronic currencies to be transferred;
a hash value of a root node of the Merkle tree and a signature for the hash value are added to each of the plurality of electronic currencies;
A computer implemented currency processing method.
(Additional Note 7)
A non-transitory storage medium storing a program for causing a computer to execute the currency processing method according to any one of claims 4 to 6.

(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 embodiment of the present invention has been described in detail above, the present invention is not limited to such a specific embodiment, and various modifications and changes are possible within the scope of the gist of the present invention described in the claims.

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 certification 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 section 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 (7)

An information processing device in an information system in which information in which a plurality of pieces of data each having a pair of a public key and a signature are linked is transmitted and received between information processing devices,
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 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 unit configured to transmit or receive information including the newly generated public key. The information processing device according to claim 1 , wherein an owner of the information processing device is a store, and the public key generated by the key generating unit is a public key indicating a pseudonym of the store. The information processing device according to claim 1 , wherein the key generation unit is provided within a secure processing unit. 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 generated using a private key. An information system including an information processing device according to any one of claims 1 to 4 and a server that generates the certificate. 1. An information processing method executed by an information processing device in an information system in which information is transmitted and received between information processing devices, the information being a concatenation of a plurality of data pieces each having a pair of a public key and a signature, comprising:
a key generation step of generating a new public key and private key pair and obtaining a certificate for the newly generated public key after a certain period of time has elapsed since the generation of the public key and private key pair, or after the generated public key or private key has been used a certain number of times;
an information distribution step of transmitting or receiving information including the newly generated public key. A program for causing a computer to function as each part of an information processing device according to any one of claims 1 to 4.

Images