CN114595460A - Signature firmware verification method, device and computer readable medium - Google Patents
Signature firmware verification method, device and computer readable medium Download PDFInfo
- Publication number
- CN114595460A CN114595460A CN202210027834.6A CN202210027834A CN114595460A CN 114595460 A CN114595460 A CN 114595460A CN 202210027834 A CN202210027834 A CN 202210027834A CN 114595460 A CN114595460 A CN 114595460A
- Authority
- CN
- China
- Prior art keywords
- firmware
- information
- type
- signature
- upgraded
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a signature firmware verification method, equipment and a computer readable medium, wherein a firmware to be upgraded is signed, public key information in a tree node of the equipment is obtained, a magic digital field in the firmware to be upgraded is read, the type of the corresponding firmware in the firmware to be upgraded is determined according to the magic digital field, and signature verification corresponding to the type of the firmware is carried out on the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic digital field at the head of the firmware to be upgraded, and the corresponding signature verification is carried out on the firmware of the type according to the public key, so that the different firmware types in the firmware to be upgraded can be subjected to targeted verification, and the accuracy of the signature verification is improved.
Description
Technical Field
The present invention relates to the field of embedded technologies, and in particular, to a method and an apparatus for verifying a signature firmware, and a computer readable medium.
Background
Currently, a device supporting secure boot needs to sign firmware and verify the firmware during the boot process. However, existing FOTA (Firmware Over-The-Air) Firmware upgrade schemes are typically direct upgrades to signed Firmware. When the device hardware (such as an SoC chip) is blown, if the firmware is not signed or a signature error is caused by using an incorrect key, the device cannot be started after the upgrade, and therefore signature verification of the firmware is particularly important.
Disclosure of Invention
The invention aims to provide a signature firmware verification method, equipment and a computer readable medium, which can improve the accuracy of signature verification.
In one aspect of the invention, a signed firmware verification method is provided. The method comprises the following steps: signing the firmware to be upgraded; acquiring public key information in equipment tree nodes, and reading magic digital fields in firmware to be upgraded; and determining the corresponding firmware type in the firmware to be upgraded according to the magic digital field, and performing signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information.
In another aspect of the present invention, a signed firmware verification device is provided. The apparatus comprises a memory configured to store a computer program; and a processor configured to execute the computer program to perform the signature firmware verification method described above.
In yet another aspect of the invention, a computer-readable medium is provided. The medium has stored thereon a computer program that is executed by a processor to implement the signature firmware verification method described above.
The invention has the beneficial effects that: signing the firmware to be upgraded, acquiring public key information in the equipment tree nodes, reading a magic digital field in the firmware to be upgraded, determining the type of the corresponding firmware to be upgraded according to the magic digital field, and performing signature verification corresponding to the type of the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic digital field at the head of the firmware to be upgraded, and the corresponding signature verification is carried out on the firmware of the type according to the public key, so that the different firmware types in the firmware to be upgraded can be subjected to targeted verification, and the accuracy of the signature verification is improved.
Drawings
FIG. 1 is a flow diagram of a signed firmware verification method according to an embodiment of the invention;
FIG. 2 is a flowchart for verifying boot strap firmware and trusted operating system firmware;
FIG. 3 is a flow chart of verifying boot firmware;
FIG. 4 is a flow chart of verifying upgrade mode firmware;
fig. 5 is a block diagram of a signed firmware verification apparatus according to an embodiment of the present invention.
Detailed Description
In order to explain technical contents, achieved objects, and effects of the present invention in detail, the following description is made with reference to the accompanying drawings in combination with the embodiments.
In the prior art, when the hardware of the device is blown, if the firmware is not signed or the signature is wrong due to the use of a wrong key, the device cannot be started after the upgrade, and therefore, the accuracy of the verification of the signature of the firmware needs to be improved.
To address at least the above technical problems, the present disclosure provides a method for signature firmware verification. According to the method, the firmware to be upgraded is signed, public key information in the equipment tree nodes is obtained, and magic digital fields in the firmware to be upgraded are read; and determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field, and performing signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information. In this way, according to the embodiment of the disclosure, different firmware types in the firmware to be upgraded can be subjected to targeted verification, and the accuracy of signature verification is improved.
Hereinafter, technical solutions according to the present disclosure will be described with reference to specific embodiments and with reference to the accompanying drawings.
Fig. 1 is a flow diagram illustrating a signed firmware verification method 100 according to an embodiment of the present disclosure. Referring to fig. 1, the method 100 includes the following steps 102 to 106.
At step 102, the firmware to be upgraded is signed. The firmware to be upgraded comprises one or more of boot-strap firmware, trusted operating system firmware, boot-up firmware, and firmware of upgrade mode firmware. In some embodiments, a pair of public key and private key is generated according to a preset digital signature algorithm, each firmware in the firmware to be upgraded is sequentially acquired, the type of each firmware is determined according to a magic digital field at the head of the firmware to be upgraded, a signature method required by each firmware is determined according to the type of each firmware, the signature is carried out by using the private key, and finally, the public key information is stored in the equipment tree node. In this way, the firmware of each type of firmware to be upgraded can be signed specifically, and the security of firmware signing is guaranteed.
At step 104, public key information in the device tree node is obtained.
At step 106, the magic digital field in the firmware to be upgraded is read.
In step 108, the firmware type in the corresponding firmware to be upgraded is determined according to the magic number field.
In step 110, signature verification corresponding to the firmware type is performed on the firmware to be upgraded according to the public key information.
In some embodiments, if the magic number field corresponds to the first type or the second type of boot firmware, the boot firmware is read into the memory when the signature verification is performed. When the boot program firmware is started to have the signature mark, the first type of firmware reads the digital signature information according to the public key information, the second type of firmware reads the digital signature information according to the length field of the digital signature, calculates a message digest of information in the header of the boot program firmware, and verifies the digital signature information by using the public key information according to the message digest. In this way, different types of boot firmware can be adaptively verified.
In some embodiments, if the magic digital field corresponds to the first type or the second type of the trusted operating system firmware, the trusted operating system firmware is read into the memory first when the signature verification is performed. When the trusted operating system firmware has a signature mark, the first type of firmware reads digital signature information according to the length field of the digital signature, calculates a message digest of information in the header of the trusted operating system firmware, verifies the digital signature information according to the message digest and by using public key information, and the second type of firmware calculates the message digest of data between an initial address in the trusted operating system firmware and an offset address of the digital signature information, reads the digital signature information according to the offset address of the digital signature information, and verifies the digital signature information according to the message digest and by using the public key information. In this way, different types of boot firmware can be adaptively verified.
In some embodiments, if the magic digital field corresponds to the Android boot type of the boot firmware, when the firmware to be upgraded has an image file, acquiring verification information related to the boot firmware from the image file for verification, or acquiring the verification information from the tail of the boot firmware for verification. And when the image file does not exist, directly acquiring the starting firmware in the firmware to be upgraded. And reading the starting firmware into the memory, if the starting firmware has a signature mark, re-signing the signed content in the starting firmware by using the public key, and verifying according to a signature result. In this way, different types of boot firmware can be adaptively verified.
In some embodiments, if the magic digital field corresponds to the Android boot type of the upgrade mode firmware, when the firmware to be upgraded has an image file, acquiring verification information related to the upgrade mode firmware from the image file for verification, or acquiring verification information from the tail of the upgrade mode firmware for verification. And when the image file does not exist, directly acquiring the upgrade mode firmware in the firmware to be upgraded. And reading the upgrade mode firmware into the memory, if the upgrade mode firmware has a signature mark, re-signing the signed content in the upgrade mode firmware by using the public key, and verifying according to a signature result. In this way, different types of upgrade mode firmware can be adaptively verified.
In some embodiments, if the firmware corresponding to the magic number field is in the FIT format, when the FDT node corresponding to the signature data exists in the firmware header, the firmware in the FIT format is verified according to the FIT firmware verification method. In this way, the method can carry out adaptive verification on the firmware in the preset format, and improve the accuracy and reliability of firmware signature verification.
According to the embodiment of the disclosure, different firmware types in the firmware to be upgraded can be subjected to targeted verification through the signature firmware verification method. In this way, the accuracy of signature verification is improved.
Hereinafter, application scenarios of the signature firmware verification method and apparatus according to the embodiment of the present invention will be described by way of examples.
When signing the firmware to be upgraded, the firmware to be upgraded comprises one or more of boot-strap program firmware, trusted operating system firmware, boot-up firmware and upgrade mode firmware.
Firstly, a pair of public and private keys is generated according to a selected digital signature algorithm, and a to-be-verified firmware binary file is signed.
If the boot firmware needs to be signed, the boot firmware can be divided into three types according to the difference of the magic numbers of the firmware headers: type one, type two, and type three. Where the primary boot firmware must be type one.
For type one, the digital signature algorithm and public key parameter information are first written into a specific location of the firmware, while the signature flag (e.g., SignFlag) field of the firmware header is set as the signature flag, and then the entire firmware is signed using the private key and the signature information is written into 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 reserved area, respectively, and the message digest field stores the message digest calculated by all firmware header information before the field according to the algorithm indicated by the message digest algorithm type. The rearmost reserved area part of the header includes three 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 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, finally, a message digest field (such as hash) of the firmware header is signed by using a private key, and signature information is written into a digital signature information area of the firmware header.
For type three, the firmware is in FIT format, then the firmware in FIT format is signed according to the uboot FIT signature method.
If the trusted operating system firmware needs to be signed, the trusted operating system firmware can be divided into two types according to the difference of magic numbers of firmware headers: type one and type two.
For type one, the last three parts of the firmware header are a message digest algorithm type field, a message digest field (such as hash), and a reserved area, and the message digest field stores the message digest calculated by all the firmware header information before the field according to the algorithm indicated by the message digest algorithm type. The rearmost reserved area part of the header includes three contents, namely a firmware signature mark, a digital signature information length and digital signature information.
In the type-one firmware signing process, a signature mark (such as SignFlag) field of a firmware header is firstly 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, finally, a message digest field (such as hash) of the firmware header is signed by using a private key, and signature information is written into a digital signature information area of the firmware header.
For type two, the firmware of this type includes a plurality of sub-firmware (such as ATF firmware and TEE OS firmware), and the firmware layout is: basic header information + sub-firmware meta-information + digital signature information + respective sub-firmware binary data.
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 "child firmware meta-information" includes information such as a message digest and a load address of each child firmware.
In the type two firmware signing process, a signature flag (such as SignFlag) field of a firmware header is firstly set as a signature flag, 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 the message digest of all information before the offset address field of the digital signature information (namely 'basic header information + sub-firmware meta information' in the firmware) according to the algorithm specified by the algorithm type field of the message digest, finally signing the calculated message digest by using a private key, and writing the signature information into the position specified by the offset address field of the digital signature information.
Img, if the boot firmware needs to be signed, the boot firmware can be classified into two types according to the difference of magic numbers of firmware headers: android format and FIT format.
There are two signature methods for firmware in Android format: mode one and mode two.
The first method is as follows: the firmware is signed using standard Android verify.
The second method comprises the following steps: firstly writing a signature mark in a certain fixed position of a reserved field of a BOOT firmware HEADER (such as BOOT HEADER), then taking the field content (such as id field) which changes every compilation in the BOOT firmware HEADER (such as BOOT HEADER) as the signed content, finally signing the signed content by using a private key, and writing signature information in a certain fixed position of the reserved field of the BOOT firmware HEADER (such as BOOT HEADER).
For the FIT format boot firmware, the FIT format firmware is signed according to the uboot FIT signature method.
If the upgrade mode firmware (such as recovery. img) needs to be signed, the upgrade mode firmware can be divided into two types according to the difference of the magic numbers of the firmware headers: android format and FIT format.
There are two signature methods for firmware in Android format: mode one and mode two.
The first method is as follows: the firmware is signed using standard Android verify.
The second method comprises the following steps: firstly writing a signature mark in a certain fixed position of a reserved field of a BOOT firmware HEADER (such as BOOT HEADER), then taking the field content (such as id field) which changes every compilation in the BOOT firmware HEADER (such as BOOT HEADER) as the signed content, finally signing the signed content by using a private key, and writing signature information in a certain fixed position of the reserved field of the BOOT firmware HEADER (such as BOOT HEADER).
For upgrade mode firmware in the FIT format, the firmware in the FIT format is signed according to the uboot FIT signature method.
FIG. 2 is a flowchart illustrating verification of boot-loader firmware and trusted operating system firmware, specifically performing steps 202 through 212.
In step 202, it is checked whether the firmware to be verified exists, and if not, the verification result flag is set to be successful, and the verification result flag is returned. If so, step 204 is performed.
In step 204, public key information (e.g.,/sys/firmware/device tree/base/public-key/data) of the device tree (dtb) node is obtained, including the public key algorithm and public key parameters used. And if the public key information is failed to be acquired, setting a verification result mark as successful and returning a verification result mark. If the public key information is successfully acquired, step 206 is performed.
In step 206, the magic number field of the firmware header is read, if the type of boot firmware corresponds to the first boot firmware type, the boot firmware verification of step 2082 is executed, and if the type of boot firmware corresponds to the second boot firmware type, the boot firmware verification of step 2084 is executed; if the magic number corresponds to the trusted operating system firmware type one, the trusted operating system firmware verification of the step 2102 is executed, and if the magic number corresponds to the trusted operating system firmware type two, the trusted operating system firmware verification of the step 2104 is executed; if so, step 212 is performed.
In step 2082, if the magic number field of the firmware header corresponds to the boot loader type one, the boot loader firmware to be verified is completely read into the Memory, the signature flag (such as SignFlag) field of the firmware header is checked, if the firmware has no signature, the verification result flag is set to fail, and the verification result flag is returned. If the firmware has a signature, reading digital signature information with a fixed length at the tail of the boot program firmware according to the type of the public key algorithm obtained in the step 204, then obtaining the content of the boot program firmware except the tail digital signature information, verifying the digital signature information by using the public key algorithm and the public key parameters obtained in the step 204, and judging whether the signature information is matched, if so, setting a verification result as successful and returning, otherwise, setting a verification result as failed and returning.
In step 2084, if the magic number field of the firmware header corresponds to the boot loader type two, the header of the boot loader firmware to be verified is read into the Memory, the signature mark (such as SignFlag) field of the firmware header is checked, if the firmware has no signature, the verification result mark is set to fail, and the verification result mark is returned. If the firmware has the signature, reading a digital signature length field of a firmware header, and then reading digital signature information with a specified length after the digital signature length field according to the value of the digital signature length field. And calculating the message digest of all firmware header information before the message digest field of the firmware header according to the message digest algorithm type field of the firmware header, finally checking the digital signature information according to the calculated message digest by using the public key algorithm and the public key parameters acquired in the step 204 to see whether the signature information is matched, if the signature information is matched, setting a check result mark as successful and returning, otherwise, setting a check result mark as failed and returning.
At step 2102, if the magic number field of the firmware header corresponds to the trusted operating system firmware type one, the header of the trusted operating system firmware to be verified is read into the Memory, the signature flag (e.g., SignFlag) field of the firmware header is checked, if the firmware is not signed, the verification result flag is set to fail, and the verification result flag is returned. If the firmware has the signature, reading a digital signature length field of a firmware header, and then reading digital signature information with a specified length after the digital signature length field according to the value of the digital signature length field. And calculating the message digest of all firmware header information before the message digest field of the firmware header according to the message digest algorithm type field of the firmware header, finally checking the digital signature information according to the calculated message digest by using the public key algorithm and the public key parameters acquired in the step 204 to see whether the signature information is matched, if the signature information is matched, setting a check result to be marked as successful and returning, and if not, setting the check result to be marked as failed and returning.
In step 2104, if the magic number field of the firmware header corresponds to the trusted operating system firmware type two, the header of the trusted operating system firmware to be verified is read into the Memory, the signature flag (e.g., SignFlag) field of the firmware header is checked, if the firmware has no signature, the verification result flag is set to fail, and the verification result flag is returned. If the firmware has a signature, reading a message digest algorithm type field, a digital signature algorithm type field and a digital signature information offset address field of a firmware header, reading all data between the initial 0x0 position of the trusted operating system firmware and the digital signature information offset address to a buffer area according to the value of the digital signature information offset address field, and calculating a corresponding message digest for the read data (namely the data in the buffer area) according to the algorithm type (such as SHA-256) indicated by the message digest algorithm type field. Determining the length of the digital signature information according to the algorithm type (such as RSA-2048) indicated by the digital signature algorithm type field, positioning the trusted operating system firmware to be verified to the position indicated by the digital signature information offset address field, and reading the digital signature information with the determined length. And finally, according to the calculated message digest, verifying the digital signature information by using the public key algorithm and the public key parameters acquired in the step 204 to see whether the signature information is matched, if the signature information is matched, setting a verification result as successful and returning, and if not, setting the verification result as failed and returning.
In step 212, if the magic number field of the firmware header corresponds to firmware in the fit (signed Image tree) format, checking whether an FDT node (such as signature) corresponding to the signature data exists in the firmware header, if not, indicating that the firmware has no signature, setting a check result flag to fail, and returning the check result flag. And if the FDT node corresponding to the signature data exists, the firmware has a signature, and at the moment, the firmware in the FIT format is verified according to an FIT firmware verification method. If the verification is successful, the verification result is set to be marked as successful and returned, otherwise, the verification result is set to be marked as failed and returned.
And if the magic number field of the firmware header corresponds to the firmware in other formats, setting the verification result mark as successful and returning the verification result mark.
Fig. 3 is a flowchart illustrating the verification of the boot firmware, specifically executing step 302 to step 310.
In step 302, it is checked whether the firmware to be verified exists, and if not, the verification result flag is set to be successful, and the verification result flag is returned. If so, step 304 is performed.
In step 304, public key information (e.g.,/sys/firmware/device tree/base/public-key/data) of the device tree (dtb) node is obtained, including the public key algorithm and public key parameters used. And if the public key information is failed to be acquired, setting a verification result mark as successful and returning a verification result mark. If the public key information is successfully acquired, step 306 is executed.
In step 306, reading the magic number field of the firmware header, and if the corresponding type is the Android Boot firmware type, executing the starting firmware verification in step 308; if the magic number corresponds to firmware in the fit (flattened Image tree) format, the following boot firmware verification of step 310 is performed; if the value is other, the check result mark is set to be successful, and the check result mark is returned.
In step 308, if the magic number corresponds to the verification of the Android Boot-type Boot firmware, specifically executing steps 3082 to 3086.
In step 3082, if a vbmeta image (e.g., vbmeta. img) exists in the firmware to be upgraded, the vbmeta image (e.g., vbmeta. img) is first extracted from the firmware to be upgraded and stored in the Memory or in the read-write file system partition as a temporary file. And then checking whether the vbmeta image comprises check information related to boot firmware (such as boot. img) or not, if the vbmeta image comprises the check information related to the boot firmware, setting a check result to be marked as successful and returning the check result, otherwise, checking the boot firmware (such as boot. img) according to the check information in the vbmeta image, if the check is successful, setting the check result to be marked as successful and returning the check result, and otherwise, setting the check result to be marked as failed and returning the check result.
If the vbmeta image does not contain verification information related to boot firmware (such as boot. img) and the device is not blown, setting a verification result to be marked as successful and returning; if the device is in a blown state, step 3084 is performed.
In step 3084, if the vbmeta image (e.g., vbmeta.img) does not exist in the firmware to be upgraded, checking whether check information exists at the tail of the boot firmware (e.g., boot.img), if so, setting a check result to be marked as successful and returning if the device is in a non-locked state, otherwise, checking the boot firmware (e.g., boot.img) according to the check information in the tail of the boot firmware (e.g., boot.img), if the check is successful, setting the check result to be marked as successful and returning, otherwise, setting the check result to be marked as failed and returning.
Img, if the tail of the boot firmware (such as boot) does not contain the verification information and the device is not fused, setting a verification result to be marked as successful and returning; if the device is in a blown state, step 3086 is performed.
In step 3086, the Android Boot header information of the Boot firmware to be verified is read into the Memory, the signature mark (such as SignFlag) information in the reserved field of the firmware header is checked, if the firmware has no signature, the verification result mark is set to fail, and the verification result mark is returned. If the firmware has the signature, the digital signature information length information behind the signature mark information in the reserved field of the firmware header is continuously read, and then the digital signature information with the specified length behind the digital signature length information in the reserved field of the firmware header is continuously read according to the value of the digital signature length field. And finally, acquiring signed content (such as an id field) of the firmware header, verifying the digital signature information by using the public key algorithm and the public key parameters acquired in the step 304 to see whether the signature information is matched, setting a verification result to be marked as successful and returning if the signature information is matched, and otherwise, setting the verification result to be marked as failed and returning.
In step 310, if the magic number corresponds to the checking of the FIT type boot firmware, checking whether an FDT node (such as signature) corresponding to the signature data exists in the firmware header, if not, indicating that the firmware does not have the signature, setting a check result flag to fail, and returning the check result flag. And if the FDT node corresponding to the signature data exists, the firmware has a signature, and at the moment, the starting firmware in the FIT format is verified according to an FIT firmware verification method.
FIG. 4 is a flow chart illustrating verification of upgrade mode firmware. Specifically, step 402 to step 410 are executed.
In step 402, it is checked whether the firmware to be verified exists, and if not, the verification result flag is set to be successful, and the verification result flag is returned. If so, step 404 is performed.
In step 404, public key information (e.g.,/sys/firmware/device tree/base/public-key/data) of the device tree (dtb) node is obtained, including the public key algorithm and the public key parameters used. And if the public key information is failed to be acquired, setting a verification result mark as successful and returning a verification result mark. If the public key information is successfully acquired, step 406 is performed.
In step 406, reading a magic number field of the firmware header, and if the corresponding type is an Android Boot firmware type, executing the firmware verification of the upgrade mode in step 408; if the magic number corresponds to firmware in an FIT (Flexible Image Tree) format, performing upgrade mode firmware verification of step 410; if the value is other, the check result mark is set to be successful, and the check result mark is returned.
In step 408, if the magic number corresponds to the verification of the Android Boot type upgrade mode firmware, specifically executing steps 4082 to 4086.
At step 4082, if a vbmeta image (e.g., vbmeta. img) exists in the firmware to be upgraded. The vbmeta image (e.g., vbmeta. img) is first extracted from the firmware to be upgraded and stored in the Memory or in the read-write file system partition as a temporary file. And then checking whether the vbmeta image comprises check information related to the upgrade mode firmware (such as recovery. img), if the vbmeta image comprises the check information related to the upgrade mode firmware (such as recovery. img), and if the vbmeta image comprises the check information related to the upgrade mode firmware, setting a check result to be marked as successful and returning, otherwise, checking the upgrade mode firmware (such as recovery. img) according to the check information in the vbmeta image, if the check is successful, setting the check result to be marked as successful and returning, and if the check is not successful, setting the check result to be marked as failed and returning.
If the vbmeta image does not contain verification information related to the upgrade mode firmware (recovery.img), whether the verification information exists at the tail of the upgrade mode firmware (such as recovery.img) is checked, if so, the verification result is set to be marked as successful and returned, otherwise, the upgrade mode firmware (such as recovery.img) is verified according to the verification information in the tail of the upgrade mode firmware (such as recovery.img), if the verification is successful, the verification result is set to be marked as successful and returned, otherwise, the verification result is set to be marked as failed and returned.
If the tail part of the firmware (such as recovery. img) in the upgrading mode does not contain the verification information and the equipment is not fused, setting a verification result to be marked as success and returning; if the device is in a blown state, step 4806 is performed.
At step 4084, if the firmware to be upgraded does not have a vbmeta image (e.g., vbmeta. img),
checking whether verification information exists at the tail part of the firmware (such as recovery.img) of the upgrade mode, if so, setting a verification result to be marked as success and returning, otherwise, verifying the firmware (such as recovery.img) of the upgrade mode according to the verification information at the tail part of the firmware (such as recovery.img) of the upgrade mode, if so, setting the verification result to be marked as success and returning, otherwise, setting the verification result to be marked as failure and returning.
If the tail of the firmware (such as recovery. img) in the upgrading mode does not contain the verification information and the equipment is not fused, setting a verification result to be marked as success and returning; if the device is in a blown state, step 4806 is performed.
In step 4086, read the Android Boot header information of the Boot firmware to be verified into the Memory, check the signature flag (e.g., SignFlag) information in the reserved field of the firmware header, if the firmware has no signature, set the verification result flag to fail, and return the verification result flag. If the firmware has the signature, the digital signature information length information behind the signature mark information in the reserved field of the firmware header is continuously read, and then the digital signature information with the specified length behind the digital signature length information in the reserved field of the firmware header is continuously read according to the value of the digital signature length field. And finally, acquiring signed content (such as an id field) of the firmware header, verifying the digital signature information by using the public key algorithm and the public key parameters acquired in the step 404 to see whether the signature information is matched, setting a verification result to be marked as successful and returning if the signature information is matched, and otherwise, setting the verification result to be marked as failed and returning.
In step 410, if the magic number corresponds to the verification of the FIT-type upgrade mode firmware, checking whether an FDT node (such as signature) corresponding to the signature data exists in the firmware header, if not, indicating that the firmware does not have the signature, setting a verification result flag to fail, and returning the verification result flag. And if the FDT node corresponding to the signature data exists, the firmware has a signature, and at the moment, the recovery mode or upgrade mode firmware of the FIT format is verified according to an FIT firmware verification method. If the verification is successful, the verification result is set to be marked as successful and returned, otherwise, the verification result is set to be marked as failed and returned.
Fig. 5 is a schematic diagram illustrating a signed firmware verification apparatus 500 according to another aspect of the present invention, according to an embodiment of the present invention. Referring to fig. 5, the electronic device 500 comprises a memory 502, a processor 504 and a computer program stored on said memory and executable on the processor, said processor implementing the signature firmware verification method as described above when executing said computer program.
According to yet another aspect of the 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 signature firmware verification method as described above.
In summary, in the signed firmware verification method, device and computer readable medium provided by the present invention, the firmware to be upgraded is signed, where the firmware to be upgraded includes one or more of boot firmware, trusted operating system firmware, boot firmware and firmware of upgrade mode firmware. In addition, public key information in the equipment tree node is obtained, a magic digital section of the head of the firmware to be upgraded is read, the type of the corresponding firmware in the firmware to be upgraded is determined according to the magic digital section, and signature verification corresponding to the type of the firmware is carried out on the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic digital field at the head of the firmware to be upgraded, and the corresponding signature verification is carried out on the firmware of the type according to the public key, so that the pertinence verification can be carried out on different firmware types in the firmware to be upgraded, and the accuracy of the signature verification is improved.
The above description is only an embodiment of the present invention, and is not intended to limit the scope of the present invention, and all equivalent modifications made by the present invention and the contents of the accompanying drawings, which are directly or indirectly applied to the related technical fields, are included in the scope of the present invention.
Claims (10)
1. A method for verifying signed firmware, comprising:
signing the firmware to be upgraded;
acquiring public key information in equipment tree nodes;
reading a magic digital field in the firmware to be upgraded;
determining the corresponding firmware type in the firmware to be upgraded according to the magic digital field; and
and performing signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information.
2. The signed firmware verification method according to claim 1, wherein signing the firmware to be upgraded comprises:
generating a pair of public key and private key according to a preset digital signature algorithm;
sequentially acquiring each firmware in the firmware to be upgraded, and determining the type of each firmware according to the magic digital field at the head of the firmware to be upgraded, wherein the firmware to be upgraded comprises one or more of boot program firmware, trusted operating system firmware, boot firmware and firmware of upgrade mode firmware;
determining a signature method required by each firmware according to the type of each firmware and performing corresponding signature by using the private key;
storing public key information associated with the public key in a device tree node.
3. The signed firmware verification method according to claim 1, wherein determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field comprises: determining whether boot strap firmware in the firmware to be upgraded is of a first type or a second type according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps:
if the boot program firmware is of the first type, reading digital signature information according to the public key information, and verifying the digital signature information by using the public key information to determine whether the signature information is matched; and
if the boot loader firmware is of the second type, reading a digital signature length field, reading digital signature information according to the digital signature length field, calculating a message digest of information in a header of the boot loader firmware, and verifying the digital signature information by using the public key information according to the message digest to determine whether signature information is matched.
4. The signed firmware verification method according to claim 1, wherein determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field comprises: determining whether the trusted operating system firmware in the firmware to be upgraded is of a first type or a second type according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps:
if the trusted operating system firmware is of the first type, reading a digital signature length field, reading digital signature information according to the digital signature length field, calculating a message digest of information in a header of the trusted operating system firmware, and verifying the digital signature information by using the public key information according to the message digest to determine whether the signature information is matched; and
if the trusted operating system firmware is of the second type, calculating a message digest of data between an initial address and an offset address of the digital signature information in the trusted operating system firmware, reading the digital signature information according to the offset address of the digital signature information, and verifying the digital signature information by using the public key information according to the message digest to determine whether the signature information is matched.
5. The signed firmware verification method according to claim 1, wherein determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field comprises: determining whether the starting firmware in the firmware to be upgraded is an Android boot type according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps:
if the starting firmware is of an Android boot type, judging whether an image file exists in the firmware to be upgraded, if so, determining verification information related to the starting firmware from the image file, and verifying the starting firmware according to the verification information, otherwise, determining whether verification information exists from the tail part of the starting firmware, and verifying the starting firmware according to the verification information; and
and if the equipment is in a fusing state, reading the length information of the digital signature information, reading the digital signature information according to the length information of the digital signature, and verifying the digital signature information by using the public key information to determine whether the signature information is matched.
6. The signed firmware verification method according to claim 5, wherein determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field comprises: determining whether the starting firmware in the firmware to be upgraded is of an FIT type or not according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps: if the starting firmware is of an FIT type, determining whether an FDT node corresponding to the signature data exists in a head of the starting firmware, if so, verifying the starting firmware in the FIT format according to an FIT firmware verification method, and otherwise, determining that a verification result fails.
7. The method for verifying the signature firmware as claimed in claim 1, wherein determining the corresponding firmware type in the firmware to be upgraded according to the magic digital field comprises: determining whether the upgrade mode firmware in the firmware to be upgraded is an Android boot type according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps:
if the upgrade mode firmware is of an Android boot type, judging whether an image file exists in the firmware to be upgraded, if so, determining verification information related to the upgrade mode firmware from the image file, and verifying the upgrade mode firmware according to the verification information, otherwise, determining whether verification information exists from the tail part of the upgrade mode firmware, and verifying the upgrade mode firmware according to the verification information; and
and if the equipment is in a fusing state, reading the length information of the digital signature information, reading the digital signature information according to the length information of the digital signature, and verifying the digital signature information by using the public key information to determine whether the signature information is matched.
8. The signed firmware verification method according to claim 7, wherein determining the firmware type in the corresponding firmware to be upgraded according to the magic digital field comprises: determining whether the upgrade mode firmware in the firmware to be upgraded is of an FIT type according to the magic digital field,
the signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information comprises the following steps: if the upgrade mode firmware is of an FIT type, determining whether an FDT node corresponding to the signature data exists in the head of the upgrade mode firmware, if so, checking the upgrade mode firmware in the FIT format according to an FIT firmware checking method, and otherwise, determining that the checking result fails.
9. A signed firmware verification device comprising:
a memory configured to store a computer program; and
a processor configured to execute the computer program to perform the signature firmware verification method of any one of claims 1 to 8.
10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out a method for signature firmware verification according to any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210027834.6A CN114595460A (en) | 2022-01-11 | 2022-01-11 | Signature firmware verification method, device and computer readable medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210027834.6A CN114595460A (en) | 2022-01-11 | 2022-01-11 | Signature firmware verification method, device and computer readable medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114595460A true CN114595460A (en) | 2022-06-07 |
Family
ID=81803439
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210027834.6A Pending CN114595460A (en) | 2022-01-11 | 2022-01-11 | Signature firmware verification method, device and computer readable medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114595460A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115514498A (en) * | 2022-09-27 | 2022-12-23 | 四川长虹电器股份有限公司 | Method for rapidly detecting signature information in image file of android television system |
-
2022
- 2022-01-11 CN CN202210027834.6A patent/CN114595460A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115514498A (en) * | 2022-09-27 | 2022-12-23 | 四川长虹电器股份有限公司 | Method for rapidly detecting signature information in image file of android television system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7512749B2 (en) | Safe software revision for embedded systems | |
| CN111538517B (en) | Method and system for upgrading server firmware, electronic equipment and storage medium | |
| CN107783776B (en) | Processing method and device of firmware upgrade package and electronic equipment | |
| WO2008154862A1 (en) | Management method for intelligent terminal system and intelligent terminal | |
| TW201025008A (en) | System of updating firmware and method thereof, and method of creating firmware | |
| CN110704428A (en) | Data indexing method and device for block chain, computer equipment and storage medium | |
| CN107861832B (en) | Data verification method and device and readable storage medium | |
| CN114595460A (en) | Signature firmware verification method, device and computer readable medium | |
| CN111400267A (en) | Method and device for recording log | |
| CN115220796A (en) | Secure boot device | |
| CN101009888A (en) | Secure booting method for a mobile terminal, computer readable recording medium and mobile terminal | |
| CN113238790B (en) | Firmware program updating method and system based on SD card and EEPROM | |
| KR20080083512A (en) | Firmware over the air system | |
| CN114547620A (en) | Signature firmware upgrading method, device and computer readable medium | |
| CN115828255A (en) | Method for upgrading signed firmware, electronic device and storage medium | |
| CN111459496B (en) | Method for generating tamper-proof program file and method for upgrading equipment | |
| CN113360914A (en) | BIOS updating method, system, equipment and medium | |
| CN117608627A (en) | Method for upgrading firmware, electronic device and storage medium | |
| CN116909659A (en) | Execution method, device, equipment and storage medium of blockchain intelligent contract | |
| CN117009976A (en) | Firmware loading control method, device and chip | |
| CN115686946A (en) | Firmware updating method, firmware updating device and vehicle | |
| CN108132793A (en) | Transmission, upgrade method and the device of eMMC online upgrading files | |
| WO2021171906A1 (en) | Information processing device, and program starting method | |
| JP2019096200A (en) | Rewrite confirmation device, method for confirming rewrite, and rewrite confirmation program | |
| CN111611000A (en) | High-reliability firmware over-the-air upgrading method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |