Firmware package generation method, secure starting method, verification method, device and medium

Abstract

The invention relates to the technical field of system security, and discloses a firmware package generation method, a secure starting method, a verification method, a device and a medium, the starting method is suitable for a vehicle-mounted SoC system without OTP / eFuse and with a BootROM unmodifiable, and complementary building of a trusted root is achieved in a software mode. In response to the starting instruction, the BootROM loads a security bootstrap program; during first deployment, a secure storage area is created in a nonvolatile memory, and an initial root public key and an abstract thereof are written in to complete initialization of a trust chain. In the subsequent starting process, after the security bootstrap program verifies the integrity of the root public key, the mirror image public key, the abstract and the signature of the mirror image to be started are verified, and it is ensured that the source is legal and the data is complete. On-line updating of a root public key through a chain signature mechanism is supported, that is, a current effective root private key is used for carrying out abstract signature on a new public key, and the new public key can be replaced after the signature verification of an old public key is passed, so that key rotation and trust anchor migration without hardware modification are realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of system security, and in particular to a firmware package generation method, a secure startup method and a verification method thereof, a device and a medium. BACKGROUND

[0002] With the development of centralized and intelligent automotive electronic and electrical architecture, the secure startup capability of vehicle-mounted chips has become a basic link to ensure the information security of the whole vehicle. The secure startup establishes a trust chain of step-by-step verification from BootROM to the operating system, ensures that only firmware with authorized signature can be executed, and thus prevents malicious image flashing and remote vehicle control attacks. The current mainstream solution relies on an in-chip one-time programmable storage unit (OTP) or an electronic fuse (eFuse) to store a root public key or a hash value thereof, and uses the hardware irreversible write feature to achieve tamper resistance and form a trusted root. However, a large number of vehicle-mounted SoCs that have been mass-produced or are in service do not integrate OTP or eFuse structures due to cost control or design history reasons, and their BootROMs have been fixed and cannot be modified by flow to introduce a hardware-level security mechanism. For such devices, if signature verification is only performed in the application layer or in the unprivileged mode, it is easy to be bypassed by attackers by tampering with early boot code, resulting in the failure of the security mechanism. Although some solutions attempt to store the root public key in an external Flash, they lack effective access control and legality verification mechanisms, and still have the risk of being replaced illegally.

[0003] It is worth noting that the existing solutions that store the root public key in an external Flash (such as some MCU or SoC designs) usually only support one-time writing and lack effective access control and legality verification mechanisms. Once the key is leaked, it cannot be updated and the entire machine must be recalled or the chip must be physically replaced. In addition, these solutions often require key programming to be completed during the production stage and cannot achieve the post-deployment of security capabilities through remote upgrades. SUMMARY

[0004] Therefore, the embodiments of the present application provide a firmware package generation method, a secure startup method and a verification method thereof, a device and a medium.

[0005] In a first aspect, the embodiments of the present application provide a secure startup firmware package generation method, which includes: obtaining a target system firmware to be upgraded, and performing digest calculation on the target system firmware to obtain a firmware digest value; using a currently valid root private key to digitally sign the firmware digest value to generate firmware signature data; if the root public key needs to be updated this time, using the currently valid root private key to digitally sign the digest of the new root public key to generate root public key update signature data; and encapsulating the target system firmware, the firmware signature data and the root public key related information to obtain a secure startup firmware package.

[0006] In an optional implementation, when the current upgrade does not update the root public key, the root public key related information includes: the currently valid root public key and the digest corresponding to the currently valid root public key; and the root public key update signature field is empty or filled with a preset invalid value to indicate that the root public key update operation is not needed to be performed.

[0007] In an optional implementation, when the current upgrade updates the root public key, the root public key related information includes: the new root public key, the digest of the new root public key, and the root public key update signature data; and the root public key update signature is obtained by performing asymmetric encryption signature on the digest of the new root public key using the currently valid root private key, and is used to implement key rotation based on chain trust at the device end.

[0008] In a second aspect, the embodiments of the present application provide a secure boot method, applied to a secure chip system without one-time programmable storage unit (OTP) or eFuse, and including: in response to a boot instruction, loading and executing a secure boot program through a BootROM; wherein when the secure boot program is deployed for the first time, a secure storage area can be created in an original system without secure boot, and an initial root public key and a corresponding digest are written to complete the reconstruction of a trusted root; if the secure boot program detects that the secure storage area in a non-volatile memory exists, a current root public key and a pre-stored digest are read from the secure storage area; a root public key digest of the current root public key is calculated, and when the root public key digest is consistent with the pre-stored digest, image information in a to-be-booted image is obtained; the image information includes an image public key, an image signature and an image digest; when the image public key is consistent with the current root public key, a digest of a firmware body of the to-be-booted image is calculated to obtain an actual digest; when the actual digest is consistent with the image digest, the image signature is digitally verified by using the current root public key, and after the verification passes, a system corresponding to the to-be-booted image is booted; and the boot image is obtained from the secure boot firmware package in any one of the foregoing embodiments.

