JP7428049B2 - Devices, secure elements and device secure boot methods - Google Patents

Description

The present invention relates to a device, a secure element, and a secure boot method for a device.

A technology called secure boot is beginning to become popular as a technology for ensuring security in IoT devices. Secure boot is a technology that prevents unauthorized software from starting a device by only allowing software that has been digitally signed in advance to be executed when a device such as a PC is started.

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

Japanese Patent Application Publication No. 2015-201091

However, the following problems remain in the conventional secure boot technology. When verifying the validity of executable code by performing verification and decryption using a key, there is a strong relationship between the key and the executable code that are stored in separate media, and when updating, it is necessary to update both. becomes. Additionally, IoT devices generally operate continuously for long periods of time, sometimes unattended, and are required to be tamper-resistant in order to retain keys. Furthermore, when performing software verification based on a public key, it is possible to falsify both the key and the software to make it appear that legitimate verification has been performed. Furthermore, it is difficult to update the bootloader based on a reliable root of trust, and there is room for unauthorized rewriting at the time of update.

The present invention has been made in view of the above circumstances, and an object of the present invention is to provide a device, a secure element, and a secure boot method for a device that can realize a secure boot with higher safety.

A device according to an embodiment of the present invention has a secure boot function, and includes a secure element that holds boot loader information including a boot loader, a boot loader verification key, and a signature of the boot loader, and a boot loader information readout function as an initial execution code. and a non-rewritable non-volatile memory that stores processing, boot loader verification processing, and boot loader execution processing including the execution order, and executes the boot loader information read processing at the time of device startup to read the boot loader information from the secure element. The bootloader verification process verifies the bootloader using the bootloader verification key and the bootloader signature, and if the verification is successful, the bootloader execution process executes the bootloader.

A secure element according to an embodiment of the present invention 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 signature of the boot loader, and when the device is started, The bootloader information is output to the device for verification of the bootloader.

A secure boot method for a device according to an embodiment of the present invention stores bootloader information read processing, bootloader verification processing, and bootloader execution processing, including the execution order, in a non-volatile memory that cannot be rewritten as initial execution code. and when the device is started, the boot loader information reading process is executed to read the boot loader information including the boot loader, the boot loader verification key, and the signature of the boot loader from the secure element; The bootloader execution process verifies the bootloader using the signature of the bootloader, and if the verification is successful, executes the bootloader.

According to the present invention, secure boot with higher safety can be realized.

FIG. 2 is a schematic diagram showing a trust chain of keys, certificates, and signatures according to the present embodiment. FIG. 1 is a schematic diagram showing an example of the configuration of an IoT device. FIG. 2 is an explanatory diagram showing an example of a basic boot process. FIG. 2 is an explanatory diagram illustrating an example of verification of an execution image by a boot loader. FIG. 3 is an explanatory diagram showing an example of authentication before reading a boot loader. FIG. 2 is an explanatory diagram showing an example of remote management of boot loader information. FIG. 3 is an explanatory diagram showing an example of updating boot loader information.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below based on drawings showing embodiments thereof. FIG. 1 is a schematic diagram showing a trust chain of keys, certificates, and signatures according to this embodiment. In this embodiment, three parties, the IoT device manufacturer, the secure element manufacturer, and the software manufacturer executed after the bootloader, each maintain the necessary data, and each manufacturer appropriately manages the target key pair. This allows multiple software implementation entities to work together to achieve secure booting. An IoT device is, for example, a device (also referred to as an electronic device) that is equipped with an OS and can operate independently, and is a device that corresponds to a "thing" in the "Internet of Things" (IoT).

Note that 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 the software executed after the boot loader. It is not limited to these, and includes all software images executed after the boot loader, including software contents such as Docker images.

Data is broadly classified into three types: executable software, keys, and signatures (certificates). First, executable software will be explained.

