Method and apparatus for data integrity protection

Abstract

An embodiment of the present application provides a method and apparatus for data integrity protection. Among them, the method for data integrity protection is applied to an electronic device. The electronic device stores device manufacturer data and first verification information. The first verification information is stored in a first storage area of the electronic device and is used to perform integrity verification on the device manufacturer data. The method includes: obtaining first data; performing digital signature on the first data to generate second data and second verification information; storing the second data and the second verification information; wherein, the second verification information is stored in a second storage area of the electronic device. The method for data integrity protection provided by the embodiment of the present application supports the reloading of firmware or software customized by a third-party integrator into the system for operation, simplifies the process, and improves the integration and development efficiency of the electronic device.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computing, and in particular, to a method and device for data integrity protection. Background Art

[0002] Firmware, software, etc. stored in a device may be attacked, resulting in illegal tampering or being implanted with a Trojan horse, endangering the operation security of the device. To protect data such as firmware and software in the device, a trusted computing system usually adopts a method of digital signature verification.

[0003] Generally, when the device is powered on and starts up, starting from the trusted root of the system, the firmware or software is started level by level. Before starting the lower-level firmware or software, the integrity of the firmware or software is first verified, and after the integrity verification passes, it is started.

[0004] With the development of communication technology and the refinement of division of labor, co-constructed systems jointly participated by multiple manufacturers are becoming more and more common. After the device leaves the factory, in order to adapt to the needs of the business, a third-party integrator may need to customize the firmware or software. At present, after the device leaves the factory, it does not support reloading the firmware or software customized by the third-party integrator into the system for operation. It must be returned to the original manufacturer for re-signature before it can be loaded, and the process is complex, and the integration and development efficiency of the device is very low. Summary of the Invention

[0005] The embodiments of the present application provide a method and device for data integrity protection, which support reloading the firmware or software customized by a third-party integrator into the system for operation, and improve the integration and development efficiency of the electronic device.

[0006] In a first aspect, the embodiments of the present application provide a method for data integrity protection, which can be applied to an electronic device. The electronic device stores device manufacturer data and first verification information, and the first verification information is stored in the first storage area of the electronic device and is used to verify the integrity of the device manufacturer data. The method includes: obtaining first data; performing a digital signature on the first data to generate second data and second verification information; storing the second data and the second verification information; wherein, the second verification information is stored in the second storage area of the electronic device.

[0007] Through the method for data integrity protection provided by the first aspect, after the electronic device leaves the factory, it stores the device manufacturer data and the first verification information. The first verification information is stored in the first storage area of the electronic device and is used to perform integrity verification on the device manufacturer data. After the electronic device leaves the factory, a third-party integrator can customize the firmware or software, and can digitally sign the first data to generate the second data and the second verification information. The second verification information is stored in the second storage area of the electronic device. Since the first storage area and the second storage area store the verification information related to different entities respectively, therefore, according to the verification information in at least one of the first storage area and the second storage area, when the electronic device is powered on for secure startup, it can support the reloading of the firmware or software customized by the third-party integrator into the system for operation, without the need to return the electronic device to the factory for re-digital signing. In the scenario of a multi-vendor co-built system, the process is simplified, the integrated development efficiency of the electronic device is improved, and the cooperation efficiency of multiple vendors is improved.

[0008] Optionally, in a possible implementation manner of the first aspect, both the first storage area and the second storage area are one-time write storage areas.

[0009] Through the method for data integrity protection provided by this possible implementation manner, the risk of other entities tampering with the first storage area and the second storage area is avoided, and the security performance of data integrity protection is improved.

[0010] Optionally, in a possible implementation manner of the first aspect, the first data includes the data modified by the third-party integrator to the device manufacturer data. Digitally signing the first data to generate the second data and the second verification information may include: obtaining the public-private key pair provided by the third-party integrator, and digitally signing the first data according to the private key in the public-private key pair to generate the second data and the second verification information; or, digitally signing the first data according to the private key corresponding to the first verification information to generate the second data and the second verification information.

[0011] Through the method for data integrity protection provided by this possible implementation manner, the private key used for digitally signing the first data can be flexibly set according to the customization requirements of the third-party integrator, and the flexibility of the third-party integrator's customization is improved.

[0012] Optionally, in a possible implementation manner of the first aspect, the second verification information includes a secure startup policy and / or a root of trust; wherein, the secure startup policy is used to indicate the rules for performing integrity verification on the second data.

[0013] Optionally, in a possible implementation of the first aspect, the secure boot policy is specifically used to indicate any one of the following: directly load the first data; perform an integrity check on the second data using the first verification information; perform an integrity check on the second data using the second verification information; perform an integrity check on the second data using the first verification information or the second verification information.

[0014] Through the data integrity protection method provided by this possible implementation, third-party integrators can flexibly set the rules for digitally signing the first data according to customization requirements. When the rules for digitally signing are different, the secure boot policy is different. Subsequently, during the secure boot process of the electronic device, the rules for performing an integrity check on the second data can be determined according to the secure boot policy, improving the running speed and stability of the data during the secure boot process.

[0015] Optionally, in a possible implementation of the first aspect, the method may further include: performing a write protection operation on the second storage area.

[0016] Through the data integrity protection method provided by this possible implementation, the second storage area can be locked to prevent other entities from tampering with the second storage area, improving the security performance of data integrity protection.

[0017] Optionally, in a possible implementation of the first aspect, the second data may include the first data, the signature information corresponding to the first data, and the integrity verification information corresponding to the first data.

[0018] Optionally, in a possible implementation of the first aspect, the integrity verification information corresponding to the first data may include at least one of the following: a certificate, a certificate chain, the public key used for digitally signing the first data, or the hash value of the public key used for digitally signing the first data.

[0019] In a second aspect, an embodiment of the present application provides a method for data integrity protection, including: obtaining data to be verified, first verification information, and second verification information. The first verification information is stored in the first storage area of the electronic device, and the second verification information is stored in the second storage area of the electronic device. Both the first storage area and the second storage area are one-time write storage areas. Perform an integrity check on the data to be verified according to at least one of the first verification information and the second verification information.

[0020] Optionally, in a possible implementation of the second aspect, the second verification information includes at least one of the following provided by a third-party integrator: a secure boot policy or a second trust root; the secure boot policy is used to indicate the rules for performing an integrity check on the data to be verified.

[0021] Optionally, in a possible implementation manner of the second aspect, performing integrity verification on the data to be verified according to the second verification information may include: determining whether to directly load the data to be verified according to the secure boot policy; if it is determined not to directly load the data to be verified and integrity verification of the data to be verified is required, then performing integrity verification on the data to be verified according to the first verification information or the second verification information.

[0022] Optionally, in a possible implementation manner of the second aspect, if it is determined to directly load the data to be verified, then load and execute the data to be verified.

[0023] Optionally, in a possible implementation manner of the second aspect, the first verification information includes a first trust root provided by the device provider, and the first trust root includes a first root public key or a hash value of the first root public key.

[0024] Optionally, in a possible implementation manner of the second aspect, the secure boot policy is specifically used to indicate any one of the following: directly loading the data to be verified; performing integrity verification on the data to be verified using the first verification information; performing integrity verification on the data to be verified using the second verification information; performing integrity verification on the data to be verified using the first verification information or the second verification information.

[0025] Optionally, in a possible implementation manner of the second aspect, before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information, it may further include: determining that the second storage area is in a write-protected state.

[0026] Through the method for data integrity protection provided by this possible implementation manner, the risk of other entities tampering with the second storage area is avoided, and the security performance of data integrity protection is improved.

[0027] Optionally, in a possible implementation manner of the second aspect, the method may further include: if it is determined that the second storage area is not in a write-protected state, then performing a write protection operation on the second storage area.

[0028] Optionally, in a possible implementation manner of the second aspect, the method may further include: performing a write protection operation on the second storage area may include: generating a prompt message; the prompt message is used to indicate that the second storage area is not in a write-protected state; receiving a write protection instruction, the write protection instruction is used to indicate performing a write protection on the second storage area; performing a write protection operation on the second storage area according to the write protection instruction.

