CN117708897A

CN117708897A - Method for protecting firmware data of embedded device and embedded device

Info

Publication number: CN117708897A
Application number: CN202311739833.5A
Authority: CN
Inventors: 王豫新; 徐春光; 巫建刚
Original assignee: Espressif Systems Shanghai Co Ltd
Current assignee: Espressif Systems Shanghai Co Ltd
Priority date: 2023-12-15
Filing date: 2023-12-15
Publication date: 2024-03-15

Abstract

The application discloses a method for protecting embedded device firmware data, comprising the following steps: during startup of the embedded device, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed such that: acquiring a signature public key stored in a loading bootstrap program in a nonvolatile memory of the embedded device, and verifying the signature public key according to a signature public key abstract stored in a one-time programmable memory of the embedded device; and in response to the signature public key verification passing, performing signature verification on the load boot program using the signature public key; and in response to the load bootstrap signature verification passing, executing the load bootstrap such that: and carrying out signature verification on the application program firmware according to the signature public key. The method and the device establish the firmware data for completely protecting the embedded equipment, prevent illegal tampering, and facilitate batch enabling safe operation and subsequent maintenance while protecting the data safety.

Description

Method for protecting firmware data of embedded device and embedded device

Technical Field

The present disclosure relates to the field of embedded technologies, and in particular, to a method for protecting firmware data of an embedded device and an embedded device.

Background

The internet of things terminal is embedded electronic equipment with network connection capability, and can realize data exchange and control with other equipment or cloud. The application field of the terminal of the Internet of things is very wide, and the terminal of the Internet of things covers a plurality of fields such as intelligent home, intelligent industry, medical care and the like. The core part of the internet of things terminal is firmware, namely an executable program running in the internet of things terminal, which is responsible for coordinating the scheduling of system internal resources and the function of communicating with external equipment. Typical firmware data includes two parts, a bootloader (bootloader) running in the terminal, and an application (app).

The security of the firmware data is very important for developers, maintenance personnel and users of the terminal of the Internet of things. On the one hand, the firmware data define the functions of the device, and is the core competitiveness of the terminal of the internet of things. If the firmware data is stolen, the same type of competing manufacturer may copy the firmware data to its own product, so that the market competitiveness of the original product is reduced. On the other hand, if the firmware data is destroyed, the function of the device may be abnormal, and even the embedded malicious program threatens the personal privacy and life safety of the user. For example, some terminals of the internet of things may relate to sensitive information such as health data, location information, payment information, etc. of the user, and if the sensitive information is revealed or tampered, serious loss may be caused to the user.

To protect the security of firmware, the following protection of firmware data is typically required:

1) Integrity of the data. This means that the firmware data cannot be lost or corrupted during transmission and storage to ensure that its data is complete. The integrity of the firmware data is typically checked by computing a digest of the firmware. The specific operation method can be briefly described as follows: when a developer makes firmware, packing the firmware data and a picker corresponding to the firmware data into an accessory, and then sending the accessory to a device end; before the firmware data is applied, the device side recalculates the abstract of the firmware data and compares the abstract with the abstract in the accessory. If the two are identical, it is stated that the firmware data is intact.

2) Confidentiality of data. This means that the firmware data must be transmitted and stored in an encrypted manner and cannot be easily obtained or used by unspecified developers. Confidentiality of data is typically protected by data encryption computation. The specific operation method can be briefly described as follows: when transmitting or storing firmware data, the firmware data is encrypted so that it cannot be directly read or modified. And when the firmware data is used, the firmware data is decrypted through a professional hardware module in the chip and then loaded for use.

3) And protecting the legitimacy of the data. This means that the firmware data must be from a legitimate data issuing authority and that the firmware data needs to contain information that can identify the firmware issuer. The legitimacy of the data is usually verified by a digital signature algorithm. Common signature algorithms are RSA algorithm and DSA algorithm. The signature algorithm is an asymmetric algorithm, as shown in fig. 1, requiring the data issuer to generate a pair of private and public key pairs. Wherein the private key and the public key are keys having a correspondence relationship. The private key of the data issuer may sign the firmware data to generate a signature message, and the data receiver (e.g., embedded device side) may verify the signature message using the public key to determine whether the firmware data is authorized by the matching private key signature. The specific operation method can be briefly described as follows: when a developer makes firmware, a pair of private keys and public keys are generated, then the private keys are used for signing the firmware data, and finally the firmware data and signature information are packaged together to form an accessory and sent to the equipment end. Before the firmware data is applied, the device side firstly uses the public key burnt in the device in advance to check the firmware data and the signature information, and if the verification is passed, the firmware data is made by a legal data issuing mechanism.

The current firmware data protection scheme mainly guarantees the security of data in the transmission process, such as using HTTPS encryption transmission protocol to transmit firmware. But there are few security protection schemes for firmware data stored on the device.

Firmware data is typically stored in programmable memory of the system, such as in storage media like Flash, SD cards, etc. After the development of the terminal of the Internet of things is finished or after the equipment leaves the factory, the access to the firmware mainly comprises the following three aspects:

1. and reading the firmware data on the terminal. The firmware data in the memory is read mainly through a peripheral interface reserved by the terminal of the Internet of things, such as a UART interface.

2. The firmware data on the terminal is rewritten. This is mainly by way of a reserved peripheral interface or OTA remote firmware update to modify or replace the firmware data in the memory.

3. Firmware data on the application terminal. This is mainly that the CPU reads firmware data from the memory into the register, then parses instructions and data in the firmware data, and executes corresponding functions according to the instructions and data.

In order to improve the security of firmware stored in the device, some device manufacturers may use some security schemes, and common examples are:

1. And carrying out signature verification according to the starting flow. Some embedded devices in common typically have three programs, namely an initial boot-up program segment (Rom Code), a load boot program (bootloader), and an application program (app). Wherein the initial startup procedure section is non-modifiable data fixed on the chip, which will check if the signature verification function is enabled, and if so, verify the next procedure, i.e. the load boot procedure. If the verification is successful, the loading and loading bootstrap program is operated. Similarly, the loading bootstrap program can also carry out signature verification on the application program, and if verification is successful, the loading application program runs. Thus, through layer-by-layer signature verification, the firmware can be ensured to come from legal publishers. However, there is still a risk of the root of trust being tampered with or destroyed in existing trust chain mechanisms.

2. And (5) encrypting the firmware. To ensure that the firmware can be read from the device for decryption, the firmware is typically encrypted using a uniform key and then sent to the device. All devices use the same encrypted firmware. There are also schemes for generating the key internally to the device so that the key is not known externally and thus the firmware on the device cannot be decrypted, but this also results in the maintenance personnel not being able to decrypt the firmware on the device.

3. And closing the data read-write interface of the equipment. By closing the physical access interface, a person touching the device can be prevented from reading and writing firmware data through a serial-port like device. But this also sacrifices maintainability of the device. To occupy the market faster and release new products, equipment manufacturers typically need multiple product iterations, and each time a problem occurs with a product, repeated read and write operations are required to be performed on the firmware of the equipment to identify and solve the software and hardware problems of the equipment. Therefore, this method causes inconvenience in practical application, thereby affecting development efficiency.

However, these usual safety measures as described above still have a number of problems, in particular:

1. the mechanism for enabling the security functions of the device is complex, resulting in inconvenience to the developer to enable the security functions in large quantities. Such an operation is very cumbersome and time consuming for a large number of devices.

2. The safety scheme is not uniform and is inconvenient to use in batches. While some existing schemes use a uniform key to encrypt the firmware, such a key, if compromised, can result in all devices being hacked. While the key of each device is different for the existing scheme realizing one-machine-one-pad, a complex key management strategy is needed, and a special maintenance scheme is provided for each device, so that the scheme is inconvenient to implement in batches.

3. And the maintenance is inconvenient. For equipment manufacturers, after the safety functions are started, some equipment cannot read and write the data on the equipment again, which makes the equipment difficult to repair in factory. Because maintenance personnel need to read and write data on the device to analyze the cause of the abnormality, if the firmware on the device is encrypted and the key is only present inside the device, the maintenance personnel cannot decrypt the firmware on the device and cannot analyze the problem of the firmware.

4. For the user, the security performance of the device is insufficient, and an attacker can inject an executable illegal program into the embedded device through an OTA or physical burning mode, so that the firmware data and the user information of the device are tampered or stolen. For example, if the firmware on the device does not perform signature verification, then the attacker may send a fake firmware in an OTA manner, so that the device loads and runs, and thus the behavior of the device is controlled. For another example, if a key for signature verification is compromised, an attacker can forge the signature data, thereby implementing the forged firmware data.

In particular, if one-machine-one-encryption is to be realized in the prior art, two problems of key management and encryption key and encryption firmware introduction are mainly involved. The conventional key management method includes the following: (a) recording a key: each device is numbered, and the corresponding relation between the number and the secret key is recorded. How many devices are, how many the number of bars is recorded. In this method, the maintenance of the key is cumbersome. (b) employing a unified key: some developers often discard a secret for convenience, and choose to set the same key for all devices. Moreover, since the developer needs to record these keys, there is a risk of key leakage. Therefore, this management method can easily import the key and import the encrypted firmware, but there is a risk of disclosure of the key. (c) The key is randomly generated inside the device without management at the host: in some technical solutions, each device automatically generates a random key inside, but the outside does not know the key information. The method has the advantages of high safety and simple management, but has the defects that the encrypted firmware is difficult to import, and the equipment firmware cannot be decrypted, analyzed and updated when the equipment returns to a factory for maintenance. Because the secret key only exists in the device, the device can encrypt the firmware only, and even if the device can encrypt the device by introducing an unencrypted firmware, the device can also face the risks of slow running speed of the embedded device, long time consumption in the encryption process, power failure interruption and the like. Once a power loss breaks the encryption process, the outside does not know the key, and the device may need to be manually repaired or even completely damaged. Therefore, a security scheme for realizing one-machine-one-key is not available in the prior art, which is convenient for key management, batch introduction of encryption firmware and later maintenance.

