Proof verification system and proof verification method

Abstract

The present disclosure is a proof verification system comprising: a proof terminal that proves the safety of a high-level language program; and a verification terminal that verifies the safety of the program. The proof terminal comprises: a compiler that generates an executable file on the basis of a source code of the program; a logical expression generation unit that generates an intermediate representation on the basis of the source code of the program, and generates, on the basis of secret definition information indicating that a prescribed variable name in the intermediate representation and in the high-level language is confidential information, a verification logical expression indicating a condition to be established immediately before and immediately after executing the executable file of the program; a proof creation unit that demonstrates that the executable file satisfies the condition on the basis of the verification logical expression, and creates a safety proof for guaranteeing the safety of the executable file; and an output unit that outputs the executable file, the verification logical expression, and the safety proof.

Description

Proof verification system and proof verification method

[0001] The present disclosure relates to a proof verification system and a proof verification method.

[0002] With the spread of open technologies, software components are becoming increasingly common and diverse, even in critical systems. In recent years, cyber attacks targeting the software supply chain have become increasingly prevalent.

[0003] The use of Proof-Carrying Code (PCC) has been proposed as a conventional technique for ensuring the safety of software (see Non-Patent Document 1). PCC is a technique that enables the assurance of program authenticity and the proof that a program satisfies desired safety requirements by distributing a program's safety proof along with the program. In conventional techniques, this technique analyzes the program (software) and expresses the safety requirements, such as whether secret information such as passwords is hashed and stored in the correct procedure, in the form of a verification logic formula, allowing users of the program to confirm that the secret information is stored safely.

[0004] Tsubasa Tokoshi, Hitoshi Yoshimura, Misato Nakabayashi, Tetsuya Okuda, "A Secure and Private Execution Method for Programs Using Proof-Carrying Code and TEE," Research Report Computer Security (CSEC), 2022-CSEC-97, 2022-05-12

[0005] However, conventional technologies target specific high-level languages ​​such as C++ for analysis. Therefore, when multiple languages ​​are used in the software supply chain, analysis corresponding to each language is required, which increases the effort required to perform formal verification of the program.

[0006] The present invention has been made in view of the above points, and has as its object to reduce the number of steps required to verify a program.

[0007] In order to achieve the above object, the invention of claim 1 is a proof verification system having a proof terminal that proves the safety of a program written in a high-level language, and a verification terminal that verifies the safety of the program, wherein the proof terminal comprises: a compiler that generates an executable file based on the source code of the program; a logical formula generation unit that generates an intermediate representation based on the source code of the program, and generates a verification logical formula indicating a condition that must be met immediately before and after executing the executable file of the program, based on the intermediate representation and confidential definition information that indicates confidentiality, meaning that a specific variable name in the high-level language is confidential information; a proof creation unit that proves that the executable file satisfies the condition based on the verification logical formula and creates a safety proof to guarantee the safety of the executable file; and an output unit that outputs the executable file, the verification logical formula, and the safety proof, and the verification terminal comprises a proof confirmation unit that verifies the existence of the safety proof obtained from the proof terminal if the executable file satisfies the condition based on the verification logical formula.

[0008] As described above, the present invention has the effect of reducing the number of steps required to verify a program.

[0009] FIG. 1 is a schematic diagram of a proof verification system according to a first embodiment. FIG. 2 is an electrical hardware configuration diagram of each terminal. FIG. 3 is a functional configuration diagram of a proving terminal according to the first embodiment. FIG. 4 is a functional configuration diagram of a verification terminal according to the first embodiment. FIG. 5 is a sequence diagram showing the processing or operation of a proof verification system according to the first embodiment. FIG. 6 is a flowchart showing the processing or operation of a verification terminal that is a premise of the first embodiment. FIG. 7 is a functional configuration diagram of a proving terminal according to a second embodiment. FIG. 8 is a sequence diagram showing the processing or operation of a proof verification system according to the second embodiment. FIG. 9 is a functional configuration diagram of a proving terminal according to a third embodiment. FIG. 10 is a sequence diagram showing the processing or operation of a proof verification system according to the third embodiment.