[0029] In a third aspect, an embodiment of the present application provides a data integrity protection device, which can be applied to an electronic device. The electronic device stores device manufacturer data and first verification information. The first verification information is stored in a first storage area of the electronic device and is used to perform integrity verification on the device manufacturer data. The data integrity protection device may include: an acquisition module, configured to acquire first data; a processing module, configured to perform digital signature on the first data to generate second data and second verification information; a storage module, configured to store the second data and the second verification information; wherein, the second verification information is stored in a second storage area of the electronic device.

[0030] Optionally, in a possible implementation manner of the third aspect, both the first storage area and the second storage area are one-time write storage areas.

[0031] Optionally, in a possible implementation manner of the third aspect, the first data includes data obtained by a third-party integrator after modifying the device manufacturer data. The processing module is specifically configured to: acquire a public-private key pair provided by the third-party integrator; perform digital signature on the first data according to the private key in the public-private key pair to generate second data and second verification information; or, perform digital signature on the first data according to the private key corresponding to the first verification information to generate second data and second verification information.

[0032] Optionally, in a possible implementation manner of the third aspect, the second verification information includes a secure boot policy and / or a root of trust; wherein, the secure boot policy is used to indicate rules for performing integrity verification on the second data.

[0033] In a fourth aspect, an embodiment of the present application provides a data integrity protection device, which may include: an acquisition module, configured to acquire data to be verified, first verification information, and second verification information; the first verification information is stored in a first storage area of the electronic device, the second verification information is stored in a second storage area of the electronic device, and both the first storage area and the second storage area are one-time write storage areas; a processing module, configured to perform integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

[0034] Optionally, in a possible implementation manner of the fourth aspect, the second verification information includes at least one of the following provided by a third-party integrator: a secure boot policy or a second root of trust; wherein, the secure boot policy is used to indicate rules for performing integrity verification on the data to be verified.

[0035] Optionally, in a possible implementation manner of the fourth aspect, the processing module is specifically configured to: determine whether to directly load the data to be verified according to the secure boot policy; if it is determined not to directly load the data to be verified and integrity verification of the data to be verified is required, then perform integrity verification on the data to be verified according to the first verification information or the second verification information.

[0036] Optionally, in a possible implementation manner of the fourth aspect, the first verification information includes a first root of trust provided by the device provider, and the first root of trust includes a first root public key or a hash value of the first root public key.

[0037] Optionally, in a possible implementation manner of the fourth aspect, the processing module is further configured to: determine that the second storage area is in a write-protected state before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

[0038] In a fifth aspect, an embodiment of the present application provides a device for data integrity protection, including a processor and a memory. The processor is configured to call a program stored in the memory to execute the method provided in the above first aspect or the second aspect.

[0039] In a sixth aspect, an embodiment of the present application provides an electronic device, including a processor and a memory. The processor is configured to call a program stored in the memory to execute the method provided in the above first aspect or the second aspect.

[0040] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium. Instructions are stored in the computer-readable storage medium. When the instructions run on a computer or a processor, the method provided in the above first aspect or the second aspect is implemented.

[0041] In an eighth aspect, an embodiment of the present application provides a program product. The program product includes a computer program. The computer program is stored in a readable storage medium. At least one processor of the device can read the computer program from the readable storage medium, and the at least one processor executes the computer program so that the device implements the method provided in the above first aspect or the second aspect. Description of the Drawings

[0042] Figure 1 It is a software and hardware architecture diagram of an electronic device applicable to an embodiment of the present application;

[0043] Figure 2 It is a schematic structural diagram of an electronic device;

[0044] Figure 3 It is a schematic diagram of the principle of secure boot of an electronic device;

[0045] Figure 4A schematic structural diagram of an electronic device applicable to the embodiments of the present application;

[0046] Figure 5 A flowchart of a method for data integrity protection provided by the embodiments of the present application;

[0047] Figure 6 Another flowchart of a method for data integrity protection provided by the embodiments of the present application;

[0048] Figure 7 Another flowchart of a method for data integrity protection provided by the embodiments of the present application;

[0049] Figure 8 A schematic diagram of the principle of secure boot of an electronic device provided by the embodiments of the present application;

[0050] Figure 9 A schematic structural diagram of a device for data integrity protection provided by the embodiments of the present application;

[0051] Figure 10 Another schematic structural diagram of a device for data integrity protection provided by the embodiments of the present application;

[0052] Figure 11 Another schematic structural diagram of a device for data integrity protection provided by the embodiments of the present application;

[0053] Figure 12 A schematic structural diagram of an electronic device provided by the embodiments of the present application. Detailed implementation manners

[0054] The embodiments of the present application will be described below with reference to the accompanying drawings.

[0055] First, the concepts related to the embodiments of the present application will be described.

[0056] 1. Digital signature

[0057] A digital signature can also be called a public key digital signature or an electronic signature. It is a method for authenticating whether digital information is valid and complete by using technologies in the field of public key cryptography. A set of digital signatures usually defines two complementary operations, one for signing and the other for verification.

[0058] 2. Secure boot (verified boot)

[0059] Secure boot refers to a technology that only allows firmware or software signed by a specific entity (such as a device manufacturer) to run on a device. The core function of secure boot is to use digital signatures to confirm whether the firmware or software is trusted. Secure boot can be based on public key encryption algorithms, digital signature algorithms, hash algorithms, etc. The hardware infrastructure on which secure boot depends can be called the trusted root. The trusted root ensures the integrity of the first instruction that the platform runs, and through digital signature verification, it can ensure the integrity of subsequent loaded objects, thereby passing the trust chain level by level to subsequent firmware or software, and finally building the trust of the entire platform.

[0060] Firmware, software, etc. stored in an electronic device may be attacked, resulting in illegal tampering or being implanted with Trojans, endangering the running safety of the device. To ensure the running safety of the electronic device, a digital signature verification method is usually adopted. Exemplarily, Figure 1 This is a software and hardware architecture diagram of an electronic device applicable to the embodiments of the present application. As Figure 1 shown, the hardware part of the electronic device may include but is not limited to: a chip, a flash memory, and peripherals. The software part of the electronic device may include but is not limited to: firmware, an operating system, drivers, hardware configuration information, and application software. Among them, the chip may include a memory. The embodiments of the present application do not limit the quantity, type, and specific content stored in the memory. For example, referring to Figure 1, in an electronic device supporting secure boot, the chip may include a read-only memory (ROM) and electrical fuses (eFUSEs). Trusted boot code may be stored in the ROM. The eFUSEs are used to write non-changeable data once, for example, the data may include verification information for digital signature verification during secure boot. Optionally, configuration information may also be stored in the eFUSEs, for example, the configuration information may include at least one of the following: the power supply voltage used by the chip, the version number of the chip, and the production date. Persistent data such as software packages may be stored in the Flash. In an electronic device, firmware (FW) refers to the programmable software part in a hardware device, usually the software that performs the most basic and underlying work of the system and is written into an erasable read-only memory (EROM) or an erasable programmable read-only memory (EPROM), and has the property of software upgradability. Optionally, the firmware may include, but is not limited to, bootloader firmware and unified extensible firmware interface (UEFI) firmware. The operating system, drivers, and hardware configuration information may constitute the running platform for application software, and application software refers to software used to implement various specific functions. Application software is also referred to as an application program.

[0061] It should be noted that in the embodiments of this application, an "electronic device" may also be referred to as a "device".

[0062] It should be noted that in the embodiments of this application, "the firmware and software stored in the electronic device" and "the firmware or software stored in the electronic device" have the same meaning, including the data running during the secure boot of the electronic device. For example, it may include Figure 1 at least one of the firmware, operating system, drivers, or hardware configuration information.

[0063] It should be noted that the specific components included in the peripherals in the embodiments of this application are not limited. Different types of electronic devices may include different components in the peripherals.

[0064] It should be noted that the embodiments of this application do not limit other software or hardware that the electronic device further includes.

