JP7555869B2 - Business audit support system and business audit support method - Google Patents

Description

The present invention relates to a business audit support system and a business audit support method.

Distributed ledger technology using blockchain (hereafter referred to as BC) has emerged as a technology that replaces transactions that have traditionally been conducted via trusted centralized institutions such as financial institutions and governments with direct P2P (Peer to Peer) transactions between users.

Various derivatives of distributed ledger technology have been proposed and continue to evolve. The main features of distributed ledger technology today are: (1) transactions between participants in the distributed ledger are finalized through consensus building and approval by (any or specific) participants, rather than by a centralized authority; (2) multiple transactions are organized into blocks, which are recorded in a chain in a distributed ledger called a blockchain, and successive blocks are subjected to hash calculations, making tampering virtually impossible; and (3) all participants share the same ledger data, making it possible for all participants to confirm transactions.

Due to the above characteristics, distributed ledger technology using blockchain is being considered for application in a wide range of fields, including finance and manufacturing, as a mechanism for managing and sharing reliable data and executing and managing transactions based on contracts.

By using a platform that provides a distributed ledger (hereinafter referred to as the distributed ledger platform), multiple entities can share information and conduct transactions without being managed by a central authority (for example, a consortium in a specific industry or multiple companies related to a supply chain).

A blockchain or distributed ledger in which only computers authorized by a specific organization can participate in transactions is called a "consortium type." In a consortium type, there is a management body that authenticates participants, which has the advantage of speeding up transaction approval. For this reason, when using distributed ledger technology within a consortium in a specific industry, a consortium type distributed ledger platform is generally used.

In addition, some distributed ledger platforms are now able to manage not only transaction data but also logic describing transaction conditions in the distributed ledger, making them applicable to complex transaction conditions and a variety of applications. This logic is called a smart contract (hereinafter also referred to as SC).

Non-Patent Document 1 discloses technology related to distributed ledger platforms with SC execution functions. These distributed ledger platforms accept transactions (hereinafter also referred to as TX) while reaching a consensus at a predetermined consensus level between the nodes that make up the distributed ledger platform. Then, each node executes TX and stores the execution results of the TX, thereby sharing information (ledger) across multiple nodes. In addition, they are equipped with an SC execution function that executes predetermined logic on TX.

There are also attempts to improve the efficiency of business processes by using consortium-type BCs for cross-organizational operations. In this case, a ledger that stores the transaction history of all organizations participating in the BC will be shared between the organizations. This situation is not necessarily desirable from the perspective of confidentiality of each business. For this reason, an operating form in which the ledger is shared only between organizations that have a certain trading relationship is also envisioned.

In order to deal with such a situation, Non-Patent Document 1 discloses a concept called "Channel" that logically divides a distributed ledger. In this case, the distributed ledger infrastructure is a single distributed ledger infrastructure in which all organizations participate, but is internally logically divided into multiple distributed ledger infrastructures.

Hereinafter, a set of nodes belonging to this logically divided distributed ledger platform will be called a "subgroup." Nodes belonging to the above-mentioned subgroups share the distributed ledger only with nodes within that subgroup. In addition, when executing TX, each node executes the SC installed for each subsystem and updates the data in the distributed ledger linked to each subgroup.

As mentioned above, in a consortium-type blockchain, only computers authorized by a specific organization need to be able to participate in transactions. In the distributed ledger platform technology described in Non-Patent Document 1, nodes participating in transactions each hold a unique digital certificate to clarify the organization they belong to and their authority.

This digital certificate is issued by a certification authority node owned by each organization. The digital certificate is also digitally signed by the certification authority.

Meanwhile, the public key of the certification authority node itself is distributed to the entire organization in advance. Therefore, the validity of the certificate of the participating node can be confirmed by verifying the signature of the certification authority node written on the certificate of the participating node using that public key.

Furthermore, Non-Patent Document 1 discloses a technique for improving the security of a certificate authority node by storing a private key unique to each organization held by the certificate authority node on a Hardware Security Module (HSM) managed by each organization.

In this case, the CA node uses a public key cryptography standard such as PKCS#11 to create and manipulate private keys on the HSM. A typical HSM can store a tamper-proof record of access to the private key as an audit log.

On the other hand, consortium-type BC is called PaaS (Platform as a Service)
Several cloud vendors are beginning to appear that provide services in the form of managed blockchain services (e). Such services are called managed blockchain services (BC services). In BC services, in order to reduce the construction workload of customers, the construction and operation of distributed ledger nodes and certificate authority nodes is handled on behalf of the customer, while the construction of client nodes equipped with applications that access the distributed ledger and HSMs is generally carried out by the customer.

“Hyperledger Fabric”, [online], [Retrieved December 1, 2020], Internet <URL: http://hyperledger-fabric.readthedocs.io/en/latest/>

In existing blockchain services based on the technology disclosed in Non-Patent Document 1, the construction of the certificate authority node and distributed ledger node is handled by the blockchain service vendor. Therefore, customers who use the blockchain service must inform the blockchain service vendor of the access method (address, credential information) to the HSM that manages their organization's private keys.

This may result in a risk of the BC service vendor misusing the private key on the HSM. For example, if a BC service vendor colludes with a specific BC participating organization and issues a client certificate by misusing the private key of another organization, data tampering may occur through spoofing.

The object of the present invention is to provide technology that can detect fraudulent certificate issuance by BC service vendors.

The business audit support system of the present invention, which solves the above problem, is characterized in that, in a blockchain platform that stores a distributed ledger system in which a business network is formed by multiple distributed ledger nodes under multiple organizations, a first organization among the multiple organizations is in charge of managing the distributed ledger nodes and certification authority nodes under a second organization, and a specified audit node detects unauthorized access to the private key by the first organization by comparing the access history to the private key in the certification authority node held by the second organization and managed by the first organization with the access history to the certification authority node held by the second organization.

The business audit support method of the present invention is characterized in that, in a blockchain platform storing a distributed ledger system in which a business network is formed by multiple distributed ledger nodes under multiple organizations, a first organization among the multiple organizations is in charge of managing the distributed ledger nodes and certification authority nodes under a second organization, and a predetermined audit node detects unauthorized access to the private key by the first organization by comparing the access history to the private key in the certification authority node held by the second organization and managed by the first organization with the access history to the certification authority node held by the second organization.

This invention makes it possible to detect fraudulent certificate issuance by BC service vendors.

1 is a diagram illustrating an example of a configuration of a business audit support system according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of the configuration of a computer according to the present embodiment. FIG. 4 is a diagram illustrating an example of the configuration of an access log in the present embodiment. 11 is a diagram showing an example of the configuration of an information collection target management table in the present embodiment. FIG. FIG. 1 is a diagram illustrating an example of the configuration of a blockchain in this embodiment. 4 is a diagram showing an example of the configuration of state information in the present embodiment; FIG. FIG. 2 is a diagram illustrating an example of the configuration of a certificate revocation list in the present embodiment. FIG. 2 is a diagram showing an example of the configuration of a self-organization node list in the present embodiment. 10 is a diagram illustrating an example of the configuration of a certificate issuance log in the present embodiment. 10 is a diagram showing an example of the configuration of HSM access information in the present embodiment. 11 is a diagram illustrating an example of a configuration of a login ID management table in the present embodiment. FIG. 2 is a diagram illustrating an example of a configuration of a private key management table in the present embodiment. 10 is a diagram showing an example of the configuration of a signature execution log in the present embodiment. FIG. FIG. 2 is a diagram illustrating an example of a flow of a business audit support method according to the present embodiment. FIG. 2 is a diagram illustrating an example of a flow of a business audit support method according to the present embodiment. FIG. 2 is a diagram illustrating an example of a flow of a business audit support method according to the present embodiment. FIG. 2 is a diagram illustrating an example of a flow of a business audit support method according to the present embodiment. FIG. 11 is a diagram showing an example of output in this embodiment. FIG. 11 is a diagram showing an example of output in this embodiment. FIG. 11 is a diagram showing an example of output in this embodiment.

<System Configuration>
An embodiment of the present invention will be described in detail below with reference to the drawings. Fig. 1 is a diagram showing a network configuration including a business audit support system 10 according to the present embodiment. Here, business audit support system 10 is referred to as a computer system, and the configuration of the computer system and the configuration of nodes connected to the computer system are shown.

The overall configuration illustrated in Figure 1 is a schematic diagram of the configuration of a managed blockchain service (BC service).

The BC service is composed of two cloud platforms 45000, one for the BC service vendor and one for the customer. The cloud platforms 45000 are connected to each other via an Internet line 41000.

Of these, the customer-facing cloud infrastructure 45000 is composed of one or more client nodes 10000, one or more HSMs 35000, and one or more audit nodes 15000. These devices are connected to the internal network 40000 via physical or logical communication lines.

On the other hand, the cloud infrastructure 45000 for blockchain service vendors is composed of one or more distributed ledger nodes 20000 and one or more certificate authority nodes 30000. These devices are connected to the internal network 40000 via physical or logical communication lines.

In this embodiment, it is assumed that there are multiple distributed ledger nodes 20000, and that each distributed ledger node is managed by multiple organizations (e.g., multiple businesses/multiple organizations/multiple vendors) that make up the consortium.

Similarly, it is assumed that there are multiple client nodes 10000, and multiple organizations each use a different client node. In addition, there may be multiple certificate authority nodes 30000 and HSMs 35000 for each organization, and multiple certificate authority nodes and HSMs may coexist while sharing the same information, ensuring redundancy in the event of a failure.

The physical entities of the client node 10000, distributed ledger node 20000, auditor node 15000 and certificate authority node 30000 are general computers consisting of a processor 104, memory 103 and data bus 108 (see Figure 2; the same applies below).

In addition, each cloud platform has a separate DNS server that can perform DNS name resolution to match the name of each node (e.g., "peer1.org1.example.com") with the corresponding IP address.

The client node 10000 is composed of a transaction issuing unit 11000, a business application 12000, a certificate issuance request unit 13000, an access log 14000, and participating member management information 14100.

Of these, the business application 12000 receives input of business-related information from the user. The business application 12000 then issues a TX via the transaction issuing unit 11000 and transmits the user's input to the distributed ledger node 20000. The TX is signed and certified by the issuer, using the private key and certificate issued by the certification authority node 30000 and stored in the participating member management information 14100.

The audit node 15000 is composed of an audit processing unit 16000, an audit information collection unit 17000, and an information collection target management table 18000.

The distributed ledger node 20000 is composed of a transaction distribution unit 21000, a smart contract execution/management unit 22000 (hereinafter also referred to as the SC execution/management unit), a transaction management unit 23000, a subgroup management unit 24000, a distributed ledger 25000, participating member management information 29000, a certificate revocation list 29100, and a self-organization node list 29200. The distributed ledger 25000 is defined for each subgroup, and the same ledger is shared between nodes belonging to the subgroups.

The distributed ledger node 20000 accepts the TX using the function of the transaction management unit 23000, and if agreement has been reached with other organizations, deploys the SC and executes the deployed SC via the function of the SC execution/management unit 22000, and records the history of the TX and the results of its execution in the distributed ledger 25000.

In addition, the transaction management unit 23000 of the distributed ledger node 20000 provides functions/interfaces for accepting TX and obtaining/viewing TX history information in response to requests from each node, such as the client node 10000.

The transaction distribution unit 21000 provides the function of broadcasting transactions accepted by the transaction management unit 23000 to all distributed ledger nodes within the organization.

In the distributed ledger system of this embodiment, the members participating in the consortium, i.e., the organizations and distributed ledger nodes 20000, are managed by the distributed ledger 25000 of each organization. In addition, the subgroup management unit 24000 of the distributed ledger system provides functions for registering and adding new organizations and subgroups.

In addition, in the distributed ledger system of this embodiment, it is assumed that private keys and certificates are used to authenticate participating organizations, sign TX, control SC execution authority, etc. Information on the certificate and private key unique to each distributed ledger node is stored and managed in the participating member management information 29000 of the distributed ledger node 20000. Meanwhile, information on the root certificate of each organization is shared between all distributed ledger nodes.

Whenever a TX is received, the transaction manager 23000 of the distributed ledger node 20000 verifies whether the issuer of the TX is a valid authorized participant. In addition, the certificate revocation list 29100 registers the serial numbers of certificates that have been revoked by the certification authority node 30000.

Whenever the transaction management unit 23000 receives a TX, it checks whether the TX has been signed using an expired certificate, and if so, does not accept the TX.

The method for generating a pair of a certificate and a private key and the method for verifying a signature can be any known or publicly known technology, so they will not be described in detail in this embodiment.

The distributed ledger 25000 stores and manages smart contracts 26000 related to the business and the TX results by the SC. In this embodiment, the data structure of the TX results is assumed to be the blockchain 27000 for the TX history, and state information 28000 based on the execution results of the TX is held in table format.

The certificate authority node 30000 is composed of a certificate issuing unit 31000, a certificate issuance log 32000, and HSM access information 33000.

The HSM 35000 is composed of a signature execution unit 36000, an ID management table 37000, a private key management table 37200, and a signature execution log 37300.

In this embodiment, the HSM 35000 creates a private key in advance and stores it in the private key management table 37200, and also stores the ID and password of the user who can access the private key in the ID management table 37000.

The signature execution unit 36000 externally receives the ID and password of the user attempting to access the private key, the ID of the private key to be used, and the file to be signed. The signature execution unit 36000 then references the ID management table 37000 and the private key management table 38000 to determine whether the user has access authority to the specified private key, and if access authority exists, uses that key to sign the file to be signed.

<Hardware Configuration>
The hardware configuration of each computer 100 constituting the business audit support system 10 of this embodiment is as shown in FIG.

That is, the computer 100 includes a storage device 101, a memory 103, a processor 104, an input device 105, an output device 106, and a communication device 107.

Of these, the storage device 101 is composed of an appropriate non-volatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

In addition, memory 103 is composed of a volatile memory element such as RAM.

The processor 104 is a CPU that reads the program 102 stored in the storage device 101 into the memory 103 and executes it to perform overall control of the device itself as well as various judgments, calculations, and control processes.

The communication device 107 is assumed to be a network interface card or the like that is connected to the Internet 41000 and handles communication processing with external devices.

