Software Installation Method

Abstract

The present disclosure relates to a software installation method for a device. The device includes a non-volatile memory 10 and an access control circuit 6, which controls access to the non-volatile memory based on area definition data 7, the area definition data 7 defining whether a given area of ​​the non-volatile memory is a less secure area or a more secure area, wherein access to the more secure area is subject to greater access restrictions than access to the less secure area. The method includes installing target software 40 in a target area of ​​the non-volatile memory defined as a less secure area by the area definition data; verifying the target software; and at least when the verification of the target software is successful, and after the target software is installed, updating the area definition data to change the target area from a less secure area to a more secure area.

Description

Technical Field

[0001] The present technology relates to the field of information processing devices. More specifically, the present technology relates to a software installation method for a device including a non-volatile memory. Background Art

[0002] The device may have non-volatile memory for storing software and data that will be persistently stored even when the device is not powered. Some devices may support partitioning the non-volatile memory into areas with different security levels, such as including less secure areas and more secure areas. Typically, access to more secure areas may be more restricted than access to less secure areas. For example, in some operating states of the device, the device may not be allowed to access more secure areas of non-volatile memory. This is useful for protecting sensitive code or data from being accessed by less secure processes executing on the device. Summary of the invention

[0003] At least some instances provide a software installation method for a device, the device including a nonvolatile memory and an access control circuit, the access control circuit controlling access to the nonvolatile memory based on area definition data, the area definition data defining whether a given area of ​​the nonvolatile memory is a less secure area or a more secure area, wherein the access control circuit is configured to impose greater restrictions on access to the more secure area than on access to the less secure area; the method including: installing target software in a target area of ​​the nonvolatile memory defined as a less secure area by the area definition data; verifying the target software; and at least when the verification of the target software is successful and after the target software is installed, updating the area definition data to change the target area from a less secure area to a more secure area.

[0004] At least some examples provide at least one computer program for controlling a device to perform the aforementioned method. At least one storage medium may be provided to store at least one computer program.

[0005] At least some examples provide an apparatus comprising: a processing circuit for performing data processing; and a data storage device storing at least one computer program for controlling the processing circuit to perform the aforementioned method. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Other aspects, features and advantages of the present technology will become apparent from the following description of examples, which description is to be read in conjunction with the accompanying drawings, in which:

[0007] Figure 1 An example of an information processing device having a non-volatile memory is schematically shown;

[0008] Figure 2A schematic diagram showing a method for installing software to be booted from a secure area of ​​non-volatile memory;

[0009] Figure 3 Another example of performing a method of installing another security module is shown;

[0010] Figure 4 is a flow chart showing a method of installing software; and

[0011] Figure 5 is a flow chart showing in more detail the steps for verifying target software. DETAILED DESCRIPTION

[0012] A device may have a non-volatile memory and access control circuitry for controlling access to the non-volatile memory based on region definition data that defines whether a given region is a less secure region or a more secure region. By dividing the non-volatile memory into less secure and more secure regions, access to the more secure region may be subject to greater access restrictions than access to the less secure region. However, in such a device, handling the installation of security software to be written to the more secure region of the non-volatile memory may be challenging.

[0013] One approach could be that any security software to be stored in a secure area of ​​non-volatile memory would need to be entered into the non-volatile memory by the original equipment manufacturer (OEM) that manufactures the device during the production process when full access is given to the device's memory map. In order to establish a root of trust on the device, no one after the initial manufacturer can have full memory access to the production device (including access rights to the secure area of ​​​​the memory that can be written). However, the problem with requiring the OEM to install all security software for the device is that this is extremely restrictive for the manufacturer. For example, the OEM may be dealing with many different batches of devices that may need different software installed, and this may result in more overhead in controlling the installation of individual pieces of software in the secure area of ​​​​each device and any verification / authentication steps to ensure that the installed software is trustworthy. This will also require any software developers to work directly with the microchip manufacturer to coordinate the software to be installed on a specific batch of devices, which may be undesirable.

[0014] Another approach may be to provide a dedicated serial port or some other communication channel through which the software can be delivered to a secure area of ​​the device's non-volatile memory after leaving the OEM. However, this may require dedicated tools or may require the device to include additional pins just for injecting the secure software, which may increase the cost of manufacturing the integrated circuit.

[0015] Another option could be that the code could be installed into a non-secure area of ​​non-volatile memory after leaving the OEM, and then that data could be copied into a secure area of ​​memory using dedicated software tools. However, it may be necessary to ensure that those dedicated software tools are not able to tamper with other secure code already installed in memory. This approach would therefore mean that different software installation tools would be required when installing secure software compared to non-secure software, which could increase the cost of developing devices designed to run secure software to be booted from a secure area of ​​non-volatile memory.

