Detailed Description
In order to describe the technical contents, the achieved objects and effects of the present invention in detail, the following description will be made with reference to the embodiments in conjunction with the accompanying drawings.
In the prior art, if the firmware is not signed or the signature is wrong due to the use of an error key under the condition that the hardware of the device is fused, the device cannot be started after upgrading.
To solve at least the above technical problems, the present disclosure provides a method for signing firmware upgrade. According to the method, the device and the system, the firmware to be upgraded is signed and stored in a firmware upgrading package, then the firmware is in a firmware upgrading mode, a digital signature algorithm and a public key parameter are transmitted to a device tree of a memory, a fusing mark and a locking mark are transmitted to a command line parameter, and if the fusing mark in the command line parameter indicates that the device is fused or the locking mark indicates that the device is locked, the signed firmware to be upgraded is verified, and the firmware which is verified to be successful is upgraded. In this way, according to the embodiment of the disclosure, no signature or signature error firmware can be avoided after the firmware is upgraded, so that the equipment can be normally started, and the reliability of the firmware upgrade is improved.
Hereinafter, a technical scheme according to the present disclosure will be described with reference to specific embodiments and with reference to the accompanying drawings.
Fig. 1 is a flowchart illustrating a signed firmware upgrade method 100 according to an embodiment of the present disclosure. Referring to fig. 1, the method 100 includes the following steps 102-108.
At step 102, the firmware to be upgraded is signed. In some embodiments, the firmware to be upgraded includes one or more of boot strap firmware, trusted operating system firmware, boot firmware, upgrade mode firmware. In this way, the firmware to be upgraded at least comprises one firmware, so that the universality of the firmware signature can be improved.
In some embodiments, a type tag of a header of the firmware to be upgraded is obtained, and each firmware in the firmware to be upgraded is signed in a corresponding signature manner according to the firmware and the type tag included in the firmware to be upgraded. In this way, the signature manner is determined according to the firmware and the type mark included in the firmware to be upgraded, and flexibility of the signature is improved.
In step 104, the signed firmware to be upgraded is stored in the firmware upgrade package, and the firmware upgrade mode is entered. In some embodiments, after the firmware upgrade package is obtained by the device, the device verifies the validity of the firmware upgrade package, and if the firmware upgrade package is valid, the device initiates a firmware upgrade, and the device is booted into a firmware upgrade mode.
At step 106, the digital signature algorithm and public key parameters are passed into the device tree of memory and the fuse and lock flags are passed into the command line parameters by the boot strap firmware in the firmware to be upgraded. In some embodiments, when the public key of each level of boot strap firmware is legal, the digital signature algorithm, the public key parameter, the fusing flag and the locking flag are transferred to the next level of boot strap firmware that passes the verification using the current level of boot strap firmware that passes the verification until the last level of boot strap firmware. In addition, the digital signature algorithm and the public key parameters in the last stage boot loader firmware are written into the device tree of the memory, and the fusing mark and the locking mark are written into the command line parameters. In this way, under the condition that the public key is legal and all levels of starting bootstrap programs pass verification, the transmission of the digital signature algorithm, the public key parameters, the fusing mark and the locking mark can be safely carried out, and the security of the firmware signature is ensured.
In some embodiments, when verifying the validity of the public key of each level of boot firmware, it is necessary to extract the public key information in each level of boot firmware and calculate the digital digest of the public key information, and if the calculation result is the same as the preset result, the public key is legal. In this way, the security of the firmware signature can be improved.
In some embodiments, the data in the device tree and command line parameters is sent to the upgrade mode firmware in the firmware to be upgraded, and if the upgrade mode firmware passes the verification, the upgrade mode firmware is guided to perform firmware upgrade. In this way, the upgrade mode firmware is able to receive the digital signature algorithm, public key parameters, fusing flag, and locking flag in the device tree and command line parameters, facilitating subsequent firmware upgrades.
In step 108, when the fusing flag included in the command line parameter indicates that the device fuses or the locking flag indicates that the device is locked, the firmware to be upgraded after the signature in the firmware upgrade package is checked, and the firmware that is checked successfully is upgraded. In some embodiments, if the fusing flag contained in the command line parameters indicates that the device is not fused and the locking flag indicates that the device is not locked, the firmware to be upgraded is directly upgraded. In this way, the firmware without signature or signature error can be obtained after the firmware is upgraded, so that the equipment is ensured to be normally started, and meanwhile, under the condition that the equipment is not fused, the legal upgrade package is allowed to be directly upgraded, and the reliability of the firmware upgrade is improved.
In some embodiments, when the fusing flag in the command line parameter is true, the boot loader firmware, the trusted operating system firmware, the boot firmware and the upgrade mode firmware in the firmware upgrade package are sequentially checked, if all the checks are successful, the check result is marked as successful and the firmware is upgraded, otherwise, when the locking flag in the command line parameter is true, the boot firmware and the upgrade mode firmware in the firmware upgrade package are sequentially checked, and if all the checks are successful, the check result is marked as successful and the firmware is upgraded. In this way, the firmware can be checked pertinently according to the fusing mark or the locking mark, and the checking efficiency is improved.
In step 110, the firmware to be upgraded, which is checked successfully, is upgraded.
In some embodiments, the firmware in the firmware upgrade package is stored in a memory or a readable and writable file system partition in the form of a temporary file, and a path where the temporary file is located is checked. In this way, asynchronous verification can be performed in the form of a temporary file, further improving verification efficiency.
According to the embodiment of the disclosure, through the signature firmware upgrading method, the firmware to be upgraded can be firstly subjected to signature verification under the condition of fusing equipment, and the firmware is ensured to be allowed to be upgraded after verification is passed, so that the problem that the equipment cannot be started after upgrading the firmware without signature or with wrong signature is solved. And meanwhile, under the condition that the equipment is not fused, the legal upgrade package is allowed to be directly upgraded, and the availability of the equipment and the development and debugging efficiency of the equipment are improved. In this way, upgrades of the signed firmware are achieved, thereby improving the reliability of the firmware upgrade.
Hereinafter, application scenarios of the signature firmware upgrade method and apparatus according to the embodiment of the present invention will be described by way of example.
Fig. 2 is a flowchart illustrating a signed firmware upgrade method according to an embodiment of the present invention, including the following steps 202 to 208.
At step 202, the firmware to be upgraded is signed. The method comprises the steps of generating a pair of public and private keys according to a selected digital signature algorithm, and signing a to-be-verified firmware binary file, wherein the firmware signature specifically comprises signing one or more of a boot loader firmware, a trusted operating system firmware, a boot firmware and an upgrade mode firmware of the to-be-upgraded firmware.
When signing the boot strap firmware, the boot strap firmware can be classified into three types, namely a type one, a type two and a type three according to the magic numbers of the firmware head. The boot strap firmware comprises a plurality of levels of boot strap firmware, wherein the one level of boot strap firmware must be type one.
For type one, the digital signature algorithm and public key parameter information are first written to a specific location of the firmware, while the signature tag (e.g., signFlag) field of the firmware header is set to the signature tag, then the entire firmware is signed using the private key, and the signature information is written to the firmware trailer.
For type two, the last three parts of the firmware header are a message digest algorithm type field, a message digest field (e.g., hash), and a block reserved area, respectively, where the message digest field holds a message digest calculated from the algorithm specified by the message digest algorithm type for all the firmware header information preceding that field. The last reserved area part of the head comprises three aspects of contents, namely a firmware signature mark, a digital signature information length and digital signature information.
In the type two firmware signing process, firstly, a signature mark (such as SignFlag) field of a firmware head is set as a signature mark, the value of a digital signature information length field of the firmware head is set according to the type of a digital signature algorithm, and finally, a private key is used for signing a message digest field (such as a hash) of the firmware head, and signature information is written into a digital signature information area of the firmware head.
For type three, the firmware is in the FIT format, and then the firmware in the FIT format is signed according to the uboot FIT signature method.
When signing the trusted operating system firmware, the trusted operating system firmware can be classified into two types, namely type one and type two, according to the magic numbers of the firmware header.
For type one, the last three parts of the firmware header are a message digest algorithm type field, a message digest field (e.g., hash), and a block reserved area, respectively, where the message digest field holds a message digest calculated from the algorithm specified by the message digest algorithm type for all the firmware header information preceding that field. The last reserved area part of the head comprises three aspects of contents, namely a firmware signature mark, a digital signature information length and digital signature information.
In a type one firmware signing process, firstly, a signature mark (such as SignFlag) field of a firmware header is set as a signature mark, a value of a digital signature information length field of the firmware header is set according to a digital signature algorithm type, and finally, a private key is used for signing a message digest field (such as a hash) of the firmware header, and signature information is written into a digital signature information area of the firmware header.
For type two, the firmware of the type comprises a plurality of sub-firmware (such as ATF firmware and TEE OS firmware) with the layout of the firmware comprising basic header information, sub-firmware meta-information, digital signature information and binary data of each sub-firmware.
Wherein the "basic header information" includes a firmware signature flag, a message digest algorithm type field, a digital signature algorithm type field, and a digital signature information offset address field. The sub-firmware meta-information includes information such as message digests and loading addresses of the respective sub-firmware.
In the type two firmware signing process, firstly, a signature mark (such as SignFlag) field of a firmware head is set as a signature mark, and a message digest algorithm type field, a digital signature algorithm type field and a digital signature information offset address field are respectively set. And then calculating a message digest of all information (namely 'basic header information+sub-firmware meta information' in firmware) before the digital signature information offset address field according to an algorithm specified by a message digest algorithm type field, finally signing the calculated message digest by using a private key, and writing signature information into a position specified by the digital signature information offset address field.
When signing the boot firmware (such as boot. Img), the boot firmware can be classified into two types, namely an Android format and an FIT format according to the magic numbers of the firmware header.
There are two signature modes for Android formatted firmware, mode one and mode two.
The first way is to sign the firmware using standard Android Verity.
The second mode is that firstly, a signature mark is written in a certain fixed position of a reserved field of a BOOT firmware head (such as a BOOT loader), then field content (such as an id field) which changes in each compiling in the BOOT firmware head (such as the BOOT loader) is taken as signed content, finally, a private key is used for signing the signed content, and signature information is written in a certain fixed position of the reserved field of the BOOT firmware head (such as the BOOT loader).
For the FIT format, the firmware in the FIT format is signed according to the uboot FIT signature method.
When signing the upgrade mode firmware (such as recovery. Img), the upgrade mode firmware can be classified into two types, namely an Android format and an FIT format according to the magic numbers of the firmware header.
There are two signature modes for Android formatted firmware, mode one and mode two.
The first way is to sign the firmware using standard Android Verity.
The second mode is that firstly, a signature mark is written in a certain fixed position of a reserved field of a BOOT firmware head (such as a BOOT loader), then field content (such as an id field) which changes in each compiling in the BOOT firmware head (such as the BOOT loader) is taken as signed content, finally, a private key is used for signing the signed content, and signature information is written in a certain fixed position of the reserved field of the BOOT firmware head (such as the BOOT loader).
For the FIT format, the firmware in the FIT format is signed according to the uboot FIT signature method.
In step 204, the signed complete firmware to be upgraded is put into a firmware upgrade package, after the device obtains the firmware upgrade package, the validity of the upgrade package is checked, after the upgrade package is legal, the firmware upgrade is started, and the device is guided to enter a firmware upgrade mode (such as recovery).
At step 206, the device boots, the boot strap program passes the digital signature algorithm and public key parameters to the device tree in memory, and passes the device fuse flag and the device lock flag to the command line parameters.
Specifically, when the device is started, the ROM firmware of the SoC chip checks the validity of public key information in the first-stage starting bootstrap firmware in the storage medium, namely, firstly reads the public key information in the first-stage starting bootstrap firmware to be booted, calculates the digital abstract of the public key information, compares the digital abstract with the OTP or efuse in the device chip, and verifies the validity of the public key. And if the public key is legal, checking the first-stage boot loader firmware to be booted, and loading and starting the first-stage boot loader after the checking is passed.
And sequentially checking the next-stage boot loader to be booted in the storage medium, and sequentially transmitting information such as a digital signature algorithm, public key parameters and the like contained in the firmware of the first-stage boot loader to the last-stage boot loader (such as uboot) after the verification is passed. The primary boot loader also passes the fusing flag of the device to the last primary boot loader.
In the last stage of boot program, the information such as digital signature algorithm and public key parameter transmitted from the first stage of boot program is written into the equipment tree (dtb) area in the memory, and relevant nodes are created, and the whole equipment tree area is transmitted to the upgrade mode firmware (such as recovery). The fusing flag write command line parameters passed by the primary boot loader are passed to the upgrade mode firmware (e.g., recovery). And reads the device's lock flag, passes the flag write command line parameters to the upgrade mode firmware (e.g., recovery). And checking the upgrade mode firmware in the storage medium to be booted, and after the verification is passed, booting the upgrade mode firmware.
In step 208, in firmware upgrade mode, the device fusing flag and the device locking flag in the command line parameters are first read. Wherein a device blown flag (e.g., fuse. Programmed) is present and true indicates blown, otherwise no blown, and a device locked flag is present and locked indicates that the device is locked, otherwise no locked.
Judging whether the equipment is fused according to the equipment fusing mark, if the equipment is fused, executing the following step 210, if the equipment is not fused and is not locked, executing a firmware upgrading flow to finish upgrading the equipment firmware, and if the equipment is not fused but is in a locked state, executing the following steps 2082 to 2084.
At step 2082, the upgrade package is checked to see if boot firmware (e.g., boot. Img) is present.
If not, step 2084 is performed. If so, boot firmware (such as boot. Img) is extracted from the upgrade package and stored in a Memory or readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file, if the path is checked successfully, checking whether the upgrade mode firmware exists, otherwise, setting a check result mark as failure, and executing step 212.
At step 2084, the upgrade package is checked to see if upgrade mode firmware (e.g., recovery. Img) is present.
If not, the check result flag is set to successful and step 212 is performed. If so, upgrade mode firmware (such as recovery. Img) is extracted from the upgrade package and stored in a Memory or in a readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file, if the check is successful, setting a check result mark as successful, otherwise, setting a check result mark as failed. After the check result flag is set, step 212 is performed.
At step 210, a firmware binary to be verified is extracted from the upgrade package to the memory or the readable and writable file system partition, where the firmware binary to be verified includes one or more of boot loader firmware, trusted operating system firmware (e.g., TEE and ATF), boot firmware (e.g., boot. Img), and upgrade mode firmware (e.g., recovery. Img). Wherein, the boot program may have multiple stages, and if the boot program has multiple stages, the boot programs of the respective stages are sequentially extracted and verified, that is, the following steps 2102 to 2108 are performed.
At step 2102, the upgrade package is checked to see if startup bootstrap firmware exists.
If not, step 2104 is performed. If so, the boot strap firmware is extracted from the upgrade package and stored in a Memory or in a readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file. If the verification is successful, then see if there is trusted operating system firmware, otherwise set the verification result flag as failed, and execute step 212.
If the boot program has multiple stages, extracting boot program firmware of each stage from the firmware upgrade package in sequence, storing the boot program firmware of each stage in a Memory or a readable and writable file system partition in a temporary file mode, checking a path where the extracted temporary file is located, continuing checking the next stage of boot program firmware if the checking is successful until all boot program firmware of the boot program is checked successfully, checking whether trusted operating system firmware exists or not, if the checking is failed, setting a check result mark as failed, and executing step 212.
At step 2104, the upgrade package is checked to see if trusted operating system firmware is present.
If not, step 2106 is performed. If so, the trusted operating system firmware is extracted from the upgrade package and stored in a Memory or in a readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file. If the verification is successful, it is checked whether there is boot firmware, otherwise the verification result flag is set as failed, and step 212 is performed.
At step 2106, the upgrade package is checked to see if boot firmware (e.g., boot. Img) is present.
If not, step 2108 is performed. If so, boot firmware (such as boot. Img) is extracted from the upgrade package and stored in a Memory or in a readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file. If the verification is successful, it is checked whether there is upgrade mode firmware, otherwise the verification result flag is set as failed, and step 212 is performed.
At step 2108, the upgrade package is checked to see if upgrade mode firmware (e.g., recovery. Img) is present.
If not, the check result flag is set to successful and step 212 is performed. If so, upgrade mode firmware (such as recovery. Img) is extracted from the upgrade package and stored in a Memory or in a readable and writable file system partition in the form of a temporary file. And then checking the path of the extracted temporary file. If the verification is successful, setting the verification result mark as successful, otherwise, setting the verification result mark as failed. After the check result flag is set, step 212 is performed.
In step 212, the verification result mark is read, if the mark is failed, the firmware upgrading process is exited, the firmware is prompted to be verified to be wrong and cannot be upgraded, and if the mark is successful, the firmware upgrading process is executed, and the equipment firmware is upgraded.
According to another aspect of the invention, FIG. 3 is a schematic diagram illustrating a signed firmware upgrade apparatus 300 according to an embodiment of the invention. Referring to fig. 3, the electronic device 300 includes a memory 302, a processor 304, and a computer program stored on the memory and executable on the processor, which when executed implements the steps of the signed firmware upgrade method as described above.
According to yet another aspect of the present invention, a computer-readable medium is provided. The computer readable medium has stored thereon a computer program that is executed by a processor to implement the signed firmware upgrade method as described above.
In summary, in the method, the device and the computer readable medium for upgrading the signed firmware provided by the invention, one or more of the boot strap firmware, the trusted operating system firmware, the boot firmware and the upgrade mode firmware contained in the firmware to be upgraded are signed, and the versatility of the firmware signature can be improved because the firmware to be upgraded contains at least one of the above-mentioned firmware. Storing the signed firmware to be upgraded into a firmware upgrading packet, and entering a firmware upgrading mode when the firmware upgrading packet passes the validity check. In addition, the fusing tag and the locking tag are passed to the command line parameters by starting the bootstrap program to pass the digital signature algorithm and the public key parameters to the device tree of the memory. If the fusing mark contained in the command line parameter is true or the locking mark is true, verifying the signed firmware to be upgraded in the firmware upgrading packet, upgrading the successfully verified firmware, and if the fusing mark and the locking mark are not true, directly upgrading the firmware to be upgraded. Therefore, under the condition of fusing equipment, the firmware to be upgraded can be signed and checked, and the firmware is ensured to be upgraded after being checked, so that the firmware which is not signed or has a wrong signature after being upgraded is avoided, and the equipment is ensured to be normally started. Meanwhile, under the condition that the equipment is not fused, the legal upgrade package is allowed to be directly upgraded, and the usability of the equipment, the development and debugging efficiency of the equipment and the reliability of firmware upgrade are improved.
The foregoing description is only illustrative of the present invention and is not intended to limit the scope of the invention, and all equivalent changes made by the specification and drawings of the present invention, or direct or indirect application in the relevant art, are included in the scope of the present invention.