Method for accelerating sleep starting speed in Internet of Things

Abstract

The invention provides a method for accelerating sleep starting speed. The method may include determining that a system-on-chip (SoC) is in a sleep mode; determining that an awakening condition is met; calculating a second authentication key based on data stored in a flash memory of the SoC using a cryptographic algorithm; and comparing the second authentication key to a first authentication key, wherein the first authentication key is associated with a secure boot of the SoC and is obtained from a normally-on (AON) memory of the SoC; and awakening the SoC from a sleep mode in response to a comparison result that the first authentication key is the same as the second authentication key.

Description

Technical Field

[0001] The present disclosure generally relates to the startup of electronic devices. Specifically, example embodiments of the present disclosure address systems and methods for accelerating the sleep startup speed in Internet of Things (IoT) devices. Background Art

[0002] IoT is a network of physical objects (called "smart devices" or "IoT devices") that are embedded with sensors, software, and other technologies for enabling the connection and exchange of data with other devices via the Internet. For example, IoT devices are used for home automation to control lighting, heating and air conditioning, media and security systems, and camera systems. Many IoT devices have been provided that act as smart home control centers (home hubs) to connect different smart home products. IoT devices have also been used in many other applications. Application layer protocols and supporting frameworks for implementing such IoT applications have been provided.

[0003] The secure boot of IoT devices is an important process implemented by a software program permanently written into the read-only memory (ROM). It uses a public key stored in a one-time programmable (OTP) memory to verify one or more programs to be executed. If the verification is successful, the subsequent level of programs is loaded and verified, and the process is repeated. In this way, a chain of trust is formed, and the secure boot is the foundation and source of the chain of trust.

[0004] Over the past few years, power consumption has become an important focus in the IoT industry. Sleep mode is a power saving mode where all modules of an IoT device (including the CPU) are turned off except for the Always-On (AON) module. Since most modules are not working, IoT devices cannot detect attacks in sleep mode. Undetected attacks can modify, replace, or corrupt data in memory, causing serious harm to IoT devices. Summary of the invention

[0005] The present invention provides a method for accelerating the sleep startup speed. The method includes: determining that a system on chip (SoC) is in a sleep mode; determining that a wake-up condition is satisfied; using a cryptographic algorithm to calculate a second authentication key based on data stored in a flash memory of the SoC; and comparing the second authentication key with a first authentication key, wherein the first authentication key is associated with a secure startup of the SoC and is obtained from an always-on (AON) memory of the SoC; and waking up the SoC from the sleep mode in response to a comparison result that the first authentication key is the same as the second authentication key.

[0006] The present invention provides a system on chip (SoC). The SoC includes a processor, the processor being configured to: determine that the SoC is in a sleep mode; determine that a wake-up condition is satisfied; calculate a second authentication key based on data stored in a flash memory of the SoC using a cryptographic algorithm; compare the second authentication key with a first authentication key, wherein the first authentication key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; and wake up the SoC from the sleep mode in response to a comparison result that the first authentication key is the same as the second authentication key.

[0007] The present invention provides a non-transitory computer-readable storage medium. The computer-readable storage medium includes instructions, which, when executed by a computer, enable the computer to: determine that a system on chip (SoC) is in a sleep mode; determine that a wake-up condition is satisfied; calculate a second authentication key based on data stored in a flash memory of the SoC using a cryptographic algorithm; compare the second authentication key with a first authentication key, wherein the first authentication key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; and in response to a comparison result that the first authentication key is the same as the second authentication key, wake up the SoC from the sleep mode. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To facilitate identification of any particular element or activity discussed, the most significant digit or digits in a reference number refer to the figure numeral that first introduces that element or activity.

[0009] Figure 1 is a block diagram illustrating an Internet of Things (IoT) device according to some example embodiments.

[0010] Figure 2 is a schematic diagram illustrating data stored in a flash memory of an IoT device according to some example embodiments.

[0011] Figure 3 is a schematic diagram illustrating data stored in an always-on (AON) memory of an IoT device according to some example embodiments.

[0012] Figure 4 is a flow chart illustrating the operation of an IoT device when starting the IoT device from a sleep mode according to some example embodiments. DETAILED DESCRIPTION

