Information processing apparatus, information processing system, and information processing method

Abstract

To provide an information processor, an information processing system and an information processing method for reducing the update frequency of the verification information of software with respect to the update of dependency to be frequently generated.SOLUTION: In an information processing system, a software issuing unit of a provider system includes a first digest calculating unit that calculates a target digest that is a digest used for generation of an electronic signature used for verification of software by a predetermined business operator, and an electronic signature adding unit that adds an electronic signature generated on the basis of the target digest to the software, and the first digest calculating unit extracts a part describing a dependency relation related to utilization software used by the software or to be used by the software among a plurality of files included in the software, and calculates the target digest on the basis of the extracted part.SELECTED DRAWING: Figure 1

Description

[Technical Field]

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

[0002] In software development in the IT (Information Technology) field, it has become common to use a wide variety of existing software as "dependencies." This trend has become particularly pronounced with the use of open source software. As the number of related software increases, the number of stakeholders also increases, increasing the risk of malicious or vulnerable code being introduced into the software. In this situation, software supply chain security, which ensures the safety of software, is attracting attention.

[0003] On the other hand, in SI (System Integration), a customer who orders software is required to conduct acceptance tests on the software created by the software provider, and the provider is then required to officially deliver the software that passes the acceptance tests. In many cases, customers conduct acceptance tests using build deliverables (containers are used as an example below) or source code. The provider can then guarantee that the software delivered has been accepted and tested by the customer by attaching the customer's digital signature to the container image or source code that has passed the acceptance test. This is because if the software provider modifies the software, the customer will be able to detect a discrepancy in the digital signature during verification at the time of delivery and become aware of the software modification.

[0004] Patent Document 1 discloses a technology for verifying the integrity of software installed by a software package (for example, that files have not been modified or tampered with). The technology described in Patent Document 1 generates verification information used for verifying software, including file paths and hash values ​​of files stored in the directory where the software is installed. This makes it possible to generate verification information for software packages in which the user specifies the installation destination of the software, or for software packages in which various setting information is changed depending on the installation environment. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] International Publication No. 2021 / 014596 Summary of the Invention [Problem to be solved by the invention]

[0006] When an update to address a vulnerability or other issue is made to one of a large number of dependent software programs, the dependent software is also updated. The more dependent software programs there are, the more frequently updates occur. However, because updates to address vulnerabilities or other issues do not involve changes to the software's specifications or functions, there are cases where acceptance testing is not required for such updates. However, the technology described in Patent Document 1 calculates hash values ​​for the entire group of files at a given point in time, so verification information (e.g., digital signatures) must be updated every time the dependency relationships change. In other words, the technology described in Patent Document 1 has the problem of requiring re-implementing acceptance testing and updating the customer's digital signature every time the dependency relationships change.

[0007] The present invention has been made in consideration of the above circumstances, and its purpose is to provide an information processing device, an information processing system, and an information processing method that can reduce the frequency of updating software verification information in response to dependency updates, which can occur frequently. [Means for solving the problem]

[0008] One aspect of the present invention for solving the above problem is an information processing device having a processor and memory, and including a first digest calculation unit that calculates a target digest, which is a digest used to generate an electronic signature used for verifying software by a specified business operator, and an electronic signature addition unit that adds an electronic signature generated based on the target digest to the software, wherein the first digest calculation unit extracts, from a plurality of files included in the software, a portion that describes dependencies related to software used by the software or used by the software, and calculates the target digest based on the extracted portion. [Effects of the Invention]

[0009] According to the present invention, it is possible to reduce the frequency of updating software verification information in response to dependency updates that may occur frequently. Configurations and effects other than those described above will become apparent from the following description of the embodiments. [Brief explanation of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an example of the configuration of an information processing system. [Figure 2] FIG. 2 is a diagram illustrating an example of the configuration of a first digest calculation unit. [Figure 3] FIG. 10 is a diagram illustrating an example of a target file pattern list. [Figure 4] FIG. 10 is a diagram illustrating an example of a dependency description file pattern list. [Figure 5] FIG. 10 is a diagram illustrating an example of a list of past electronic signatures. [Figure 6]FIG. 10 is a diagram illustrating an example of a UAT accepted list. [Figure 7] FIG. 2 is a diagram illustrating an example of the hardware configuration of a provider system and an orderer system. [Figure 8] FIG. 10 is a flowchart illustrating an outline of processing performed in the provider-side system. [Figure 9] FIG. 10 illustrates an example of a test proof. [Figure 10] FIG. 10 is a diagram illustrating an example of a digital signature request. [Figure 11] FIG. 10 illustrates an example of signed software. [Figure 12] FIG. 10 is a flow diagram illustrating electronic signature processing performed in the orderer system. [Figure 13] FIG. 4 is a flow diagram illustrating a verification process performed in the orderer system in the first embodiment. [Figure 14] FIG. 4 is a flowchart illustrating details of a digest calculation process in the first embodiment. [Figure 15] FIG. 10 is a flowchart illustrating details of a normal file digest calculation process. [Figure 16] FIG. 10 is a flowchart illustrating details of a dependency description file digest calculation process in the first embodiment. [Figure 17] FIG. 10 is a diagram illustrating an example of a dependency description file. [Figure 18] FIG. 4 is a diagram illustrating an example of a dependency relationship list according to the first embodiment. [Figure 19] FIG. 3 is a diagram illustrating an example of a file list according to the first embodiment. [Figure 20] FIG. 10 is a flowchart illustrating details of a dependency description file digest calculation process in the second embodiment. [Figure 21] FIG. 10 is a diagram illustrating an example of a dependency list according to the second embodiment. [Figure 22] FIG. 11 is a flowchart illustrating details of a digest calculation process in the third embodiment. [Figure 23] FIG. 13 is a diagram illustrating an example of a file list according to the third embodiment. [Figure 24] FIG. 11 is a flow diagram illustrating a verification process performed in the orderer system according to the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0011] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. The following description and drawings are examples for explaining the present invention, and some omissions and simplifications have been made as appropriate for clarity of explanation. The present invention can be implemented in various other forms. Unless otherwise specified, each component may be singular or plural. In order to facilitate understanding of the invention, the position, size, shape, range, etc. of each component shown in the drawings may not represent the actual position, size, shape, range, etc. Therefore, the present invention is not necessarily limited to the position, size, shape, range, etc. disclosed in the drawings. In the following explanation, various types of information may be described using expressions such as "table," "list," and "queue," but the various types of information may also be expressed using data structures other than these. To indicate that the information is not dependent on the data structure, "XX table," "XX list," etc. may be referred to as "XX information." When describing identification information, expressions such as "identification information," "identifier," "name," "ID," and "number" are used, but these are interchangeable. When there are multiple components with the same or similar functions, they may be described using the same reference numeral with different subscripts. However, when there is no need to distinguish between these multiple components, the subscripts may be omitted. Furthermore, in the following description, processing performed by executing a program may be described, but the program is executed by a processor (e.g., a CPU or a GPU) to perform the specified processing while appropriately using storage resources (e.g., a memory) and / or interface devices (e.g., a communication port), and therefore the subject of the processing may be the processor. Similarly, the subject of the processing performed by executing a program may be a controller, device, system, computer, or node having a processor. The subject of the processing performed by executing a program may be any computing unit, and may include a dedicated circuit (e.g., an FPGA or an ASIC) that performs a specific processing. A program may be installed on a device such as a computer from a program source. The program source may be, for example, a program distribution server or a computer-readable storage medium. If the program source is a program distribution server, the program distribution server may include a processor and storage resources for storing the program to be distributed, and the processor of the program distribution server may distribute the program to be distributed to other computers. Also, in the following description, two or more programs may be realized as one program, and one program may be realized as two or more programs.

[0012] [First embodiment] First, an information processing system and an information processing method according to the first embodiment will be described.

[0013] <<System Configuration>> FIG. 1 is a diagram showing an example of the configuration of an information processing system 1 according to this embodiment. The information processing system 1 is a software digital signature and verification system for delivering the software 110 from a provider who provides the software 110 to a predetermined business (in this embodiment, this is an orderer who is a customer who receives the software 110 from the provider, but this is not particularly limited). The orderer performs an acceptance test on the software 110, and affixes an orderer digital signature, which is the digital signature of the orderer, to the software 110 that passes the acceptance test. The provider delivers the software 110 affixed with the orderer digital signature to the orderer. Then, by verifying the orderer digital signature affixed to the delivered software 110, the orderer can confirm that the delivered software is the same software 110 that passed the acceptance test.

[0014] The software 110 is a container or software. Software here refers to a package including source code and a dependency description file. Here, the software 110 utilizes one or more open source software programs. In software development using open source software, it is common and recommended to manage the open source software using a package management system. A package management system automatically handles complex software dependencies. A developer simply describes the open source software (hereinafter sometimes referred to as "dependent software" or "used software") that the software they are developing uses or that is used by the software they are developing in a dependency description file. The package management system resolves the dependencies and automatically installs the required dependent software or uninstalls the unnecessary software. The dependency description file is managed together with the source code of the software being developed. The dependency description file describes, for example, the package name and version of the dependent software.

[0015] On the other hand, when using a large amount of open source software, the likelihood of a vulnerability being discovered in one of the pieces of software increases. When a version that addresses a discovered vulnerability is released, the dependent software must be updated. Because the version of the dependent software is described in a dependency description file in the source code, this file must be modified and the software 110 must be rebuilt. In other words, whether a container or software is delivered, changes are made to the delivered product, invalidating the customer's digital signature based on the acceptance test. However, because updating to a version that addresses a vulnerability does not involve changes to specifications or functionality, there is a desire to complete the update with only regression testing on the provider's side, avoiding further acceptance testing, and releasing the software quickly.

[0016] Therefore, the information processing system 1 according to this embodiment is devised with a method for calculating a digest used to generate an orderer's digital signature to guarantee the quality of the delivered software 110. Specifically, the information processing system 1 generates a digest, which is the subject of the orderer's digital signature, for the dependency description file by taking a hash value from only the package name (name) of the dependent software (i.e., excluding the version). As a result, even if the dependent software is updated, the orderer's digital signature remains valid, eliminating the need for another acceptance test on the customer side.

[0017] 1, the information processing system 1 includes a provider-side system 10 (first system) managed by a provider-side (first user) and an orderer-side system 20 (second system) managed by an orderer-side (second user). The provider-side system 10 and the orderer-side system 20 are communicably connected by a wired or wireless communication network such as the Internet, a LAN (Local Area Network), a WAN (Wide Area Network), or a dedicated line.

[0018] <Provider system> The provider system 10 includes a software issuing unit 100 that issues software to the client side. The software issuing unit 100 includes functional units, such as an automatic testing unit 101, a test signature unit 102, a first digest calculation unit 103, a digital signature request unit 104, a digital signature receiving unit 105, a digital signature adding unit 106, and a software transmitting unit 107. The software issuing unit 100 also stores software 110, which is the delivered product, a provider private key 120, which is the private key of the provider, and a past digital signature list 300, which is a list of digital signatures previously added to the software 110 by the client side.

[0019] The automatic test unit 101 executes an automatic test of the software 110 .

[0020] The test signature unit 102 generates a test certificate from a digest of the software 110 that has passed the automated test, and adds a provider digital signature to the generated test certificate using the provider private key 120 .

[0021] The first digest calculation unit 103 calculates, from the software 110, a digest to be the subject of the orderer's digital signature.