In summary, firmware security of embedded devices is an important issue, which relates to the integrity, confidentiality, legitimacy, and the like of data. In order to protect the security of firmware, the prior art scheme mainly comprises signature verification based on trust root, data encryption, hardware isolation and the like. However, these schemes have problems such as complicated mechanisms for enabling the security function, non-uniform security schemes, inconvenient maintenance, insufficient security performance, and the like. Therefore, a new technical solution is needed, which can effectively improve the firmware security of the embedded device, and can be conveniently implemented to leave the factory as soon as possible, and is convenient to maintain in a later period.

It should be understood that the above-listed technical problems are merely examples and are not limiting of the present invention, and the present invention is not limited to the technical solutions that solve all the above-mentioned technical problems at the same time. The technical solution of the present invention may be implemented to solve one or more of the above or other technical problems.

Disclosure of Invention

To solve the above and other problems, the present application provides a method for protecting embedded device firmware data, the method comprising the steps of: during startup of the embedded device, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed such that: reading an interaction pattern identifier from the OTP memory, the interaction pattern identifier being used to indicate whether an interaction pattern of the embedded device is enabled; and in response to the interaction mode identifier indicating an interaction mode enabling the embedded device, obtaining an external key according to the received first external instruction, and generating a symmetric key based on the external key and a unique identification code of the embedded device stored in the OTP memory; wherein the symmetric key is used to encrypt or decrypt firmware stored in the non-volatile memory. Preferably, after the symmetric key is generated, it is stored in the OTP memory. The acquired external key may preferably also be written to the OTP memory.

Optionally, the firmware includes a load boot program; the method further includes executing the initial startup procedure segment such that: reading a symmetric key from the OTP memory in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device; and decrypting the load boot program in the nonvolatile memory using the symmetric key.

Optionally, the method further comprises executing the initial startup procedure segment such that: in response to the interaction pattern identifier indicating that the interaction pattern of the embedded device is enabled, the interaction pattern identifier in the OTP memory is modified to turn on or off the interaction pattern of the embedded device in accordance with the received second external instruction.

Further optionally, the method further comprises executing the initial startup procedure segment such that: after decrypting the load boot program in the non-volatile memory using the symmetric key, the load boot program is integrity checked.

Further optionally, the method further comprises executing the initial startup procedure segment such that: in response to the loading bootstrap program passing the integrity check, obtaining a signature public key stored in the loading bootstrap program, and verifying the signature public key according to a signature public key digest stored in the OTP memory; and in response to the signature public key verification passing, performing signature verification on the loading bootstrap program using the signature public key.

Optionally, the firmware comprises an application program, the method further comprising executing a load boot program to cause: decrypting the application in the firmware using the symmetric key; and performing integrity check on the application program. Optionally, the method further comprises executing the load boot program such that: in response to the application passing the integrity check, the application is signature checked according to the signature public key.

Optionally, the method further comprises receiving the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application according to the public signature key in the loading bootstrap program.

Further optionally, the update application includes instructions for re-enabling the interaction mode of the embedded device, which when executed modifies the interaction mode identifier in the OTP memory such that the interaction mode identifier indicates that the interaction mode of the embedded device is enabled.

The application also provides an embedded device, which comprises a read-only memory (ROM), a nonvolatile memory, a one-time programmable (OTP) memory and an encryption and decryption circuit; the OTP memory stores an interaction mode identifier and a unique identification code of the embedded equipment, and the nonvolatile memory stores firmware; the embedded device is configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up such that: reading the interaction pattern identifier from the OTP memory; responding to the interaction mode identifier to indicate the interaction mode of the enabled embedded device, acquiring an external key according to the received first external instruction, and generating a symmetric key based on the external key and a unique identification code of the embedded device; the symmetric key is used for encrypting and decrypting firmware in the nonvolatile memory. Preferably, after the symmetric key is generated, it is stored in the OTP memory. The acquired external key may preferably also be written to the OTP memory.

Preferably, the firmware includes a load boot program, and the embedded device is configured to execute an initial boot program segment in Read Only Memory (ROM) during boot up, such that: in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device, the encryption and decryption circuitry reads the symmetric key from the OTP memory; and the encryption and decryption circuit decrypts the load boot program in the nonvolatile memory using the symmetric key.

Preferably, the embedded device is further configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up, such that: in response to the interaction pattern identifier indicating that the interaction pattern of the embedded device is enabled, the interaction pattern identifier in the OTP memory is modified to turn on or off the interaction pattern of the embedded device in accordance with the received second external instruction.

Further preferably, the embedded device is further configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up, such that: after decrypting the load boot program in the non-volatile memory using the symmetric key, the load boot program is integrity checked.

Further preferably, the embedded device is further configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up, such that: responding to the loading bootstrap program to pass the integrity verification, acquiring a signature public key in the loading bootstrap program, and verifying the signature public key according to a signature public key abstract in the OTP memory; and in response to the signature public key verification passing, performing signature verification on the loading bootstrap program using the signature public key.

Further preferably, the firmware comprises an application program, and the embedded device is configured to execute the load boot program during startup such that: the encryption and decryption circuit decrypts the application program by using the symmetric key; and performing integrity check on the application program. Optionally, executing the load boot further causes: and in response to the application program passing the integrity check, performing signature check on the application program according to the signature public key in the loading bootstrap program.

Further preferably, the embedded device is configured to receive the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application according to the public signature key in the loading bootstrap program.

Further preferably, the update application includes instructions for re-enabling the interaction mode of the embedded device; and the embedded device is further configured to: when the update application is executed, the interaction pattern identifier in the OTP memory is modified such that the interaction pattern identifier indicates an interaction pattern of the embedded device is enabled.

The present application also provides a non-transitory computer readable medium having stored thereon computer readable instructions for providing firmware data protection in an embedded device; the computer readable instructions, when executed by a processor, cause the embedded device to perform any of the methods described above.

In addition, the application also provides a method for protecting firmware data of the embedded device, which comprises the following steps: during startup of the embedded device, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed such that: 1) Acquiring a signature public key stored in a loading bootstrap program in a nonvolatile memory of the embedded device, and verifying the signature public key according to a signature public key digest stored in a one-time programmable (OTP) memory of the embedded device; and in response to the signature public key verification passing, performing signature verification on the load boot program using the signature public key; 2) And, in response to the load bootstrap signature verification passing, executing the load bootstrap such that: and carrying out signature verification on the application program stored in the nonvolatile memory according to the public signature key.

Preferably, the method further comprises executing the initial startup procedure segment such that: before verifying the signature public key, carrying out integrity verification on the loading bootstrap program; and verifying the public signature key in response to the loading bootstrap program passing the integrity check.

Preferably, the method further comprises executing the initial startup procedure segment such that: before signature verification is carried out on the application program, carrying out integrity verification on the application program; and in response to the application passing the integrity check, performing a signature check on the application.

Preferably, the signature public key digest is written into the OTP memory according to the received external instruction when the embedded device is in a state in which the interaction mode is enabled.

Preferably, the method further comprises executing the initial startup procedure segment such that: reading the symmetric key from the OTP memory; and encrypting or decrypting the load boot program and/or boot identification and/or application program stored in the non-volatile memory using the symmetric key.

Further preferably, wherein reading the symmetric key from the OTP memory further comprises: reading an interaction mode identifier from the OTP memory, which indicates whether the embedded device is in an enabled interaction mode; and in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device, reading the symmetric key from the OTP memory.

Further preferably, the symmetric key is generated from an external key and a unique identification code of the embedded device, wherein the external key is obtained from the received first external instruction when the interaction mode of the embedded device is enabled. Preferably, the external key is also written to the OTP memory.

Preferably, the method further comprises receiving the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application program according to the signature public key.

Further preferably, the update application includes instructions for re-enabling the interaction mode of the embedded device, which when executed modifies the interaction mode identifier in the OTP memory such that the interaction mode identifier indicates that the interaction mode of the embedded device is enabled.

In addition, the present application also provides an embedded device comprising a Read Only Memory (ROM), a non-volatile memory, and a one-time programmable (OTP) memory; the read-only memory (ROM) stores an initial starting program section, the OTP memory stores a signature public key abstract, and the nonvolatile memory stores a loading bootstrap program and an application program; the embedded device is configured to execute an initial boot program segment during boot-up such that: 1) Acquiring a signature public key in the loading bootstrap program, and verifying the signature public key according to the signature public key abstract; and in response to the signature public key verification passing, performing signature verification on the load boot program using the signature public key; 2) And, in response to the load bootstrap signature verification passing, executing the load bootstrap such that: and carrying out signature verification on the application program according to the public signature key.

Preferably, the embedded device is further configured to execute an initial boot-up program segment during boot-up such that: before verifying the signature public key, carrying out integrity verification on the loading bootstrap program; and verifying the public signature key in response to the loading bootstrap program passing the integrity check.

Preferably, the embedded device is further configured to execute an initial boot-up program segment during boot-up such that: before signature verification is carried out on the application program, carrying out integrity verification on the application program; and in response to the application passing the integrity check, performing a signature check on the application.

Preferably, the embedded device further comprises encryption and decryption circuitry, and the embedded device is further configured to execute the initial boot-up program segment during boot-up such that: reading the symmetric key from the OTP memory; and the encryption and decryption circuit encrypts or decrypts the loading bootstrap program and/or the bootstrap identification and/or the application program stored in the nonvolatile memory by using the symmetric key.

Preferably, wherein reading the symmetric key from the OTP memory further comprises: reading an interaction mode identifier from the OTP memory, which indicates whether the embedded device is in an enabled interaction mode; and reading the symmetric key from the OTP memory in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device

Further preferably, the symmetric key is generated from an external key and a unique identification code of the embedded device, wherein the external key is obtained from the received first external instruction when the interaction mode of the embedded device is enabled. Preferably, the external key may also be written to the OTP memory.

