Conceptio › Archive › Google Patents

Google Patentsopen access

Software encryption — Trustonic Limited (US11218299B2)

Trustonic Limited · Google Patents

Google Patents · Patents · License: Open Access

patent, google patents, intellectual property, US11218299B2, Trustonic Limited, Lukas HANEL, en, 2022

ABSTRACT

Abstract

A software decryption key is injected into a computing device 2 having a secure execution environment 20 and a less secure execution environment 22. The key 38 is for decryption of software to be run on the computing device. A key injection software component 36 executed within the secure execution environment 20 is used to control storage of the software decryption key 38 in a protected state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment 22 of the computing device. Software provided to the device is decrypted based on the injected software decryption key 38.

Description

This application claims priority to GB Patent Application No. 1901596.5 filed 5 Feb. 2019, the entire contents of which is hereby incorporated by reference.

The present technique relates to the field of computing devices.

A computing device may be vulnerable to hackers who may use code vulnerabilities in device firmware or in the entire software stack installed on a given computing device to mount malicious attacks. To do so, the hacker may extract the raw software binary from a device and apply reverse engineering techniques to understand the software's content and possible vulnerabilities. To prevent reverse engineering of software on a device, the software may be stored locally in an encrypted form as well as being distributed in an encrypted form during over the air updates. This can reduce the opportunity for the attacker to be able to identify code vulnerabilities. However, when software encryption is used then this creates challenges in management of the decryption key for decrypting the software.

At least some examples provide a key injection method for a computing device having a secure execution environment and a less secure execution environment, wherein program code or data associated with the secure execution environment is isolated from access by program code executed in the less secure execution environment; the method comprising: providing a software decryption key for decryption of software to be run on the computing device, wherein the software decryption key is a class key shared between a class of devices including said computing device; using a key injection software component executed within the secure execution environment of the computing device, controlling storage of the software decryption key in a protected state in a key storage location accessible to the computing device; the protected state comprising a state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment of the computing device.

At least some examples provide a method for a computing device having a secure execution environment and a less secure execution environment, wherein program code or data associated with the secure execution environment is isolated from access by program code executed in the less secure execution environment; the method comprising: using a control software component running within the secure execution environment: obtaining a software decryption key stored in a key storage location in a protected state, the protected state comprising a state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment of the computing device; and using the obtained software decryption key, decrypting target software to be run on the computing device; wherein the software decryption key is a class key shared between a class of devices including said computing device.

At least some examples provide a method for providing an over-the-air update for target software to be run on a given class of computing devices; the method comprising: using a class key shared between said given class of computing devices, encrypting updated software for said target software; providing a control portion comprising at least: an encryption status indication indicating that the updated software requires decryption; and a key identifier for identifying the class key used to encrypt the updated software; and making a software update package available to the given class of computing devices, the software update package including the encrypted updated software and the control portion.

At least some examples may provide at least one computer program to control the device to perform the method of any of the examples discussed above. At least one storage medium may store the at least one computer program. The storage medium may be a non-transitory or a transitory storage medium.

At least some examples provide an apparatus comprising processing circuitry to perform data processing and data storage storing at least one computer program for controlling the processing circuitry to perform the method of any of the examples discussed above.

Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

FIG. 1 schematically illustrates an example of a computing device;

FIG. 2 illustrates a secure execution environment and a less secure execution environment;

FIG. 3 illustrates key injection of a class key to be used for decrypting software on the device;

FIG. 4 illustrates a method of injection of the key;

FIG. 5 illustrates a software update package including encrypted program code or data;

FIG. 6 shows examples of encryption parameters for controlling decryption of the software;

FIG. 7 shows a method for providing an over-the-air update for target software to be run on a given class of computing devices;

FIG. 8 shows decryption of software on the device; and

FIG. 9 shows a method of controlling decryption of the software.

A technical challenge in implementing software encryption lies in management of the software decryption key to be used to decrypt the encrypted software to be run on a computing device. The device will need a key to be able to decrypt the software, but where does it obtain the key from, and how is this key shared between the party providing the software and the device itself, while maintaining security? Another consideration is that production time is a critical factor in the production line for producing computing devices cost effectively, so it is desirable that the measures introduced for provision of the key do not incur too much additional complexity during the production line.

In the key injection method described below, a key is injected into a computing device which has a secure execution environment and a less secure execution environment, where program code or data associated with the secure execution environment is isolated from access by program code executed in the less secure execution environment. A software decryption key is provided, for decrypting software to be run on the computing device, where the software decryption key is a class key which is shared between a class of devices including the computing device. A key injection software component executed within the secure execution environment of the computing device is used to control storage of the software decryption key in a protected state in a key storage location accessible to a computing device. The protected state is a state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment of the computing device.

This approach has several advantages. By using a class key as the software decryption key, which is shared between the devices of a given class, the same software binary can be provided to each of the devices of the class and there is no need to provide targeted software packages which are bespoke to each device. This makes over-the-air updates much more efficient for a software provider. Also, this makes the production line more efficient as the key injection mechanism can inject the same key for each device on the production line, and there is no need to incur extra overhead in secure management and distribution of individual software decryption keys per device.

Also, by using a key injection software component executed within the secure execution environment of the computing device to control the storage of the software decryption key in a protected state, this makes the method suitable for being performed by an original equipment manufacturer (OEM) who may be producing a class of computing devices which include devices made with integrated circuits or system-on-chips provided by two or more different chip manufacturers, as it means that the software decryption key used for each device can be independent of the particular chip manufacturer who manufactured the system-on-chip of that device.