[0022] 2 is a diagram showing an example of the configuration of first digest calculation unit 103. First digest calculation unit 103 includes functional units of normal file digest calculation unit 131 and dependency description file digest calculation unit 132. In addition, first digest calculation unit 103 stores target file pattern list 133 and dependency description file pattern list 134 in advance.

[0023] The normal file digest calculation unit 131 calculates the digest of normal files other than the dependency description file. For example, the normal file digest calculation unit 131 calculates a list of all normal files and a hash value of a list of hash values ​​of each normal file.

[0024] The dependency description file digest calculation unit 132 calculates the digest of the dependency description file excluding some or all of the versions of the dependent software (used software). In this embodiment, the dependency description file digest calculation unit 132 calculates the digest of the dependency description file using only the names of the dependent software. For example, the dependency description file digest calculation unit 132 calculates a hash value of a list of the names of the dependent software.

[0025] The first digest calculation unit 103 calculates a target digest, which is a digest of the software 110, based on the digest of the dependency description file and the digest of the normal file.

[0026] (Target file pattern list) FIG. 3 is a diagram showing an example of a target file pattern list. The target file pattern list 133 is a list of target file patterns (hereinafter, sometimes referred to as "target file patterns") used to calculate the target digest. The target file pattern is, for example, data obtained by normalizing the target file or file path. For example, if only a specific application part in a container is to be verified, only the files of that application part are set as target file patterns, and files that do not affect other operations but may change with each build are excluded from the target file patterns.

[0027] (Dependency description file pattern list) 4 is a diagram showing an example of a dependency description file pattern list. The dependency description file pattern list 134 is a list of patterns of dependency description file paths (hereinafter, sometimes referred to as "dependency description file patterns"). A dependency description file pattern is, for example, data obtained by normalizing the file paths of dependency description files.

[0028] The digital signature request unit 104 refers to the past digital signature list 300 and determines whether or not there is an orderer digital signature corresponding to the target digest calculated by the first digest calculation unit 103 .

[0029] (Past electronic signature list) 5 is a diagram showing an example of a past digital signature list. Past digital signature list 300 is data in a table format having data items of target digest 301 and orderer digital signature 302. A target digest calculated in the past is set in target digest 301. The orderer digital signature affixed to target digest 301 is set in orderer digital signature 302.

[0030] If the orderer digital signature corresponding to the target digest calculated by the first digest calculation unit 103 exists in the past digital signature list 300, the digital signature request unit 104 reads out the corresponding orderer digital signature from the past digital signature list 300. On the other hand, if the orderer digital signature corresponding to the target digest calculated by the first digest calculation unit 103 does not exist in the past digital signature list 300, the digital signature request unit 104 generates a digital signature request including the target digest and transmits the generated digital signature request to the orderer system 20.

[0031] The digital signature receiving unit 105 receives the orderer digital signature for the target digest calculated by the first digest calculation unit 103 from the orderer system 20 as a response to the transmitted digital signature request.

[0032] The digital signature adding unit 106 generates signed software by integrating the orderer's digital signature, the test certificate, and the software 110. The digital signature adding unit 106 stores the generated signed software in the signed software database 130.

[0033] The signed software database 130 is a database that stores signed software.

[0034] The software transmission unit 107 transmits the generated signed software to the orderer system 20 .

[0035] <Orderer system> The orderer system 20 includes an electronic signature issuing unit 200 that issues an orderer's electronic signature to software 110 that has passed an acceptance test, and a verification unit 210 that verifies the software 110 delivered by the provider.

[0036] The digital signature issuing unit 200 includes the functional units of a digital signature request receiving unit 201 and a digital signature transmitting unit 202. The digital signature issuing unit 200 also stores an orderer private key 203, which is the private key of the orderer, and a UAT accepted list 400 in advance.

[0037] The digital signature request receiving unit 201 receives a digital signature request from the provider system 10 .

[0038] If the software 110 included in the received electronic signature request has passed the acceptance test (a predetermined test), the electronic signature sending unit 202 generates an orderer's electronic signature using the target digest included in the electronic signature request and the orderer's private key 203. Specifically, if the target digest included in the received electronic signature request exists in the UAT accepted list 400, the electronic signature sending unit 202 determines that the software 110 has passed the acceptance test and generates an orderer's electronic signature. Then, the electronic signature sending unit 202 sends the generated orderer's electronic signature to the provider-side system 10.

[0039] (UAT Accepted List) 6 is a diagram showing an example of a UAT accepted list 400. The accepted list 400 is a list of target digests of the software 110 that have passed the acceptance test conducted by the client.

[0040] The verification unit 210 has the functional units of a software receiving unit 211, a software verification unit 212, and a second digest calculation unit 213. The verification unit 210 also stores in advance a provider public key 214, which is the public key of the provider, and an orderer public key 215, which is the public key of the orderer. The provider public key 214 and the provider private key 120 form a key pair. The orderer public key 215 and the orderer private key 203 form a key pair.

[0041] The software receiving unit 211 receives signed software from the provider system 10 .

[0042] The software verification unit 212 uses the provider public key 214 and the orderer public key 215 to verify the test certificate and the orderer digital signature attached to the signed software, and stores the signed software that has been successfully verified as verified software in the verified software database 216.

[0043] The verified software database 216 is a database that stores verified software.

[0044] Similar to the first digest calculation unit 103, the second digest calculation unit 213 calculates the target digest from the software 110. The second digest calculation unit 213 has the same configuration as the first digest calculation unit 103.

[0045] 7 is a diagram showing an example of the hardware configuration of the provider-side system 10 and the orderer-side system 20. As an example, the provider-side system 10 and the orderer-side system 20 can be realized by a general computer (information processing device) equipped with a processing device 11 such as a CPU (Central Processing Unit), a memory 12 such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a storage device 13 such as an HDD (Hard Disk Drive) or an SSD (Solid State Drive), an input device 14 such as a keyboard, a mouse, or a touch panel, an output device 15 such as a display or a printer, and a communication device 16 configured with a NIC (Network Interface Card), a wireless communication module, a USB (Universal Serial Interface) module, a serial communication module, or the like.

