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

Abstract

To efficiently mitigate vulnerability to the threat of fault injection attacks. [Solution] The CPU 20 of the MCU 10 (information processing device) executes the first subprogram (block J) and the second subprogram (block K) in order. The first subprogram redundantly executes the first specific processing associated with the first subprogram two or more times (steps S202 to S208, steps S212 to S218). The first subprogram then records each of the output data output for each of the first specific processing (specific processing J_0, J_1) in the first data area (data area D0j, D1j) that has been allocated in advance. If the output data or the digest value of the output data for each of the first specific processing recorded in each of the first data areas matches (steps S220, step S228), it permits the execution of the second subprogram which will be executed after the first subprogram (step S238).

Description

Technical Field

[0006] , , , , , ,

[0005]

[0001] Embodiments of the present invention relate to an information processing apparatus, an information processing method, and an information processing program.

Background Art

[0002] Techniques for countermeasures against threats by fault injection attacks are known. For example, techniques for HW (hardware) redundancy such as DCLS (Dual Core Lock System) are disclosed.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Non-Patent Documents

[0004]

Non-Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0005] However, since DCLS originally mounts two necessary CPU (Central Processing Unit) cores and performs a comparison operation for each logical clock, a logical circuit of the original CPU and a comparator is required, and there is a problem that the operating frequency also significantly decreases compared to a single CPU. Therefore, it has been difficult to efficiently reduce the vulnerability to the threat of fault injection attacks in the prior art.

[0006] The problem that this invention aims to solve is to provide an information processing device, an information processing method, and an information processing program that can efficiently mitigate vulnerability to the threat of fault injection attacks. [Means for solving the problem]

[0007] The information processing device of the embodiment includes a CPU, the CPU executes a first subprogram and a second subprogram in sequence, the first subprogram redundantly executes the specific processing associated with the first subprogram two or more times, records each of the output data output for each specific processing in a first data area pre-allocated to each, and if the output data for each specific processing or the digest value of the output data recorded in each of the first data areas matches, the execution of the second subprogram, which is executed after the first subprogram, is permitted. [Brief explanation of the drawing]

[0008] [Figure 1] A schematic diagram of the MCU package of the embodiment. [Figure 2] A flowchart illustrating application examples using the MCU package of the embodiment. [Figure 3] A diagram illustrating the virtual instructions used in the CPU of this embodiment. [Figure 4] A diagram illustrating the sequential execution structure of a subprogram. [Figure 5] A diagram illustrating the memory layout. [Figure 6] A diagram illustrating a list of MPU applications. [Figure 7] A flowchart illustrating the flow of information processing. [Figure 8A] Diagram illustrating the conventional technology. [Figure 8B] Diagram illustrating the conventional technology. [Figure 8C] Diagram illustrating the conventional technology. [Figure 9] A diagram illustrating the memory layout. [Figure 10] A flowchart illustrating the flow of information processing. [Figure 11] Figure showing the sequential execution structure of a partial program. [Figure 12] Explanatory diagram of the memory layout. [Figure 13] Flowchart showing the flow of information processing.

Mode for Carrying Out the Invention

[0009] Hereinafter, referring to the attached drawings, the information processing apparatus, information processing method, and information processing program of the present embodiment will be described in detail.

[0010] In the description of each of the following embodiments, parts with the same reference numerals have substantially the same functions, and the description of overlapping parts will be omitted as appropriate.

[0011] (First Embodiment) FIG. 1 is a schematic diagram of an example of the MCU (Micro Controller Unit) package 10 of the present embodiment. Hereinafter, the MCU package 10 will be described as the MCU 10. The MCU 10 is an example of an information processing apparatus. That is, in the present embodiment, as an example of an information processing apparatus, a case where a device in which the main logical functions of an IoT device are integrated in a single-chip MCU is used will be described.

[0012] The MCU 10 of the present embodiment is an MCU 10 that strengthens countermeasures against threats of fault injection attacks in software execution, particularly VFI (Voltage Fault Injection), a fault injection attack that can be executed without leaving traces with inexpensive devices, by a software configuration that utilizes existing CPU functions, with a configuration to be described in detail later.

[0013] The MCU 10 includes a CPU (Central processing unit) 20, a power supply 21, a clock (クロック) 22, a non-volatile memory 23, a non-volatile memory 24, a volatile memory 25, a control input / output unit 26, an external connection function control unit 27, an LSI (Large-Scale Integration) tester I / F 28, and a debugger I / F 29.

[0014] The CPU 20, clock 22, non-volatile memory 23, non-volatile memory 24, volatile memory 25, control input / output unit 26, external connection function control unit, LSI tester I / F 28, and debugger I / F 29 are communicably connected via a bus or the like.

[0015] The power supply 21 supplies power to each part of the MCU 10. The clock 22 is a circuit that generates a clock signal inside the MCU 10. The non-volatile memory 23, non-volatile memory 24, and volatile memory 25 are an example of memory. The non-volatile memory 23 is, for example, a mask ROM (Read Only Memory). The non-volatile memory 24 is, for example, a flash memory. The volatile memory 25 is, for example, a RAM (Random Access Memory).

[0016] The control input / output unit 26 controls the input / output with an external device. The external connection function control unit 27 controls the connection with an external device by controlling each of the LSI tester I / F 28, debugger I / F 29, and control input / output unit 26. The LSI tester I / F 28 is a communication I / F that connects to an LSI test device 30 which is a device for executing an LSI test. The debugger I / F 29 is a communication I / F that connects to a SW debug device 31 which is a debug device for the software (SW) of the MCU 10.

[0017] The CPU 20 executes various programs in the MCU 10. The CPU 20 includes an MPU (microprocessor) 20A and a debugger 20B. The MPU 20A is a known microprocessor composed of main components such as an arithmetic circuit, a control circuit, and registers. The debugger 20B has functions such as arithmetic processing, input / output control, and memory access control. The debugger 20B is a functional unit that executes debug processing.

[0018] The CPU 20 reads and executes the partial programs stored in the non-volatile memory 24 or the like, and the partial programs execute various processes using the MPU 20A. The details of the partial programs will be described later.

[0019] Figure 1 illustrates an attack scenario in which the MCU 10 is subjected to a VFI (Voltage Fault Injection) attack by an attacker, a VFI attack device 32. In detail, this embodiment assumes that the VFI attack device 32 is connected to the MCU 10 via the power terminal of the power supply 21 or the clock terminal of the clock 22, and attacks the MCU 10. However, the attacker's actions are not limited to this scenario. Possible attack scenarios include intervening in the software configuration process for external connection functions such as the LSI test device 30, the SW debug device 31, and the control input / output unit 26, illegally enabling SW debug functions and LSI test functions, and then using the SW debug device 41 to access the inside of the MCU 10.

[0020] Figure 2 is a flowchart showing an example of an application example of the MCU10 in this embodiment.

[0021] The CPU 20 of the MCU 10 reads multiple subprograms stored in the non-volatile memory 24 and executes them in a predetermined order.

[0022] Figure 2 shows an example of a scenario where the maximum number of times the software for realizing value-added functions is executed is notified by an external information processing device as an execution permission public key signature. The software for realizing value-added functions is already stored in the built-in flash memory (non-volatile memory 24) of the MCU10, and the number of times the software is executed is controlled according to the number of execution permission notified by the external information processing device. Figure 2 also shows an example of how the CPU 20 of the MCU10 controls the number of executions so that the number of times the value-added functions are executed does not exceed the execution limit, based on the execution count counter value stored in the non-volatile memory 24.

[0023] The CPU 20 verifies the received execution permission public key signature based on the verification public key previously held by the subprogram (step S100). Then, the CPU 20 determines whether the verification in step S100 was successful or not (step S102).

[0024] If verification fails in step S102 (step S102: No), the process proceeds to step S112. In step S112, CPU 20 executes only basic functions (S112). In step S112, CPU 20 can obtain new valid execution permissions. Then, this routine terminates.