[0016] In the technology discussed below, a method for simplifying the installation of target software booted from a more secure area of ​​non-volatile memory is provided. This can enable non-secure software installation tools to be used to install the target software while still maintaining security. This is useful for reducing the development cost of the device, and is useful for both original equipment manufacturers (no longer responsible for installing all secure software on the device) and downstream manufacturers who need to provide secure software (without the need to use a dedicated installation tool dedicated to the installation of secure software). This is particularly important for devices to be used in the Internet of Things, which are relatively power-constrained and circuit-area-constrained, and the cost budget for each device may be too low, making it unlikely that manufacturers or software developers will be willing to spend a lot of resources on developing dedicated tools for handling secure software installation separate from existing non-secure tools.

[0017] In the method described below, target software that is ultimately required to be installed in a more secure area of ​​a non-volatile memory is initially installed into a target area defined by an area defining data as a less secure area. The target software to be installed may include not only program code to be executed according to the target software, but also associated data to be used by the target software.

[0018] Therefore, since the target software is initially installed in the less secure area, standard non-secure installation tools or software can be used. The target software is verified, and at least when the target software is successfully verified, and after the target software is installed in the less secure area, the area defining the data of the access control circuit of the device is updated to change the target area from the less secure area to the more secure area. Therefore, by changing the security state of the target area after the software has been installed in the target area, this enables the software to be placed in the secure memory without the need for a dedicated tool. Therefore, this method can eliminate the need to provide an additional dedicated secure installation tool to handle the installation of software for secure devices.

[0019] Verification of the target software can be performed under the control of the installer software. In one example, the installer software itself can be installed in a secure area of ​​non-volatile memory. This provides security because the less secure code cannot tamper with the installer software located in the more secure memory area.

[0020] Alternatively, the installer software may be stored in a less secure area of ​​non-volatile memory, but may be verified based on installer software verification information stored in a more secure area of ​​non-volatile memory. Thus, using this approach, the installer software may be securely installed into a less secure area of ​​memory (e.g., using a non-secure software installation tool), but some verification information may be embedded into a more secure area of ​​non-volatile memory (e.g., embedded at the time of manufacture), which may be used to check whether the installer software is suitable and may be reliably used to verify the target software to be installed. This approach may be useful for reducing the amount of secure storage that needs to be provided, and may help to utilize non-volatile memory capacity more efficiently overall, as the installer software may be downloaded on demand and installed into a non-secure area of ​​memory via a standard non-secure installation tool, and then overwritten when installation of the target software is complete if storage capacity in the non-secure area is needed for other purposes.

[0021] In one example, when the installer software is stored in a less secure area of ​​non-volatile memory, the installer software can be verified by the boot loader software installed in the more secure area of ​​non-volatile memory based on the hash value stored in the more secure area of ​​non-volatile memory. Whether to allow the update of the area definition data to change the definition of which areas are less secure or more secure can depend on the software requesting the update being verified by the boot loader software based on the hash value stored in the more secure area. This can ensure that only certain secure installation code that satisfies the known hash can request to change the boundary between the less secure area and the more secure area.

[0022] Although in some embodiments, the bootloader software may allow two or more optional forms of installer software corresponding to different hash values ​​to be directly verified by the bootloader software and / or trigger an update of the region definition data, it may be more secure if the bootloader software only allows one specific form of installer software to be verified and / or update the region definition data. Therefore, in some examples, the installer software may be the only software whose hash value is stored in a more secure area to be directly verified by the bootloader software (in the case where the installer software itself is directly verified by the bootloader software, any other software to be installed is verified by the installer software). Furthermore, in some examples, once the device has passed a certain stage of its manufacturing, the installer software that is verified by the bootloader software based on the hash value may be the only software allowed to trigger an update of the region definition data.

[0023] The region definition data may define the less secure and more secure regions in different ways. In some examples, the memory address space of the non-volatile memory may be divided into two, where addresses on one side of the boundary are considered more secure and addresses on the other side of the boundary are considered less secure. In this case, an update of the region definition data may simply be an update of the boundary address that marks the partition between the more secure and less secure regions.