[0046] In the provider system 10 and the orderer system 20, data such as programs that realize each functional unit is stored in the storage device 13, for example, and the processing device 11 reads the data into the RAM of the memory 12 and executes it. In addition, the programs that realize each functional unit of the provider system 10 and the orderer system 20 can be distributed by recording them on a portable or fixed recording medium, for example.

[0047] Next, the processing performed by the information processing system 1 will be described.

[0048] <Outline of the provider system processing> 8 is a flow diagram outlining the processing performed in the provider system 10. The processing shown in this figure is executed, for example, when the software 110 is updated. For example, the software issuing unit 100 may start the processing shown in this figure using CD (Continuous Deployment or Continuous Delivery) as a trigger.

[0049] First, the automatic test unit 101 waits until the software 110 is updated, and when the software 110 is updated, it reads the updated software 110 (S101).

[0050] Next, the automatic test unit 101 executes an automatic test on the software 110 (S102). Here, the automatic test executed by the automatic test unit 101 is, for example, a general regression test automated by a tool that realizes CI (Continuous Integration).

[0051] Next, the automatic test unit 101 determines whether the software 110 has passed all the tests (S103).

[0052] If the software 110 has not passed all the tests (S103: No), the automatic test unit 101 outputs an error (S104) and ends the process.

[0053] On the other hand, if the software 110 passes all the tests (S103: Yes), the test signing unit 102 generates a test certificate from a digest of the software 110 (hereinafter referred to as a "test certificate digest 510") (S105). Here, the test signing unit 102 generates the test certificate digest 510 from the software 110 using a general digest calculation. For example, the test signing unit 102 calculates a hash value of the contents of an executable file, package, container, etc. of the software 110. The test signing unit 102 may also use a commit number of a repository as the test certificate digest 510.

[0054] Next, the test signature unit 102 adds a provider digital signature to the generated test certificate using the provider private key 120 (S106). For example, the test signature unit 102 encrypts the test certificate digest 510 with the provider private key 120 to generate the provider digital signature.

[0055] (Test Proof) 9 is a diagram showing an example of a test certificate 500. As shown in the diagram, the test certificate 500 includes a test certificate digest 510 and a provider digital signature 520.

[0056] Next, the first digest calculation unit 103 calculates a target digest to be the target of the orderer digital signature from the software 110 (S107). The digest calculation process by the first digest calculation unit 103 will be described in detail later.

[0057] Next, the digital signature request unit 104 refers to the past digital signature list 300 and determines whether or not there is an orderer digital signature corresponding to the target digest calculated by the first digest calculation unit 103 (S108).

[0058] If the orderer digital signature does not exist (S108: No), the digital signature request unit 104 generates a digital signature request (S109).

[0059] (electronic signature request) 10 is a diagram showing an example of a digital signature request 600. As shown in the figure, the digital signature request 600 includes the software 110 and a target digest 610 calculated by the first digest calculation unit 103.

[0060] Next, the digital signature request unit 104 transmits the generated digital signature request 600 to the orderer system 20 (S110).

[0061] Next, the digital signature receiving unit 105 receives the orderer digital signature from the orderer system 20 as a response to the digital signature request 600 (S111). The digital signature receiving unit 105 stores the orderer digital signature received in S111 in the past digital signature list 300 in association with the target digest 610 calculated by the first digest calculation unit 103 in S107. Thereafter, the process proceeds to S113.

[0062] On the other hand, if the orderer's digital signature exists (S108: Yes), the digital signature request unit 104 acquires the orderer's digital signature from the past digital signature list 300 (S112).

[0063] Next, the digital signature adding unit 106 generates signed software by integrating the orderer digital signature received in S111 or the orderer digital signature acquired in S112 with the test proof 500 and the software 110. Then, the digital signature adding unit 106 stores the generated signed software in the signed software database 130 (S113).

[0064] (Signed Software) 11 is a diagram showing an example of signed software 700. As shown in the figure, signed software 700 includes software 110, test certificate 500, and orderer digital signature 710.

[0065] Next, the software transmission unit 107 transmits the new signed software 700 generated in S113 to the orderer system 20 (S114), after which the process ends.

[0066] <Outline of the electronic signature issuance process on the purchaser's system> 12 is a flow diagram illustrating the digital signature issuing process performed by the orderer system 20. The process shown in this figure is executed, for example, when the orderer system 20 receives the digital signature request 600 transmitted from the provider system 10 in S110 described above.

[0067] First, the digital signature request receiving unit 201 receives the digital signature request 600 from the provider system 10 (S201).

[0068] Next, the digital signature transmission unit 202 determines whether the target digest 610 included in the received digital signature request 600 exists in the UAT accepted list 400 (S202).

[0069] If the target digest 610 does not exist in the UAT accepted list 400 (S202: No), the digital signature transmission unit 202 waits until the target digest 610 is added to the UAT accepted list 400 (S203), and returns to the process of S202.

[0070] The user on the ordering side performs an acceptance test on the software 110 included in the received digital signature request 600. Then, when the software 110 passes the acceptance test, the user on the ordering side adds the target digest 610 to the UAT accepted list 400 via a user interface (not shown) or the like.

[0071] If the target digest 610 exists in the UAT accepted list 400 (S202: Yes), the digital signature sending unit 202 encrypts the target digest 610 with the orderer private key 203 to generate the orderer digital signature 710 (S204). That is, the digital signature sending unit 202 generates the orderer digital signature 710 for the target digest 610 of the software 110 that has passed the acceptance test conducted by the orderer.

[0072] Next, the digital signature transmission unit 202 transmits the generated orderer digital signature 710 to the provider-side system 10 (S205). Thereafter, the digital signature issuance process ends.

