JP6622360B2 - Information processing device - Google Patents

Description

  The present embodiment relates to an information processing apparatus and a control method.

  An information processing apparatus such as a microcontroller performs a predetermined operation according to the activated program. At this time, it is desired to start the program appropriately and at high speed.

International Publication No. 2009/013831 JP 2003-216445 A International Publication No. 2010/021269

Arbaugh, W.H. Farber, D .; & Smith, J.A. , A secure and reliable bootstrap architecture, Security and Privacy, 1997. Proceedings. , 1997 IEEE Symposium on, 1997, 65-71.

  An object of one embodiment is to provide an information processing apparatus capable of starting a program appropriately and at high speed.

According to one embodiment, an information processing apparatus is provided that includes a nonvolatile memory, a first flag, a switching circuit, a verification circuit, and a second flag . The first flag can be set to a first value and a second value. The first value indicates that the program stored in the first memory area in the nonvolatile memory has not been verified. The second value indicates that the program has been verified. Switching circuit in response to the rewriting permission request of a program executed in an information processing apparatus, it sets the first value to the first flag. The verification circuit sets a second value in the first flag in accordance with verification of the program stored in the first memory area. The verification circuit performs a verification process on the program when the first value is set in the first flag in response to the restart of the information processing apparatus, and the second value is set in the first flag. If so, the program is executed without performing verification processing. The second flag can be set to a third value and a fourth value. The third value is a value indicating that rewriting to the first memory area is prohibited. The fourth value is a value indicating that rewriting to the first memory area is permitted. In response to the change of the second flag from the third value to the fourth value, the first value is set in the first flag. Prior to the execution of the verification process, the third value is set in the second flag.

The block diagram which shows the function structure of the information processing apparatus concerning embodiment. The figure which shows the function of the rewriting control flag and verification status flag in embodiment. The block diagram which shows the hardware constitutions of the information processing apparatus concerning embodiment. 6 is an exemplary flowchart illustrating an operation in response to a rewrite permission request of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. 6 is an exemplary flowchart illustrating an operation according to a verification request of the information processing apparatus according to the embodiment. 6 is an exemplary flowchart illustrating an operation corresponding to a restart process of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. FIG. 5 is a sequence diagram showing an operation of the information processing apparatus according to the embodiment. The block diagram which shows the hardware constitutions of the information processing apparatus concerning the modification of embodiment. 9 is a flowchart showing an operation in response to a rewrite permission request of the information processing apparatus according to the modification of the embodiment. 10 is a flowchart showing an operation according to a verification request of the information processing apparatus according to the modification of the embodiment. The block diagram which shows the hardware constitutions of the information processing apparatus concerning the other modification of embodiment. The flowchart which shows the operation | movement according to the restart process of the information processing apparatus concerning the other modification of embodiment.