[0024] In other examples, the memory address space of the non-volatile memory may be divided into a plurality of separate (possibly discontinuous) less secure and / or secure regions, wherein each region is defined by an arbitrary start and end address (or a start address and region size), the start and end addresses being defined by region definition data. In this case, updating of the region definition data may include changing parameters defining boundary addresses and / or sizes of certain regions, or changing security attributes controlling whether the address region is a more secure or less secure region.

[0025] In some implementations, the access control circuitry may support only two different types of security levels for regions of non-volatile memory. In this case, the more secure region may be a secure region, and the less secure region may be a non-secure region, wherein more access restrictions are imposed on the secure region than on the non-secure region.

[0026] Yet, in other examples, three or more security levels can be defined for a specific area of ​​the non-volatile memory as access permissions increase and decrease.In this case, the above-mentioned safer and less safer areas can simply be any two areas to which different security levels are applied.

[0027] Asymmetric cryptography (e.g., elliptic curve cryptography, etc.) can be used to authenticate the target software. This can provide higher security.

[0028] Verification can include verifying whether a cryptographic signature associated with the target software meets certain requirements. For example, the signature can cover a hash value derived as a function of the target software, and can also cover other parameters (e.g., the size parameter discussed below). The cryptographic signature can be verified based on a public key associated with a specific party that proves the authenticity of the target software. For example, the installer software can check whether the identity of the signer matches the known identities of one or more trusted parties that are allowed to guarantee the authenticity of the installed software. For example, a cryptographic signature can be derived from an information bundle associated with the target software (including a hash, a size parameter, or any other information) using a private key associated with the signer, and the verification of the signature can be based on the signer's public key, for example, checking whether the result of a signature verification function based on the public key applied to the signature matches the parameters covered by the signature (e.g., hash and size). Therefore, the installer software can check the identity of the party that proves the authenticity of the software before enabling the software installation.

[0029] As described above, a size parameter can be provided with the target software, which can indicate the size of the target software. For example, the size can be specified in bytes or in other units. The installer software can then use the size parameter to determine the extent to which the area definition data needs to be updated to change the target area from a less secure area to a more secure area. Therefore, the area definition data can be updated based on the size parameter. As described above, the size parameter can be verified based on the cryptographic signature associated with the target software to control malicious parties who request to install the software and then request that the size parameter is actually much larger than the size of the target software being installed, otherwise additional information in the less secure area of ​​the non-volatile memory may become more secure, which may lead to security vulnerabilities. Therefore, by proving the authenticity of the size parameter based on the signature, the trust in correctly configuring the device during the installation process of booting the target software from the newly created more secure area of ​​the non-volatile memory can be increased.

[0030] Verification of the target software may be performed before updating the area definition data, after updating the area definition data, or both before and after updating the area definition data.

[0031] Thus, in some examples, verification may be performed first, and if verification is unsuccessful, the region definition data is not updated, and thus the target region will still be designated as a less secure region of the address space of the non-volatile memory.

[0032] However, in other examples, the zone definition data may be updated to change the target zone from a less secure zone to a more secure zone, regardless of whether verification of the target software is successful. The target software may then be verified after the zone definition data is updated, and in the event that verification at this point is deemed unsuccessful, the method may include changing the target zone from a more secure zone back to a less secure zone, and preventing execution of software from the target zone. Preventing execution of software from the target zone may be accomplished in different ways, such as by erasing data and code from the target zone, or by setting a control flag that prevents booting or execution from the target zone.

[0033] In other examples, the target software may be verified before and after updating the zone definition data. It may be useful to provide a two-step verification process so that an initial verification step is performed before any updates to the zone definition data are allowed to avoid any changes to the zone definition data without being able to verify the target software, but then a second verification step may be performed after the zone definition data is updated to check that no modifications were made during the process for importing the target software, which could otherwise affect security.

[0034] Therefore, it should be understood that verification of the target software before updating the area definition data is not essential, as the verification can also be performed afterwards. Similarly, verification after updating the area definition data (if it has been done before) is also not essential. However, both can be separate or combined.

[0035] In one example, when the target software is installed in a less secure area, the target software may be associated with a verification indicator set to a first value. When the verification of the target software is successful and the area definition data is updated to define the target area as a safer area, the verification indicator may be updated to a second value (e.g., under the control of the installer software or the boot loader software). When the verification indicator has a first value, the execution of the target software may be prohibited. For example, prohibiting the execution of the target software may be achieved by completely prohibiting the booting of the target software (e.g., prohibiting the target software from being copied from a non-volatile memory to a random access memory (RAM) from which the processing circuit can execute the software); or allowing the software to be booted from a non-volatile memory to an area of ​​the RAM, but then prohibiting execution from the area of ​​the RAM. Therefore, generally, by providing a flag that can be used to control whether the software can be executed, and preventing the flag from being set to a second value until the following two: (i) the verification is successful and (ii) the area definition data has been updated to define the target area as a safer area, the inappropriate execution of potentially sensitive software is prevented in the case where the software has not been verified to be authentic, or appropriate security protection has not been set for the target area containing the software by updating the area definition data.