[0073] <Outline of verification process on the client system> 13 is a flow diagram illustrating the verification process performed in the orderer system 20 in the first embodiment. The process shown in this figure is executed, for example, when the signed software 700 transmitted from the provider system 10 in S114 described above is received.

[0074] First, the software receiving unit 211 receives the signed software 700 from the provider system 10 (S301).

[0075] Next, the software verification unit 212 verifies the test proof 500 using the provider public key 214 (S302). Specifically, the software verification unit 212 obtains a digest by decrypting the provider digital signature 520 included in the test proof 500 with the provider public key 214. The software verification unit 212 then verifies the test proof 500 based on whether the obtained digest matches the test proof digest 510.

[0076] Next, the software verification unit 212 determines whether the verification of the test proof 500 has been successful (S303).

[0077] If the verification of the test proof 500 fails (S303: No), the software verification unit 212 issues an alert (S304) and ends the verification process.

[0078] On the other hand, if the verification of the test proof 500 is successful (S303: Yes), the software verification unit 212 obtains the target digest 610 from the orderer digital signature 710 using the orderer public key 215 (S305). Specifically, the software verification unit 212 decrypts the orderer digital signature 710 with the orderer public key 215.

[0079] Next, the second digest calculation unit 213 calculates the target digest from the software 110 (S306). The digest calculation process will be described in detail later.

[0080] Next, the software verification unit 212 determines whether the target digest 610 acquired in S305 matches the target digest calculated in S306 (S307).

[0081] If the target digests do not match (S307: No), the software verification unit 212 issues an alert (S304) and ends the verification process.

[0082] On the other hand, if the target digests match (S307: Yes), the software verification unit 212 stores the signed software 700 as verified software in the verified software database 216 (S308), and then ends the verification process.

[0083] <Digest calculation process> 14 is a flow diagram illustrating details of the digest calculation process in the first embodiment. The process shown in this diagram is details of the processes shown in S107 and S306 described above.

[0084] First, the first digest calculation unit 103 extracts the files and their paths included in the software 110 (S401).

[0085] Next, the first digest calculation unit 103 sorts the extracted files according to their paths (S402).

[0086] Next, the first digest calculation unit 103 executes the following processes of S404 to S408 for each of the extracted files (S403).

[0087] Specifically, first, the first digest calculation unit 103 determines whether or not the file matches any of the target file patterns included in the target file pattern list 133 (S404).

[0088] If the file does not match the target file pattern (S404: No), the first digest calculation unit 103 excludes the file from the targets of digest calculation and proceeds to the process of S409. For example, when verifying only a specific application part in a container, the first digest calculation unit 103 first performs filtering according to the target file pattern, assuming that files that do not affect operation but may be changed every time a build is performed will be excluded.

[0089] On the other hand, if the file matches the target file pattern (S404: Yes), the first digest calculation unit 103 determines whether the path of the file matches a dependency description file pattern included in the dependency description file pattern list 134 (S405).

[0090] If the path of the file does not match the dependency description file pattern (S405: No), first digest calculation unit 103 causes normal file digest calculation unit 131 to calculate the digest of the file (S406).

[0091] <Normal file digest calculation process> 15 is a flow diagram illustrating the details of the normal file digest calculation process, which is the details of S406 described above.

[0092] The normal file digest calculation unit 131 calculates a hash value from the contents of the entire file using SHA-256 or the like (S501), and then ends the normal file digest calculation process.

[0093] On the other hand, if the path of the file matches the dependency description file pattern (S405: No), first digest calculation unit 103 causes dependency description file digest calculation unit 132 to calculate the digest of the file (S407).

[0094] <Dependency Description File Digest Calculation Process> 16 is a flow diagram illustrating details of the dependency description file digest calculation process in the first embodiment. The process shown in this diagram is details of the above-mentioned S407.

[0095] First, the dependency description file digest calculation unit 132 extracts the name and version of each dependency from the dependency description file (S601). A dependency is dependent software that the software 110 uses.

[0096] (dependency description file) 17 is a diagram showing an example of a dependency description file. As shown in the figure, a dependency description file 800 describes a name 801 of each dependency and its version 802.

[0097] Next, the dependency relationship description file digest calculation unit 132 executes the next process of S603 for each of the extracted dependency relationships (S602).

[0098] Specifically, the dependency description file digest calculation unit 132 adds the name of the dependency to the dependency list (S603).

[0099] (dependency list) 18 is a diagram showing an example of a dependency list in the first embodiment. As shown in the figure, a dependency list 900 is a list of names of dependencies.

[0100] After executing the process of S603 for all dependency relationships (S604), the dependency relationship description file digest calculation unit 132 sorts the dependency relationship list 900 by name (S605).

[0101] Next, the dependency description file digest calculation unit 132 calculates a hash value from the dependency list 900 using SHA-256 or the like (S606), and then ends the dependency description file digest calculation process.

[0102] Following the process of S406 or S407, the first digest calculation unit 103 adds the file path, the file type, and the hash value calculated in S406 or S407 to the file list (S407).

[0103] (File List) 19 is a diagram showing an example of a file list in the first embodiment. As shown in the figure, a file list 1000 is data in a table format having the following data items: path 1001, file type 1002, and hash value 1003. The path of the file is set in the path 1001. The file type 1002 is set to a "dependency description file" or a "normal file" other than a dependency description file. The hash value 1003 is set to the hash value calculated in S406 or S407.

[0104] When the first digest calculation unit 103 has executed the processes of S404 to S408 for all files included in the software 110 (S409), it calculates the hash value of the file list 1000 as the target digest 610 (S410), and then ends the digest calculation process.

[0105] As described above, the information processing device (provider system 10) of this embodiment includes a first digest calculation unit 103 that calculates a target digest, which is a digest used to generate a digital signature used by a predetermined business to verify the software 110, and a digital signature addition unit 106 that adds an orderer digital signature generated based on the target digest and the orderer private key 203 to the software 110. The first digest calculation unit 103 extracts, from multiple files included in the software 110, a portion that describes dependencies related to software used by or to be used by the software 110, and calculates a target digest based on the extracted portion.