Preferably, the embedded device is further configured to receive the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application according to the public signature key in the loading bootstrap program.

Further, the present application also provides a non-transitory computer readable medium having stored thereon computer readable instructions for providing firmware data protection in an embedded device; the computer readable instructions, when executed by a processor, cause the embedded device to perform any of the methods described above.

The invention provides a method and a device for protecting firmware data, which are used for managing whether to allow a command to be issued through a communication interface such as a serial port or not, reading and writing safety data in a one-time programmable memory area, reading and writing a nonvolatile memory and the like by setting an interactive mode identifier in a one-time programmable (OTP) memory, and have high safety. In the development stage of the device, the security function of the embedded device can be closed by setting the value of the interaction mode identifier, so that the access of a developer is facilitated; after the device function development is finished and before the device leaves the factory formally, the security functions of a plurality of embedded devices can be quickly enabled in batches by changing the value of the interaction mode identifier so as to enable the security functions of the embedded devices to be asked. In addition, according to the scheme of the invention, the unique symmetric key is generated based on the external key and the unique equipment identification code stored in the OTP memory, so that one-machine-one-key can be realized, and after the security function is started, only the equipment knows the symmetric key for encryption and decryption and cannot know the symmetric key by the outside. And, since the symmetric key used for encryption and decryption is generated based on the external key and the unique identification code of the device, even if the external key is leaked (for example, leaked at the host end), the external world still cannot know the symmetric key used by the device. The key management is convenient, no matter signature verification or firmware encryption is carried out, and at the host end, maintenance personnel only need to manage the signature key for signature verification and the unified external key for generating the symmetric key, so that one-machine-one secret key can be realized.

In another aspect, the present invention further verifies the initial Boot section first, then the load Boot, and finally the application based on the signed public key digest stored in the OTP memory, starting from the non-modifiable initial Boot section (ROM Boot), thereby forming a complete trust chain from the initial Boot section, the load Boot, and until between the applications, the signed public key digest can only be written when the embedded device is in the interactive-enabled mode. Compared with the prior art, the attacker cannot tamper with the signature public key digest, so that the subsequent verification step can be correctly performed only by using the correct signature public key digest, and therefore, even if the trust root is loophole or tampered, the embedded device can find a problem when verifying the signature public key and stop guiding the subsequent program in time. Furthermore, the invention combines signature verification, integrity verification and data encryption technology, and can realize a complete protection scheme for three aspects of validity, integrity and confidentiality of firmware data.

In addition, the invention is convenient for later maintenance or factory return maintenance, the firmware can be updated in an OTA mode, and new firmware data is automatically written into the nonvolatile memory in a cryptographically written mode. The new firmware is executed to shut down the security function, re-enable the read-write function to the OTP memory and the nonvolatile memory in the embedded device, etc. The new firmware can be issued to the device only through digital signature, and the device will verify the signature.

The method of the invention completely protects the firmware data of the embedded equipment, effectively prevents the firmware data from being stolen, prevents illegal tampering, and simultaneously protects the data use safety of users. The invention has the advantages of high safety, convenient key management, convenient starting and post maintenance, and has stronger practical value and wide application prospect. The protection method and the protection device can be applied to various embedded devices needing to protect firmware data, such as smart phones, tablet computers, smart televisions, smart watches, smart sound boxes, smart routers and the like. In addition, the application also provides the embedded equipment with the technical advantages.

Drawings

Hereinafter, the present application will be further explained with reference to the drawings based on embodiments.

FIG. 1 schematically illustrates a schematic flow diagram of a data issuer generating a key pair for a signature algorithm;

FIG. 2 schematically illustrates a schematic diagram of a memory hierarchy of an embedded device according to an embodiment of the present invention;

FIG. 3 schematically illustrates a flow chart of one embodiment of a method for protecting embedded device firmware data provided herein;

FIG. 4 schematically illustrates a flow chart of another embodiment of a method for protecting embedded device firmware data provided herein;

FIG. 5 schematically illustrates a schematic flow diagram of a method for protecting embedded device firmware data in accordance with one example of the invention;

FIG. 6 schematically illustrates a schematic flow diagram of a method for protecting embedded device firmware data in accordance with another example of the present invention;

FIG. 7 schematically illustrates a schematic flow diagram of performing an initial startup procedure segment according to one example of the invention;

FIG. 8 schematically illustrates a schematic flow diagram of an execution load boot program according to one example of the invention;

FIG. 9 schematically illustrates a schematic flow diagram of an embedded device updating an application by OTA, which is performed by a currently running application, in accordance with one example of the invention;

FIG. 10 schematically illustrates a schematic flow diagram of enabling security functions of an embedded device through a host side in accordance with one example of the invention;

fig. 11 schematically shows a schematic flow chart of a method of restarting an interaction-mode with an update application according to one example of the invention.

Detailed Description

The method and system of the present application will be described in detail below with reference to the attached drawings and detailed description. It is to be understood that the embodiments shown in the drawings and described below are merely illustrative and not restrictive of the application.

Fig. 2 shows a schematic diagram of a memory hierarchy of an embedded device according to an embodiment of the invention. Three types are included: read Only (ROM) memory, one-Time Programmable (OTP) memory, and nonvolatile memory (e.g., flash). Specifically, the ROM memory is a read-only memory area for storing a primary Boot program ROM Boot at the time of manufacturing the chip, the primary Boot program being unalterable. OTP memory is a one-time programmable memory area that is also internal to the chip and can only be read/written by an on-the-fly executable program loaded into the chip. Among them, executable programs that can be loaded into a chip and read/write operations to the OTP memory include a ROM Boot, a load Boot (Bootloader), an application program (app). The property of OTP memory is that each bit (bit) can only be written once and cannot be altered once the data is written. A common implementation of OTP memory is a single use electrical fuse that is cured within the chip, and once fused, is not recoverable, such as the efuse used on Le Xin product ESP 32. The nonvolatile memory, such as a Flash memory, an SD card, a USB storage device, an NVRAM, or the like, is a storage area in which data can be read and written a plurality of times, and is used to store a load boot program, an application program, or the like.

Example 1

As shown in fig. 3, a flowchart of one embodiment of a method for protecting embedded device firmware data provided herein is shown. By way of example, and not limitation, firmware may be stored in a non-volatile memory of an embedded device for controlling basic functions of the embedded device. Firmware typically includes at least a load boot program and an application program. The firmware also comprises a boot identifier which is independent of the loading boot program and the application program, and the boot identifier is responsible for reading a starting identifier from a nonvolatile memory (such as Flash) after the execution of the loading boot program is finished, initializing an operating system and then jumping to the appointed application program for running. According to the technical scheme of the invention, the boot identification part in the firmware data can be encrypted, but signature verification is not needed in general. The application program is used for executing main functions of the device, such as network transmission, network authentication, reading and writing data of the sensor, device OTA and the like. Those skilled in the art will appreciate that both the load boot program and the application program are executable programs that are compiled and generated from source code and then loaded into the processor for execution.

Referring to fig. 3, the method specifically includes the steps in which operations in the solid line box are necessary and operations in the dashed line box are optional, according to various embodiments of the present disclosure.

S300: during startup of the embedded device, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed, so that the following S300 (a) and S300 (b) are executed.

The initial Boot program segment (ROM Boot) is a primary Boot program stored in a ROM memory in the chip and is responsible for initializing hardware resources of the chip, such as a clock, a power supply, a memory, etc. After the embedded device is powered on, the initial starting program section is automatically operated. Typically, the initial startup procedure segment solidifies executable data in the chip before the embedded device leaves the factory, and the user cannot change the data in the initial startup procedure segment, or can read the data of the initial startup procedure segment to the outside of the embedded device. The initial boot-up program segment can only be loaded and executed by the chip in the embedded device.

S300 (a): an interaction pattern identifier is read from the OTP memory, the interaction pattern identifier being used to indicate whether interaction pattern of the embedded device is enabled.

By way of example and not limitation, the interaction-mode identifier may be stored in a fixed-length memory region in the OTP memory. And judging whether the current embedded equipment is in an enabling interaction mode or a closing interaction mode by reading the data in the fixed-length storage area. For example, it may be defined that the interaction pattern identifier is stored in a memory area of 8bits in length in the OTP memory and indicates that the interaction pattern is turned off when an odd number of "1's" are contained in the 8 bits; and when the 8bits contain 0 or even number of "1 s", the interactive mode is enabled. It should be appreciated that where enabling the interactive mode of the embedded device includes enabling the read-write functionality of the embedded device such that external commands can be received and issued to an internal storage area of the embedded device, for example via a serial port or like communication interface and read-write OTP memory or nonvolatile memory. When the embedded device is determined to be in the enabled state, optionally, the ROM Boot may further determine whether to enter the interaction mode of the embedded device by determining the level of the chip pin. By way of example and not limitation, the interaction-mode identifier stored in the OTP may only be read for use by a trusted firmware program. As will be appreciated by those skilled in the art, since the interaction-mode identifier is stored in a length of the fixed-length memory area in the OTP memory, the number of times the interaction mode can be re-enabled can be set according to the length of the fixed-length memory area. For example, the interactive mode identifier is set to be stored in a storage area of 7bits in length in the OTP memory, and is defined to represent that reading and writing are prohibited (i.e., protection function is enabled) when an odd number of "1's" are contained therein, and to represent that reading and writing are possible when an even number of "1's" are contained therein. The value of the initial state interaction pattern identification code is 000 0000, and if reading and writing are forbidden when the factory leaves the factory, the value is modified to 000 0001. If the read-write is to be re-enabled, such as for return to service, the value is changed to "000 0011" to indicate that the read-write is possible. After the modification is completed, it is changed to "000 0111" to prohibit reading and writing. Similarly, when the length of the interactive mode identification code is 7bits, the interactive mode identification code can be re-started for 3 times after leaving the factory. In a specific application, an appropriate fixed-length storage area can be reserved in the OTP memory according to the requirement so as to control the number of times of re-enabling the reading and writing.