[0065] Next, in combination with Figures 1-3 , the digital signature process and the secure boot process of the electronic device will be exemplarily described through Example A and Example B, but do not limit the digital signature process and the secure boot process of the electronic device. Exemplarily,Figure 2 It is a schematic structural diagram of an electronic device, Figure 3 and is a schematic diagram of the principle of secure startup of an electronic device. As Figure 2 shown, the electronic device may include a chip 100, and the chip 100 may include a storage area 11 and a ROM 12. The storage area 11 is a one-time write storage area. For the descriptions of the chip, eFUSE, and ROM, reference can be made to Figure 1 respectively. The principles are similar and will not be elaborated here. In Example A and Example B, the firmware and software stored in the electronic device may include: bootloader firmware, UEFI firmware, kernel software package, drivers, and hardware configuration information.

[0066] Example A

[0067] First, an exemplary description of the digital signature process before the electronic device leaves the factory is given. The electronic device may perform the following operations:

[0068] 1.1. Burn an unchangeable and trustworthy startup code in the ROM 12 of the chip 100.

[0069] 1.2. Obtain the root public key A and root private key A provided by the device provider, and write the root public key A or the hash value of the root public key A in the storage area 11 of the chip 100. Compared with writing the root public key A, writing the hash value of the root public key A can save storage space. This example is described by taking writing the hash value of the root public key A as an example.

[0070] Perform write protection on the storage area 11 and lock the storage area 11 to prevent other entities from tampering with the storage area 11.

[0071] 1.3. Obtain the secondary public key B and secondary private key B provided by the device provider. In this example, the secondary private key B is used to digitally sign the firmware or software.

[0072] 1.4. Digitally sign the bootloader firmware.

[0073] Sign the bootloader firmware with the secondary private key B to generate the signature information corresponding to the bootloader firmware.

[0074] Sign the secondary public key B with the root private key A to generate the certificate chain corresponding to the bootloader firmware. This certificate chain includes the secondary public key B signed with the root private key A, and also includes the root public key A or the hash value of the root public key A. This example is described by taking including the hash value of the root public key A as an example.

[0075] Packing and storing the bootloader firmware, the signature information corresponding to the bootloader firmware, and the certificate chain corresponding to the bootloader firmware in the electronic device can be referred to as data packet a.

[0076] 1.5. Using a method similar to 1.4, digitally sign and pack and store the UEFI firmware, the kernel software package, the drivers, and the hardware configuration information in sequence.

[0077] Among them, packing the UEFI firmware, the signature information corresponding to the UEFI firmware, and the certificate chain corresponding to the UEFI firmware can be referred to as data packet b.

[0078] Packing the kernel software package, the signature information corresponding to the kernel software package, and the certificate chain corresponding to the kernel software package can be referred to as data packet c.

[0079] Packing the drivers, the signature information corresponding to the drivers, and the certificate chain corresponding to the drivers can be referred to as data packet d.

[0080] Packing the hardware configuration information, the signature information corresponding to the hardware configuration information, and the certificate chain corresponding to the hardware configuration information can be referred to as data packet e.

[0081] Next, an exemplary description of the secure boot process after the electronic device leaves the factory will be given.

[0082] After the electronic device is powered on, it starts from the trusted boot code in the ROM and starts the firmware or software in data packets a to e step by step. Before starting the next-level firmware or software, it is necessary to first perform an integrity check on the firmware or software, and start it after the integrity check passes. Specifically, the electronic device can perform the following operations:

[0083] 2.1. Start from the boot code stored in ROM12 of chip 100.

[0084] 2.2. The boot code reads the hash value of the root public key A provided by the device provider from storage area 11. For the convenience of description, the read root public key A can be referred to as root public key A'.

[0085] 2.3. The boot code reads the certificate chain corresponding to the bootloader firmware in data packet a and parses out the root public key A. For the convenience of description, the parsed root public key A can be referred to as root public key A".

[0086] 2.4. Verify whether the root public key A provided by the device provider has been tampered with.

[0087] Specifically, compare whether the hash value of root public key A' is the same as the hash value of root public key A".

[0088] Case 1: If the hash value of the root public key A' is the same as the hash value of the root public key A", it indicates that the root public key A provided by the device provider has not been tampered with, and proceed to 2.5.

[0089] Case 2: If the hash value of the root public key A' is different from the hash value of the root public key A", it indicates that the root public key A provided by the device provider may have been tampered with, then stop the startup.

[0090] 2.5. Verify whether the secondary public key B provided by the device provider has been tampered with.

[0091] Specifically, the startup code reads the certificate chain corresponding to the bootloader firmware in the data packet a and parses out the secondary public key B signed with the root private key A. For ease of explanation, the parsed secondary public key B can be referred to as secondary public key B'. Use the root public key A' or root public key A" to verify the secondary public key B'.

[0092] Case 1: If the verification passes, it indicates that the secondary public key B provided by the device provider has not been tampered with, and proceed to 2.6.

[0093] Case 2: If the verification fails, it indicates that the secondary public key B provided by the device provider may have been tampered with, then stop the startup.

[0094] 2.6. Perform integrity verification on the bootloader firmware.

[0095] Specifically, perform integrity verification on the bootloader firmware according to the secondary public key B' and the signature information corresponding to the bootloader firmware.

[0096] Case 1: If the verification passes, it indicates that the bootloader firmware has not been tampered with, then load and execute the bootloader firmware.

[0097] Case 2: If the verification fails, it indicates that the bootloader firmware may have been tampered with, then stop the startup.

[0098] 2.7. Subsequently, using a method similar to 2.3 - 2.6, the bootloader firmware can perform integrity verification on the UEFI firmware, and the UEFI firmware can perform integrity verification on the kernel software package, drivers, and hardware configuration information, enabling secure startup step by step, thereby achieving the secure startup of the electronic device.

[0099] Example B

[0100] The difference between this example and Example A is that different private keys are used for digital signing of the firmware and software, and correspondingly, different public keys are used for digital signature verification of the firmware and software. In Example A, the secondary private key B and secondary public key B provided by the device provider are used for digital signing and verification respectively. In this example, the root private key A and root public key A provided by the device provider are used for digital signing and verification respectively.

[0101] In this example, the same step numbers are used for the same steps as in Example A, and different step numbers are used for the steps different from those in Example A and are described in detail.

[0102] In this example, for the digital signature process, the electronic device can execute steps 1.1 to 1.2, 1.3' to 1.4'.

[0103] 1.3'. Digitally sign the bootloader firmware.

[0104] Sign the bootloader firmware using the root private key A to generate the signature information corresponding to the bootloader firmware.

[0105] The certificate chain corresponding to the bootloader firmware may include: the root public key A or the hash value of the root public key A. In this example, the case where the hash value of the root public key A is included is taken as an example for description.

[0106] Pack and store the bootloader firmware, the signature information corresponding to the bootloader firmware, and the certificate chain corresponding to the bootloader firmware in the electronic device, which can be called data packet a.

[0107] 1.4'. Using a method similar to 1.3', digitally sign and pack and store the UEFI firmware, kernel software package, driver, and hardware configuration information in sequence, and form data packets b to e respectively.

[0108] For the secure boot process, the electronic device can execute steps 2.1 to 2.2, 2.3' to 2.6'.

[0109] 2.3'. The startup code reads the certificate chain corresponding to the bootloader firmware in data packet a and parses out the root public key A. For the convenience of description, the parsed root public key A can be called the root public key A".

[0110] 2.4'. Verify whether the root public key A provided by the device provider has been tampered with.

[0111] Specifically, compare whether the hash value of the root public key A' is the same as the hash value of the root public key A".

[0112] Case 1: If the hash value of the root public key A' is the same as the hash value of the root public key A", it indicates that the root public key A provided by the device provider has not been tampered with, and step 2.5' is executed.

[0113] Case 2: If the hash value of the root public key A' is different from the hash value of the root public key A", it indicates that the root public key A provided by the device provider may have been tampered with, and the startup is stopped.

[0114] 2.5': Perform integrity verification on the bootloader firmware.

[0115] Specifically, according to the root public key A' or the root public key A", and the signature information corresponding to the bootloader firmware, perform integrity verification on the bootloader firmware.