[0025] If the verification is deemed successful in step S102 (Step S102: Yes), the process proceeds to step S104. In step S104, the CPU 20 compares the execution limit number received in step S100 with the execution count counter value stored in the non-volatile memory 24 (Step S104). If the execution limit value is less than or equal to the execution count counter value (Step S106: No), the CPU 20 proceeds to step S112.

[0026] If the execution limit value is greater than the execution counter value (step S106: Yes), CPU20 proceeds to step S108.

[0027] In step S108, the CPU 20 increments the execution count counter value stored in the non-volatile memory 24 by 1 (step S108).

[0028] In low-cost MCUs, flash memory is often used as non-volatile memory 24. Flash memory can be read in word units, similar to RAM. However, to rewrite a value in flash memory, it is necessary to erase the entire memory page that stores the value. Therefore, if the CPU 20 contains other data in the page, it will back up all of this data before erasing the page, and then increment only the execution count counter. In addition, in some cases, wear leveling is performed in flash memory to extend its lifespan by equalizing the number of rewrites across multiple pages.

[0029] Next, the CPU 20 executes a value-added function (step S110). This value-added function is a predetermined process. Then, the routine terminates.

[0030] In the example shown in Figure 2, steps 100 to S102 correspond to the specific processing of one subprogram, steps S104 to S106 correspond to the specific processing of one subprogram, and steps S110 to S112 correspond to the specific processing of one subprogram. Details of the specific processing will be described later.

[0031] Here, if any of the processes from step S100 to step S110 are skipped, it will lead to a vulnerability in terms of correctly managing the number of times the value-added function is executed. For example, after the verification process of the execution permission public key signature in S100 is executed, a fault injection attack may be performed on the MCU10, and the comparison process in step S104 may be executed without the verification success determination process in step S102 being executed. In this case, the value-added function in step S110 may be executed illegally.

[0032] Furthermore, even if the processes in steps S100 to S106 are executed correctly, if the count-up process of the execution count counter value in step S108 is skipped due to a fault injection attack, the CPU 20 will have difficulty accurately managing the execution count counter value.

[0033] Furthermore, for example, even if the processes in steps S100 to S106 are executed correctly, if a fault injection attack causes the execution count counter value incremented by 2 or more in step S108, it becomes difficult for the CPU 20 to accurately manage the execution count counter value.

[0034] Therefore, the CPU 20 of the MCU 10 in this embodiment executes the first subprogram and the second subprogram in order. The first subprogram redundantly executes the specific processing associated with the first subprogram two or more times, and records each of the output data output for each specific processing in a first data area that is pre-allocated to each. If the output data for each specific processing or the digest value of the output data recorded in each of the first data areas matches, the execution of the second subprogram, which is executed after the first subprogram, is permitted.

[0035] By having CPU20 perform this process, it becomes possible to efficiently mitigate vulnerability to the threat of fault injection attacks.

[0036] The first and second subprograms are examples of subprograms stored in the non-volatile memory 24. In this embodiment, the execution order of the multiple subprograms stored in the non-volatile memory 24 is predetermined. The first subprogram is a subprogram that is executed before the second subprogram. The second subprogram is a subprogram that is executed after the first subprogram. Therefore, each of the multiple subprograms stored in the non-volatile memory 24 can become either the first subprogram or the second subprogram, depending on its execution timing and execution order. That is, the subprogram currently being executed by the CPU 20 functions as the first subprogram, and another subprogram scheduled to be executed after the currently executing subprogram functions as the second subprogram.

[0037] A unique process is a process specific to each subprogram. A unique process is a program that is not protected against fault injection attacks and can be called from each of the subprograms, such as the first subprogram and the second subprogram.

[0038] Specifically, as described above, in the example shown in Figure 2, the processing in step S100 corresponds to the specific processing of the subprograms in steps 100 to S102, the processing in step S104 corresponds to the specific processing of the subprograms in steps S104 to S106, and steps S110 and S112 correspond to the specific processing of the subprograms. Furthermore, the specific processing of the first subprogram corresponds to the first specific processing, and the specific processing of the second subprogram corresponds to the second specific processing.

[0039] The processing performed by the MCU10 in this embodiment will be described in detail.

[0040] In this embodiment, the fault injection attack against MCU10 acts on the execution of machine language instructions. In this embodiment, the fault injection attack against MCU10B and countermeasures will be described in detail based on the configuration of virtual instructions.

[0041] Figure 3 is an explanatory diagram of an example of virtual instructions used in the CPU 20 of this embodiment. In this embodiment, from the viewpoint of generalizing and simplifying instruction sets that differ depending on the CPU architecture, only seven types of virtual instructions directly related to the MCU 10 of this embodiment are defined.

[0042] Furthermore, in this embodiment, for the sake of simplification, it is explained that the instruction MPU aborts upon instruction execution or data reference. Also, in this embodiment, it is explained that immediate processing aborts if an error occurs in the data MPU. Furthermore, processing is assumed to abort in the event of a data mismatch during the execution of DMPUmatch and Compare instructions. In addition, in this embodiment, it is assumed that processing interruption due to abort during a fault injection attack is acceptable.

[0043] The instruction MPU is the instruction management function of the MPU20A. The data MPU is the memory management function of the MPU20A.

[0044] Figure 4 shows an example of a sequential execution structure for subprograms executed by the CPU 20. Figure 4 shows a simple configuration in which the CPU 20 uses only the virtual instruction IMPUset to guarantee the execution order of subprograms even if a fault injection attack occurs to the MCU 10.

[0045] For example, CPU20 executes the subprograms of Block I, Block J, and Block K in this order. Each block consists of two parts: the first half (1st) and the second half (2nd). Figure 4 shows only the second half and first half of Block I and Block K, respectively, and shows both parts of Block J.

[0046] Each part contains two instructions. The first instruction disables the execution of the previous part's instruction MPU by setting its attribute to "N" while keeping its address range unchanged. The second instruction sets the attribute to "X" for the data area corresponding to the next part, enabling the execution of the next part. This process is repeated in the program.

[0047] In this embodiment, the CPU 20 implements countermeasures against fault injection attacks by dividing the program to be executed into functional units and incorporating them into a block structure. The processing corresponding to the contents of the block structure corresponds to the unique processing described above. As described above, in the example shown in Figure 2, steps S100, S104, and S110 each correspond to the unique processing of different subprograms. Note that the term "unique processing" is a conceptual name and does not need to be unique for each block; the same unique processing may be used repeatedly in different subprograms.

[0048] Let's consider a scenario where a fault injection attack occurs on MCU10 during the execution of this program. For example, let's assume a fault injection attack occurs on MCU10 during the execution of Part 1, which is the first half (1st) of Block J. In this case, processing transitions to distant parts, excluding those within the same part or the preceding and succeeding parts, are outside the scope permitted by MPU20A, and therefore processing is aborted. Here, a transition refers to a change in the instructions executed in a different part from the part and instructions that were executed immediately before, whether it is the sequential execution of instructions, the execution of branch instructions contained in an instruction, or the result of a fault injection attack.

[0049] Furthermore, if a processing transition to block J part 2 occurs during the execution of part 2, which is the second half (2nd) of block I, it can be detected as an abort by the instruction MPU. Similarly, if a processing transition to block J part 1 occurs during the execution of part 1, which is the first half (1st) of block K, it can be detected as an abort by the instruction MPU.

[0050] On the other hand, if a fault injection attack occurs during the execution of block J part 1, this mechanism will not always detect the processing transition caused by the fault injection attack within the same part. Also, depending on the timing, processing transitions to the preceding and succeeding block I part 2 and block J part 2 may not be detected.

[0051] In other words, this simple mechanism allows CPU20 to prevent one or more parts from being completely skipped for the part it is currently executing, or to prevent a transition to two or more previous parts.

[0052] Figure 5 is an explanatory diagram of an example memory layout.