[0010] Each embodiment of the present invention will be described below. In each embodiment, the processing or operation of a program developer and user in a series of distribution processes in a software supply chain (design, development, and manufacturing of equipment and software, function addition, installation, and operation (or use)) will be described.

[0011] First Embodiment First, the first embodiment will be described.

[0012] [Overall Configuration] Fig. 1 is a schematic diagram of a proof verification system according to a first embodiment. As shown in Fig. 1, the proof verification system 10 of the first embodiment is constructed by a proof terminal 30 and a verification terminal 50. In this case, the proof terminal 30 is a terminal that proves the safety of a program and creates a safety proof p, etc., and in this embodiment, it is also a development terminal for the program developer. The verification terminal 50 is a terminal that verifies the safety of the program and in this embodiment, it is also a user terminal for the program user. The verification terminal 50 executes the program (executable file) after confirming the existence of the safety proof p.

[0013] [Electrical Configuration of Each Terminal] Next, the electrical hardware configuration of each terminal will be described with reference to Fig. 2. Fig. 2 is a diagram showing the electrical hardware configuration of each terminal.

[0014] As shown in Figure 2, each terminal (certification terminal 30, verification terminal 50) is a computer and is equipped with a CPU 101, a ROM 102, a RAM 103, an SSD 104, an external device connection I / F (Interface) 105, a network I / F 106, a display device 107, an input device 108, a media I / F 109, and a bus line 110, as shown in Figure 2.

[0015] Of these, the CPU 101 controls the overall operation of each terminal. The ROM 102 stores programs such as IPL used to drive the CPU 101. The RAM 103 is used as a work area for the CPU 101.

[0016] The SSD 104 reads or writes various data under the control of the CPU 101. Note that instead of the SSD 104, a hard disk drive (HDD) may be used.

[0017] The external device connection I / F 105 is an interface for connecting various external devices, such as a display, a speaker, a keyboard, a mouse, a USB memory, and a printer.

[0018] The network I / F 106 is an interface for performing data communication via a communication network such as the Internet.

[0019] The display device 107 is a type of display means that displays various images, such as a liquid crystal display or an organic electroluminescence (EL) display. An example of the display device 107 is a display.

[0020] The input device 108 is a type of input means for selecting and executing various instructions, selecting a processing target, moving a cursor, etc. An example of the input device 108 is a pointing device.

[0021] The media I / F 109 controls reading and writing (storing) of data from and to a recording medium 109m such as a flash memory, etc. The recording medium 109m includes DVDs and Blu-ray Discs (registered trademarks).

[0022] The bus line 110 is an address bus, a data bus, etc. for electrically connecting the components such as the CPU 101 shown in FIG.

[0023] [Functional Configuration of the Proof Verification System According to the First Embodiment] Next, the functional configuration of each terminal (the proving terminal 30a, the verification terminal 50) of the proof verification system 10 according to the first embodiment will be described with reference to FIGS.

[0024] <Certification Terminal> Fig. 3 is a functional configuration diagram of the certification terminal according to the first embodiment. Note that the certification terminal 30a is an example of the certification terminal 30 shown in Fig. 1 .

[0025] 3, the proof terminal 30a has an acquisition unit 31, a compiler 32, a logical formula generation unit 35a, a proof creation unit 36, and an output unit 39. Each of these units is a function that is realized by the CPU 101 as a processor in the proof terminal 30a using one or more programs installed in the proof terminal 30a.

[0026] The acquisition unit 31 acquires source code s written in a programming language, etc., through the operation of a prover (developer).

[0027] The compiler 32 is a general compiler that reads and analyzes the source code s and converts (generates) it into an executable file (binary) b that can be directly executed by a computer.