[0013] The following description includes systems, methods, techniques, instruction sequences and computer machine program products that embody the illustrative embodiments of the present disclosure. In the following description, for the purpose of explanation, many specific details are set forth to provide an understanding of the various embodiments of the subject matter of the present invention. However, it will be apparent to those skilled in the art that the embodiments of the subject matter of the present invention can be implemented without these specific details. Typically, well-known instruction instances, protocols, structures and techniques need not be shown in detail.

[0014] As mentioned above, when an IoT device boots up (or wakes up) from sleep mode, an attack in sleep mode cannot be detected. Direct booting is insecure, and performing the entire secure boot process is time-consuming and energy-consuming.

[0015] The present disclosure provides a system and method for starting an IoT device from sleep mode securely and at a fast speed. First, the IoT device is started under a complete secure boot process. After the secure boot process is completed, a first hash value (or a first authentication key) is calculated based on the data in the flash memory (e.g., a public key, a hash value of an image, a patch, and an image) and stored in the AON memory. When the IoT device enters sleep mode, the data in the flash memory may be modified, replaced, or damaged by an attack, while the first hash value stored in the AON memory remains unchanged. When the IoT device is awakened or started from sleep mode, a second hash value (or a second authentication key) is calculated based on the current data in the flash memory. The first hash value is then compared with the second hash value. If the first hash value and the second hash value are the same, the IoT device continues to start. If the first hash value and the second hash value are different, the IoT device remains in sleep mode and generates a notification that it has been attacked in sleep mode.

[0016] Therefore, the present disclosure potentially has at least the following advantages:

[0017] 1. Booting from sleep mode is faster than performing a full safe boot process.

[0018] 2. Attacks in sleep mode can be detected.

[0019] Figure 11 is a block diagram illustrating an Internet of Things (IoT) device 100 according to some example embodiments. The IoT device 100 may include a system on a chip (SoC) 102, a power supply 122, and an off-chip memory 124. The SoC 102 may include a processor 104, an on-chip memory 106, and a communication interface 120. The on-chip memory 106 may include a one-time programmable (OTP) memory 108, a content addressable memory (CAM) 110, a read-only memory (ROM) 112, a random access memory (RAM) 114, a flash memory (FLASH memory) 116, and / or a non-volatile read-write memory (NVM) 118.

[0020] The processor 104 can perform operations, logic, input / output (I / O), and other basic instructions. The processor 104 can make determinations, receive data from other components of the IoT device 100, and / or send data / instructions to other components.

[0021] The OTP memory 108 may be a non-volatile memory that allows data to be written only once. Once the memory is programmed, it retains its value when power is removed. The OTP memory 108 may be used in applications where reliable and repeatable read data is required. Examples include boot code, encryption keys, and configuration parameters for analog, sensor, or display circuits. In some embodiments, the OTP memory 108 may be replaced by an electronic fuse (eFuse) or a physically unclonable function (PUF).

[0022] CAM 110 may be a data storage device that stores memories in a unit form. When any aspect of the memory is input, CAM 110 may compare the input with all stored data. In CAM 110, the memories are not arranged in chronological order and are not packaged in isolated modules.

[0023] ROM 112 is a type of electronic memory built into IoT device 100 during manufacturing. ROM 112 can store "firmware," which is permanent software hardwired into an integrated circuit. Manufacturers can install specially designed ROM chips into the device during the build process. Unlike the non-volatile memory of a hard drive, rewriting ROM 112 is difficult and time-consuming.

[0024] RAM 114 is a form of memory that can be read and changed in any order and is typically used to store working data and machine code. Compared to other direct access data storage media, RAM 114 can allow data items to be read or written in nearly the same amount of time regardless of the data's physical location within the memory. Among them, due to mechanical limitations such as media rotation speed and arm movement, the time required to read and write data items varies significantly depending on their physical location on the recording medium.

[0025] Flash memory 116 is a long-life, non-volatile memory chip widely used in embedded systems. Flash memory 116 can maintain stored data and information even when power is off. Flash memory 116 can be electrically erased and reprogrammed. Because flash memory 116 can be easily modified (in other words, attacked), flash memory 116 can include additional data for security purposes, such as public keys, image hash values, manifest signatures, etc.

[0026] NVM 118 is a computer memory that can retain saved data even when power is off. Unlike volatile memory, NVM 118 does not need to periodically refresh its stored data. As described above, ROM 112 is a type of NVM, and OTP memory 108 also becomes a type of NVM after being programmed once. NVM 118 herein may refer to other non-volatile memories. In some embodiments, NVM 118 may be omitted.