[0116] Case 1: If the verification passes, it indicates that the bootloader firmware has not been tampered with, and the bootloader firmware is loaded and executed.

[0117] Case 2: If the verification fails, it indicates that the bootloader firmware may have been tampered with, and the startup is stopped.

[0118] 2.6': Subsequently, using a method similar to 2.3' to 2.5', the bootloader firmware can perform integrity verification on the UEFI firmware, and the UEFI firmware can perform integrity verification on the kernel software package, drivers, and hardware configuration information, and start securely step by step, thereby realizing the secure startup of the electronic device.

[0119] With the development of communication technology and the refinement of division of labor, co - built systems jointly participated by multiple manufacturers are becoming more and more common. After the device leaves the factory, in order to adapt to the needs of the business, the third - party integrator may customize the firmware or software. For example, add new firmware or software, or modify the default firmware or software in the electronic device. Currently, after the device leaves the factory, it does not support re - loading the firmware or software customized by the third - party integrator into the system for operation. It must be returned to the device provider for re - signing before it can be loaded and run. The process is complex, and the integration and development efficiency of the device is very low, which is not conducive to cooperation among multiple manufacturers.

[0120] In view of the above - mentioned technical problems, the embodiment of the present application provides a method for data integrity protection. Refer to Figure 4 , Figure 4 which is a schematic structural diagram of an electronic device applicable to the embodiment of the present application. The electronic device may include a chip 100, and the chip 100 may include a storage area 11, a ROM 12, and a storage area 13. The chip 100, the storage area 11, and the ROM 12 may be respectively referred to Figure 2The chip 100, storage area 11, and ROM 12 therein have similar principles and will not be elaborated here. When the electronic device leaves the factory, the electronic device stores default firmware or software, as well as verification information for verifying the integrity of the default firmware or software. This verification information is stored in a storage area of the electronic device, for example, the storage area 11. After the electronic device leaves the factory, the firmware or software that needs to be customized by a third-party integrator is digitally signed, and the corresponding verification information is stored in another storage area of the electronic device, for example, the storage area 13. Since the storage area 11 and the storage area 13 store verification information related to different entities respectively, therefore, according to the verification information in at least one of the storage area 11 and the storage area 13, when the electronic device is powered on for a secure startup, it can support the reloading of the firmware or software customized by the third-party integrator into the system for operation, without the need to return the electronic device to the factory for re-digital signing. In the scenario of a multi-vendor co-built system, the process is simplified, the integration and development efficiency of the electronic device is improved, and the cooperation efficiency of multiple vendors is improved.

[0121] It should be noted that the embodiments of the present application do not limit the type and application scenario of the electronic device. For example, the electronic device can be any device applied in the fields of computing or communication, such as a computer, a mobile phone, a router, a switch, or a smart device. The electronic device can be applied in the field of artificial intelligence (AI). The device provider can provide AI module hardware, firmware, an operating system, and some AI application software. The third-party integrator can integrate the AI module onto the motherboard and expand the peripherals, add drivers corresponding to the peripherals, and at the same time modify the operating system kernel and AI application software according to the customization requirements. Exemplarily, in one application scenario, the electronic device can be an AI edge computing device.

[0122] It should be noted that the embodiments of the present application do not limit the names of the device provider and the third-party integrator. For example, the device provider can also be referred to as the device providing party, the first device entity, or the first manufacturer, and the third-party integrator can also be referred to as the third-party integrating party, the second device entity, or the second manufacturer.

[0123] It should be noted that the embodiments of the present application do not limit the number of storage areas included in the electronic device. When the number of storage areas is greater than two, the storage areas can correspond one-to-one with different entities, or one entity can correspond to at least one storage area. For example, there are 3 storage areas, called storage areas 1 to 3. In one implementation, storage areas 1 to 3 store verification information related to manufacturers 1 to 3 respectively. In another implementation, storage areas 1 to 2 can store verification information related to manufacturer 1, and storage area 3 can store verification information related to manufacturer 2.

[0124] It should be noted that the embodiments of the present application do not limit the names of the storage area and the verification information. For the sake of convenience of description, in the embodiments of the present application, the storage area related to the device provider may be referred to as the first storage area, and the verification information stored in the first storage area may be referred to as the first verification information. The storage area related to the third-party integrator may be referred to as the second storage area, and the verification information stored in the second storage area may be referred to as the second verification information.

[0125] The following uses specific embodiments to describe in detail the technical solution of the present application and how the technical solution of the present application solves the above technical problems. These specific embodiments below can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0126] Figure 5 A flowchart of a method for data integrity protection provided by an embodiment of the present application. The method for data integrity protection provided in this embodiment can be applied to the stage of integrated development by a third-party integrator after the electronic device leaves the factory, and the execution subject can be a data integrity protection device or an electronic device. For the sake of convenience of description, each method embodiment of the present application is described with an electronic device as the execution subject. Among them, the electronic device stores device provider data and first verification information, and the first verification information is stored in the first storage area of the electronic device for integrity verification of the device provider data. The device provider data may include firmware or software stored when the electronic device leaves the factory. It should be noted that the embodiments of the present application do not limit the name of the device provider data. For example, the device provider data may also be referred to as "default data" or "default firmware or software". The first verification information may include a first trust root provided by the device provider. Among them, the first trust root may include a first root public key, or a hash value of the first root public key, or other information related to the first root public key. It should be noted that in the embodiments of the present application, for the sake of convenience of description, the trust root included in the first verification information may be referred to as the first trust root, the root public key provided by the device provider may be referred to as the first root public key, and the root private key corresponding to the first root public key may be referred to as the first root private key. Among them, the digital signature process before the electronic device leaves the factory can refer to the above Example A or Example B, which will not be repeated here. As Figure 5 shown, the method for data integrity protection provided in this embodiment may include:

[0127] S501. Obtain first data.

[0128] The first data may include firmware or software customized by a third-party integrator. The firmware or software customized by a third-party integrator may be obtained by modifying the equipment vendor data in the electronic device. The data after the third-party integrator modifies the equipment vendor data may be obtained by modifying part or all of the data in the equipment vendor data, or may be obtained by adding new firmware or software based on the equipment vendor data.

[0129] Combine the following Figure 3 , which exemplifies the first data but does not limit the first data.

[0130] Example 1: The UEFI firmware includes a first data packet and a second data packet. If a third-party integrator needs to modify the first data packet, the first data packet may include the modified first data packet and the unmodified second data packet.

[0131] Example 2: The UEFI firmware includes a first data packet and a second data packet, and the driver includes a third data packet and a fourth data packet. If a third-party integrator needs to modify the first data packet and the fourth data packet, the first data packet may include the modified first data packet and the unmodified second data packet, and the unmodified third data packet and the modified fourth data packet.

[0132] Example 3: The UEFI firmware includes a first data packet and a second data packet. If a third-party integrator needs to add a new third data packet based on the first data packet, the first data packet may include an unmodified first data packet, an unmodified second data packet, and the newly added third data packet.

[0133] S502: Digitally sign the first data to generate second data and second verification information.

[0134] The second data may include the first data, signature information corresponding to the first data, and integrity verification information corresponding to the first data. In this embodiment, the integrity verification information corresponding to the first data may include at least one of the following: a certificate, a certificate chain, a public key used to digitally sign the first data, or a hash value of the public key used to digitally sign the first data.

[0135] Among them, the second verification information is used to perform integrity verification on the second data during the secure startup process after the electronic device is powered on. In this embodiment, the second verification information may include at least one of the following: a secure startup policy or a second trust root. The secure startup policy is used to indicate the rules for performing integrity verification on the second data. The second trust root may include a second root public key provided by a third-party integrator, or include a hash value of the second root public key, or include other information related to the second root public key. It should be noted that in the embodiments of the present application, for the convenience of description, the trust root included in the second verification information may be referred to as the second trust root, the root public key provided by the third-party integrator may be referred to as the second root public key, and the root private key corresponding to the second root public key may be referred to as the second root private key. Among them, the secure startup policy or the second trust root may be provided by a third-party integrator.