[0028] The logical formula generation unit 35a generates a verification logical formula v based on confidential definition information c set in advance by the developer and the source code s acquired from the acquisition unit 31. While creating a program in a high-level language, the developer also creates confidential definition information, and indicates confidential parts in the confidential definition information. The "confidential definition information" indicates that a specific variable name in the high-level language (e.g., "password") is confidential information.

[0029] An example of a method for generating verification logical formula v is disclosed in Reference 1. (Reference 1) Confidentiality of Proofs in an Interactive Security-Proofed Program Distribution Method and Its Applications, Tsukada Yasuaki, 2005. Verification logical formula v is a condition (pre-condition, post-condition) that must be true immediately before and after the execution of a program (executable file b), and is provided to the developer in advance by the program user. If verification logical formula v is a valid logical formula, it is mathematically guaranteed that "when executable file b is executed in a situation where the pre-condition is true and the calculation is completed, the post-condition will always be true, and the safety required by the user will be met when executable file b is executed."

[0030] The logical formula generation unit in Reference 1 has both a front-end function (a function for parsing source code s) and a back-end function (a function for creating an executable file) of the compiler functions in order to generate a verification logical formula v.

[0031] In contrast, the logical formula generation unit 35a of this embodiment does not have a back-end function, or if it has a back-end function, it does not execute it, but has a front-end function. As a result, the logical formula generation unit 35a generates up to an intermediate representation (LLVM-IR) during the compilation process and generates a verification logical formula v using this intermediate representation. As a result, by sending the verification logical formula v using the intermediate representation (LLVM-IR) common to each language to the verification terminal 50 in the subsequent process, even if multiple languages ​​are used in the software supply chain, there is no need to perform analysis corresponding to each language, and the number of steps required to perform formal verification of the program can be reduced.

[0032] As shown in the above-mentioned Reference 1, the proof creation unit 36 ​​proves that the executable file b satisfies the precondition and postcondition based on the verification logical formula v, and creates a security proof p to guarantee the security of the executable file b.

[0033] The output unit 39 obtains the executable file b from the compiler 32, the security proof p from the proof creation unit 36, and the verification logical formula v from the logical formula generation unit 35, and outputs all of this data. Each output data may be transmitted to the verification terminal 50 via a communication network such as the Internet, or may be recorded on a recording medium such as a DVD-ROM and sent to the verification terminal 50.

[0034] <Verification Terminal> FIG. 4 is a functional configuration diagram of the certification terminal according to the first embodiment.

[0035] 4, the verification terminal 50 has an acquisition unit 51, a certificate verification unit 56, and an execution unit 59. Each of these units is a function that the CPU 101 as a processor causes the verification terminal 50 to realize using one or more programs installed in the verification terminal 50.

[0036] The acquisition unit 51 acquires the above-mentioned data output from the certification terminal 30 in response to an operation by the verifier (user).

[0037] The proof checking unit 56 confirms the existence of the security proof p. In this case, the proof checking unit 56 confirms the existence of the security proof p by using the above data and performing the same processing as the proof creation unit 36. Specifically, the proof checking unit 56 uses the above data and determines whether the executable file b satisfies the above conditions (pre-condition and post-condition) based on the verification logical formula v, just like the proof creation unit 36, and if the conditions are satisfied, confirms that the security proof p obtained from the certification terminal 30 certainly exists.

[0038] If the proof checking unit 56 confirms the existence of the security proof p, the execution unit 59 executes the executable file b acquired from the acquisition unit 51 .

[0039] [Processing or Operation of First Embodiment] Next, the processing or operation of the first embodiment will be described with reference to Fig. 5 and Fig. 6. Fig. 5 is a sequence diagram showing the processing or operation of the proof verification system according to the first embodiment. Fig. 6 is a flowchart showing the processing or operation of the verification terminal according to the first embodiment.

[0040] S131: The acquisition unit 31 acquires source code s written in a programming language through the operation of a prover (developer).