[0053] Figure 6 is an explanatory diagram illustrating an example of the uses of the MPU20A. Of the uses of the MPU20A shown in Figure 6, the most important uses are the instruction MPUs IMPU1 to IMPU3 and the data MPUs DMPU1 to DMPU4.

[0054] Figure 7 is a flowchart illustrating an example of the information processing flow executed by the CPU 20 in this embodiment. Figure 7 shows an example in which the CPU 20 executes a partial program (first partial program) including block J part 1 and block J part 2, and then executes a partial program (second partial program) of block K. Each specific process has a data area allocated in advance that corresponds to that specific process. That is, each specific process has a non-overlapping data area that can be used for that specific process that is allocated in advance.

[0055] Block J Part 1, executed by CPU 20, clears the instruction MPU execution permission corresponding to the previous part, Block I Part 2 (step S200). By processing in step S200, CPU 20 limits the scope of processing transitions due to fault injection attacks at the time of completion of step S200 to within Block J Part 1 of the subblock being processed.

[0056] Next, part 1 of block J, executed by CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_0 of block J (step S202). Unique process J_0 represents the unique process associated with the subprogram of block J, and represents the unique process that is executed for the first time.

[0057] Then, block J part 1, executed by CPU 20, uses the output data stored in the data output area (D0i) of the first unique process I_0 of the previous block I as input to its own unique process J_0. Then, block J part 1, executed by CPU 20, executes its own unique process J_0 and writes the output data from the unique process J_0 to the data area D0j that has been pre-allocated to the unique process J_0 (step S204).

[0058] Then, block J part 1, executed by CPU 20, clears the execution permission of the instruction MPU corresponding to its own specific process J_0 (step S206). Also, if block J part 1 uses a general-purpose library, it clears the general-purpose library as well. The description of MPU processing for general-purpose libraries is omitted below.

[0059] Then, block J part 1 executed by CPU 20 clears the write permission to the data MPU corresponding to the data area D0j of unique process J_0, making it write-prohibited and changing the setting to read-only (step S208).

[0060] Next, block J part 1, executed by CPU 20, waits for a predetermined time interval set randomly (step S210).

[0061] Next, part 1 of block J, executed by CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_1 of block J (step S212). Unique process J_1 represents a unique process associated with the subprogram of block J, and represents a unique process that is executed a second time.

[0062] Then, block J part 1, executed by CPU 20, uses the output data recorded in the data output area (D1i) of the second unique process I_1 of the previous block I as input to its own unique process J_1. Then, block J part 1, executed by CPU 20, executes its own unique process J_1 and writes the output data from that unique process J_1 to the data area D1j that was previously allocated to that unique process J_1 (step S214).

[0063] Then, block J part 1, executed by CPU 20, clears the execution permission of the instruction MPU corresponding to the unique process J_1 of block J part 1 (step S216).

[0064] Then, block J part 1 executed by CPU 20 clears the write permission to the data MPU corresponding to the data area D1j of unique process J_1, making it write-prohibited and changing the setting to read-only (step S218).

[0065] Next, block J part 1, executed by CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S220). In step S220, it may also be determined whether the digest values ​​of the output data match. The digest value is, for example, the hash value of the output data. That is, in step 220, the first subprogram executed by CPU 20 determines whether the output data for each unique process J_0, J_1 recorded in each of the first data areas (D0j, D1j) or the digest values ​​of the output data match.

[0066] If the CPU 20 determines in step S220 that block J part 1 is a mismatch (step S220: No), it aborts the process. On the other hand, if the CPU 20 determines in step S220 that block J part 1 is a match (step S220: Yes), it sets the execution permission for the instruction MPU corresponding to the next part, block J part 2 (step S222).

[0067] In this way, block J part 1, executed by CPU 20, redundantly executes the unique process J associated with the subprogram containing block J part 1 two or more times by executing the first unique process J_0 in steps S202 to S208 and the second unique process J_1 in steps S212 to S218. Then, block J part 1, executed by CPU 20, records each of the output data output for each unique process into the data areas D0j and D1j, respectively, which are pre-allocated to each.

[0068] Then, if the CPU 20 determines that the output data written to data area D0j matches the output data written to data area D1j (step S220: Yes), it sets the execution permission for the instruction MPU corresponding to the next part, block J part 2 (step S222).

[0069] Therefore, the CPU 20 of this embodiment can efficiently mitigate its vulnerability to the threat of fault injection attacks by executing the program shown in Figure 7.

[0070] Furthermore, in the redundant execution of the specific processing in steps S202 to S208 and steps S212 to S218, block J part 1 executed by the CPU 20 permits the execution of the instruction MPU, which is the instruction program for executing each specific processing, before writing the output data to the respective data areas D0j and D1j corresponding to each specific processing (steps S204 and S214) (steps S202 and S212). Then, block J part 1 executed by the CPU 20 prohibits the execution of the instruction MPU after the writing (steps S206 and S216).

[0071] Therefore, the CPU 20 of this embodiment can suppress the execution of instructions from parts other than those permitted in the instruction MPU during periods other than the execution of a specific process by the instruction MPU corresponding to that specific process.

[0072] Furthermore, block J part 1, executed by CPU 20, performs its respective specific processes J_0 and J_1 in steps S202 to S208 and steps S212 to S218 at randomly set predetermined time intervals (step S210).

[0073] Therefore, the MCU10 of this embodiment can make it more difficult for fault injection attacks common to each specific process J_0 and J_1 to be carried out.

[0074] As described above, each unique process is pre-allocated with a non-overlapping data area available for that process. In other words, the unique processes associated with each subprogram are mapped to a specific data area; that is, they are bound. Functions commonly used by the unique processes associated with each subprogram may be provided as a separate general-purpose library. By configuring the general-purpose library to utilize the data areas provided by the unique processes associated with each subprogram, the instruction image of the general-purpose library can be standardized. In this embodiment, due to the redundant execution nature of the unique processes, the general-purpose library can also be given the capability to detect fault injection attacks without requiring any special countermeasures against fault injection attacks.

[0075] Furthermore, as mentioned above, each unique process is pre-allocated with non-overlapping data areas that can be used for each unique process. However, each unique process does not require any particular countermeasures against fault injection attacks, such as branching. This is because if a fault injection attack occurs during the execution of a unique process, it will be detected as a mismatch in output data due to redundant execution of the unique process (see step S220, and step S228 described later).

[0076] In block K, the subprogram executed after block J, only the output data from unique process J_0, written to the data area D0j pre-allocated for unique process J_0, and the output data from unique process J_1, written to the data area D1j pre-allocated for unique process J_1, are processed as variable inputs. Therefore, even if a fault injection attack occurs during the execution of the subprogram in block J, it is extremely rare in a fault injection attack using VFI for the output data from unique process J_0 written to data area D0j and the output data from unique process J_1 written to data area D1j to be exactly the same.

[0077] Furthermore, if the processing of block J is very simple, calculations that have the property of propagating errors, such as hash calculations, may be processed in parallel. In this case, the MCU10 can enhance its ability to detect fault injection attacks.

[0078] Let's return to the flowchart in Figure 7 and continue the explanation.

[0079] Next, CPU20 starts executing block J part 2 (step S224). Block J part 2, executed by CPU20, does not perform any specific processing, but confirms that the specific processing in the preceding part, block J part 1, was successfully executed by referring to multiple pieces of evidence.

[0080] In detail, block J part 2, executed by CPU 20, clears the instruction MPU execution permission corresponding to the previous part, block J part 1 (step S226). By processing in step S226, CPU 20 limits the scope of processing transitions due to fault injection attacks at the time of completion of step S226 to block J part 2, which is the subblock being processed.

[0081] Next, block J part 2, executed by CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S228). In step S228, it may also be determined whether the digest values ​​of the output data match. The digest value is, for example, the hash value of the output data.

