JP2021164009A - Device, secure element and secure boot method for device - Google Patents

Abstract

To provide a device, secure element, and secure boot method for the device that enable a secure boot with enhanced security.SOLUTION: A device having a secure boot function comprises: a secure element that retains boot loader information including a boot loader, a boot loader verification key, and a signature of the boot loader; and a non-rewritable non-volatile memory that statically carries an initial execution code such as a boot loader information readout process, a boot loader verification process, and a boot loader execution process including a sequence of execution. At the startup of the device, the boot loader information readout process is executed to read out the boot loader information from the secure element, the boot loader verification process verifies the boot loader using the boot loader verification key and the signature of the boot loader, and the boot loader execution process executes the boot loader in response to the successful verification.SELECTED DRAWING: Figure 3

Description

The present invention relates to devices, secure elements and secure boot methods for devices.

As a technology for ensuring security in IoT devices, a technology called secure boot has begun to spread. Secure boot is a technique for preventing unauthorized software from booting a device by allowing only software with a digital signature to be executed in advance when the device such as a PC is booted.

Patent Document 1 discloses an example of a secure boot technique using a boot loader. In secure boot technology, at power up, the boot loader is the Root of Trust in secure boot. In such a secure boot, for example, the bootloader validates the Root of Trust code and, if successful, executes the Root of Trust code. The Root of Trust code verifies the execution image of the OS, and if the verification is successful, the OS is executed, and the boot is completed when the OS startup process is completed.

Japanese Unexamined Patent Publication No. 2015-201091

However, the following problems remain in the conventional secure boot technology. When verifying the validity of the executable code by performing verification or decryption with the key, there is a strong relationship between the key held in different media and the executable code, and when updating, it is necessary to update both. It becomes. Further, the IoT device generally operates continuously for a long period of time without any person, and tamper resistance is required to hold the key. In addition, when software verification is performed based on a public key, it is possible to tamper with both the key and the software to make it appear that valid verification has been performed. Furthermore, it is difficult to update the boot loader based on the reliable Root of Trust, and there is room for unauthorized rewriting at the timing of the update.

The present invention has been made in view of such circumstances, and an object of the present invention is to provide a device, a secure element, and a secure boot method for a device capable of realizing a more secure secure boot.

The device according to the embodiment of the present invention is a device having a secure boot function, which is a secure element that holds boot loader information including a boot loader, a boot loader verification key, and a boot loader signature, and reads boot loader information as an initial execution code. It is provided with a non-rewritable non-volatile memory that holds the process, boot loader verification process, and boot loader execution process including the execution order. When the device is started, the boot loader information read process is executed, and the boot loader information is transmitted from the secure element. Is read, the boot loader verification process verifies the boot loader using the boot loader verification key and the boot loader signature, and if the verification is successful, the boot loader execution process executes the boot loader.

The secure element according to the embodiment of the present invention is a secure element implemented in a device having a secure boot function, and holds boot loader information including a boot loader, a boot loader verification key, and a boot loader signature. The boot loader information is output to the device for verification of the boot loader.

In the secure boot method of the device according to the embodiment of the present invention, the boot loader information reading process, the boot loader verification process, and the boot loader execution process are held in a non-rewritable non-volatile memory including the execution order as the initial execution code. When the device is started, the boot loader information read process is executed to read the boot loader information including the boot loader, the boot loader verification key, and the boot loader signature from the secure element, and the boot loader verification process is performed on the boot loader verification key and the boot loader verification key. The boot loader is verified using the boot loader signature, and if the verification is successful, the boot loader execution process executes the boot loader.

According to the present invention, a more secure secure boot can be realized.

It is a schematic diagram which shows the trust chain of the key, the certificate and the signature of this embodiment. It is a schematic diagram which shows an example of the structure of an IoT device. It is explanatory drawing which shows an example of a basic boot process. It is explanatory drawing which shows an example of the verification of the execution image by a boot loader. It is explanatory drawing which shows an example of the authentication before reading the boot loader. It is explanatory drawing which shows an example of the remote management of boot loader information. It is explanatory drawing which shows an example of the update of boot loader information.

Hereinafter, the present invention will be described with reference to the drawings showing the embodiments thereof. FIG. 1 is a schematic diagram showing a trust chain of a key, a certificate, and a signature according to the present embodiment. In the present embodiment, the IoT device manufacturer, the secure element manufacturer, and the software manufacturer executed after the boot loader hold the necessary data, and each manufacturer appropriately manages the target key pair. As a result, multiple software implementers work together to achieve a secure boot. The IoT device is, for example, a device (also referred to as an electronic device) capable of independently operating by mounting an OS, and is a device corresponding to "things" in the "Internet of Things" (IoT).