[0041] S132: The compiler 32 reads the source code s and generates an executable file (binary) b.

[0042] S133: The logical expression generating unit 35a generates an intermediate representation r based on the source code s acquired from the acquiring unit 31.

[0043] S134: The logical formula generation unit 35a generates a verification logical formula v based on the intermediate representation r and the secret definition information c.

[0044] S135: The proof creating unit 36 ​​proves that the executable file b satisfies the pre-condition and post-condition based on the verification logical formula v, and creates a safety proof p to guarantee the safety of the executable file b.

[0045] S136: The output unit 39 obtains the executable file b from the compiler 32, obtains the security proof p from the proof creation unit 36, and obtains the verification logical formula v from the logical formula generation unit 35, and transmits each piece of data to the verification terminal 50. As a result, the acquisition unit 51 of the verification terminal 50 obtains each piece of data.

[0046] S151: Proceeding to FIG. 6, the proof checking unit 56 of the verification terminal 50 uses the above data to perform the same processing as the proof creating unit 36, thereby confirming the existence of the security proof p.

[0047] S152: If the proof checking unit 56 can confirm the existence of the security proof p (S151; True), the execution unit 59 executes the executable file. On the other hand, if the proof checking unit 56 cannot confirm the existence of the security proof p (S151; False), the security of the executable file cannot be guaranteed, so the execution unit 59 does not execute the executable file, and the process shown in FIG. 6 ends.

[0048] [Major Effects of the First Embodiment] As described above, according to this embodiment, the certification terminal 30a sends the verification logical formula v using an intermediate representation (LLVM-IR) common to each language to the verification terminal 50 in the subsequent process. This eliminates the need for analysis corresponding to each language, even when multiple languages ​​are used in the software supply chain, and makes it possible to reduce the man-hours required for formal verification of a program.

[0049] Second Embodiment Next, a second embodiment will be described with reference to Fig. 7 and Fig. 8. The second embodiment also has the overall configuration shown in Fig. 1. The certification terminal 30b is an example of the certification terminal 30 shown in Fig. 1.

[0050] First, an outline of the differences from the first embodiment will be explained. In the first embodiment, if source code s in a high-level language contains confidential information in a variable name such as "password," the intermediate representation generated from the source code s is difficult for humans to read, making it difficult for a verifier in a subsequent process to confirm which part of the executable file b contains confidential information. To solve this problem, the second embodiment generates a variable name in the intermediate representation (such as "20" in order from the beginning) and a label indicating that the variable name is confidential information. This will be explained in detail below.

[0051] [Functional Configuration of the Proof Verification System According to the Second Embodiment] The functional configuration of the proof terminal 30b of the proof verification system 10 according to the second embodiment will be described with reference to FIG.

[0052] <Proof Terminal> Fig. 7 is a functional configuration diagram of a proof terminal according to the second embodiment. As shown in Fig. 7, the proof terminal 30b has an acquisition unit 31, a compiler 32, a labeling information generation unit 34b, a logical formula generation unit 35b, a proof creation unit 36, and an output unit 39. Each of these units is a function that is realized by the CPU 101 as a processor in the proof terminal 30b using one or more programs installed in the proof terminal 30b. Note that, here, the same functional components as those of the first embodiment shown in Fig. 3 are denoted by the same reference numerals, and their description will be omitted.

[0053] The labeling information generation unit 34b has a function of generating an intermediate representation (LLVM-IR), similar to the logical expression generation units 35a and 35b. Based on confidential definition information c indicating that a variable name (e.g., "password") in a high-level language is confidential information, the labeling information generation unit 34b analyzes the source code s acquired from the acquisition unit 31, and generates auxiliary information a, which is an intermediate representation that inherits attribute information in the high-level language (variable name (e.g., "password"), function name, and program file name).