[0082] If the decision in step S228 is negative (Step S228: No), the CPU 20 aborts the process. If the decision in step S228 is positive (Step S228: Yes), the process proceeds to step S230.

[0083] In step S230, block J part 2, executed by CPU 20, determines whether its own block J's specific process J_0 was executed successfully (step S230).

[0084] In this embodiment, block J part 2 executed by the CPU 20 determines whether the setting value for the data area D0j pre-allocated to the specific processing J_0 of block J part 1 of the first subprogram matches the expected value for the data area. This setting value is an example of execution evidence. Specifically, block J part 2 executed by the CPU 20 determines whether the expected value representing "write prohibited, read only" for the data area D0j, which was set for the data MPU corresponding to the data area D0j in step S208, matches the setting value set for the data area D0j.

[0085] By executing the decision process in step S230, block J part 2, executed by the CPU 20, determines whether its own block J's specific process J_0 was executed successfully. This decision process makes it possible to exclude cases where, for example, the output data written to data area D0j matches the output data written to data area D1j, but specific processes J_0 and J_1 are not executed, simply because the initial values ​​of data area D0j and data area D1j match.

[0086] Furthermore, as mentioned above, a fault injection attack that bypasses all processing in block J part 1 and executes block J part 2 from block I part 2 is not simply possible. However, if a fault injection attack occurs that causes a transition to step S222 immediately after the execution of step S200 in block J part 1, it is possible that the processing of both redundantly executed unique processes J_0 and J_1 may be bypassed.

[0087] However, in this embodiment, when block I part 2 is executed by the CPU 20, both reading and writing to data area D0i and data area D1j are permitted. Writing to data area D0j and data area D1j is prohibited in steps S208 and S218, which follow steps S204 and S214, where specific processes J_0 and J_1 are executed. Therefore, in order to make the MPU settings match the expected value without executing specific processes J_0 and J_1, it is necessary to successfully perform fault injection attacks that accurately identify the processing transition destination by fault injection attacks two or more times, which is probabilistically extremely difficult. For this reason, the MCU 10 of this embodiment can mitigate its vulnerability to the threat of fault injection attacks.

[0088] Let's return to the flowchart in Figure 7 and continue the explanation.

[0089] If the decision in step S230 is negative (Step S230: No), the CPU 20 aborts the process. If the decision in step S230 is positive (Step S230: Yes), the process proceeds to step S232.

[0090] In step S232, part 2 of block J, executed by the CPU 20, sets read / write permissions for the data MPU corresponding to the data area D0k allocated to the first specific process K_0 of block K, which is the next subprogram (second subprogram) (step S232).

[0091] Next, block J part 2, executed by CPU 20, determines whether its own block J's specific process J_1 was executed successfully (step S234).

[0092] Similar to step S230, in this embodiment, block J part 2 executed by the CPU 20 determines whether the setting value for the data area D1j, which is pre-allocated to the specific processing J_1 of block J part 1 of the first subprogram and is the execution evidence, matches the expected value for the data area. Specifically, block J part 2 executed by the CPU 20 determines whether the expected value representing "write prohibited, read only" for the data area D1j, which was set for the data MPU corresponding to the data area D1j in step S218, matches the setting value set for the data area D1j.

[0093] If the decision in step S234 is negative (Step S234: No), the CPU 20 aborts the process. If the decision in step S234 is positive (Step S234: Yes), the process proceeds to step S236.

[0094] In step S236, part 2 of block J, executed by the CPU 20, sets read / write permissions for the data MPU corresponding to the data area D1k allocated to the second specific process K_1 of block K, which is the next subprogram (second subprogram) (step S236).

[0095] In other words, through the processing in steps S232 and S236, if block J, an example of the first partial program, is affirmed in step S228, and affirmed in each of steps S230 and S234, execution of block K, an example of the second partial program, is permitted, and block K, an example of the second partial program, is permitted to read and write to data areas D0k and D1k, which are second data areas pre-allocated to specific processes K_0 and K_1, which are second specific processes associated with block K.

[0096] Then, block J part 2, executed by CPU 20, sets the execution permission for the instruction MPU corresponding to block K part 1, which is the next subprogram to be executed (step S238).

[0097] In other words, if an affirmative decision is made in each of steps 220, S228, S230, and S234, block J, which is an example of the first subprogram, is allowed to execute block K, which is an example of the second subprogram that will be executed after the first subprogram.

[0098] Then, block K, executed by CPU 20, performs the same processing on itself as in steps S200 to S238. Similarly, the subprograms that are executed sequentially after block K should also perform the same processing on themselves as in steps S200 to S238.

[0099] As described above, the CPU 20 of the MCU 10 (information processing device) in this embodiment executes the first subprogram (block J) and the second subprogram (block K) in order. The first subprogram redundantly executes the first specific processing associated with the first subprogram two or more times (steps S202 to S208, steps S212 to S218). The first subprogram then records each of the output data output for each of the first specific processing (specific processing J_0, J_1) in the first data area (data area D0j, D1j) that has been allocated in advance. If the output data or the digest value of the output data for each of the first specific processing recorded in each of the first data areas matches (steps S220, step S228), it permits the execution of the second subprogram which will be executed after the first subprogram (step S238).

[0100] Therefore, the MCU10 of this embodiment can efficiently mitigate vulnerability to the threat of fault injection attacks.

[0101] In the past, it has been difficult to effectively mitigate vulnerability to the threat of fault injection attacks.

[0102] In detail, cybersecurity for so-called IoT devices has traditionally been a problem, and security measures are increasingly required even for low-cost devices. In terms of security measures, the threat of software vulnerabilities related to communications during operation is attracting attention, but these are essential functions not only for functions used during operation, but also for functions throughout the device lifecycle, including development, mass production, and return to service. On the other hand, appropriate control is required regarding the enabling and disabling of functions that, if exploited during operation, could lead to security breaches (internal intrusion functions). In addition to remote attacks via communications, security threats also include proximity fault injection attacks.

[0103] In relatively high-performance computer systems such as personal computers, the CPU, volatile memory, and non-volatile storage devices are often interconnected as separate components. However, in IoT devices, the CPU, volatile memory, non-volatile storage devices, and input / output control are provided as an integrated MCU package. Therefore, unless an attacker uses specialized skills and tools such as package opening, they cannot freely manipulate the information inside the MCU. However, threats are known where attackers can steal information or modify the operation of a target MCU by using methods such as indirect theft of confidential information through side-channel attacks or fault injection attacks.

[0104] As described above, the primary threat to the MCU10 in this embodiment is the latter type of fault injection attack, particularly the VFI method, which involves electrically connecting relatively inexpensive devices to terminals outside the package. As an attack with a similar effect to VFI, non-localized electromagnetic fault injection (EMFI), which does not require an electrical connection, can produce effects similar to VFI. The countermeasures of this application are effective against both VFI and EMFI.

[0105] Conventional attacks involving IC cards and other devices that exploit malfunctions caused by fault injection attacks to steal encryption keys within the chip, and countermeasures against such attacks, are well-known. However, when enabling or disabling functions is based on simple match comparison results rather than cryptographic calculations, the attacker's objective can sometimes be achieved by simply inverting the match comparison result. For example, consider a case where CPU debugging tool connection is permitted based on the result of a match comparison of a debug permission request input via communication. The attacker inputs a dummy debug permission request via the communication interface, and the MCU performs a verification process for the request, performing a match comparison to determine whether the verification succeeds or fails. When the verification is determined to be successful, the HW setting for debug permission is performed internally, allowing the attacker to connect an external debugger to the MCU and read or write information within the MCU. Here, we assume that the attacker has prior knowledge of when the match comparison is performed inside the MCU.

[0106] Several conventional techniques have been proposed to mitigate fault injection attacks against software processing, including non-cryptographic processing. For example, Non-Patent Document 2, "Fill your Boots: Enhanced Embedded Bootloader Exploits via Fault Injection and Binary Analysis," describes 10 vulnerable design patterns. However, this technique allows for the connection of a debugging tool simply by reversing the conditions of a single comparison.