An alternative would be that the chip manufacturer manufactures the integrated circuit to include a hardware element which securely retains the software decryption key, which is built into the chip hardware during manufacture of the integrated circuit itself. However, with this approach, either the software decryption key would need to be different for devices using integrated circuits manufactured by different manufacturers, or there would need to be communication of a common key between the OEM and the chip manufacturers. If different chip manufacturers embed different keys, this would complicate distribution of over-the-air software updates as different update packages would be needed for each set of devices based on an integrated circuit from a different chip manufacturer. If an OEM had to share a common key with each chip supplier (either by the OEM transmitting the key to the chip supplier, or with the chip supplier supplying the key to the OEM), so that a class of devices including system-on-chips (SoCs) manufactured by different chip manufacturers could all share the same software decryption key to make subsequent over-the-air updates more efficient, this sharing of the key between the OEM and the chip supplier may provide an avenue for a hacker to intercept the key and in any case this may complicate the production line at the chip supplier, where a batch of chips being manufactured may need to be injected with different keys supplied by different OEMs, again increasing the cost of manufacturing the device. In general, the cost of manufacture increases if the production line needs to provide bespoke keys for a number of subsets of devices within a given batch, as compared to providing the same key for all devices in the batch. Especially for lower cost devices such as personal fitness watches, low cost sensors, or other relatively power-constrained or area-constrained devices such as those proposed for use in the Internet of Things, such increased production costs may not be justified making it difficult to efficiently support software encryption on such devices.

Another approach would be that fuses built into the system-on-chip by the chip manufacturer may be programmed by the OEM to inject a key into the secure hardware. However, a problem with this approach is that such fuses typically have very little storage capacity, and often this capacity is already used for other purposes. Also, the particular steps needed to program the fuses may be different per SoC design, again creating a fragmentation of the OEM manufacturing process and hence higher integration cost than may be justified for some types of device.

Instead, by using a key injection software component executed within the secure execution environment of the computing device, this avoids the need for specific keys to be embedded in the SoC by the chip supplier, thus enabling an OEM (who is integrating the SoC with other components to form a computing device) to perform key injection while sharing the same key between a class of devices, which may include devices based on SoCs supplied by different chip manufacturers. This approach also makes the key injection method more suitable for environments where the chip manufacturer and the party providing software for execution on the computing device are different operators, rather than a single party having control over a closed system including both the underlying integrated circuit and the software stack executing on the device.

The software decryption key is stored in the key storage location in a protected state which protects the key against access by an external device or by program code executed in the less secure execution environment. This protected state can be implemented in different ways.

In one example, the protected state is a state in which the software decryption key is encrypted based on a device key which is private to the computing device and is inaccessible to the program code executed in the less secure execution environment. For example, the device key could be a key embedded in the integrated circuit design by the chip manufacturer during manufacture of the system on chip. Unlike the software decryption key, the device key does not need to be known outside the device because it will not be used for encryption of the software itself by the software supplier. Instead the device key is used for protection of the software decryption key once the software decryption key has been injected. The decryption of the software decryption key using the device key may be controlled by a component running in the secure execution environment to the device, to protect against interception of the unencrypted software decryption key by an external device or by potentially insecure software executing on the device in the less secure execution environment. The device key could be used directly as the decryption key for decrypting the software decryption key, or a further key derived from the device key could be used to decrypt the software decryption key.

With this approach, it is not necessary for the key storage location to be a location which is inaccessible to the external device or to program code executing the less secure execution environment. As the software decryption key is protected by encryption based on the device key, the software decryption key can be stored in the encrypted form within a potentially insecure storage location, such as a region of memory of the computing device which is accessible to less secure code executing in the less secure execution environment, or an external storage location such as an unprotected flash memory or a hard drive or in a remote location accessible in the cloud from the computing device via a network. The provision of a two-level key structure with a device private key being used to protect a class key used as a software decryption key, and the software decryption key being used to decrypt software to be run on the device, enables a better balance between security and ease of manufacture on the production line for the reasons discussed above.

Alternatively, another way of implementing the protected state may be that the software decryption key is stored in a storage region which is accessible to program code executed in the secure execution environment, but inaccessible to an external device or to program code executed in the less secure execution environment. Hence, with this approach it is possible to store the software decryption key in the clear as it is not possible for code other than code executed within the secure execution environment to access the key. For example with this approach the storage location could be a region of non-volatile memory isolated for access by the secure execution environment. For example, some hardware processor architectures may have features designed for policing accesses to non-volatile memory so as to prevent access to designated secure regions of non-volatile memory by code executing in the less secure execution environment.

This application claims priority to GB Patent Application No. 1901596.5 filed 5 Feb. 2019, the entire contents of which is hereby incorporated by reference.

The present technique relates to the field of computing devices.

FIG. 1 schematically illustrates an example of a computing device;

FIG. 2 illustrates a secure execution environment and a less secure execution environment;

FIG. 3 illustrates key injection of a class key to be used for decrypting software on the device;

FIG. 4 illustrates a method of injection of the key;

FIG. 5 illustrates a software update package including encrypted program code or data;

FIG. 6 shows examples of encryption parameters for controlling decryption of the software;

FIG. 7 shows a method for providing an over-the-air update for target software to be run on a given class of computing devices;

FIG. 8 shows decryption of software on the device; and

FIG. 9 shows a method of controlling decryption of the software.

When the software decryption key is stored in the protected state, the software decryption key may be unreadable in the clear by a software component other than a predetermined control software component of the secure execution environment and the key injection software component. For example, the computing device may support storage of secure objects which are stored in association with an identifier of a particular software component which is allowed to read or decrypt the secure object. This identifier may be set such that only the predetermined control software component or the key injection software component is able to read the software decryption key in the clear. In some implementations, the key injection software component itself may also be unable to read the software decryption key in the clear once it is has been stored to the key storage location. For example the key injection software component may be able to perform the encryption of the software decryption key based on the device key, but may be unable to decrypt the encrypted key. This provides added security as it means that software components executing the secure execution environment other than the predetermined control software component cannot obtain the key in the clear. The predetermined control software component could for example be a part of a trusted operating system for managing trusted applications running in the secure execution environment.

As mentioned above, the key injection method may be performed by an original equipment manufacturer (OEM) of the computer device, where the computing device comprises a system-on-chip manufactured by a different manufacturer to the OEM. The software decryption key may be independent of the manufacturer of the system-on-chip. Hence even if the OEM is manufacturing computing devices with SoCs provided by two or more different chip manufacturers, the same software decryption key can be used for each of those devices. The key injection method may be performed within a secure or trusted environment, such as the factory of the OEM. Alternatively, even if the OEM desires that devices with SoCs provided by different chip manufacturers should have different software decryption keys, an advantage of the key injection method described above is that the key selected for each class of device can be selected independent of the chip manufacturer, and does not need to be shared with the chip manufacturer, which improves security.