[0036] In one example, access to at least one less secure area may be prohibited during at least one of the following: a verification process for verifying the target software; and a zone update process for updating the zone definition data to change the target area from a less secure area to a more secure area. This may prevent other less secure code executed on the device from being able to access the installed target software until the software installation is complete (at which point the zone definition data will update the zone definition data to mark the target area as more secure). In addition, during one or both of the verification process and the zone update process, debug access to non-volatile memory may be prohibited. This prevents non-secure access to non-volatile memory from obtaining improper access to potentially sensitive code and data of the target software during the installation process.

[0037] The non-volatile memory may be implemented using a variety of memory technologies (eg, magnetoresistive RAM, ferroelectric RAM, or read-only memory). However, in one example, the non-volatile memory may be flash memory.

[0038] Figure 1 An example of an information processing device 2 is schematically shown. The device 2 includes a processing circuit 4 (e.g., a processor core or a cluster of cores) for performing data processing and a memory access control circuit 6 for controlling access to a region of a memory address space accessible to the processing circuit 4. The address space may be mapped onto a plurality of memory devices, including a random access memory 8 (RAM, such as RAM implemented using volatile memory technology (e.g., DRAM)) and a non-volatile memory 10 (e.g., flash memory or other types of non-volatile memory as described above). Persistent data and software code that is retained even when the device is not powered on may be stored in the non-volatile memory 10. When the device is powered on, the boot loader code may control the booting (copying) of the software and data processed by the processing circuit 4 into the RAM 8, and the software may then be executed with reference to the copy of the software stored in the RAM. Although Figure 1 A single shared memory access controller 6 is shown that controls access to both the RAM 8 and the non-volatile memory 10, but in other examples separate access control units may be provided for the two types of memory.

[0039] The memory access controller 6 may define region definition data 7 that defines regions of the RAM 8 and non-volatile memory 10 as secure regions or less secure regions. Memory access (reading or writing) to those regions designated as more secure regions may be subject to greater access restrictions than access to less secure regions. For example, when operating in a secure operating state, the processing circuit 4 may be allowed to access only certain more secure regions of the memory 8, 10. The transitions between secure and less secure operating states of the processing circuit 4 may be carefully controlled. For example, the processing circuit 4 may have, for example, a processor based on a processor developed by Cambridge, England. Provided by Co., Ltd. The hardware architecture that regulates secure / less secure boundaries. Region definition data that identifies regions of memory as secure or less secure may be defined in different ways, such as using entries that each correspond to a region of variable size that specifies the start and end addresses of the region (using two separate boundary addresses, or using a single boundary address and a size parameter) and an attribute indicating whether the region is less secure or more secure. Optionally, in other implementations, the region definition data 7 may include only one or more boundary addresses, where the boundary address marks the point at which the security state changes (for example, in a system with only two security states, a single boundary address may mark the division between secure / non-secure memory; or in a system with three or more security states, there may be two or more boundary addresses).