[0136] This embodiment does not limit the digital signature algorithm used, and it can be any digital signature algorithm, such as the relevant descriptions in Example A or Example B above.

[0137] This embodiment does not limit the private key used for digital signature. Different private keys are used, and the corresponding secure startup policies are different.

[0138] For example, the second root private key corresponding to the second root public key provided by the third-party integrator can be used to perform digital signature on the first data. Then, the secure startup policy can be used to indicate using the second verification information to perform integrity verification on the second data, or the secure startup policy can be used to indicate using the first verification information or the second verification information to perform integrity verification on the second data.

[0139] For another example, the first root private key corresponding to the first root public key provided by the device provider can be used to perform digital signature on the first data. Then, the secure startup policy can be used to indicate using the first verification information to perform integrity verification on the second data, or the secure startup policy can be used to indicate using the first verification information or the second verification information to perform integrity verification on the second data.

[0140] It should be noted that the firmware or software stored in the electronic device has a hierarchy, and each firmware or software will be started step by step during the secure startup process after the electronic device is powered on. For example, in Figure 3Among them, the firmware and software stored in the electronic device include: bootloader firmware, UEFI firmware, kernel software package, drivers, and hardware configuration information. The firmware or software customized by a third-party integrator may involve at least one level. If the firmware or software customized by a third-party integrator involves at least two levels, that is, when the first data involves at least two levels, digital signatures are respectively performed on the firmware or software of each level. For example. Referring to the above Example 2, when the first data involves two levels of UEFI firmware and drivers, performing a digital signature on the first data may include: performing digital signatures on the modified first data packet and the unmodified second data packet to generate corresponding second data; performing digital signatures on the unmodified third data packet and the modified fourth data packet to generate corresponding second data.

[0141] S503. Store the second data and the second verification information. Among them, the second verification information is stored in the second storage area of the electronic device.

[0142] Exemplarily, the first storage area can refer to Figure 4 the storage area 11 in Figure 4 the storage area 13 in, with a similar principle, which will not be elaborated here.

[0143] It can be seen that in the method for data integrity protection provided in this embodiment, after the electronic device leaves the factory, it stores the device manufacturer data and the first verification information, and the first verification information is stored in the first storage area of the electronic device for integrity verification of the device manufacturer data. After the electronic device leaves the factory, a third-party integrator can customize the firmware or software, and can perform a digital signature on the first data to generate the second data and the second verification information. The second verification information is stored in the second storage area of the electronic device. Since the first storage area and the second storage area respectively store the verification information related to different entities, therefore, according to the verification information in at least one of the first storage area and the second storage area, when the electronic device is powered on for secure startup, it can support the firmware or software customized by the third-party integrator to be reloaded into the system for operation, without the need to return the electronic device to the factory for re-digital signature. In the scenario of a multi-vendor co-built system, the process is simplified, the integration and development efficiency of the electronic device is improved, and the cooperation efficiency of multiple vendors is improved.

[0144] Optionally, in S502, performing a digital signature on the first data to generate the second data and the second verification information may include:

[0145] Obtain the public-private key pair provided by the third-party integrator.

[0146] Perform a digital signature on the first data according to the private key in the public-private key pair to generate the second data and the second verification information.

[0147] Alternatively,

[0148] Perform a digital signature on the first data using the private key corresponding to the first verification information to generate second data and second verification information.

[0149] Specifically, according to the customization requirements of the third-party integrator, the private key used for digital signature of the first data can be flexibly set to improve the flexibility of third-party integrator customization. Among them, in one implementation, the private key used for digital signature of the first data is related to the third-party integrator, specifically the private key provided by the third-party integrator. For example, referring to the digital signature process in the above Example A, the public-private key pair provided by the third-party integrator can include a second root private key and a second root public key, and can also include a pair of secondary public-private key pairs. The first data can be digitally signed using the secondary private key in the secondary public-private key pair provided by the third-party integrator. Another example, referring to the digital signature process in the above Example B, the public-private key pair provided by the third-party integrator can include a second root private key and a second root public key, and the first data can be digitally signed using the second root private key provided by the third-party integrator. In another implementation, the private key used for digital signature of the first data is related to the device provider, specifically the private key corresponding to the first verification information, that is, the first root private key provided by the device provider.

[0150] In this embodiment, in order to improve the security performance of data integrity protection, both the first storage area and the second storage area are one-time write storage areas. The one-time write storage area is used to write non-changeable data once, avoiding the risk of other entities tampering with the first storage area and the second storage area. The implementation method of the one-time write storage area in this embodiment is not limited. For example, both the first storage area and the second storage area are eFUSE. Another example, the first storage area and the second storage area can be two one-time write storage areas in the same memory. Another example, the first storage area and the second storage area are respectively one-time write storage areas in different memories.

[0151] Optionally, the method for data integrity protection provided in this embodiment may further include:

[0152] Perform a write protection operation on the second storage area.

[0153] By performing write protection on the second storage area, the second storage area can be locked to avoid other entities tampering with the second storage area, improving the security of secure boot of the electronic device.

[0154] Figure 6Another flowchart of the data integrity protection method provided by the embodiments of the present application. The data integrity protection method provided by this embodiment can be applied to the stage of integrated development by a third-party integrator after the electronic device leaves the factory, and the execution subject can be a data integrity protection device or an electronic device. This embodiment is different from Figure 5 the embodiment shown in that Figure 5 in the embodiment shown, it is necessary to digitally sign the first data. In this embodiment, it can be determined that the first data is trustworthy, and the first data can be not digitally signed. Correspondingly, during the secure boot process after the electronic device is powered on, the first data can be directly loaded and run.

[0155] In this embodiment, the same step numbers are used for the same steps as in Figure 5 the embodiment shown, and different step numbers are used for the steps different from Figure 5 the embodiment shown and are described in detail.

[0156] As Figure 6 shown, the data integrity protection method provided by this embodiment may include:

[0157] S501. Obtain the first data.

[0158] S602. Store the first data and the second verification information. The second verification information is stored in the second storage area of the electronic device.

[0159] The second verification information is used to perform integrity verification on the second data during the secure boot process after the electronic device is powered on. In this embodiment, since it can be determined that the first data is trustworthy, subsequently, during the secure boot process after the electronic device is powered on, the first data can be directly loaded and run, and the second verification information may include a secure boot policy, and the secure boot policy may be used to indicate directly loading the first data, or to indicate using the first verification information to perform integrity verification on the second data.

[0160] It can be seen that in the data integrity protection method provided in this embodiment, after the electronic device leaves the factory, it stores the device manufacturer data and the first verification information. The first verification information is stored in the first storage area of the electronic device and is used to perform integrity verification on the device manufacturer data. After the electronic device leaves the factory, a third-party integrator can customize the firmware or software. In a scenario where it can be determined that the customized firmware or software is trustworthy, the first data does not need to be digitally signed, and the second verification information is stored in the second storage area of the electronic device. Since the first storage area and the second storage area respectively store the verification information related to different entities, therefore, according to the verification information in at least one of the first storage area and the second storage area, when the electronic device is powered on for secure startup, it can support the customized firmware or software of the third-party integrator to be reloaded into the system for operation, without the need to return the electronic device to the factory for re-digital signature. In a scenario where multiple manufacturers jointly build a system, the process is simplified, the integrated development efficiency of the electronic device is improved, and the cooperation efficiency of multiple manufacturers is improved.

[0161] It should be noted that Figure 5 The embodiments shown Figure 6 The embodiments shown can be combined with each other in some scenarios. At this time, the first data involves at least two levels. For the firmware or software at different levels, according to the requirements of the third-party integrator, it can be digitally signed or not.

[0162] Next, on the basis of Figure 5 and Figure 6 the embodiments shown, in combination with Figure 4 Example C is used to exemplarily illustrate the data integrity protection method provided in the embodiments of the present application. For example, in this example, when the electronic device leaves the factory, the device manufacturer data may include: bootloader firmware, UEFI firmware, kernel software package, drivers, and hardware configuration information, all of which are digitally signed using the root private key A (i.e., the first root private key) provided by the device provider. The first verification information may include the hash value of the root public key A (i.e., the first root public key) provided by the device provider and is stored in the storage area 11 (i.e., the first storage area) of the electronic device. For example, the third-party integrator needs to modify the UEFI firmware and drivers. It should be noted that this example does not limit the specific content included in the first data, the second data, and the second verification information.