[0054] Furthermore, the labeling information generation unit 34b generates labeling information L2 based on the auxiliary information a. The labeling information generation unit 34b uses a predetermined tool that associates a predetermined variable name in a high-level language (e.g., "password") with the order of variables in the intermediate representation r from the beginning (e.g., "20"). As a result, the labeling information generation unit 34b can generate labeling information that is a pair of the variable name "20(th)" and a label indicating that this is confidential information, using, for example, auxiliary information a indicating that the variable name "password" is confidential information and a predetermined tool indicating that the variable name "password" is the variable name "20(th)".

[0055] The "labeling information" includes a pair of a predetermined variable name in the intermediate representation r and a label to be assigned to the predetermined variable. The "label" indicates that the portion of the predetermined variable name is confidential information.

[0056] The logical expression generating unit 35 b generates an intermediate representation r based on the source code s acquired from the acquiring unit 31, similar to the logical expression generating unit 35 a.

[0057] Furthermore, the logical formula generation unit 35b generates a verification logical formula v based on the generated intermediate representation r and the labeling information L2 (a set of a variable name (e.g., "20") and a label (e.g., "confidential information")) generated by the labeling information generation unit 34b. The method for generating the verification logical formula v is the same as in the first embodiment.

[0058] [Processing or Operation of Second Embodiment] Next, the processing or operation of the second embodiment will be described with reference to Fig. 8. Fig. 8 is a sequence diagram showing the processing or operation of the proof verification system according to the second embodiment. Note that the processing or operation of the verification terminal 50 according to the second embodiment is the same as that of the first embodiment, and therefore description thereof will be omitted.

[0059] S231: The acquisition unit 31 acquires source code s written in a programming language through the operation of the prover (developer).

[0060] S232: The compiler 32 reads the source code s and generates an executable file (binary) b.

[0061] S233: The logical expression generating unit 35b generates an intermediate representation r based on the source code s acquired from the acquiring unit 31.

[0062] S234: The labeling information generating unit 34b analyzes the source code s acquired from the acquiring unit 31 based on the secret definition information c, and generates auxiliary information a, which is an intermediate representation that inherits the attribute information in the high-level language.

[0063] S235: The labeling information generating unit 34b generates labeling information L2 based on the auxiliary information a.

[0064] S236: The logical formula generation unit 35b generates a verification logical formula v based on the intermediate representation r and the labeling information L2.

[0065] S237: The proof creating unit 36 ​​proves that the executable file b satisfies the pre-condition and post-condition based on the verification logical formula v, and creates a safety proof p to guarantee the safety of the executable file b.

[0066] S238: The output unit 39 obtains the executable file b from the compiler 32, obtains the security proof p from the proof creation unit 36, and obtains the verification logical formula v from the logical formula generation unit 35, and transmits each piece of data to the verification terminal 50. As a result, the acquisition unit 51 of the verification terminal 50 obtains each piece of data.

[0067] [Major Effects of the Second Embodiment] As described above, in addition to the effects of the first embodiment, the present embodiment generates variable names (such as "20" in order from the beginning) in the intermediate representation r and labels indicating that the variable names are confidential information. This has the effect of enabling a verifier in a subsequent process to easily confirm which parts of the executable file b contain confidential information, even if the source code s in a high-level language contains confidential information in the form of a variable name such as "password."

[0068] Third Embodiment Next, a third embodiment will be described with reference to Fig. 9 and Fig. 10. The third embodiment also has the overall configuration shown in Fig. 1. The certification terminal 30c is an example of the certification terminal 30 shown in Fig. 1.

[0069] The third embodiment assumes processing or operations performed in an open source supply chain using GitHub or the like. Git is a distributed version control system and is a tool used by developers. GitHub is a web service that uses the Git mechanism to enable people around the world to store and publish their own works (program code, design data, etc.). The third embodiment assumes a situation in which, for example, in an open source supply chain, developer B copies a program developed by developer A and adds a new program.