[0009] In an optional implementation, if it is detected that the secure storage area does not exist, the method further includes: creating the secure storage area in the non-volatile memory through the secure boot program, and writing a default security field to the secure storage area; the default security field includes an initial root public key and a corresponding digest; and after the secure storage area is created, the secure storage area is marked as an initialized state.

[0010] In an optional embodiment, when the secure boot program is first deployed, a burning process thereof includes: receiving a first upgrade package, the first upgrade package containing secure boot program binary data with a security verification function; writing, by an original Bootloader, the secure boot program binary data to a preset jump address region of a nonvolatile memory; triggering a system restart after the burning is completed, so that a BootROM loads and executes the secure boot program.

[0011] In a third aspect, the embodiments of the present application provide a firmware upgrade verification method, applied to the secure chip system, and including: after receiving a secure start firmware package, determining, by a secure boot program, whether the secure start firmware package contains a root public key update signature; if the secure start firmware package contains the root public key update signature and is not marked as invalid, then using a current root public key stored in a secure storage area to verify the root public key update signature; if the verification is passed, then calculating a digest value of a new root public key in the secure start firmware package and comparing the digest value with a new root public key digest carried in the secure start firmware package; if the comparison is consistent, then erasing content of an original secure storage area and writing the new root public key and a corresponding digest into the secure storage area, thereby completing root public key update.

[0012] In an optional embodiment, after the root public key update is completed, the method further includes: calculating a digest of data in the secure start firmware package to obtain an actual digest value; when the actual digest value is consistent with an image digest carried in the secure start firmware package, using a latest root public key to digitally verify firmware signature data in the secure start firmware package; the firmware signature data is generated based on the image digest; after the verification is passed, erasing original firmware partitions and writing new firmware data.

[0013] In a fourth aspect, the embodiments of the present application provide a vehicle-mounted electronic device, including: a SoC chip, the SoC internally having no OTP or eFuse unit; a nonvolatile memory, provided with a secure storage area and storing a secure boot program and a main operating system; the secure boot program is configured to execute a secure start method according to any one of the preceding embodiments at each start, so as to establish a trusted execution environment.

[0014] In a fifth aspect, the present application provides a computer readable storage medium, which stores a computer program, the computer program being executed on a processor to implement the method described above.

[0015] The embodiments of the present application have the following beneficial effects: the secure starting method of the present application, without relying on the hardware trust anchor such as OTP or eFuse, constructs a complete trusted starting chain by software. The method realizes tamper-proof storage of the root public key by using the secure storage area in the non-volatile memory, and performs a double-checking mechanism in the starting process, that is, verifying the integrity of the root public key itself first, and then verifying the source legality and data integrity of the starting image. The whole process does not change the existing hardware design, the cost of a single chip is zero, and it is compatible with various vehicle-mounted SoC platforms. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0017] Figure 1 A first flowchart of the firmware package generation method of the embodiments of the present application is shown; Figure 2 A second flowchart of the firmware package generation method of the embodiments of the present application is shown; Figure 3 A first flowchart of the secure starting method of the embodiments of the present application is shown; Figure 4 A second flowchart of the secure starting method of the embodiments of the present application is shown; Figure 5 A first flowchart of the firmware upgrade verification method of the embodiments of the present application is shown; Figure 6 A second flowchart of the firmware upgrade verification method of the embodiments of the present application is shown. DETAILED DESCRIPTION

[0018] The technical solutions of the embodiments of the present application will be described clearly and completely in the embodiments of the present application combined with the drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, not all the embodiments.

[0019] The components of the embodiments of the present application generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of the present application.

[0020] Hereinafter, the terms "include", "have", and their conjugates, used in the various embodiments of the present application, merely indicate that the specified features, numbers, steps, operations, elements, components, or combinations thereof are present and do not preclude the presence or addition of one or more other features, numbers, steps, operations, elements, components, or combinations thereof.

[0021] Unless defined otherwise, all terms used herein (including technical terms and scientific terms) have the same meanings as those generally understood by those with ordinary knowledge in the field of the various embodiments of the present application. Such terms as those defined in a generally used dictionary are to be interpreted to have the same meanings as those in the context of the relevant field of art and are not to be interpreted to have ideal or excessively formal meanings unless clearly defined in the various embodiments of the present application.

[0022] Some embodiments of the present application will be described below in detail with reference to the accompanying drawings. Embodiments described below and features in the embodiments can be combined with each other in the case of no conflict.