S300 (b): in response to the interaction pattern identifier indicating an interaction pattern of the enabled embedded device, obtaining an external key according to the received first external instruction, and generating a symmetric key based on the external key and a unique identification code of the embedded device stored in the OTP memory; wherein the symmetric key is used to encrypt or decrypt firmware stored in the non-volatile memory.

By way of example and not limitation, the first external instruction may be issued by a developer of the embedded device into the embedded device at the host end via the communication interface. The developer generates a unified external key at the host end and sends the unified external key to different embedded devices. The embedded device in turn generates a locally unique symmetric key based on the external key and its own unique identification code. For example, a storage area for storing the unique identification code of the embedded device is provided in the OTP memory. The unique identification code is preset in the OTP memory of the embedded device and is readable and not rewritable only in specific cases. In addition, the OTP memory is provided with a storage area associated with encryption for storing a symmetric key generated based on an external key and a unique identification code. Optionally, the storage area associated with encryption in the OTP memory may also store an external key. In other examples, the first external instruction may be an instruction included in an application.

By way of example and not limitation, the symmetric key may be generated based on the external key and the unique identification code of the embedded device stored in the OTP memory according to rules agreed upon by the embedded device with the host side. For example, the agreed rule may be to combine the external key with a unique identification code. For example, taking the symmetric key for the AES256 encryption algorithm as an example, the length of the symmetric key is required to be 32 bytes, so that the host side generates a 24-byte random number as an external key, the unique identification code of the embedded device side is 8 bytes, and the two are spliced and combined together to obtain the symmetric key with the total length of 32 bytes. It should be appreciated that the present invention is not limited to agreed rules, and any rules may be employed to combine based on an external key and a unique identification code to generate a symmetric key. For example, encryption can be adopted to obtain a symmetric key meeting the length requirement, or compression filling can be adopted to compress the two to obtain a symmetric key meeting the length requirement. According to the scheme of the invention, since the unique identification code is stored in the OTP memory of the embedded device and cannot be read by the outside, the symmetric key generated according to the unique identification code and the external key cannot be acquired by the outside. Because of this, since the firmware data is stored in the nonvolatile memory after being encrypted using the symmetric key, even if the firmware data in the embedded device is stolen from the outside, the encrypted firmware cannot be run on other devices. Therefore, the scheme of the invention can also realize the function of firmware anti-plagiarism and effectively protect intellectual property. It can be understood by those skilled in the art that according to the scheme of the present invention, a one-machine-one key can be supported, and after the embedded device starts the security function, only the device itself knows the symmetric key used for encryption and decryption, but the outside cannot know. By the implementation, the key can be conveniently managed at the host end, and the product batch enabling safety function is easy to realize. When the encryption function is enabled in batches before the embedded equipment leaves the factory, a developer can encrypt all the embedded equipment by using the same external key at the host end, so that the complex mapping relation is avoided to record keys used by different embedded equipment. In contrast, in order to implement one-machine-one key in the prior art, the difficulty that the security function cannot be enabled in batch and different keys of different devices need to be recorded is generally faced.

Further optionally, in response to the interaction pattern identifier indicating that the interaction pattern of the embedded device is enabled, the interaction pattern identifier in the OTP memory is modified to turn on or off the interaction pattern of the embedded device in accordance with the received second external instruction. By modifying the interaction pattern identifier, a developer can conveniently enable or disable the security functions of the embedded device. For example, at the factory, the interaction pattern identifier can be modified to close the interaction pattern, preventing illegal access or data tampering; upon rework, the interaction pattern identifier is modified to turn on the interaction pattern, allowing data to be updated. As an example, the second external instruction may be an instruction contained in the application program, or an instruction issued by the host side. Those skilled in the art will appreciate that the off-interaction-mode may be set for multiple embedded devices in rapid batch, preferably by sending external instructions from the host side to modify the interaction-mode identifier. In some special cases, it is also conceivable to update the application program using OTA, which contains instructions to modify the interaction pattern identifier of the embedded device.

Optionally, referring to fig. 3, the method further comprises executing an initial startup procedure segment, such that S300 (c) and S300 (d) are executed.

S300 (c): reading a symmetric key from the OTP memory in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device; and

s300 (d): the firmware in the non-volatile memory is decrypted using the symmetric key. It will be appreciated that the firmware data in the non-volatile memory may include a load boot program, a boot identification, and an application program. In embodiments of the present invention, a portion of the data in the firmware may be encrypted and decrypted using a symmetric key, e.g., only the load boot program may be decrypted to further verify it to determine whether to execute the program, and, e.g., only the application may be decrypted to further verify whether to execute the application.

It will be appreciated that the symmetric key may be automatically applied for decryption when the firmware data is read from the non-volatile memory or for encryption when the data is written to the non-volatile memory when the initial boot-up program segment is executed by the embedded device, thereby ensuring that critical data in the non-volatile memory is encrypted. Therefore, according to the scheme of the invention, the encryption and decryption of the symmetric key applied when the nonvolatile memory is read and written are realized, and the confidentiality of the firmware data during storage or loading execution can be protected.

It should be appreciated that optionally, an encryption enable identifier may also be provided in the OTP memory. The encryption enabling identifier is stored in a section of fixed-length storage area in the OTP memory and is used for indicating whether a read-write mode of decrypting read data and encrypting write data of the nonvolatile memory is started or not. For example, the encryption enable identifier may be defined as 8bits in length, and when the 8bits contain an odd number of "1 s", it indicates a read/write mode for implementing the above-described decryption read data and encryption write data to the nonvolatile memory, for example, by enabling the encryption/decryption circuit in the embedded device; when the 8bits contain 0 or even numbers of "1", it means that the read-write operation is directly performed on the nonvolatile memory without the need of encrypting and decrypting the application symmetric key, for example, by closing the encrypting and decrypting circuit in the embedded device.

Example 2

As shown in fig. 4, a flowchart of another embodiment of a method for protecting embedded device firmware data provided herein is shown. Referring to fig. 4, the method specifically includes S402 and S404:

s402: during startup of the embedded device, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed, so that the following S402 (a) and S402 (b) are executed.

S402 (a): the method includes obtaining a public signature key stored in a load boot in a non-volatile memory of the embedded device and verifying the public signature key based on a public signature key digest stored in a one-time programmable (OTP) memory of the embedded device.

It should be appreciated that the signature public key digest is optionally written to the OTP memory upon receipt of an external instruction when the embedded device is in a state that enables the interaction mode. By way of example and not limitation, a signed public key digest is a digest of a signed public key that may be made by a developer at the host side and issued a command from the host side to instruct the embedded device to write the signed public key digest into OTP memory upon receipt of the command. It is worth noting that according to the scheme of the invention, the signature public key digest can be written only when the embedded device is in a state of enabling the interaction mode, so that the risk of the signature public key digest being attacked can be effectively avoided. The function of the signature public key digest is to compare with the signature public key when loading the bootstrap program, and if there is no match, it is indicated that the signature public key has been tampered with or replaced, thereby rejecting the loading of the bootstrap program. In this way, the security and reliability of the load boot program may be further enhanced. Those skilled in the art will appreciate that OTP memory is actually composed of a series of disposable electrical fuses, which are not only expensive but also easily occupy the volume in the chip, and if OTP memory is used too much, the chip volume becomes large and the cost increases. Therefore, as an advantageous effect of the embodiment of the present invention, by storing the signature public key digest in the OTP memory for verifying the signature public key in the firmware data, verification of the signature public key can be achieved with only a small amount of OTP memory space being occupied, without directly storing the signature public key whose data amount is much larger than the digest in the OTP memory. In addition, since the signature public key is not directly stored in the embedded device, even if the embedded device is attacked to leak data in the OTP memory, an attacker can only acquire the digest of the signature public key, and cannot restore the signature public key, so that the security is greatly improved. Meanwhile, as the signature public key is not stored in the OTP memory, the risk that the public key is tampered and the safety of equipment is further affected can be completely avoided.

Those skilled in the art will appreciate that different embodiments may be used to obtain a digest of the public signature key, for example, the digest of the public signature key may be calculated using the SHA256 algorithm or other integrity checking algorithm. Further by way of example, a signature public key in the load boot may be obtained and a digest of the signature public key calculated using a verification algorithm agreed with the host side and compared to the signature public key digest stored in the OTP memory. If the comparison is consistent, the signature public key in the loading bootstrap program is indicated to pass the verification, otherwise, the signature public key is indicated to not pass the verification.

S402 (b): in response to the signature public key verification passing, signature verification is performed on the load boot program using the signature public key.

By way of example and not limitation, to verify the legitimacy of a load bootstrap program, aspects of the present application may use a public signature key that passes verification to verify the load bootstrap program. If the signature verification is successful, it indicates that the load bootstrap is signed by a legal private key. As will be appreciated by those skilled in the art, the host side generates a key pair comprising a private signature key and a public signature key and stores the public signature key in the home bootstrap program, and the specific key generation method may be RSA signature algorithm, ECDSA signature algorithm or any other signature algorithm that may be used for signature verification.

The method further comprises step S404: in response to the load bootstrap signature verification passing, the load bootstrap is executed, so that the following S404 (a) is executed.

S404 (a): and carrying out signature verification on the application program stored in the nonvolatile memory according to the public signature key.

It should be appreciated that optionally, a signature verification enable identifier may also be provided in the OTP memory. The signature verification enable identifier is stored in a fixed length of memory area in the OTP memory for indicating whether signature verification of the load boot program and/or application program is to be initiated. For example, in some examples, if the signature verification enable identifier indicates that the signature verification is turned off, steps S402 (a) and S402 (b) are skipped to directly execute the load boot program, and step S404 is skipped to boot the execution of the application program by the load boot program. Conversely, if the signature verification enabled identifier indicates that signature verification is enabled, steps S402 (a), S402 (b), and S404 are sequentially performed as described above. By way of example and not limitation, the signature verification enable identifier may be written by the developer at the host side into the OTP memory of the embedded device by sending a command to the embedded device.