The executable software includes, for example, the boot loader 11 and the IoT device OS 12. The boot loader 11 is software that executes boot processing on the IoT device, and is code for starting 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 RTOS or Rich OS (Linux, etc.). The bootloader 11 and the IoT device OS 12 may be implemented by an IoT device manufacturer and an IoT device OS vendor, respectively, or both the bootloader 11 and the IoT device OS 12 may be implemented by one of the parties. The bootloader 11 needs to be provided to the secure element manufacturer.

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

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

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

The OS verification key (public key) 25 is a key for verifying the signature for the IoT device OS generated by the IoT device OS vendor. The OS signature generation key (private key) 26 is a key used by 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, signatures will be explained. A signature is a technology that allows the recipient to know that the transmitted content has been tampered with. Generally, a sender generates a signature by hashing data to generate a digest, and encrypting the generated digest with a private key. The sender sends the signature along with the data. The recipient receives the data and signature and hashes the data to generate a digest. The recipient decrypts the signature with the public key to obtain the digest. Compare the two digests to determine whether they match or do not match. If the two match, it can be confirmed that the data has not been tampered with.

The signatures include, 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 bootloader digital signature 31 is a signature generated for the bootloader 11 using the bootloader signature generation key (private key) 24. For example, a value obtained by encrypting a hash value of the boot loader 11 (binary string) using the boot loader signature generation key (private key) 24 can be used as the signature. The bootloader verification key certificate 32 is a signature generated by the secure element CA private key 22 for the bootloader verification key (public key) 23. For example, a value obtained by encrypting a hash value of the boot loader verification key (public key) 23 using the secure element CA private key 22 can be used as the signature.

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

In this embodiment, a signature is generated by encrypting a hash value to be signed using a signature generation key, but the signature generation algorithm is not limited to this, and the signature generation algorithm is not limited to this. Any signature generation and verification method that relies on the above may be used.

Signature verification is performed by decrypting the signature using a verification key and comparing it with the signature target. The verification key must be the opposite key to the signature generation key, and signature generation is impossible unless you have the opposite private key. Therefore, if the signature target is successfully verified, it is proven that the signature was signed by a subject who has a private key and that the signature target has not been tampered with since the time of signing.

In this embodiment, (1) verification of the boot loader digital signature 31 using the boot loader verification key (public key) 23 (proof that the boot loader 11 has not been tampered with); (2) verification of the boot loader verification key using the secure element CA public key 21; Two signature verifications are performed: verification of the (public key) 23 (proof that the bootloader verification key (public key) 23 has not been tampered with). This ensures that the bootloader 11 is signed by the secure element manufacturer and has not been tampered with, and that the verification process itself has not been tampered with (verification is performed using a valid verification key). It is possible to ensure legitimacy and realize secure boot.

In addition, when verifying against the OS, (1) verification of the OS digital signature 33 using the OS verification key (public key) 25 (proof that the OS has not been tampered with), (2) secure element CA public key 21 Validation of the OS verification key (public key) 25 (proof that the OS verification key (public key) 25 has not been tampered with) is ensured by the Trust Chain. This makes it possible to ensure that the OS has been 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 diagram showing an example of the configuration of the IoT device 100. The IoT device 100 is a device to which secure boot is implemented, and includes, for example, an embedded board that runs RTOS, Linux, or the like. The IoT device 100 includes an SoC (System on Chip) 50 and a secure element 60 inside. IoT device 100 may include a user authentication input device. The user authentication input device is a device for accepting input of authentication information from the user when user authentication is required when the IoT device 100 is activated, and includes, for example, a PIN pad, a fingerprint sensor, and the like.