In this embodiment, for ease of explanation, an IoT device OS (for example, RTOS: Real Time Operating System, Linux (registered trademark), etc.) is assumed as software executed after the boot loader. The present invention is not limited to these, and includes all software images executed after the boot loader, including software contents such as a Docker image.

Data is roughly classified into three categories: executable software, keys, and signatures (certificates). First, the executable software will be described.

Executable software includes, for example, a boot loader 11 and an IoT device OS 12. The boot loader 11 is software that executes a boot process on the IoT device, and is a code for booting the OS from a specific process (boot loader execution function) of the IoT device.

The IoT device OS 12 is an OS that actually operates on the IoT device, and corresponds to an execution image of an RTOS or a Rich OS (Linux, etc.). The boot loader 11 and the IoT device OS 12 may be implemented by the IoT device manufacturer and the IoT device OS vendor, respectively, or both the boot loader 11 and the IoT device OS 12 may be implemented by either main body. The boot loader 11 needs to be provided to the secure element manufacturer.

Next, the key will be described. The keys include, for example, the secure element CA public key 21, the secure element CA private key 22, the boot loader verification key (public key) 23, the boot loader signature generation key (private key) 24, the OS verification key (public key) 25, and the OS. A signature generation key (private key) 26 is included.

The secure element CA public key 21 is a public key for the secure element manufacturer to prove the validity (signature verification) of each secure element key. The secure element CA private key 22 is a key for the secure element manufacturer to give a signature to each key of the secure element.

The boot loader verification key (public key) 23 is a key for verifying the signature of the boot loader generated by the secure element manufacturer. The boot loader signature generation key (private key) 24 is a key for the secure element manufacturer to generate a signature for the boot loader.

The OS verification key (public key) 25 is a key for verifying the signature of the IoT device OS generated by the IoT device OS vendor. The OS signature generation key (private key) 26 is a key for the IoT device OS vendor to generate a signature for the IoT device OS. The OS verification key (public key) 25 needs to be provided to the secure element manufacturer.

Next, the signature will be described. Signature is a technique that allows the recipient to know that the transmitted content has been tampered with when it has been tampered with. Generally, the sender hashes the data to generate a digest, and encrypts the generated digest with a private key to generate a signature. The sender sends the signature along with the data. The recipient receives the data and the signature and hashes the data to generate a digest. The recipient decrypts the signature with the public key to get the digest. The two digests are compared and a match / mismatch is determined. If they match, you can be sure that the data has not been tampered with.

The signature includes, for example, a boot loader digital signature 31, a boot loader verification key certificate 32, an OS digital signature 33, and an OS verification key certificate 34.

The boot loader digital signature 31 is a signature generated by the boot loader signature generation key (private key) 24 for the boot loader 11. For example, the hash value of the boot loader 11 (binary string) can be encrypted with the boot loader signature generation key (private key) 24 as the signature. The boot loader verification key certificate 32 is a signature generated by the secure element CA private key 22 for the boot loader verification key (public key) 23. For example, the hash value of the boot loader verification key (public key) 23 can be encrypted with the secure element CA private key 22 as a signature.

The OS digital signature 33 is a signature generated by the OS signature generation key (private key) 26 for the image of the IoT device OS. For example, the hash value of the IoT device OS (binary string) can be encrypted with the OS signature generation key (private key) 26 as the signature. The OS verification key certificate 34 is a signature generated by the secure element CA private key 22 for the OS verification key (public key) 25. For example, the hash value of the OS verification key (public key) 25 can be encrypted with the secure element CA private key 22 as a signature.

In the present embodiment, the signature is generated by encrypting the hash value of the signature target with the signature generation key, but the signature generation algorithm is not limited to this, and the target key encryption is used. Any method may be used as long as it is a signature generation and verification method that relies on.

Signature verification is performed by decrypting the signature with the verification key and comparing it with the signature target. The verification key must be the key opposite to the signature generation key, and signature generation is impossible without the opposite private key. Therefore, if the verification of the signature target is successful, it is proved that the signature target has been signed by the entity having the private key and has not been tampered with since the time of signature.

In this embodiment, (1) verification of the boot loader digital signature 31 by the boot loader verification key (public key) 23 (proof that the boot loader 11 has not been tampered with), and (2) boot loader verification key by the secure element CA public key 21. Two signature verifications are performed: verification of the (public key) 23 (proof that the boot loader verification key (public key) 23 has not been tampered with). As a result, the boot loader 11 is signed by the secure element manufacturer and has not been tampered with, and the verification process itself has not been tampered with (verification is performed with a valid verification key) by the Trust Chain. The legitimacy can be ensured and secure boot can be realized.