[0163] Example C

[0164] The data integrity protection method provided in this example may include:

[0165] 3.1. Obtain the first data.

[0166] Since third-party integrators need to modify the UEFI firmware and drivers when the electronic device leaves the factory, the first data involves two levels in the firmware or software. For ease of explanation, the UEFI firmware when the electronic device leaves the factory is referred to as the first UEFI firmware, and the UEFI firmware customized by the third-party integrator is referred to as the second UEFI firmware. The second UEFI firmware includes the unmodified part of the first UEFI firmware and the modified part of the first UEFI firmware. Similarly, the driver when the electronic device leaves the factory is referred to as the first driver, and the driver customized by the third-party integrator is referred to as the second driver. The second driver includes the unmodified part of the first driver and the modified part of the first driver. The first data may include the second UEFI firmware and the second driver.

[0167] 3.2. Digitally sign the first data to generate second data and second verification information.

[0168] For example, in this example, according to the requirements of the third-party integrator, it is necessary to use the root private key C (i.e., the second root private key) provided by the third-party integrator to digitally sign the second UEFI firmware, and it is not necessary to digitally sign the second driver.

[0169] Use the root private key C provided by the third-party integrator to digitally sign the second UEFI firmware to generate the signature information corresponding to the second UEFI firmware. Moreover, pack the second UEFI firmware, the signature information corresponding to the second UEFI firmware, and the integrity verification information corresponding to the second UEFI firmware into second data, which can be called data packet b'. Among them, the integrity verification information corresponding to the second UEFI firmware may include the hash value of the root public key C (i.e., the second root public key), and the root public key C corresponds to the root private key C.

[0170] The second verification information may include a secure boot policy and a second trust root. The secure boot policy is used to indicate using the second verification information to perform integrity verification on the second UEFI firmware and can directly load the second driver. The second trust root may include the hash value of the root public key C.

[0171] 3.3. Store the second data and the second verification information.

[0172] Specifically, store data packet b' and the second driver in the electronic device, and write the second verification information in storage area 13.

[0173] 3.4. Perform write protection on storage area 13, lock storage area 13, and prevent other entities from tampering with storage area 13.

[0174] Figure 7Another flowchart of the data integrity protection method provided by the embodiments of the present application. The data integrity protection method provided by this embodiment can be applied to the secure startup process after the electronic device is powered on, and the execution subject can be a data integrity protection device or an electronic device. As Figure 7 shown, the data integrity protection method provided by this embodiment may include:

[0175] S701. Obtain the data to be verified, the first verification information, and the second verification information.

[0176] Among them, the first verification information is stored in the first storage area of the electronic device, and the second verification information is stored in the second storage area of the electronic device. Both the first storage area and the second storage area are one-time write storage areas.

[0177] Exemplarily, for the first storage area, reference can be made to the storage area 11 in Figure 4 , and for the second storage area, reference can be made to the storage area 13 in Figure 4 . The principle is similar and will not be elaborated here.

[0178] This embodiment does not limit the specific content included in the data to be verified. Optionally, the data to be verified may include the firmware or software default when the electronic device leaves the factory. For example, the data to be verified may include Figure 3 the boot code firmware package, UEFI firmware package, kernel software package, driver, and hardware configuration information in

[0179] at least one of them and their corresponding signature information and certificate chain. For example, the data to be verified may include: the UEFI firmware package, the signature information and certificate chain corresponding to the UEFI firmware package. Another example, the data to be verified may include: the UEFI firmware package, the signature information and certificate chain corresponding to the UEFI firmware package, and the kernel software package, the signature information and certificate chain corresponding to the kernel software package. Optionally, the data to be verified may include the firmware or software customized by a third-party integrator after the electronic device leaves the factory. Optionally, the data to be verified may include any combination of the default firmware or software in the electronic device and the firmware or software customized by a third-party integrator.

[0180] In this embodiment, the first verification information may include the first trust root provided by the device provider, and the first trust root may include the first root public key, or the hash value of the first root public key, or other information related to the first root public key.

[0181] In this embodiment, the secure boot policy can be used to indicate any one of the following:

[0182] Directly load the data to be verified;

[0183] Use the first verification information to perform integrity verification on the data to be verified;

[0184] Use the second verification information to perform integrity verification on the data to be verified;

[0185] Use the first verification information or the second verification information to perform integrity verification on the data to be verified.

[0186] In this embodiment, the first storage area can be in a write-protected state. By determining that the first storage area is in a write-protected state, the risk of malicious tampering of the first storage area can be avoided, and the security of the secure boot of the electronic device is further improved.

[0187] S702. Perform integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

[0188] It can be seen that in the data integrity protection method provided in this embodiment, both the first storage area and the second storage area of the electronic device are one-time write storage areas, avoiding the risk of tampering with the storage area and improving the security performance of data integrity protection. Moreover, the first verification information is stored in the first storage area, the second verification information is stored in the second storage area, and the subjects involved in the first verification information and the second verification information are different. When the electronic device is powered on for secure boot, by using dual verification information for integrity verification, if the integrity verification performed on the data to be verified using at least one of the first verification information and the second verification information passes, the integrity of the data to be verified in the electronic device can be ensured, realizing the secure boot of the electronic device in the scenario of a multi-vendor co-built system. The data integrity protection method provided in this embodiment supports directly loading the firmware or software customized by a third-party integrator into the system for operation, without the need to return the electronic device to the factory for re-digital signature. In the scenario of a multi-vendor co-built system, the process is simplified, the integrated development efficiency of the electronic device is improved, and the cooperation efficiency of multiple vendors is improved.

[0189] It should be noted that in this embodiment, the execution order of performing integrity verification on the data to be verified according to the first verification information and performing integrity verification on the data to be verified according to the second verification information in S702 is not limited. It is possible to first perform integrity verification on the data to be verified according to the first verification information, or first perform integrity verification on the data to be verified according to the second verification information. The following is a detailed description.

[0190] In the first implementation, the integrity verification of the data to be verified is first performed according to the first verification information. Specifically, in S702, performing the integrity verification of the data to be verified according to at least one of the first verification information and the second verification information may include steps 4.1 to 4.3:

[0191] 4.1. Perform the integrity verification of the data to be verified according to the first verification information.

[0192] If the integrity verification of the data to be verified according to the first verification information fails, then execute 4.2.

[0193] If the integrity verification of the data to be verified according to the first verification information passes, then execute 4.3.

[0194] 4.2. Continue to perform the integrity verification of the data to be verified according to the second verification information.

[0195] If the integrity verification of the data to be verified according to the second verification information passes, then execute 4.3.

[0196] If the integrity verification of the data to be verified according to the second verification information fails, then stop the startup.

[0197] 4.3. Load and execute the data to be verified.

[0198] In the second implementation, the integrity verification of the data to be verified is first performed according to the second verification information. Specifically, in S702, performing the integrity verification of the data to be verified according to at least one of the first verification information and the second verification information may include steps 5.1 to 5.3:

[0199] 5.1. Perform the integrity verification of the data to be verified according to the second verification information.

[0200] If the integrity verification of the data to be verified according to the second verification information fails, then execute 5.2.

[0201] If the integrity verification of the data to be verified according to the second verification information passes, then execute 5.3.

[0202] 5.2. Continue to perform the integrity verification of the data to be verified according to the first verification information.

[0203] If the integrity verification of the data to be verified according to the first verification information passes, then execute 5.3.

[0204] If the integrity verification of the data to be verified according to the first verification information fails, then stop the startup.

[0205] 5.3. Load and execute the data to be verified.

[0206] Among them, in the first implementation manner and the second implementation manner, performing integrity verification on the data to be verified according to the second verification information may include:

[0207] Determine whether to directly load the data to be verified according to the secure boot policy.