If the computer 100 is a standalone machine, it is preferable to further include an input device 105 that accepts key input or voice input from the user, and an output device 106 such as a display that displays the processing data.

In addition to programs 102 for implementing the functions required for the computer of this embodiment, data 1125 required for executing these programs 102 is also stored in the storage device 101.

<Data structure example>
Next, various types of information used by the computers constituting the business audit support system 10 of this embodiment will be described.

3 is a diagram showing an example of the configuration of an access log 14000 provided in the client node 10000. An entry is added to the access log 14000 when the client node 10000 makes a certificate issuance request to the certificate authority node 30000.

The access log 14000 includes, as its configuration items, a field 14010 for registering the date and time when the access occurred, a field 14020 for registering the name of the certificate authority node 30000 that was the destination of the access, a field 14030 for registering the identifier of the certificate obtained from the certificate authority node 30000 by the access, and a field 14040 for registering the serial number of the certificate.

Figure 4 shows an example of the configuration of the information collection target management table 18000 provided by the audit node 15000.

The information collection target management table 18000 includes as configuration items a field 18010 for registering the domain name of the organization to be audited, a field 18020 for registering the type of node to be audited, and a field 18030 for registering the name of the node to be audited.

Figures 5 and 6 are examples of data structures stored in the distributed ledger 25000 provided by the distributed ledger node 20000.

Figure 5 is an example of a blockchain 27000, which is one of the data structures managed on a distributed ledger 25000. In distributed ledger management using blockchain, multiple TXs are grouped together as blocks, and data is managed in a linked manner by each block having the hash value of the previous block.

If even one bit of the value of the previous block changes, the hash values of all subsequent blocks change, making tampering difficult. Note that in this embodiment, for simplicity's sake, one TX is stored as one block, but the present invention can also be applied to cases where multiple TXs are stored together in one block.

The BC shown in FIG. 5 is composed of a series of blocks 27010 to 27030. Each block contains TX information for either deploying or executing the SC. Each block also contains a hash value 27100 of the previous block, and a hash value 27200 generated from state information described below.

With the data structure described above, the history information of subgroup creation, SC deployment, and execution is managed as a data chain within the BC.

Of these, block 27010 is an example of a block that stores initial information for a subgroup. In the initial block 27300 of this embodiment, the ID of the subgroup linked to the distributed ledger is defined. In addition, a list of domain names and root certificates of organizations belonging to the subgroup, and the name of the distributed ledger node that represents each organization are defined. In addition, it includes the conditions necessary to obtain approval of a transaction between participating organizations.

Block 27020 is an example of a block that stores the deploy TX of an SC. In this embodiment, the deploy TX 27400 includes a contract ID that uniquely identifies the contract and the logic of the contract (e.g., an executable binary).

It also includes contract input specifications that allow users to understand the function names and arguments that the contract has.

In this example, "Remittance" is defined as the function name of the SC with the ID "Remittance Business", and the logic of the function is also defined. Furthermore, it includes the ID of the issuer of this Deploy TX and a digital signature used to verify that the data has not been tampered with. It also includes an ID that is a unique identifier of the TX.

Block 27030 is an example of a block that stores the execution TX of an SC. In this embodiment, the execution TX 27500 includes the contract ID of the contract to be called, the function name of the contract to be called, and information on the arguments to be input.

In this example, the function "Remittance" of the SC with the ID "Remittance Operation" is called, and its arguments are the remittance organization ID, the receiving organization ID, and the amount, and the values are "Org1", "Org3", and "100", respectively.

In addition, it contains the ID of the issuer of this TX and a digital signature used to verify that the data has not been tampered with. In addition to the issuer, information on the nodes involved in the consensus formation is also managed.
It may also contain an ID, which is a unique identifier of the TX within the distributed ledger.

Figure 6 shows state information 28000 managed on a distributed ledger. In distributed ledger management using a BC, one must usually trace the BC to obtain the latest state (for example, the account balance in the case of virtual currency). This is inefficient, so there is a method of caching the latest state information separately from the BC (Non-Patent Document 1, etc.).

In this embodiment, it is assumed that the latest state information will be stored. In this embodiment, a state data area is prepared for each function that the smart contract has.

The state information 28000 holds the ID 28010, which is the identifier of the smart contract, the entity 28020 of that smart contract, and the identifier 28300 of the subgroup linked to the smart contract.

This allows the SC execution/management unit to obtain and execute the entity of the smart contract using the contract ID and function name as keys. In addition, the state information includes an internal table 28040 for holding the execution results of the SC.

The contents of this internal table are updated each time TX is executed. Internal table 28040 of state information 28000 is composed of a table called "owned amount data," and is overwritten as needed with the information specified by the TX arguments.

Figure 7 shows an example of the configuration of the certificate revocation list 29100 provided in the distributed ledger node 20000. The certificate revocation list 29100 is created when a certificate revocation request is made to the certificate authority node 30000 from an external source such as the client node 10000, and becomes valid when the BC service vendor places it in the distributed ledger node 20000 as needed.

In addition, there may be a mechanism whereby the certificate authority node 30000 automatically distributes a certificate revocation request to all distributed ledger nodes 20000 each time the certificate authority node 30000 receives the request.

The certificate revocation list 29100 includes, as configuration items, a field 29110 for registering the identifier of a certificate that has been revoked by the certificate authority node 30000, and a field 29120 for registering the serial number of that certificate.

8 is a diagram showing an example of the configuration of the own-organization node list 29200 included in the distributed ledger node 20000. The own-organization node list 29200 is automatically generated by the transaction distributors 21000 in the distributed ledger node 20000 communicating with each other.

The self-organization node list 29200 includes as its configuration items a field 29210 for registering the names of nodes belonging to the same organization as the distributed ledger node.

Figure 9 is a diagram showing an example of the configuration of the certificate issuance log 32000 provided in the certificate authority node 30000. The certificate issuance log 32000 is appended when a certificate issuance request is made to the certificate authority node 30000 from an external source such as the client node 10000.

The certificate issuance log 32000 includes, as configuration items, a field 32010 for registering the date and time when the access occurred, a field 32020 for registering the purpose of the certificate issued by the access, a field 32030 for registering the identifier of the certificate issued by the certification authority node by the access, and a field 32040 for registering the serial number of the certificate.

Figure 10 shows an example of the configuration of HSM access information 33000 provided by the certificate authority node 30000.

The HSM access information 33000 includes, as configuration items, a field 33010 for registering the name of the HSM 35000 to be accessed by the certificate authority node 30000, a field 33020 for registering the ID used to log in to the HSM 35000, and a field 33030 for registering the password used to log in to the HSM 35000.

Figure 11 shows an example of the configuration of the login ID management table 37000 provided in the HSM 35000.

The login ID management table 37000 includes as configuration items a field 37010 for registering an ID used to log in to the HSM 35000 from outside, a field 37020 for registering a password used to log in to the HSM 35000, and a field 37030 for registering an identifier of a private key that can be used when logging in to the HSM 35000 using the account.

Figure 12 is a diagram showing an example of the configuration of a private key management table 37100 provided in the HSM 35000. The private key management table 37100 includes, as configuration items, a field 37110 for registering an identifier of a private key issued by the HSM 35000, and a field 37120 for registering the binary of the private key.

Figure 13 is a diagram showing an example of the configuration of the signature execution log 37200 provided in the HSM 35000. The signature execution log 37200 is added when a signature execution request is made to the HSM 35000 from an external source such as the certificate authority node 30000.

The signature execution log 37200 includes as its configuration items a field 37210 for registering the date and time when the access occurred, a field 37220 for registering the name of the node that performed the access, and a field 37230 for registering the identifier of the private key used during the access.

<Flow Example 1>
The actual procedure of the business audit support method according to this embodiment will be described below with reference to the drawings. The various operations corresponding to the business audit support method described below are realized by a program that is read into memory or the like and executed by the computer 100. This program is made up of codes for performing the various operations described below.

Figure 14 is a flowchart showing an example of a new subgroup creation process of the subgroup management unit 21400 of the distributed ledger node 20000. The specific internal process is shown below.

When multiple organizations on the blockchain wish to create a new subgroup, the administrator of the blockchain service will determine the subgroup ID, the domain name of the participating organization, the root certificate of the participating organization, the name of the representative node of the participating organization, and the transaction approval conditions in advance, and input them into the subgroup management unit 21400.

The subgroup management unit 21400 creates an initial block based on this information (step 51010).

Next, the subgroup management unit 21400 distributes the created initial block to the subgroup management units of other distributed ledger nodes (step 51020).

In addition, the subgroup management unit 21400 of each organization creates a distributed ledger that includes a blockchain starting from the initial block (step 51030).

<Flow Example 2>
FIG. 15 is a flowchart showing an example of the TX execution process of the distributed ledger node 20000, i.e., the deployment and execution of an SC.

The client node 10000 issues a transaction to the transaction manager 21300 of the distributed ledger node 20000 of each participating organization to obtain the approval required to execute the transaction (step 52010).

The contents of TX are the name of the SC to be executed, the name of the function, and arguments. When issuing TX, the client node 10000 signs the TX using its own private key and sends it together with a certificate. The certificate and private key were issued in advance by the certification authority node 30000 through the certificate issuance process shown in Figure 16.

When the transaction management unit 21300 of the distributed ledger node 20000 receives TX from the client node 10000, it verifies whether the signature of the client node 1000 attached to the transaction and the certificate sent at the same time are valid by comparing them with the root certificate in the initial block (step 52020).