When verifying the OS, (1) verification of the OS digital signature 33 by the OS verification key (public key) 25 (proof that the OS has not been tampered with), (2) secure element CA public key 21 The validity is ensured by the Trust Chain of verification of the OS verification key (public key) 25 by (proof that the OS verification key (public key) 25 has not been tampered with). As a result, it can be ensured that the OS is signed by the OS manufacturer (vendor) and has not been tampered with, and that the key used for the verification has been verified by the secure element manufacturer.

FIG. 2 is a schematic view showing an example of the configuration of the IoT device 100. The IoT device 100 is a device for which secure boot is implemented, and includes, for example, an embedded board on which an RTOS, Linux, or the like operates. The IoT device 100 has a SoC (System on Chip) 50 and a secure element 60 inside. The IoT device 100 may include a user authentication input device. The user authentication input device is a device for receiving input of authentication information from a user when user authentication is required at the time of starting the IoT device 100, and includes, for example, a PIN pad, a fingerprint sensor, and the like.

The SoC50 is an IC chip that holds the main functions of the IoT device 100. The SoC50 has a ROM 51, an NVM 52, a RAM (REE) 53, and a RAM (TEE) 54 as non-rewritable non-volatile memory. In this specification, ROM is given as an example of a non-rewritable non-volatile memory. Specifically, the non-rewritable non-volatile memory includes a mask ROM and a programmable ROM. Programmable ROM includes OTP (One Time Programmable) -ROM, EEPROM (Electronically Erasable and Programmable Read Only Memory), non-rewritable protected flash memory, and the like. Any of these may be used as the ROM 51. The secure element 60 is a security chip having tamper resistance, has a CPU and NVM (Non-volatile memory) inside, and has a secure non-volatile memory. The secure element 60 communicates with the SoC50 on a standard communication path (for example, ISO7816 / SPI / I2C, etc.).

The boot management server 200 has a function as an external server, holds information related to secure boot of the IoT device 100, acquires the boot state of the IoT device 100, and performs individual management.

The pre-boot user authentication function 41, the boot loader information read function 42, the boot loader verification function 43, the boot loader execution function 44, and the secure element CA public key 21 are held in the ROM 51.

The pre-launch user authentication function 41 receives user authentication information from the user authentication input device, opens a communication path with the secure element 60, and performs a process of requesting user authentication from the secure element 60.

The boot loader information reading function 42 opens a communication path with the secure element 60 and performs a process of acquiring information (boot loader information) necessary for booting from the secure element 60.

The boot loader verification function 43 uses the boot loader digital signature 31 to perform a process of verifying the validity of the decrypted boot loader 11.

The boot loader execution function 44 passes control to the decrypted boot loader 11 and performs a process for executing the boot loader 11. The processing and data of the pre-boot user authentication function 41, the boot loader information reading function 42, the boot loader verification function 43, and the boot loader execution function 44 are fixedly held (stored) in the ROM 51 by the IoT device manufacturer. After shipment from the factory, these processing procedures and processing contents, including the processing execution order, cannot be rewritten (maintained in a secure state).

The information in the NVM (Non-volatile memory) 52 is rewritable and can be rewritten by the user after shipment from the factory. In addition, instead of NVM (Non-volatile memory) 52, or together with NVM 52, a recording medium such as an SD card or eMMC (embedded Multi Media Card) that can be stored outside the SoC50 may be used.

The RAM of the SoC50 is divided into a normal memory area (REE: Rich Execution Environment) 53 that is not secure and a secure area (TEE: Trusted Execution Environment) 54. In the present embodiment, the boot loader information of the secure element 60 is read into the RAM (TEE) 54, but in the case of the SoC which does not have the RAM (TEE) 54 and has only the RAM (REE) 53. , The boot loader information of the secure element 60 may be read into the RAM (REE) 53.

The secure element 60 holds SIDE, user authentication information (PIN, etc.) in addition to boot loader information. The SEI D is an ID that uniquely identifies the secure element 60. It can be used as a value for specifying the secure element 60 from the boot management server 200. The user authentication information is information that the secure element 60 holds in the secure element 60 in order to perform user authentication of the IoT device 100, and holds biometric authentication information such as a user PIN and fingerprint authentication, for example.

For each SEID, the boot management server 200 has a boot loader management table that holds the version of the boot loader held in the secure element 60 of the SEI ID, the latest version of the boot loader at the present time, and the like.

Next, the secure boot of the present embodiment will be described. The following describes the basic boot process, verification of the execution image by the boot loader, authentication before reading the boot loader, remote management of the boot loader information, and update of the boot loader information.

FIG. 3 is an explanatory diagram showing an example of a basic boot process. Hereinafter, the processes represented by the reference numerals P1 to P9 will be described.

P1 (Power on): The user of the IoT device 100 turns on the power of the IoT device 100. Depending on the IoT device, in addition to turning on the power, an operation such as restarting may be performed.

P2 (Execution of boot loader information reading function): When the power of the IoT device 100 is turned on, the execution of the boot loader information reading function 42, which is the initial execution code, is started.