[0023] The secure boot firmware package generation method will be described below in connection with some specific embodiments. The method is executed by a firmware publisher of a vehicle system (such as an OEM or an OTA service platform) on a server, and is used to generate a firmware package that can be securely verified in a vehicle SoC system without a one-time programmable storage unit (OTP) or an electronic fuse (eFuse).

[0024] Figure 1 A flowchart of the secure boot firmware package generation method of the embodiments of the present application is shown when the root public key does not need to be updated. Exemplarily, the firmware package generation method includes steps S111-S113: In step S111, the target system firmware to be upgraded is obtained, and the target system firmware is subjected to digest calculation to obtain a firmware digest value.

[0025] Exemplarily, the complete target system firmware to be published, such as a binary image file (such as firmware.bin) containing an operating system, middleware, and application software, is first obtained. Then, a predetermined hash algorithm (such as SHA-256) is used to calculate the digest of the overall data of the target system firmware to obtain a firmware digest value that uniquely represents the integrity thereof. The firmware digest value will be used as the input data for subsequent digital signature, for verifying whether the firmware has been tampered with on the device side.

[0026] Step S112, digitally sign the firmware digest value using the currently valid root private key to generate firmware signature data.

[0027] In this step, the root private key currently in the valid life cycle (i.e., the currently valid root private key) is used to perform an asymmetric encryption signature operation on the firmware digest value obtained in step S111. In some embodiments, an RSA-2048 or ECDSA algorithm can be used to generate firmware signature data with strong anti-counterfeiting capability. The obtained firmware signature data is used by the secure boot program at the device end to verify the corresponding root public key to confirm the legitimacy of the firmware source.

[0028] Step S113, encapsulate the target system firmware, firmware signature data, and root public key related information to obtain a secure boot firmware package.

[0029] The root public key related information includes the currently valid root public key and its corresponding digest; in this embodiment, since there is no root public key update, the root public key update signature field is empty or filled with a preset invalid value (such as all 0xFF) to indicate that the device end does not need to perform a key update operation. The secure boot firmware package can be transmitted to the terminal device through USB, CAN FD, Ethernet, or OTA, etc. for the secure boot program to perform integrity and legality verification during the upgrade process.

[0030] When encapsulating, the above-mentioned target system firmware, firmware signature data, currently valid root public key, and its digest, etc. fields are packaged according to a predefined data structure to generate a complete format secure boot firmware package.

[0031] Figure 2 A flowchart of a secure boot firmware package generation method of the embodiment of the application when the root public key needs to be updated is shown. This method is usually used in the scenario where the vehicle-mounted system faces root private key leakage or actively rotates the key for security policy, to safely update the trust anchor through software without modifying the hardware design or recalling the device. Demonstratively, the firmware package generation method includes steps S211-S214: Step S211, obtain the target system firmware to be upgraded, and calculate the digest of the target system firmware to obtain a firmware digest value.

[0032] Step S212, digitally sign the firmware digest value using the currently valid root private key to generate firmware signature data.

[0033] Steps S211 and S212 are the same as steps S111 and S112 described above, and will not be described again here.

[0034] Step S213, digitally sign the digest of the new root public key using the currently valid root private key to generate root public key update signature data.

[0035] Exemplarily, when the trust anchor needs to be changed, a new root key pair is generated, and a new root public key is extracted. The same hash algorithm is used to calculate the digest value of the new root public key. Then, the digest of the new root public key is digitally signed using the currently valid root private key to generate root public key update signature data. This operation constitutes a one-way irreversible trust chain, ensuring that only the party holding the legal private key can authorize key rotation, preventing malicious public keys from being injected by illegal subjects.

[0036] In step S214, the target system firmware, firmware signature data, and root public key related information are encapsulated to obtain a secure startup firmware package.

[0037] The root public key related information includes the new root public key, the digest of the new root public key, and the root public key update signature data. The secure startup firmware package can be transmitted to the terminal device through OTA, USB, or a diagnostic interface. In the upgrade process, the security boot program verifies the legality of the new public key and completes the online update of the trusted root.

[0038] When encapsulating the target system firmware, firmware signature data, and root public key related information, it is consistent with the above step S113, and will not be described here.

[0039] The method of the embodiment solves the technical problem that vehicle-mounted systems without OTP or eFuse hardware support are difficult to implement secure startup by constructing a secure and trusted firmware encapsulation mechanism at the software level. The method uniformly designs the firmware package structure, compatible with multiple scenarios whether to update the root public key, supports source authentication in regular upgrades, and can also achieve online secure rotation of the root public key through chain signature. The generated firmware package contains complete metadata required for verification to ensure that the device can independently complete trust chain verification. The entire generation process does not require the use of special security chips or physical programming devices, significantly reducing deployment costs, while being compatible with existing OTA and diagnostic upgrade channels, facilitating vehicle manufacturers to quickly land a secure upgrade system that meets the requirements of UNECE WP.29, ISO / SAE 21434, and other regulations.

