Method, device and storage medium for performing authentication extension

Abstract

The present disclosure relates to a bootloader verification extension method. The method includes: in response to a request to verify a signature associated with first data, obtaining an asymmetric verifier application from an off-device storage device; loading the asymmetric verifier application; executing the asymmetric verifier application; using the asymmetric verifier application to verify the signature associated with the first data using asymmetric key cryptography.

Description

Technical Field

[0001] The present technology relates to the field of electronic devices. More specifically, the present technology relates to enabling devices to perform asymmetric verification of data. Background Art

[0002] Increasingly, electronic devices are being used to access services that may involve the handling of potentially sensitive information, such as mobile banking, access to healthcare services or the handling of employment details. Additionally, with the continued development of the Internet of Things (IoT), it is becoming more common to control systems such as heating, air conditioning or street lighting based on information provided by electronic devices that may provide sensor information such as temperature data or proximity information indicating the presence of a user. In these scenarios, it may be important to ensure that software updates to these devices are performed securely and have not been compromised or otherwise manipulated by malicious parties.

[0003] Cryptographic techniques can be provided that are capable of authenticating software updates received by a device. However, in very small computing devices such as sensors, actuators, or other devices in the IoT, memory storage capacity, processing power, and communication bandwidth may be extremely constrained, which may limit the cryptographic techniques that can be performed. Furthermore, such devices often lack dedicated cryptographic hardware.

[0004] When performing secure software updates on devices, it is often better to use asymmetric cryptography rather than symmetric cryptography because the use of asymmetric cryptography eliminates the high risk of security being rendered useless by a symmetric key leak. However, given the limited capabilities of IoT devices, the use of asymmetric cryptography has proven to be infeasible because the size of the asymmetric cryptography software reserves a large portion of the IoT device's storage capacity for activities that are rarely performed (i.e., verification of software updates).

[0005] At least some embodiments of the present disclosure address one or more of these problems as stated above. Summary of the invention

[0006] Particular aspects and embodiments are set out in the following claims.

[0007] From one perspective, a verification extension method for a device may be provided, the method comprising: in response to a request to verify a signature associated with first data, obtaining an asymmetric verifier application from a storage device outside the device; loading the asymmetric verifier application; executing the asymmetric verifier application; and using the asymmetric verifier application to verify the signature associated with the first data using asymmetric key cryptography.

[0008] By storing the asymmetric authenticator application in an off-device storage device and obtaining the asymmetric authenticator application when needed, the need to permanently reserve memory on the device for the asymmetric authenticator application is avoided, thereby making it feasible for capability-constrained devices such as IoT devices to utilize high-security asymmetric key cryptography.

[0009] In some examples, the signature associated with the first data is a signature of a hash of the first data. Thus, by only requiring the signature of the hash to be verified, rather than the entire first data, the computational complexity of verifying the signature can be reduced.

[0010] In some examples, the first data is another application. Therefore, the integrity / security of the application can be verified before the application is loaded / installed and executed. In some examples, the first application can be software for performing specific tasks such as writing to flash memory, formatting a storage device, importing a key, or programming a fuse.

[0011] In some examples, the device verifies the asymmetric authenticator application using the first hash function and the initial application hash before executing the asymmetric authenticator application, and in response to a positive verification result, the device executes the asymmetric authenticator application. The integrity of the asymmetric authenticator application itself can therefore be confirmed, thereby further enhancing security by avoiding the possibility of a malicious party presenting a forged asymmetric authenticator application to the device.

[0012] In some examples, the asymmetric authenticator application is authenticated using the device's primary bootloader.The asymmetric authenticator application can thus be authenticated by a low-level process of the device, thereby avoiding the need for additional intermediate processes that can introduce computational overhead and additional security vulnerabilities.

[0013] In some examples, the initial application hash is retrieved from the on-device storage. Therefore, the space required to store the initial application hash on the device can be avoided. In addition, by not storing the initial application hash in the on-device storage, the risk of being able to extract the initial application hash from the device is reduced, thereby enhancing security.

