CN117827229A

CN117827229A - Method for preventing device firmware version from rolling back

Info

Publication number: CN117827229A
Application number: CN202310299018.5A
Authority: CN
Inventors: 张猛
Original assignee: Jindi Spacetime Zhuhai Technology Co ltd
Current assignee: Jindi Spacetime Zhuhai Technology Co ltd
Priority date: 2023-03-24
Filing date: 2023-03-24
Publication date: 2024-04-05

Abstract

The invention discloses a method for preventing equipment firmware version rollback, which comprises the following steps that step 1, at least two public and private key pairs are generated during SOC production, and a public key or a public key hash is stored in a Boot ROM; step 2, defining a public key bitmap, and allocating a bit to each public key for indicating whether the public key bitmap is valid or not, wherein the validity of the public key is equivalent to the validity of a public-private key pair; and 3, in the initial state, all public keys are defaulted to be effective, one public key is selected to carry out signature verification on BL1, when the BL1 has loopholes or risks, bits of the public key at the positions corresponding to the public key bitmaps are written to be invalid, one effective public key is selected again, and the effective public key is used for signature verification of BL 1. The invention is based on a public-private key encryption system, only codes which use valid public-private key pairs and are signed correctly are operated, and the validity of the public key is configured by changing the public key bitmap of the EFUSE/OTP module, so that the function of invalidating signature authentication of a certain old version is realized, and the effect of preventing the firmware version of the equipment from rolling back is achieved.

Description

Method for preventing device firmware version from rolling back

Technical Field

The invention relates to a method for preventing a device firmware version from rolling back, which is mainly applied to secure boot.

Background

With the development of society and iteration of products, devices such as computers, mobile phones and hand rings contain more and more personal data such as payment passwords, privacy and the like; the data and the information need to be protected from being accessed by an unauthorized third party, and the following two targeted protection schemes are introduced in the industry.

First kind: secure boot, which only enables authorized software solutions, cannot boot and run unauthorized or malicious software.

By using a hash function (e.g., SHA 256) and an asymmetric encryption algorithm (e.g., RSA 2048), a secure boot chain is implemented; only the authenticated code is started to run, so that malicious code is prevented from running, and products and data are protected. Root of Trust, as shown in fig. 1, is generally implemented by using a Boot ROM as a Trust Root of the whole system, and the Boot ROM is read-only and unchangeable, and is generated and written into the chip at one time. BL1 (boot loader stage, first level boot), as shown in FIG. 2, is located on external memory and can be updated. The signature data contained in BL1 is generated by a private key (private key, which needs to be protected and cannot be revealed), and the public key (public key, which is generated by the private key, and the private key cannot be reversely obtained by the public key) is used in the Boot ROM to verify the signature. The public key can be published in a public way, and is generally written into an EFUSE or OTP (one time program) module in the chip at one time, and cannot be changed. The existing defects are 1. For the product used at the client, the old public key cannot be erased, the old version can still be operated, only the old public key can be destroyed, and the SOC safe starting mechanism is not available; 2. for products which are used at the client, the new public key cannot be updated, and the new version cannot be run; 3. the length of the recorded data is relatively large, the recording failure risk is in direct proportion to the length of the data, and any 1bit recording failure can lead to the unavailability of the whole public key; 4. the length of the recorded data is relatively large, the recording time is in direct proportion to the length of the data, and the recording cost is high.

Second kind: rollback prevention is performed to manage the version, and old versions are prevented from being started and operated by updating software version numbers.

In the development of a software scheme, a BUG inevitably exists, and the version needs to be prevented from running in a product and is forcedly updated to a new version; for this purpose, an anti-rollback mechanism is required, and as shown in fig. 3, the module C can be normally loaded and operated, the version number of the module B is smaller than the designated version, possibly including code with risk, and the module B cannot be loaded and operated. The disadvantage is that the data of the loaded module is stored outside the SOC and possibly tampered or lost, so that the version comparison is invalid and then rolled back to the old version.

Disclosure of Invention