P3 (boot loader information acquisition instruction): The boot loader information reading function 42 activates the communication function with the secure element 60 and sends an information acquisition command to the secure element 60.

P4 (boot loader information acquisition): As a response, the secure element 60 includes a boot loader 11, a boot loader verification key (public key) 23, a boot loader digital signature 31, a boot loader verification key certificate 32, an OS verification key (public key) 25, and an OS. The verification key certificate 34 (collectively referred to as boot loader information) is returned. The boot loader information read function 42 arranges the boot loader information in a designated area (here, RAM (TEE) 54) on the RAM in the SoC 50.

P5 (Execution of boot loader verification function): At the end of the boot loader information read function 42, control is transferred to the boot loader verification function 43, and the boot loader information read function 42 is executed.

P6 (validity verification of boot loader verification key): The boot loader verification function 43 verifies the validity of the boot loader verification key (public key) 23 prior to verification of the boot loader 11 itself. Specifically, the secure element CA public key 21 held in the ROM 51 by the IoT device 100 is used to decrypt the signature in the boot loader verification key certificate 32, and the comparison with the boot loader verification key (public key) 23 is performed. conduct. Verification is considered successful only if the two match. If the verification fails, such as a mismatch between the two, the code execution is stopped here and the power of the IoT device 100 is turned off.

P7 (Verification of boot loader by digital signature): The boot loader verification function 43 verifies the decrypted boot loader 11 by using the boot loader digital signature 31 arranged at a predetermined position of the RAM (TEE) 54. Here, the boot loader digital signature 31 is decrypted by the boot loader verification key (public key) 23, the hash value of the boot loader 11 is obtained, and verification is performed according to whether or not the two match. Verification is considered successful only if the two match. If the verification fails, such as a mismatch between the two, the code execution is stopped here and the power of the IoT device 100 is turned off.

P8 (Execution of boot loader execution function): When the verification is successful, control is transferred to the boot loader execution function 44 at the end of the boot loader verification function 43, and the boot loader execution function 44 is executed.

P9 (Execution of boot loader): The boot loader execution function 44 executes the verified boot loader 11 arranged at a predetermined location in the RAM (TEE) 54.

In the above example, the setting of the initial execution code at the time of power-on is set on the ROM 51 by the IoT device manufacturer, and cannot be changed by a third party thereafter. The initial execution code is the boot loader information reading function 42, and this setting is a fixed value printed on the ROM 51. Further, the verification process of the boot loader 11 executes signature verification using the target key (public key), but as with the algorithm related to signature generation, any method may be used as long as it is a verification method corresponding to the algorithm.

The process illustrated in FIG. 3 is a process for verifying the validity of the boot loader 11, but basically the boot loader 11 cannot realize the function of the IoT device 100 by itself. In order to realize the function of the IoT device, the boot loader 11 needs to start subsequent software (software after the boot loader 11) such as an OS.

In the present embodiment, it is assumed that the subsequent software is deployed on the IoT device 100 in advance (it is not held in the secure element 60), but it is deployed on the IoT device 100 as it is from the boot loader 11. Just by executing the software, it is not possible to detect that the software has been tampered with, and security vulnerabilities remain. In the following, the secure element 60, the boot loader 11, and the subsequent software are executed by executing the logic for verifying the subsequent software from the boot loader 11 while holding the key for verifying the subsequent software in the secure element 60. The process that can secure the validity of the subsequent software by connecting the Trust Chain to is explained.

FIG. 4 is an explanatory diagram showing an example of verification of the execution image by the boot loader. Hereinafter, the processes represented by the reference numerals P1 to P12 will be described. Since the processes from P1 to P9 are the same as those in FIG. 3, the description thereof will be omitted, and P10 to P12 will be described.

P10 (validation of OS verification key): The boot loader 11 verifies the validity of the OS verification key (public key) 25 prior to verification of the IoT device 100 itself. Specifically, the IoT device 100 uses the secure element CA public key 21 held in the ROM 51 to decrypt the signature in the OS verification key certificate 34, and compares it with the OS verification key (public key) 25. conduct. Verification is considered successful only if the two match. If the verification fails, such as a mismatch between the two, the code execution is stopped here and the power of the IoT device 100 is turned off.

P11 (Verification of IoT device OS): The boot loader 11 verifies the IoT device OS 12 on the NVM 52 using the OS verification key (public key) 25. Similar to the verification of the boot loader 11 itself, the OS digital signature 33 is decrypted with the OS verification key (public key) 25, the hash value of the boot loader 11 is obtained, and verification is performed according to whether or not the two match. Verification is considered successful only if the two match. If the verification fails, such as a mismatch between the two, the code execution is stopped here and the power of the IoT device 100 is turned off.

P12 (Execution of OS): The boot loader 11 executes the verified IoT device OS 12 located at a predetermined location on the NVM 52.

The information necessary for booting is held in the secure element 60, and the secure element 60 can select whether or not to provide the information necessary for booting. Utilizing this fact, when the power of the IoT device 100 is turned on, booting by an unauthorized user can be suppressed by performing user authentication based on the information in the secure element 60. The case where user authentication is performed at startup will be described below.

FIG. 5 is an explanatory diagram showing an example of authentication before reading the boot loader. Hereinafter, the processes represented by the reference numerals P21 to P31 will be described.

P21 (Power on): The user of the IoT device 100 turns on the power of the IoT device 100.

P22 (input of user authentication information): When the power is turned on, the IoT device 100 executes the pre-start user authentication function 41 which is the initial execution code. The pre-launch user authentication function 41 activates the communication function with the secure element 60 and waits for the input of user authentication information such as PIN and fingerprint.

P23 (User authentication): When the user authentication information is input, the pre-start user authentication function 41 sends the input user authentication information to the secure element 60. The secure element 60 compares the received user authentication information with the user authentication information in the secure element 60, performs user authentication, and returns whether or not the authentication is possible. If the authentication fails, the code execution is stopped here and the IoT device 100 is turned off.

Since the processes from P24 to P31 are the same as the processes from P2 to P9 illustrated in FIG. 3, the description thereof will be omitted.

When the secure element 60 has a function of opening a secret communication path with the outside using self-confidence as an endpoint, the boot loader information of the IoT device 100 can be securely managed from the outside. When it is necessary to update the boot loader itself to add functions or prevent security vulnerabilities, as the management side of the IoT device 100, identify the IoT device on which the old boot loader is running and replace the old boot loader with the new boot loader. Is required. In this embodiment, the boot loader can be updated securely. In the following, first, the case where the secure element 60 notifies the server of the boot loader information will be described.

FIG. 6 is an explanatory diagram showing an example of remote management of boot loader information. Hereinafter, the processes represented by the reference numerals P41 to P44 will be described.

P41 (Opening of communication path): The boot loader 11 enables the network communication function of the IoT device 100 and opens a secret communication path with the boot management server 200 for the secure element 60. Here, only the network communication function (Ethernet (trademark) / Wi-Fi (trademark), etc.) uses the function of the IoT device 100, and TLS (Transport Layer Security), etc. is used between the secure element 60 and the boot management server 200. Although a secure channel is established, if the secure element 60 can independently perform network communication, communication may be performed independently.

P42 (Instruction to transmit version information to the secure element): The boot loader 11 instructs the secure element 60 to transmit the version information of the boot loader currently held. At this time, the boot loader 11 transmits the version information held by itself to the secure element 60. In this specification, an example of using the boot loader version information itself is given, but the description is not limited to the version information. For example, it may be specific information that can uniquely identify the boot loader version. The specific information may be not only the version information itself, but also a value obtained by performing a predetermined operation on the binary string of the boot loader itself, such as a hash value of the boot loader.

P43 (Comparison of version information): The secure element 60 compares the version information received from the boot loader 11 with the version information of the boot loader held by the secure element 60, and determines whether or not the match is possible.

P44 (Transmission of version information to the server): The secure element 60 transmits the comparison result to the boot management server 200 together with its own ID. If they match, the matching version information is sent. If they do not match, the IoT device 100 is operating with a boot loader 11 of a version different from the version of the boot loader held by the secure element 60. Therefore, the version number and the version number on the boot loader 11 side are different. Notify the boot management server 200 that there is a mismatch.

In the above example, the processing is started from the boot loader 11, but the processing start timing does not necessarily have to be when the boot loader is executed, and even if the processing is started at the timing when the subsequent software such as the OS is operating. good. Further, in the above example, the comparison result between the acquired version information and the retained version information is transmitted to the boot management server 200, but the present invention is not limited to this. For example, the secure element 60 may transmit the acquired version information and the retained version information to the boot management server 200 via the secret communication path established by the secure element 60. In this case, the boot management server 200 can perform comparative verification of the two.

If the version of the boot loader 11 itself and the version of the boot loader in the secure element 60 do not match, it is assumed that the boot loader 11 has been tampered with because the version booted is different from the version specified by the secure element 60. NS. The operation when the boot management server 200 receives the notification that there is a mismatch depends on the security policy of the IoT device 100. For example, a restart instruction is remotely output to the IoT device 100. Alternatively, there are various options such as notifying an alert as a security attack.

As described above, the boot management server 200 can collect the version information of the boot loader running on each IoT device 100 by collecting the version information of the boot loader from the IoT device 100. The boot management server 200 can replace the old boot loader with a new one by communicating with the secure element 60 having the old boot loader. The update of the boot loader information will be described below.