[0106] In this way, the information processing system 1 of this embodiment calculates the target digest based on the part of the file of the software 110 that describes the dependency relationships related to the software being used. This makes it possible to reduce the frequency of updating the software verification information (orderer digital signature) in response to dependency updates that may occur frequently.

[0107] In addition, the provider-side system 10 of this embodiment calculates digests of dependency description files, which describe the names and versions of software used by or to be used by the software 110, from among the multiple files included in the software 110, excluding some or all of the versions, calculates digests of normal files other than the dependency description files from among the multiple files included in the software 110, and calculates target digests based on the digests of the dependency description files and the digests of the normal files.

[0108] That is, the provider-side system 10 of this embodiment calculates the digest of the dependency description file, excluding part or all of the version of the software being used. In other words, the information processing system 1 uses a separate identifier, excluding part or all of the version, that is independent of updates to the software being used, as the target digest for the electronic signature, rather than a simple hash value or commit number that changes every time a change is made to the container or source code. As a result, even if the software being used is updated to address a vulnerability, the target digest remains unchanged, and the resulting digital signature of the purchaser remains valid. On the other hand, any changes to the software 110 other than updates to the software being used invalidate the digital signature of the purchaser. This enables the integrity of the software to be verified while reducing the frequency with which software verification information (digital signature of the purchaser) is updated in response to dependency updates, which can occur frequently.

[0109] In addition, the provider-side system 10 of this embodiment includes the software 110, an electronic signature request unit 104 that sends an electronic signature request including the target digest to the orderer-side system 20, and an electronic signature receiving unit 105 that receives the orderer's electronic signature, which is an electronic signature for verifying the software 110 that has passed a specified test and is generated based on the target digest, from the orderer's system (orderer-side system 20).

[0110] That is, the information processing system 1 of this embodiment adds a purchaser's digital signature to software 110 that has passed a predetermined test, such as an acceptance test. Therefore, even if the software being used is updated to address a vulnerability, the target digest remains unchanged, eliminating the need for the purchaser to re-execute the predetermined test. This allows the frequency of predetermined tests, such as acceptance tests, to be reduced in response to dependency updates, which can occur frequently.

[0111] In addition, the provider-side system 10 of this embodiment stores a past electronic signature list 300 that holds target digests calculated in the past and the orderer's electronic signatures for the target digests, and if the orderer's electronic signature corresponding to the target digest is not present in the past electronic signature list 300, it sends an electronic signature request to the orderer-side system 20, and if the orderer's electronic signature corresponding to the target digest is present in the past electronic signature list 300, it obtains the orderer's electronic signature corresponding to the target digest from the past electronic signature list 300.

[0112] That is, for a target digest to which an orderer's digital signature has been added in the past, the provider system 10 of this embodiment does not send a digital signature request to the orderer system 20, but uses the orderer's digital signature that it previously acquired. This reduces the frequency of digital signature requests and simplifies the process.

[0113] In addition, the provider-side system 10 of this embodiment calculates the digest of the dependency description file using only the name of the software being used, and calculates the target digest based on the digest of the dependency description file and the digest of the normal file.

[0114] This configuration allows updates to the software to be excluded from the verification process, while changes to dependencies can be detected during verification. For example, when new software is added, the orderer's electronic signature can be reissued, i.e., acceptance testing can be re-implemented.

[0115] In the information processing system 1 of this embodiment, a first system (provider-side system 10) managed by a first user (provider side) and a second system (orderer-side system 20) managed by a second user (orderer side) are communicably connected via a network. The provider-side system 10 includes a first digest calculation unit 103 that calculates a target digest, which is a digest used to generate a digital signature used for verifying the software 110 by a predetermined business operator, a digital signature addition unit 106 that adds a digital orderer digital signature generated based on the target digest and a digital orderer private key 203 to the software 110, and a software transmission unit 107 that transmits the software 110 with the digital orderer signature added to it to the orderer-side system 20. The orderer system 20 includes a software receiving unit 211 that receives the software 110 from the provider system 10, a second digest calculation unit 213 that calculates a target digest of the received software 110, and a software verification unit 212 that verifies the received software 110 based on the digest obtained using the orderer public key 215 from the orderer digital signature added to the received software 110 and the calculated target digest. The first digest calculation unit 103 and the second digest calculation unit 213 extract portions of multiple files included in the software 110 that describe dependencies related to software used by or to be used by the software 110, and calculate the target digest based on the extracted portions.

[0116] As a result, the information processing system 1 of this embodiment can reduce the frequency of updating software verification information (orderer digital signature) in response to updates to dependencies that may occur frequently.

[0117] [Second embodiment] Next, an information processing system and an information processing method according to a second embodiment will be described.

[0118] In the first embodiment, the digest of the dependency relationship is calculated based only on the dependency relationship name included in the dependency relationship description file 800, but in this embodiment, the digest of the dependency relationship is calculated including the major version of the dependency relationship. In this embodiment, a policy is defined on the part of the client or provider that minor version or patch level differences are allowed as being outside the scope of acceptance testing (verification), but major version differences are subject to acceptance testing.

[0119] The configuration of the information processing system 1 in this embodiment is the same as that in the first embodiment, and therefore a description thereof will be omitted. In addition, the processes executed in the information processing system 1 in this embodiment other than the dependency description file digest calculation process are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0120] <Dependency Description File Digest Calculation Process> 20 is a flow diagram illustrating details of the dependency description file digest calculation process in the second embodiment. The process shown in this diagram is details of S407 described above. In this diagram, the same processes as those in the first embodiment shown in FIG. 16 are assigned the same reference numerals, and their description will be omitted.