[0070] First, an outline of the differences from the second embodiment will be explained. In the second embodiment, if a developer makes a small modification or alteration to a program published on GitHub or the like, regenerating all of the verification logical formulas v would take time or result in the generation of duplicate verification logical formulas v. This reduces the efficiency of the developer and verifier's work. In the third embodiment, to solve this problem, a new verification logical formula v is generated without changing the overlapping parts (common parts) of the verification logical formula v before and after the modification or alteration. For example, if the modified or altered verification logical formula v2 completely contains the modified or altered verification logical formula v1, only the verification logical formula v2 is retained, rather than both the verification logical formula v1 and the verification logical formula v2. This will be explained in detail below.

[0071] [Functional Configuration of the Proof Verification System According to the Third Embodiment] The functional configuration of the proof terminal 30c of the proof verification system 10 according to the third embodiment will be described with reference to FIG.

[0072] <Proof Terminal> FIG. 9 is a functional configuration diagram of a proof terminal according to the third embodiment. As shown in FIG. 9, the proof terminal 30b includes an acquisition unit 31, a compiler 32, a labeling information generation unit 34c, a logical expression generation unit 35c, a proof creation unit 36, and an output unit 39. These units are functions that the CPU 101 as a processor realizes in the proof terminal 30c using one or more programs installed in the proof terminal 30c. Here, among the functional configurations of the first and second embodiments shown in FIG. 7, similar functional configurations are denoted by the same reference numerals, and their description will be omitted. Note that the labeling information generation unit 34c and the logical expression generation unit 35c are modified versions of the labeling information generation unit 34b and the logical expression generation unit 35b in the second embodiment, respectively.

[0073] The labeling information generation unit 34c basically includes the same functions as the labeling information generation unit 34b, and further combines auxiliary information a1 acquired from another terminal and auxiliary information a2 generated on its own terminal (the certification terminal 30c) into a single file, and generates labeling information L3 based on the combined auxiliary information a1 and a2. The auxiliary information a1 is information acquired from GitHub or the like by the acquisition unit 31, and is an example of auxiliary information a by another developer A. The auxiliary information a2 is an example of auxiliary information a generated by the labeling information generation unit 34c in the certification terminal 30c of developer B using the same procedure as the labeling information generation unit 34b. Each piece of auxiliary information a1 and a2 includes attribute information (variable name (e.g., "password"), function name, and program file name), so the labeling information generation unit 34c combines the auxiliary information a1 and the auxiliary information a2 based on the attribute information of each piece of auxiliary information a1 and a2.

[0074] The logical formula generation unit 35c basically includes the same functions as the logical formula generation unit 35b, and further combines an intermediate representation r1 acquired from another terminal and an intermediate representation r2 generated on its own terminal (the proof terminal 30c) into a single file. The intermediate representation r1 is information acquired from GitHub or the like by the acquisition unit 31, and is an example of an intermediate representation r created by another developer A. The intermediate representation r2 is an example of an intermediate representation r generated by the logical formula generation unit 35c in the proof terminal 30c of developer B using the same procedure as the logical formula generation unit 35b. Each of the intermediate representations r1 and r2 includes attribute information (variable name (e.g., "20"), function name, and program file name), so the labeling information generation unit 34c combines the intermediate representations r1 and r2 based on the attribute information of each of the intermediate representations r1 and r2.

[0075] Furthermore, the logical formula generation unit 35c generates a verification logical formula v based on the combined intermediate representations r1 and r2 and the labeling information L3 (a set of a variable name (e.g., "20") and a label (e.g., "confidential information")) generated by the labeling information generation unit 34c. In this case, it is possible that more sets of variable names and labels are generated than in the second embodiment due to program modification or alteration.