Optionally, before performing S402 (a) and S402 (b), the method further includes: carrying out integrity check on the loading bootstrap program; and verifying the public signature key in response to the loading bootstrap program passing the integrity check. By way of example and not limitation, the host side may calculate a digest of the load boot using a integrity check algorithm at the time of firmware manufacture and save the digest to the embedded device. When the initial starting program section carries out integrity check on the loading bootstrap program, firstly, the same integrity check algorithm as that of the host computer end is used for calculation to obtain the abstract of the loading bootstrap program, the abstract is compared with the saved abstract, and if the comparison is consistent, the loading bootstrap program is indicated to pass the integrity check. The scheme as described herein, wherein the integrity check algorithm may be a CRC32 algorithm, a SHA256 algorithm, or any other algorithm that may be used for integrity check to ensure that the load boot program is not tampered with or corrupted during transfer or storage, thereby ensuring data integrity.

Optionally, before executing S404, the method further includes: carrying out integrity check on the application program; and in response to the application passing the integrity check, performing a signature check on the application. By way of example, and not limitation, the host side may calculate a digest of the application using a integrity check algorithm at the time of firmware manufacture and save the digest to the embedded device. When the loading bootstrap program performs integrity check on the application program, firstly, the same integrity check algorithm as that of the host computer side is used for calculation to obtain the abstract of the application program, the abstract is compared with the stored abstract, and if the comparison is consistent, the application program is indicated to pass the integrity check. The scheme as described herein, wherein the integrity check algorithm may be a CRC32 algorithm, a SHA256 algorithm, or any other algorithm that may be used for integrity check to ensure that the application is not tampered with or damaged during transmission or storage, thereby ensuring data integrity.

Alternatively, it should be appreciated that the firmware data may be encrypted or unencrypted depending on whether the embedded device enables encryption or turns encryption off. The encryption enabled state of the embedded device is indicated, for example, by an encryption enabled identifier set in the OTP memory. For example, when the embedded device enables encryption, an initial startup procedure section is executed during startup of the embedded device so that, when step S402 is executed: reading a symmetric key from an OTP memory of the embedded device, and automatically applying the symmetric key to decrypt when firmware data is read from a nonvolatile memory to obtain a decrypted loading bootstrap program and/or bootstrap identification and/or application program; alternatively, the symmetric key is automatically applied for encryption when writing data into the non-volatile memory, thereby ensuring that critical data in the non-volatile memory is encrypted.

By way of example and not limitation, optionally, reading the symmetric key from the OTP memory further includes: reading an interaction mode identifier from the OTP memory, which indicates whether the embedded device is in an enabled interaction mode; and in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device, reading the symmetric key from the OTP memory.

By way of example and not limitation, the symmetric key may alternatively be generated from an external key and a unique identification code of the embedded device, wherein the external key is obtained from the received first external instruction when the interaction mode of the embedded device is enabled. Preferably, the external key may be written to the OTP memory.

Example 3

As previously described, to ensure that critical data of the device is not tampered with and read before the embedded device is shipped, the interaction pattern of the embedded device may be turned off by modifying the interaction pattern identifier, disabling reading of data in the OTP memory (e.g., the unique identification code of the embedded device), and disabling reading of data in the nonvolatile memory. However, when a factory return maintenance occurs, for example, when a product problem needs to be located, in order to facilitate the development and maintenance personnel to locate the problem, the interactive mode of the embedded device needs to be re-started, so that the development personnel can conveniently acquire the unique identification code of the device and read and write the data on the nonvolatile memory.

To solve this problem, in another embodiment of the present invention, an interactive mode is provided in which firmware is updated and the embedded device is restarted by an OTA.

Optionally, the method according to an embodiment of the present disclosure further includes: receiving an update application program in an OTA remote mode; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application program according to the signature public key. By way of example and not limitation, the embedded device may implement a firmware upgrade via wireless communication or otherwise.

Optionally, the update application may include instructions for re-enabling the interaction mode of the embedded device, which when executed modifies the interaction mode identifier in the OTP memory such that the interaction mode identifier indicates that the interaction mode of the embedded device is enabled.

The update application proves safe and effective by the integrity check and the signature check, and the execution modification application can modify the interaction mode identifier to switch back to the enabled interaction mode. Therefore, through the scheme of the invention, the interaction mode of the embedded equipment can be re-started through a safe and reliable new application program.

Example 4

According to another embodiment of the present application, there is provided an embedded device, referring to fig. 2, including a Read Only Memory (ROM), a non-volatile memory, a one-time programmable (OTP) memory, and an encryption/decryption circuit; the OTP memory stores an interaction mode identifier and a unique identification code of the embedded equipment, and the nonvolatile memory stores firmware; the embedded device is configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up such that: reading the interaction pattern identifier from the OTP memory; and in response to the interaction pattern identifier indicating an interaction pattern enabling the embedded device, obtaining an external key according to the received first external instruction, and generating a symmetric key based on the external key and the unique identification code of the embedded device; the encryption and decryption circuit is used for encrypting or decrypting the firmware in the nonvolatile memory by using the symmetric key.

Optionally, the firmware includes a load boot program, and the embedded device is configured to execute an initial boot program segment in a Read Only Memory (ROM) such that: in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device, the encryption and decryption circuitry reads the symmetric key from the OTP memory; and the encryption and decryption circuit decrypts the loading bootstrap program in the nonvolatile memory by using the symmetric key.

In another embodiment of the present invention, the embedded device includes a chip and a nonvolatile memory, wherein the chip includes a CPU, a read-only memory, an OTP memory, an encryption/decryption circuit, and a buffer memory (e.g. RAM). The nonvolatile memory is used to store firmware data, including load boot strap, boot strap identification, and application programs. According to one embodiment of the invention, the encryption and decryption circuit is directly connected with the RAM memory to realize the function of decryption according to the need. Specifically, when firmware data is required to be run, only corresponding partial data (such as a loading guide program or an application program) is read from the nonvolatile memory, and the partial data is decrypted by the encryption and decryption circuit and then is transmitted to the RAM memory. In this way, the scheme of the application does not need to decrypt the encrypted complete firmware data and store the whole into the RAM memory, but only reads and partially decrypts the encrypted complete firmware data as required at the runtime. Under the circumstance that the volume of the firmware data is larger and larger, decrypting the whole firmware data and storing the whole firmware data into the RAM memory in the prior art not only results in the need of a RAM memory with larger capacity and more expensive, but also results in long starting time and general implementation of the embedded device because all the decrypted firmware data are transferred into the RAM memory. In contrast, the embodiment of the invention can save the space of the RAM memory, shorten the starting time of the embedded equipment and has high operability.

As another alternative implementation example, optionally, an encryption enable identifier may also be set in the OTP memory to indicate whether the encryption and decryption circuit is enabled. Specifically, the encryption enable identifier corresponds to a circuit in the OTP memory that can be operated only once, similar to an electric fuse. When the encryption enabled identifier is burned, its corresponding circuitry in the chip of the embedded device is caused to change state, e.g., to be disconnected or bridged. For example, in one example, when the encryption enable identifier indicates that the encryption and decryption circuitry is enabled, the corresponding circuitry is bridged such that the encryption and decryption circuitry communicates with the RAM memory within the embedded device chip, and subsequent read and write operations of the firmware data from the non-volatile memory to the chip are automatically either encrypted (when writing data from the chip to the non-volatile memory) or decrypted (when reading data from the non-volatile memory to the chip) by the encryption and decryption circuitry. When the encryption enabling identifier indicates to close the encryption and decryption circuit, the corresponding circuit is disconnected, so that the nonvolatile memory is directly connected with the RAM memory without passing through the encryption and decryption circuit. Thus, by setting the encryption enabling identifier, security measures of the embedded device can be flexibly set to determine whether to automatically encrypt and decrypt the firmware data.

Optionally, if the encryption and decryption functions are enabled, generating a symmetric key of the embedded device according to the external key and the unique identification code of the embedded device read from the OTP memory, the symmetric key being used for encrypting and decrypting the firmware data; alternatively, if the generated symmetric key has been stored in the OTP memory, the symmetric key is read directly from the OTP memory.

Further optionally, the embedded device is further configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up, such that: after decrypting the firmware in the non-volatile memory using the symmetric key, the load boot program is integrity checked.

Further optionally, the embedded device is further configured to execute an initial boot program segment in a Read Only Memory (ROM) during boot up, such that: responding to the loading bootstrap program to pass the integrity verification, acquiring a signature public key in the loading bootstrap program, and verifying the signature public key according to a signature public key abstract in the OTP memory; and in response to the signature public key verification passing, performing signature verification on the loading bootstrap program using the signature public key.

Further optionally, the firmware comprises an application program, and the embedded device is configured to execute the load boot program during the boot-up such that: the encryption and decryption circuit decrypts the application program by using the symmetric key; and carrying out integrity check on the application program. Optionally, executing the load boot further causes: and in response to the application program passing the integrity check, performing signature check on the application program according to the signature public key in the loading bootstrap program.

Optionally, during startup, an initial startup program segment in Read Only Memory (ROM) is executed such that: in response to the interaction pattern identifier indicating that the interaction pattern of the embedded device is enabled, the interaction pattern identifier in the OTP memory is modified to turn on or off the interaction pattern of the embedded device in accordance with the received second external instruction.

Optionally, the embedded device is configured to receive the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application according to the public signature key in the loading bootstrap program.

Further optionally, the update application includes instructions for re-enabling the interaction mode of the embedded device; and the embedded device is further configured to: when the update application is executed, the interaction pattern identifier in the OTP memory is modified such that the interaction pattern identifier indicates an interaction pattern of the embedded device is enabled.