If the transaction is valid, distributed ledger node 20000 signs the TX using its private key (step 52030). Distributed ledger node 20000 then returns the signed TX to client node 10000 (step 52040).

When the client node 10000 receives the signed TX from each distributed ledger node, it assumes that consensus has been reached and requests the transaction management unit 21300 of its own organization's distributed ledger node 20000 to distribute the TX (step 52050).

The transaction manager 21300 of the distributed ledger node 20000 sends the TX to the transaction distributor 21000. The transaction distributor 21000 assigns an ID to the TX and requests the representative distributed ledger nodes of other organizations recorded in the initial block to distribute the TX (step 52060).

The representative distributed ledger node of each organization refers to the participating member management information 29000 and distributes the transaction to other distributed ledger nodes within its own organization (step 52070). The SC executor/manager unit 22000 of each distributed ledger node 20000 that receives the TX registers the received TX in the distributed ledger 25000.

At that time, if the contents of the TX relate to the deployment of the SC, the contract ID and contract entity are registered as state information 28000 on the distributed ledger, and a block containing this TX is added to the end of the blockchain 27000.

If the contents of TX are related to the execution of a function defined in the SC, the SC with the contract ID specified in the TX is executed by providing the call function and input arguments specified in the TX.

Then, based on the result, the contents of the distributed ledger 25000 are updated. That is, based on the execution result, the state information 28000 regarding this contract is updated, and the execution TX is added as the last block of the blockchain 27000 (step 52080).

In this embodiment, the broadcast processing in steps 52060 and 52070 is performed by distributed ledger node 20000, but this may also be performed by a separate node dedicated to transaction distribution.

<Flow Example 3>
16 is a flowchart showing an example of a certificate issuing process of the certificate issuing unit 31000 included in the certificate authority node 30000. A specific internal process is shown below.

A client administrator who wishes to obtain a certificate and private key for the client node 10000 accesses the certificate issuing unit 31000 of the certification authority node 30000 through the certificate issuance request unit 13000 of the client node 10000, and requests the issuance of a certificate.

On the other hand, a BC service administrator who wishes to obtain a certificate and private key for a distributed ledger node in order to build the distributed ledger node directly accesses the certificate issuing unit 31000 of the certification authority node 30000 and performs a certificate issuance operation. In this case, the certificate issuing unit 31000 of the certification authority node 30000 requests the issuance of a certificate (step 53010).

When requesting a certificate, you must specify its purpose (for distributed ledger node or client node). The purpose is recorded inside the certificate and cannot be diverted for a different purpose.

Next, the certificate issuing unit 31000 creates a private key and public key pair (step 53020). Next, the certificate issuing unit 31000 uses the HSM access information to access the private key in the HSM, and signs the public key to create a certificate (step 53030).

Finally, the certificate issuing unit returns the created certificate and private key to the requester (step 53040).

<Flow Example 4>
17 is a flowchart showing an example of the audit processing of the audit processing module 16000 provided in the audit node 15000. A specific internal process is shown below.

The administrator of an organization that uses the BC service can access the audit processing unit 11000 of the audit node 15000.
The user accesses 6000, specifies the domain name of the organization, and issues an instruction to execute an audit.

When the audit processing unit 16000 receives the above instruction, it instructs the audit information collection unit 17000 to collect the necessary information. The audit information collection unit 17000 refers to the information collection target management table 18000, identifies the client nodes 10000 owned by the organization, and collects the access logs (step 54010).

Next, the audit information collection unit 17000 refers to the information collection target management table 18000 to identify the certificate authority node 30000 owned by the organization, and collects the certificate issuance log from the certificate authority node 30000 (step 54020).

Next, the audit processing unit 16000 calculates (A) the number of certificate generation requests in the client node 10000 and (B) the number of client node certificates issued in the certification authority node 30000 based on the information collected by the audit information collection unit 17000, and compares them (step 54030).

If the result of the above comparison shows that (A) is less than (B), the audit processing unit 16000 returns a response (see FIG. 18) to the administrator that "there is a possibility that the client certificate was fraudulently created by the cloud vendor, etc." (step 54040). On the other hand, if the result of the above comparison shows that (A) and (B) are the same in number, the process proceeds to the next step.

The following is an explanation using the example data shown in the figure. First, the administrator of the organization org1.example.com instructs the audit node to perform an audit. The audit information collection unit refers to the information collection target management table shown in Figure 4, identifies the client node (client1.org1.example.com) owned by the organization org1.example.com, and collects the access log (Figure 3).

Next, the audit information collection unit 17000 refers to the information collection target management table 18000 to identify the certification authority node (ca.org1.example.com) owned by the organization, and collects the certificate issuance log (Figure 9).

As a result, the audit processing unit 16000 determines that (A) the number of certificate generation requests in the client node 10000 and (B) the number of client node certificates issued in the certification authority node are both two, which is the same number, and proceeds to the next step 54050. On the other hand, if (B) is greater, it is determined that there is a possibility that the BC service vendor has created client certificates fraudulently.