Exemplary embodiments of an information processing apparatus will be explained below in detail with reference to the accompanying drawings. In addition, this invention is not limited by this embodiment.
(Embodiment)
An information processing apparatus according to an embodiment will be described. The information processing apparatus can be applied to, for example, a controller (ECU) that electrically controls each part of an automobile and a controller that controls each part of a sensor node (smart meter) that transmits observation values wirelessly. Since these controllers are required to be reduced in size and cost, the information processing apparatus is mounted as a microcontroller (embedded microcomputer) configured by one chip, for example. This information processing apparatus performs a predetermined operation according to the activated system program. At this time, in order to detect and prevent unauthorized alteration of the system program at the time of startup, the information processing apparatus is configured to be able to execute secure boot.

  For example, various functions are realized by software, and the scope of the functions extends to the safety functions of devices such as social infrastructure and automobiles that cause serious disasters. In addition, various cyber attacks have been conducted against computer systems, increasing the sophistication of techniques, and causing damage such as shutting down the power system. Secure boot is a basic cyber attack countermeasure means that confirms the trust base of a computer system by confirming the legitimacy of the system program at the time of startup.

  On the other hand, information processing devices that are assumed to be applied to ECUs, sensor nodes, etc. have limited processing capabilities in order to meet the demands for downsizing and cost reduction. It is necessary to speed up the startup process of the system program while minimizing the frequency. That is, the information processing apparatus is desired to start the system program appropriately and at high speed.

  For example, an embedded microcomputer employs an XIP (eXecut In Place) system in which the contents of a non-volatile flash memory are executed as they are without being expanded to DRAM. In this case, if there is no secure boot, the execution of the application on the flash memory can be started immediately after startup. However, when the secure boot is performed, the reading of the program image and the fingerprint calculation are delayed as they are. Compared to a large-scale, high-speed processor installed in a personal computer, embedded microcomputers have low memory and fingerprint calculation throughput and large delays, so the system program can be executed with the minimum number of secure boot executions required. There is a high need to speed up the startup process.

  Therefore, in this embodiment, the following measures are taken and the execution frequency of the secure boot is appropriately controlled to reliably detect and prevent unauthorized alteration of the program (system program) and to reduce the average startup time of the program. Shorten.

  FIG. 1 is a block diagram illustrating a functional configuration of the information processing apparatus 1. The information processing apparatus 1 (microcontroller) is configured to be able to execute secure boot. The information processing apparatus 1 includes a nonvolatile memory 10, a nonvolatile memory 20, a rewrite permission unit 30, a program verification necessity determination unit 40, a program verification unit 50, and an instruction execution unit 60. Functions related to secure boot can be realized by the rewrite permission unit 30, the program verification necessity determination unit 40, and the program verification unit 50.

  The functions of the rewrite permission unit 30, the program verification necessity determination unit 40, the program verification unit 50, and the instruction execution unit 60 may be implemented in hardware (for example, as a circuit) in the information processing apparatus 1. However, it may be implemented in software (for example, as a functional module stored in the nonvolatile memory 20 and read in a batch or sequentially in accordance with the progress of processing). Alternatively, some functions may be implemented in hardware in the information processing apparatus 1, and the remaining functions may be implemented in software in the information processing apparatus 1.

  The nonvolatile memory 20 is a memory that stores information in a nonvolatile manner and cannot be rewritten, and is, for example, a mask ROM in which information is written in a manufacturing process. The nonvolatile memory 20 stores in advance a system program serving as a platform in the information processing apparatus 1. The system program is read from the nonvolatile memory 20 to the instruction execution unit 60 (for example, in units of bytes) when the information processing apparatus 1 is activated.

  The nonvolatile memory 10 is a memory that stores information in a nonvolatile and rewritable manner, and is, for example, a flash memory. When the instruction execution unit 60 accesses the nonvolatile memory 10 in byte units, the nonvolatile memory 10 can be a NOR flash memory, for example. The nonvolatile memory 10 includes a first nonvolatile memory area 11 and a second nonvolatile memory area 12.

  The first nonvolatile memory area 11 includes a program memory block 11a. The program memory block 11a stores the program 11a1 in a nonvolatile manner. The program 11a1 is verified by the program verification unit 50. The program 11a1 may be a functional module in an updated part of the system program, or may be the system program itself after the update.

  The second nonvolatile memory area 12 stores a verification state flag (first flag) 12a in a nonvolatile manner. The verification state flag 12a has a first value or a second value. The first value indicates that the program 11a1 has not been verified (hereinafter referred to as “unverified” or “x”). The second value indicates that the program 11a1 has been verified (hereinafter referred to as “verified” or “◯”). The verification state flag 12a may be made redundant, and may include, for example, a control bit indicating unverified / verified and a code bit for performing error correction of the control bit.

  The rewrite permission unit 30 permits or prohibits writing to the first nonvolatile memory area 11. The rewrite permission unit 30 includes a storage device 31. The storage device 31 stores the rewrite control flag (second flag) 31a in a volatile manner. The rewrite control flag 31a has a third value or a fourth value. The third value indicates that rewriting to the first nonvolatile memory area 11 is prohibited (hereinafter, represented by “prohibited” or “◯”). The fourth value indicates that rewriting to the first nonvolatile memory area 11 is permitted (hereinafter, expressed as “permitted” or “x”).

  The rewrite permission unit 30 can prohibit writing to the first nonvolatile memory area 11 by setting the value of the rewrite control flag 31 a to “prohibited”, and can set the first value by setting the value of the rewrite control flag 31 a to “permitted”. Writing to the non-volatile memory area 11 can be permitted.

  For example, when the rewrite permission unit 30 receives a rewrite permission request from the instruction execution unit 60 and the verification state flag 12a is “verified”, the value of the verification state flag 12a is changed from “verified” to “unverified”. To do. The rewrite permission unit 30 changes the rewrite control flag 31a from “prohibited” to “permitted” in response to the verification state flag 12a being changed to “unverified”. As a result, writing to the first nonvolatile memory area 11 from the instruction execution unit 60 is permitted.

  The program verification necessity determination unit 40 determines whether or not the program 11a1 needs to be verified according to the value of the verification state flag 12a when the information processing apparatus 1 is activated (for example, when a restart process is performed). The program verification necessity determination unit 40 determines that the verification of the program 11a1 is necessary when the verification state flag 12a is “unverified” when the information processing apparatus 1 is activated. The program verification necessity determination unit 40 determines that the verification of the program 11a1 is unnecessary when the verification state flag 12a is “verified” when the information processing apparatus 1 is started, and sends a normal activation permission notification to the command execution unit. 60.

  The program verification unit 50 can verify the program 11a1.

  For example, when receiving a verification request from the instruction execution unit 60, the program verification unit 50 controls the rewrite permission unit 30 to change the rewrite control flag 31a from “permitted” to “prohibited”. Alternatively, the program verification unit 50 controls the rewrite permission unit 30 to change the rewrite control flag 31a from “permitted” to “prohibited” when the program 11a1 needs to be verified.

  In accordance with this control, the rewrite permission unit 30 changes the rewrite control flag 31a from “permitted” to “prohibited”. As a result, writing to the first nonvolatile memory area 11 from the instruction execution unit 60 is prohibited. The program verification unit 50 verifies the program 11a1 according to this change. When the verification is successful, the program verification unit 50 changes the verification status flag 12 a from “unverified” to “verified”, and supplies a verification success notification to the instruction execution unit 60. If the verification fails, the program verification unit 50 supplies a verification failure notification to the instruction execution unit 60 without changing the verification status flag 12a as “unverified”.

  Or the program verification part 50 skips verification with respect to the program 11a1, when the verification of the program 11a1 is unnecessary. At this time, the verification state flag 12a is “verified”.

  The instruction execution unit 60 does not execute the program 11a1 that has failed verification, but executes the program 11a1 that has been verified successfully. The instruction execution unit 60 can comprehensively control each unit in accordance with the program 11a1. For example, when the instruction execution unit 60 receives an update command for the program 11a1 from the outside (higher-order controller or the like), the instruction execution unit 60 issues a rewrite permission request according to the update command according to the program 11a1 being executed and Supply. If the instruction execution unit 60 determines that the program 11a1 should be started according to an external command or according to an autonomous determination and does not receive a normal activation permission notification within a predetermined period of time, it is being executed. In accordance with the program 11a1, the verification request is issued and supplied to the program verification unit 50. Then, when receiving the verification success notification, the instruction execution unit 60 starts executing the updated program 11a1 read from the program memory block 11a. When the instruction execution unit 60 receives the verification failure notification from the program verification unit 50, the instruction execution unit 60 stops the execution of the program 11a1 (the updated program 11a1 is not executed even if it is read from the program memory block 11a). Alternatively, the instruction execution unit 60 determines that the program 11a1 should be started according to a command from the outside or according to an autonomous determination, and determines whether the program verification is necessary or not within a predetermined time. When received from the unit 40, execution of the updated program 11a1 read from the program memory block 11a is started without issuing a verification request.

  FIG. 2 is a diagram illustrating the functions of the rewrite control flag 31a and the verification status flag 12a. In the information processing apparatus 1, by operating the nonvolatile verification state flag 12a and the volatile rewrite control flag 31a, it is possible to determine whether or not the program 11a1 is in a safe state without performing verification. ing. In other words, the rewrite permission function by the rewrite permission unit 30 changes the rewrite control flag 31a from “◯” to “×” while the verification state flag 12a is “×”. Then, the rewrite control flag 31a is changed from “×” to “◯” with the verification state flag 12a being “×” by the verification function of the program verification unit 50. Thereby, when the verification state flag 12a is “◯”, it is ensured that the rewrite control flag 31a is “◯”. This can be ensured even when the information processing apparatus 1 is restarted because the verification state flag 12a is stored in the second nonvolatile memory area 12 in a nonvolatile manner.

  As a result, when the verification state flag 12a is “◯” and it can be predicted that the first nonvolatile memory area 11 has not been rewritten (that is, the program 11a1 has not been rewritten), Execution can be skipped. As a result, the execution frequency of the secure boot can be suppressed to a necessary minimum (when the verification status flag 12a is “x”), and the startup process of the program 11a1 can be speeded up. Therefore, unauthorized alteration of the program 11a1 can be reliably detected and prevented, and the average startup time of the program 11a1 can be shortened. In addition, since the execution frequency of the secure boot can be minimized, the average power consumption of the information processing apparatus 1 can be reduced.

  FIG. 3 is a block diagram illustrating a hardware configuration of the information processing apparatus 1. In FIG. 3, a microcontroller chip 101 is illustrated as the information processing apparatus 1.

  The microcontroller chip 101 includes a CPU core 102, SRAM 103, mask ROM 104, bus 105, nonvolatile memory 111, rewrite permission circuit 121, program verification circuit 141, program verification necessity determination circuit 161, and reset control circuit 106. The CPU core 102, SRAM 103, mask ROM 104, nonvolatile memory 111, rewrite permission circuit 121, program verification circuit 141, and program verification necessity determination circuit 161 are connected to each other via the bus 105.

  The CPU core 102 and the SRAM 103 correspond to the instruction execution unit 60 in the functional configuration (see FIG. 1). The mask ROM 104 corresponds to the non-rewritable nonvolatile memory 20. The nonvolatile memory 111 corresponds to the rewritable nonvolatile memory 10. The rewrite permission circuit 121 corresponds to the rewrite permission unit 30. The program verification circuit 141 corresponds to the program verification unit 50. The program verification necessity determination circuit 161 corresponds to the program verification necessity determination unit 40.

  The SRAM 103 includes a work area for the CPU core 102. For example, the CPU core 102 can read and execute a system program stored in the mask ROM 104 to the SRAM 103 in units of words.

  The nonvolatile memory 111 is divided into a plurality of logical blocks. The plurality of logical blocks include logical blocks 112 and 113. The logical block 112 corresponds to the first nonvolatile memory area 11. The logic block 112 includes a program memory block 11a. The program memory block 11a stores the program 11a1 in a nonvolatile manner. The logical block 113 corresponds to the second nonvolatile memory area 12. The logical block 113 stores the verification state flag 12a in a nonvolatile manner.

  The non-volatile memory 111 is connected to the bus 105, but the area that can be directly accessed from the CPU core 102 via the bus 105 is limited to the logical block 112 among the plurality of logical blocks. A program 11a1 may be stored. The verification status flag 12a is indirectly referenced / updated via the rewrite permission circuit 121, the program verification circuit 141, and the program verification necessity determination circuit 161, and the program cannot directly manipulate the value. The reset control circuit 106 is connected to the program verification necessity determination circuit 161.

  The rewrite permission circuit 121 includes a register 122, an unverified state setting function 123, a verification state reading function 124, a rewrite permission setting function 125, and a writing function 126. The register 122 corresponds to the storage device 31. In the state where the rewrite control flag 31a is “permitted”, the write function 126 rewrites information such as a program for the program memory block 11a according to control from the CPU core 102, and information stored in the program memory block 11a. Or delete. The program verification circuit 141 has a fingerprint value calculation function 142, a fingerprint expected value verification function 143, a fingerprint value verification function 144, and a rewrite prohibition setting function 145. The program verification necessity determination circuit 161 has a verification necessity determination function 162.

  There are two major threats assumed by secure boot that can be executed by the microcontroller chip 101. One is an external attack (physical attack) in which a general-purpose memory connected to the outside of the microcontroller chip 101 or a general-purpose memory is removed from the microcontroller chip 101 or accessed in parallel to illegally rewrite the system program. The other is an internal attack in which a malicious program that has entered from the outside during system execution illegally rewrites a system program by using a memory or storage rewriting function provided for regular program update. Side channel attacks such as fault injection are excluded here.

  In the microcontroller chip 101 having the on-chip memory (non-volatile memory 111), it is advantageous that the external attack may be basically excluded from consideration due to its configuration. In other words, when the microcontroller chip 101 is configured as a system-on-chip, the microcontroller chip 101 can be configured to have no external terminal that can directly access the nonvolatile memory 111. Although not shown, for initial program writing, the microcontroller chip 101 may have a write terminal for a nonvolatile memory such as a JTAG terminal in a stage before shipment from the factory. After writing the program, invalidate the JTAG terminal in the factory and ship it. After shipment, the program cannot be written through the JTAG terminal. The subsequent program update is performed by writing the program acquired via the network by the operation of the written initial program from the CPU core 102 to the nonvolatile memory 111.

  In the present embodiment, a configuration is disclosed in which the startup time can be shortened by adding or changing a small amount of hardware while ensuring the safety of secure boot by utilizing the advantage that an attack can be limited to an internal attack. The main requirements are as follows.

  (Request 1): Once the fingerprint verification of the system program (program 11a1) is performed, the verification status flag 12a of “verified” is held in the nonvolatile memory 111 inside the microcontroller chip 101 when the verification is successful. By doing so, except for the case of the next item, the next time activation can be performed at high speed without performing fingerprint verification.