[0107] This vulnerability can be exploited by performing multiple matching comparisons to reduce the probability of a successful attack.

[0108] Figure 8A is an explanatory diagram of an example of the prior art. Figure 8A shows the program to be protected in the form of a pseudo-program. For the sake of clarity, the program to be protected is shown here as a pseudo-program in a high-level language, but actual attacks affect the reading and processing of machine code instructions by the CPU.

[0109] Figure 8A shows a simulated program that demonstrates how the "DebugDecision" function calls the "CheckPermissionData" function to verify the signature of a pre-entered debug permission request "PermissionData," and if the signature verification is successful, it grants debug functionality and authorizes the user firmware.

[0110] Here, "PermssionData" is assumed to be data provided by the attacker that causes the signature verification to fail. The attacker performs a fault injection attack at the timing of the result determination process, which occurs immediately after the completion of the "CheckPermissionData" process. Normally, if signature verification fails, the "abort" process is executed based on the condition, and subsequent program execution is stopped.

[0111] However, if a fault injection attack is performed, various anomalies occur in the instructions executed at that time, such as machine language instructions becoming different instructions, register values ​​becoming incorrect, conditional checks becoming incorrect, and program counter values ​​becoming incorrect. In VFIs that use power supplies, localized fault injection attacks are difficult, so the attacker cannot choose which effects occur. However, it has been reported that by controlling the timing of the fault injection attack, it is possible to cause a certain probability of reversal of conditional checks and other anomalies.

[0112] In the attack scenario shown in Figure 8A, the "CheckPerssionData" function is executed, and immediately afterward, the condition check should have stopped the process. However, the system continues, assuming the verification was successful. Subsequently, the "EnableDebug" function is executed, allowing a connection to an external debugger, and the user firmware is then executed. While this function is necessary as it only allows debugging if permitted, there is a concern that the check can be bypassed by a relatively simple fault injection attack.

[0113] Furthermore, for the attack to succeed in the above attack scenario, it is assumed that the program execution proceeds normally except at the time of the fault injection attack. If all instructions are replaced with random abnormal behavior unrelated to the original program, the above attack scenario will not work. Also, in the above case, "EnableDebug" will be executed, and the attacker will have no way of directly knowing whether the attack was successful; it will only be possible through indirect methods such as successfully connecting an external debugger. Due to these constraints, in an attack scenario that is effective in VFI, it is necessary to pre-determine several time points in which attack attempts will be made and to determine whether the attack was successful after each attempt.

[0114] Figure 8B is an explanatory diagram of an example of the prior art. Figure 8B shows a program that implements a simple countermeasure against the attack in Figure 8A, taking into account the above constraints for the attack scenario.

[0115] In Figure 8A, the success / failure determination of "CheckPermissionData" is compared twice. By performing the comparison twice, even if the verification failure is bypassed in the first comparison, the attack scenario will fail if it is aborted in the second comparison. According to Non-Patent Literature 2, the success rate of condition inversion on a simple 8-bit microcontroller is reported to be around 0.1%, and the probability of condition inversion is generally lower on more complex CPUs. By repeating the comparison, time-domain redundancy can be created, thereby lowering the success rate of the above attack scenario.

[0116] However, as already explained, VFI can have effects other than condition inversion. Changes to instructions that do not affect the program execution order, and many register values, can have their probability reduced by performing the above value checks multiple times. However, the above countermeasures are not effective when the value of the program counter (hereinafter referred to as PC) is changed directly, or when changes occur to instructions that change the program execution order, such as jumps and branches.

[0117] Figure 8C is an explanatory diagram illustrating an example of the prior art.

[0118] Figure 8C illustrates a scenario where a fault injection attack occurs during the execution of the instruction immediately preceding the execution of "CheckPermissionData," causing the PC to become the starting point for the execution of "EnableDebug." Assuming that PC anomalies occur uniformly across the CPU address space (e.g., 32 bits), the likelihood of this attack scenario occurring is quite low. However, compared to the security of cryptography, which currently requires effective key lengths of 100 bits or more, this threat cannot be ignored. Furthermore, while the above example involves a simple process where debugging is permitted after verification, if this were a more complex transaction involving multiple conditional judgments and saving the results to storage (committing non-volatile memory data and I / O control only if the entire process ultimately succeeds), evaluating the attack scenario and implementing countermeasures in the program would become more complex.

[0119] Furthermore, as a countermeasure against proximity fault injection attacks in software execution, there is a hardware redundancy method called DCLS (Dual Core Lock System) as shown in Patent Document 1. However, DCLS requires two CPU cores to be installed and to perform comparison operations for each logic clock, thus requiring the original CPU and the comparator logic circuit. Moreover, the operating frequency is significantly lower compared to a single CPU, resulting in a large hardware cost and performance penalty.

[0120] In other words, conventional technologies have made it difficult to effectively mitigate vulnerability to the threat of fault injection attacks.

[0121] On the other hand, the CPU 20 of the MCU 10 (information processing device) in this embodiment executes the first subprogram (block J) and the second subprogram (block K) in order. The first subprogram redundantly executes the first specific processing associated with the first subprogram two or more times (steps S202 to S208, steps S212 to S218). The first subprogram then records each of the output data output for each of the first specific processing (specific processing J_0, J_1) in the first data area (data area D0j, D1j) that has been allocated in advance for each of the first specific processing. If the output data or the digest value of the output data for each of the first specific processing recorded in each of the first data areas matches (steps S220, step S228), it permits the execution of the second subprogram which will be executed after the first subprogram (step S238).

[0122] Therefore, the MCU10 of this embodiment can efficiently mitigate vulnerability to the threat of fault injection attacks.

[0123] Furthermore, in order for the CPU 20 of the MCU 10 in this embodiment to execute the above-mentioned processing, complex processing such as cryptographic processing and transaction processing is treated as the above-mentioned specific processing, so that existing high-performance program libraries without fault injection attack countermeasures can be used as is.

[0124] Furthermore, the CPU 20 of the MCU 10 in this embodiment can be run using a general-purpose single-core CPU with memory protection functionality, and can be configured without requiring special high-reliability CPU hardware such as DCLS (Dual Core Lock System).

[0125] Furthermore, as explained with reference to Figure 7, the CPU 20 of the MCU 10 in this embodiment sequentially executes the partial program, and aborts the process if the result of the matching or non-matching determination (steps S220, S228, S230, and S234) indicates a mismatch. Also, as explained with reference to Figure 7, the CPU 20 of the MCU 10 in this embodiment aborts the process when it determines that there is a mismatch if at least one of the results of the multiple matching or non-matching determinations (steps S220, S228, S230, and S234) indicates a mismatch.

[0126] Furthermore, as explained with reference to Figure 7, the CPU 20 of the MCU 10 in this embodiment is limited to the output data of the immediately preceding subprogram that can be directly referenced by a subprogram. This restriction allows for multiple checks to confirm that the execution of 12 subprograms prior to a given subprogram has been completed while the current subprogram is running.

[0127] Furthermore, the CPU 20 of the MCU 10 in this embodiment executes the processing shown in Figure 7. By effectively combining the basic structure of sequential execution by the instruction MPU with two elements—redundant execution of specific processing and utilization of the data MPU—it is possible to mitigate vulnerability to the threat of fault injection attacks.

[0128] Furthermore, the CPU 20 of the MCU 10 in this embodiment executes the process shown in Figure 7. Therefore, sequential processing proceeds normally when two values ​​match, or when the address range defined in the instruction MPU and data MPU matches the access destination. If processing proceeds despite a mismatch in values, the condition can be easily reversed if an error occurs in any of the registers storing the values ​​due to a fault injection attack. The CPU 20 of the MCU 10 in this embodiment aborts if the values ​​do not match, as described above, making it resistant to the threat of fault injection attacks. Also, if the algorithm includes a condition for mismatch in values, it can be implemented within the specific processing.