Next, the audit information collection unit 17000 refers to the information collection target management table 18000 to identify the distributed ledger node owned by the organization, and collects the organization's own node list and revoked certificate list from the distributed ledger node (step 54050).

Next, the audit information collection unit 17000 refers to the information collection target management table 18000 to identify the HSM 35000 owned by the organization, and collects the signature execution log from the HSM 35000 (step 54060).

Next, based on the information collected by the audit information collection unit 17000, the audit processing unit 16000 calculates and compares (C) the number of distributed ledger nodes in the organization, (D) the number of revoked certificates for distributed ledger nodes in its own organization, and (E) the number of signatures made using the private key in the HSM (step 54070).

If the result of the above comparison is that the total value of (A), (C), and (D) is less than (E), the audit processing unit 16000 returns a response (see FIG. 19) to the administrator that “there is a possibility of unauthorized use of the private key in the HSM by a cloud vendor, etc.” (step 54080).

On the other hand, if the result of the above comparison is that the total value of (A), (C), and (D) is the same as (E), the audit processing unit returns a response (see FIG. 20) to the administrator that "there is no possibility of fraud by the cloud vendor, etc." (step 54090).

The following will be explained using the example data shown in the drawings. The audit information collection unit 17000 refers to the information collection target management table 18000 shown in FIG. 4, identifies the distributed ledger node (peer1.org1.example.com) owned by the organization org1.example.com, and collects the local organization node list (FIG. 8) and the revoked certificate list (FIG. 7).

Next, the audit information collection unit 17000 refers to the information collection target management table 18000 to identify the HSM (hsm.org1.example.com) owned by the organization, and collects the signature execution log (Figure 9).

As a result, the audit processing unit 16000 calculates that (C) the number of distributed ledger nodes in the organization = 2, (D) the number of revoked certificates for distributed ledger nodes in the organization = 1, and (E) the number of signatures using the private key in the HSM = 5.

Based on this result, it is determined that the total values of (A), (C), and (D) are all equal at 5, and a response is returned to the administrator stating that there is no possibility of fraud by the cloud vendor, etc. (see Figure 20).

On the other hand, if (E) is prevalent, it is possible that the BC service vendor may have illegally accessed the private key in the HSM and performed actions such as issuing certificates.

Note that it is not necessary to perform all of the above steps, and obtaining any of the information (A) through (E) may be omitted.

In this embodiment, the certificate authority node 30000 may also be configured to hold the private key directly without using the HSM 35000. In that case, the above-mentioned "(E) number of signatures using the private key in the HSM" may be determined from the number of certificates issued contained in the certificate issuance log 32000 in the certificate authority node 30000.

In such cases, the logs must be stored using a tamper-proof third-party log storage service to prevent the BC service vendor from tampering with them after the fact.

As described above, by using this invention, each organization that uses a BC service can detect whether or not the BC service vendor has misused a private key on an HSM, using only logs and configuration information that the BC service vendor cannot directly manipulate.

On the other hand, by providing the audit function of this invention to their customers, BC service vendors can ensure the reliability of the security of their BC services and increase the value of their services.

The above describes in detail the best mode for carrying out the present invention, but the present invention is not limited to this, and various modifications are possible without departing from the spirit of the present invention.

According to this embodiment, each organization can manage logs and configuration information by itself, specifically, access logs from client nodes to certificate authority nodes, configuration information of distributed ledger nodes, H
By checking the history log of signatures made using the private key on the SM, it is possible to detect fraudulent certificate issuance by the BC service vendor. System administrators in each organization can detect fraudulent activities by the BC service vendor by periodically running an audit tool with such functionality.

On the other hand, by providing customers with auditing functions using the above-mentioned methods, BC service vendors can ensure the reliability of the security of their BC services and increase the value of their services.

In other words, it will be possible to detect fraudulent certificate issuance by BC service vendors.

The description in this specification makes clear at least the following. That is, in the business audit support system of this embodiment, the audit node may compare the certificate creation history by the certification authority node held by the second organization and managed by the first organization with the access history to the certification authority node held by the second organization, and detect fraudulent certificate issuance by the first organization using the certification authority.

This makes it possible to more efficiently detect fraudulent certificate issuance by BC service vendors by comparing the certificate creation history with the access history to the certification authority node.

In addition, in the business audit support system of this embodiment, the private key in the certificate authority node held by the second organization may be managed in dedicated hardware held by the second organization.

This means that information management using so-called HSMs will make it possible to more securely and accurately detect fraudulent certificate issuance by BC service vendors.

In addition, in the business audit support system of this embodiment, the audit node may obtain configuration information of the distributed ledger node held by the second organization in addition to the access history to the certificate authority node held by the second organization, and use this information to detect unauthorized access to the private key by the first organization.