[0040] The device 2 may also include other components that can communicate with the processing circuit 4 via the bus network 12. For example, these components may include a display 14 for displaying information to a user, a user input unit 16 for accepting user input (e.g., buttons, keyboards, touch screens or other forms of user interfaces), and a communication protocol (e.g., A communication interface 18 for performing wired or wireless communication with external devices (e.g., a temperature sensor, a pressure sensor, a light sensor, etc.), and one or more sensors 20 for sensing parameters associated with the device or its surroundings (e.g., a temperature sensor, a pressure sensor, a light sensor, etc.). It should be understood that the particular set of circuit elements provided in the device may depend on the particular purpose for which the device is intended. Not all implementations of the device 2 need have Figure 1All elements 14, 16, 18, 20 shown in . For example, in some relatively simple Internet of Things type devices, there may be no need for interaction with a local user at the physical location of the device, and therefore there may be no need to provide a display 14 and / or a user input module 16. Instead, such a device may act as a sensor, use its sensor 20 to record data, process the sensed data, and then communicate these results to an external device via the communication interface 18. Other devices may need to interact with a user, and therefore may require a display 14 or a user input interface 16, but may not necessarily require a sensor 20. Therefore, the specific configuration of a device may vary greatly and may include other Figure 1 Elements not shown.

[0041] Figure 2 A method for installing target software into the non-volatile memory 10 of the device 2 is schematically shown. Figure 2 In the first part, the non-volatile memory 10 can be divided into one or more non-security areas 30 and one or more security areas 32, which are defined by the area definition data of the memory access control unit 6. Similarly, the RAM 8 can also be divided into a security area 34 and a non-security area 35. For simplicity, Figure 2 In the figure, the figure simply shows a single boundary between the secure area and the non-secure area in both RAM8 and non-volatile memory 10, but it should be understood that multiple discontinuous areas of a given security level can also be defined within RAM 8 or non-volatile memory 10.

[0042] Typically, a device will need to install its software into a secure area of ​​non-volatile memory at some point in its lifecycle (e.g., at the manufacturing site or in a post-processing step). However, there may be challenges in handling the installation of secure code that resides in the secure area 32 of non-volatile memory at boot time (copied into RAM 8 for execution by processing circuit 4). Typically, an OEM can install software in production via JTAG or some other means when the OEM has full access to the memory map of the device. However, in order to establish a root of trust on the device, no one after the initial manufacturer can have full memory access to the production device. This means that if the software is to be installed in the secure area 32 after manufacturing, it may be necessary to create and use dedicated tools to install the software, which requires a different process than using a non-secure device.

[0043] use Figure 2This problem can be avoided by the method shown in , which enables existing production non-secure flash tools to install secure software directly into non-secure memory and change the security state of this memory area once verification is complete, thereby eliminating the need for any additional tools for flashing secure devices in a production environment. This can reduce the development cost of data processing devices, which may be particularly useful in the field of Internet of Things, where the low cost per device may be such that the expense of developing dedicated tools for secure software installation may not be considered justified.

[0044] Figure 2 An example of a method is shown as follows. As shown in Part 1, the device 2 is initially created with the memory space in the non-volatile memory 10 relatively empty, except for the boot loader code BL1 and any persistent data installed in the secure area 32 (in this example, which may be located in the less secure area 30). The installation of the boot loader code and persistent data may have been completed by the OEM at the factory. The boot loader code BL1 may include a hash value 36 that corresponds to a value derived as a function of the code / data of the secure installer 38, which is trusted to manage the installation of other security software. As part of the boot loader code BL1, the secure installer hash value 36 is stored (by the OEM at the manufacturing stage) within the secure area 32 of the non-volatile memory.

[0045] After the device leaves the OEM, if it is subsequently desired to install specific blocks of the target software into secure storage, then Figure 2 As shown in part 2 of the present invention, a standard off-the-shelf non-secure flash tool can be used to write an image 40 of the target software into the less secure area 30 of the non-volatile memory 10. The addresses where the target image 40 is installed can be the same addresses that will eventually become the secure area intended to contain the target software. However, when the target image is written to the non-volatile memory 10, these addresses are defined as less secure areas in the area definition data 7 of the memory access controller 6.

[0046] Additionally, a secure installer 38 is installed into the less secure area 30 of the non-volatile memory 10. Again, standard off-the-shelf non-secure flash tools may be used for this. The secure installer may be written to any address other than the area containing the target image 40, but it may be useful to place a temporary installer in an area where non-secure software will eventually be placed, as this allows reuse of that area after installation of the target software 40 is complete. The secure installer 38 should be software that matches the secure installer hash 36 maintained by the boot loader BL1.

[0047] In addition, the non-secure flash tool also writes a signed hash of the target software image 40 to be installed to the non-secure area 30 of the non-volatile memory 10. That is, the non-volatile memory is written with a hash value 42 that defines the expected result of applying a particular hash function to the contents of the target image 40. The hash value 42 and any other parameters associated with the target software (e.g., a size parameter that defines the size of the target software) are signed by a trusted party that certifies the authenticity of the software to generate a signature 44 (which is performed offline when the information bundle to be provided for installing the image 40 is generated). The signature 44 is provided to the device along with the software image 40 and can be used to check the authenticity of the hash 42 and any other parameters (e.g., size). These can be used during verification of the target software image 40, as described below.

[0048] As shown in section 3, when the device is booted, the device (under control of the boot loader BL1) detects the new image in the non-secure memory and imports the secure installer 38 into the secure area 34 of RAM 8. In addition, the signature hashes 42, 44 are imported into the secure RAM. The boot loader code may also be imported into RAM, and the boot loader exports a hash as a function of the code and data associated with the secure installer 38, and checks whether the exported hash matches the secure installer hash 36 stored in the secure area of ​​non-volatile memory. If there is a mismatch between the expected hash 36 and the actual exported hash of the secure installer, the process may be terminated to prevent the target image from being installed.

[0049] If the secure installer 38 is successfully verified, the secure installer is allowed to execute, and then the secure installer uses the target software hash 42 and the signature 44 to verify the target software 40 to be installed. For example, the secure installer 38 calculates a hash value as a function of the target image 40 in the non-secure area 30 of the non-volatile memory, and compares the calculated hash with the expected hash 42 to detect whether they match. If not, the process can be terminated again. In addition, the secure installer 38 checks whether the signature 44 can be verified based on some information associated with the trusted party that proves the authenticity of the software. For example, the secure installer 38 can obtain one or more public keys associated with one or more trusted entities, and check whether the signature 44 that has been provided to the target software 40 can be authenticated based on any of these public keys. For example, the signature 44 can correspond to the result of encrypting one or more values ​​(e.g., hash and size parameters) using the private key of the trusted entity, and the secure installer 38 can check whether decrypting the signature 44 using the public key of the trusted entity matches the hash value 42 and size parameter provided for the secure software. Thus, verification may include verifying the content and related parameters of the software 40 to be installed (eg, its size parameters), and also verifying the identity of the party providing the software.

[0050] like Figure 2 As shown in steps 3 and 4 of , if the verification of the security installation program 38 and the target software 40 are both successful, the secure / non-secure boundary is adjusted so that the target area containing the target software 40 now becomes the more secure area 32 of the non-volatile memory. For example, one or more boundary addresses or security attributes in the area definition data 7 can be updated to change the security state of the address in the target area of ​​the memory where the target software 40 is installed. The size parameter can indicate the size of the area to be designated as secure, and the change in the area definition data 7 can be controlled based on the size parameter (for example, the boundary between the secure / non-secure area can be moved by an amount corresponding to the size parameter). Therefore, the secure image associated with the target software 40 now resides in the secure area of ​​the non-volatile memory.

[0051] like Figure 2As shown in Section 4 of , optionally, the secure installer 38 can then be loaded and run again to repeat the verification of the secure image 40 before deciding whether to accept the new image or reject the new image by erasing the new image or otherwise preventing subsequent execution of the target software 40, but now with the new security boundary in place. This post-update verification can be optional, and in other examples, the verification can be performed only before updating the area definition data. Optionally, other methods can omit the pre-boundary adjustment verification and perform the adjustment only after the boundary has been adjusted. However, by either way of performing a verification of the hash of the secure image, this can check that only the desired software is allowed to be installed into the secure memory (and / or only software provided by certain trusted parties is installed into the secure memory).

[0052] like Figure 2 As shown in Section 5 of , the device can then be booted with the new secure / non-secure layout and the newly input secure image 40 in place to enable execution of the software corresponding to the secure image 40.

[0053] like Figure 3 As shown, after the previous security image 40 has been installed, the same method can then be performed again to install additional security modules 48. Again, this can be done in the same way as Figure 2 In a similar manner as discussed in Figure 3 In the embodiment of the present invention, if some non-secure application or data is provided in the location already occupied by the secure installer 38, hash 42 or signature 44 in the non-volatile memory, the data can be temporarily erased before step 2 and then reinstalled in step 5 once the installation is complete (for example, by downloading the information again or restoring the data from a backup storage device).

[0054] In some examples, the security software 40 may be associated with an enable flag that serves as an indicator of whether the software can be executed. For example, when the security image 40 is written to the non-volatile memory, the flag may be initially written in a first state (0 or 1), and the verification of the hash 42 may depend on the indicator being in the first state. When the area definition data has been updated to adjust the boundary between the secure and non-secure areas and any verification required has been completed, the verification indicator associated with the target software may then be flipped to indicate a second state (e.g., the opposite of 0 and 1). A secure boot loader code BL1 may be arranged that may be loaded first when the device boots and may control the subsequent booting of other code, so that any software from the secure area of ​​the non-volatile memory may be prevented from being booted and copied to the RAM 8 when the corresponding enable flag is still in the first state. Therefore, in the case where the software has not been verified or the software is still in the less secure memory because the installation process has not been completed, the system may refuse to boot the image installed in the secure area of ​​the RAM.

[0055] Thus, using the above method, the main boot loader (e.g., boot loader BL1) provides security enforcement by maintaining control of the CPU until additional software is loaded, thereby allowing only specific software to be added before then (security installer 38 corresponding to hash 36). The security installer 38 uses asymmetric cryptography to verify that the new software 40 comes from a trusted source and rejects it if it is not. The boot loader BL1, security installer 38, or other operating system components use built-in hardware on the device (e.g., access control unit 6) to adjust the boundaries of the secure area of ​​​​memory under security control only during the boot process. The boot loader or operating system component prohibits any non-secure or debug access during the verification process and during the modification of the secure area parameters. Optionally, a two-step verification process can be performed, in which verification is performed before and after the modification of the secure area is performed, which can be used to ensure that the image has not been modified during the import process.

[0056] Figure 4A flow chart illustrating a method for controlling the installation of software is shown. At step 100, a non-secure flash tool (which may be the same tool used to install non-secure software into a non-secure area of ​​non-volatile memory 10) installs a secure installer 38, a target software image 40, and a hash 42 (signed by a signature 44) in a non-secure area of ​​non-volatile memory 10. At step 102, the secure installer 38 is booted into RAM 8, and the boot loader BL1 verifies the installer 28 based on the hash value 36 stored in the secure area 32 of non-volatile memory 10. That is, the boot loader can compare the function derived from the code and data of the secure installer 38 with the stored secure hash value 36, and if these values ​​do not match, it is determined that the verification is unsuccessful. At step 104, the boot loader determines whether the installer 38 has been successfully verified, and if not, then at step 105, the installation of the target software is denied, for example by preventing the execution of the secure installer 38.

[0057] If the installer is successfully verified, then at step 106, the installer is executed and the installer 38 verifies whether the target software 40 is acceptable for installation. This verification is based on the hash value 42 and the signature 44, and the reference Figure 5 In step 108, the secure installer 38 determines whether the verification is successful, and if not, in step 105, the installation of the target software is again denied (eg, by erasing the area where the target software is installed or by preventing execution of code booted from that area).

[0058] If the verification of the target software 40 is successful, then at step 110, the area definition data 7 is updated so that the target area where the target software 40 is installed is now a more secure area of ​​the non-volatile memory 10. Figure 5 As discussed, at step 112, a second verification step may be performed similar to step 106. At step 114, the security installer 38 again determines whether the verification is successful. If the verification is successful, then at step 116, the change in the zone definition data from step 110 may be accepted, and at step 118, the verification indicator associated with the target software may be switched from the first value to the second value. Code execution from the target software may be limited to the case where the verification indicator has the second value. The verification indicator may be initially set to the first value when the software is installed at step 100, and if a party attempts to install the code when the verification indicator already has the second value, the verification performed at steps 106 and 112 may not be successful (because in this case, the installed code will not match the expected hash 42, or if the attacker tampered with the hash 42, because in this case, the signature of the hash 42 will not be verified based on the public key of the trusted party).

[0059] If it is determined in step 114 that the verification after the update is unsuccessful, then in step 120 the changes to the zone definition data performed in step 110 are reversed, and in step 122 the data from the target zone is erased, otherwise code execution from the target zone is blocked (for example, because the verification indicator has not changed from the first value), and then in step 105 the installation of the target software is again denied.

[0060] Figure 4 An example is shown in which there are two verification steps, one at step 106 and the other at step 112. In other examples, there may be no second step of verifying the target software after the region definition data is updated, and in this case, the method may proceed directly from step 110 to step 116, omitting steps 112, 114, 120, 122. Alternatively, steps 106 and 108 may be omitted, and in this case, only verification may be performed at step 112, and in this case, the method may proceed directly from step 104 to step 110.

[0061] Figure 5 is a flow chart illustrating verification at step 106 or 112. At step 150, the secure installer checks whether the value derived as a function of the target software image 40 matches the hash value 42 installed in the non-secure portion of the non-volatile memory together with the target image 40. Furthermore, at step 152, the secure installer checks whether a signature 44 associated with the target software can be verified, which signature 44 may cover the hash 42 and the size parameter (and optionally other parameters), based on information defining a trusted entity (that is allowed to attest to the authenticity of the hash).

[0062] If either of steps 150 or 152 determine that the hash or signature does not meet the expected requirements, then at step 154, it is determined that the verification was unsuccessful. If the hashes match and the signature can be successfully verified, then at step 156, the verification is successful. Thus, these checks enable the installer to check that the change to the secure / unsecure boundary as represented by the size parameter is as expected by the party signing the hash, and if it can be checked and the identity of the signing party (e.g., based on public key information from an asymmetric cryptography scheme) and the hash match, then the verification is successful and the installation can be allowed to proceed. The size parameter covered by the signature can be a parameter that controls the zone definition data to be updated at step 110.

[0063] It is not necessary to use hash 42 for verification of the target software. In other examples, signature 44 may be derived directly from target software image 40 rather than a hash of the image, and verification of the target software may simply include verifying that the signature is authentic based on the signer's public key. In this case, signature 44 may be omitted. Figure 5 Step 150 of , and in step 152, the signature may be based on the entire target image rather than the hash. However, using a hash to check the signature can make signature verification more efficient because it means that less data needs to be compared with the signature when performing verification.

[0064] In this application, the phrase "configured to ..." is used to mean that an element of a device has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to the arrangement or manner of interconnection of hardware or software. For example, a device may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device elements need to be changed in any way in order to provide the defined operation.

[0065] Although exemplary embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it should be understood that the present invention is not limited to these precise embodiments and that various changes and modifications may be made therein by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims.

Claims

1. A method for installing software for a device, the device comprising a non-volatile memory and an access control circuit, the access control circuit being used to control access to the non-volatile memory based on region definition data, the region definition data defining whether a given region of the non-volatile memory is a less secure region or a more secure region, wherein: The access control circuit is configured to impose greater restrictions on access to more secure areas than on access to less secure areas; the method comprising: installing target software in a target area of ​​the nonvolatile memory defined as a less secure area by the area definition data; verifying the target software; and at least when verification of the target software is successful, and after the target software is installed, updating the zone definition data to change the target zone from a less secure zone to a more secure zone, wherein the target software is verified under control of installer software, wherein at least one of the installer software and installer software verification information for verifying the installer software is stored in a more secure area of ​​the nonvolatile memory.

2. The method according to claim 1, wherein: The installer software is installed in a less secure area of ​​the non-volatile memory, and Updates to the zone definition data are dependent upon the installer software being authenticated by boot loader software installed in the more secure zone based on a hash value stored in the more secure zone.

3. The method according to claim 2, wherein: Include at least one of the following: The installer software is the only software whose hash value is stored in the more secure area so as to be directly verifiable by the boot loader software; as well as The installer software verified by the boot loader software based on the hash value is the only software allowed to trigger an update of the zone definition data associated with the target zone in which the target software is installed.

4. A method according to any one of the preceding claims, wherein: The target software is authenticated using asymmetric cryptography.

5. The method according to any one of claims 1 to 3, wherein: Verifying the target software includes verifying a cryptographic signature associated with the target software.

6. The method according to any one of claims 1 to 3, wherein: When verification of the target software succeeds, the area definition data is updated based on a size parameter indicating a size of the target software.

7. The method according to claim 6, wherein: The size parameter is verified based on a cryptographic signature associated with the target software.

8. The method according to any one of claims 1 to 3, wherein: The target software is verified before updating the zone definition data.

9. The method according to claim 1, wherein: The target software is verified after the zone definition data is updated.

10. The method according to claim 1, wherein: The target software is verified both before and after updating the zone definition data.

11. The method according to any one of claims 9 and 10, wherein: When it is determined that verification of the target software is unsuccessful after updating the area definition data, the method includes: changing the target area from a safer area to a less safe area; and Execution of software from the target zone is blocked.

12. The method according to any one of claims 1 to 3, wherein: When the target software is installed in the less secure area, the target software is associated with a verification indicator that is set to a first value; When verification of the target software succeeds and the region definition data is updated to define the target region as a safer region, the verification indicator is updated to a second value; as well as When the verification indicator has the first value, execution of the target software is prohibited.

13. The method according to any one of claims 1 to 3, wherein: Access to the less secure area is prohibited during at least one of the following: A verification process for verifying the target software; as well as A zone update process is used to update the zone definition data to change the target zone from a less safe zone to a safer zone.

14. The method according to any one of claims 1 to 3, wherein: Debug access to the non-volatile memory is prohibited during at least one of the following: A verification process for verifying the target software; and a region update process for updating the region definition data to change the target region from a less secure region to a more secure region.

15. The method according to any one of claims 1 to 3, wherein: The non-volatile memory includes flash memory. 16 . A storage medium for storing at least one computer program, wherein the at least one computer program is used to control a device to execute the method according to claim 1 .

17. An information processing device, comprising: processing circuitry for performing data processing; as well as A data storage device storing at least one computer program, wherein the at least one computer program is used to control the processing circuit to execute the method according to any one of claims 1 to 15.

Images