According to the embodiment of the invention, as the device enables the safety function on the chip when leaving the factory, the interaction mode of the embedded device is closed, and no method is available outside for reading/writing the firmware data of the device except that new firmware data is injected into the device in an OTA mode. It is therefore an advantage of embodiments of the present invention that even if a root of trust (e.g., an initial boot program segment) is tampered with or corrupted, subsequent authentication steps may be stopped because the authentication of the signed public key digest cannot be passed. In addition, when the embedded device operates, the encrypted firmware data is required to be loaded into the chip and then decrypted by the internal encryption and decryption circuit for use, so that an external attacker cannot analyze the data from the electrical signal.

Example 5

According to another embodiment of the present application, there is provided an embedded device, referring to fig. 2, including a Read Only Memory (ROM), a non-volatile memory, and a one-time programmable (OTP) memory; the read-only memory (ROM) stores an initial starting program section, the OTP memory stores a signature public key abstract, and the nonvolatile memory stores a loading bootstrap program and an application program; the embedded device is configured to execute an initial boot program segment during boot-up such that: a) Acquiring a signature public key in the loading bootstrap program, and verifying the signature public key according to the signature public key abstract; and in response to the signature public key verification passing, performing signature verification on the load boot program using the signature public key; and b) in response to the load bootstrap signature verification passing, executing the load bootstrap such that: and carrying out signature verification on the application program according to the public signature key.

Optionally, the embedded device is further configured to execute an initial startup procedure segment during startup such that: before verifying the signature public key, carrying out integrity verification on the loading bootstrap program; and verifying the public signature key in response to the loading bootstrap program passing the integrity check.

Optionally, the embedded device is further configured to execute an initial startup procedure segment during startup such that: before signature verification is carried out on the application program, carrying out integrity verification on the application program; and in response to the application passing the integrity check, performing a signature check on the application.

Optionally, the signature public key digest is written into the OTP memory according to the received external instruction when the embedded device is in a state in which the interaction mode is enabled.

Optionally, the embedded device further comprises an encryption and decryption circuit; and the embedded device is further configured to execute, during the boot, an initial boot-up program segment such that: reading the symmetric key from the OTP memory; and the encryption and decryption circuit encrypts or decrypts the loading bootstrap program and/or the bootstrap identification and/or the application program stored in the nonvolatile memory by using the symmetric key.

Optionally, wherein reading the symmetric key from the OTP memory further comprises: reading an interaction mode identifier from the OTP memory, which indicates whether the embedded device is in an enabled interaction mode; and in response to the interaction pattern identifier indicating an interaction pattern to turn off the embedded device, reading the symmetric key from the OTP memory.

Optionally, the symmetric key is generated based on the external key and a unique identification code of the embedded device, wherein the external key is obtained based on the received first external instruction when the interaction mode of the embedded device is enabled. Preferably, the external key may be written to the OTP memory.

Optionally, the embedded device is further configured to receive the update application remotely over the OTA; performing an integrity check on the updated application by the currently running application; and performing signature verification on the updated application program according to the public signature key in the loading bootstrap program.

Optionally, the update application includes instructions for re-enabling the interaction mode of the embedded device, which when executed modifies the interaction mode identifier in the OTP memory such that the interaction mode identifier indicates that the interaction mode of the embedded device is enabled.

As will be appreciated by those skilled in the art, in general, OTP memory is a special non-volatile memory. The data bit in the OTP memory can be written only once, and can not be written after being written, which is the one-time writing characteristic of the OTP memory. The OTP memory is also provided with control bits which are used for controlling the read-write authority of corresponding data bits, and the control bits can be written once. Therefore, if a control bit corresponding to a certain data bit of the OTP is programmed (for example, written from 1 to 0), the circuit corresponding to the control bit is destroyed, which means that the corresponding data bit cannot be written any more. For the OTP memory, different data information can be divided into different blocks (blocks), and read/write control bits of the blocks are respectively set for a plurality of blocks, so that the aim of controlling different read/write authorities of the different blocks is fulfilled. For example, some sensitive data, such as a unique identification code, may be placed in a block and its read/write control bits programmed so that it can only be read and cannot be written, modified or erased. This can improve the security and reliability of the data. Based on this principle, table 1 exemplarily shows respective fields in the OTP memory of the embedded device according to an embodiment of the present application and explains whether each respective field is readable or writable and its condition in the scheme according to the present invention, as an example and not limiting. Wherein the field optionally indicates that the OTP memory may or may not include a corresponding field.

TABLE 1

Example 1

As shown in fig. 5, a schematic flow chart diagram of a method for protecting embedded device firmware data according to one example of the invention is shown.

After power-up, the embedded device will automatically run an initial boot-up program segment stored in ROM, which reads the interaction pattern identifier from OTP memory to determine whether the interaction pattern of the embedded device is enabled. If in a state of enabling the interactive mode, further, the initial start-up program section can determine whether to immediately enter the interactive mode by judging the level of a corresponding pin (for example, a chip_status pin) of the chip of the embedded device. In the case of enabling the interactive mode, the embedded device may receive external instructions, read and write data to the OTP memory, and read and write data from the nonvolatile memory. In the case of the interaction mode being switched off, after the initial start-up program segment is executed, a jump is made to the load boot program. The load boot program is responsible for reading the boot identification in non-volatile memory (e.g., flash) and initializing the operating system. Then, after the loading boot program is executed, the operation is skipped to the application program indicated by the boot identification.

Further, in example 1, the load boot program, the boot identification, and the application program may be stored encrypted in the nonvolatile memory. Before executing the boot loader and the application program, it may further comprise reading a symmetric key from the OTP memory and decrypting firmware data in the non-volatile memory using the symmetric key, the firmware data including the boot loader, the boot strap identifier, and the application program.

Further, in example 1, before executing the load boot program and the application program, the method may further include performing an integrity check and/or a signature check on the load boot program, and performing an integrity check and/or a signature check on the application program. Specific methods for performing the integrity check and the signature check are described above, and are not described herein.

Example 2

As shown in fig. 6, a schematic flow chart diagram of a method for protecting embedded device firmware data according to another example of the present invention is shown.

According to example 2, a complete firmware security scheme is established from the initial startup of the program segment to the application until the updated application is received and executed. Specifically, during startup of the embedded device, as shown in step 602 in fig. 6, an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device is executed. Next, step 604 is performed to obtain the public signature key stored in the loading bootstrap program in the non-volatile memory of the embedded device and verify the public signature key from the public signature key digest stored in the one-time programmable (OTP) memory of the embedded device. In response to the signature public key verification passing, step 606 is performed to verify the signature of the load boot program using the verified signature public key. Responsive to the load bootstrap signature verification passing, step 608 is performed to execute the load bootstrap. After the execution of the load boot program is completed, step 610 continues to perform signature verification on the application stored in the non-volatile memory based on the signature public key. Responsive to the application signature verification passing, step 612 is performed to execute the application. Optionally, when the embedded device receives the update application (e.g., by way of an OTA or local update), step 614 is performed to verify the signature of the update application based on the public signature key. If the update application passes the signature verification, step 616 is performed to execute the update application.

Further, in example 2, the load boot program and the application program may be stored in the nonvolatile memory in an encrypted manner. Before executing the boot loader and the application program, it may further comprise reading a symmetric key from the OTP memory and decrypting firmware data in the nonvolatile memory using the symmetric key, the firmware data comprising the boot loader and the application program.

Further, in example 2, before executing the load boot program and the application program, the method may further include performing an integrity check on the load boot program and performing an integrity check on the application program. Specific methods for performing the integrity check are described above and will not be described in detail herein.

Preferably, the signature public key digest is written into the OTP memory according to the received external command when the embedded device is in a state of enabling the interaction mode, and when the embedded device starts a security function (for example, closes the interaction mode when leaving a factory), the signature public key digest cannot be modified, so that external attack or tampering can be effectively prevented, and the credibility of the signature public key is ensured. Therefore, the scheme starts from an initial starting program section, firstly, the signature public key is verified according to the signature public key digest, the loading bootstrap program and the application program are verified successively, and only the firmware passing verification can be loaded and executed. Through the firmware security scheme, the scheme can effectively protect the firmware in the embedded equipment from being stolen, falsified or leaked, and the plaintext data of the firmware cannot be cracked outside in a symmetric key encryption mode, so that the safety and the reliability of the equipment are ensured. In addition, the scheme can re-enable the interaction mode of the embedded equipment on the basis of ensuring that the updated firmware program is credible by updating the firmware program and verifying the firmware program, thereby facilitating later maintenance.

According to the scheme of the invention, verification is established from an unalterable initial starting program section, the signature public key is verified through the signature public key abstract stored in the OTP memory, and the signature public key is used for subsequent signature verification on the basis that the signature public key passes the verification, so that step-by-step verification of a boot loader and an application program is realized, a complete trust chain can be established, and the scheme has high safety. In addition, programmable security function settings are realized in the technical scheme of the invention, namely, the device is allowed to select which security functions are started before leaving the factory, for example, the integrity check, the firmware encryption measures and the like are optionally applied. The highest security level adopts triple verification, namely data encryption, integrity verification and signature verification, and the security performance is high. Furthermore, the scheme of the invention also realizes a step-by-step trust mode from an initial starting program section, loading a bootstrap program, an application program to an updating application program, on one hand, the establishment of a complete trust chain is truly realized, and on the other hand, the interactive mode can be creatively restarted through the updating application program, so that the later management and maintenance are facilitated.