When the computing device, with the software decryption key injected in it, is released for in-field use, an in-field software image provided on the computing device at the point of release for in-field use may exclude the key injection software component. Hence, as the key injection software component may only appear in the factory software image installed on the device within the factory and the key injection software component is removed prior to release for in-field use, this prevents further software decryption keys being injected after the device is being released into the field, and may prevent existing software decryption keys being overwritten by the key injection software component. This helps to maintain security of encrypted software.

Alternatively, another way of preventing injected keys being manipulated may be that the key injection software component may be prohibited from overwriting a previously injected software decryption key. With this approach it may still be possible for the key injection software component to be included in the in-field software image, as even if it was subsequently executed once the device is in the field, any previously injected software decryption keys would be unaffected and so can still be used to protect subsequent over-the-air software updates.

The software decryption key may be stored in the protected state in association with a key identifier which distinguishes the software decryption key from other software decryption keys. This enables different keys to be used to protect different pieces of software to be installed on the same device. This can improve security, for example when different parts of the software on the device are to be provided by different software suppliers, in which case it may be undesirable to share the same software decryption key among each of those software suppliers. Even if all the software to be protected by encryption comes from the same supplier, it may still be desirable to support multiple different keys to reduce the vulnerability of attack by limiting which parts of the software would be exposed if any individual key is leaked. Hence, in some examples two or more software decryption keys can be injected, associated with different key identifiers, each stored in the protected state under control of the key injection component running in the secure execution environment.

The software decryption key could be passed to the key injection software component during key injection by further key injection software which runs in the less secure execution environment of the device. If the key injection method is performed within a secure environment such as an OEM factory then it may be considered sufficiently secure to allow a component running in the less secure execution environment to handle the passing of the key to the secure key injection software component running on the secure execution environment, although it is the secure key injection software component that controls the storage of the software decryption key in the protected state (e.g. based on encryption of the key using the device private key as discussed above). By performing some of the key passing steps using a further key injection software component running in the less secure execution environment, this can reduce the complexity of the secure key injection component which may increase security. For example, steps of communicating with a server, creating a secure connection with the server, exchanging messages with the server, or generation of keys for protecting the communication channel with the server, are just some examples of steps which could be handled by the further key injection software component, to reduce the complexity of the key injection software component itself. Also, the key injection method may be designed to reduce the number of components that can create errors and delays, such as network connection, key generation, remote processing and exchange of messages. For example, once the software decryption key has been obtained, no further communication with a remote device may be needed as the other steps of injecting the software decryption key into the device in the protected state may be performed locally on the device.

In the present application, the term âsoftwareâ is used to refer not only to the program code for the software, but also to related data which may be provided as part of the software binary when the target software is installed.

A corresponding method is provided for decryption of software installed on a target device based on the software decryption key discussed above. Again, the computing device has a secure and less secure execution environment. A control software component running within the secure execution environment is used to obtain the software decryption key stored in the key storage location in a protected state, and using the obtained software decryption key, the control software component decrypts the target software to be run on the computing device. The software decryption key could be used to directly decrypt the target software, or alternatively the software decryption key could be used to derive a further key and then the derived further key can be used to decrypt the target software. Again, the software decryption key is a class key shared between a class of devices including the computing device. Hence, by using a software component running within the secure execution environment to obtain the software decryption key and remove any protection such as encryption and then to decrypt the target software, this protects the key against unauthorised access by an external device or potentially insecure code running in the less secure execution environment which could be used by an attacker in an attempt to circumvent the protection provided for the software using the encryption. By using a class key as the software decryption key this avoids the need for device specific software update packages to be provided to each member of the class.

The software decryption key may be stored in a protected state within a software-writeable storage location accessible to the computing device. Hence it is not necessary to provide some read-only hardware element for protecting the key, which helps reduce the cost of manufacturing the device and also means that it is practical for a party other than the integrated circuit manufacturer to perform the key injection method as discussed above.

As mentioned above, the protected state may comprise a state in which the software decryption key is stored in encrypted form based on a device key which is private to the computing device and is inaccessible to the program code executed in the less secure execution environment. Hence, the control software component may control decryption of the software decryption key based on the device key. As the control software component is run within the secure execution environment this protects against leakage of both the device key and the software decryption key. The combination of a device-specific key which is private to the computing device (it is not known outside of the computing device) and a class key used for the software decryption, which is protected based on the device key, provides a good balance between security and ease of implementing the production line for device manufacture. The key storage location used to store the key may be a location accessible to program code executed in the less secure execution environment, since protection against access to the code in the clear by the less secure code may be provided by the encryption of the software decryption key raised on the device which is inaccessible to the secure code.

When decrypting the software decryption key, the control software component may copy the software decryption key in encrypted form from the key storage location to a second storage location which is inaccessible to the program code executed in the less secure execution environment and then may decrypt the software decryption key in place within the second storage location. The device-specific key used to decrypt the software decryption key may also be stored within this second storage location. By decrypting in place within a region of memory which is inaccessible to the less secure execution environment, this prevents attackers seeing the decrypted version of the software decryption key.

The target software may be associated with a control portion (e.g. a header or footer) which may include information for controlling the decryption of the software. The control portion could include a number of pieces of information, for example including an encryption status indication which indicates whether the target software requires decryption. Not all software to be run within the secure execution environment may require encryption and so by providing a flag or other indicator (such as a version number) in the control portion of the software this can allow the control software component of the device to distinguish whether decryption is required or not. This can also help distinguish newer software designed for use with the software decryption from legacy software distributed in the clear. The control portion of the software may be supplied in the clear so that it does not itself need decrypting in order to be read.

In another example the control portion could specify a key identifier for identifying which software decryption key is to be obtained for decrypting the target software. This helps support the use of different software decryption keys for different portions of software to be run on the device, which can help to limit the effects of a key leakage and/or allows software supplied by different providers to be encrypted with different keys.