[0014] In some examples, the initial application hash is embedded on the device during manufacture or assembly of the device. Thus, the initial application hash is immediately available when needed (i.e., further delays in obtaining it can thus be avoided), and the initial application hash is resistant to modification / tampering by malicious parties after manufacture or assembly of the device. Further, by avoiding the need to communicate (e.g., send) the initial application hash to the device, communication bandwidth required to communicate the initial application hash to the device can be saved, which is particularly important in bandwidth-constrained devices such as IoT devices.

[0015] Additionally, by not transmitting / sending the initial application hash, the possibility of it being intercepted or modified by a malicious party during transmission / transmission (e.g., so that the initial application hash corresponds to an arbitrary unapproved application) is avoided. Further distribution of the initial application hash can in this way be controlled by the manufacturer or assembler without the need to trust another party.

[0016] In some examples, the asymmetric verifier application verifies the signature using one or more keys stored in a storage device on the device. Therefore, by storing the one or more keys in a storage device on the device, the one or more keys are immediately available when needed (i.e., further delays in obtaining them are avoided). Further, by avoiding the need to transmit / send the one or more keys, the communication bandwidth required to transmit the one or more keys to the device can be saved, which is particularly important in bandwidth-constrained devices such as IoT devices. In addition, by not transmitting / sending the one or more keys, the possibility of it being intercepted by a malicious party is avoided.

[0017] In some examples, a plurality of keys are stored in a storage device on a device, wherein each of the keys is associated with a privilege level, and wherein a restriction associated with the privilege level of a key used to verify a signature associated with first data is applied to the first data. Thus, the device is enabled to use the same verification process to process a series of data with different restrictions associated with the privilege level to be applied. Thus, the need for multiple different processes to verify data at different privilege levels can be avoided, thereby reducing the required storage space and reducing complexity.

[0018] In some examples, the one or more keys are embedded on the device during manufacture or assembly of the device. Thus, the one or more keys are immediately available when needed (i.e., further delays in obtaining them can thus be avoided), and the one or more keys are resistant to modification / tampering by malicious parties after manufacture or assembly of the device. Further, by avoiding the need to transmit / send the one or more keys, communication bandwidth required to transmit the one or more keys to the device can be saved, which is particularly important in bandwidth-constrained devices such as IoT devices.

[0019] Additionally, by not transmitting / sending the key or keys, the possibility of it being intercepted by a malicious party is avoided. Further distribution of the key or keys can in this way be controlled by the manufacturer or assembler without the need to trust another party.

[0020] In some examples, the asymmetric authenticator application verifies the signature using one or more keys embedded in the asymmetric authenticator application. Thus, the one or more keys may be provided to the device along with the asymmetric authenticator application in an integrated package.

[0021] In some examples, in response to a positive or negative verification of a signature associated with the first data, the asymmetric verifier application is uninstalled. Thus, memory occupied by the asymmetric verifier application can be recovered after use, thereby freeing up memory for other uses. For example, by uninstalling the asymmetric verifier application, sufficient memory can be freed up to allow a firmware update to be performed. More generally, for example, uninstalling the asymmetric verifier application allows a software update to be performed on the device using a footprint that is optimally sized for the memory update.

[0022] In some examples, a plurality of signatures corresponding to a plurality of data including the first data are verified using an asymmetric verifier application, and in response to completing independent positive or negative verification of the plurality of signatures, the asymmetric verifier application is uninstalled.

[0023] Thus, the device can save communication bandwidth by allowing the use of a single instance of the asymmetric verifier application to be obtained, loaded and executed to verify multiple signatures, while avoiding the need to obtain and / or load and / or execute the asymmetric verifier application multiple times. In addition, by verifying multiple signatures in this manner, verification results can be provided in a more timely and efficient manner. In other words, the device can avoid repeatedly swapping the asymmetric verifier application in and out of memory.

[0024] In some examples, in response to a positive verification of a signature associated with the first data, the first data is loaded. Thus, the data is actually available to the device. In the case where the data is an application, the loading of the device may include an installation process for the application. In some examples, such as when the data is small enough, the signature may be directly the data itself, thereby avoiding the need to use a hash of the data and verify it.