[0121] The dependency description file digest calculation unit 132 executes the following process of S603A for each of the extracted dependency relationships instead of the process of S603 (S602).

[0122] Specifically, the dependency description file digest calculation unit 132 adds the name of the dependency and the highest version number to the dependency list (S603A).

[0123] (dependency list) 21 is a diagram showing an example of a dependency list in the second embodiment. As shown in the figure, the dependency list 900A is data in a table format having data items of dependency name 901 and top version 902. The dependency name 901 is set to the name of the dependency. The top version number (major version) is set to the top version number 902.

[0124] Other processes in the dependency description file digest calculation process in this embodiment are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0125] In this embodiment, in addition to the dependency name 901, the highest version 902 is extracted to calculate the digest of the dependency description file, but this is not limited to this. A pattern to be extracted using a regular expression or the like may be defined according to the policy of the ordering party or the provider, and the target for the digest calculation of the dependency description file may be extracted based on the defined pattern.

[0126] As described above, the information processing system 1 of this embodiment calculates the digest of the dependency description file using only the name and major version of the software being used, and calculates the target digest based on the digest of the dependency description file and the digest of the normal file.

[0127] That is, the information processing system 1 of this embodiment allows differences in minor versions or patch levels to be excluded from verification, while major version updates can be detected during verification. Therefore, when the major version of the software being used is updated, the software can be subject to the issuance of a new purchaser digital signature, i.e., the re-implementation of acceptance testing.

[0128] [Third embodiment] Next, an information processing system and an information processing method according to the third embodiment will be described.

[0129] In the first embodiment, only software 110 is the subject of verification, but in this embodiment, in order to specifically address the verification of containers, the OS (Operating System) package is also the subject of verification, which is different.

[0130] The configuration of the information processing system 1 in this embodiment is the same as that in the first embodiment, and therefore the description thereof will be omitted. In addition, the processes executed in the information processing system 1 in this embodiment, other than the digest calculation process and the verification process, are the same as those in the first embodiment, and therefore the description thereof will be omitted.

[0131] <Digest calculation process> Fig. 22 is a flow diagram illustrating details of the digest calculation process in the third embodiment. The process shown in this diagram is details of S107 and S306 described above. In this diagram, the same processes as those in the first embodiment shown in Fig. 14 are given the same reference numerals, and their description will be omitted. In this embodiment, the first digest calculation unit 103 classifies files included in the software 110 into package management target files, dependency description files, and other normal files, and targets the dependency description files and normal files for digesting.

[0132] Following the process of S402 described above, the first digest calculation unit 103 extracts package information (S1001).

[0133] Next, the first digest calculation unit 103 generates a list of files included in the package from the package information (S1002). The package information contains a list of files included in the package as meta-information. The list (meta-information) can be obtained from a file included in the software 110 or from an external source via the Internet, etc. Furthermore, if the package file itself is included in the software 110, the first digest calculation unit 103 adds the file itself to the list of files included in the package. Then, the process proceeds to S403.

[0134] Then, following the process of S404 described above, the first digest calculation unit 103 determines whether or not the file is included in the list of files included in the package (S1003). If the file is not included in the list of files included in the package (S1003: No), the first digest calculation unit 103 proceeds to the process of S405.

[0135] On the other hand, if the file is included in the list of files included in the package (S1003: Yes), the first digest calculation unit 103 proceeds to processing S408 and adds the path and file type of the file to the file list 1000 without calculating the digest (hash value) of the file.

[0136] Other processes in the digest calculation process in this embodiment are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0137] (File List) 23 is a diagram showing an example of a file list in the third embodiment. The configuration of the file list 1000 in this embodiment is the same as that in the first embodiment. This embodiment differs from the first embodiment in that, as shown in the third line of the figure, files included in a package are added to the file list 1000. As shown in the figure, the hash value 1003 corresponding to the file type "file included in package" is not calculated and therefore not set.

[0138] <Outline of verification process on the client system> Fig. 24 is a flow diagram illustrating the verification process performed in the orderer system 20 in the third embodiment. The process shown in this figure is executed, for example, when the signed software 700 transmitted from the provider system 10 in S114 described above is received. In this figure, the same processes as those in the first embodiment shown in Fig. 13 are given the same reference numerals, and their description will be omitted. In this embodiment, the software verification unit 212 verifies the orderer digital signature 710 and also verifies the package management target file in accordance with the package meta information (list).

[0139] If the target digests match in the process of S307 (S307: Yes), the software verification unit 212 extracts package information from the software 110 (S1101).

[0140] Next, the software verification unit 212 generates a list included in the package and a hash value related to the package from the package information (S1102).

[0141] For example, if the package information includes a hash value for each file (1), the software verification unit 212 obtains information on the hash value of each file included in the package from the package information as the hash value related to the package.

[0142] Furthermore, if the package information includes a hash value of the entire package (2), the software verification unit 212 acquires the hash value of the entire package from the package information as the hash value related to the package.

[0143] Furthermore, if the same package can be acquired externally via the Internet or the like (3), the software verification unit 212 acquires the same package from the outside. Then, the software verification unit 212 calculates the hash value of each file included in the acquired package from the outside, or the hash value of the entire package, as the hash value related to the package.

[0144] Next, the software verification unit 212 determines whether or not the list included in the package and the hash value associated with the package match (S1103).

[0145] For example, if the hash value related to the package is the hash value of each file included in the package (corresponding to the above case (1) or (3)), the software verification unit 212 calculates the hash values ​​of all of the corresponding files (files on the list) included in the software 110. Then, the software verification unit 212 compares the hash values ​​of the files acquired in S1102 with the calculated hash values, and determines whether the hash values ​​of all the files match.