[0027] The communication interface 120 can facilitate communication between the IoT device 100 or its components and external devices. The communication can be wired or wireless.

[0028] The power supply 122 may be an electrical device that supplies power to the SoC 102. In some embodiments, whenever the power supply 122 is turned on, the SoC 102 may perform a secure boot.

[0029] The off-chip memory 124 may be memory that is not on the SoC 102. The off-chip memory 124 typically has more latency than the on-chip memory 106, which means that less frequently used or less critical data may be stored in the off-chip memory 124. In some embodiments, the off-chip memory 124 may be used as a replacement for one or more on-chip memories 106.

[0030] The on-chip memory 106 may also include an always-on (AON) memory 126. The AON memory 126 is a type of non-volatile memory that retains its data even when power is lost. Unlike volatile memory, which loses its data when power is turned off, the AON memory 126 allows data to be permanently stored and does not require an external power source to maintain the data. Details regarding the data stored in the AON memory 126 may be found elsewhere in this disclosure. For example, see Figure 3 and its description.

[0031] In some embodiments, the IoT device 100 may also include functional components based on the desired functions of the IoT device 100. For example, the IoT device 100 may include sensors, speakers, displays, lights, cameras, microphones, etc. or any combination thereof.

[0032] It should be noted that although the present disclosure is described using IoT devices as an example, the present disclosure can be used in any other applicable system or device without departing from the spirit of the present disclosure. For example, the present method can be used by any device, including a SoC that has a need to accelerate the sleep startup speed while also detecting attacks in sleep mode. As another example, the present method can be used by a device to accelerate the startup speed from other power saving modes.

[0033] Figure 2 is a schematic diagram showing data stored in the flash memory 116 of the IoT device 100 according to some example embodiments. Figure 2 As shown, flash memory 116 may include manifest signature 202 , public key 204 , image hash 206 , patch 208 , and / or image 210 .

[0034] Manifest signature (also called digital signature) 202 may be a value calculated based on the manifest (signature data) and the private key. The manifest collectively refers to the public key 204, the image hash value 206, and / or the patch 208. The private key may be paired with the public key 204. The public key may be used to decrypt any information encrypted by the private key to the original information, and vice versa. The private key may not be known to anyone except the designer or manufacturer.

[0035] The public key 204 may be a series of numbers created by a symmetric or asymmetric algorithm. The public key 204 may be generated based on a symmetric or asymmetric algorithm using a paired private key. For a symmetric algorithm, the generated public key 204 and the paired private key are the same. For an asymmetric algorithm, the generated public key 204 and the paired private key are different.

[0036] The IoT device 100 can use a cryptographic algorithm to generate a public key hash value based on the public key 204. During a secure boot, the public key hash value can be compared with a public key hash value pre-stored in the OTP memory 108. The cryptographic algorithm can include a secure hash algorithm (SHA) and / or a message authentication code (MAC) algorithm or other algorithms. The SHA algorithm can include a SHA-2 algorithm and / or a SHA-3 algorithm. The SHA-2 algorithm can include a SHA-224 algorithm, a SHA-256 algorithm, a SHA-384 algorithm, and / or a SHA-512 algorithm.

[0037] The image hash value 206 may be a value generated based on the image 210 using a cryptographic algorithm. For example only, the image hash value 206 is generated using the SHA-256 algorithm and is 256 bits long. It should be noted that the image 210 used herein may refer to a code image of an executable program rather than a picture. After passing through the secure boot of the IoT device 100, the image 210 may be executed by the IoT device 100 to perform certain functions.

[0038] The patch 208 may include a code image of a patch that is desired to be applied to the IoT device 100. In some embodiments, the patch 208 may be designed to cure a problem or defect in the IoT device 100, or to update a portion or all of the IoT device 100. For example, the patch 208 may change at least one hardware property of the SoC 102 of the IoT device 100 (e.g., the clock frequency of the flash memory). As another example, the patch 208 may change a software function related to the startup of the IoT device 100. For example, the change in software function may be achieved by changing a function call table stored in the ROM 112.