[0040] The secure startup method provided by the embodiment is particularly designed for vehicle-mounted SoC platforms that have been mass-produced, do not have OTP / eFuse, and have BootROM that cannot be modified. The purpose is to rebuild a verifiable trusted root in their running environment through software means and construct a complete step-by-step trust chain, as shown in Figure 3 The secure startup method includes steps S311-S322: In step S311, in response to a startup instruction, a security boot program is loaded and executed through BootROM.

[0041] Exemplarily, after the vehicle-mounted device is powered on or reset, the BootRom inside the SoC runs first as the starting point of trust, and jumps to the location of the secure boot program Secure-BL according to the preset address, loads it into the memory (such as SRAM) and starts execution. The secure boot program is a secondary boot code with integrity verification and digital signature functions, and is a core module for building a software-defined trust chain.

[0042] BootRom (Boot Read-Only Memory) is a section of read-only memory area inside the SoC chip that cannot be modified, which stores the most basic boot code. Since its content is written at the time of chip manufacturing and cannot be changed, BootRom is considered as the physical starting point of the trust chain, and plays the role of the initial trusted root in the secure boot process.

[0043] It should be noted that when the secure boot program is first deployed, a secure storage area can be created in the original system without security capabilities, and the initial root public key and its digest are written to complete the reconstruction of the trusted root. Subsequent upgrade support updates the root public key through a chain signature mechanism, that is, the digest of the new root public key is signed using the current valid root private key, and the device can replace the new root public key after passing the old root public key signature verification, realizing online key rotation and trust anchor migration without hardware modification. This mechanism solves the problem of lifelong fixed root public key in traditional solutions, which is invalid if leaked, and improves the long-term security and compliance adaptability of the system.

[0044] Step S312, whether the secure storage area located in the non-volatile memory exists is detected by the secure boot program.

[0045] Exemplarily, after the secure boot program (Secure-BL) is started, it first detects whether a secure storage area for storing the root public key has been created in the non-volatile memory (such as eMMC, UFS or NOR Flash). The area is preferably set in the reserved physical block of the Flash, and is configured by the memory management unit (MMU) to allow only the CPU to access in privileged mode, preventing user state programs from illegal reading and writing.

[0046] If it is detected that the secure storage area exists, step S313 is performed; otherwise, step S314 is performed.

[0047] Step S313, the current root public key and the corresponding pre-stored digest are read from the secure storage area.

[0048] In this step, the current valid root public key and the corresponding pre-stored digest (i.e. the hash value of the public key) are read from the existing secure storage area, which is used for subsequent self-integrity verification.

[0049] The content stored in the secure storage area is shown in Table 1.

[0050] Table 1:

[0051] Step S314, creating a secure storage area.

[0052] If the secure storage area has not been created (e.g. first deployment scenario), the secure boot program allocates a specified physical block in the non-volatile memory and initializes it as a secure storage area. Default security fields, including but not limited to Magic_Word, initial root public key, digest of the root public key, and status flag bit, are then written into it, and the area is marked as initialized. After the initialization is completed, step S313 is entered.

[0053] Step S315, calculating a root public key digest of the current root public key and comparing the root public key digest with the pre-stored digest.

[0054] Exemplarily, the secure boot program Secure-BL recalculates the digest value of the read current root public key using the same hash algorithm (e.g. SHA-256) as that used to generate the pre-stored digest, to obtain a locally calculated root public key digest. The calculation result is compared with the pre-stored digest stored in the secure storage area for consistency.

[0055] If the root public key digest is consistent with the pre-stored digest, it indicates that the root public key has not been tampered with, and step S316 is executed, otherwise step S317 is executed.

[0056] Step S317, determining that the startup fails.

[0057] When any of the verification links (root public key self-check, image public key comparison, digest comparison, or signature verification) fails, the system determines that there is a security risk in the startup process, terminates the subsequent operation, and enters a security exception mode (e.g. locking the device, entering the recovery mode, or reporting a security event).

[0058] Step S316, obtaining image information in the image to be started.

[0059] The image information includes an image public key, an image signature, and an image digest, all of which are packaged in the secure startup firmware package with the image to be started. Secure-BL parses the above information from the image header metadata to prepare for source authentication and integrity verification.

[0060] After the image information is obtained in step S316, step S318 is executed to compare the image public key with the current root public key.

[0061] To prevent an attacker from replacing the public key field in the image, the Secure-BL first performs a byte-by-byte comparison between the image public key and the current root public key in the secure storage area. If the image public key does not match the current root public key, step S317 is performed.

[0062] If the image public key matches the current root public key, step S319 is performed to perform a digest calculation on the firmware body of the image to be started to obtain an actual digest.

[0063] It can be understood that if the image public key comparison passes, the same hash algorithm as when packaging is performed on the received firmware body of the image to be started to calculate its actual digest value, which is used for comparison with the image digest carried in the image.

