Signature firmware verification method, device and computer readable medium

Abstract

The present invention discloses a signature firmware verification method, device and computer-readable medium, which signs the firmware to be upgraded, obtains the public key information in the device tree node and reads the magic number field in the firmware to be upgraded, determines the firmware type in the corresponding firmware to be upgraded according to the magic number field, and performs signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic number field in the head of the firmware to be upgraded, and the corresponding signature verification is performed on the firmware of the type according to the public key, which can perform targeted verification on different firmware types in the firmware to be upgraded, and improve the accuracy of signature verification.

Description

Technical Field

[0001] The present invention relates to the field of embedded technology, and in particular to a signature firmware verification method, device and computer-readable medium. Background Art

[0002] Currently, devices that support secure boot need to sign the firmware and verify the firmware during the boot process. However, existing FOTA (Firmware Over-The-Air) firmware upgrade solutions usually directly upgrade signed firmware. In the case that the device hardware (such as the SoC chip) has been blown, if the firmware is not signed or the signature is incorrectly caused by using the wrong key, the device will not be able to boot after the upgrade, so it is particularly important to verify the firmware signature. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide a signature firmware verification method, device and computer-readable medium, which can improve the accuracy of signature verification.

[0004] In one aspect of the present invention, a signature firmware verification method is provided. The method includes the steps of: signing the firmware to be upgraded; obtaining the public key information in the device tree node and reading the magic number field in the firmware to be upgraded; determining the firmware type in the firmware to be upgraded according to the magic number field, and performing signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information.

[0005] In another aspect of the present invention, a signed firmware verification device is provided, which includes a memory configured to store a computer program and a processor configured to execute the computer program to perform the signed firmware verification method.

[0006] In another aspect of the present invention, a computer-readable medium is provided, wherein a computer program is stored on the medium, and the computer program is executed by a processor to implement the above-mentioned signature firmware verification method.

[0007] The beneficial effects of the present invention are: signing the firmware to be upgraded, obtaining the public key information in the device tree node and reading the magic number field in the firmware to be upgraded, determining the firmware type in the corresponding firmware to be upgraded according to the magic number field, and performing signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic number field in the header of the firmware to be upgraded, and the corresponding signature verification is performed on the firmware of the type according to the public key, so that targeted verification can be performed on different firmware types in the firmware to be upgraded, thereby improving the accuracy of signature verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1is a flowchart of a signature firmware verification method according to an embodiment of the present invention;

[0009] Figure 2 A flowchart for verifying the bootloader firmware and the trusted operating system firmware;

[0010] Figure 3 A flowchart for verifying the startup firmware;

[0011] Figure 4 A flowchart for verifying the firmware in upgrade mode;

[0012] Figure 5 4 is a block diagram of a signed firmware verification device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0013] In order to explain the technical content, achieved objectives and effects of the present invention in detail, the following is an explanation in combination with the implementation modes and the accompanying drawings.

[0014] In the prior art, when the device hardware has been blown, if the firmware is not signed or a signature error is caused by using an incorrect key, the device will be unable to start after the upgrade, so it is necessary to improve the accuracy of the firmware signature verification.

[0015] In order to solve at least the above technical problems, the present disclosure provides a method for signing firmware verification. According to the present disclosure, the firmware to be upgraded is signed, the public key information in the device tree node is obtained, and the magic number field in the firmware to be upgraded is read; according to the magic number field, the firmware type in the corresponding firmware to be upgraded is determined, and the signature verification corresponding to the firmware type is performed on the firmware to be upgraded according to the public key information. In this way, according to the embodiments of the present disclosure, different firmware types in the firmware to be upgraded can be verified in a targeted manner, thereby improving the accuracy of signature verification.

[0016] Hereinafter, the technical solution according to the present disclosure will be described with reference to specific embodiments and in conjunction with the accompanying drawings.

[0017] Figure 1 1 is a flowchart showing a signature firmware verification method 100 according to an embodiment of the present disclosure. Figure 1 The method 100 includes the following steps 102 to 106.