FIG. 7 is an explanatory diagram showing an example of updating the boot loader information. Hereinafter, the processes represented by the reference numerals P51 to P55 will be described.

P51 (Boot loader update determination): The boot management server 200 identifies the secure element 60 to be updated from the boot loader version of each secure element 60. For example, various methods can be used for the update determination, such as checking the version corresponding to the ID of each secure element 60 and specifying the secure element 60 as an update target if it is different from the latest version.

P52 (Specification of boot loader to be updated): The boot management server 200 specifies the version of boot loader information (including the boot loader) to be transmitted to the secure element 60. Here, we simply update to the latest version of the boot loader.

P53 (boot loader copy to secure element): The boot management server 200 transmits the boot loader information specified on P52 to the secure element 60 via the secret communication path. The secure element 60 overwrites the existing boot loader with the received boot loader and updates the held version information.

P54 (version notification after update): After updating the boot loader, the secure element 60 transmits the updated boot loader version to the boot management server 200.

P55 (Update of boot loader management table): The boot management server 200 updates the corresponding part of the boot loader management table (the row of the secure element that received the updated version) with the version of the boot loader received from the secure element 60. In the example shown, version 1.0.0 has been updated to 1.0.1.

When the IoT device 100 is already booting the OS, simply updating the boot loader in the secure element 60 does not update the software actually running on the device side, and it is necessary to restart. Regarding the response regarding the restart, the boot management server 200 or another server may remotely instruct the IoT device 100 to restart. The restart instruction may be, for example, displaying characters or images prompting the restart on a display screen or the like, or may be combined with existing technologies.

The device of this embodiment is a device having a secure boot function, and has a secure element that holds boot loader information including a boot loader, a boot loader verification key, and a boot loader signature, and boot loader information read processing and boot loader as initial execution code. It is provided with a non-rewritable non-volatile memory that holds the verification process and the boot loader execution process including the execution order. When the device is started, the boot loader information read process is executed to read the boot loader information from the secure element. The boot loader verification process verifies the boot loader by using the boot loader verification key and the signature of the boot loader, and when the verification is successful, the boot loader execution process executes the boot loader.

The secure element of the present embodiment is a secure element implemented in a device having a secure boot function, holds boot loader information including a boot loader, a boot loader verification key, and a boot loader signature, and at the time of device startup, the boot loader The boot loader information is output to the device for verification.

In the secure boot method of the device of the present embodiment, the boot loader information reading process, the boot loader verification process, and the boot loader execution process are held in a non-rewritable non-volatile memory including the execution order as the initial execution code, and the device. At startup, the boot loader information read process is executed to read the boot loader information including the boot loader, the boot loader verification key, and the boot loader signature from the secure element, and the boot loader verification process is performed on the boot loader verification key and the boot loader signature. The boot loader is verified using the above, and if the verification is successful, the boot loader execution process executes the boot loader.

The secure element holds the boot loader information, including the boot loader, boot loader verification key, and boot loader signature. By holding both the boot loader and the verification key in a secure element that cannot be tampered with and cannot be updated, the correspondence between the key and the code is limited within the secure element while preventing tampering with the boot loader and the key. As a result, the management of each key and boot loader can be integrated on the secure element side, and the load of key management can be removed from the device side. The IoT device manufacturer can delegate security management to the secure array manufacturer by supplying only the boot loader to the secure element manufacturer.

The non-rewritable non-volatile memory holds the boot loader information read process, the boot loader verification process, and the boot loader execution process as the initial execution code, including the execution order. Holding in a non-rewritable non-volatile memory means that, for example, after shipment from the factory, these processing procedures and contents, including preparation for execution of each processing, cannot be rewritten. That is, the initial execution code of the IoT device is fixedly sequenced. The execution content and order of the initial execution code that does not depend on the key value can be retained on the IoT device side in a non-updatable form. As a result, security management can be performed safely and flexibly by having individual information such as a key and a boot loader on the secure element side while preventing falsification of the initial execution code.

When the device starts up, the boot loader information read process is executed to read the boot loader information from the secure element. The boot loader verification process verifies the boot loader by using the boot loader verification key and the boot loader signature. If the verification is successful, the boot loader execution process executes the boot loader. As a result, a more secure secure boot can be realized.

In the device of the present embodiment, the secure element further holds a boot loader verification key certificate, the non-rewritable non-volatile memory holds the secure element CA public key, and the boot loader information at the time of device startup. The read process is executed to read the boot loader verification key certificate from the secure element, and the boot loader verification process uses the secure element CA public key and the read boot loader verification key certificate to perform the boot loader verification. The key is verified, and if the verification is successful, the boot loader is verified.

In the secure element of the present embodiment, the boot loader information includes a boot loader verification key certificate for verifying the boot loader verification key, and outputs the boot loader verification key certificate to the device when the device is started.