[0129] Furthermore, in the CPU 20 of the MCU 10 of this embodiment, each processing step shown in Figure 7 is executed sequentially, but in actual processing, there may be cases where it is desirable to omit certain processing steps. In such cases, this can be addressed by incorporating a procedure to skip that processing step within the specific processing of a certain block. If it is desired to confirm whether or not the processing included in the specific processing has been skipped, this can be addressed by configuring the system to write the confirmation result to a data area.

[0130] In the CPU 20 of the MCU 10 of this embodiment, processing steps are blocked and a mechanism is provided to detect inconsistencies caused by fault injection attacks in each block. Therefore, in the MCU 10 of this embodiment, countermeasures against the threat of fault injection attacks can be implemented without making special modifications for fault injection attack countermeasures to specific processing or general-purpose libraries outside the block structure.

[0131] Furthermore, the CPU 20 of the MCU 10 in this embodiment enables fault injection attack countermeasures even in a general-purpose MCU equipped with an MPU, rather than requiring special hardware such as dual-core lockstep. Utilizing dual-core lockstep as a fault injection attack countermeasure can be considered overkill if high-level malfunction prevention is not required for all applications. However, the CPU 20 of the MCU 10 in this embodiment can provide countermeasures against the threat of fault injection attacks for a limited number of processes.

[0132] Furthermore, since the CPU 20 of the MCU 10 in this embodiment occupies multiple MPUs, its introduction into task implementations of an RTOS (Real-Time Operating System) that similarly uses MPUs requires adjustment of the MPUs used. On the other hand, the MCU 10 in this embodiment is particularly suitable for fault injection countermeasures for sequential processing in environments where all MPUs are freely available before RTOS startup, such as secure boot prior to RTOS execution.

[0133] Furthermore, preventing bypasses and guaranteeing the execution order during program execution on the CPU 20 of the MCU 10 in this embodiment are part of the impact of fault injection attacks, and error detection of register values ​​is also necessary. However, as already explained, errors in register values ​​can be detected by multiple checks, or in the case of complex calculations, by redundant execution of the specific processing described above and comparison of the results. For this reason, it is relatively easy to estimate the scope of impact and the preventative effect of countermeasures in the MCU 10 of this embodiment. In addition, it is generally considered difficult to estimate the impact of fault injection on a PC and the preventative effect of countermeasures for complex programs. However, in the MCU 10 of this embodiment, countermeasures that can prevent the impact of fault injection attacks, especially fault injection attacks in two or more locations, with a high probability can be introduced without changing the software implementation of each specific processing, making it highly useful.

[0134] In this embodiment, the CPU 20 of the MCU 10 is described as a means of confirming that the specific processing has been executed successfully, by confirming the results of the setting changes (steps S208 and S218) to data areas D0j and D1j after the execution of specific processing J_0 and specific processing J_1 in steps S204 and S214, respectively, in steps S230 and S234 of the next part, block J part 2. This is to prevent the confirmation process from succeeding incorrectly if the initial value of the data area is 0 and both specific processing J_0 and specific processing J_1 are skipped within the part due to two or more fault injection attacks.

[0135] Furthermore, if there are auxiliary means such as random initialization of the data area contents through software or hardware processing during MCU10 startup, this verification process can be omitted.

[0136] (Second embodiment) In the above embodiment, the block J part 2 executed by the CPU 20 determines whether its own block J's specific processes J_0 and J_1 have been executed successfully by determining whether the setting values ​​for the data areas D0j and D1j, which are pre-allocated to each specific process, match the expected values ​​for each data area (see steps S230 and S234 in Figure 7).

[0137] In this embodiment, the CPU 20 of the MCU 10 determines whether or not a specific process has been successfully executed using values ​​written to the execution evidence storage area, which is a different area in the library from the output data area D0j and data area D1j.

[0138] Figure 9 is an explanatory diagram of an example of the memory layout in this embodiment. In addition to the memory layout described in the above embodiment (see Figure 5), the memory layout shown in Figure 9 includes execution evidence storage areas (Evidence_I, Evidence_J, Evidence_K) for each of blocks I, J, and K.

[0139] The execution evidence storage area is a different area within the library from the output data areas such as data area D0j and data area D1j, and is the area where evidence values ​​are written after the execution of specific processing.

[0140] Figure 10 is a flowchart showing an example of the information processing flow executed by the CPU 20 in this embodiment. The flowchart shown in Figure 10 is the same as the flowchart shown in Figure 7, but with the processing of steps S310-S314 added, and steps S230 and S234 replaced with the processing of steps S336 and S340.

[0141] In detail, the CPU 20 of MCU 10 executes the processing in steps S300 to S308 in the same manner as steps S200 to S208.

[0142] In detail, Block J Part 1, executed by the CPU 20 of MCU 10, clears the execution permission for the instruction MPU corresponding to the previous part, Block I Part 2 (step S300). Next, Block J Part 1, executed by the CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_0 of its own block J (step S302). Then, Block J Part 1, executed by the CPU 20, executes the unique process J_0 of its own block J Part 1 and writes the output data from the unique process J_0 to the data area D0j pre-allocated to the unique process J_0 (step S304). Then, Block J Part 1, executed by the CPU 20, clears the execution permission for the instruction MPU corresponding to the unique process J_0 of its own block J Part 1 (step S306). Then, block J part 1 executed by CPU 20 clears the write permission to the data MPU corresponding to the data area D0j of unique process J_0, making it write-prohibited and changing the setting to read-only (step S308).

[0143] Next, block J part 1, executed by CPU 20, sets read / write permissions for the MPU 20A to the execution evidence storage area Evidence_J pre-allocated to block J (step S310). Then, block J part 1, executed by CPU 20, writes a predetermined evidence value to the execution evidence storage area Evidence_J (step S312).

[0144] The evidence value can be any predetermined value that indicates that a specific process has been completed. Each block can use a value unique to that block as its evidence value. For example, the evidence value may be a random value.

[0145] Then, block J part 1, executed by CPU 20, is made write-prohibited by clearing the write permission for the execution evidence storage area Evidence_J (step S314).

[0146] Then, the CPU 20 executes the processing of steps S316 to S334 in the same manner as steps S210 to S228 of the first embodiment.

[0147] In detail, block J part 1, executed by CPU 20, waits at a predetermined time interval set randomly (step S316). Next, block J part 1, executed by CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_1 of its own block J (step S318). Then, block J part 1, executed by CPU 20, executes the unique process J_1 of its own block J part 1 and writes the output data of the unique process J_1 to the data area D1j that has been pre-allocated to the unique process J_1 (step S320). Then, block J part 1, executed by CPU 20, clears the execution permission for the instruction MPU corresponding to the unique process J_1 of its own block J part 1 (step S322). Then, block J part 1, executed by CPU 20, clears the write permission to the data area D1j of the unique process J_1 for the data MPU corresponding to the data area D1j, making it write-prohibited and changing the setting to read-only (step S324).

[0148] Next, Block J Part 1, executed by the CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S326). If Block J Part 1, executed by the CPU 20, determines in step S326 that there is a mismatch (step S326: No), it aborts the process. On the other hand, if Block J Part 1, executed by the CPU 20, determines in step S326 that there is a match (step S326: Yes), it sets the execution permission for the instruction MPU corresponding to the next part, Block J Part 2 (step S328).

[0149] Next, the CPU 20 starts executing block J part 2 (step S330). Block J part 2, executed by the CPU 20, clears the instruction MPU execution permission corresponding to the previous part, block J part 1 (step S332). Next, block J part 2, executed by the CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S334). If the determination in step S334 is negative (step S334: No), the CPU 20 aborts the process. If the determination in step S334 is positive (step S334: Yes), the process proceeds to step S336.