In order to solve the technical problems, the invention provides a method for preventing a firmware version of a device from rolling back, which is based on a public-private key encryption system, only runs codes which use valid public-private key pairs and are signed correctly, and adopts the following technical scheme:

a method of preventing rollback of a device firmware version, comprising the steps of:

step 1, generating at least two public and private key pairs during SOC production, and storing a public key or a public key hash into a Boot ROM;

step 2, defining a public key bitmap, and allocating a bit to each public key for indicating whether the public key bitmap is valid or not, wherein the validity of the public key is equivalent to the validity of a public-private key pair;

and 3, in the initial state, all public keys are defaulted to be effective, one public key is selected to carry out signature verification on BL1, when the BL1 has loopholes or risks, bits of the public key at the positions corresponding to the public key bitmaps are written to be invalid, one effective public key is selected again, and the effective public key is used for signature verification of BL 1.

The invention has the following beneficial technical effects:

the EFUSE/OTP requirement is smaller, only one bit is allocated for each public and private key, and the recording error risk and the recording cost of the EFUSE/OTP are reduced.

The Boot ROM saves the public key or the public key hash, and the cost of the Boot ROM is lower than that of EFUSE/OTP.

3. The public key bitmap is stored in the EFUSE/OTP, and the public and private key pairs used before are invalidated by programming the public key bitmap in the EFUSE/OTP, so that rollback to the old version can be prevented.

The public key is valid by default, and when the EFUSE/OTP preservation bitmap is used, the default initial value of the public key and the EFUSE are different, if the EFUSE is used, the default value is 0, and the default value is written as 1 to invalidate the public key; if OTP is used, default value is 1, and programming to 0 invalidates it.

4. The starting of the old version can be prevented by only programming 1bit, and the programming cost and the programming failure risk are low.

5. For published products, updating the public key bitmap on the IC internal EFUSE/OTP can also prevent rollback to the old version.

6. When one or more private keys are leaked due to invasion, poor management, personnel change and the like, a group of valid public and private key pairs are re-started, and the leaked public and private key pairs are invalidated.

7. Different public-private key generation policies, corresponding to different public-private key distribution policies, use different public-private key pairs when authorizing development or operation to multiple partners. If a certain cooperation is terminated, the bit of the position corresponding to the public key bitmap is written as invalid.

8. The burning error probability is low, and even if a few bits are burnt due to the fact that the operation error is more than a few bits, a new public and private key pair still effective can be used through updating software, so that the chip is prevented from being scrapped.

Drawings

The invention is further described below with reference to the accompanying drawings:

FIG. 1 is a schematic diagram of a root of trust;

FIG. 2 is a schematic diagram of a first stage boot;

FIG. 3 is a schematic diagram of a conventional rollback prevention mechanism;

FIG. 4 is a schematic diagram of an SOC according to the present invention;

fig. 5 is a flowchart at the time of SOC start-up.

Detailed Description

The technical terms described in the invention are defined as follows:

soc (system on chip): a system on chip as shown in fig. 4.

Boot ROM: a read-only memory containing a boot code.

Bl1 (boot loader stage 1): a first level boot program.

4. Public key (public key): the public key in the asymmetric encryption algorithm can be published in public and is derived from the private key.

5. Private key): the private key in the asymmetric encryption algorithm cannot be revealed and cannot be derived from the public key.

Efuse (Electronic Fuse): an electronic fuse, a solid-state memory capable of writing data only once, realizes information storage by melting metal to form permanent electrical connection, has default value of 0 when not writing, has default value of 1 after writing, and cannot write back 0 after writing once.

Otp (one time program): the one-time programmable memory has default value of 1 when not programmed, is 0 after programmed, and cannot be programmed back to 1 after programmed once.

Flag bit: the bit is marked.

Bitmap: the bitmap, the status is indicated by 0/1 of the data bit.

The invention discloses a method for preventing a device firmware version from rolling back, which comprises the following steps:

and step 1, generating a plurality of public and private key pairs during SOC production, and storing the public keys or the public key hash into a Boot ROM. In the SOC design stage, multiple sets of public and private key pairs are generated, and there may be multiple generation strategies: i. the client generates a public-private key pair, the private key client manages, and the client signs BL1 by itself; generating a public-private key pair by a trusted third party, and enabling the BL1 to be submitted to the third party by a client for signing; and thirdly, generating a public-private key pair by the SOC designer, and enabling the client to transmit BL1 to the SOC designer for signing. Dividing the obtained public keys into a plurality of groups: i. grouping according to different customer groups; grouping according to different signature algorithms.

Step 2, defining a bitmap for indicating the validity of the public key, and allocating a bit to each public key for indicating whether the public key is valid or not, namely indicating the validity of the public key, wherein the bitmap is stored in an EFUSE or OTP module in the chip; if EFUSE is used to save bitmap, 0 indicates valid and 1 indicates invalid; if OTP is used to save bitmap, then 1 indicates valid and 0 indicates invalid.

And 3, in the initial state, all public keys are defaulted to be effective, one public key is selected to carry out signature verification on BL1, when the BL1 has loopholes or risks, the flag bit of the public key bitmap of the EFUSE or OTP module corresponding to the currently used public key is invalid (the EFUSE is written as 1, the OTP is written as 0), namely, the indication is invalid, an effective public key is reselected, the new effective public key is used for signature verification of BL1, namely, the validity of the public key is configured by changing the public key bitmap of the EFUSE/OTP module, and the function of invalidating signature authentication of an old version is realized, so that the effect of preventing the firmware version of the equipment from rolling back is achieved.

The public key signing process in fig. 5 is:

step 1: after the SOC is electrified, starting from Boot ROM codes, initializing BL1 signature verification environment, wherein the codes in the Boot ROM cannot be modified;

step 2: reading out a public key bitmap stored in the SOC internal EFUSE or OTP for bitmap data indicating validity of the public key;

step 3: searching the next valid public key or public key hash from front to back through the public key bitmap;

step 4.1: checking whether the public key is found or not, if so, acquiring a valid public key or a public key hash, and jumping to the step 5; if the step 4.2 is not found to be continued;

step 4.2: checking whether all public key bitmap data are searched, if yes, starting failure, otherwise jumping to step 3;

step 5: if the public key is directly stored in the Boot ROM, the step is skipped; if the public key hash is stored in the Boot ROM, the public key is stored in the BL1, and the correctness of the public key in the BL1 is compared and confirmed according to a hash algorithm; if the verification is successful, continuing to the next step, otherwise, jumping to the step 3;

step 6: and (3) according to the obtained effective public key, verifying the signature data of the BL1 by using a public-private key algorithm, if the signature verification is successful, jumping to the BL1 to continue execution, otherwise jumping to the step (3).

The above is only a preferred embodiment of the present invention, but the scope of the present invention is not limited thereto. Any of the features based on the present invention, which are basically the same means to realize basically the same functions and basically the same effects, are also included in the protection scope of the present invention, and can be replaced by features that can be suggested by a person of ordinary skill in the art without creative effort when the infringement occurs.

Claims

1. A method of preventing rollback of a device firmware version, comprising the steps of:

2. The method for preventing rollback of a firmware version of a device according to claim 1, wherein in step 1 the public-private key pair generation policy generates a public-private key pair for a client, the private key client manages, and the client signs BL1 by itself.

3. The method of preventing rollback of device firmware versions of claim 1, wherein in step 1 the public-private key pair generation policy is that a trusted third party generates a public-private key pair, and the client signs BL1 with the third party.

4. The method of preventing rollback of device firmware versions of claim 1, wherein the public-private key pair generation policy in step 1 is that a public-private key pair is generated by an SOC designer, and the client submits BL1 to the SOC designer for signing.

5. A method of preventing rollback of a device firmware version as claimed in claim 1 wherein the generated public key is grouped in step 1.

6. A method of preventing rollback of device firmware versions according to claim 5, wherein the public key is grouped by different client groups or by different signature algorithms.

7. The method of preventing rollback of device firmware versions according to claim 1, wherein the public key bitmap in step 2 is written into an on-chip EFUSE or OTP module, on which a public key validity flag is defined.