[0064] Step S320 compares the actual digest with the image digest.

[0065] The actual digest obtained in step S319 is compared with the image digest obtained in step S316. If they do not match, it indicates that the firmware has been tampered with during transmission or storage, and step S317 is performed; if they match, step S321 is continued to digitally verify the signature of the image using the current root public key.

[0066] It can be understood that the current root public key in the secure storage area can be used in this step to perform a digital verification operation on the image signature to verify whether the signature is generated by a legal private key. If the verification passes, it indicates that the image source is trusted, and step S322 is continued; if it does not pass, step S317 is performed.

[0067] Step S322 starts the system corresponding to the image to be started. The image to be started is obtained from the secure boot firmware package described above.

[0068] It can be understood that after all the verification steps pass, the Secure-BL jumps to the main operating system entry address to formally start the system corresponding to the image to be started. The image to be started is derived from the secure boot firmware package generated in the foregoing embodiments (such as the method shown in Figure 1 or Figure 2 ), ensuring the entire trust chain closed loop.

[0069] Through the above process, a technical breakthrough of "rebuilding" a trusted root in a system without a hardware trust anchor can be achieved, so that stock devices without native secure boot capabilities can meet the requirements of UNECE WP.29 R155, ISO / SAE 21434, etc. through pure software upgrade.

[0070] In some embodiments, for stock vehicle systems that have not yet integrated a secure boot program with security verification functions, a secure boot program needs to be deployed for the first time through software upgrade. For example, Figure 4As shown, it shows a burning process flow diagram when the secure boot program is first deployed in the embodiment of the application. The process can be executed in the production line burning, after-sales maintenance or OTA remote upgrade scene, without changing the hardware design. The burning process includes steps S411-step S413: Step S411, receiving a first upgrade package, the first upgrade package containing secure boot program binary data with security verification function.

[0071] Demonstratively, in the initial deployment phase, the device receives a special upgrade package (called the first upgrade package) through the USB interface, diagnostic instrument, OBD port or wireless communication module, and the upgrade package format is compatible with the original upgrade protocol (such as ISO 14229 UDS or A / B partition update mechanism). The first upgrade package encapsulates the binary data of the secure boot program (Secure-BL) with complete security verification capability, which is used to replace the original traditional Bootloader without signature verification function.

[0072] Step S412, the secure boot program binary data is written into the preset jump address region of the non-volatile memory by the original Bootloader.

[0073] Demonstratively, the original Bootloader of the device parses and verifies the validity of the first upgrade package (such as based on CRC check or basic version check), and then writes the secure boot program binary data contained therein into the preset jump address region in the non-volatile memory (such as eMMC or NOR Flash). The region is the startable image loading position defined by the BootROM of the SoC (for example, fixed offset address 0x8000_0000), which ensures that it can be correctly identified and loaded next time power on.

[0074] Step S413, after the burning is completed, the system is restarted to make the BootROM load and execute the secure boot program.

[0075] When the data writing of the secure boot program is completed and the verification is correct, the system automatically triggers the restart operation. After restarting, the BootROM detects whether there is a valid image in the preset address region according to the predetermined process, confirms it, loads it into the memory and starts to execute. From now on, the device enters the secure boot mode dominated by the secure boot program Secure-BL, and all subsequent firmware upgrades and system starts need to pass through strict integrity and legality verification.

[0076] In some embodiments, after the first upgrade package completes the Secure-BL burning and restarts, a formal security upgrade operation needs to be performed once to establish a complete trust chain. The operation is implemented by sending a second upgrade package.

[0077] The second upgrade package is a secure boot firmware package in a format defined in the present application, which contains a target system firmware integrated with a Secure-BL compatible boot header structure, and carries a valid image public key, image signature and image digest. The image public key is consistent with the initial root public key in the secure storage area, and the image signature is generated by the corresponding private key.

[0078] When the device is restarted and loaded with Secure-BL by BootRom, Secure-BL will parse the second upgrade package and perform the secure boot process as described above: including root public key self-check, image public key comparison, actual digest calculation, comparison with image digest and digital signature verification, etc. After all the verifications are passed, the original firmware partition is allowed to be erased and new firmware is written.

[0079] Thus, the smooth migration from a system without security capabilities to a full-link trusted system is completed, ensuring that the end-to-end tamper-proofing capability is still available when the security mechanism is first enabled.