Alternatively, another way of supporting use of multiple different keys for decrypting different software components can be that a requesting software component executed in the less secure execution environment may supply the control software component with the specific software decryption key required for decryption of the target software, with that software decryption key being supplied in encrypted form by the requesting software component. With this approach, it could be a component in the less secure execution environment which is responsible for providing the appropriate key for the given piece of software to be run. In this case, the control software component running in the secure execution environment does not need to track any key identifiers for distinguishing which particular key is to be used for decrypting the target software, and the software would not need to have a control portion specifying an identifier of the related software decryption key. For example, a request for execution of a given software module within the secure execution environment, which is made by a component in the less secure execution environment, could be accompanied by the encrypted software decryption key itself.

The control portion of the target software could also include information specifying at least one encryption parameter for controlling the decryption of the target software. Hence the decryption of the target software may be dependent not only on the software decryption key but also on the at least one encryption parameter specified in the control portion. For example, the at least one encryption parameter could include an identifier identifying which encryption algorithm type is used (e.g. AES, or AES-GCM). Also, the at least one encryption parameter could specify constants or parameters to be used in the encryption algorithm, such as a nonce (value to be used once) which provides freshness in encryption and may be different for each version of software encrypted using the same class key, or another value such as a tag value which is a value used specifically in the AES or AES-GCM encryption algorithms. It will be appreciated that the particular encryption parameters to encode within the control portion of the target software may be specific to the particular type of algorithm used, and so could vary from implementation to implementation.

Alternatively, rather than encoding the encryption parameters within a header or other control portion of the target software package itself, the at least one encryption parameter could also be communicated between the software provider and the device in other ways, such as by separate communication with the encryption parameters then being stored locally on the device separate from the target software itself.

The software decryption key may be a symmetric key. Hence it is not necessary to use asymmetric cryptography for the software encryption and decryption.

Startup of the target software following decryption may be dependent on successful verification of a signature associated with the target software. While the encryption of the target software provides confidentiality to protect against an attacker being able to reverse engineer information about the target software, it does not provide authenticity (a guarantee about who is the party providing the software). For some applications, it may be important to trust that the software has come from an authorised source, which can be verified based on the signature. For example, the signature may be derived from the target software using a private key which is known only to the particular trusted provider and then on receipt of the target software the control software component on the computing device may verify the signature, for example using a public key associated with that trusted provider, to check whether the software has indeed originated from the expected provider. In some decryption algorithms, such as AES-GCM, the signature verification may be an integral part of the algorithm so that the performance of the decryption algorithm also includes verification of the signature. For other types of decryption algorithms which do not include signature verification, the signature can then be verified in a separate step, either before or after decryption. In some examples the signature may itself be part of the encrypted bundle of information associated with the target software, so that the signature itself may require decryption prior to being verified.

Alternatively, the signature could be sent in unencrypted form and in this instance the signature verification could occur prior to decryption. Alternatively, signature verification can be performed in parallel or as part of a single combined algorithm.

In cases where the control portion includes an encryption status indication indicating whether the target software requires decryption, and the signature covers the control portion, then when the encryption status indication does indicate that the target software requires decryption, the signature verification may be based on a version of the control portion in which the encryption status indication has either been removed or updated to indicate that the target software does not require decryption. This can be useful because it means that the signature can be the same regardless of whether decryption is applied or not and also it is possible to include the signature within the encrypted portion of the target software as even if the encryption status indication is subsequently set when the code/data and signature of the target software is encrypted, this does not require recomputation of the signature.

The use of encryption based on a class key as discussed above can be applied to any software to be executed on the computing device. However it is particularly useful for target software which is to be executed within the secure execution environment, which may have a greater security requirement.

This method enables the target software to be updatable through over-the-air update, with both the transmission in the over-the-air (OTA) update and the subsequent storage of the updated software on the device being protected by encryption.

The decryption of the target software may occur at different timings depending on the particular implementation chosen. In some cases, the decryption could be applied as soon as the over-the-air update package is received, if it can be guaranteed that the subsequent decrypted target software can be securely stored on the device within the region of memory which is inaccessible to external devices and to less secure code operating in the less secure execution environment.

However, in other examples it may be preferred that initially the software is stored in the encrypted form until the point when it is to be booted or executed, at which point the encrypted software may be copied into a secure region of memory which is isolated from access by the less secure execution environment, and then decrypted under control of the control software component running within the secure execution environment.

In another corresponding method, a method is provided for providing an over-the-air (OTA) update for target software to be run on a given class of computing devices. The software is encrypted using the class key shared between the given class of computing devices. A control portion is provided comprising at least an encryption status indication indicating that the updated software requires decryption, and a key identifier for identifying the class key used to encrypt the updated software. A software update package is then made available to the given class of computing devices which includes the encrypted updated software and the control portion. Hence, this promotes support for different software update packages to use different class keys and then the device receiving the package can identify from the encryption status indication that decryption is required and from the key identifier which particular key is to be used to decrypt the updated software.

The class key used for encrypting the updated software may be the same as the class key used to encrypt a previous version of the updated software. Hence it is not necessary to cycle or update keys on each subsequent iteration of the same piece of software. This is useful because it means that only a single key for software decryption needs to be injected during manufacture for supporting use of a given piece of software even if the software is updated, which simplifies the production line for computing devices.

As well as the encryption status indication and the key identifier, the control portion may also specify at least one encryption parameter for use in a decryption algorithm for decrypting the updated software using the class key. For example, as described above the at least one encryption parameter may include an identifier of the decryption algorithm type to use and/or constants for use in the decryption algorithm.

The software update package may also include a signature attesting to a source of the software update package. The signature may be part of the encrypted portion of the software. The signature may be generated by deriving the signature from at least a portion of the software code and data (and optionally also the control portion) using a private key associated with an attestable identity, such that the signature can then be verified as coming from the attested source by verifying the signature and the software update package based on a public key associated with that attested identity. For example a certificate chain based on asymmetric cryptography can be used to verify the signature. The signature may be generated based on an unencrypted version of the updated software, prior to encrypting the updated software using the class key.

All of the methods discussed above may be implemented in software using at least one computer program which controls a device to perform these methods. The computer program may be stored on a storage medium. The storage medium may be a non-transitory storage medium.