[0025] In some examples, the signature associated with the first data is a signature of a hash of the first data and in response to a positive verification of the signature associated with the first data, the hash of the first data is stored on the device. Thus, the device now has the hash of the data ready to verify the first data as it is received and when the first data is received. For large amounts of data, the use of a signature over a hash can be more efficient because asymmetric verification of a signature tends to be more computationally intensive than verifying a hash. Thus, it is more efficient to verify a smaller hash of the larger first data and asymmetrically verify the signature of the smaller hash than to simply asymmetrically verify the larger first data.

[0026] In some examples, the method further includes: obtaining the first data; loading the first data; and verifying the first data using a hash of the first data and a second hash function. In other words, for example, the device generates a hash of the obtained first data and checks whether the obtained hash of the first data matches a hash that has been previously stored or otherwise available to the device (e.g., a hash verified by an asymmetric verifier application). Thus, when the signature associated with the first data is a signature of the hash of the first data, the hash previously stored on the device may be obtained and used to verify the first data.

[0027] In some examples, in response to positive verification of the first data using the second hash function, the first data is executed or made available to the executable code. Thus, when the first data is another application, the other application is actually executed on the device, and when the first data is non-executable code, the first data is provided for use by the executable code on the device. In some examples, in the event that a matching hash is not found for a piece of obtained data, the data will not be executed or will not be made available to the executable code, and a user or operator is optionally alerted to the lack of a match.

[0028] In some examples, after the first data has been executed or becomes available to the executable code, the hash of the first data is removed from the device. Thus, the space associated with storing the first hash on the device can be recovered. Additionally, this can be used to prevent the first data from being verified again at another point in time (i.e., because the hash of the first data is no longer available to the device).

[0029] In some examples, the algorithms of the first hash function and the second hash function use the same computation function, but take different data as input. Thus, only a single computation hash function needs to be stored on the device, thereby saving space and, generally, allowing further hardware / software optimization of the performance of the hash function. Furthermore, in some examples, the first data may be authenticated using exactly the same hashing process as is used to authenticate an asymmetric authenticator application, for example, using the device's primary boot loader. Thus, from one perspective, the device may simply check a list of all hashes stored on the device in response to receiving a piece of first data (e.g., an asymmetric authenticator application or another application) and see if any of these match a hash of the received piece of first data generated by the device itself.

[0030] In some examples, the device does not include hardware asymmetric validator circuits. Therefore, any asymmetric verification cannot be performed directly in hardware, but instead must be performed in software. This saves the cost and physical space associated with accommodating dedicated asymmetric validator circuits on the device. This is particularly important for IoT devices that may be highly constrained in terms of performance, size, and energy consumption.

[0031] From one perspective, a computer program may be provided, the computer program being used to control a device to perform any of the above methods. In some examples, the computer program is stored on a storage medium.

[0032] From one perspective, there may be provided an apparatus comprising: a processing circuit for performing data processing; and a data storage device storing a computer program for controlling the processing circuit to perform any of the above methods.

[0033] Other aspects will become apparent after reviewing the disclosure, particularly after reviewing the drawings, detailed description, and claims section. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Examples of the present disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0035] Figure 1 : Schematically illustrates a first example method for enabling a device to perform asymmetric verification of data according to the teachings of the present disclosure.

[0036] Figure 2 : Schematically illustrates a second example method for enabling a device to perform asymmetric verification of data according to the teachings of the present disclosure.

[0037] Figure 3 : Schematically illustrates an example of an electronic device that can be used to implement the teachings of the present disclosure.

[0038] Although the present disclosure is susceptible to various modifications and alternative forms, specific example methods are shown by way of example in the drawings and are described in detail herein. It should be understood, however, that the drawings and detailed descriptions thereto are not intended to limit the present disclosure to the particular forms disclosed, but on the contrary the present disclosure will cover all modifications, equivalents and alternatives that fall within the spirit and scope of the claimed invention.

[0039] It will be appreciated that features of the above-described examples of the present disclosure may be used conveniently and interchangeably in any suitable combination. DETAILED DESCRIPTION

[0040] Figure 1A schematic illustration of a first example method 100 for enabling a device to perform asymmetric verification of data according to the teachings of the present disclosure is shown, the first embodiment method 100 comprising the following steps.

[0041] At step S110, an asymmetric verifier application is obtained by the device from an off-device storage in response to a request to verify a signature associated with the first data. The method then proceeds to step S115.

[0042] At step S115, the device loads the asymmetric authenticator application. The method then proceeds to step S120.

[0043] At step S120, the device executes the asymmetric authenticator application. The method then proceeds to step S130.

[0044] At step S130, the device uses an asymmetric verifier application to verify the signature associated with the first data to perform asymmetric key cryptography. The asymmetric verifier application verifies the signature using one or more keys. The one or more keys can be stored or retrieved from many different locations. In some examples, at least one of the one or more keys is stored in an on-device storage device on the device itself.

[0045] In some examples, multiple keys are stored in an on-device storage device, where each of these keys is associated with a different privilege level. Each privilege level is associated with one or more restrictions and the privilege level of the key that verifies the signature associated with a particular piece of data (e.g., the first data) determines what restrictions are imposed on the piece of data (i.e., the restrictions corresponding to the particular key are imposed). For example, one key may be a top-level key that allows a privileged mode to be executed on the device and may be used, for example, by the device manufacturer / assembler itself. Another key may, for example, not permit execution and may be provided, for example, to a third party.

[0046] Additionally or alternatively, in some examples at least one of the one or more keys is embedded on the device during manufacture or assembly of the device, for example by the manufacturer or assembler of the device. In some examples, the device may have been manufactured / assembled by multiple manufacturers / assemblers and each of these manufacturers / assemblers may embed the one or more keys into the device. Additionally or alternatively, in some examples at least one of the one or more keys may be embedded in an asymmetric authenticator application such that one of the one or more keys is obtained by the device integrally with the asymmetric authenticator application when the asymmetric authenticator application is obtained. In some examples, the one or more keys are not permanently stored in an on-device storage device of the device, but may instead be obtained by the device on demand from an off-device storage device when needed.

[0047] In some examples, multiple signatures corresponding to multiple data may be verified by an asymmetric verifier application during a single acquisition, loading, and execution event of the asymmetric verifier application prior to any unloading of the asymmetric verifier application.

[0048] In response to the negative verification of the signature associated with the first data at step S130, the method proceeds to step S140. At step S140, the asymmetric verifier application is uninstalled. It is expressly contemplated that in some examples, the asymmetric verifier application is not uninstalled in response to the negative verification. For example, the asymmetric verifier application can be kept loaded and / or executed on the device to allow verification of the second piece of data at some future point in time.

[0049] In response to the positive verification of the signature associated with the first data at step S130, the method proceeds to step S150. At step S150, the asymmetric authenticator application is uninstalled. It is expressly contemplated that in some examples, the asymmetric authenticator application is not uninstalled in response to the positive verification. For example, the asymmetric authenticator application can remain loaded and / or executed on the device until a specific trigger condition has been met (such as confirmation by a user or remote device that the data is no longer currently required to be verified). The method then proceeds to step S160.

[0050] At step S160, in response to the affirmative verification of the signature associated with the first data, the first data is loaded. It is expressly contemplated that, in some examples, step S160 is performed before step S150. It is also expressly contemplated that, in some examples, the first data is only loaded at some future point in time, or not at all. For example, if the first data is needed at some future point in time, the device may preemptively verify the signature associated with the first data.

[0051] Figure 2 A schematic diagram of a second exemplary method 200 for enabling a device to perform asymmetric verification of data according to the teachings of the present disclosure is shown. The second exemplary method 200 includes the following steps.

[0052] Many of the steps performed in the second example method proceed in substantially the same manner as corresponding steps performed in the first example method, unless otherwise described, and therefore will not be discussed in detail. Specifically, step S210 is substantially the same as step S110, step S215 is substantially the same as step S115, step S220 is substantially the same as step S120, step S230 is substantially the same as step S130, step S240 is substantially the same as step S140, and step S250 is substantially the same as step S150.

[0053] In a second example method, following step S215 but before step S220, step S218 is performed. At step S218, before executing the asymmetric authenticator application, the asymmetric authenticator application itself is authenticated. The asymmetric authenticator application is authenticated by using a first hash function and an initial application hash. For example, a hash is generated by a device of the asymmetric authenticator application and checking whether the hash so generated matches the initial application hash. The first hash function can be a cryptographic hash function for further enhancing security. Examples of suitable hash algorithms include MD5, the SHA family (e.g., SHA-256), or any other suitable hash algorithm.

[0054] In some examples, the asymmetric authenticator application is authenticated using a low-level process of the device, such as the device's primary boot loader. In some examples, the initial application hash is retrieved from on-device storage. In other embodiments, the initial application hash may be retrieved from off-device storage on demand. In some examples, the initial application hash is embedded in on-device storage during manufacture or assembly of the device. During manufacture / assembly, in some examples, the initial application hash may be a unique hash stored on the device immediately after manufacture / assembly.

[0055] In response to a positive verification result, the method proceeds to step S220 and the asymmetric verifier application is executed. In response to a negative verification result, the asymmetric verifier application is not executed. In some examples, in response to a negative verification result, the asymmetric verifier application may be uninstalled.

[0056] In the second example method, the signature associated with the first data is a signature of a hash of the first data. Further, in the second example method, the first data is another application (e.g., a security sensing application, a banking application, or a device security monitor). It is expressly contemplated that the first example method can also be performed where the signature associated with the first data is a signature of a hash of the first data and the first data is another application.

[0057] Conversely, it is expressly contemplated that the second example method can be performed where the signature associated with the first data is not a signature of a hash of the first data and where the first data is not another application (eg, is non-executable data).

[0058] However, in the depicted example, after the asymmetric verifier application is executed at step S220, the method proceeds to step S230 and the signature of the hash of another application is verified at step S230.

[0059] exist Figure 2In the embodiment, step S250 is depicted as being performed immediately after step S230 and before step S270. However, it is expressly contemplated that step S250 may alternatively be performed after step S270 and before step S280, or may alternatively be performed after step S280 and before step S290, or may alternatively be performed after step S250.

[0060] At step S270, in response to the positive verification of the hash of the other application at step S230, the hash of the other application is stored on the device. In other examples, the hash of the other application may be stored in an off-device storage device.

[0061] At step S280, the device obtains and loads another application and performs a verification process on the other application. Specifically, the device uses the stored hash of the other application and the second hash function to verify the obtained another application, for example, by generating the hash of the obtained another application by the device itself and comparing it with the stored hash of the other application.

[0062] Like the first hash function, the second hash function can be a cryptographic hash function for further enhancing security. Examples of suitable hash algorithms include MD5, the SHA family (e.g., SHA-256), or any other suitable hash algorithm. In some examples, the first hash function algorithm and the second hash function algorithm use the same calculation function, but take different data as input.

[0063] In response to the positive verification of the other application at step S280, the depicted method proceeds to step S290 of executing the other application. In other examples, the other application may not be executed immediately in response to the positive verification, but instead the device is left in a state ready to execute the other application on demand at some future point. In response to the negative verification of the other application at step S280, the other application is not executed, and in some examples the other application is uninstalled. In some examples, after the first application has been executed onto the device, the hash of the first application may be discarded to recover the memory used by the hash.

[0064] Although the specific steps are Figure 1 and Figure 2 , but it should be appreciated that various of these steps are optional and / or may be performed in alternative orders. Many such optional steps and alternative orders have been explicitly recited in the description of the first and second example methods above, however, it is explicitly contemplated that certain other steps may be optional and / or performed in alternative orders, for example, as set forth in the claim set.

[0065] Figure 3 An example of an electronic device 300 is schematically illustrated. The device has a processing circuit 310 for performing data processing in response to program instructions, and a data storage device 320 for storing data and instructions to be processed by the processing circuit 310. The data storage device 320 may have a secure area 330 protected by a hardware mechanism (e.g., using a memory protection unit or security mechanism that provides a trusted execution environment) or by a software mechanism (e.g., encryption), so that data stored in the secure area 330 is inaccessible to software that is not executed in a trusted environment. The device 300 has a communication interface 340 for communicating with an external device. For example, the communication interface 340 can use any other range of different communication protocols, such as Ethernet, The device may have one or more sensors 350 for sensing certain external conditions such as temperature, pressure, proximity of a nearby user, etc. The specific sensors 350 provided may depend on the purpose of the device. It should be appreciated that Figure 3 These are merely examples of possible hardware that may be provided in a device, and other components may also be provided. For example, some devices that expect user interaction may be provided with a display and / or user interface module to display information to the user and receive input from the user. Other types of devices may simply be sensors that capture data and send that data to an external device, so these types of devices may not require a user interface or display. In some examples, the device does not include dedicated hardware asymmetric verifier circuitry (e.g., asymmetric acceleration hardware), so that any asymmetric verification must be performed by "general purpose" processing circuitry 310.