By detecting unauthorized access based on the configuration information of the distributed ledger node, it becomes possible to detect fraudulent certificate issuance by blockchain service vendors more efficiently and accurately.

In addition, in the business audit support system of this embodiment, the audit node may obtain a certificate revocation list indicating revoked certificates among the certificates issued by the certificate authority node held by the second organization, in addition to the access history to the certificate authority node held by the second organization, and use the list to detect unauthorized access to the private key by the first organization.

This makes it possible to more efficiently detect fraudulent certificate issuance by BC service vendors based on certificate revocation lists.

In addition, in the business audit support method of this embodiment, the audit node may compare the certificate creation history by the certification authority node held by the second organization and managed by the first organization with the access history to the certification authority node held by the second organization, and detect fraudulent certificate issuance by the first organization using the certification authority.

In the business audit support method of the present embodiment, a private key in a certificate authority node held by the second organization may be managed in dedicated hardware held by the second organization.

In addition, in the business audit support method of this embodiment, the audit node may obtain configuration information of the distributed ledger node held by the second organization in addition to the access history to the certificate authority node held by the second organization, and use this information to detect unauthorized access to the private key by the first organization.

In addition, in the business audit support method of this embodiment, the audit node may obtain a certificate revocation list indicating revoked certificates among the certificates issued by the certificate authority node held by the second organization, in addition to the access history to the certificate authority node held by the second organization, and use the list to detect unauthorized access to the private key by the first organization.

10 Business audit support system 100 Computer 101 Storage device 102 Program 103 Memory 104 Computing device 105 Input device 106 Output device 107 Communication device 125 Data 10000 Client node 11000 Transaction issuing unit 12000 Business application 13000 Certificate issuance request unit 14000 Access log 15000 Audit node 16000 Audit processing unit 17000 Audit information collection unit 18000 Information collection target management table 20000 Distributed ledger node 21000 Transaction distribution unit 22000 Smart contract execution/management unit 23000 Transaction management unit 24000 Subgroup management unit 25000 Distributed ledger 26000 Smart contract 27000 Blockchain 28000 State information 29000 Participating member management information 29100 Certificate revocation list 29200 Own organization node list 30000 Certificate authority node 31000 Certificate issuing unit 32000 Certificate issuance log 33000 HSM access information 35000 HSM
36000 Signature execution unit 37000 Login ID management table 37100 Private key management table 37200 Signature execution log 40000 Internal network 41000 Internet 45000 Cloud platform

Claims (8)

In a blockchain platform that stores a distributed ledger system in which a business network is composed of multiple distributed ledger nodes under multiple organizations,
In an operation in which a first organization among the multiple organizations acts as a proxy for management of a distributed ledger node and a certificate authority node under a second organization, a predetermined audit node detects unauthorized access to the private key by the first organization by comparing an access history to the private key in the certificate authority node held by the second organization and managed by the first organization with an access history to the certificate authority node held by the second organization;
This is a business audit support system that features the following: In the dedicated hardware maintained by the second organization,
A certificate authority node that manages a private key in the certificate authority node held by the second organization.
2. The business audit support system according to claim 1, The audit node:
The system obtains configuration information of a distributed ledger node held by the second organization in addition to an access history of the certificate authority node held by the second organization, and uses the information to detect unauthorized access to the private key by the first organization.
2. The business audit support system according to claim 1, The audit node:
a certificate revocation list indicating revoked certificates among the certificates issued by the certificate authority node held by the second organization, in addition to an access history to the certificate authority node held by the second organization, is obtained, and the obtained certificate revocation list is used to detect unauthorized access to the private key by the first organization.
2. The business audit support system according to claim 1, In a blockchain platform that stores a distributed ledger system in which a business network is composed of multiple distributed ledger nodes under multiple organizations,
In an operation in which a first organization among the multiple organizations acts as a proxy for management of a distributed ledger node and a certificate authority node under a second organization, a predetermined audit node detects unauthorized access to the private key by the first organization by comparing an access history to the private key in the certificate authority node held by the second organization and managed by the first organization with an access history to the certificate authority node held by the second organization;
A method for supporting business audits, characterized by: In the dedicated hardware maintained by the second organization,
Manage a private key in a certificate authority node held by the second organization;
6. The business audit support method according to claim 5, The audit node:
acquiring configuration information of a distributed ledger node held by the second organization in addition to an access history of the certificate authority node held by the second organization, and using the information to detect unauthorized access to the private key by the first organization;
6. The business audit support method according to claim 5, The audit node:
obtaining a certificate revocation list indicating revoked certificates among the certificates issued by the certificate authority node held by the second organization in addition to an access history to the certificate authority node held by the second organization, and using the list to detect unauthorized access to the private key by the first organization;
6. The business audit support method according to claim 5,

Images