[0080] The secure boot method of the present embodiment, without relying on hardware security modules such as one-time programmable storage unit OTP or electronic fuse eFuse, constructs a complete and trusted boot verification mechanism through software, effectively solving the technical problem that the inventory vehicle SoC system cannot meet the requirements of information security regulations. The method creates a secure storage area using reserved physical blocks in the non-volatile memory, and ensures that only privileged mode can read and write through access permission control, achieving tamper-proof storage of the root public key and its digest. At each system startup, the secure boot program first performs self-integrity check on the root public key to prevent it from being maliciously replaced, and then performs step-by-step verification on the legitimacy of the source and the data integrity of the image to be started, forming a double protection mechanism and further improving the attack resistance of the system. Compared with traditional solutions that rely on hardware trust anchors, this method does not require changes to chip design, packaging or PCB layout, and the cost of a single device increases to zero, making it particularly suitable for low-end vehicle platforms that have already been mass-produced or installed. At the same time, this method is compatible with existing OTA, USB and diagnostic interface upgrade processes, supporting the deployment of security capabilities through software pushing, thereby reducing the technical upgrade threshold and operation and maintenance costs of the vehicle manufacturer. In addition, by designing the first deployment of the secure boot program as an independent burn-in process, smooth migration from a system without security functions to a trusted system can be achieved, thereby ensuring compatibility and upgrade reliability between new and old systems.

[0081] The firmware upgrade verification method of the present embodiment will be described below. The firmware upgrade verification method is applied to the secure chip system of the foregoing embodiment without one-time programmable storage unit OTP or electronic fuse eFuse, and is used to perform trusted verification on whether to update the root public key and the legality of the new public key after the device receives the secure boot firmware package, ensuring the security and controllability of the key rotation process. As shown in FIG. 4, the firmware upgrade verification method comprises the following steps:Figure 5 As shown, the firmware upgrade verification method includes steps S511-S517: Step S511, after receiving the secure boot firmware package, the secure boot program parses whether the secure boot firmware package contains the root public key update signature.

[0082] Exemplarily, after the device receives a secure boot firmware package through OTA, USB or a diagnostic interface, the secure boot program first parses the metadata field in the package to determine whether it contains valid root public key update signature data. The presence or absence of this field indicates whether the current upgrade involves a change in the root public key.

[0083] If the root public key update signature data is empty or marked as an invalid value (such as all 0xFF), it is considered that the root public key does not need to be updated, and step S512 is entered; otherwise, step S515 is entered.

[0084] Step S512, determine whether the root public key digest matches.

[0085] In the case where the root public key is not updated, the secure boot program compares the root public key and its digest carried in the secure boot firmware package with the current root public key and the pre-stored digest stored in the current secure storage area. If they completely match, it means that the public key information has not been tampered with, and step S514 is executed; if they do not match, step S513 is executed.

[0086] Step S513, determine that the boot fails.

[0087] Exemplarily, when any verification link fails, including cases such as root public key digest mismatch, signature verification failure or digest inconsistency, the system determines that there is a security risk, terminates the upgrade process, and enters a security exception handling mode, such as locking the write permission, reporting a security event or entering a recovery mode.

[0088] Step S514, continue the boot process.

[0089] After confirming that the root public key does not need to be updated and all information is consistent, the secure boot program continues the subsequent firmware integrity and legality verification process, and prepares to write new firmware.

[0090] Step S515, use the current root public key stored in the secure storage area to verify the root public key update signature.

[0091] In this step, if it is detected that the root public key update signature data is not empty and has not been marked as invalid, the secure boot program uses the current root public key stored in the current secure storage area to perform a digital signature verification operation on the signature. The signature should be the result of encrypting the digest of the new root public key by the current valid root private key, which is used to prove that the authorized source of the new public key is legal.

[0092] If the signature verification fails, it indicates that the signature is illegal or the private key is not matched, and step S513 is performed; if the signature verification is passed, step S516 is entered.

[0093] In step S516, the digest value of the new root public key in the secure boot firmware package is calculated and compared with the new root public key digest carried in the secure boot firmware package.

[0094] It can be understood that in this step, the new root public key in the firmware package is extracted by the secure boot program, and the digest value thereof is recalculated by using the same hash algorithm (such as SHA-256) as that of the packaging end. Then, the calculation result is compared with the new root public key digest field explicitly carried in the package to verify that the public key itself has not been tampered with.

[0095] If the comparison is inconsistent, step S513 is performed; if the comparison is consistent, step S517 is entered.

[0096] In step S517, the content of the original secure storage area is erased, and the new root public key and the corresponding digest are written into the secure storage area, and then the root public key update is completed.

[0097] After the double verification is passed, the secure boot program releases the write protection state of the original secure storage area, erases the old root public key and related data, and writes the new root public key and its digest into the area. After the writing is completed, the area is marked as an updated state, and the trusted migration of the trust anchor is realized. From now on, the subsequent start and verification will be based on the new root public key, forming a one-way irreversible chain trust path, effectively preventing rollback attacks and systemic risks caused by root private key leakage.