[0018] In step 102, the firmware to be upgraded is signed. The firmware to be upgraded includes one or more of the boot program firmware, the trusted operating system firmware, the boot firmware, and the upgrade mode firmware. In some embodiments, a pair of public keys and private keys are generated according to a preset digital signature algorithm, each firmware in the firmware to be upgraded is obtained in turn, and the type of each firmware is determined according to the magic number field in the header of the firmware to be upgraded. The signature method required for each firmware is determined by the type of each firmware and signed with the private key, and finally the public key information is stored in the device tree node. In this way, each type of firmware to be upgraded can be signed in a targeted manner, ensuring the security of the firmware signature.

[0019] In step 104, public key information in the device tree node is obtained.

[0020] In step 106, the magic number field in the firmware to be upgraded is read.

[0021] In step 108, the firmware type in the corresponding firmware to be upgraded is determined according to the magic number field.

[0022] In step 110, a signature verification corresponding to the firmware type is performed on the firmware to be upgraded according to the public key information.

[0023] In some embodiments, if the magic number field corresponds to the first type or the second type of boot program firmware, the boot program firmware is first read into the memory when performing the signature verification. When the boot program firmware has a signature mark, the first type of firmware reads the digital signature information according to the public key information, and the second type of firmware reads the digital signature information according to the length field of the digital signature, and calculates the message digest of the information in the header of the boot program firmware, and verifies the digital signature information according to the message digest and the public key information. In this way, different types of boot program firmware can be adaptively verified.

[0024] In some embodiments, if the magic number field corresponds to the first type or the second type of the trusted operating system firmware, the trusted operating system firmware is first read into the memory when performing the signature verification. When the trusted operating system firmware has a signature mark, the first type of firmware reads the digital signature information according to the length field of the digital signature, and calculates the message digest of the information in the header of the trusted operating system firmware, and verifies the digital signature information based on the message digest and the public key information, and the second type of firmware calculates the message digest of the data between the starting address in the trusted operating system firmware and the 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 based on the message digest and the public key information. In this way, different types of boot firmware can be adaptively verified.

[0025] In some embodiments, if the magic number field corresponds to the Android boot type of the boot firmware, then when the firmware to be upgraded has an image file, the verification information related to the boot firmware is obtained from the image file for verification, or the verification information is obtained from the end of the boot firmware for verification. When the image file does not exist, the boot firmware in the firmware to be upgraded is directly obtained. The boot firmware is then read into the memory. If the boot firmware has a signature mark, the signed content in the boot firmware is re-signed with the public key, and verification is performed based on the signature result. In this way, different types of boot firmware can be adaptively verified.

[0026] In some embodiments, if the magic number field corresponds to the Android boot type of the upgrade mode firmware, then when there is an image file for the firmware to be upgraded, the verification information related to the upgrade mode firmware is obtained from the image file for verification, or the verification information is obtained from the end of the upgrade mode firmware for verification. When there is no image file, the upgrade mode firmware in the firmware to be upgraded is directly obtained. After that, the upgrade mode firmware is read into the memory. If the upgrade mode firmware has a signature mark, the signed content in the upgrade mode firmware is re-signed with the public key, and verification is performed based on the signature result. In this way, different types of upgrade mode firmware can be adaptively verified.

[0027] In some embodiments, if the firmware corresponding to the magic number field is in FIT format, then when there is an FDT node corresponding to the signature data in the firmware header, the firmware in FIT format is verified according to the FIT firmware verification method. In this way, the firmware in the preset format can be adaptively verified, thereby improving the accuracy and reliability of the firmware signature verification.

[0028] According to the embodiments of the present disclosure, through the signature firmware verification method, targeted verification can be performed on different firmware types in the firmware to be upgraded, thereby improving the accuracy of signature verification.

[0029] Hereinafter, application scenarios of the signature firmware verification method and device according to embodiments of the present invention will be described by way of examples.

[0030] When signing the firmware to be upgraded, the firmware to be upgraded includes one or more of boot program firmware, trusted operating system firmware, startup firmware, and upgrade mode firmware.

[0031] First, generate a pair of public and private keys according to the selected digital signature algorithm, and sign the firmware binary file to be verified.

[0032] If you need to sign the bootloader firmware, the bootloader firmware can be divided into three types according to the magic number in the firmware header: Type 1, Type 2, and Type 3. The first-level bootloader firmware must be Type 1.

[0033] For type one, the digital signature algorithm and public key parameter information are first written into a specific location of the firmware, and the signature mark (such as SignFlag) field in the firmware header is set to the signature mark. Then the entire firmware is signed with a private key, and the signature information is written to the end of the firmware.

[0034] For type 2, the last three parts of the firmware header are the message digest algorithm type field, the message digest field (such as hash), and a reserved area. The message digest field stores the message digest of all firmware header information before this field calculated according to the algorithm specified by the message digest algorithm type. The reserved area at the end of the header includes three aspects: firmware signature mark, digital signature information length, and digital signature information.

[0035] During the type 2 firmware signing process, the signature tag (such as SignFlag) field of the firmware header is first set to the signature tag, and the value of the digital signature information length field of the firmware header is set according to the digital signature algorithm type. Finally, the message digest field (such as hash) of the firmware header is signed using the private key, and the signature information is written into the digital signature information area of ​​the firmware header.

[0036] For type three, the firmware is in FIT format, and the FIT format firmware is signed according to the uboot FIT signature method.

[0037] If the trusted operating system firmware needs to be signed, the trusted operating system firmware can be divided into two types according to the magic number in the firmware header: type one and type two.

[0038] For type 1, the last three parts of the firmware header are the message digest algorithm type field, the message digest field (such as hash), and a reserved area. The message digest field stores the message digest of all firmware header information before this field calculated according to the algorithm specified by the message digest algorithm type. The reserved area at the end of the header includes three aspects: firmware signature mark, digital signature information length, and digital signature information.

[0039] During the type 1 firmware signing process, the signature tag (such as SignFlag) field of the firmware header is first set to the signature tag, and the value of the digital signature information length field of the firmware header is set according to the digital signature algorithm type. Finally, the message digest field (such as hash) of the firmware header is signed using the private key, and the signature information is written into the digital signature information area of ​​the firmware header.

[0040] For type 2, this type of firmware contains multiple sub-firmware (such as ATF firmware and TEE OS firmware), and its firmware layout is: basic header information + sub-firmware meta information + digital signature information + each sub-firmware binary data.

[0041] The "basic header information" includes the firmware signature tag, message digest algorithm type field, digital signature algorithm type field and digital signature information offset address field. The "sub-firmware meta information" includes the message digest and loading address of each sub-firmware.

[0042] During the type 2 firmware signing process, the signature tag (such as SignFlag) field of the firmware header is first set to the signature tag, and the message digest algorithm type field, digital signature algorithm type field, and digital signature information offset address field are set respectively. Then, the message digest of all information before the digital signature information offset address field (i.e., the "basic header information + sub-firmware meta information" in the firmware) is calculated according to the algorithm specified in the message digest algorithm type field, and finally the calculated message digest is signed with the private key, and the signature information is written to the location specified in the digital signature information offset address field.

[0043] If the boot firmware (such as boot.img) needs to be signed, the boot firmware can be divided into two types according to the magic number in the firmware header: Android format and FIT format.

[0044] There are two signing methods for Android-formatted firmware: Method 1 and Method 2.

[0045] Method 1: Use standard Android Verity to sign the firmware.

[0046] Method 2: First, write the signature mark in a fixed position of the reserved field of the boot firmware header (such as BOOT HEADER), then take the field content (such as the id field) that changes every time the boot firmware header (such as BOOT HEADER) is compiled as the signed content, and finally use the private key to sign the signed content, and write the signature information to a fixed position of the reserved field of the boot firmware header (such as BOOT HEADER).

[0047] For the boot firmware in FIT format, sign the firmware in FIT format according to the uboot FIT signature method.

[0048] 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 magic number in the firmware header: Android format and FIT format.

[0049] There are two signing methods for Android-formatted firmware: Method 1 and Method 2.

[0050] Method 1: Use standard Android Verity to sign the firmware.

[0051] Method 2: First, write the signature mark in a fixed position of the reserved field of the boot firmware header (such as BOOT HEADER), then take the field content (such as the id field) that changes every time the boot firmware header (such as BOOT HEADER) is compiled as the signed content, and finally use the private key to sign the signed content, and write the signature information to a fixed position of the reserved field of the boot firmware header (such as BOOT HEADER).

[0052] For the upgrade mode firmware in FIT format, the firmware in FIT format is signed according to the uboot FIT signature method.

[0053] Figure 2 2 is a flow chart showing the verification of the boot program firmware and the trusted operating system firmware, specifically executing steps 202 to 212.

[0054] In step 202, it is checked whether the firmware to be verified exists. If not, the verification result flag is set to success and the verification result flag is returned. If it exists, step 204 is executed.

[0055] In step 204, the public key information of the device tree (dtb) node (such as / sys / firmware / devicetree / base / public-key / data) is obtained, including the public key algorithm and public key parameters used. If the public key information acquisition fails, the verification result mark is set to success and the verification result mark is returned. If the public key information is successfully obtained, step 206 is executed.

[0056] In step 206, read the magic number field in the firmware header. If it corresponds to the boot program firmware type one, execute the boot program firmware verification of step 2082. If it corresponds to the boot program firmware type two, execute the boot program firmware verification of step 2084. If the magic number corresponds to the trusted operating system firmware type one, execute the trusted operating system firmware verification of step 2102. If the magic number corresponds to the trusted operating system firmware type two, execute the trusted operating system firmware verification of step 2104. If it is other values, execute step 212.

[0057] In step 2082, if the magic number field in the firmware header corresponds to boot program type 1, the boot program firmware to be verified is completely read into the Memory, and the signature mark (such as SignFlag) field in the firmware header is checked. If the firmware is not signed, the verification result mark is set to fail and the verification result mark is returned. If the firmware is signed, the fixed-length digital signature information at the end of the boot program firmware is read according to the public key algorithm type obtained in step 204, and then the content of the boot program firmware other than the digital signature information at the end is obtained, and the digital signature information is verified using the public key algorithm and public key parameters obtained in step 204 to see if the signature information matches. If the signature information matches, the verification result mark is set to success and returned, otherwise the verification result mark is set to failure and returned.

[0058] In step 2084, if the magic number field in the firmware header corresponds to the boot program type 2, the header of the boot program firmware to be verified is read into the Memory, and the signature mark (such as SignFlag) field in the firmware header is checked. If the firmware is not signed, the verification result mark is set to failure and the verification result mark is returned. If the firmware is signed, the digital signature length field in the firmware header is read, and then according to the value of the digital signature length field, the digital signature information of the specified length after the digital signature length field is read. According to the message digest algorithm type field in the firmware header, the message digest of all firmware header information before the message digest field in the firmware header is calculated. Finally, according to the calculated message digest, the digital signature information is verified using the public key algorithm and public key parameters obtained in step 204 to see whether the signature information matches. If the signature information matches, the verification result mark is set to success and returned, otherwise the verification result mark is set to failure and returned.

[0059] In step 2102, if the magic number field in the firmware header corresponds to the trusted operating system firmware type 1, the header of the trusted operating system firmware to be verified is read into the Memory, and the signature mark (such as SignFlag) field in the firmware header is checked. If the firmware is not signed, the verification result mark is set to failure and the verification result mark is returned. If the firmware is signed, the digital signature length field in the firmware header is read, and then according to the value of the digital signature length field, the digital signature information of the specified length after the digital signature length field is read. According to the message digest algorithm type field in the firmware header, the message digest of all firmware header information before the message digest field in the firmware header is calculated. Finally, according to the calculated message digest, the digital signature information is verified using the public key algorithm and public key parameters obtained in step 204 to see whether the signature information matches. If the signature information matches, the verification result mark is set to success and returned, otherwise the verification result mark is set to failure and returned.

[0060] In step 2104, if the magic number field in the firmware header corresponds to the trusted operating system firmware type 2, the header of the trusted operating system firmware to be verified is read into the Memory, and the signature mark (such as SignFlag) field in the firmware header is checked. If the firmware is not signed, the verification result mark is set to fail and the verification result mark is returned. If the firmware is signed, the message digest algorithm type field, the digital signature algorithm type field and the digital signature information offset address field in the firmware header are read. According to the value of the digital signature information offset address field, all data between the initial 0x0 position of the trusted operating system firmware and the digital signature information offset address are read into the buffer, and the corresponding message digest is calculated for the above-read data (i.e., the data in the buffer) according to the algorithm type (such as SHA-256) specified in the message digest algorithm type field. According to the algorithm type (such as RSA-2048) specified in the digital signature algorithm type field, the length of the digital signature information is determined, and the trusted operating system firmware to be verified is located at the position specified by the digital signature information offset address field, and the digital signature information of the determined length is read. Finally, based on the message digest calculated above, and using the public key algorithm and public key parameters obtained in step 204, the digital signature information is verified to see whether the signature information matches. If the signature information matches, the verification result mark is set as success and returned; otherwise, the verification result mark is set as failure and returned.

[0061] In step 212, if the magic number field in the firmware header corresponds to a firmware in FIT (Flattened Image Tree) format, then check whether there is an FDT node (such as signature) corresponding to the signature data in the firmware header. If not, it means that the firmware is not signed, set the verification result mark to failure, and return the verification result mark. If there is an FDT node corresponding to the signature data, the firmware has a signature. At this time, the FIT format firmware is verified according to the FIT firmware verification method. If the verification is successful, set the verification result mark to success and return, otherwise set the verification result mark to failure and return.

[0062] If the magic number field in the firmware header corresponds to a firmware of another format, the verification result flag is set to success and the verification result flag is returned.

[0063] Figure 3 3 is a flow chart showing the verification of the startup firmware, specifically executing steps 302 to 310.

[0064] In step 302, it is checked whether the firmware to be verified exists. If not, the verification result flag is set to success and the verification result flag is returned. If it exists, step 304 is executed.

[0065] In step 304, the public key information of the device tree (dtb) node (such as / sys / firmware / devicetree / base / public-key / data) is obtained, including the public key algorithm and public key parameters used. If the public key information acquisition fails, the verification result mark is set to success and the verification result mark is returned. If the public key information is successfully obtained, step 306 is executed.

[0066] In step 306, the magic number field in the firmware header is read. If it corresponds to the Android Boot firmware type, the startup firmware verification of step 308 is executed; if the magic number corresponds to a firmware in the FIT (Flattened Image Tree) format, the startup firmware verification of step 310 is executed as follows; if it is other values, the verification result mark is set to success and the verification result mark is returned.

[0067] In step 308, if the magic number corresponds to the verification of the Android Boot type startup firmware, specifically execute steps 3082 to 3086.

[0068] In step 3082, if there is a vbmeta image (such as vbmeta.img) in the firmware to be upgraded, the vbmeta image (such as vbmeta.img) is first extracted from the firmware to be upgraded and stored in the Memory or a readable and writable file system partition in the form of a temporary file. Then check whether the vbmeta image includes verification information related to the boot firmware (such as boot.img). If it exists, but the device is in an unlocked state, set the verification result mark as success and return, otherwise verify the boot firmware (such as boot.img) according to the verification information in the vbmeta image. If the verification is successful, set the verification result mark as success and return, otherwise set the verification result mark as failure and return.

[0069] If the vbmeta image does not contain the verification information related to the boot firmware (such as boot.img) and the device is not blown, set the verification result mark to success and return; if the device is in a blown state, execute step 3084.

[0070] In step 3084, if the vbmeta image (such as vbmeta.img) does not exist in the firmware to be upgraded, check whether there is verification information at the end of the boot firmware (such as boot.img). If it exists, but the device is in an unlocked state, set the verification result mark as success and return. Otherwise, verify the boot firmware (such as boot.img) according to the verification information in the end of the boot firmware (such as boot.img). If the verification is successful, set the verification result mark as success and return. Otherwise, set the verification result mark as failure and return.

[0071] If the end of the boot firmware (such as boot.img) does not contain verification information and the device is not blown, set the verification result mark to success and return; if the device is in a blown state, execute step 3086.

[0072] In step 3086, the Android Boot header information of the boot firmware to be verified is read into Memory, and the signature mark (such as SignFlag) information in the reserved field of the firmware header is checked. If the firmware is not signed, the verification result mark is set to failure and the verification result mark is returned. If the firmware is signed, continue to read the digital signature information length information after the signature mark information in the reserved field of the firmware header, and then continue to read the digital signature information of the specified length after the digital signature length information in the reserved field of the firmware header according to the value of the digital signature length field. Finally, the signed content (such as the id field) of the firmware header is obtained, and the digital signature information is verified using the public key algorithm and public key parameters obtained in step 304 to see if the signature information matches. If the signature information matches, the verification result mark is set to success and returned, otherwise the verification result mark is set to failure and returned.

[0073] In step 310, if the magic number corresponds to the verification of the FIT type boot firmware, then check whether there is an FDT node (such as signature) corresponding to the signature data in the firmware header. If not, it means that the firmware is not signed, set the verification result mark to failure, and return the verification result mark. If there is an FDT node corresponding to the signature data, the firmware has a signature, and the FIT format boot firmware is verified according to the FIT firmware verification method.

[0074] Figure 4 4 is a flow chart showing how to verify the firmware in upgrade mode. Specifically, step 402 to step 410 are performed.

[0075] In step 402, it is checked whether the firmware to be verified exists. If not, the verification result flag is set to success and the verification result flag is returned. If it exists, step 404 is executed.

[0076] In step 404, the public key information of the device tree (dtb) node (such as / sys / firmware / devicetree / base / public-key / data) is obtained, including the public key algorithm and public key parameters used. If the public key information acquisition fails, the verification result mark is set to success and the verification result mark is returned. If the public key information is successfully obtained, step 406 is executed.

[0077] In step 406, the magic number field in the firmware header is read. If it corresponds to the Android Boot firmware type, the upgrade mode firmware check of step 408 is executed; if the magic number corresponds to the firmware in the FIT (Flattened Image Tree) format, the upgrade mode firmware check of step 410 is executed; if it is other values, the check result mark is set to success and the check result mark is returned.

[0078] In step 408, if the magic number corresponds to the verification of the Android Boot type upgrade mode firmware, specifically execute steps 4082 to 4086.

[0079] In step 4082, if there is a vbmeta image (such as vbmeta.img) in the firmware to be upgraded. First, extract the vbmeta image (such as vbmeta.img) from the firmware to be upgraded and store it in the form of a temporary file in the Memory or in a readable and writable file system partition. Then check whether the vbmeta image includes verification information related to the upgrade mode firmware (such as recovery.img). If it exists, but the device is in an unlocked state, set the verification result mark as success and return. Otherwise, verify the upgrade mode firmware (such as recovery.img) according to the verification information in the vbmeta image. If the verification is successful, set the verification result mark as success and return. Otherwise, set the verification result mark as failure and return.

[0080] If the vbmeta image does not contain the verification information related to the upgrade mode firmware (recovery.img), check whether there is verification information at the end of the upgrade mode firmware (such as recovery.img). If it exists, but the device is in an unlocked state, set the verification result mark as success and return. Otherwise, verify the upgrade mode firmware (such as recovery.img) according to the verification information in the end of the upgrade mode firmware (such as recovery.img). If the verification is successful, set the verification result mark as success and return. Otherwise, set the verification result mark as failure and return.

[0081] If the upgrade mode firmware (such as recovery.img) does not contain verification information at the end and the device is not blown, set the verification result mark to success and return; if the device is in a blown state, execute step 4806.

[0082] In step 4084, if the firmware to be upgraded does not have a vbmeta image (such as vbmeta.img),

[0083] Check whether there is verification information at the end of the upgrade mode firmware (such as recovery.img). If it exists, but the device is in an unlocked state, set the verification result mark as success and return. Otherwise, verify the upgrade mode firmware (such as recovery.img) according to the verification information in the end of the upgrade mode firmware (such as recovery.img). If the verification is successful, set the verification result mark as success and return. Otherwise, set the verification result mark as failure and return.

[0084] If the upgrade mode firmware (such as recovery.img) does not contain verification information at the end and the device is not blown, set the verification result mark to success and return; if the device is in a blown state, execute step 4806.

[0085] In step 4086, the Android Boot header information of the boot firmware to be verified is read into Memory, and the signature mark (such as SignFlag) information in the reserved field of the firmware header is checked. If the firmware is not signed, the verification result mark is set to fail and the verification result mark is returned. If the firmware is signed, continue to read the digital signature information length information after the signature mark information in the reserved field of the firmware header, and then continue to read the digital signature information of the specified length after the digital signature length information in the reserved field of the firmware header according to the value of the digital signature length field. Finally, the signed content (such as the id field) of the firmware header is obtained, and the digital signature information is verified using the public key algorithm and public key parameters obtained in step 404 to see if the signature information matches. If the signature information matches, the verification result mark is set to success and returned, otherwise the verification result mark is set to failure and returned.

[0086] In step 410, if the magic number corresponds to the verification of the FIT type upgrade mode firmware, then check whether there is an FDT node (such as signature) corresponding to the signature data in the firmware header. If not, it means that the firmware is not signed, set the verification result mark to failure, and return the verification result mark. If there is an FDT node corresponding to the signature data, the firmware has a signature. At this time, the recovery mode or upgrade mode firmware in the FIT format is verified according to the FIT firmware verification method. If the verification is successful, set the verification result mark to success and return, otherwise set the verification result mark to failure and return.

[0087] According to another aspect of the present invention, Figure 5 Schematic diagram of a signature firmware verification device 500 according to an embodiment of the present invention. Figure 5 The electronic device 500 includes a memory 502, a processor 504, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the signature firmware verification method described above is implemented.

[0088] According to another aspect of the present invention, a computer-readable medium is provided, wherein a computer program is stored on the computer-readable medium, and the computer program is executed by a processor to implement the signature firmware verification method described above.

[0089] In summary, in the signature firmware verification method, device and computer-readable medium provided by the present invention, the firmware to be upgraded is signed, wherein the firmware to be upgraded includes one or more of the boot program firmware, the trusted operating system firmware, the boot firmware and the upgrade mode firmware. In addition, the public key information in the device tree node is obtained and the magic number field in the header of the firmware to be upgraded is read, the firmware type in the corresponding firmware to be upgraded is determined according to the magic number field, and the signature verification corresponding to the firmware type is performed on the firmware to be upgraded according to the public key information. Therefore, the firmware type is determined according to the magic number field in the header of the firmware to be upgraded, and the corresponding signature verification is performed on the firmware of this type according to the public key, so that targeted verification can be performed on different firmware types in the firmware to be upgraded, thereby improving the accuracy of the signature verification.

[0090] The above descriptions are merely embodiments of the present invention and are not intended to limit the patent scope of the present invention. Any equivalent transformations made using the contents of the present invention's specification and drawings, or directly or indirectly applied in related technical fields, are also included in the patent protection scope of the present invention.

Claims

1. A signature firmware verification method, characterized in that: include: Sign the firmware to be upgraded; Get the public key information in the device tree node; Read the magic number field in the firmware to be upgraded; Determining the firmware type in the corresponding firmware to be upgraded according to the magic number field, which includes determining whether the startup firmware in the firmware to be upgraded is of Android boot type according to the magic number field; as well as Performing a signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information includes: If the boot firmware is of Android boot type, determine whether there is an image file for the firmware to be upgraded; if so, determine verification information related to the boot firmware from the image file, and verify the boot firmware according to the verification information; otherwise, determine whether there is verification information from the tail of the boot firmware, and verify the boot firmware according to the verification information; as well as If the device is in a blown state, the digital signature information length information is read, the digital signature information is read according to the digital signature length information, and the digital signature information is verified using the public key information to determine whether the signature information matches.