FIG. 1 schematically illustrates an example of a computing device 2 , e.g. an electronic device. The computing device could be, for example, a mobile telephone or tablet computer, a laptop or other processing device, or a smaller-scale device such as a smart watch, personal fitness/health tracker, or other devices in the Internet of Things, such as a temperature sensor within a heating or air conditioning system, an actuator for controlling street lighting, etc. It will be appreciated that these are just some examples of possible uses of the computing device.

The computing device 2 has processing circuitry (e.g. a central processing unit, CPU) 4 and storage circuitry (memory) 6 , 7 for storing data and program code executed by the processing circuitry 4 . In this example the memory includes volatile memory (e.g. DRAM) 6 and non-volatile memory (e.g. flash memory) 7 . The device may also have one or more sensors 8 for sensing external conditions such as temperature, pressure, infrared radiation, etc., a display 10 for displaying information to a user, a user input module 12 for accepting input gestures from a user, and a communications interface 14 for communicating with other devices, for example through wireless protocols such as Wi-Fi, Bluetooth, or NFC or through wired communication such as Ethernet. The various components 4 - 14 of the device 2 communicate via at least one bus 16 . It will be appreciated that FIG. 1 is just one example of a possible configuration of the device 2 and other examples may have many other components not shown in FIG. 1 . Also not all of the components shown in FIG. 1 need to be included. For example some devices may not need any sensors 8 or if they do not interact directly with a user may not need a display 10 and/or user input 12 .

As shown in FIG. 2 , the processing circuitry 4 and other components of the device may have a hardware architecture which provides for a secure execution environment 20 and a less secure (normal) execution environment 22 which coexist on the device. Software applications and data may be associated with one of the secure or less secure execution environments, and application code or data associated with the secure execution environment 20 is isolated from access by the code executed within the less secure execution environment 22 . This may be implemented using hardware architecture features, such as using a memory management unit which may define a partition of memory address space into secure and less secure regions, and may enforce memory protection so that access requests issued by an application executed in the less secure execution environment 22 are not permitted to read/write a region of the memory address space that is restricted for access by the secure execution environment 20 . In some examples, only the volatile memory unit 6 may be partitioned into the secure and less secure regions and have its access policed by the memory management unit. In such examples the non-volatile memory 7 may be considered entirely associated with the less secure execution environment. Alternatively, other approaches may also partition the non-volatile memory 7 into secure and less secure regions and prevent less secure code accessing data stored in the secure region in the non-volatile memory. Other security mechanisms that can be provided to protect the assets associated with a secure environment 20 may be to provide for encryption of any data which may need to be paged out of the secure regions of memory to a potentially insecure location such as an external device (or in the flash memory 7 if this is not within the secure boundary of the secure execution environment 20 ). The secure execution environment 20 may be a trusted execution environment (TEE). The isolation of the secure execution environment 20 from the less secure execution environment 22 could in some examples be controlled according to the TrustZoneÂ® architecture provided by ArmÂ® Limited of Cambridge, UK. Other architectures for providing TEEs are also known.

A secure operating system running within the secure execution environment 20 may control the execution of trusted applications 24 within the secure execution environment 20 . The secure operating system may include a runtime manager 26 which may act as a control software component for handling certain tasks such as decryption of trusted applications and unwrapping of protected keys as discussed below.

In the examples discussed below, trusted applications 24 to be executed within the secure execution environment 20 of the device 2 are encrypted using a symmetric device-class key, so that the trusted application code's confidentiality is maintained both on the device flash memory 7 and during over-the-air updates. The symmetric key is injected to the device in the trusted execution environment 20 during production and is itself encrypted using a per-device secret key that does not leave the device (it is private to the device). On booting of the device, first the encrypted decryption key is loaded into memory restricted for access in the trusted execution environment 20 , then the decryption key is itself decrypted using the per-device secret key and then the decrypted decryption key is used to decrypt the encrypted trusted application 24 so that the trusted application can be run. This approach is supported through three complementary functions as described in the subsequent figures. FIGS. 3 and 4 show injection of the software decryption key in the factory during device manufacturing. FIGS. 5 to 7 illustrate generation of encrypted application's software for distribution to the device. FIGS. 8 and 9 illustrate decryption of trusted application software 24 before starting it on the computing device 2 .

Hence, with reference to FIGS. 3 and 4 , the device production may include a step of key injection which may be performed by an original equipment manufacturer (OEM) within their secured factory environment. The OEM may be a manufacturer of computing devices who does not themselves manufacture their own integrated circuits or system-on-chips for the processing hardware of the device, but integrates chips made by a separate chip manufacturer into an overall computing device together with other components such as the display 10 , user input 12 , communications interface 14 , etc. Such an OEM may be manufacturing a batch of devices which may include devices with different system-on-chips manufactured by different chip providers, but nevertheless for production efficiency it is useful to use the same key injection method for each of the devices in the batch, with keys selected independent of which chip manufacturer provided the system-on-chip for an individual device.

As shown in FIG. 3 , a class key associated with the class of devices to be manufactured is obtained from a key server 30 , which could be maintained locally within the OEM factory or could be a remote server, and the key is provided to a factory writing tool 32 which controls the device 2 to start up with a factory software image being booted on the device, and the factory software image including software components including a key injection client application (CA) 37 and key injection trusted application (TA) 36 for running in the less secure and secure execution environments

22 , 20 respectively. The communications channel between the key server 30 and factory writing tool 32 may be secured in any known manner for protecting communications, for example a channel may be secured based on asymmetric key cryptography, or a physically secure channel may be used.

The class key (software decryption key) injected by the factory writing tool 32 is provided to the key injection CA 37 running within the less secure execution environment 22 of the device 2 . In some examples, the class key may be encrypted with a temporary factory key at the time of injection into the device 2 , where that temporary key is inaccessible to code executing in the less secure execution environment 22 , and accessible to the key injection TA 36 in the secure execution environment. In this case, the key injection TA 36 decrypts the class key

CLAIMS

Claims ( 17 )

The invention claimed is:

1. A key injection method for a computing device having a secure execution environment and a less secure execution environment, wherein program code or data associated with the secure execution environment is isolated from access by program code executed in the less secure execution environment; the method comprising:

providing a software decryption key for decryption of software to be run on the computing device, wherein the software decryption key is a class key shared between a class of devices including said computing device;