[0146] On the other hand, if the hash value related to the package is the hash value of the entire package (corresponding to the above case (2) or (3)), the software verification unit 212 calculates the hash value of the entire package, which is configured in the same way as the package, for the relevant files (files on the list) included in the software 110. Then, the software verification unit 212 compares the hash value of the entire package acquired in S1102 with the calculated hash value, and determines whether they match.

[0147] If the hash values ​​related to the package do not match (S1103: No), the software verification unit 212 issues an alert (S304) and ends the process.

[0148] On the other hand, if all of the hash values ​​related to the packages match (S1103: Yes), the software verification unit 212 proceeds to the process of S308.

[0149] Other steps in the verification process in this embodiment are the same as those in the first embodiment, and therefore a description thereof will be omitted.

[0150] As described above, in the information processing system 1 of this embodiment, when software includes package information related to the OS, the provider-side system 10 calculates the target digest without calculating the digest of the file included in the package information.

[0151] That is, the information processing system 1 of this embodiment excludes the contents of files included in the OS package from the calculation of the target digest, which makes it possible to exclude changes to the contents of files included in the OS package from the need to reissue the purchaser's digital signature, i.e., the need to re-perform the acceptance test.

[0152] Furthermore, in the information processing system 1 of this embodiment, when package information is included in the software, the orderer system 20 verifies the package information in addition to verifying the issuer digital signature.

[0153] This allows the information processing system 1 of this embodiment to check the package management target files of the OS based on the package information.

[0154] The present invention is not limited to the above-described embodiments, and can be implemented using any components within the scope of the present invention. The above-described embodiments and modifications are merely examples, and the present invention is not limited to these contents as long as the characteristics of the invention are not impaired. Furthermore, although various embodiments and modifications have been described above, the present invention is not limited to these contents. Other aspects conceivable within the scope of the technical idea of ​​the present invention are also included within the scope of the present invention.

[0155] For example, part of the hardware provided in each device of this embodiment may be provided in another device.

[0156] Furthermore, each program of the provider system 10 or the orderer system 20 may be provided on another device, a program may consist of multiple programs, or multiple programs may be integrated into a single program. [Explanation of symbols]

[0157] 1. Information Processing Systems 10 Provider System 100 Software Publishing Department 101 Automated Testing Department 102 Test Signature Section 103 First Digest Calculation Unit 104 Electronic signature request section 105 Electronic Signature Receiving Department 106 Electronic signature addition part 107 Software transmission unit 20 Ordering system 200 Electronic Signature Issuance Department 201 Electronic Signature Request Receiving Unit 202 Electronic Signature Transmission Department 210 Verification Department 211 Software Receiving Unit 212 Software Verification Department 213 Second Digest Calculation Unit 300 Past Electronic Signature List

Claims

1. a processor and a memory; a first digest calculation unit that calculates a target digest, which is a digest used to generate a digital signature used for verifying software by a predetermined business; a digital signature adding unit that adds a digital signature generated based on the target digest to the software; Equipped with The first digest calculation unit extracting a portion of a plurality of files included in the software that describes dependencies related to software used by the software or used by the software, and calculating the target digest based on the extracted portion; Information processing device.

2. The first digest calculation unit Calculating a digest of a dependency description file that describes the names and versions of software used by or utilized by the software from among a plurality of files included in the software, excluding part or all of the versions; Calculating digests of ordinary files other than the dependency description file among the plurality of files included in the software; calculating the target digest based on a digest of the dependency description file and a digest of the normal file; The information processing device according to claim 1 .

3. an electronic signature request unit that transmits an electronic signature request including the software and the target digest to the system of the orderer; an electronic signature receiving unit that receives, from the system of the orderer, the electronic signature of the orderer that is used to verify the software that has passed a predetermined test and that is generated based on the target digest; The information processing device according to claim 1 , comprising:

4. storing a list of past digital signatures that holds previously calculated target digests and digital signatures corresponding to the target digests; The electronic signature request unit sending the electronic signature request to the system of the orderer if the electronic signature corresponding to the target digest does not exist in the past electronic signature list; and obtaining the electronic signature corresponding to the target digest from the past electronic signature list if the electronic signature corresponding to the target digest does exist in the past electronic signature list. The information processing device according to claim 3 .

5. The first digest calculation unit calculating a digest of the dependency description file using only the name of the software to be used, and calculating the target digest based on the digest of the dependency description file and the digest of the normal file; The information processing device according to claim 2 .

6. The first digest calculation unit a digest of the dependency description file is calculated using only the name and major version of the software to be used, and the target digest is calculated based on the digest of the dependency description file and the digest of the normal file; The information processing device according to claim 2 .

7. The first digest calculation unit If the software includes package information related to an operating system, the target digest is calculated without calculating digests of files included in the package information. The information processing device according to claim 2 .

8. An information processing system in which a first system managed by a first user and a second system managed by a second user are communicably connected via a network, The first system comprises: a processor and a memory; a first digest calculation unit that calculates a target digest, which is a digest used to generate a digital signature used for verifying software by a predetermined business; a digital signature adding unit that adds a digital signature of the second user, generated based on the target digest, to the software; a software transmission unit that transmits the software to which the digital signature has been added to the second system; Equipped with The second system is a processor and a memory; a software receiving unit that receives the software from the first system; a second digest calculation unit that calculates a target digest of the received software; a verification unit that verifies the digital signature attached to the received software based on the calculated target digest; Equipped with The first digest calculation unit and the second digest calculation unit extracting a portion of a plurality of files included in the software that describes dependencies related to software used by the software or used by the software, and calculating the target digest based on the extracted portion; Information processing system.

9. The information processing device a first digest calculation process for calculating a target digest, which is a digest used to generate a digital signature used for verifying software by a predetermined business; a digital signature adding process for adding a digital signature generated based on the target digest to the software; Run In the first digest calculation process, extracting a portion of a plurality of files included in the software that describes dependencies related to software used by the software or used by the software, and calculating the target digest based on the extracted portion; Information processing methods.

Images