As with the methods of examples 1 and 2 above, high security may be achieved. For the signature verification section, since only the digest of the signature public key is stored in the embedded device, and the signature public key and the signature private key are never saved, an external attacker cannot acquire the signature public key or the private key from the embedded device to forge the signature data. For the encryption part, a one-machine-one-key mechanism of the embedded device is realized, the symmetric key for encryption and decryption is automatically generated by combining an external key and a unique identification code of the device stored in the OTP memory inside the embedded device, and after encryption is enabled, even if the external key at the host end leaks, the symmetric key cannot be obtained due to the lack of the unique identification code, so that encrypted firmware data in the embedded device cannot be decrypted. Moreover, even if the firmware data on the embedded device is copied to other devices in a violent manner, the other devices cannot load and run the firmware due to the lack of the unique identification code of the embedded device, so that the function of protecting intellectual property rights is played.

Example 3

As shown in fig. 7, a schematic flow chart of executing an initial startup procedure segment according to one example of the invention is shown. As mentioned above, the initial Boot section (ROM Boot) is executable data that is solidified in the chip, and is written before shipment, and cannot be modified or exported by the user, but can be loaded and run by the chip. According to the scheme of the invention, when the embedded device is powered up, the initial start-up program section decides whether to execute some functions according to some fields in the OTP memory.

Referring to fig. 7, the main operational flow of the initial startup procedure segment is as follows, wherein operations in the solid line box are necessary and operations in the dashed line box are optional, according to various embodiments of the present disclosure:

and reading the interaction mode identifier in the OTP memory, and judging whether the interaction mode of the embedded device is enabled. And optionally further determines whether to enter an interaction mode, for example, by determining the level of the corresponding pin of the chip. If the interaction mode is determined to be entered, the host side can send a command to the device through a communication interface such as a serial port, read and write data in part of the OTP memory, and read and write the nonvolatile memory.

If it is determined not to enter the interactive mode, the initial startup procedure segment continues to be executed. Optionally, the encryption enable identifier is read from the OTP memory to determine whether encryption and decryption are enabled. If the encryption and decryption functions are started, generating a symmetric key of the embedded device according to the external key and the unique identification code of the embedded device read from the OTP memory, wherein the symmetric key is used for encrypting and decrypting the firmware data; alternatively, if the generated symmetric key has been stored in the OTP memory, the symmetric key is read directly from the OTP memory. Then, the embedded device can automatically encrypt and decrypt when reading and writing the firmware data stored in the nonvolatile memory, so as to ensure that the key data on the nonvolatile memory are encrypted, thereby improving the confidentiality of the firmware data. In this example, the firmware data stored in the non-volatile memory may be decrypted using the symmetric key to obtain the decrypted load boot program and application program.

Optionally, further reading the integrity check code in the loading bootstrap program, and recalculating the abstract of the loading bootstrap program by using the same integrity check algorithm as that of the host computer, and if the calculated abstract is consistent with the integrity check code, indicating that the integrity check of the loading bootstrap program passes. If the integrity check is not passed, an error is prompted and the embedded device is driven to restart.

Optionally, the signature verification enable identifier in the OTP memory is read to determine whether signature verification is enabled. If the signature verification function is enabled, a priori the public key in the load boot is correct. The specific method is to calculate the digest of the public key in the loading bootstrap program by using an integrity checking algorithm (for example, SHA 256 algorithm), compare the digest with the signed public key digest pre-stored in the OTP memory, and if the digest is consistent, consider the public key to be correct. And then the public key is used for checking the signature in the loading bootstrap program, and if the signature passes the checking, the loading bootstrap program is signed by a legal private key, so that the validity of the loading bootstrap program is ensured. Conversely, if it is determined that the digest of the computed public key does not match the digest of the pre-stored signed public key, the public key is deemed incorrect. In the event that the public key is incorrect, or in the event that the public key is correct but the load boot does not pass the signature verification, an error is prompted and the embedded device is driven to restart.

Referring to Table 2 below, the main content in the load bootstrap in one example is shown.

TABLE 2

Example 4

As shown in FIG. 8, a schematic flow chart diagram of an execution load boot program according to one example of the invention is shown. Referring to fig. 8, the main operational flow of the load bootstrap is as follows, where operations in the solid line box are necessary and operations in the dashed line box are optional, according to various embodiments of the present disclosure:

Optionally, reading the integrity check code in the application program, recalculating the abstract of the application program by using the same integrity check algorithm as the host end, and if the calculated abstract is consistent with the integrity check code, indicating that the integrity check of the application program passes. If the integrity check is not passed, an error is prompted.

Optionally, the signature verification enable identifier in the OTP memory is read to determine whether signature verification is enabled. If the signature verification function is started, the public key in the loading bootstrap program is used for verifying the signature in the application program, and if the verification is passed, the application program is signed by the legal private key, so that the validity of the application program is ensured. In the case that the application fails signature verification, an error is prompted. In another embodiment, the signature public key in the load boot is read directly and used to verify the signature in the application.

Preferably, if the integrity check or signature check of the application fails, the data of the partition in which the application is located may also be marked as invalid data and an attempt may be made to find other available application partitions in the nonvolatile memory. The steps described above in fig. 8 are repeatedly performed for each partitioned application in turn to perform verification. If no available application is eventually found, the embedded device is deemed to have been damaged or under attack and the embedded device is driven to restart.

Referring to Table 3 below, the main content in one example application is shown.

TABLE 3 Table 3

Example 5

According to the scheme of the invention, the embedded device can remotely update the application program in an OTA mode. To ensure that the updated application received by OTA is secure, the currently running application will also verify the updated application. And the host signs the compiled update application program according to the signature private key and transmits the signature to the embedded device in an OTA mode. As shown in fig. 9, a schematic flow chart of an embedded device updating an application by OTA, which is executed by a currently running application, is shown according to one example of the invention. Wherein operation in a solid line box is necessary and operation in a dashed line box is optional in accordance with various embodiments of the present disclosure.

The embedded device downloads the update reference program through the OTA and writes it into the corresponding partition in the nonvolatile memory.

Optionally, the currently running application program reads the integrity check code in the update application program, recalculates the abstract of the update application program by using the same integrity check algorithm as the host end, and if the calculated abstract is consistent with the integrity check code, the integrity check of the update application program is passed. If the integrity check is not passed, an error is prompted.

Optionally, the signature verification enable identifier in the OTP memory is read to determine whether signature verification is enabled. If the signature verification function is started, the public key in the loading bootstrap program is used for verifying the signature in the updating application program, and if the verification is passed, the updating application program is signed by a legal private key, so that the validity of the updating application program is ensured. In the event that the update application fails signature verification, an error is prompted.

Preferably, if the updated application passes the verification, the updated application is set to the application that the boot program is to boot for the next time it is restarted. Further, the embedded device may be driven to restart to execute the update application.

If the integrity check or signature check of the update application fails, an error is prompted, indicating that the OTA fails.

According to the scheme of the invention, the application program can be safely updated.

Example 6

The specific principles of the secure firmware functions of the embedded device according to the present invention have been described in detail above, and corresponding code may be implemented according to these specific principles during device development to generate firmware containing the above-described functions. Generally, after the function development of a device is completed, in order to protect intellectual property rights and to protect user privacy and device security, before the device leaves the factory, an interaction mode of the device needs to be turned off to enable a security function of the device. After the safety function is started, the device executes checksum encryption and decryption according to the initial starting program section, the loading guide program and the verification flow in the application program. As shown in fig. 10, a schematic flow chart of enabling the security function of an embedded device through a host side according to an example of the present invention is shown.

The host side generates a key pair for signature verification, including a signature private key and a signature public key. The privacy of the signature private key is a key factor in ensuring the scheme, so after the development and maintenance personnel obtain the signature private key, the private key should be ensured to be stored in a safe position and be accessed by appointed personnel only.

The host-side compilations generate firmware data, including, for example, a load boot program, a boot strap, and an application program, and generate signature data and an integrity check code for the load boot program and the application program, respectively. The host further attaches signature data, an integrity check code, and a signature public key to the load boot program, and attaches the signature data and the integrity check code to the application program.

The host computer restarts the embedded device and enables the embedded device to enter an interactive mode by controlling the pin level of the embedded device.

And the host generates a digest corresponding to the signature public key, and writes the signature public key digest into an OTP memory of the embedded equipment.

The host side sends a command to the embedded device to modify the signature verification enable identifier to enable the signature verification function. At this point, the check enable identifier field in the OTP memory of the embedded device is set to valid.

The host side sends a command to the embedded device requesting to read the unique identification code of the embedded device stored in the OTP memory. The embedded device returns the unique identification code of the embedded device to the host side.

Further, the host generates an external key and generates a symmetric key for encryption and decryption with the read unique identification code according to a stipulated rule. Illustratively, the AES256 encryption algorithm is taken as an example of the encryption/decryption algorithm, which requires a key length of 32bytes, so that the host side can generate a random number with a length of 24bytes as an external key, and obtain a symmetric key with a total length of 32bytes by combining a unique identification code with a length of 8 bytes. It should be noted that the present invention is not limited to specific generation rules.

After the symmetric key is obtained by calculation, the host encrypts the firmware data according to an encryption algorithm agreed with the embedded device using the symmetric key. The firmware data comprises loading bootstrap data of the additional signature data, the integrity check code and the signature public key, a bootstrap identifier and application program data of the additional signature data and the integrity check code. Alternatively, the host may delete the symmetric key obtained by calculation from the host after the firmware encryption is completed. Therefore, one technical advantage of the present invention is that it is not necessary to record the symmetric key of each embedded device at the host side, but only the embedded device knows the symmetric key of itself, thereby achieving the effect of one-machine-one-key, and achieving high security.

And the host sends a command and imports the encrypted firmware data into a nonvolatile memory of the embedded equipment.