[0150] In step S336, block J part 2, executed by CPU 20, determines whether its own block J's specific process J_0 was executed successfully (step S336).

[0151] In this embodiment, block J part 2 executed by CPU 20 determines, by the process in step S312, whether the evidence value written to the execution evidence storage area J after the execution of specific process J_0 matches the estimated evidence value (step S336).

[0152] Let's consider the case where a predetermined value is used for the evidence value written in step S312. In this case, in step S336, it is sufficient to determine whether the evidence value written in the execution evidence storage area J matches the predetermined value.

[0153] Furthermore, consider the case where the evidence value written in step S312 is a random value. In this case, the CPU 20 should generate and store a random value before executing the specific processing in step S304, and then write the random value to the execution evidence storage area J during the processing in step S312. Then, in step S336, it should be determined whether the evidence value written to the execution evidence storage area J matches the stored random value.

[0154] For example, CPU20 can generate random values ​​each time it is executed during initialization procedures not included in this flowchart, and store these random values ​​in a designated CPU register or memory. By applying a mask value specific to each block to these random values, malfunctions that might occur if the previous evidence value remains in memory can be avoided.

[0155] If the decision in step S336 is negative (Step S336: No), the CPU 20 aborts the process. If the decision in step S336 is positive (Step S336: Yes), the process proceeds to step S338.

[0156] In step S338, similar to step S232, part 2 of block J executed by the CPU 20 sets read / write permission to the data MPU corresponding to the data area D0k allocated to the first specific process K_0 of block K, which is the next subprogram (second subprogram) (step S338).

[0157] Next, in step S340, block J part 2, executed by CPU 20, determines whether its own block J's specific process J_1 was executed successfully (step S340).

[0158] In this embodiment, block J part 2 executed by the CPU 20 determines, by the process in step S312, whether the evidence value written to the execution evidence storage area J after the execution of specific process J_0 matches the estimated evidence value (step S340). The determination in step S340 is the same as in step S336.

[0159] If the decision in step S340 is negative (step S340: No), the CPU 20 aborts the process. If the decision in step S340 is positive (step S340: Yes), the process proceeds to step S342.

[0160] CPU20 executes the processes in steps S342 to S344 in the same manner as in steps S236 to S238.

[0161] In detail, Block J Part 2, executed by CPU 20, sets read / write permissions for the data MPU corresponding to the data area D1k allocated to the second specific process K_1 of Block K, which is the next subprogram (second subprogram), to the said data area D1k (step S342). Then, Block J Part 2, executed by CPU 20, sets execution permission for the instruction MPU corresponding to Block K Part 1, which is the next subprogram to be executed (step S344). Then, Block K, executed by CPU 20, performs the same processing on itself as Block J.

[0162] In the MCU10 (information processing device) of this embodiment, as in the above embodiment, it is possible to efficiently mitigate vulnerability to the threat of fault injection attacks.

[0163] (Third embodiment) In the above embodiment, as shown in Figure 4, the case in which each subprogram of block I, block J, and block K is configured as two parts, part 1 and part 2, was described as an example. However, each block, which is a subprogram, may be configured as three or more parts.

[0164] In this embodiment, we will describe an example in which each block, or subprogram, is composed of three parts.

[0165] Figure 11 shows an example of a sequential execution structure for subprograms executed by the CPU 20. Figure 11 shows a simple configuration in which the CPU 20 uses only the virtual instruction IMPUset to guarantee the execution order of subprograms even if a fault injection attack occurs to the MCU 10.

[0166] For example, CPU20 executes each subprogram of block I, block J, and block K in this order. Each block consists of three parts. Figure 11 shows only the final part (part 3) and the first part (part 1) of block I and block K, respectively, and shows all three parts of block J.

[0167] In this embodiment, each block executed by the CPU 20 performs its first unique processing in Part 1 and its second unique processing in Part 2.

[0168] Figure 12 is an explanatory diagram of an example of the memory layout in this embodiment. In addition to the memory layout described in the above embodiment (see Figure 9), the memory layout shown in Figure 12 includes additional information about Part 3 in each of blocks I, J, and K.

[0169] Figure 13 is a flowchart showing an example of the information processing flow performed by the CPU 20 in this embodiment.

[0170] In detail, the CPU 20 of MCU 10 executes the processing of steps S400 to S416 in the same manner as steps S300 to S316.

[0171] In detail, Block J Part 1, executed by the CPU 20 of MCU 10, clears the execution permission for the instruction MPU corresponding to the previous part, Block I Part 2 (step S400). Next, Block J Part 1, executed by the CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_0 of its own block J (step S402). Then, Block J Part 1, executed by the CPU 20, executes the unique process J_0 of its own block J Part 1 and writes the output data of the unique process J_0 to the data area D0j that has been pre-allocated for the unique process J_0 (step S404). Then, Block J Part 1, executed by the CPU 20, clears the execution permission for the instruction MPU corresponding to the unique process J_0 of its own block J Part 1 (step S406). Then, block J part 1 executed by CPU 20 clears the write permission to the data MPU corresponding to the data area D0j of unique process J_0, making it write-prohibited and changing the setting to read-only (step S408).

[0172] Next, block J part 1, executed by CPU 20, sets read / write permissions for MPU 20A to the execution evidence storage area Evidence_J pre-allocated to block J (step S410). Then, block J part 1, executed by CPU 20, writes a predetermined evidence value to the execution evidence storage area Evidence_J (step S412). Then, block J part 1, executed by CPU 20, waits for a predetermined time interval set randomly (step S416).

[0173] Next, block J part 1, executed by CPU 20, sets the execution permission for the instruction MPU corresponding to the next part, block J part 2 (step S418). Then, CPU 20 starts executing block J part 2 (step S420). Block J part 2, executed by CPU 20, clears the execution permission for the instruction MPU corresponding to the previous part, block J part 1 (step S422). The processes in steps S418, S420, and S422 are the same as those in steps S328, S330, and S332, respectively.

[0174] Next, the CPU 20 executes the processes in steps S424 to S432. The processes in steps S424 to S432 are the same as those in steps S318 to S326, except that block J part 2 is executed instead of block J part 1.

[0175] In detail, Block J Part 2, executed by CPU 20, sets execution permission for the instruction MPU corresponding to the unique process J_1 of Block J (step S424). Then, Block J Part 2, executed by CPU 20, executes the unique process J_1 of Block J and writes the output data of the unique process J_1 to the data area D1j that has been pre-allocated to the unique process J_1 (step S426). Then, Block J Part 2, executed by CPU 20, clears the execution permission for the instruction MPU corresponding to the unique process J_1 of Block J (step S428). Then, Block J Part 2, executed by CPU 20, clears the write permission to the data area D1j of the unique process J_1 for the data MPU, making it write-prohibited and changing the setting to read-only (step S430).

[0176] Next, block J part 2, executed by CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S432). If block J part 2, executed by CPU 20, determines in step S432 that there is no match (step S432: No), it aborts the process. On the other hand, if block J part 2, executed by CPU 20, determines in step S432 that there is a match (step S432: Yes), it proceeds to step S434.

[0177] In step S434, block J part 2, executed by CPU 20, sets the execution permission for the instruction MPU corresponding to the next part, block J part 3 (step S434). Then, block J part 2, executed by CPU 20, clears the execution permission for the instruction MPU corresponding to the previous part, block J part 2 (step S436).

[0178] Next, the CPU 20 executes the processes in steps S438 to S448 in the same manner as in steps S334 to S344.

[0179] In detail, block J part 3, executed by CPU 20, determines whether the output data written to data area D0j matches the output data written to data area D1j (step S438). If the determination in step S438 is negative (step S438: No), CPU 20 aborts the process. If the determination in step S438 is positive (step S438: Yes), the process proceeds to step S440.

[0180] In step S440, block J part 3, executed by CPU 20, determines whether its own block J's specific process J_0 was executed successfully (step S440). In step S440, for example, block J part 2, executed by CPU 20, determines whether the evidence value written to the execution evidence storage area J after the execution of specific process J_0 by the process in step S412 matches the estimated evidence value.