using a key injection software component executed within the secure execution environment of the computing device, controlling storage of the software decryption key in a protected state in a key storage location accessible to the computing device;

the protected state comprising a state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment of the computing device,

wherein the key injection method is performed by an original equipment manufacturer of the computing device, the computing device comprising a system-on-chip manufactured by a different manufacturer than the original equipment manufacturer of the computing device; and

wherein the software decryption key is selectively provided to a subset of manufacturers involved in the manufacture of the computing device including the original equipment manufacturer.

2. The method of claim 1 , in which the protected state comprises a state in which the software decryption key is encrypted based on a device key which is private to the computing device and is inaccessible to the program code executed in the less secure execution environment.

3. The method of claim 2 , in which the key storage location is accessible to the external device or to the program code executed in the less secure execution environment.

4. The method of claim 1 , in which the protected state comprises a state in which the software decryption key is stored in a storage region which is accessible to program code executed in the secure execution environment and inaccessible to the external device or the program code executed in the less secure execution environment.

5. The method of claim 1 , in which when the software decryption key is stored in the protected state, the software decryption key is unreadable in the clear by a software component other than a predetermined control software component of the secure execution environment and said key injection software component.

6. The method of claim 5 , in which when stored in the protected state, the software decryption key is also unreadable in the clear from the key storage location by the key injection software component.

7. The method of claim 1 , in which an in-field software image to be provided on the computing device when the device is released for in-field use excludes said key injection software component.

8. The method of claim 1 , in which said key injection software component is prohibited from overwriting a previously injected software decryption key.

9. The method of claim 1 , in which the software decryption key is stored in the protected state in association with a key identifier distinguishing the software decryption key from other software decryption keys.

10. The method of claim 1 , in which the target software is associated with a control portion comprising an encryption status indication indicating that the target software requires decryption, wherein decryption of the target software is dependent on the software decryption key and at least one encryption parameter specified in the control portion.

11. The method of claim 1 , in which the target software is associated with a control portion specifying a key identifier for identifying which software decryption key is to be obtained for decrypting the target software, wherein decryption of the target software is dependent on the software decryption key and at least one encryption parameter specified in the control portion.

12. The method of claim 1 , in which the control software component obtains the software decryption key in an encrypted form from a requesting software component executed in the less secure execution environment, which is requesting execution of the target software.

13. The method of claim 1 , wherein startup of the target software following decryption is dependent on successful verification of a signature associated with the target software, wherein when the target software is associated with a control portion comprising an encryption status indication indicating that the target software requires decryption, the method comprises verification of the signature based on a version of the control portion in which the encryption status indication has been removed or updated to indicate that the target software does not require decryption.

14. A method for a computing device having a secure execution environment and a less secure execution environment and comprising a system-on-chip, wherein program code or data associated with the secure execution environment is isolated from access by program code executed in the less secure execution environment; the method comprising:

using a control software component running within the secure execution environment:

obtaining a software decryption key stored in a key storage location in a protected state, the protected state comprising a state in which the software decryption key is unreadable in the clear from the key storage location by an external device or by program code executed in the less secure execution environment of the computing device, wherein the software decryption key has been previously provided to the computing device by an original equipment manufacturer of the computing device, the original equipment manufacturer of the computing device being a different manufacturer than the manufacturer of the system-on-chip, and wherein the software decryption key is selectively provided to a subset of manufacturers involved in the manufacture of the computing device including the original equipment manufacturer; and

using the obtained software decryption key, decrypting target software to be run on the computing device;

wherein the software decryption key is a class key shared between a class of devices including said computing device.

15. The method of claim 14 , in which the software decryption key is stored in the protected state within a software-writable storage location.

16. The method of claim 14 , in which the protected state comprises a state in which the software decryption key is stored in encrypted form based on a device key which is private to the computing device and is inaccessible to the program code executed in the less secure execution environment; and

the control software component controls decryption of the software decryption key based on the device key.

17. The method of claim 16 , in which the key storage location is accessible to the program code executed in the less secure execution environment, wherein, to decrypt the software decryption key, the control software component copies the software decryption key in encrypted form from the key storage location to a second storage location inaccessible to the program code executed in the less secure execution environment, and decrypts the software decryption key in-place within the second storage location.

US16/781,204

2019-02-05

2020-02-04

Software encryption

Active

2040-07-03

US11218299B2

( en )

Applications Claiming Priority (3)

Application Number

Priority Date

Filing Date

Title

GB1901596

2019-02-05

GB1901596.5A

GB2581161A

( en )

2019-02-05

Software encryption

GB1901596.5

2019-02-05

Publications (2)

Publication Number

Publication Date

US20200252207A1

US20200252207A1 ( en )

2020-08-06

US11218299B2

true

US11218299B2 ( en )

2022-01-04

Family

ID=65997041

Family Applications (1)

Application Number

Title

Priority Date

Filing Date

US16/781,204

Active

2040-07-03

US11218299B2

( en )

2019-02-05

2020-02-04

Software encryption

Country Status (3)

Country

Link

( 1 )

US11218299B2

( en )

( 1 )

EP3693880B1

( en )

( 1 )

GB2581161A

( en )

Cited By (1)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20220253521A1

( en )

2021-02-10

2022-08-11

Canon Kabushiki Kaisha

Image forming apparatus capable of executing application programs, control method therefor, and storage medium

Families Citing this family (24)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US10642970B2

( en )

2017-12-12

2020-05-05

John Almeida

Virus immune computer system and method

US11340894B2

( en )

2019-04-30

2022-05-24

JFrog, Ltd.

Data file partition and replication

US11106554B2

( en )

2019-04-30

2021-08-31

JFrog, Ltd.

Active-active environment control

US11386233B2

( en )

2019-04-30

2022-07-12

JFrog, Ltd.

Data bundle generation and deployment

US11113424B2

( en )

2019-05-07

2021-09-07

Motorola Solutions, Inc.

Device, system and method for installing encrypted data

US11336684B2

( en )

2019-06-07

2022-05-17

Lookout, Inc.

Mobile device security using a secure execution context

WO2021014326A2

( en )

2019-07-19