The secure element further holds the bootloader verification key certificate, and the non-rewritable non-volatile memory holds the secure element CA public key. When the device starts up, the boot loader information read process is executed to read the boot loader verification key certificate from the secure element. The boot loader verification process verifies the boot loader verification key using the secure element CA public key and the read boot loader verification key certificate. If the verification is successful, verify the bootloader. That is, prior to the verification of the boot loader, the boot loader verification key is verified by the secure element CA public key.

The signature verification of the boot loader verification key is performed using the secure element CA public key held in the non-rewritable non-volatile memory in the IoT device, and the validity of the boot loader verification key is verified. As a result, it is possible to prevent an attack that attempts to start an unauthorized boot loader by tampering with the key.

In the device of the present embodiment, the secure element further holds a software verification key, executes the boot loader information read process at device startup, reads the software verification key from the secure element, and the boot loader , The software verification key is used to verify the software image executed after the boot loader.

In the secure element of the present embodiment, the boot loader information includes a software verification key for verifying a software image executed after the boot loader, and outputs the software verification key to the device when the device is started.

The secure element also holds the software verification key. When the device starts up, the boot loader information read process is executed to read the software verification key from the secure element. The boot loader uses the software verification key to verify the image of software (for example, OS) executed after the boot loader.

The key for verifying the software image executed after the boot loader is stored in the secure element. This makes it possible to easily configure a key-based Trust Chain with the secure element as the Root of Trust.

In the device of the present embodiment, the secure element further holds the software verification key certificate, executes the boot loader information read process at device startup, and reads the software verification key certificate from the secure element. The boot loader verifies the software verification key using the secure element CA public key and the software verification key certificate, and if the verification is successful, verifies the software image.

In the secure element of the present embodiment, the boot loader information includes a software verification key certificate for verifying the software verification key, and outputs the software verification key certificate to the device when the device is started.

The secure element also holds a software verification key certificate. When the device starts up, the boot loader information read process is executed to read the software verification key certificate from the secure element. The bootloader verifies the software verification key using the secure element CA public key and the software verification key certificate. If the verification is successful, verify the software image. That is, prior to the verification of the software image, the software verification key is verified by the secure element CA public key and the software verification key certificate.

The software verification key is verified using the software verification key certificate held in the non-rewritable non-volatile memory in the IoT device, and the validity of the software verification key is verified. This makes it possible to prevent attacks that attempt to execute malicious software by tampering with the key.

The device of this embodiment includes a SoC having a secure area for holding the boot loader information read from the secure element.

The SoC (System on Chip) has a secure area (for example, TEE: Trusted Execution Environment), and holds the boot loader information read from the secure element in the secure area. For example, the encrypted boot loader is read and decrypted in a secure area in the SoC. As a result, it is possible to prevent an attack aimed at the verification process of the boot loader.

In the device of the present embodiment, the secure element holds the user authentication information, and when the device is started, the user authentication is performed based on the input user authentication information and the held user authentication information, and the user authentication is successful. In this case, the boot loader information reading process is performed.

The secure element of the present embodiment holds the user authentication information, performs user authentication based on the input user authentication information and the held user authentication information at the time of device startup, and when the user authentication is successful, the boot loader. Information is output to the device.

The secure element holds the user authentication information. When the device is started, user authentication is performed based on the input user authentication information and the retained user authentication information. If the user authentication is successful, the boot loader information is read.

Prior to reading the boot loader and key, the secure element requests external authentication, and if the authentication is successful, the boot loader information is read (the boot loader information is output to the device side). As a result, strong authentication such as biometric authentication and PIN (Personal Identification Number) authentication can be introduced into the device activation itself and bypass of the authentication can be prevented according to the security needs for the IoT device.

The secure element of the present embodiment holds specific information that identifies the version of the boot loader, acquires specific information of the boot loader from the device, and obtains and holds the specific information, or holds the acquired specific information and the specific information. The comparison result with the specified specific information is transmitted to an external server via a secret communication path.

The specific information may be any information that can uniquely identify the boot loader version. The specific information may be, for example, version information itself, or a value obtained by performing a predetermined operation on a binary string of the boot loader itself, such as a hash value of the boot loader. The secure element may transmit the acquired specific information and the retained specific information to an external server via the secret communication path established by the secure element, or compare the acquired specific information with the retained specific information. The result may be sent to an external server. This makes it possible to check the versions of the boot loaders loaded inside the secure element and in the IoT device via the secret communication path established by the secure element.

The secure element of the present embodiment is a boot loader, a boot loader verification key, a boot loader signature, a boot loader verification key certificate, a software verification key, and a hold, based on a command from an external server via a secret communication path. Update all or part of the software verification key certificate.