[0039] Figure 3 is a schematic diagram showing data stored in the AON memory 126 of the IoT device 100 according to some example embodiments. Figure 3 As shown, the AON memory 126 may include a public key hash value 302 , an image hash value 304 , a patch hash value 306 , and a collection hash value 308 .

[0040] The public key hash value 302 may be a value calculated based on the public key using a cryptographic algorithm. In some embodiments, the public key hash value 302 is calculated based on the public key 204. Alternatively, the public key hash value 302 is obtained directly from the OTP memory 108. The public key hash value 302 may be calculated or obtained at any time during the secure boot of the IoT device 100 or before the IoT device 100 enters sleep mode.

[0041] Image hash value 304 may be a value calculated based on the image using a cryptographic algorithm. In some embodiments, image hash value 304 is calculated based on image 210. Alternatively, image hash value 304 is a copy of image hash value 206. Image hash value 304 may be calculated or obtained at any time during a secure boot of IoT device 100 or before IoT device 100 enters sleep mode.

[0042] The patch hash value 306 may be a value calculated based on the patch using a cryptographic algorithm. In some embodiments, the patch hash value 306 is calculated based on the patch 208. Alternatively, the patch hash value 306 is obtained directly from the OTP memory 108. The patch hash value 306 may be calculated or obtained at any time during a secure boot of the IoT device 100 or before the IoT device 100 enters sleep mode.

[0043] The set hash value 308 may be a value calculated using a cryptographic algorithm based on one or more sets of data stored together in the flash memory 116 (or OTP memory 108). For example, the set hash value 308 is generated based on the manifest data (including the public key 204, the image hash value 206, the patch 208) and the image 210.

[0044] It should be noted that the hash values ​​302-308 mentioned herein are merely examples and should not be limiting. The idea of ​​the present disclosure is to pre-store (one or more) short encrypted values ​​in the AON memory before the IoT device enters sleep mode, and to calculate (one or more) values ​​again from the same source in the IoT device 100 after the IoT device is awakened. These values ​​are compared with each other to check whether the device is attacked during sleep mode. Unlike the secure boot process that compares full-length public keys, the comparison of hash values ​​is much faster (at least 1 times and up to 10 times faster).

[0045] Figure 4 4 is a flowchart illustrating the operation of an IoT device when starting the IoT device from a sleep mode according to some example embodiments. The method 400 may be embodied in computer-readable instructions for execution by one or more processors, such that the operations of the method 400 may be performed in part or in whole by functional components of the IoT device 100; therefore, the method 400 is described below with reference thereto by way of example. However, it should be understood that at least some of the operations of the method 400 may be deployed on various other hardware configurations in addition to the IoT device 100. Furthermore, the operations of the method 400 may be partially omitted or performed in any order.

[0046] In operation 402, the IoT device 100 may obtain a first authentication key (or a first hash value) associated with a secure boot of a system on chip (SoC). The first authentication key may be generated based on one or more sets of data stored in the flash memory 116 or the OTP memory 108 using a cryptographic algorithm. Examples of the first authentication key may include a public key hash value 302, an image hash value 304, a patch hash value 306, a set hash value 308, and the like. In some embodiments, the first authentication key may be generated during a secure boot of the IoT device 100. Alternatively, the first authentication key is generated after a secure boot of the IoT device 100 but before the IoT device enters sleep mode. For example, the first authentication key is a set hash value 308 generated based on the public key 204, the image hash value 206, the patch 208, and the image 210 using the SHA-256 algorithm.

[0047] In operation 404, the IoT device 100 may write the first authentication key to the AON memory before the SoC enters the sleep mode. The IoT device 100 may write part (e.g., the first 32 bits) or all bits of the calculated first authentication key to the AON memory. Then, the IoT device 100 may enter the sleep mode while all modules in the IoT device 100 are turned off (except the AON memory).

[0048] In operation 406, the IoT device 100 may determine that a wake-up condition is satisfied. The wake-up condition may include receiving a user interaction with the device, such as pressing a button or clicking a screen, reaching a preset wake-up time, passing a preset duration, receiving an internal wake-up trigger signal, receiving an external wake-up instruction, sensing motion or falling, sensing a change in light conditions, sensing a change in sound conditions, etc.