2021-01-28

JFrog Ltd.

Software release verification

US10999314B2

( en )

2019-07-19

2021-05-04

JFrog Ltd.

Software release tracking and logging

US11695829B2

( en )

2020-01-09

2023-07-04

JFrog Ltd.

Peer-to-peer (P2P) downloading

DE102020109696A1

( en )

2020-04-07

2021-10-07

Endress + Hauser Process Solutions Ag

Method for connecting a field device to a cloud

CN113779652B

( en )

2020-06-09

2025-05-30

åä¸ºææ¯æéå¬å¸

Data integrity protection method and device

CN112286562B

( en )

2020-10-28

2021-09-10

é£è¾ä¿¡æ¯ææ¯æéå¬å¸

Debugging updating method and system for trusted operating system

US11475140B1

( en )

2020-11-24

2022-10-18

Amazon Technologies, Inc.

Enclave-based cryptography services in edge computing environments

US11960596B2

( en )

2021-03-11

2024-04-16

Xilinx, Inc.

Network interface device

JP7447864B2

( en )

2021-04-26

2024-03-12

ãã¨ã¿èªåè»æ ªå¼ä¼ç¤¾

OTA master, method and program

CN113299018A

( en )

2021-06-22

2021-08-24

ä¸æµ·åæ°è½¯ä»¶æéå¬å¸

ATM software remote upgrading method

WO2023048707A1

( en )

2021-09-22

2023-03-30

Hewlett-Packard Development Company, L.P.

Encrypted storage

US11755721B2

( en )

2021-10-25

2023-09-12

International Business Machines Corporation

Trusted workload execution

US11645092B1

( en )

2021-10-25

2023-05-09

International Business Machines Corporation

Building and deploying an application

US12536008B2

( en )

2021-10-29

2026-01-27

JFrog Ltd.

Managing a federated software repository across multiple devices

US12061889B2

( en )

2021-10-29

2024-08-13

JFrog Ltd.

Software release distribution across a hierarchical network

CN116793223A

( en )

2022-03-15

2023-09-22

åäº¬èªä¸ºé«ç§è¿æ¥ææ¯æéå¬å¸

Method, system and device for measuring thread ending length

CN118673481A

( en )

2023-03-15

2024-09-20

åäº¬å°ç±³ç§»å¨è½¯ä»¶æéå¬å¸

Secure startup method, device, equipment and storage medium for IoT devices

WO2024240351A1

( en )

2023-05-25

2024-11-28

Huawei Technologies Co., Ltd.

Secure key provisioning with multiple secure component vendors

Citations (29)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20050182952A1

( en )

2004-02-12

2005-08-18

Sony Corporation

Information processing apparatus and method and computer program

US20060090084A1

( en )

2004-10-22

2006-04-27

Mark Buer

Secure processing environment

US20060130130A1

( en )

2004-11-30

2006-06-15

Joshua Kablotsky

Programmable processor supporting secure mode

US20100122088A1

( en )

2002-06-20

2010-05-13

Oxford William V

Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol

US20100174919A1

( en )

2009-01-08

2010-07-08

Takayuki Ito

Program execution apparatus, control method, control program, and integrated circuit

US20110010770A1

( en )

2009-07-10

2011-01-13

Certicom Corp.

System and method for performing key injection to devices

US20110246707A1

( en )

2010-03-30

2011-10-06

Renesas Electronics Corporation

Semiconductor device and data processing method

US20130254537A1

( en )

2012-03-26

2013-09-26

Symantec Corporation

Systems and methods for secure third-party data storage

US20130266137A1

( en )

2012-04-10

2013-10-10

Western Digital Technologies, Inc.

Digital rights managment system, devices, and methods for binding content to an intelligent storage device

US20140010371A1

( en )

2012-07-09

2014-01-09

Roger I. Khazan

Cryptography and key management device and architecture

US20140016776A1

( en )

2011-03-30

2014-01-16

Arnoud Evert Van Foreest

Establishing unique key during chip manufacturing

US8645716B1

( en )

2010-10-08

2014-02-04

Marvell International Ltd.

Method and apparatus for overwriting an encryption key of a media drive

US20140149748A1

( en )

2012-11-28

2014-05-29

Infineon Technologies Ag

Methods and Systems for Securely Transferring Embedded Code And/Or Data Designed for a Device to a Customer

US20140181498A1

( en )

2012-12-22

2014-06-26

Samsung Electronics Co., Ltd.

Method and apparatus for supporting dynamic change of authentication means secure booting

US20140359268A1

( en )

2013-06-03

2014-12-04

Broadcom Corporation

Methods of Securely Changing the Root Key of a Chip, and Related Electronic Devices and Chips

US20150010151A1

( en )

2011-06-21

2015-01-08

Peter Roelse

Receiver software protection

US20150113278A1

( en )

2012-03-02

2015-04-23

Syphermedia International, Inc.

Blackbox security provider programming system permitting multiple customer use and in field conditional access switching

US20160034702A1

( en )

2014-07-15

2016-02-04

Neil Sikka

Apparatus For And Method Of Preventing Unsecured Data Access

US20160070932A1

( en )

2014-09-10

2016-03-10

Vincent J. Zimmer

Providing A Trusted Execution Environment Using A Processor

US20160094548A1

( en )

2014-09-30

2016-03-31

Apple Inc.

Method for secure key injection with biometric sensors

US20160182238A1

( en )

2014-12-18

2016-06-23

Prashant Dewan

Partitioning access to system resources

US20170090909A1

( en )

2015-09-25

2017-03-30

Qualcomm Incorporated

Secure patch updates for programmable memories

US20170302456A1

( en )

2016-04-13

2017-10-19

Rockwell Automation Technologies, Inc.

Device specific cryptographic content protection

EP3346415A2

( en )

2017-01-10

2018-07-11

Trustonic Limited

Event attestation for an electronic device

US20190087578A1

( en )

2017-09-19

2019-03-21

Sling Media Pvt Ltd

Electronic devices and methods supporting unsecured system-on-chip secure boot functionalities

US20190349346A1

( en )

2013-10-17

2019-11-14

Arm Ip Limited

Registry apparatus, agent device, application providing apparatus and corresponding methods