[0208] If it is determined not to directly load the data to be verified and integrity verification of the data to be verified is required, then perform integrity verification on the data to be verified according to the first verification information or the second verification information.

[0209] If it is determined to directly load the data to be verified, then load and execute the data to be verified.

[0210] Specifically, according to different customization requirements of third-party integrators, there may be the following two scenarios during the secure boot process of the electronic device. The first scenario is that the data to be verified can be directly loaded to improve the loading speed. The second scenario is that the data to be verified needs to be subjected to integrity verification and is loaded and run only after the verification passes, to improve the running security. When it is determined to be the second scenario, then perform integrity verification on the data to be verified according to the first verification information or the second verification information. When it is determined to be the first scenario, then directly load and execute the data to be verified.

[0211] Before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information in S702 in the method for data integrity protection provided in this embodiment, it may further include:

[0212] Determine whether the second storage area is in a write-protected state.

[0213] If the second storage area is in a write-protected state, then perform the step of performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

[0214] Specifically, to prevent third-party integrators from forgetting to lock the second storage area, especially to prevent third-party integrators who do not require customization from forgetting to lock the second storage area, determine whether the second storage area is in a write-protected state before performing integrity verification on the data to be verified. If the second storage area is in a write-protected state, malicious attackers cannot tamper with the second verification information stored in the second storage area, and the operation of performing integrity verification on the data to be verified can continue.

[0215] The method for data integrity protection provided in this embodiment may further include:

[0216] If it is determined that the second storage area is not in a write-protected state, then perform a write-protection operation on the second storage area.

[0217] By performing a write protection operation on the second storage area, it is possible to prevent the second storage area from being maliciously tampered with, improving the security of the electronic device startup.

[0218] Among them, performing a write protection operation on the second storage area may include:

[0219] Generating a prompt message. The prompt message is used to indicate that the second storage area is not in a write-protected state.

[0220] Receiving a write protection instruction, which is used to indicate to perform write protection on the second storage area.

[0221] Performing a write protection operation on the second storage area according to the write protection instruction.

[0222] It should be noted that the implementation manner of the prompt message in this embodiment is not limited. Optionally, the prompt message may include any one of the following: text information or voice information.

[0223] In Figure 7 Based on the illustrated embodiment, in combination with Figure 4 and Figure 8 The method for data integrity protection provided by the embodiments of the present application is described through Example D. This example corresponds to the above Examples B and C. Figure 8 It is a schematic diagram of the principle of secure startup of the electronic device provided by the embodiments of the present application. In Figure 8Among them, the electronic device may include a chip 100, and the chip 100 may include a storage area 11, a ROM 12, and a storage area 13. Among them, the storage area 11 is the first storage area, and the storage area 13 is the second storage area. In this example, when the electronic device leaves the factory, the device manufacturer data includes: bootloader firmware, UEFI firmware, kernel software package, drivers, and hardware configuration information, all of which are digitally signed using the root private key A (i.e., the first root private key) provided by the device provider. After the electronic device leaves the factory, the third-party integrator modifies the UEFI firmware and drivers when the electronic device leaves the factory to form the second UEFI firmware and the second drivers respectively. Among them, the second UEFI firmware is digitally signed using the root private key C (i.e., the second root private key) provided by the third-party integrator, and the second drivers are not digitally signed. In this example, the second verification information is stored in the storage area 13 and includes a secure boot policy and a second trust root. The secure boot policy is used to indicate using the second verification information to perform an integrity check on the second UEFI firmware and can directly load the second drivers. The second trust root may include the hash value of the root public key C (i.e., the second root public key). The first verification information is stored in the storage area 11 and includes the hash value of the root public key A (i.e., the first root public key). Assume that during the integrity check process, first perform an integrity check on the data to be verified according to the first verification information. If the check fails, then perform an integrity check on the data to be verified according to the second verification information.

[0224] Example D

[0225] After the electronic device is powered on, the method for data integrity protection provided in this embodiment may include:

[0226] 6.1. Start from the boot code stored in the ROM 12 of the chip 100.

[0227] 6.2. The boot code reads the hash value of the root public key A provided by the device provider from the storage area 11.

[0228] The boot code reads the second verification information from the storage area 13.

[0229] 6.3. Obtain the data to be verified. The data to be verified includes: bootloader firmware and its corresponding signature information and certificate chain.

[0230] 6.4. First perform an integrity check on the data to be verified according to the first verification information.

[0231] Specifically, read the certificate chain corresponding to the bootloader firmware in the data packet a and parse out the root public key A. For ease of explanation, the parsed root public key A may be referred to as the root public key A”. The root public key A read from the storage area 11 may be referred to as the root public key A’.

[0232] Compare whether the hash value of the root public key A’ is the same as the hash value of the root public key A”. Assume that the hash value of the root public key A’ is the same as the hash value of the root public key A”, and the root public key A provided by the device provider has not been tampered with. Then, perform an integrity check on the bootloader firmware based on the root public key A’ or the root public key A”, and the signature information corresponding to the bootloader firmware.

[0233] Assume that the check passes, indicating that the bootloader firmware has not been tampered with. Then, load and execute the bootloader firmware.

[0234] 6.5. Obtain the data to be verified. The data to be verified includes: the second UEFI firmware and its corresponding signature information and certificate chain (integrity verification information).

[0235] 6.6. First, perform an integrity check on the data to be verified according to the first verification information.

[0236] Since the second UEFI firmware is digitally signed using the root private key C (i.e., the second root private key) provided by the third-party integrator, the check fails.

[0237] 6.7. Then, perform an integrity check on the data to be verified according to the second verification information.

[0238] According to the secure boot policy, it is determined that the second verification information needs to be used to perform an integrity check on the second UEFI firmware. Read the certificate chain corresponding to the second UEFI firmware in the data packet b’, and parse out the root public key C. For the sake of convenience, the parsed root public key can be referred to as the root public key C”. The root public key C read from the storage area 13 can be referred to as the root public key C’.

[0239] Compare whether the hash value of the root public key C’ is the same as the hash value of the root public key C”. Assume that the hash value of the root public key C’ is the same as the hash value of the root public key C”, and the root public key C provided by the third-party integrator has not been tampered with. Then, perform an integrity check on the second UEFI firmware based on the root public key C’ or the root public key C”, and the signature information corresponding to the second UEFI firmware.

[0240] Assume that the check passes, indicating that the second UEFI firmware has not been tampered with. Then, load and execute the second UEFI firmware.

[0241] 6.8. Obtain the data to be verified. The data to be verified includes: the kernel software package and its corresponding signature information and certificate chain.

[0242] 6.9. First, perform an integrity check on the data to be verified according to the first verification information.

[0243] Refer to the description in 6.4. The principle is similar and will not be elaborated here.

[0244] 6.10. Obtain the data to be verified. The data to be verified includes: the second driver.

[0245] 6.11. First, perform integrity verification on the data to be verified according to the first verification information.

[0246] Since the second driver is not digitally signed, the verification fails.

[0247] 6.12. Then, perform integrity verification on the data to be verified according to the second verification information.

[0248] If it is determined according to the secure boot policy that the second driver can be directly loaded, then directly load and execute the second driver.

[0249] 6.13. Obtain the data to be verified. The data to be verified includes: hardware configuration information and its corresponding signature information and certificate chain.

[0250] 6.14. First, perform integrity verification on the data to be verified according to the first verification information.

[0251] Reference can be made to the description in 6.4. The principle is similar and will not be elaborated here.

[0252] Figure 9 It is a schematic structural diagram of a device for data integrity protection provided by an embodiment of the present application. As Figure 9 shown, the device for data integrity protection provided by this embodiment can be applied to an electronic device. The electronic device stores device manufacturer data and first verification information. The first verification information is stored in the first storage area of the electronic device and is used to perform integrity verification on the device manufacturer data. The device includes:

[0253] An acquisition module 91, configured to acquire first data;

[0254] A processing module 92, configured to perform digital signature on the first data to generate second data and second verification information;

[0255] A storage module 93, configured to store the second data and the second verification information; wherein, the second verification information is stored in the second storage area of the electronic device.