[0049] In operation 408, the IoT device 100 can calculate a second authentication key. In some embodiments, the second authentication key is calculated based on one or more sets of data stored in the same source used to generate the first authentication key using the same cryptographic algorithm. For example, the second authentication key is a collective hash value generated based on the public key 204, the image hash value 206, the patch 208, and the image 210 using the SHA-256 algorithm.

[0050] In operation 410, the second authentication key is compared with the first authentication key. In some embodiments, all bits of the first authentication key and the second authentication key are compared. Alternatively, only a portion (e.g., the first 16 bits, the first 32 bits) of the first authentication key and the second authentication key are compared.

[0051] In operation 412, the IoT device 100 may determine whether the first authentication key is the same as the second authentication key. In response to determining that the first authentication key is the same as the second authentication key, the method 400 proceeds to 414 and wakes up the SoC (or booting of the IoT device continues); otherwise, the method 400 proceeds to 416.

[0052] In operation 416, the IoT device 100 may keep the SoC in sleep mode. The IoT device 100 may allow limited modules or components to be awakened and perform limited work. For example, the communication interface 120 may be awakened to receive or send a signal. As another example, an onboard error indicator (e.g., an LED) is allowed to light up. Most modules and components are in sleep mode to avoid further damage to the IoT device.

[0053] In operation 418, the IoT device 100 may generate a notification that the SoC was attacked during sleep mode. In some embodiments, the notification may be generated to one or more components of the IoT device 100. Additionally or alternatively, the notification may be generated to an external device (e.g., a user mobile device, a server) via, for example, the communication interface 120. Example

[0054] 1. A method comprising: Determine if the system on chip (SoC) is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; and In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from a sleep mode.

[0055] 2. The method of Example 1, wherein the first authentication key is written to the AON memory before the SoC enters the sleep mode.

[0056] 3. The method according to any of the preceding examples, further comprising: In response to a comparison result that the first attestation key is different from the second attestation key, the SoC is maintained in the sleep mode.

[0057] 4. The method of any of the preceding examples, wherein, in response to a comparison result that the first authentication key is different from the second authentication key, the method further comprises: A notification is generated that the SoC was attacked during the sleep mode.

[0058] 5. A method according to any of the preceding examples, wherein the second authentication key comprises: A signing key calculated based on the signature data read from the flash memory.

[0059] 6. A method according to any of the preceding examples, wherein the second authentication key comprises: An image key is calculated based on the code image read from the flash memory.

[0060] 7. A method according to any of the preceding examples, wherein the second authentication key does not include a public key.

[0061] 8. The method of any preceding example, wherein comparing the first authentication key with the second authentication key comprises: A portion of the first attestation key is compared to a corresponding portion of the second attestation key.

[0062] 9. The method of any preceding example, wherein comparing the first authentication key to the second authentication key comprises: The first 32 bits of the first authentication key are compared with the first 32 bits of the second authentication key.

[0063] 10. A method according to any of the preceding examples, wherein the first authentication key is read from a one-time programmable (OTP) memory of the SoC during a secure boot of the SoC.

[0064] 11. The method according to any of the preceding examples, wherein the wake-up condition comprises: receiving a wake-up command signal from an external device; Sticking in said sleep mode for a predetermined duration; or A wake-up trigger signal is received from an internal component of the SoC.

[0065] 12. A system on chip (SoC), comprising: The processor is configured as: Determining that the SoC is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; and In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from the sleep mode.

[0066] 13. The SoC of Example 12, wherein the first authentication key is written to the AON memory before the SoC enters the sleep mode.

[0067] 14. The SoC of any preceding example, wherein the processor is further configured to: In response to a comparison result that the first attestation key is different from the second attestation key, the SoC is maintained in the sleep mode, and a notification is generated that the SoC is under attack during the sleep mode.

[0068] 15. The SoC of any preceding example, wherein the second authentication key comprises: A signing key calculated based on the signature data read from the flash memory.

[0069] 16. The SoC of any preceding example, wherein the second authentication key comprises: An image key is calculated based on the code image read from the flash memory.

[0070] 17. The SoC of any preceding example, wherein comparing the first attestation key to the second attestation key comprises: A portion of the first attestation key is compared to a corresponding portion of the second attestation key.

[0071] 18. The SoC of any of the preceding examples, wherein the first authentication key is read from a one-time programmable (OTP) memory of the SoC during a secure boot of the SoC.

[0072] 19. The SoC of any preceding example, wherein the wake-up condition comprises: receiving a wake-up command signal from an external device; Sticking in said sleep mode for a predetermined duration; or A wake-up trigger signal is received from an internal component of the SoC.

[0073] 20. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: Determine if the system on chip (SoC) is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; and In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from the sleep mode. in conclusion

[0074] The present disclosure provides a system and method for starting an IoT device from sleep mode securely and at a fast speed. After the secure boot is completed, a first hash value (or a first authentication key) is calculated based on the data in the flash memory (e.g., a public key, a hash value of an image, a patch, and an image) and stored in the AON memory. When the IoT device is awakened or started from sleep mode, a second hash value (or a second authentication key) is calculated based on the current data in the flash memory. The first hash value is then compared with the second hash value to determine whether to start the IoT device or keep it in sleep mode. Therefore, the present disclosure potentially has at least the following advantages: 1. The boot speed from sleep mode is faster than performing the entire secure boot process. 2. Attacks in sleep mode can be detected.

Claims

1. A method, characterized in that include: Determine if the system on chip (SoC) is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; as well as In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from the sleep mode.

2. The method according to claim 1, characterized in that Before the SoC enters the sleep mode, the first authentication key is written to the AON memory.

3. The method according to claim 1, characterized in that Also includes: In response to a comparison result that the first attestation key is different from the second attestation key, the SoC is maintained in the sleep mode.

4. The method according to claim 3, characterized in that In response to a comparison result that the first authentication key is different from the second authentication key, the method further includes: A notification is generated that the SoC was attacked during the sleep mode.

5. The method according to claim 1, characterized in that The second authentication key includes: A signing key calculated based on the signature data read from the flash memory.

6. The method according to claim 1, characterized in that The second authentication key includes: An image key is calculated based on the code image read from the flash memory.

7. The method according to claim 1, characterized in that The second authentication key does not include a public key.

8. The method according to claim 1, characterized in that Comparing the first authentication key with the second authentication key includes: A portion of the first attestation key is compared to a corresponding portion of the second attestation key.

9. The method according to claim 1, characterized in that: Comparing the first authentication key with the second authentication key includes: The first 32 bits of the first authentication key are compared with the first 32 bits of the second authentication key.

10. The method according to claim 1, characterized in that During a secure boot of the SoC, the first authentication key is read from a one-time programmable (OTP) memory of the SoC.

11. The method according to claim 1, characterized in that The wake-up conditions include: receiving a wake-up command signal from an external device; Sticking in said sleep mode for a predetermined duration; or A wake-up trigger signal is received from an internal component of the SoC.

12. A system on chip (SoC), characterized in that: include: The processor is configured as: Determining that the SoC is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; as well as In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from the sleep mode.

13. The SoC according to claim 12, characterized in that: Before the SoC enters the sleep mode, the first authentication key is written to the AON memory.

14. The SoC according to claim 12, characterized in that: The processor is further configured to: In response to a comparison result that the first attestation key is different from the second attestation key, the SoC is maintained in the sleep mode, and a notification is generated that the SoC is under attack during the sleep mode.

15. The SoC according to claim 12, characterized in that: The second authentication key includes: A signing key calculated based on the signature data read from the flash memory.

16. The SoC according to claim 12, characterized in that: The second authentication key includes: An image key is calculated based on the code image read from the flash memory.

17. The SoC according to claim 12, characterized in that: Comparing the first authentication key with the second authentication key includes: A portion of the first attestation key is compared to a corresponding portion of the second attestation key.

18. The SoC according to claim 12, characterized in that: During a secure boot of the SoC, the first authentication key is read from a one-time programmable (OTP) memory of the SoC.

19. The SoC according to claim 12, characterized in that: The wake-up conditions include: receiving a wake-up command signal from an external device; Sticking in said sleep mode for a predetermined duration; or A wake-up trigger signal is received from an internal component of the SoC.

20. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: Determine if the system on chip (SoC) is in sleep mode; Determine that the wake-up conditions are met; Calculate a second authentication key based on data stored in the flash memory of the SoC using a cryptographic algorithm; comparing the second attestation key to a first attestation key, wherein the first attestation key is associated with a secure boot of the SoC and is obtained from an always-on (AON) memory of the SoC; as well as In response to a comparison result that the first attestation key is the same as the second attestation key, waking up the SoC from the sleep mode.

Images