[0076] [Processing or Operation of Third Embodiment] Next, the processing or operation of the third embodiment will be described with reference to FIG. 10. FIG. 10 is a sequence diagram showing the processing or operation of the proof verification system according to the third embodiment. Note that the processing or operation of the verification terminal 50 according to the third embodiment is the same as that of the first embodiment, and therefore description thereof will be omitted. Furthermore, the intermediate representation r1 is an example of a first intermediate representation, and the intermediate representation r2 is an example of a second intermediate representation. The auxiliary information a1 is an example of first auxiliary information, and the auxiliary information a2 is an example of second auxiliary information. Furthermore, the secret definition information used in the other proving terminals is an example of first secret definition information, and the secret definition information used in the proving terminal 30c is an example of second secret definition information.

[0077] S331: The acquisition unit 31 acquires source code s written in a programming language through the operation of the prover (developer).

[0078] S332: The compiler 32 reads the source code s and generates an executable file (binary) b.

[0079] S333: The acquisition unit 31 acquires the intermediate representation r1 and auxiliary information a1 generated by another certification terminal from GitHub or the like in the open source supply chain. The intermediate representation r1 and auxiliary information a1 correspond to the intermediate representation r and auxiliary information a in the second embodiment, respectively.

[0080] S334: The logical expression generating unit 35c generates an intermediate representation r2 based on the source code s acquired from the acquiring unit 31.

[0081] S335: The logical formula generation unit 35c combines the intermediate representation r1 acquired from the acquisition unit 31 and the intermediate representation r2 generated by the logical formula generation unit 35c into one file.

[0082] S336: The labeling information generation unit 34c analyzes the source code s acquired from the acquisition unit 31 based on the confidential definition information c2 created by the developer using the certification terminal 30c, and generates auxiliary information a2, which is an intermediate representation r2 that inherits the attribute information in the high-level language.

[0083] S337: The labeling information generating unit 34c combines the auxiliary information a1 acquired from the acquiring unit 31 and the auxiliary information a2 generated by the labeling information generating unit 34c into one file.

[0084] S338: The labeling information generating unit 34c generates labeling information L3 based on the combined auxiliary information a1 and a2.

[0085] S339: The logical formula generation unit 35c generates a verification logical formula v based on the combined intermediate representations r1 and r2 and the labeling information L3.

[0086] S340: The proof creation unit 36 ​​proves that the executable file b satisfies the pre-condition and post-condition based on the verification logical formula v, and creates a safety proof p to guarantee the safety of the executable file b.

[0087] S341: The output unit 39 obtains the executable file b from the compiler 32, obtains the security proof p from the proof creation unit 36, and obtains the verification logical formula v from the logical formula generation unit 35, and transmits each piece of data to the verification terminal 50. As a result, the acquisition unit 51 of the verification terminal 50 obtains each piece of data.

[0088] [Major Effects of the Third Embodiment] As described above, in addition to the effects of the first and second embodiments, according to this embodiment, when a developer slightly modifies or alters a program published on GitHub or the like, a new verification logical formula v is generated without changing the overlapping parts (common parts) of the verification logical formula v before and after the modification or alteration. This has the effect of reducing the data size of the verification logical formula and improving the work efficiency of the developer and verifier.

[0089] [Supplementary Note] The present invention is not limited to the above-described embodiment, and may have the following configurations or processes (operations).

[0090] (1) The above-mentioned programs can be recorded on a (non-transitory) recording medium or provided via a network such as the Internet.

[0091] (2) The CPU 101 in FIG. 2 may be a single CPU or multiple CPUs.

[0092] 10 Proof verification system 30, 30a, 30b, 30c Proof terminal 31 Acquisition unit 32 Compiler 34b, 34c Labeling information generation unit 35a, 35b, 35c Logical formula generation unit 36 ​​Proof creation unit 39 Output unit 51 Acquisition unit 56 Proof confirmation unit 59 Execution unit

Claims