[0098] In some embodiments, in order to ensure the integrity and security of the system upgrade process, after the root public key update is completed, independent integrity and source legality verification of the target firmware body also needs to be performed. As shown in FIG. 6, after the root public key update is completed, steps S611-S615 are further included: Figure 6 In step S611, the data in the secure boot firmware package is subjected to digest calculation to obtain an actual digest value.

[0099] In this step, the secure boot program extracts the target system firmware (i.e., the complete image data to be upgraded) encapsulated in the secure boot firmware package, and calculates the digest of the firmware body by using a preset hash algorithm (such as SHA-256) to obtain a locally generated actual digest value. This operation is independently completed at the device end, and is used to prevent the firmware from being tampered with during transmission or storage.

[0100] In step S612, the actual digest value is compared with the image digest carried in the secure boot firmware package.

[0101] ​The actual digest value calculated in step S611 is compared with the image digest field explicitly carried in the secure boot firmware package for consistency. If the two are completely matched, it means that the firmware data is complete and correct, and step S614 is executed; if not, step S613 is executed.

[0102] In step S613, the digest is not matched, and the update is terminated.

[0103] It can be understood that when the actual digest value and the image digest comparison result are inconsistent, it is determined that the firmware integrity is damaged, there may be malicious modification or transmission error, the system immediately terminates the current upgrade operation, prohibits any write operation, and can trigger a security alarm or enter a recovery mode to prevent illegal firmware flashing.

[0104] In step S614, the latest root public key is used to digitally sign the firmware signature data in the secure boot firmware package.

[0105] Exemplarily, after the firmware integrity check is passed, the secure boot program calls the latest root public key (i.e., the new root public key just completed the update) to perform a digital signature operation on the firmware signature data in the secure boot firmware package. The firmware signature data is an encrypted signature generated by the corresponding latest root private key based on the image digest during the firmware packaging stage, and can only be verified by the paired public key.

[0106] If the signature is passed, it means that the firmware indeed comes from a trusted publisher and has not been forged, and step S615 is executed; if the signature fails, step S613 is returned.

[0107] In step S615, the original firmware partition is erased and the new firmware data is written.

[0108] It can be understood that after all the verification links are passed, the secure boot program releases the write protection state of the original system firmware partition, erases the old version firmware, and writes the new target system firmware data to the specified storage area. After the writing is completed, the upgrade success can be marked, and the updated secure boot program or operating system is loaded by BootROM at the next start to realize function iteration and security policy synchronization.

[0109] The firmware upgrade verification method of the embodiment realizes the secure online update of the root public key without the support of the hardware security module by introducing the chain signature mechanism. The method performs double verification of the new root public key on the device side: the legality is verified by the old root public key, and the integrity is ensured by the digest comparison, which effectively prevents illegal key injection and rollback attacks. At the same time, after the key update is completed, the independent integrity check and source authentication of the firmware body are continued, and a complete trust transmission chain is built.

[0110] In addition, the chain signature update mechanism adopted in the application can ensure that each root public key change must be authorized by the current valid private key, forming a one-way progressive trust chain to prevent old key replay attacks and illegal public key injection. This method breaks through the limitation of lifelong validity after writing in the traditional externally stored public key scheme, and further realizes the full life cycle management of the root trust anchor under the condition of no OTP / eFuse.

[0111] The application also provides a vehicle-mounted electronic device, which comprises: a SoC chip without OTP or eFuse unit inside; a non-volatile memory provided with a secure storage area and storing a secure boot program and a main operating system; and the secure boot program is configured to execute the above-mentioned secure boot method at each start to establish a trusted execution environment. The SoC chip is a system-on-chip (System-on-Chip) integrating a central processing unit (CPU), a storage controller, a bus interface, a DMA engine and various peripheral modules into one body, and is used for running functions such as vehicle information entertainment system, cabin control or gateway communication. In the embodiment, the SoC chip does not integrate hardware security elements such as one-time programmable storage unit (OTP) or electronic fuse (eFuse), and the BootROM has been solidified and cannot be modified to introduce a physical trust anchor through tape-out.

[0112] The application also provides a computer readable storage medium for storing the computer program used in the above-mentioned vehicle-mounted electronic device. For example, the computer readable storage medium can include but is not limited to various program code storage media such as U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), magnetic disk or optical disk.

[0113] In several embodiments provided in the present application, it should be understood that the disclosed apparatus and method can also be implemented by other means. The apparatus embodiments described above are only illustrative, for example, the flowcharts and structural diagrams in the drawings show the possible implementation architecture, function and operation of the apparatus, method and computer program product according to the embodiments of the present application. In this regard, each block in the flowchart or block diagram can represent a module, a program segment or a part of code, which contains one or more executable instructions for implementing the specified logic function. It should also be noted that in alternative implementation, the functions noted in the block can also occur in different order from that noted in the drawings. For example, two consecutive blocks can actually be executed substantially in parallel, and sometimes they can be executed in reverse order, depending on the functions involved. It should also be noted that each block in the structural diagram and / or flowchart, and the combination of blocks in the structural diagram and / or flowchart, can be implemented by a dedicated hardware-based system for executing the specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0114] In addition, each functional module or unit in the embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0115] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer readable storage medium. Based on this understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a smart phone, a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the embodiments of the present application.

[0116] The above description is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application.

Claims

1. A method for generating a firmware package for secure boot, characterized in that, include: Obtain the target system firmware to be upgraded, and perform digest calculation on the target system firmware to obtain the firmware digest value; The firmware digest value is digitally signed using the currently valid root private key to generate firmware signature data; If this upgrade requires updating the root public key, then the digest of the new root public key is digitally signed using the currently valid root private key to generate root public key update signature data; The target system firmware, the firmware signature data, and root public key related information are encapsulated to obtain a secure boot firmware package.

2. The firmware package generation method according to claim 1, characterized in that, When the root public key is not updated during this upgrade, the root public key related information includes: the currently valid root public key and the digest corresponding to the currently valid root public key; wherein, the root public key update signature data is empty or filled with a preset invalid value to indicate that no root public key update operation needs to be performed.

3. The firmware package generation method according to claim 1, characterized in that, When the root public key is updated during this upgrade, the relevant information of the root public key includes: the new root public key, the digest of the new root public key, and the root public key update signature data; wherein, the root public key update signature data is obtained by using the currently valid root private key to perform asymmetric encryption signature on the digest of the new root public key, which is used to implement key rotation based on chain trust on the device side.

4. A safe startup method, characterized in that, For use in security chip systems that do not have one-time programmable memory units (OTP) or eFuse, including: In response to the boot command, a secure boot program is loaded and executed via BootROM; wherein, when the secure boot program is deployed for the first time, a secure storage area can be created in the original system without secure boot, and the initial root public key and the corresponding digest can be written to complete the reconstruction of the trusted root; If the secure bootloader detects the existence of the secure storage area located in non-volatile memory, it reads the current root public key and the corresponding pre-stored digest from the secure storage area. Calculate the root public key digest of the current root public key, and when the root public key digest matches the pre-stored digest, obtain the image information in the image to be started; the image information includes the image public key, the image signature, and the image digest; When the image public key matches the current root public key, a digest is calculated on the firmware body of the image to be started to obtain the actual digest; When the actual digest matches the image digest, the image signature is digitally verified using the current root public key, and the system corresponding to the image to be started is started after the verification is successful; wherein, the startup image is obtained from the secure boot firmware package according to any one of claims 1-3.

5. The safe startup method according to claim 4, characterized in that, If the secure storage area is detected to be absent, the method further includes: The secure bootloader creates the secure storage region in the non-volatile memory and writes a default security field into the secure storage region; the default security field includes an initial root public key and a corresponding digest; Once the secure storage area is created, it is marked as initialized.

6. The secure startup method according to claim 4, characterized in that, The security bootloader, when deployed for the first time, includes the following burning process: Receive a first upgrade package, which contains secure bootloader binary data with security verification capabilities; The original bootloader writes the secure boot program binary data into a preset jump address region of the non-volatile memory; After the burning process is complete, the system will restart, causing the BootROM to load and execute the secure boot program.

7. A firmware upgrade verification method, characterized in that, Applied to the security chip system as described in any one of claims 4-6, comprising: Upon receiving the Secure Boot firmware package, the Secure Boot program parses the Secure Boot firmware package to determine whether it contains a root public key update signature. If it contains and is not marked as invalid, the current root public key stored in the secure storage area is used to verify the signature update of the root public key; If the signature verification is successful, the digest value of the new root public key in the Secure Boot firmware package is calculated and compared with the digest of the new root public key carried in the Secure Boot firmware package. If the comparison matches, the original secure storage area content is erased, and the new root public key and its corresponding digest are written into the secure storage area, thus completing the root public key update.

8. The firmware upgrade verification method according to claim 7, characterized in that, After the root public key update is completed, the following is also included: Digest calculation is performed on the data in the secure boot firmware package to obtain the actual digest value; When the actual digest value matches the image digest carried in the Secure Boot firmware package, the latest root public key is used to digitally verify the firmware signature data in the Secure Boot firmware package; wherein, the firmware signature data is generated based on the image digest; After the signature verification is successful, the original firmware partition is erased and new firmware data is written.

9. A vehicle-mounted electronic device, characterized in that, include: SoC chip, wherein the SoC has no OTP or eFuse unit; Non-volatile memory with a secure storage area, which stores a secure boot program and the main operating system; The secure bootloader is configured to execute the secure boot method as described in any one of claims 4-6 at each startup to establish a trusted execution environment.

10. A computer-readable storage medium, characterized in that, It stores a computer program that, when executed on a processor, implements the method according to any one of claims 1-8.

Images