Then, the host side transmits a command containing information of the external key to transmit the generated external key to the embedded device. Preferably, after obtaining the external key, the embedded device may also generate the same symmetric key according to the rules agreed with the host side using the external key and the unique identification code of the device itself. It is noted that, since the external key is used to combine with the unique identification code to further generate the symmetric key for encryption, the external world cannot know the existence of the symmetric key, and cannot access the OTP memory inside the embedded device to obtain the unique identification code, and certainly cannot generate the symmetric key based on the external key and the unique identification code. In addition, even if the external key is known from the outside, the unique identification code of the embedded device cannot be read, so that the complete symmetric key cannot be generated, and the security of the symmetric key can be protected to the greatest extent. In addition, because the unique identification codes of each embedded device are different, the scheme of the invention can transmit the unique external key to a plurality of embedded devices at the host end, and the symmetric keys used for encryption and decryption on the embedded devices are different finally, so that the one-machine-one-secret effect is realized on the premise of convenient configuration. After the equipment leaves the factory, only the equipment knows the symmetric key used by the equipment, so that the safety of the equipment is protected to the greatest extent.

Optionally, the host side may also send a command to modify the encryption enable identifier to be valid to enable encrypted reading from and writing to non-volatile memory.

After the setting is completed, the host sends a command to modify the interaction mode identifier to be in a closed state so as to close the interaction mode of the embedded device. At this time, the outside cannot read the data in the OTP memory, and cannot read and write the nonvolatile memory, namely, the device enables the safety function, and the device can leave the factory. Those skilled in the art can understand that it is necessary to ensure that the device is already in a state of closing the interaction mode when leaving the factory, so as to achieve the security purpose, otherwise if the device is still leaving the factory when the interaction mode is enabled, an illegal operator has an opportunity to acquire information for encryption in the OTP memory, so that the device may be at risk of attack.

Example 7

As described above, for example, according to example 6, before shipment of the embedded device, in order to prevent critical data of the device from being tampered with and read, the interaction pattern may be turned off by modifying the value of the interaction enabling identifier to secure firmware data. However, if the device fails, requiring return to service, to help develop a quick localization problem for the maintenance personnel, the interactive mode of the embedded device needs to be re-enabled so that the developer can obtain more information. To achieve this object, the present invention provides a method for obtaining an updated application program in an OTA manner to restart an interaction mode. As shown in fig. 11, a schematic flow chart of a method for restarting an interaction pattern with an update application according to an example of the present invention is shown.

The host side first generates an update application including code that modifies the interaction pattern identifier. As previously described, the storage area length of the interaction-pattern identifier may be determined based on the number of desired restartable interaction patterns. Further, the host side signs the updated application using a signature private key and attaches an integrity check code. Alternatively, the host side may encrypt the data of the update application using a symmetric key.

The host may issue the update application in an OTA manner, and the embedded device may decrypt the update application using the local symmetric key after receiving it, and verify the update reference as in the example of fig. 9 above. When the updated application passes the verification, it is safe and effective on behalf of the updated application. Thus, after the embedded device is restarted, execution of the update application begins. Wherein updating the code included in the application causes modification of the interaction enabling identifier in the OTP memory to enable the interaction mode of the embedded device. Further, the embedded device is driven to restart, so that a developer can safely read and write the embedded device under the condition that an interaction mode is enabled.

The present invention introduces a number of embodiments for securing firmware of an embedded device. In one aspect, the enabling of the interaction mode and the switching of the off state are achieved using the OTP memory, and the security function can be conveniently enabled. By setting the interaction mode identifier, the security function is conveniently started, in general, when the device leaves the factory, the security function can be quickly started in batches only by simple interaction between the host side and the embedded device through the steps shown in fig. 10, and the embedded device can be immediately used after configuration, so that the time and the cost are saved. In the subsequent maintenance, the firmware can be conveniently updated in an OTA mode to support remote authentication, and after the equipment starts a safety function, new firmware can be issued to the equipment only through digital signature, the equipment performs signature verification, and encryption writing is automatically performed when data is written into a nonvolatile memory, so that the firmware updating flow and operation are simplified. And after the equipment enables the safety function, the safety updating firmware is allowed to be acquired through the OTA, the interactive function of the equipment is re-started, the information of the equipment is convenient to check and read and write, such as an OTP memory, a nonvolatile memory and the like, and the equipment maintenance efficiency and quality are improved. On the other hand, the unique identification code of the embedded device is stored in the OTP memory, so that one-machine-one key is supported, after the safety function is started, the device only knows the key of the device itself, the external world cannot know the key used by the current device, and key leakage is effectively prevented. And the key management is convenient, no matter signature verification or firmware encryption is carried out, maintenance personnel only need to manage the signature key and the unified external key at the host end, and corresponding symmetric keys for encryption and decryption are not required to be respectively stored for each embedded device, so that the complexity and risk of key management are reduced. In yet another aspect, a check is established starting from an unalterable initial boot program segment, ensuring the security and reliability of the device. Meanwhile, the signature verification, the integrity verification and the data encryption technology are combined optionally, so that the intellectual property of the firmware data can be protected completely, a competitor is prevented from stealing the firmware, and meanwhile, the data security of a user is protected, and the data is prevented from being tampered or stolen. The embodiments of the present invention effectively solve the problems existing in the prior art by considering the design of security mechanisms in terms of policy, implementation, post maintenance, etc.

While various embodiments of the various aspects of the present application have been described for purposes of this disclosure, it should not be construed that the teachings of this disclosure are limited to these embodiments. Features disclosed in one particular embodiment are not limited to that embodiment, but may be combined with features disclosed in a different embodiment. For example, one or more features and/or operations of the methods according to the present application described in one embodiment may also be applied in another embodiment, alone, in combination, or in whole. Those skilled in the art will appreciate that there are many more alternative embodiments and variations that can be made to the above-described system without departing from the scope defined by the claims of the present application.

Claims

1. A method for protecting embedded device firmware data, the method comprising the steps of:

during startup of the embedded device, executing an initial startup program segment stored in a Read Only Memory (ROM) of the embedded device such that:

-obtaining a public signature key stored in a loading bootstrap program in a non-volatile memory of the embedded device and verifying the public signature key from a public signature key digest stored in a one-time programmable (OTP) memory of the embedded device; and

-in response to the signature public key verification passing, signature verifying the load boot program using the signature public key;

and in response to the load boot signature verification passing, executing the load boot such that:

-signature checking the application firmware stored in the non-volatile memory based on the signature public key.

2. The method of claim 1, further comprising executing the initial startup procedure segment such that:

-performing an integrity check on the load boot prior to verifying the public signature key; and

-verifying the public signature key in response to the load bootstrap passing an integrity check.

3. The method of claim 1, further comprising executing the initial startup procedure segment such that:

-integrity checking the application firmware before signature checking the application firmware; and

-in response to the application firmware passing the integrity check, signature checking the application firmware.

4. The method of claim 1, wherein,

The signature public key digest is written into the OTP memory according to a received external instruction when the embedded device is in a state in which an interaction mode is enabled.

5. The method of claim 1, further comprising executing the initial startup procedure segment such that:

-reading a symmetric key from the OTP memory; and

-encrypting or decrypting a load boot program and/or boot identification and/or application program stored in the non-volatile memory using the symmetric key.

6. The method of claim 5, wherein reading a symmetric key from the OTP memory further comprises:

-reading an interaction mode identifier from the OTP memory, indicating whether the embedded device is in an enabled interaction mode; and

responsive to the interaction pattern identifier indicating a closing of the interaction pattern of the embedded device,

a symmetric key is read from the OTP memory.

7. The method of claim 5, wherein,

the symmetric key is generated from an external key and a unique identification code of the embedded device, wherein the external key is obtained from a received first external instruction when an interaction mode of the embedded device is enabled.

8. The method of claim 1, wherein,

the method further includes receiving updated application firmware over the OTA remotely;

performing an integrity check on the updated application firmware by the application firmware currently running; and

and executing signature verification on the updated application program firmware according to the signature public key.

9. The method of claim 8, wherein,

the update application firmware includes instructions for re-enabling an interaction mode of an embedded device that, when executed, modifies an interaction mode identifier in the OTP memory such that the interaction mode identifier indicates that the interaction mode of the embedded device is enabled.

10. An embedded device, characterized in that,

the embedded device includes a Read Only Memory (ROM), a non-volatile memory, and a one-time programmable (OTP) memory; the system comprises an OTP memory, a nonvolatile memory, a read-only memory (ROM), a loading bootstrap program and an application program, wherein the ROM stores an initial starting program section, the OTP memory stores a signature public key abstract, and the nonvolatile memory stores a loading bootstrap program and an application program;

the embedded device is configured to execute the initial boot program segment during boot-up such that:

-obtaining a public signature key in the load boot program and verifying the public signature key from the public signature key digest; and

-signature verification of the application firmware based on the public signature key.

11. The apparatus of claim 10, wherein the device comprises a plurality of sensors,

the embedded device is further configured to execute the initial boot program segment during boot up such that:

before verifying the signature public key, carrying out integrity verification on the loading bootstrap program; and

and verifying the signature public key in response to the loading bootstrap program passing an integrity check.

12. The apparatus of claim 10, wherein the device comprises a plurality of sensors,

13. The apparatus of claim 10, wherein the device comprises a plurality of sensors,

14. The apparatus of claim 10, wherein the device comprises a plurality of sensors,

the embedded device further comprises an encryption and decryption circuit; and

-reading a symmetric key from the OTP memory; and

-said encryption and decryption circuitry encrypting or decrypting a load boot program and/or boot identification and/or application program stored in said non-volatile memory using said symmetric key.

15. The device of claim 14, wherein reading a symmetric key from the OTP memory further comprises:

A symmetric key is read from the OTP memory.

16. The apparatus of claim 14, wherein

17. The apparatus of claim 10, wherein the device comprises a plurality of sensors,

the embedded device is further configured to receive updated application firmware over the OTA remote mode;

and executing signature verification on the updated application program firmware according to the public signature key in the loading bootstrap program.

18. The apparatus of claim 17, wherein the device comprises a plurality of sensors,

19. A non-transitory computer readable medium having stored thereon computer readable instructions for providing firmware data protection in an embedded device, which when executed by a processor, cause the embedded device to perform the method of any of claims 1-9.