[0256] Optionally, both the first storage area and the second storage area are one-time write storage areas.

[0257] Optionally, the first data includes the data after the third-party integrator modifies the device manufacturer data. The processing module 92 is specifically configured to:

[0258] Obtain the public-private key pair provided by the third-party integrator;

[0259] Digital-sign the first data using the private key in the public-private key pair to generate the second data and the second verification information;

[0260] Or,

[0261] Digital-sign the first data using the private key corresponding to the first verification information to generate the second data and the second verification information.

[0262] Optionally, the second verification information includes a secure boot policy and / or a root of trust; wherein, the secure boot policy is used to indicate the rules for performing integrity verification on the second data.

[0263] The apparatus for data integrity protection provided in this embodiment can execute the Figure 5 or Figure 6 data integrity protection method provided in the illustrated embodiment. The technical principles and technical effects are similar and will not be elaborated here.

[0264] Figure 10 Another structural schematic diagram of the apparatus for data integrity protection provided in an embodiment of the present application. As Figure 10 shown, the apparatus for data integrity protection provided in this embodiment may include:

[0265] An acquisition module 101, configured to acquire data to be verified, first verification information, and second verification information; the first verification information is stored in a first storage area of the electronic device, the second verification information is stored in a second storage area of the electronic device, and both the first storage area and the second storage area are one-time write storage areas;

[0266] A processing module 102, configured to perform integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

[0267] Optionally, the second verification information includes at least one of the following provided by a third-party integrator: a secure boot policy or a second root of trust; wherein, the secure boot policy is used to indicate the rules for performing integrity verification on the data to be verified.

[0268] Optionally, the processing module 102 is specifically configured to:

[0269] Determine whether to directly load the data to be verified according to the secure boot policy;

[0270] If it is determined not to directly load the data to be verified and integrity verification of the data to be verified is required, then perform integrity verification on the data to be verified according to the first verification information or the second verification information.

[0271] Optionally, the first verification information includes a first root of trust provided by a device provider, and the first root of trust includes a first root public key or a hash value of the first root public key.

[0272] Optionally, the processing module 102 is further configured to:

[0273] Before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information, determine that the second storage area is in a write-protected state.

[0274] The data integrity protection device provided in this embodiment can execute the Figure 7 data integrity protection method provided in the embodiments shown in this application. The technical principles and technical effects are similar and will not be elaborated here.

[0275] Figure 11 Another structural schematic diagram of the data integrity protection device provided in the embodiments of this application. As Figure 11 shown, the data integrity protection device provided in this embodiment may include a processor 1101 and a memory 1102. The memory 1102 is used to store instructions, and the processor 1101 is used to execute the instructions stored in the memory 1102, and is used to execute the Figures 5-7 data integrity protection method provided in any of the embodiments of this application. The technical principles and technical effects are similar and will not be elaborated here.

[0276] Figure 12 A structural schematic diagram of an electronic device provided in the embodiments of this application. As Figure 12 shown, the electronic device provided in this embodiment may include a processor 1201 and a memory 1202. The memory 1202 is used to store instructions, and the processor 1201 is used to execute the instructions stored in the memory 1202, and is used to execute the Figures 5-7 data integrity protection method provided in any of the embodiments of this application. The technical principles and technical effects are similar and will not be elaborated here.

[0277] It should be understood that the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, and can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of this application can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.

[0278] In the embodiments of the present application, the memory may be a non-volatile memory, such as a hard disk drive (HDD) or a solid-state drive (SSD), etc., or may also be a volatile memory, such as a random access memory (RAM). The memory is any medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory in the embodiments of the present application may also be a circuit or any other device capable of implementing a storage function, for storing program instructions and / or data.

Claims

1. A method for data integrity protection, characterized in that, applied to an electronic device, the electronic device stores device manufacturer data and first verification information, the first verification information is stored in a first storage area of the electronic device, and is used for integrity verification of the device manufacturer data. The method includes: Obtain first data; Perform digital signature on the first data to generate second data and second verification information; Store the second data and the second verification information; wherein, the second verification information is stored in a second storage area of the electronic device; Both the first storage area and the second storage area are one-time write storage areas; The first data includes data modified by a third-party integrator to the device manufacturer data. The performing digital signature on the first data to generate second data and second verification information includes: Obtain the public-private key pair provided by the third-party integrator; Perform digital signature on the first data according to the private key in the public-private key pair to generate the second data and the second verification information.

2. The method according to claim 1, characterized in that, The second verification information includes a secure boot policy and / or a root of trust; wherein, the secure boot policy is used to indicate the rules for integrity verification of the second data.

3. A method for data integrity protection, characterized in that, includes: Obtain data to be verified, first verification information and second verification information; wherein, the data to be verified includes firmware or software default when the electronic device leaves the factory, or, the data to be verified includes firmware or software customized by a third-party integrator after the electronic device leaves the factory, or, the data to be verified includes any combination of the default firmware or software in the electronic device and the firmware or software customized by the third-party integrator; the first verification information is stored in a first storage area of the electronic device and is used for integrity verification of the device manufacturer data, the second verification information is stored in a second storage area of the electronic device, both the first storage area and the second storage area are one-time write storage areas; the second verification information is generated by performing digital signature on first data according to the private key in the public-private key pair provided by the third-party integrator, and the first data includes the data modified by the third-party integrator to the device manufacturer data; Perform integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

4. The method according to claim 3, characterized in that, The second verification information includes at least one of the following provided by the third-party integrator: a secure boot policy or a root of trust; wherein, the secure boot policy is used to indicate the rules for integrity verification of the data to be verified.

5. The method according to claim 3 or 4, characterized in that, Before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information, it further includes: Determine that the second storage area is in a write protection state.

6. A device for data integrity protection, characterized in that, Applied to an electronic device, the electronic device stores device manufacturer data and first verification information, and the first verification information is stored in a first storage area of the electronic device for performing integrity verification on the device manufacturer data. The apparatus includes: An acquisition module, configured to acquire first data; A processing module, configured to perform digital signature on the first data to generate second data and second verification information; A storage module, configured to store the second data and the second verification information; wherein, the second verification information is stored in a second storage area of the electronic device; Both the first storage area and the second storage area are one-time write storage areas; The first data includes data modified by a third-party integrator to the device manufacturer data, and the processing module is specifically configured to: Acquire a public-private key pair provided by the third-party integrator; Perform digital signature on the first data according to the private key in the public-private key pair to generate the second data and the second verification information.

7. The apparatus according to claim 6, wherein, The second verification information includes a secure boot policy and / or a root of trust; wherein, the secure boot policy is used to indicate rules for performing integrity verification on the second data.

8. An apparatus for data integrity protection, wherein, includes: An acquisition module, configured to acquire data to be verified, first verification information, and second verification information; wherein, the data to be verified includes firmware or software default when the electronic device leaves the factory, or, the data to be verified includes firmware or software customized by a third-party integrator after the electronic device leaves the factory, or, the data to be verified includes any combination of the default firmware or software in the electronic device and the firmware or software customized by the third-party integrator; the first verification information is stored in a first storage area of the electronic device for performing integrity verification on the device manufacturer data, the second verification information is stored in a second storage area of the electronic device, both the first storage area and the second storage area are one-time write storage areas; the second verification information is generated by performing digital signature on first data according to the private key in a public-private key pair provided by a third-party integrator, and the first data includes data modified by the third-party integrator to the device manufacturer data; A processing module, configured to perform integrity verification on the data to be verified according to at least one of the first verification information and the second verification information.

9. The apparatus according to claim 8, wherein, The second verification information includes at least one of the following provided by a third-party integrator: a secure boot policy or a root of trust; wherein, the secure boot policy is used to indicate rules for performing integrity verification on the data to be verified.

10. The apparatus according to claim 8 or 9, wherein, The processing module is further configured to: Before performing integrity verification on the data to be verified according to at least one of the first verification information and the second verification information, determine that the second storage area is in a write-protected state.

11. An electronic device, wherein, It includes a processor and a memory, and the processor is used to call a program stored in the memory to execute the method according to any one of claims 1-5.

Images