(Request 2): Even if the power is cut off, the verification state is maintained and the effect of speeding up is maintained.
(Request 3): However, when the system program (program 11a1) is rewritten, the verification is performed at the time of restart, and when the verification is successful, the verification state flag 12a of “verified” is held. If there is no rewriting at the next activation, it can be activated at high speed without performing fingerprint verification.

  (Request 4): Rewriting detection of the system program (program 11a1) at the next start-up is not limited to rewriting by a regular procedure, and can be performed by executing arbitrary programs including malicious programs. . Regardless of whether or not rewriting has actually been performed, it is possible to detect a wide range of cases, including cases where rewriting may have been performed, such as cases where the power is interrupted during rewriting and the rewriting is interrupted. thing.

  (Requirement 5): The hardware scale for implementation is small. For example, saving all logs written to the program memory block 11a in the secure memory is not preferable because the cost of the secure memory for saving and the increase in power consumption are large.

  (Request 6): The writing of the update program to the nonvolatile memory 111 depends on the distribution method of the update program, and therefore must be performed by the system program side. The system program performs complex functions including network communication and management of received update fragment, so it has potential vulnerabilities, and malicious programs are temporarily executed by attacks from the network, and further to flash memory There is a risk that this or another malicious program may be written, but even in that case, it is possible to eliminate the malicious program by performing verification and restart.

  In order to satisfy the requirements 1 to 6, the microcontroller chip 101 indicates that the nonvolatile memory 111 has not been rewritable once after the verification by the hardware engine (program verification circuit 141) is completed. Hardware logic that secures the security across the network is implemented.

  FIG. 4 is a flowchart showing the operation of the information processing apparatus 1 (microcontroller chip 101) in response to the rewrite permission request.

  The rewrite permission circuit 121 sets “prohibited” as a default value in the rewrite control flag 31 a when the microcontroller chip 101 is activated. The system program (program 11a1) supplies the rewrite permission circuit 121 with the rewrite permission request issued by the CPU core 102 prior to writing to the program memory block 11a (S1). The rewrite permission circuit 121 acquires the right to write the verification status flag 12a on the nonvolatile memory 111 (S2), and writes a value of “unverified” in the verification status flag 12a (S3). The rewrite permission circuit 121 reads the verification state flag 12a from the nonvolatile memory 111 in order to confirm whether or not the value is properly written in the verification state flag 12a (S4). At this time, if the read information includes a code bit, error correction may be performed. When the read verification status flag 12a is “unverified” (“success” in S5), the rewrite permission circuit 121 writes “permitted” in the rewrite control flag 31a (S6), and the verification status flag 12a The write right is released (S7). For example, the value of “unverified” in the verification status flag 12a and the “permitted” value in the rewrite control flag 31a are defined to be the same value, so that the operation in S6 can be performed to rewrite the value of the read verification status flag 12a. It can be simplified as an operation for copying to the flag 31a. When the value of the verification status flag 12a is not properly read (ie, reading has failed) (eg, “failure” in S5), the rewrite permission circuit 121 sets the rewrite permission (S6). The right to write the verification status flag 12a is released (S7).

  With the operations so far, the processing corresponding to the rewrite permission request is completed (S8), and “permitted” is set in the rewrite control flag 31a, thereby enabling writing to the program memory block 11a. Since “permitted” is set in the rewrite control flag 31a only in the above procedure based on the rewrite permission request, when the rewrite control flag 31a is “permitted”, the verification state flag 12a becomes “unverified”. Is guaranteed. Even if the microcontroller chip 101 is restarted at this time, the verification process is performed at the next restart.

  Furthermore, in addition to the normal procedure described above, even if there is an interruption due to a power interruption or a failure to write to the verification status flag 12a at any point in this procedure, the rewrite permission state (the rewrite control flag 31a is “permitted” state) In such a case, the unverified state (the state where the verification state flag 12a is “unverified”) is secured. In the present embodiment, the history of writing to the program memory block 11a is not saved, but the verification status flag 12a is set to “unverified” as preprocessing when the rewrite control flag 31a is set to “permitted”. Thus, if the verification status flag 12a is in the “verified” state, it can be ensured that no writing to the program memory block 11a has been performed since the previous verification was completed.

  FIG. 5 is a sequence diagram showing the operation of the information processing apparatus 1 (microcontroller chip 101), and the processes corresponding to those in the flowchart of FIG. When the writing to the program memory block 11a is permitted, the CPU core 102 sequentially transmits the update program image from the external server 201 via the network 202 and the network interface 199 according to the system program (“Prog1” as the program 11a1). Obtain and write to the program memory block 11a. At this time, writing may be performed in any order. When an update program image (for example, “Prog2”) is acquired via the network 202, a packet order reversal or the like occurs. In this embodiment, a correct program image is written at the start of verification described below. As long as it is rare, the program memory block 11a may be written in any order before that. Even if the received update program is illegal, it can be detected by the verification process described later. Further, even if this update process is hijacked by a malicious program that is infected via the network 202, and the malicious program is written in the program memory block 11a, the presence of the malicious program is detected by the verification process and restarted next time. Sometimes, it is possible to prevent an unauthorized program on the program memory block 11a from being executed.

  The CPU core 102 rewrites “Prog1” to “Prog2” on the program memory block 11a. On the program memory block 11a, from the state where “Prog1” is present to the state where “Prog1” and “Prog2” are mixed (Prog1 / 2 ”),“ Prog2 ”is present. It reaches. When the rewriting from “Prog1” to “Prog2” is completed, the CPU core 102 issues a verification request for “Prog2” after the rewriting.

  FIG. 6 is a flowchart showing an operation of the information processing apparatus 1 in response to the verification request. The program verification circuit 141 receives a verification request from the CPU core 102 (S11), and verifies the contents of the program memory block 11a. Hereinafter, description of verification based on a public key signature will be described, but a MAC (Message Authentication Code) based on a common key is also applicable.

  It is assumed that a verification target program “Prog2” and a public key signature “Cert” for the verification target program are placed in the program memory block 11a. The signature “Cert” is obtained by signing the hash value of the verification target program with the public key private key “Ks” possessed by the program distribution source. The program verification circuit has a public key “Kp” corresponding to Ks.

  Receiving the verification request, the program verification circuit 141 acquires the right to write the verification status flag 12a (S12), and sets the rewrite control flag 31a to “prohibited” by the rewrite prohibition setting function 145 (S13).

  Next, the program verification circuit 141 calculates the fingerprint value of the verification target program “Prog2” using the fingerprint value calculation function 142, and acquires the fingerprint expected value using the fingerprint expected value verification function 143 (S14). That is, the fingerprint expected value verification function 143 performs the first verification process (for example, signature verification), and can acquire the fingerprint expected value when the first verification process is successful, and the first verification process fails. If it does, the expected fingerprint value cannot be acquired. When the first verification process is successful, the program verification circuit 141 performs a second verification process (for example, fingerprint verification). That is, the program verification circuit 141 compares the fingerprint value with the fingerprint expected value (verification expected value) by the fingerprint value verification function 144. Here, the hash value of the program corresponds to the fingerprint value, and the hash value extracted from the public key signature corresponds to the expected fingerprint value. Note that if the first verification process fails, the program verification circuit 141 does not perform the second verification process.

  If the fingerprint value does not match the expected fingerprint value (“failed” in S15), the verification fails, and the program verification circuit 141 releases the write right of the verification status flag 12a (S17), and performs verification. Complete (S18).

  If the fingerprint value matches the fingerprint expected value (“success” in S15), the verification is successful, and the fingerprint value matching function 144 sets “verified” in the verification status flag 12a (S16). . The program verification circuit 141 releases the right to write the verification status flag 12a (S17) and completes the verification (S18).

  FIG. 7 is a flowchart showing the operation of the information processing apparatus 1 when the restart process is performed in a state where “verified” is set in the verification status flag 12a.

  After the restart process (S21) of the microcontroller chip 101 is performed, the program verification necessity determination circuit 161 receives the activation signal from the reset control circuit 106, and uses the activation signal as a trigger to set the verification state flag 12a to nonvolatile. Read from the memory 111 (S22). Since the verification status flag 12a is “verified” (“verified” in S23), the program verification necessity determination circuit 161 determines that the execution of verification is unnecessary and notifies the CPU core 102 of the normal activation permission. (S26). In response to this, the CPU core 102 executes the stored program 11a1 from a predetermined address. FIG. 8 is a sequence diagram illustrating the operation of the information processing apparatus 1, and processes corresponding to those in the flowchart of FIG.

  In the method of the present embodiment, the combination of the operation of the rewrite control flag 31a and the verification status flag 12a in the rewrite permission and the verification process allows the verification to be performed after the restart process even if the verification is interrupted due to a power failure or the like. It can be made to be.

  The operation at that time will be described with reference to FIGS. FIG. 9 is a sequence diagram illustrating the operation of the information processing apparatus 1. The sequence until the verification execution is the same as the sequence of FIG. The restart process (S21) occurs when the verification calculation is not completed or a value indicating the verification status based on the verification calculation is not written in the verification status flag 12a.

  In the restart process, the verification status flag 12a is “unverified”. The program verification necessity determination circuit 161 determines that the verification is necessary in response to the verification status flag 12a being “unverified” (“not verified” in S23), and executes the verification to the program verification circuit 141. Request. The program verification circuit 141 changes the rewrite control flag 31a to “prohibited” and performs verification (S24). In this case, since the correct update program is written in the program memory block 11a, the program verification circuit 141 succeeds in verification (“success” in S25), and “verified” is set in the verification status flag 12a. Successful verification is notified to the program verification necessity determination circuit 161. With this, the program verification necessity determination circuit 161 notifies the CPU core 102 of the normal activation permission (S26), and the updated program 11a1 is executed (S27).

  Thus, even when the verification operation is interrupted, verification can be performed after the restart process. However, since the verification is performed after the restart process, the startup time of the program 11a1 becomes long.

  Next, an operation when fraud is detected will be described. FIG. 10 is a sequence diagram when a malicious program that has entered the SRAM 103 and executed by, for example, using a vulnerability of the system program attempts to write the malicious program into the program memory block 11a. FIG. 10 shows an example in which when a malicious program voluntarily issues a verification process, verification is performed again during the restart process and the malicious program does not start.

  The unauthorized program on the SRAM 103 issues a rewrite permission request in the same way as regular program writing, writes to the program memory block 11a, and issues a verification request. The difference is that what is written is a malicious program. Also in this case, the verification process (S14) is executed, the verification fails (“failure” in S15), and the verification status flag 12a remains “unverified” even if the verification is completed.

  The malicious program continues to operate until the restart process (S21). However, after the restart process, the verification status flag 12a is “unverified” (“unverified” in S23), so the verification process (S24) is executed. Since the verification result is failure (“failure” in S25), a stop instruction is issued to the CPU core 102 and notified to the CPU core 102 (S28). Therefore, the malicious program is not executed (S27). The malicious program on the SRAM 103 disappears when the power is turned off.

  Note that the malicious program executed on the SRAM 103 and the malicious program written in the program memory block 11a do not have to be the same program.

  FIG. 11 shows a sequence when a verification request is not issued after an illegal program is written in the program memory block 11a. Since the verification request is not issued, the verification status flag 12a remains “unverified”, and since the verification at the restart fails as in the case of FIG. 5, the malicious program is not executed.

  FIG. 12 shows a sequence when a process interruption and a restart process occur due to a power interruption or the like in the middle of the process according to the rewrite permission request.

  After the issuance of a rewrite permission request by the CPU core 102, the verification status flag 12a is rewritten to “unverified”, but the process is interrupted due to a power interruption and restarted before the result is reflected in the rewrite control flag 31a. Yes. Until the power is turned off, the rewrite control flag 31a is kept in the “prohibited” state, and therefore any writing to the program memory book 11a including the DMAC 107 other than the CPU core 102 is not performed.

  After the restart process (S21), since the verification status flag 12a is set to “unverified”, verification (S24) is performed again. However, since the program memory block 11a has not been rewritten, the verification succeeds ( “Success” in S25), normal activation permission is notified to the CPU core 102 (S26), and the program 11a1 is executed.

  Here, let us consider a case where the order of the two state flag operations is changed in the rewrite permission operation. In this case, when a rewrite permission request is issued by the CPU core 102, the verification state flag 12a is set to “unverified” after the rewrite control flag 31a is set to “permitted”.

  At this time, writing to the program memory block 11a becomes possible immediately after the rewrite control flag 31a is set to “permitted”. If a restart occurs before the completion of writing “unverified” to the nonvolatile verification status flag 12a, the verification status flag 12a is set to “verified” even though the program memory block 11a has been rewritten. Therefore, the verification after the restart process is skipped. If a malicious program is written by this writing, the malicious program is successfully executed.

  On the other hand, in the example of FIG. 12, since the power interruption has occurred after the change of the verification state flag 12a, the verification is performed after the restart process. If the power interruption occurs before the verification status flag 12a is changed, the verification status flag 12a remains “verified”, so that the verification is not performed after the restart process. At this time, since the setting of the rewrite control flag 31a is performed after the verification state flag 12a, it is ensured that writing to the program memory block 11a is not performed even in this case, and verification is not performed after the restart process. Is also safe because the possibility of rewriting the verified program 11a1 can be eliminated.

  That is, in this embodiment, verification state management including asynchronous power-off is safely performed by the verification state flag 12a indicating the verification state and the rewrite control flag 31a that controls writing to the nonvolatile memory being executed. Can do. Further, in the present embodiment, the increase in the number of circuits with respect to the existing microcontroller chip is slight, and this embodiment is suitable for devices that require both security and low cost, such as field devices and sensor devices arranged outdoors.

  In the present embodiment, it is assumed that the system program issues a write permission request and a verification request individually. This is because the memory configuration of the embedded microcontroller and the rewrite procedure are assumed. In addition to this procedure, a configuration in which a write permission request, a write, and a verification request are integrally processed by hardware is logically conceivable, but is not suitable for an embedded microcontroller. In the case of this procedure, it is necessary that all of the verification target programs 11a1 are stored in another buffer memory before the write destination program memory can be written. The most common buffer memory is SRAM, but SRAM has a higher bit unit price than flash memory, and therefore generally has a smaller capacity than flash memory. Therefore, it becomes necessary to divide and write the flash memory into a plurality of times. This complicates the verification function on the hardware side.

  For example, even when an update program is distributed and distributed, it is not always received in the order according to the arrangement on the memory. A method of dividing a program and delivering it by peer-to-peer is known, but in such a case, the reception order of the divided fragments is usually scattered.

  In this embodiment, the system program issues a write permission request and a verification request individually, so that the system program writes the update program in the program memory block 11a in an arbitrary order, and the system is in a stage where all the update programs are ready. By adopting a procedure in which the program issues a verification request, it is possible to increase the degree of freedom in distributing update programs and at the same time simplify the verification function hardware.

  As described above, in the embodiment, when a rewrite permission request is issued and the verification status flag 12a is “verified” in the information processing apparatus 1, the information processing device 1 is changed to “unverified” and the verification status flag 12a is changed. Accordingly, the rewrite control flag 31a is changed from “prohibited” to “permitted”. When a verification request is issued, or when the verification status flag 12a is “unverified” and the program 11a1 needs to be verified, the rewrite control flag 31a is changed to “prohibited” and the rewrite control flag 31a is changed. In response to this, the program 11a1 is verified. The verification status flag 12a is set to “verified” if the verification is successful, and is maintained as “unverified” if the verification fails. As a result, when the verification status flag 12a is “verified” and it can be predicted that the first nonvolatile memory area 11 has not been rewritten, execution of secure boot can be skipped. As a result, the execution frequency of the secure boot can be suppressed to a necessary minimum (when the verification status flag 12a is “unverified”). Therefore, unauthorized alteration of the program 11a1 can be reliably detected and prevented, and the average startup time of the program 11a1 can be shortened. Moreover, the average power consumption of the information processing apparatus 1 can be reduced.

  In the above embodiment, it is difficult to directly estimate the success / failure of the verification from the verification status flag 12a and the rewrite control flag 31a. For this reason, a non-volatile verification success / failure flag may be additionally provided so that the verification success or failure can be grasped by referring to the verification success / failure flag.

  In the above embodiment, the rewrite prohibition is controlled by the rewrite control flag 31a. In the case of realization by a logic circuit, in a state where rewriting is prohibited, rewriting is prohibited by providing a circuit that does not validate the write control signal for the memory. In addition to this, when a high voltage different from that of the logic circuit is required for erasing and writing as in the case of a flash memory, it is possible to more strictly guarantee rewriting prohibition by stopping supply of these power supply voltages.

  Further, as described above, the verification status flag 12a and the rewrite control flag 31a operate safely against interruption such as power interruption, but this is not limited to bit inversion due to noise. These flags may be made redundant using error correction or majority logic.

  In the above embodiment, it is assumed that the verification is stopped when the verification fails. Alternatively, the unverified program 11a1 can be executed under the condition that prohibits access to the encryption key and important input / output. The purpose can be expected to record and notify the cause when a verification failure occurs due to a memory failure other than an illegal program.

  Further, in order to prevent rewrite conflict of the verification status flag 12a between the rewrite permission circuit 121 and the program verification circuit 141, for example, the CPU core 102 can perform appropriate write right acquisition management.

  FIG. 13 is a block diagram illustrating a hardware configuration of the information processing apparatus 1 (microcontroller chip 101) as a first modification of the embodiment. As shown in FIG. 13, the expected fingerprint value acquired by the program verification circuit 141 may be stored in the logic block (third nonvolatile memory area) 114 in a nonvolatile manner.

  A difference in configuration from the above embodiment is that a fingerprint expected value memory 114 a is provided in the logical block 114. At the time of verification of the first program 11a1, or in a fingerprint expected value setting procedure provided separately, the verified expected value is written in the fingerprint expected value memory 114a.

  For example, as shown in FIG. 14, in the process in response to the rewrite permission request, when “unverified” is set in the verification status flag 12a, the fingerprint expected value memory 114a is cleared (S43) and verified for confirmation. When the value of the status flag 12a is read, it is confirmed whether the expected fingerprint value is properly cleared (S44). Further, as shown in FIG. 15, in the process in response to the verification request, after “inhibited” is set in the rewrite control flag 31a (S13), the program verification circuit 141 refers to the fingerprint expected value memory 114a. If the expected fingerprint value has been cleared (“cleared state” in S54a), the fingerprint value is calculated and the expected fingerprint value is obtained, and then both are compared (S54c). If the fingerprint expected value is stored in the fingerprint expected value memory 114a ("set" in S54a), the program verification circuit 141 skips the acquisition of the fingerprint expected value, and after calculating the fingerprint value Both are collated (S54b). Therefore, when the fingerprint expected value has been set, the time required for the verification process of the program 11a1 can be shortened.

  In the above-described embodiment, the expected fingerprint value is given in the form of a signature or MAC created based on the secret key to prevent forgery by a third party. Since a third party can forge a hash value that is not based on a secret key, it cannot be applied to the above embodiment.

  In the first modification, since the fingerprint expected value is held in the nonvolatile memory 111 protected from access by a general program, the fingerprint expected value can be a hash value. In that case, the fingerprint expected value verification function 143 receives a hash value via a program executed in the CPU core 102 or a communication path authenticated in communication with the outside of the apparatus, and stores it in the fingerprint expected value memory 114a. Can be written. For example, in the secure boot based on the specification of TCG (Trusted Computing Group), since the comparison with the hash value stored in the secure storage is performed, the use of the first modification is suitable.

  In addition, the above-described embodiment is particularly suitable for a wireless sensor, a wireless card, or the like in that a verification process that increases response deterioration and power consumption at startup can be omitted in secure boot. Wireless sensors often operate intermittently, but performing a secure boot that consumes a large amount of power each time increases the frequency of battery replacement in battery-powered terminals. In a wirelessly powered wireless card or the like, the startup time is further increased due to the inability to supply large power.

  Although these terminals are required to be low in cost at the same time, in the embodiment and the first modification, a configuration based on hardware is shown. When implemented in hardware, an increase in chip area directly leads to an increase in cost. In particular, since the secure boot function is used less frequently than sensor signal processing or the like, realizing this with software of a general-purpose CPU is directly linked to the reduction of the chip area and is an advantage. These functions can be realized in the same way by software except that the processing basically takes time for the software. However, if it is assumed that a malicious program enters the terminal, the rewrite permission function, the program verification function, and the program verification necessity determination function at the time of activation are functions that should not be interfered with by a malicious program.

  In the following, as a second modification of the embodiment, the verification function and the verification necessity determination function at the time of activation are assumed to be software processing, and even when a malicious program has entered the terminal, the influence is eliminated and the functions are executed safely The procedure to do is explained.

  In the second modification, the program verification function and the program verification necessity determination function realized by hardware in the embodiment are replaced with a program verification module 141a that is a functional module on the mask ROM 104 that cannot be rewritten, and a verification necessity determination module. Substitute with 161a. FIG. 16 is a block diagram illustrating a hardware configuration of the information processing apparatus 1 according to the second modification. The program verification module 141a and the verification necessity determination module 161a are stored in the mask ROM 104 in advance. At this time, the flag is directly manipulated by issuing an instruction on the CPU core 102. For this purpose, a flag operation circuit 181 having a flag operation function is provided. In order to prevent the use of the flag operation function by an illegal program, the function module on the mask ROM 104 performs flag access after the execution of the function module on the mask ROM 104 from the restart processing of the CPU core 102 during the period in which the flag operation can be performed by issuing an instruction Limited to the period until is invalidated. For this purpose, a flag access setting circuit 191 responsible for the flag access validation / invalidation function is provided. The program on the mask ROM 104 can be executed without verification, but since this cannot be modified by hardware, the verification may be omitted.

  The flag operation circuit 181 includes a flag access control function 182, a verification state flag operation function 183, a verification state flag operation function 184, and a rewrite control flag operation function 185. The flag access setting circuit 191 has a flag access validation function 192 and a flag access invalidation function 193.

  These functions only control the interface and permission for the rewrite control flag 31a, the verification status flag 12a, and the flag access function, and can be realized with a very small circuit compared to hardware that executes verification calculation. It is.

  Cryptographic operations such as hash values and signatures by a general-purpose CPU generally take a long time compared to dedicated hardware, and power consumption efficiency is poor. However, in the second modified example, the secure boot verification process does not occur unless the program memory block 11a is rewritten, so that there is almost no influence on the power efficiency in normal operation.

  FIG. 17 is a flowchart illustrating the operation of the information processing apparatus 1 according to the restart process in the second modification. After the restart process (S21), the flag access setting circuit 191 validates the flag access, that is, the flag verification function by the flag manipulation circuit 181 is valid (S61), and the program verification module 141a and program verification on the mask ROM 104 The necessity determination module 161a is executed (S62). The function module reads the verification status flag 12a through the flag operation circuit 181 (S22), and if it is “verified” (“verified” in S23), invalidates the flag access (S65) and loads the verified program 11a1. Execute (S66). If it is “unverified” (“not verified” in S23), the program memory block 11a is verified by software (S64). If the verification is successful (“success” in S25), the flag access is also invalidated. (S65), the verified program 11a1 is executed (S66). If the verification fails (“failure” in S25), the flag access is invalidated (S67), and the activation of the program 11a1 is stopped (S68).

  In addition, a technique called functional safety is known in which the possibility that a certain risk causes damage to human life or assets is reduced by the action of a machine or device. Software is widely used to implement functions that reduce risk when complex system components fail. In functional safety, it is extremely important for software to be correct. Secure boot can also be a means to protect the correctness of the software that is the basis of functional safety from malicious attacks. When secure boot is positioned in this way, if a malfunction occurs due to a failure of the secure boot mechanism, particularly when the necessity of secure boot malfunctions, the execution of a falsified program is allowed. Therefore, it is desirable to eliminate the secure boot skip mechanism in advance by a failure detection method generally used for functional safety.

  For example, in the present embodiment, the above-mentioned malfunction occurs in which the rewrite is enabled even though the verification status flag has not been verified. Therefore, the rewrite control flag is prohibited from being written to the program memory block. It is mentioned that the security is ensured by a BIST (Built In Self Test) function for confirming that it is correctly reflected in the system. It is known that, among the nonvolatile memories storing the verification state flag, the flash memory is deteriorated when writing is repeated and writing / reading becomes unstable. In this embodiment, the value once written in the verification status flag is read and the correctness is verified or copied to the rewrite control flag. For this reason, even if writing fails due to deterioration of the flash memory, the value of the rewrite control flag does not become a write-permitted state, so the mechanism of this embodiment itself may provide a part of the functions necessary for functional safety. it can.

  In the above embodiment, an example in which the verification target is a single program has been described. However, a plurality of programs can be set as verification targets by including a rewrite control flag and a verification status flag.

  Although several embodiments of the present invention have been described, these embodiments are presented by way of example and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the scope of the invention. These embodiments and modifications thereof are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalents thereof.

  DESCRIPTION OF SYMBOLS 1 Information processing apparatus, 10 Non-volatile memory, 20 Non-volatile memory, 30 Rewriting permission part, 40 Program verification necessity determination part, 50 Program verification part, 60 Instruction execution part