All or one of the boot loader, boot loader verification key, boot loader signature, boot loader verification key certificate, software verification key, and software verification key certificate held based on a command from an external server via a secret communication path. Update the department. The boot loader and key in the secure element can be updated from the outside via the secret communication path established by the secure element. This not only allows the bootloader to be updated safely and reliably, but also allows external control of device bootability via a secure element (strong Root of Trust). When the subsequent software is also subject to verification, it is possible to externally control whether or not the software can be started via the secure element.

1 Network secret communication path 11 Boot loader 12 IoT device OS
21 Secure element CA public key 22 Secure element CA private key 23 Boot loader verification key (public key)
24 Boot loader signature generation key (private key)
25 OS verification key (public key)
26 OS signature generation key (private key)
31 Boot loader digital signature 32 Boot loader verification key certificate 33 OS digital signature 34 OS verification key certificate 40 Communication path with secure element 41 Pre-boot user authentication function 42 Boot loader information read function 43 Boot loader verification function 44 Boot loader execution function 50 SoC
51 ROM
52 NVM
53 RAM (REE)
54 RAM (TEE)
60 Secure Element 100 IoT Device 200 Boot Management Server

Claims (14)

A device with a secure boot function
A secure element that holds boot loader information, including the boot loader, boot loader verification key, and boot loader signature.
The initial execution code includes a boot loader information read process, a boot loader verification process, and a non-rewritable non-volatile memory that holds the boot loader execution process including the execution order.
When the device is started, the boot loader information read process is executed to read the boot loader information from the secure element.
The boot loader verification process
The boot loader is verified by using the boot loader verification key and the signature of the boot loader.
If the verification is successful, the boot loader execution process executes the boot loader.
device. The secure element also holds the bootloader verification key certificate.
The non-rewritable non-volatile memory holds the secure element CA public key.
When the device is started, the boot loader information read process is executed to read the boot loader verification key certificate from the secure element.
The boot loader verification process
The boot loader verification key is verified using the secure element CA public key and the read boot loader verification key certificate.
If the verification is successful, the boot loader is verified.
The device according to claim 1. The secure element further holds the software verification key and
When the device is started, the boot loader information read process is executed to read the software verification key from the secure element.
The boot loader is
The software image executed after the boot loader is verified by using the software verification key.
The device according to claim 1 or 2. The secure element further holds a software verification key certificate.
When the device is started, the boot loader information reading process is executed to read the software verification key certificate from the secure element.
The boot loader is
The software verification key is verified using the secure element CA public key and the software verification key certificate.
If the verification is successful, the software image is verified.
The device according to claim 3. A SoC having a secure area for holding boot loader information read from the secure element.
The device according to any one of claims 1 to 4. The secure element holds user authentication information and
When the device starts up, user authentication is performed based on the entered user authentication information and the retained user authentication information.
If the user authentication is successful, the boot loader information reading process is performed.
The device according to any one of claims 1 to 5. A secure element implemented in a device that has a secure boot function.
Holds boot loader information, including the boot loader, boot loader verification key, and boot loader signature.
When the device is started, the boot loader information is output to the device for verification of the boot loader.
Secure element. The boot loader information includes a boot loader verification key certificate for verifying the boot loader verification key.
When the device is started, the boot loader verification key certificate is output to the device.
The secure element according to claim 7. The boot loader information includes a software verification key for verifying a software image executed after the boot loader.
When the device is started, the software verification key is output to the device.
The secure element according to claim 7 or 8. The boot loader information includes a software verification key certificate for verifying the software verification key.
When the device is started, the software verification key certificate is output to the device.
The secure element according to claim 9. Hold user credentials and
When the device starts up, user authentication is performed based on the entered user authentication information and the retained user authentication information.
If the user authentication is successful, the boot loader information is output to the device.
The secure element according to any one of claims 7 to 10. Holds specific information that identifies the bootloader version,
Obtain the boot loader specific information from the device and
The acquired specific information and the retained specific information, or the comparison result between the acquired specific information and the retained specific information are transmitted to an external server via a secret communication path.
The secure element according to any one of claims 7 to 11. All or one of the boot loader, boot loader verification key, boot loader signature, boot loader verification key certificate, software verification key, and software verification key certificate held based on a command from an external server via a secret communication path. Update the department,
The secure element according to any one of claims 7 to 12. As the initial execution code, the boot loader information read process, boot loader verification process, and boot loader execution process, including the execution order, are stored in a non-rewritable non-volatile memory.
When the device is started, the boot loader information read process is executed to read the boot loader information including the boot loader, the boot loader verification key, and the boot loader signature from the secure element.
The boot loader verification process
The boot loader is verified by using the boot loader verification key and the signature of the boot loader.
If the verification is successful, the boot loader execution process executes the boot loader.
How to secure boot the device.

Images