[0181] If the decision in step S440 is negative (step S440: No), the CPU 20 aborts the process. If the decision in step S440 is positive (step S440: Yes), the process proceeds to step S442.

[0182] In step S442, part 3 of block J, executed by the CPU 20, sets read / write permission to the data MPU corresponding to the data area D0k allocated to the first specific process K_0 of block K, which is the next subprogram (second subprogram) (step S442).

[0183] Next, in step S444, block J part 3, executed by CPU 20, determines whether its own block J's specific process J_1 was executed successfully (step S444). In step S444, for example, block J part 3, executed by CPU 20, determines whether the evidence value written to the execution evidence storage area J after the execution of specific process J_0 by the process in step S412 matches the estimated evidence value (step S444). The determination in step S444 is the same as in step S440.

[0184] If the decision in step S444 is negative (Step S444: No), the CPU 20 aborts the process. If the decision in step S444 is positive (Step S444: Yes), the process proceeds to step S446.

[0185] The CPU 20 executes the processes in steps S446 to S448 in the same manner as in steps S342 to S344.

[0186] In detail, part 3 of block J, executed by CPU 20, sets read / write permission for the data MPU corresponding to the data area D1k allocated to the second specific process K_1 of block K, which is the next subprogram (second subprogram), to the data area D1k (step S446). Then, part 3 of block J, executed by CPU 20, sets execution permission for the instruction MPU corresponding to part 1 of block K, which is the next subprogram to be executed (step S448). Then, block K, executed by CPU 20, performs the same processing on itself as block J.

[0187] Thus, in this embodiment, the first subprogram executed by the CPU 20 executes each of the two or more specific processes that are redundantly executed after granting permission to execute the specific process, and clears the permission to execute the specific process after it has been executed (steps S418, S448).

[0188] In the MCU10 (information processing device) of this embodiment, as in the above embodiment, it is possible to efficiently mitigate vulnerability to the threat of fault injection attacks.

[0189] Furthermore, the decision processing in step S438, the decision processing in step S440, and the decision processing in step S444, which are executed by block J part 3 executed by the CPU 20 of this embodiment, may each be further divided into individual parts and executed separately.

[0190] In the MCU10 of the above embodiment, the CPU20 reads a program from the non-volatile memory 24 or non-volatile memory 23, etc., onto the volatile memory 25 and executes it, thereby realizing each of the above processes on the computer.

[0191] The program for executing each of the above processes performed by the MCU10 in the above embodiment may be stored in the HDD (hard disk drive). Alternatively, the program for executing each of the above processes performed by the MCU10 in the above embodiment may be pre-installed and provided in the non-volatile memory 23.

[0192] Furthermore, the program for executing the above-mentioned process performed by the MCU10 of the above embodiment may be provided as a computer program product by being stored in an installable or executable file format on a computer-readable storage medium such as a CD-ROM, CD-R, memory card, DVD (Digital Versatile Disc), or flexible disk (FD). Alternatively, the program for executing the above-mentioned process performed by the MCU10 of the above embodiment may be stored on a computer connected to a network such as the Internet and provided by being downloaded via the network. Alternatively, the program for executing the above-mentioned process performed by the MCU10 of the above embodiment may be provided or distributed via a network such as the Internet.

[0193] Although embodiments of the present invention have been described above, these embodiments are presented as examples only and are not intended to limit the scope of the invention. This novel embodiment can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. This embodiment and its variations are included in the scope and spirit of the invention, as well as in the claims of the invention and its equivalents.

[0194] Furthermore, the specific processing in this embodiment may include processing related to important decisions that are necessary to prevent unauthorized use, such as granting permission to access the inside of the MCU or to update internal information in the MCU and MCU application devices. Examples of important decisions include determining whether to activate (enable) software debugging functions and hardware testing functions, which are necessary for operations such as development, mass production, recall (defect fix), and software updates, but are normally inactive (disabled) during operation. In addition, the MCU 10 of this embodiment can also be used to reliably disable certain functions that are required to be disabled by legal regulations under the user's usage conditions, such as functions related to radio frequencies or medical devices that are not permitted in certain countries. [Explanation of symbols]

[0195] 10 MCU Package (Information Processing Unit) 20 CPU 20A MPU

Claims

1. Equipped with a CPU, The aforementioned CPU, The first and second subprograms are executed in order. The first subprogram is, The specific processing associated with the first subprogram is executed redundantly two or more times, and each of the output data output for each specific processing is recorded in a first data area that has been pre-allocated to it. If the output data or the digest value of the output data for each of the specific processes recorded in each of the first data areas matches, Allows the execution of the second subprogram which is executed after the first subprogram, Information processing device.

2. The first subprogram is, If the output data for each of the specific processing areas recorded in each of the first data areas, or the digest value of the output data, matches, The execution of the second subprogram is permitted, and the reading and writing of the second data area pre-allocated for the second specific processing associated with the second subprogram is permitted. The information processing apparatus according to claim 1.

3. The first subprogram is, Based on the evidence of the execution of the aforementioned specific process, it is determined whether the specific process was executed successfully, and if it is determined that it was executed successfully, the execution of the second subprogram is permitted. The information processing apparatus according to claim 1.

4. If the execution evidence, which is the setting value for the first data area of ​​the first subprogram, is determined to match the expected value for the first data area, then it is determined that the specific processing has been executed successfully. The information processing apparatus according to claim 3.

5. If it is determined that the evidence value written to the execution evidence storage area, which is a different area in the library from the data area of ​​the output data, after the execution of the specific process matches the estimated evidence value, then it is determined that the specific process was executed successfully. The information processing apparatus according to claim 3.

6. The aforementioned evidence value is a predetermined value that indicates that the specific processing has been completed. The information processing apparatus according to claim 5.

7. The aforementioned evidence values ​​are random values. The information processing apparatus according to claim 5.

8. The aforementioned specific processing is, It is a program that does not have countermeasures against fault injection attacks, and is a program that can be called from each of the first and second subprograms. The information processing apparatus according to claim 1.

9. The aforementioned CPU is If the result of the matching / not matching determination indicates a mismatch, abort the process. The information processing apparatus according to claim 1.

10. The aforementioned CPU is If at least one of multiple judgment results indicates a discrepancy, the process is aborted at the time the discrepancy is determined. The information processing apparatus according to claim 1.

11. The first subprogram is, Before writing the output data to the first data area, The execution of the instruction program for performing the aforementioned specific processing is permitted, After the write operation, the execution of the instruction program is prohibited. The information processing apparatus according to claim 1.

12. The first subprogram is, For each of the two or more of the aforementioned specific processes that are to be executed redundantly, the specific process is executed after permission for execution is granted, and the permission for execution of the specific process is cleared after the execution of the specific process. The information processing apparatus according to claim 1.

13. The first subprogram executes a plurality of the specific processes at randomly set predetermined time intervals. The information processing apparatus according to claim 1.

14. A method of information processing performed by a computer, The computer includes a first partial program and a second partial program that are executed in order, The first subprogram is, The specific processing associated with the first subprogram is executed redundantly two or more times, and each of the output data output for each specific processing is recorded in a first data area that has been pre-allocated to it. If the output data or the digest value of the output data for each of the specific processes recorded in each of the first data areas matches, Allows the execution of the second subprogram which is executed after the first subprogram, Information processing methods.

15. An information processing program to be executed by a computer, It includes a first and second program subprogram that are executed in sequence, The first subprogram is, The specific processing associated with the first subprogram is executed redundantly two or more times, and each of the output data output for each specific processing is recorded in a first data area that has been pre-allocated to it. If the output data or the digest value of the output data for each of the specific processes recorded in each of the first data areas matches, Allows the execution of the second subprogram which is executed after the first subprogram, Information processing program.

Images