The SoC 50 is an IC chip that retains the main functions of the IoT device 100. The SoC 50 includes a ROM 51, an NVM 52, a RAM (REE) 53, and a RAM (TEE) 54 as non-volatile memories that cannot be rewritten. Note that in this specification, a ROM will be described as an example of a non-rewritable non-volatile memory, but specifically, a non-rewritable non-volatile memory includes a mask ROM, a programmable ROM, Programmable ROMs include OTP (One Time Programmable)-ROM, EEPROM (Electronically Erasable and Programmable Read Only Memory), flash memory protected against rewritability, and the like. Any of these may be used as the ROM 51. The secure element 60 is a security chip with tamper resistance, and has a CPU, NVM (Non-volatile memory), and secure non-volatile memory inside. The secure element 60 communicates with the SoC 50 using a standard communication path (eg, 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 ROM 51 holds a pre-boot user authentication function 41, a boot loader information reading function 42, a boot loader verification function 43, a boot loader execution function 44, and a secure element CA public key 21.

The pre-boot 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 processing to request user authentication from the secure element 60.

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

The bootloader verification function 43 uses the bootloader digital signature 31 to perform a process of verifying the authenticity of the decrypted bootloader 11.

The bootloader execution function 44 passes control to the decrypted bootloader 11 and performs processing for executing the bootloader 11. The processing and data of the pre-boot user authentication function 41, bootloader information reading function 42, bootloader verification function 43, and bootloader 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 (they are kept in a secure state).

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

The RAM of the SoC 50 is divided into two areas: an unsecure normal memory area (REE: Rich Execution Environment) 53 and a secure area (TEE: Trusted Execution Environment) 54. In this embodiment, the boot loader information of the secure element 60 is loaded into the RAM (TEE) 54, but in the case of an SoC that does not have the RAM (TEE) 54 and only has 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 SEID and user authentication information (PIN, etc.) in addition to bootloader information. SEID is an ID that uniquely identifies the secure element 60. It can be used as a value for identifying the secure element 60 from the boot management server 200. The user authentication information is information held in the secure element 60 in order for the secure element 60 to authenticate the user of the IoT device 100, and holds, for example, biometric authentication information such as a user PIN and fingerprint authentication.

The boot management server 200 has, for each SEID, a boot loader management table that holds the version of the boot loader held in the secure element 60 of the SEID, and the latest version of the boot loader at the current time.

Next, secure boot according to this embodiment will be explained. Below, a basic boot process, verification of an executable image by the boot loader, authentication before reading the boot loader, remote management of boot loader information, and updating of the boot loader information will be explained.

FIG. 3 is an explanatory diagram showing an example of a basic boot process. The processes indicated by symbols P1 to P9 will be described below.

P1 (power on): The user of the IoT device 100 powers on the IoT device 100. Note that depending on the IoT device, an operation such as restarting may be performed in addition to turning on the power.

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

P3 (Bootloader information acquisition instruction): The bootloader information reading function 42 enables the communication function with the secure element 60 and sends an information acquisition command to the secure element 60.

P4 (Bootloader information acquisition): The secure element 60 receives the bootloader 11, bootloader verification key (public key) 23, bootloader digital signature 31, bootloader verification key certificate 32, OS verification key (public key) 25, and OS as a response. The verification key certificate 34 (collectively referred to as boot loader information) is returned. The bootloader information reading function 42 places the bootloader information in a designated area on the RAM in the SoC 50 (in this case, the RAM (TEE) 54).

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

P6 (Verification of validity of bootloader verification key): The bootloader verification function 43 verifies the validity of the bootloader verification key (public key) 23 prior to verification of the bootloader 11 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 bootloader verification key certificate 32 and compare it with the bootloader verification key (public key) 23. conduct. Verification is considered successful only if both match. If the verification fails, such as when the two do not match, execution of the code is stopped and the power of the IoT device 100 is turned off.

P7 (Verification of bootloader using digital signature): The bootloader verification function 43 verifies the decrypted bootloader 11 using the bootloader digital signature 31 placed at a predetermined location in the RAM (TEE) 54. Here, the boot loader digital signature 31 is decrypted using the boot loader verification key (public key) 23, the hash value of the boot loader 11 is obtained, and verification is performed depending on whether the two match. Verification is considered successful only if both match. If the verification fails, such as when the two do not match, execution of the code is stopped and the power of the IoT device 100 is turned off.

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

P9 (bootloader execution): The bootloader execution function 44 executes the verified bootloader 11 placed at a predetermined location in the RAM (TEE) 54.

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

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

In this embodiment, it is assumed that the subsequent software is deployed on the IoT device 100 in advance (not retained in the secure element 60), but it is deployed directly on the IoT device 100 from the boot loader 11. Simply running the software cannot detect that the software has been tampered with, leaving security vulnerabilities. In the following, by holding a key for verifying subsequent software in the secure element 60 and executing logic for verifying subsequent software from the boot loader 11, three parties: the secure element 60, the boot loader 11, and the subsequent software We will explain the process by which a trust chain can be connected to the software to ensure the validity of subsequent software.

FIG. 4 is an explanatory diagram showing an example of verification of an execution image by a boot loader. The processes indicated by symbols P1 to P12 will be explained below. Note that since the processing from P1 to P9 is the same as that in the case of FIG. 3, the explanation will be omitted, and the processing from P10 to P12 will be explained.

P10 (Verification of validity of OS verification key): The boot loader 11 verifies the validity of the OS verification key (public key) 25 before verifying 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 compare it with the OS verification key (public key) 25. conduct. Verification is considered successful only if both match. If the verification fails, such as when the two do not match, execution of the code is stopped 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 using the OS verification key (public key) 25, the hash value of the boot loader 11 is obtained, and verification is performed depending on whether the two match. Verification is considered successful only if both match. If the verification fails, such as when the two do not match, execution of the code is stopped and the power of the IoT device 100 is turned off.

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

By holding the information necessary for booting in the secure element 60, the secure element 60 can select whether to provide the information necessary for booting. Taking advantage of this, when the IoT device 100 is powered on, user authentication is performed based on the information in the secure element 60, thereby preventing booting by an unauthorized user. In the following, a case will be described in which user authentication is performed at startup.

FIG. 5 is an explanatory diagram showing an example of authentication before reading the boot loader. The processes indicated by symbols P21 to P31 will be described below.

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

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

P23 (user authentication): When user authentication information is input, the pre-boot user authentication function 41 sends the input user authentication information to the secure element 60. The secure element 60 performs user authentication by comparing the received user authentication information with the user authentication information within the secure element 60, and returns whether or not authentication is possible. If the authentication fails, the code execution is stopped and the IoT device 100 is powered off.

The processing from P24 to P31 is the same as the processing from P2 to P9 illustrated in FIG. 3, so a description thereof will be omitted.

If the secure element 60 has a function of opening a secret communication path with the outside using itself as an endpoint, it becomes possible to securely manage the boot loader information of the IoT device 100 from the outside. When it becomes necessary to update the bootloader itself to add functionality or prevent security vulnerabilities, the person managing the IoT device 100 can identify the IoT device running the old bootloader and replace the old bootloader with the new bootloader. is required. In this embodiment, the boot loader can be updated securely. In the following, first, a case will be described in which the secure element 60 notifies the server of boot loader information.

FIG. 6 is an explanatory diagram showing an example of remote management of boot loader information. The processes indicated by symbols P41 to P44 will be explained below.

P41 (Establishing a 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.) is used as 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 is capable of independent network communication, it may communicate alone.

P42 (Instruction to transmit version information to secure element): The boot loader 11 instructs the secure element 60 to transmit the currently held version information of the boot loader. At this time, the boot loader 11 transmits the version information it holds to the secure element 60. Note that although this specification describes an example in which the version information of the boot loader itself is used, the present invention is not limited to the version information. For example, any specific information that can uniquely identify the version of the boot loader may be used. The specific information may be not only the version information itself, but also 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.

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 that it holds, and determines whether they match.

P44 (transmission of version information to server): The secure element 60 transmits the comparison result along with its own ID to the boot management server 200. If the two match, the matching version information is sent. If the two do not match, the IoT device 100 is operating with a version of the bootloader 11 that is different from the version of the bootloader held by the secure element 60, so the version number on the bootloader 11 side and the version number are different. The boot management server 200 is notified of the mismatch.

In the above example, the process is started from the bootloader 11, but the timing to start the process does not necessarily have to be when the bootloader is executed. good. Further, in the above example, the configuration is such that the comparison result between the acquired version information and the held version information is sent to the boot management server 200, but the configuration is not limited to this. For example, the secure element 60 may transmit the acquired version information and the held version information to the boot management server 200 via a secret communication path established by itself. In this case, the boot management server 200 can compare and verify 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 may have been tampered with because it has been booted with a version different from the version specified by the secure element 60. Ru. The operation when the boot management server 200 receives a notification of mismatch depends on the security policy of the IoT device 100, but for example, the boot management server 200 remotely outputs a reboot instruction to the IoT device 100. There are various options, such as treating the attack as a security attack and notifying an alert.

As described above, by collecting boot loader version information from the IoT devices 100, the boot management server 200 can collect the versions of the boot loaders running on each IoT device 100. By communicating with the secure element 60 that has an old boot loader, the boot management server 200 can replace the old boot loader with a new one. Updating the bootloader information will be described below.

FIG. 7 is an explanatory diagram showing an example of updating boot loader information. The processes indicated by symbols P51 to P55 will be described below.

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

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

P53 (bootloader copy to secure element): The boot management server 200 transmits the bootloader information specified in 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 version information it holds.

P54 (Notification of updated version): After updating the boot loader, the secure element 60 transmits the updated version of the boot loader 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 illustrated example, version 1.0.0 has been updated to 1.0.1.

If the IoT device 100 is already running the OS, simply updating the boot loader in the secure element 60 does not update the software actually running on the device, and requires rebooting. As for measures related to rebooting, rebooting may be instructed to the IoT device 100 remotely from the boot management server 200 or another server. The restart instruction may be given by, for example, displaying text or images on a display screen or the like to urge restart, or by combining existing techniques.

The device of this embodiment is a device having a secure boot function, and includes a secure element that holds boot loader information including a boot loader, a boot loader verification key, and a boot loader signature, and a boot loader information reading process and a boot loader function as an initial execution code. comprising a non-rewritable non-volatile memory that holds verification processing and bootloader execution processing including the execution order, and when the device is started, executes the bootloader information reading processing to read the bootloader information from the secure element; The bootloader verification process verifies the bootloader using the bootloader verification key and the signature of the bootloader, and if the verification is successful, the bootloader execution process executes the bootloader.

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

The device secure boot method of this embodiment stores bootloader information read processing, bootloader verification processing, and bootloader execution processing, including the execution order, as initial execution code in non-volatile memory that cannot be rewritten. At startup, the boot loader information read process is executed to read boot loader information including a boot loader, a boot loader verification key, and a signature of the boot loader from the secure element, and the boot loader verification process is performed to read the boot loader information including the boot loader verification key and the boot loader signature. The boot loader is verified using the above boot loader, and if the verification is successful, the boot loader execution process executes the boot loader.

The secure element holds bootloader information including the bootloader, a bootloader verification key, and a signature of the bootloader. By holding both the boot loader and the verification key in a secure element that cannot be tampered with or updated, the correspondence between the key and the code is limited to the secure element while preventing tampering with the boot loader and the key. As a result, the management of keys and boot loaders can be consolidated on the secure element side, and the burden of key management can be removed from the device side. The IoT device manufacturer can delegate security management to the secure element manufacturer by providing only the bootloader to the secure element manufacturer.

The non-rewritable nonvolatile memory holds bootloader information read processing, bootloader verification processing, and bootloader execution processing, including the execution order, as initial execution codes. Holding in a non-volatile memory that cannot be rewritten means that, for example, after shipment from the factory, these processing procedures and contents, including preparation for execution of each process, cannot be rewritten. That is, the initial execution code of the IoT device is made into a fixed sequence. The execution content and order of the initial execution code, which does not depend on the key value, can be held in an unupdateable form on the IoT device side. This allows security management to be performed safely and flexibly by allowing the secure element to hold individual information such as keys and boot loaders while preventing tampering with the initial execution code.

When the device is started, a bootloader information reading process is executed to read the bootloader information from the secure element. The bootloader verification process verifies the bootloader using the bootloader verification key and the signature of the bootloader. If the verification is successful, the bootloader execution process executes the bootloader. This makes it possible to achieve a more secure secure boot.

In the device of this embodiment, the secure element further holds a bootloader verification key certificate, the non-rewritable non-volatile memory holds a secure element CA public key, and the bootloader information is stored at the time of device startup. A read process is executed to read the boot loader verification key certificate from the secure element, and the boot loader verification process verifies the boot loader using the secure element CA public key and the read boot loader verification key certificate. Verify the key, and if verification is successful, verify the bootloader.

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

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

The signature of the bootloader verification key is verified using the secure element CA public key held in the non-volatile memory that cannot be rewritten within the IoT device, and the validity of the bootloader verification key is verified. This can prevent attacks that attempt to launch the bootloader illegally 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 reading process to read the software verification key from the secure element when the device is started, and the boot loader reads the software verification key from the secure element. , verifying a software image executed after the boot loader using the software verification key;

In the secure element of this embodiment, the bootloader information includes a software verification key for verifying a software image executed after the bootloader, and the software verification key is output to the device when the device is started.

The secure element also holds a software verification key. When the device is started, a 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 software (eg, OS, etc.) images that are executed after the boot loader.

A key for verifying software images 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 a software verification key certificate, and executes the boot loader information reading process at the time of device startup to read the software verification key certificate from the secure element. , the boot loader verifies a 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 this embodiment, the boot loader information includes a software verification key certificate for verifying the software verification key, and the software verification key certificate is output to the device when the device is started.

The secure element also holds a software verification key certificate. When the device is started, a boot loader information reading 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 verification is successful, verify the software image. That is, prior to verifying the software image, the software verification key is verified using the secure element CA public key and the software verification key certificate.

A software verification key certificate held in a non-volatile memory that cannot be rewritten within an IoT device is used to verify a software verification key, thereby verifying the validity of the software verification key. This prevents attacks that attempt to execute unauthorized software by tampering with keys.

The device of this embodiment includes an SoC having a secure area that holds bootloader information read from the secure element.

An SoC (System on Chip) has a secure area (for example, TEE: Trusted Execution Environment), and stores boot loader information read from a secure element in the secure area. For example, the encrypted boot loader is read and decrypted in a secure area within the SoC. This can prevent attacks targeting the bootloader verification process.

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

The secure element of this embodiment holds user authentication information, performs user authentication based on the input user authentication information and the held user authentication information when the device is started, and if the user authentication is successful, the boot loader Output information to the device.

The secure element holds 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 user authentication is successful, bootloader information reading processing is performed.

Prior to reading the bootloader and key, the secure element requests external authentication, and if authentication is successful, reads the bootloader information (outputs the bootloader information to the device side). This makes it possible to introduce strong authentication, such as biometric authentication or PIN (Personal Identification Number) authentication, to the device activation itself in accordance with security needs for IoT devices, and to prevent bypassing of the authentication.

The secure element of this embodiment retains specific information that specifies the version of the boot loader, acquires the boot loader specific information from the device, and stores the acquired specific information and the retained specific information, or the acquired specific information and the retained specific information. The results of the comparison with the identified specific information are sent to an external server via a secret communication channel.

The specific information may be any information that can uniquely identify the version of the boot loader. 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 send the acquired specific information and retained specific information to an external server via a confidential communication channel established by itself, or may compare the acquired specific information with the retained specific information. Results may be sent to an external server. Thereby, the versions of the boot loaders loaded inside the secure element and on the IoT device can be confirmed via the secret communication path opened by the secure element.

The secure element of this embodiment secures the stored boot loader, boot loader verification key, boot loader signature, boot loader verification key certificate, software verification key, and Update all or part of the software verification key certificate.

Based on instructions from an external server via a secret communication path, all or one of the retained boot loader, boot loader verification key, boot loader signature, boot loader verification key certificate, software verification key, and software verification key certificate is Update the section. The boot loader and keys in the secure element can be updated from the outside via the secret communication channel established by the secure element. This not only allows you to update the bootloader safely and reliably, but also allows you to externally control whether or not the device can be booted via a secure element (strong root of trust). If subsequent software is also subject to verification, whether or not the software can be activated can be externally controlled via the secure element.

1 Network secret communication path 11 Bootloader 12 IoT device OS
21 Secure element CA public key 22 Secure element CA private key 23 Bootloader verification key (public key)
24 Bootloader signature generation key (private key)
25 OS verification key (public key)
26 OS signature generation key (private key)
31 Bootloader digital signature 32 Bootloader 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 Bootloader information reading function 43 Bootloader verification function 44 Bootloader 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 having a secure boot function,
a secure element that holds bootloader information including a bootloader, a bootloader verification key, and a signature of the bootloader;
and a non-rewritable nonvolatile memory that holds bootloader information read processing, bootloader verification processing, and bootloader execution processing, including the execution order, as initial execution code;
executing the bootloader information reading process at device startup to read the bootloader information from the secure element;
The bootloader verification process includes:
verifying the bootloader using the bootloader verification key and the bootloader signature;
If the verification is successful, the bootloader execution process executes the bootloader;
device. The secure element further holds a bootloader verification key certificate;
The non-rewritable non-volatile memory holds a secure element CA public key,
When the device is started, executing the bootloader information reading process to read the bootloader verification key certificate from the secure element;
The bootloader verification process includes:
verifying the bootloader verification key using the secure element CA public key and the read bootloader verification key certificate;
if the verification is successful, verifying the bootloader;
A device according to claim 1. The secure element further holds a software verification key;
executing the bootloader information reading process at device startup to read the software verification key from the secure element;
The bootloader is
verifying a software image executed after the bootloader using the software verification key;
A device according to claim 2. The secure element further holds a software verification key certificate;
executing the boot loader information reading process at device startup to read the software verification key certificate from the secure element;
The bootloader is
verifying a software verification key using the secure element CA public key and the software verification key certificate;
if verification is successful, verifying the software image;
4. A device according to claim 3. comprising an SoC having a secure area that holds bootloader information read from the secure element;
A device according to any one of claims 1 to 4. The secure element holds user authentication information, and
When the device is started, user authentication is performed based on the entered user authentication information and the retained user authentication information,
If the user authentication is successful, performing the bootloader information reading process;
A device according to any one of claims 1 to 5. A secure element implemented in a device having a secure boot function,
maintains bootloader information including a bootloader, a bootloader verification key, and a bootloader signature;
outputting the bootloader information to the device for verification of the bootloader when the device boots;
secure element. The bootloader information includes a bootloader verification key certificate for verifying the bootloader verification key,
outputting the bootloader verification key certificate to the device when the device boots;
Secure element according to claim 7. The bootloader information includes a software verification key for verifying a software image executed after the bootloader,
outputting the software verification key to the device when the device starts up;
The secure element according to claim 7 or claim 8. The boot loader information includes a software verification key certificate for verifying the software verification key,
outputting the software verification key certificate to the device when the device starts;
Secure element according to claim 9. retain user credentials;
When the device is started, user authentication is performed based on the entered user authentication information and the retained user authentication information,
outputting the bootloader information to the device if the user authentication is successful;
Secure element according to any one of claims 7 to 10. Contains specific information that identifies the bootloader version,
obtaining bootloader specific information from the device;
Sending the acquired specific information and retained specific information, or the comparison result between the acquired specific information and the retained specific information, to an external server via a confidential communication channel;
A secure element according to any one of claims 7 to 11. Based on instructions from an external server via a secret communication path, all or one of the retained boot loader, boot loader verification key, boot loader signature, boot loader verification key certificate, software verification key, and software verification key certificate is update the section,
Secure element according to any one of claims 7 to 12. As initial execution code, bootloader information read processing, bootloader verification processing, and bootloader execution processing, including the execution order, are held in non-volatile memory that cannot be rewritten.
When the device is started, the bootloader information reading process is executed to read bootloader information including a bootloader, a bootloader verification key, and a signature of the bootloader from the secure element;
The bootloader verification process includes:
verifying the bootloader using the bootloader verification key and the bootloader signature;
If the verification is successful, the bootloader execution process executes the bootloader;
How to securely boot your device.

Images