Claims (9)

An information processing apparatus,
Non-volatile memory;
A first value indicating that the program stored in the first memory area of the nonvolatile memory is unverified and a second value indicating that the program has been verified can be set to a first value . With the flag
Depending on the rewriting permission request of a program executed in the information processing apparatus, a switching circuit for setting the first value to the first flag,
The second value is set in the first flag in response to verification of the program stored in the first memory area, and the first value is set in the first flag in response to restart of the information processing apparatus . A verification circuit that performs a verification process on the program when the flag is set to 1, and executes the program without performing the verification process when the second value is set in the first flag; ,
The second value can be set to a third value indicating that rewriting to the first memory area is prohibited and a fourth value indicating that rewriting to the first memory area is permitted. Flags and
Equipped with a,
In response to the change of the second flag from the third value to the fourth value, the first value is set in the first flag;
The information processing apparatus , wherein the third value is set in the second flag prior to the execution of the verification process . The information processing apparatus according to claim 1, wherein the first flag is stored in a second memory area in the nonvolatile memory. The information processing apparatus according to claim 1 , wherein the second flag is stored in a volatile memory. Prior to the verification process for setting the third value in the second flag, the first memory area is write-protected,
The information processing apparatus according to claim 1, wherein when the fourth value is set in the second flag, writing to the first memory area is permitted. When the verification process is successful, the program can be executed,
The information processing apparatus according to claim 1, wherein the program cannot be executed when the verification process fails. In the verification process, the verification circuit calculates a hash value of the program stored in the first memory area, extracts a hash value from the public key signature of the program, and calculates the calculated hash value and the The information processing apparatus according to claim 1, wherein the information processing apparatus compares the extracted hash value. The information processing apparatus according to claim 1, wherein a hash value extracted from a public key signature of the program stored in the first memory area is stored in a third memory area in the nonvolatile memory. A processing unit provided separately from the verification circuit;
The information processing apparatus according to claim 1, wherein the verification circuit executes the verification process in response to a verification request from the processing unit. A second non-volatile memory that is non-rewritable and stores a verification program;
The information processing apparatus according to claim 1, wherein the verification circuit executes the verification process according to the verification program.

Images