[0066] The methods discussed above may be performed under the control of a computer program executed on a device. Thus, the computer program may include instructions for controlling the device to perform any of the methods discussed above. The program may be stored on a storage medium. The storage medium may be a non-transitory recording medium or a transient signal medium.

[0067] In this application, the words "configured to..." are used to mean that elements of a device have a configuration that is capable of performing a defined operation. In this context, "configuration" means 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 imply that the device elements need to be changed in any way in order to provide the defined operation.

[0068] Although illustrative teachings of the present disclosure have been described in detail herein with reference to the accompanying drawings, it should be understood that the invention is not limited to those precise teachings and that various changes and modifications may be effected 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 verification extension method for a device, the method comprising: Responsive to a request to verify a signature associated with first data, obtaining an asymmetric verifier application from an off-device storage device; loading the asymmetric validator application; executing the asymmetric validator application; verifying the signature associated with the first data using asymmetric key cryptography using the asymmetric verifier application, wherein the first data is another application, wherein, prior to executing the asymmetric authenticator application, the asymmetric authenticator application is verified using a first hash function and an initial application hash, and the asymmetric authenticator application is executed in response to a positive verification result, and The initial application hash is retrieved from a storage device on the device.

2. The verification extension method according to claim 1, wherein: The signature associated with the first data is a signature of a hash of the first data.

3. The verification extension method according to claim 1, wherein: The asymmetric authenticator application is authenticated using a primary boot loader of the device.

4. The verification extension method according to claim 1, wherein: The initial application hash is embedded on the device during manufacture or assembly of the device.

5. The verification extension method according to claim 1, wherein: The asymmetric verifier application verifies the signature using one or more keys stored in storage on the device.

6. The verification extension method according to claim 5, wherein: A plurality of keys are stored in an on-device storage device, wherein each of the keys is associated with a privilege level, and wherein restrictions associated with the privilege level of the key used to verify the signature associated with the first data are applied to the first data.

7. The verification extension method according to claim 5, wherein: The one or more keys are embedded on the device during manufacture or assembly of the device.

8. The verification extension method according to claim 1, wherein: The asymmetric verifier application verifies the signature using one or more keys embedded in the asymmetric verifier application.

9. The verification extension method according to claim 1, wherein: In response to a positive or negative verification of the signature associated with the first data, the asymmetric verifier application is uninstalled.

10. The verification extension method according to claim 1, wherein: A plurality of signatures corresponding to a plurality of data including the first data are verified using the asymmetric verifier application, and in response to completing independent positive or negative verification of the plurality of signatures, the asymmetric verifier application is uninstalled.

11. The verification extension method according to claim 1, wherein: Responsive to a positive verification of the signature associated with the first data, the first data is loaded.

12. The verification extension method according to claim 1, wherein: The signature associated with the first data is a signature of a hash of the first data, and in response to a positive verification of the signature associated with the first data, the hash of the first data is stored on the device.

13. The authentication extension method according to claim 12, further comprising: obtaining the first data; Loading the first data; and The first data is verified using the hash of the first data and a second hash function.

14. The verification extension method according to claim 13, wherein: In response to affirmative verification of the first data, the first data is executed or made available to the executable code.

15. The verification extension method according to claim 14, wherein: After the first data has been executed or becomes available to executable code, the hash of the first data is removed from the device.

16. The authentication extension method according to any one of claims 13 to 15, wherein: The algorithms of the first hash function and the second hash function use the same calculation function, but take different data as input.

17. The authentication extension method according to claim 1, wherein: The apparatus does not include a hardware asymmetric validator circuit. 18 . A storage medium storing a computer program for controlling a processor, wherein when the computer program is executed, the processor executes the authentication extension method according to claim 1 .

19. A device for performing an authentication extension method, the device comprising: a processing circuit for performing data processing; and A data storage device storing a computer program for controlling the processing circuit to execute the authentication extension method according to any one of claims 1 to 17.

Images