1. A proof verification system having a proof terminal which proves the safety of a program written in a high-level language, and a verification terminal which verifies the safety of the program, wherein the proof terminal comprises: a compiler which generates an executable file based on the source code of the program; a logical formula generation unit which generates an intermediate representation based on the source code of the program, and generates a verification logical formula indicating a condition which should be satisfied immediately before and after the executable file of the program is executed, based on the intermediate representation and on confidential definition information which indicates confidentiality indicating that a specific variable name in the high-level language is confidential information; a proof creation unit which creates a safety proof to prove that the executable file satisfies the condition based on the verification logical formula and to guarantee the safety of the executable file; and an output unit which outputs the executable file, the verification logical formula, and the safety proof, and wherein the verification terminal comprises: a proof confirmation unit which confirms that the safety proof obtained from the proof terminal exists if the executable file satisfies the condition based on the verification logical formula.

2. A proof verification system having a proof terminal for proving the safety of a program in a high-level language and a verification terminal for verifying the safety of the program, wherein the proof terminal has: a compiler for generating an executable file based on source code of the program in the high-level language; a labeling information generation unit for generating auxiliary information which is an intermediate representation based on confidential definition information indicating that a specific variable name in the high-level language is confidential information, and for generating labeling information based on the auxiliary information, the labeling information including the variable name in the auxiliary information and a label indicating that the variable name in the intermediate representation is the confidential information; a logical formula generation unit for generating an intermediate representation based on the source code of the program in the high-level language and for generating a verification logical formula indicating a condition which should be satisfied immediately before and immediately after execution of an executable file of the program, based on the intermediate representation in the high-level language and the labeling information; a proof creation unit for demonstrating that the executable file satisfies the condition based on the verification logical formula and creating a safety proof to guarantee the safety of the executable file; and an output unit for outputting the executable file, the verification logical formula, and the safety proof, wherein the verification terminal has: a proof confirmation unit for confirming that the safety proof obtained from the proof terminal exists if the executable file satisfies the condition based on the verification logical formula; A proof verification system having the above structure.

3. A proof verification system having a proof terminal for proving the safety of a program in a high-level language and a verification terminal for verifying the safety of the program, comprising: a compiler for generating an executable file based on a modified source code of the program in the high-level language; a labeling information generation unit for generating labeling information including a variable name in the second auxiliary information and a label indicating that the variable name in the intermediate representation is the confidential information, based on first auxiliary information, which is an intermediate representation generated by another proof terminal based on first confidential definition information indicating that a specific variable name in the high-level language before the modification is confidential information, and second auxiliary information, which is an intermediate representation generated based on second confidential definition information indicating that a specific variable name in the high-level language after the modification is confidential information; and a logical expression generation unit for generating a verification logical expression indicating a condition that should be satisfied immediately before and immediately after the executable file of the program is executed, based on the first intermediate representation generated by the other proof terminal based on the source code of the program in the high-level language before the modification, the second intermediate representation generated based on the source code of the program in the high-level language after the modification, and the labeling information. a proof creation unit that proves that the executable file satisfies the condition based on the verification logical formula and creates a safety proof to guarantee the safety of the executable file; and an output unit that outputs the executable file, the verification logical formula, and the safety proof, wherein the verification terminal has a proof confirmation unit that confirms that the safety proof obtained from the certification terminal exists if the executable file satisfies the condition based on the verification logical formula.

4. A proof verification method executed by a proof verification system having a proof terminal for proving the safety of a program in a high-level language and a verification terminal for verifying the safety of the program, wherein the proof terminal performs the following: a compilation process for generating an executable file based on the source code of the program; a logical formula generation process for generating an intermediate representation based on the source code of the program, and generating a verification logical formula indicating a condition that should be satisfied immediately before and after executing the executable file of the program, based on the intermediate representation and confidential definition information indicating confidentiality indicating that a specific variable name in the high-level language is confidential information; a proof creation process for creating a safety proof to prove that the executable file satisfies the condition based on the verification logical formula and to guarantee the safety of the executable file; and an output process for outputting the executable file, the verification logical formula, and the safety proof; and the verification terminal performs a proof confirmation process for confirming that the safety proof obtained from the proof terminal exists if the executable file satisfies the condition based on the verification logical formula.

Images