US20200044865A1

( en )

2003-06-13

2020-02-06

Ward Participations B.V.

Method and system for performing a transaction and for performing a verification of legitimate access to, or use of digital data

US20210091952A1

( en )

2018-07-09

2021-03-25

Ares Technologies, Inc.

Secure computing hardware apparatus and methods of manufacturing a secure computing hardware apparatus

US10963593B1

( en )

2018-12-11

2021-03-30

Amazon Technologies, Inc.

Secure data storage using multiple factors

Family Cites Families (1)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US9894061B2

( en )

2015-10-16

2018-02-13

International Business Machines Corporation

Method for booting and dumping a confidential image on a trusted computer system

2019

2019-02-05

GB1901596.5A

patent/GB2581161A/en

not_active

Withdrawn

2020

2020-02-04

US16/781,204

patent/US11218299B2/en

active

Active

2020-02-05

EP20155714.7A

patent/EP3693880B1/en

active

Active

Patent Citations (29)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20100122088A1

( en )

2002-06-20

2010-05-13

Oxford William V

Method and system for control of code execution on a general purpose computing device and control of code execution in a recursive security protocol

US20200044865A1

( en )

2003-06-13

2020-02-06

Ward Participations B.V.

Method and system for performing a transaction and for performing a verification of legitimate access to, or use of digital data

US20050182952A1

( en )

2004-02-12

2005-08-18

Sony Corporation

Information processing apparatus and method and computer program

US20060090084A1

( en )

2004-10-22

2006-04-27

Mark Buer

Secure processing environment

US20060130130A1

( en )

2004-11-30

2006-06-15

Joshua Kablotsky

Programmable processor supporting secure mode

US20100174919A1

( en )

2009-01-08

2010-07-08

Takayuki Ito

Program execution apparatus, control method, control program, and integrated circuit

US20110010770A1

( en )

2009-07-10

2011-01-13

Certicom Corp.

System and method for performing key injection to devices

US20110246707A1

( en )

2010-03-30

2011-10-06

Renesas Electronics Corporation

Semiconductor device and data processing method

US8645716B1

( en )

2010-10-08

2014-02-04

Marvell International Ltd.

Method and apparatus for overwriting an encryption key of a media drive

US20140016776A1

( en )

2011-03-30

2014-01-16

Arnoud Evert Van Foreest

Establishing unique key during chip manufacturing

US20150010151A1

( en )

2011-06-21

2015-01-08

Peter Roelse

Receiver software protection

US20150113278A1

( en )

2012-03-02

2015-04-23

Syphermedia International, Inc.

Blackbox security provider programming system permitting multiple customer use and in field conditional access switching

US20130254537A1

( en )

2012-03-26

2013-09-26

Symantec Corporation

Systems and methods for secure third-party data storage

US20130266137A1

( en )

2012-04-10

2013-10-10

Western Digital Technologies, Inc.

Digital rights managment system, devices, and methods for binding content to an intelligent storage device

US20140010371A1

( en )

2012-07-09

2014-01-09

Roger I. Khazan

Cryptography and key management device and architecture

US20140149748A1

( en )

2012-11-28

2014-05-29

Infineon Technologies Ag

Methods and Systems for Securely Transferring Embedded Code And/Or Data Designed for a Device to a Customer

US20140181498A1

( en )

2012-12-22

2014-06-26

Samsung Electronics Co., Ltd.

Method and apparatus for supporting dynamic change of authentication means secure booting

US20140359268A1

( en )

2013-06-03

2014-12-04

Broadcom Corporation

Methods of Securely Changing the Root Key of a Chip, and Related Electronic Devices and Chips

US20190349346A1

( en )

2013-10-17

2019-11-14

Arm Ip Limited

Registry apparatus, agent device, application providing apparatus and corresponding methods

US20160034702A1

( en )

2014-07-15

2016-02-04

Neil Sikka

Apparatus For And Method Of Preventing Unsecured Data Access

US20160070932A1

( en )

2014-09-10

2016-03-10

Vincent J. Zimmer

Providing A Trusted Execution Environment Using A Processor

US20160094548A1

( en )

2014-09-30

2016-03-31

Apple Inc.

Method for secure key injection with biometric sensors

US20160182238A1

( en )

2014-12-18

2016-06-23

Prashant Dewan

Partitioning access to system resources

US20170090909A1

( en )

2015-09-25

2017-03-30

Qualcomm Incorporated

Secure patch updates for programmable memories

US20170302456A1

( en )

2016-04-13

2017-10-19

Rockwell Automation Technologies, Inc.

Device specific cryptographic content protection

EP3346415A2

( en )

2017-01-10

2018-07-11

Trustonic Limited

Event attestation for an electronic device

US20190087578A1

( en )

2017-09-19

2019-03-21

Sling Media Pvt Ltd

Electronic devices and methods supporting unsecured system-on-chip secure boot functionalities

US20210091952A1

( en )

2018-07-09

2021-03-25

Ares Technologies, Inc.

Secure computing hardware apparatus and methods of manufacturing a secure computing hardware apparatus

US10963593B1

( en )

2018-12-11

2021-03-30

Amazon Technologies, Inc.

Secure data storage using multiple factors

Non-Patent Citations (1)

* Cited by examiner, â Cited by third party

Title

Search and Examination Report for GB1901596.5, dated Jul. 18, 2019, 5 pages.

Cited By (2)

* Cited by examiner, â Cited by third party

Publication number

Priority date

Publication date

Assignee

Title

US20220253521A1

( en )

2021-02-10

2022-08-11

Canon Kabushiki Kaisha

Image forming apparatus capable of executing application programs, control method therefor, and storage medium

US12158948B2

( en )

2021-02-10

2024-12-03

Canon Kabushiki Kaisha

Image forming apparatus capable of executing application programs, control method therefor, and storage medium

Also Published As

Publication number

Publication date

US20200252207A1

( en )

2020-08-06

GB201901596D0

( en )

2019-03-27

GB2581161A

( en )

2020-08-12

EP3693880B1

( en )

2024-11-13

EP3693880A1

( en )

2020-08-12

Software encryption — Trustonic Limited (US11218299B2)

Related documents