2. The signature firmware verification method according to claim 1, characterized in that: Signing the firmware to be upgraded includes: Generate a pair of public and private keys according to a preset digital signature algorithm; Obtain each firmware in the firmware to be upgraded in sequence, and determine the type of each firmware according to the magic number field in the header of the firmware to be upgraded, wherein the firmware to be upgraded includes one or more of boot program firmware, trusted operating system firmware, startup firmware, and upgrade mode firmware; Determine the signature method required for each firmware according to the type of each firmware and use the private key to perform corresponding signature; Public key information associated with the public key is stored in the device tree node.

3. The signature firmware verification method according to claim 1, characterized in that: Determining the firmware type in the firmware to be upgraded according to the magic number field includes: determining whether the bootloader firmware in the firmware to be upgraded is the first type or the second type according to the magic number field, Performing a signature verification on the firmware to be upgraded corresponding to the firmware type according to the public key information includes: If the boot program firmware is of the first type, reading the digital signature information according to the public key information, and verifying the digital signature information using the public key information to determine whether the signature information matches; and If the boot program firmware is of the second type, the digital signature length field is read, and the digital signature information is read according to the digital signature length field, a message digest is calculated for the information in the header of the boot program firmware, and the digital signature information is verified according to the message digest and the public key information to determine whether the signature information matches.

4. The signature firmware verification method according to claim 1, characterized in that: Determining the firmware type in the firmware to be upgraded according to the magic number field includes: determining whether the trusted operating system firmware in the firmware to be upgraded is the first type or the second type according to the magic number field, Performing a signature verification on the firmware to be upgraded corresponding to the firmware type according to the public key information includes: If the trusted operating system firmware is of the first type, reading the digital signature length field, reading the digital signature information according to the digital signature length field, calculating a message digest for the information in the header of the trusted operating system firmware, and verifying the digital signature information according to the message digest and using the public key information to determine whether the signature information matches; and If the trusted operating system firmware is of the second type, a message digest is calculated for the data between the starting address and the offset address of the digital signature information in the trusted operating system firmware, the digital signature information is read according to the offset address of the digital signature information, and the digital signature information is verified according to the message digest and the public key information to determine whether the signature information matches.

5. The signature firmware verification method according to claim 1, characterized in that: Determining the firmware type in the firmware to be upgraded according to the magic number field includes: determining whether the startup firmware in the firmware to be upgraded is a FIT type according to the magic number field, Performing a signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information includes: if the boot firmware is of FIT type, determining whether there is an FDT node corresponding to the signature data in the header of the boot firmware; if so, verifying the boot firmware in FIT format according to the FIT firmware verification method; otherwise, determining that the verification result fails.

6. The signature firmware verification method according to claim 1, characterized in that: Determining the firmware type in the corresponding firmware to be upgraded according to the magic number field includes: determining whether the upgrade mode firmware in the firmware to be upgraded is of Android boot type according to the magic number field, Performing a signature verification on the firmware to be upgraded corresponding to the firmware type according to the public key information includes: If the upgrade mode firmware is of Android boot type, determine whether there is an image file for the firmware to be upgraded, and if so, determine verification information related to the upgrade mode firmware from the image file, and verify the upgrade mode firmware according to the verification information; otherwise, determine whether there is verification information from the tail of the upgrade mode firmware, and verify the upgrade mode firmware according to the verification information; and If the device is in a blown state, the digital signature information length information is read, the digital signature information is read according to the digital signature length information, and the digital signature information is verified using the public key information to determine whether the signature information matches.

7. The signature firmware verification method according to claim 6, characterized in that: Determining the firmware type in the corresponding firmware to be upgraded according to the magic number field includes: determining whether the upgrade mode firmware in the firmware to be upgraded is a FIT type according to the magic number field, Performing a signature verification corresponding to the firmware type on the firmware to be upgraded according to the public key information includes: if the upgrade mode firmware is of FIT type, determining whether there is an FDT node corresponding to the signature data in the header of the upgrade mode firmware; if so, verifying the upgrade mode firmware in FIT format according to the FIT firmware verification method; otherwise, determining that the verification result fails.

8. A signed firmware verification device, comprising: a memory configured to store a computer program; as well as A processor is configured to execute the computer program to perform the signature firmware verification method according to any one of claims 1 to 7.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the signature firmware verification method according to any one of claims 1 to 7 is implemented.

Images