Block verification method and device, electronic equipment, medium and product

Abstract

The invention provides a block verification method and device, electronic equipment, a medium and a product, and relates to the field of security verification. The block verification method comprises the steps of obtaining first verification starting metadata of a first to-be-verified partition and second verification starting metadata of a second to-be-verified partition, wherein the partition size of the second to-be-verified partition is larger than that of the first to-be-verified partition; based on the first verification starting metadata, performing first verification on the security of the first to-be-verified partition; in response to a verification result of the first verification, determining a starting data set of the second to-be-verified partition; and performing second verification on the second to-be-verified partition based on the startup data set and the second verification startup metadata. According to the method disclosed by the invention, the start data set of the second to-be-verified partition is determined by responding to the verification result of the first verification, so that the start data set is acquired in real time, the second to-be-verified partition is verified in real time, and the real-time security of the second to-be-verified partition is improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the field of security verification, and particularly relates to a block verification method and device, electronic equipment, medium and product. BACKGROUND

[0002] In related technologies, to prevent maliciously tampered partitions from being loaded in the system startup process, a kernel command line (kernel cmdline) stored before verification is usually used to perform partition verification on the system partition. However, this method cannot guarantee whether the partition is maliciously tampered during the verification process. SUMMARY

[0003] The present disclosure provides a block verification method, device, electronic equipment, medium and product to ensure the real-time security of the to-be-verified partition and improve the security of the to-be-verified partition.

[0004] A first aspect of the present disclosure provides a block verification method, which includes: obtaining first verification startup metadata of a first to-be-verified partition and second verification startup metadata of a second to-be-verified partition, the partition size of the second to-be-verified partition being greater than the partition size of the first to-be-verified partition; performing first verification on the security of the first to-be-verified partition based on the first verification startup metadata; determining a startup data set of the second to-be-verified partition in response to the verification result of the first verification; and performing second verification on the second to-be-verified partition based on the startup data set and the second verification startup metadata.

[0005] In some embodiments of the present disclosure, performing first verification on the security of the first to-be-verified partition based on the first verification startup metadata includes: calculating a first calculated hash value of the first to-be-verified partition based on the first verification startup metadata; finding a first stored hash value of the first to-be-verified partition based on the first verification startup metadata; and comparing the first calculated hash value and the first stored hash value to perform first verification on the security of the first to-be-verified partition.

[0006] In some embodiments of the present disclosure, determining the startup data set of the second to-be-verified partition in response to the verification result of the first verification includes: determining a data offset of the second verification startup metadata in response to the verification result of the first verification; determining a second calculated hash value of the second verification startup metadata and a salt value corresponding to the second calculated hash value based on the second verification startup metadata and the data offset; determining a parameter mapping table of the second to-be-verified partition based on the second verification startup metadata; and determining the startup data set based on the parameter mapping table, the second calculated hash value and the salt value.

[0007] In some embodiments of the present disclosure, determining the second calculated hash value of the second verification startup metadata and the salt value corresponding to the second calculated hash value based on the second verification startup metadata and the data offset includes:

[0008] based on the data address and the data offset of the second verification start metadata, a storage address of the storage salt value is calculated to determine the salt value; based on the salt value, a second calculated hash value corresponding to the salt value is determined.

[0009] In some embodiments of the present disclosure, based on the parameter mapping table, the second calculated hash value and the salt value, the start data set is determined by splicing the second calculated hash value and the salt value with the parameter mapping table by using a preset splicing function.

[0010] In some embodiments of the present disclosure, based on the start data set and the second verification start metadata, the second verification of the second to-be-verified partition includes: based on the start data set, a third calculated hash value of a first block of the second to-be-verified partition is calculated, the first block being a partial partition of the second to-be-verified partition; based on the second verification start metadata, a second stored hash value of the first block of the second to-be-verified partition is found; and the third calculated hash value and the second stored hash value are compared to perform the second verification on the security of the second to-be-verified partition.

[0011] The second aspect embodiment of the present disclosure provides a block verification device, which comprises: an acquisition module configured to acquire first verification start metadata of a first to-be-verified partition and second verification start metadata of a second to-be-verified partition, the partition size of the second to-be-verified partition being greater than the partition size of the first to-be-verified partition; a first verification module configured to perform a first verification on the security of the first to-be-verified partition based on the first verification start metadata; a processing module configured to determine a start data set of the second to-be-verified partition in response to a verification result of the first verification; and a second verification module configured to perform a second verification on the second to-be-verified partition based on the start data set and the second verification start metadata.

[0012] The third aspect embodiment of the present disclosure provides an electronic device, which comprises: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of the first aspect embodiments of the present disclosure.

[0013] The fourth aspect embodiment of the present disclosure provides a non-transitory computer readable storage medium storing computer instructions, characterized in that the computer instructions are used to enable a computer to perform the method in the first aspect embodiment of the present disclosure.

[0014] The fifth aspect embodiment of the present disclosure provides a computer program product, characterized in that the computer program product comprises a computer program, and the computer program is executed by a processor to implement the method in any one of the first aspect embodiments of the present disclosure.

[0015] In summary, the block verification method proposed in the present disclosure includes: obtaining first verification startup metadata for a first partition to be verified and second verification startup metadata for a second partition to be verified, where the partition size of the second partition to be verified is larger than the partition size of the first partition to be verified; performing a first verification on the security of the first partition to be verified based on the first verification startup metadata; determining a startup data set for the second partition to be verified in response to the verification result of the first verification; and performing a second verification on the second partition to be verified based on the startup data set and the second verification startup metadata. The method disclosed herein determines the startup data set for the second partition to be verified in response to the verification result of the first verification, thereby achieving real-time acquisition of the startup data set and performing real-time verification on the second partition to be verified, thereby improving the real-time security of the second partition to be verified.

[0016] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings herein are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the description are used to explain the principles of the present disclosure, and do not constitute an improper limitation of the present disclosure.

[0018] Figure 1 This is a flowchart of a block verification method according to an embodiment of the present disclosure;

[0019] Figure 2 is a flow chart of another block verification method according to an embodiment of the present disclosure;

[0020] Figure 3 This is a schematic structural diagram of a block verification device according to an embodiment of the present disclosure;

[0021] Figure 4 It is a block diagram of an electronic device for implementing the block check method disclosed herein according to an exemplary embodiment. DETAILED DESCRIPTION

[0022] The following describes in detail embodiments of the present disclosure, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout identify the same or similar components or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present disclosure, and should not be construed as limiting the present disclosure.

[0023] In the field of security verification, in related technologies, in order to prevent maliciously tampered partitions from being loaded during system startup, the system partition is usually verified using the kernel execution command line (kernel cmdline) stored before verification. However, this method cannot guarantee whether the partition has been maliciously tampered with during the verification process.

[0024] The present disclosure aims to guarantee the real-time safety of the to-be-verified partition, thereby further improving the safety of the to-be-verified partition.

[0025] The method provided by the present disclosure can be widely applied to code development and maintenance in aspects of vehicle driving, vehicle auxiliary driving, unmanned driving, and vehicle electronic control. The application scenarios are not limited in the embodiments of the present disclosure.

[0026] First, the encryption mode of the system partition is introduced as follows:

[0027] 1. In the Boot image encryption, the data information of the verification boot metadata (vbmeta) is mainly added at the tail of the original image to encrypt the Boot image. The hash value of the image, the data for signing the hash value, and the public key information are mainly stored in the vbmeta data information. The signature is performed in a cloud signature manner, which aims to guarantee the safety of the signature process and prevent illegal personnel from obtaining the local private key to sign the non-safe image.

[0028] 2. In the Rootfs image encryption process, the data information of the vbmeta is also needed, but there is a data content of the hash tree before the vbmeta information. After the U-Boot successfully verifies the integrity of the Boot image, the Boot image will execute the kernel code. In the kernel stage, the root partition and other large partitions will be mounted. If the hash is directly calculated, it will be particularly time-consuming, and the integrity of the partition cannot be continuously guaranteed. Therefore, the hash tree of the partition image is calculated in the compilation stage. The large partition needs to be divided into blocks with a size of 4k in the compilation stage, and the hash value of each block is calculated. These hash values are combined in a tree structure, which is the hash tree. Each node in the hash tree is a hash value. The hash value of the leaf node is the hash value of the corresponding block. The value of the intermediate node is the sum of the hash values of all child nodes.

[0029] 3. All the image data that needs to be encrypted is stored in a vbmeta image and encrypted to avoid the problem of tampering with a single image. For example, if the boot.img file is modified and burned to the specified partition, but the information about the boot partition in the vbmeta partition does not match the calculation in the original boot.img file, it can also prove that the image is tampered with.

[0030] As described above, the whole compilation phase needs to do things, mainly is the encryption data of native image is placed in the tail of the image, and then use a footer to tell the developer how to find the encrypted data in the vbmeta. If it is a small image, such as boot image can be directly calculated hash, if it is a large image, such as rootfs image needs to calculate hash tree. At the same time, all image data is summarized to vbmeta partition and the partition is also encrypted.

[0031] The block verification method provided by the present application will be described in detail below with reference to the accompanying drawings.

[0032] Figure 1 A flowchart of a block verification method according to an embodiment of the present disclosure. As shown in the embodiment, the block verification method comprises: Figure 1

[0033] Step 101, obtaining first verification startup metadata of a first to-be-verified partition and second verification startup metadata of a second to-be-verified partition.

[0034] In some embodiments, the partition size of the second to-be-verified partition is greater than the partition size of the first to-be-verified partition.

[0035] In some embodiments, the first to-be-verified partition can be a small partition in the system such as Boot partition, Vbmeta partition, etc.; and the second to-be-verified partition can be a large partition in the system such as Rootfs partition, APP partition, etc.

[0036] In other words, the first to-be-verified partition can be a partition that needs to be verified in the U-Boot startup phase in system startup, and the second to-be-verified partition can be a partition that needs to be verified in the kernle phase.

[0037] In some embodiments, the first verification startup metadata can be a vbmeta image file of the first to-be-verified partition, and the second verification startup metadata can be a vbmeta image file of the second to-be-verified partition.

[0038] Step 102, performing first verification on the security of the first to-be-verified partition based on the first verification startup metadata.

[0039] In some embodiments, based on the first verification startup metadata, it can be determined whether the hash values of the first to-be-verified partition before and after system startup change, so as to judge whether the first to-be-verified partition is tampered with, thereby realizing the first verification on the security of the first to-be-verified partition.

[0040] ​Specifically, the first verification startup metadata stores a hash value of the first to-be-verified partition before the system, i.e., a first stored hash value; and at the system startup, a hash value of the first to-be-verified partition at the system startup can be determined based on parameter information in the first verification startup metadata, i.e., a first calculated hash value; and then the security of the first to-be-verified partition is determined by comparing the first calculated hash value and the first stored hash value.

[0041] At step 103, the startup data set of the second to-be-verified partition is determined in response to the verification result of the first verification.

[0042] In some embodiments, when the first verification ends, the second to-be-verified partition can be verified by determining the startup data set of the second to-be-verified partition.

[0043] For example, after the first verification ends, the verity-table data (i.e., the startup data set) corresponding to the partition that needs to be verified is obtained and passed into the kernel command line (kernel cmdline) to verify the second to-be-verified partition at the kernel stage.

[0044] In some embodiments, the data offset of the second verification startup metadata can be determined in response to the verification result of the first verification to obtain the salt value of the second to-be-verified partition and the second calculated hash value corresponding to the salt value in real time; and the salt value and the second calculated hash value corresponding to the salt value are spliced with the parameter mapping table in the second verification startup metadata for indicating the parameters of the second to-be-verified partition, and the spliced result is determined as the startup data set of the second to-be-verified partition, so as to realize real-time data acquisition.

[0045] For specific determination methods of the startup data set, refer to the embodiments shown in Figure 2 and will not be described here again.

[0046] At step 104, the second to-be-verified partition is verified based on the startup data set and the second verification startup metadata.

[0047] In some embodiments, the second verification startup metadata stores a hash value of the second to-be-verified partition in the hash tree before the system startup (i.e., in the encryption process), i.e., a second stored hash value.

[0048] In some embodiments, since the second to-be-verified partition is a large partition, the hash value calculation amount of the second to-be-verified partition at the system startup is large, and therefore the hash values of each block of the second to-be-verified partition divided at the encryption time (i.e., a third calculated hash value) can be calculated by using the method described in the encryption process, so as to determine the security of the first to-be-verified partition by comparing the third calculated hash value and the second stored hash value.

[0049] In summary, the block verification method proposed in this disclosure includes: in response to a modification request for a function file, obtaining a modification variable corresponding to the modification request; matching the modification function corresponding to the modification variable from a preset database; generating a modification code file for the function file based on the modification function; and executing the modification code file to modify the function file. The technical solution provided by this disclosure, by matching the modification function corresponding to the modification variable from a preset database, can generate corresponding code files based on different modification requests, expanding the scope of application of the block verification method and improving the efficiency of project development and maintenance.

[0050] Figure 2 This is a flow chart of a block verification method according to an embodiment of the present disclosure. Figure 1 The embodiment shown is further explained as Figure 2 In the illustrated embodiment, the block verification method includes:

[0051] Step 201: Obtain first verification and startup metadata of a first partition to be verified and second verification and startup metadata of a second partition to be verified.

[0052] In this disclosure, the principle of step 201 is the same as Figure 1 The step 101 in the embodiment shown is the same as that in the embodiment shown. Figure 1 The relevant description will not be repeated here.

[0053] Step 202: Calculate a first calculated hash value of a first partition to be verified based on the first verification startup metadata.

[0054] In some embodiments, the first verified boot metadata is, for example, a vbmeta file in the first partition to be verified.

[0055] In some embodiments, a hash algorithm may be used to take the first verification startup metadata as an algorithm input to calculate a first calculated hash value, wherein the hash algorithm used is, for example, SHA-256, etc., which is not limited in this disclosure.

[0056] Step 203: Find the first stored hash value of the first partition to be verified based on the first verification startup metadata.

[0057] In some embodiments, the first stored hash value, the corresponding public key, and the hash signature may be stored in the first verified boot metadata, and the first stored hash value in the first verified boot metadata may be searched using a private key corresponding to the public key.

[0058] The public key of the first verification startup metadata may be generated using the RSA4096 algorithm, but is not limited thereto and is not limited in this disclosure.

[0059] Step 204 : Compare the first calculated hash value with the first stored hash value to perform a first verification on the security of the first partition to be verified.

[0060] In some embodiments, the security of the first partition to be verified may be first verified by comparing the first calculated hash value with the first stored hash value.

[0061] Specifically, when the first calculated hash value is consistent with the first stored hash value, it indicates that the first partition to be verified has not been tampered with, and when the first calculated hash value is inconsistent with the first stored hash value, it indicates that the first partition to be verified has been tampered with, and there is a security risk in the system.

[0062] Step 205 : Determine a data offset of the second verification start metadata in response to the verification result of the first verification.

[0063] In some embodiments, after the first verification is completed, verification of the second partition to be verified is started to implement verification of the large partition in the system.

[0064] In some embodiments, the footer corresponding to the second verification startup metadata can indicate the data size of the second verification startup metadata, the data offset of the second verification startup metadata, and the size of the second partition to be verified corresponding to the second verification startup metadata, and the footer and the second verification startup metadata are stored in a group in the replacement file (img) of the partition to be verified, so the data offset of the second verification startup metadata can be determined through the above footer.

[0065] Step 206 : Determine a second calculated hash value of the second verified startup metadata and a salt value corresponding to the second calculated hash value based on the second verified startup metadata and the data offset.

[0066] In some embodiments, a storage address storing a salt value can be calculated based on the data address and data offset of the second verification start metadata to determine a salt value, wherein the salt value is a randomly generated string of characters used to enhance the cryptographic security of the corresponding second hash value.

[0067] In other words, the offset address of the second verification and enable metadata may be determined by adding the data address and the data offset of the second verification and enable metadata, and the salt value is stored in the offset address.

[0068] Then, based on the salt value, a second calculated hash value corresponding to the salt value is determined. It should be understood that the salt value corresponds to the hash value, so after the salt value is determined, the second calculated hash value corresponding to the salt value can be determined based on the salt value.

[0069] Step 207, determining the parameter mapping table of the second to-be-verified partition based on the second verification starting metadata.

[0070] In some embodiments, in the encryption process, the related parameters of the second to-be-verified partition can be stored in the parameter mapping table, and the parameter mapping table is associated with the second verification starting metadata corresponding to the second to-be-verified partition. Therefore, in the verification stage, the parameter mapping table of the second to-be-verified partition can be found through the second verification starting metadata to obtain the related information of the second to-be-verified partition.

[0071] In some embodiments, the parameter mapping table can include the partition size of the second to-be-verified partition, the partition block (for example, the first block) of the second to-be-verified partition, the hash value (for example, the second stored hash value) of the second to-be-verified partition, and the like.

[0072] Step 208, determining the starting data set based on the parameter mapping table, the second calculated hash value and the salt value.

[0073] In some embodiments, the second calculated hash value and the salt value can be spliced with the parameter mapping table by using a preset splicing function to determine the starting data set, so as to realize the dynamic acquisition of the starting data set, wherein the preset splicing function is, for example, a strcat function, a strncat function, and the like, and the present disclosure is not limited thereto.

[0074] Step 209, calculating the third calculated hash value of the first block of the second to-be-verified partition based on the starting data set.

[0075] In some embodiments, the first block can be one block divided in the encryption process of the second to-be-verified partition, or can be multiple blocks divided in the encryption process of the second to-be-verified partition, and the present disclosure is not limited thereto.

[0076] In some embodiments, the third calculated hash value of the first block can be determined by using a hash algorithm through the related data (for example, the size of the first block and the data in the first block) of the first block in the starting data set, and the present disclosure is not limited to the hash algorithm used.

[0077] Step 210, finding the second stored hash value of the first block of the second to-be-verified partition based on the second verification starting metadata.

[0078] In the present disclosure, the principle of step 210 is the same as that of step 203, and the related description of step 203 can be referred to, which will not be repeated here.

[0079] Step 211, comparing the third calculated hash value and the second stored hash value to perform the second verification on the security of the second to-be-verified partition.

[0080] In some embodiments, the third calculated hash value can be compared with the second stored hash value to determine whether each first block of the second to-be-verified partition is tampered with, so as to achieve the second verification of the security of the second to-be-verified partition.

[0081] Specifically, when the third calculated hash value is consistent with the second stored hash value, it indicates that the first block is not tampered with, and when the third calculated hash value is inconsistent with the second stored hash value, it indicates that the first block is tampered with, i.e., the second to-be-verified partition is tampered with, and the system has a security risk.

[0082] In summary, the block verification method provided by the embodiments of the present disclosure includes: obtaining first verification start metadata of a first to-be-verified partition and second verification start metadata of a second to-be-verified partition, the partition size of the second to-be-verified partition being greater than the partition size of the first to-be-verified partition; calculating a first calculated hash value of the first to-be-verified partition based on the first verification start metadata; finding a first stored hash value of the first to-be-verified partition based on the first verification start metadata; comparing the first calculated hash value with the first stored hash value to perform a first verification of the security of the first to-be-verified partition; determining a data offset of the second verification start metadata in response to a verification result of the first verification; determining a second calculated hash value of the second verification start metadata and a salt value corresponding to the second calculated hash value based on the second verification start metadata and the data offset; determining a parameter mapping table of the second to-be-verified partition based on the second verification start metadata; determining a start data set based on the parameter mapping table, the second calculated hash value and the salt value; calculating a third calculated hash value of a first block of the second to-be-verified partition based on the start data set, the first block being a partial partition of the second to-be-verified partition; finding a second stored hash value of the first block of the second to-be-verified partition based on the second verification start metadata; and comparing the third calculated hash value with the second stored hash value to perform a second verification of the security of the second to-be-verified partition. The method of the present disclosure determines the second calculated hash value and the salt value corresponding to the second calculated hash value in real time by using the data offset after determining the first verification result, thereby realizing real-time acquisition of the modified data set to ensure the real-time security of the to-be-verified partition, and improving the security of the to-be-verified partition.

[0083] Therefore, the present disclosure has the following beneficial effects:

[0084] 1. In response to the verification result of the first verification, the start data set of the second to-be-verified partition is determined, thereby realizing real-time acquisition of the start data set to perform real-time verification on the second to-be-verified partition, thereby improving the real-time security of the second to-be-verified partition.

[0085] Corresponding to the method provided in the above embodiments, the disclosure also provides a block verification device. Since the device provided in the embodiments of the disclosure corresponds to the method provided in the above embodiments, the implementation of the method is also applicable to the device provided in the embodiments, which will not be described in detail in the embodiments.

[0086] Figure 3 A structural schematic diagram of a block verification device 300 according to an embodiment of the disclosure. As shown in the figure, the block verification device includes: Figure 3

[0087] The acquisition module 310 is configured to acquire first verification start metadata of a first to-be-verified partition and second verification start metadata of a second to-be-verified partition, the size of the second to-be-verified partition being greater than the size of the first to-be-verified partition.

[0088] The first verification module 320 is configured to perform first verification on the security of the first to-be-verified partition based on the first verification start metadata.

[0089] The processing module 330 is configured to determine a start data set of the second to-be-verified partition in response to the verification result of the first verification.

[0090] The second verification module 340 is configured to perform second verification on the second to-be-verified partition based on the start data set and the second verification start metadata.

[0091] In some embodiments, the first verification module 320 is further configured to: calculate a first calculated hash value of the first to-be-verified partition based on the first verification start metadata; find a first stored hash value of the first to-be-verified partition based on the first verification start metadata; and compare the first calculated hash value with the first stored hash value to perform the first verification on the security of the first to-be-verified partition.

[0092] In some embodiments, the processing module 330 is further configured to: determine a data offset of the second verification start metadata in response to the verification result of the first verification; determine a second calculated hash value of the second verification start metadata and a salt value corresponding to the second calculated hash value based on the second verification start metadata and the data offset; determine a parameter mapping table of the second to-be-verified partition based on the second verification start metadata; and determine the start data set based on the parameter mapping table, the second calculated hash value, and the salt value.

[0093] In some embodiments, the processing module 330 is further configured to: calculate a storage address of the salt value based on a data address and the data offset of the second verification start metadata to determine the salt value; and determine the second calculated hash value corresponding to the salt value based on the salt value.

[0094] ​In some embodiments, the processing module 330 is further configured to concatenate the second calculated hash value and the salt value with the parameter mapping table using a preset concatenation function to determine the startup data set.

[0095] In some embodiments, the second verification module 340 is further configured to calculate a third calculated hash value of a first block of the second to-be-verified partition based on the startup data set, the first block being a partial partition of the second to-be-verified partition; find a second stored hash value of the first block of the second to-be-verified partition based on the second verification startup metadata; and compare the third calculated hash value with the second stored hash value to perform a second verification on the security of the second to-be-verified partition.

[0096] In summary, the block verification apparatus includes an acquisition module configured to acquire first verification startup metadata of a first to-be-verified partition and second verification startup metadata of a second to-be-verified partition, the second to-be-verified partition having a larger partition size than the first to-be-verified partition; a first verification module configured to perform a first verification on the security of the first to-be-verified partition based on the first verification startup metadata; a processing module configured to determine a startup data set of the second to-be-verified partition in response to a verification result of the first verification; and a second verification module configured to perform a second verification on the second to-be-verified partition based on the startup data set and the second verification startup metadata. The apparatus provided by the present disclosure determines the startup data set of the second to-be-verified partition in response to the verification result of the first verification, thereby realizing real-time acquisition of the startup data set to perform real-time verification on the second to-be-verified partition, and improving the real-time security of the second to-be-verified partition.

[0097] The above-described embodiments of the present application provide methods and apparatuses. To implement the functions in the above-described embodiments of the present application, an electronic device can include hardware structures, software modules, or a combination of hardware structures and software modules to implement the above-described functions. Some of the above-described functions can be implemented in the form of hardware structures, software modules, or hardware structures and software modules.

[0098] Figure 4 FIG. 4 is a block diagram of an electronic device 400 for implementing the above-described block verification method according to an exemplary embodiment.

[0099] For example, the electronic device 400 can be a mobile phone, a computer, a messaging device, a game console, a tablet device, a medical device, a fitness device, a personal digital assistant, etc.

[0100] Reference is made to Figure 4The electronic device 400 can include one or more of the following components: a processing component 402, a memory 404, a power supply component 406, a multimedia component 408, an audio component 410, an input / output (I / O) interface 412, a sensor component 414, and a communication component 416.

[0101] The processing component 402 typically controls overall operations of the electronic device 400, such as operations associated with display, phone calls, data communications, camera operations, and recording operations. The processing component 402 can include one or more processors 420 to execute instructions to complete all or part of steps of the above methods. In addition, the processing component 402 can include one or more modules to facilitate

[0102] The memory 404 is configured to store various types of data to support operations of the electronic device 600. Examples of these data include instructions for any application or method operating on the electronic device 400, contact data, phonebook data, messages, pictures, videos, and the like. The memory 404 can be realized by any type of volatile or non-volatile memory device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disc, or optical disc.

[0103] The power supply component 406 supplies electrical power for the various components of the electronic device 400. The power supply component 406 can include a power supply management system, one or more power supplies, and other components associated with generating, managing, and distributing electrical power for the electronic device 400.

[0104] The multimedia component 408 includes a screen to provide an output interface between the electronic device 400 and a user. In some embodiments, the screen can include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, swiping, and gestures on the touch panel. The touch sensor can not only sense a boundary of a touching or swiping action, but also detect duration and pressure related to the touching or swiping action. In some embodiments, the multimedia component 408 includes a front camera and / or a rear camera. When the electronic device 400 is in an operation mode, such as a camera mode or a video mode, the front camera and / or the rear camera can receive external multimedia data. Each of the front camera and the rear camera can be a fixed optical lens system or have a focal length and optical zoom capability.

[0105] The audio component 410 is configured to output and / or input audio signals. For example, the audio component 410 includes a microphone (MIC) to receive external audio signals when the electronic device 400 is in an operation mode, such as a call mode, a recording mode, and a voice recognition mode. The received audio signals can be further stored in the memory 404 or transmitted via the communication component 416. In some embodiments, the audio component 410 also includes a speaker to output audio signals.

[0106] The I / O interface 412 provides an interface for the processing component 402 and peripheral interface modules, which can be a keypad, a click wheel, buttons, and the like. The buttons can include, but are not limited to, a home button, a volume button, a start button, and a lock button.

[0107] The sensor component 414 includes one or more sensors to provide various state assessments for the electronic device 400. For example, the sensor component 414 can detect an open / closed state of the electronic device 400, relative positioning of components, such as a display and a keypad of the electronic device 400, a change in position of the electronic device 400 or a component of the electronic device 400, presence or absence of user contact with the electronic device 400, an orientation or acceleration / deceleration of the electronic device 400, and a temperature change of the electronic device 400. The sensor component 414 can include a proximity sensor configured to detect presence of a nearby object without any physical touch. The sensor component 414 can further include a light sensor such as a CMOS or CCD image sensor for use in an imaging application. In some embodiments, the sensor component 414 can further include an acceleration sensor, a gyroscope sensor, a magnetic sensor, a pressure sensor, or a temperature sensor.

[0108] The communication component 416 is configured to facilitate wired or wireless communication between the electronic device 400 and other devices. The electronic device 400 can access a wireless network based on a communication standard, such as WiFi, 2G or 3G, 4G LTE, 5G NR (New Radio), or a combination thereof. In an example embodiment, the communication component 416 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an example embodiment, the communication component 416 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on Radio Frequency Identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technology.

[0109] In an example embodiment, the electronic device 400 can be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, micro-controllers, microprocessors, or other electronic elements, for performing the above-described methods.

[0110] In an example embodiment, a non-transitory computer-readable storage medium including instructions, such as the memory 404 including instructions, is also provided, which can be executed by the processor 420 of the electronic device 400 to complete the above-described methods. For example, the non-transitory computer-readable storage medium can be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disc, and an optical data storage device, etc.

[0111] Embodiments of the present disclosure also provide a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to make a computer execute the block verification method described in the above embodiments of the present disclosure.

[0112] Embodiments of the present disclosure also provide a computer program product including a computer program, which, when executed by a processor, performs the block verification method described in the above embodiments of the present disclosure.

[0113] It should be noted that the terms "first", "second", and the like in the description and claims of the present disclosure and the above-described drawings are used to distinguish similar objects, and do not necessarily indicate a specific order or sequence. It should be understood that the data thus used can be interchanged under appropriate circumstances, so that the embodiments of the present disclosure described herein can be implemented in other than the order illustrated or described herein. The implementations described in the following example embodiments are not meant to represent all implementations consistent with the present disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0114] In the description of the specification, the description of the terms "one embodiment", "some embodiments", "certain embodiments", "an example", "a specific example" or "some examples" etc. means that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present disclosure. In the specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Also, the specific features, structures, materials or characteristics described can be combined in any one or more embodiments or examples in a suitable manner.

[0115] Any process or method descriptions or descriptions of the flow diagrams in the specification or elsewhere in this document, can be understood as representing the steps of any one or more of the methods or processes, including a code segment or portion of code and / or a computer program product comprising executable instructions for performing the steps, and the scope of preferred embodiments of the present disclosure includes additional implementation involving other processes or methods that can be performed according to the description, as will be understood by those skilled in the art. Although the processes or methods described in the specification or elsewhere in this document, or in the flow diagrams, can be understood as representing the steps of any one or more of the methods or processes, the steps as described are equally applicable to corresponding steps of other methods or processes described or otherwise suggested in the specification or elsewhere in this document, and the scope of preferred embodiments of the present disclosure includes additional implementation involving other methods or processes that can be performed according to the description, as will be understood by those skilled in the art.

[0116] The logic and / or steps represented in the flow diagrams or otherwise described in this document, for example, can be considered as a list of steps for implementing the logic function, and can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor- containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions, or in conjunction with which the instructions may be executed. For purposes of this specification, a "computer-readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable medium include the following: an electrical connection having one or more wires (control method), a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, and a portable compact disc read-only memory (CDROM). In addition, the computer-readable medium can even be paper or another suitable medium upon which the program can be printed, because the program can be electronically captured, for example, by optically scanning the paper or other suitable medium, then electronically converted into a form that can be further processed by the instruction execution system, apparatus, or device, and stored in the computer memory. The computer program product or computer-readable medium can be a computer program product or a computer-readable medium that is capable of carrying or containing the program for use by or in connection with the instruction execution system, apparatus, or device.

[0117] It should be understood that parts of the embodiments of the present disclosure can be realized by hardware, software, firmware, or a combination thereof. In the above-described embodiments, a plurality of steps or methods can be realized by software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if realized by hardware, and as in another embodiment, any one or a combination of the following technologies known in the art can be used: discrete logic circuit having logic gates for implementing logic functions on data signals, application specific integrated circuit having appropriate combinational logic gates, programmable gate array (PGA), field programmable gate array (FPGA), etc.

[0118] Those skilled in the art of the present technology can understand that all or part of the steps carried out by the above-mentioned embodiment method can be completed by a program instructing the relevant hardware, and the program can be stored in a computer readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0119] In addition, each functional unit in each embodiment of the present disclosure can be integrated into one processing module, or each unit can exist physically independently, or two or more units can be integrated into one module. The integrated module can be realized in the form of hardware or in the form of a software functional module. The integrated module, if realized in the form of a software functional module and sold or used as an independent product, can also be stored in a computer readable storage medium. The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc.

[0120] Although the embodiments of the present disclosure have been shown and described above, it should be understood that the above-described embodiments are exemplary and should not be construed as limiting the present disclosure, and those skilled in the art can make changes, modifications, replacements and variations to the above-described embodiments within the scope of the present disclosure.

Claims

1. A block check method, comprising: The method comprises: obtaining first verification start metadata of a first to-be-verified partition and second verification start metadata of a second to-be-verified partition, the size of the second to-be-verified partition being greater than the size of the first to-be-verified partition; based on the first verification start metadata, performing first verification on the security of the first to-be-verified partition; in response to the verification result of the first verification, determining a start data set of the second to-be-verified partition; based on the start data set and the second verification start metadata, performing second verification on the second to-be-verified partition.

2. The method of claim 1, wherein, The first verification on the security of the first to-be-verified partition based on the first verification start metadata comprises: based on the first verification start metadata, calculating a first calculated hash value of the first to-be-verified partition; based on the first verification start metadata, finding a first stored hash value of the first to-be-verified partition; comparing the first calculated hash value and the first stored hash value to perform first verification on the security of the first to-be-verified partition.

3. The method of claim 1, wherein, The determination of the start data set of the second to-be-verified partition in response to the verification result of the first verification comprises: in response to the verification result of the first verification, determining a data offset of the second verification start metadata; based on the second verification start metadata and the data offset, determining a second calculated hash value of the second verification start metadata and a salt value corresponding to the second calculated hash value; based on the second verification start metadata, determining a parameter mapping table of the second to-be-verified partition; based on the parameter mapping table, the second calculated hash value and the salt value, determining the start data set.

4. The method of claim 3, wherein, The determination of the second calculated hash value of the second verification start metadata and the salt value corresponding to the second calculated hash value based on the second verification start metadata and the data offset comprises: based on the data address of the second verification start metadata and the data offset, calculating a storage address of the salt value to determine the salt value; based on the salt value, determining a second calculated hash value corresponding to the salt value.

5. The method of claim 3, wherein, The determination of the start data set based on the parameter mapping table, the second calculated hash value and the salt value comprises: using a preset splicing function to splice the second calculated hash value and the salt value with the parameter mapping table to determine the start data set.

6. The method of claim 1, wherein, The second verification on the second to-be-verified partition based on the start data set and the second verification start metadata comprises: based on the start data set, calculating a third calculated hash value of a first block of the second to-be-verified partition, the first block being a partial partition of the second to-be-verified partition; based on the second verification start metadata, finding a second stored hash value of the first block of the second to-be-verified partition; comparing the third calculated hash value and the second stored hash value to perform second verification on the security of the second to-be-verified partition.

7. A block check device, characterized by The device comprises: The acquisition module is configured to acquire first verification start metadata of a first to-be-verified partition and second verification start metadata of a second to-be-verified partition, wherein a size of the second to-be-verified partition is greater than a size of the first to-be-verified partition. The first verification module is configured to perform first verification on the security of the first to-be-verified partition based on the first verification start metadata. The processing module is configured to determine a start data set of the second to-be-verified partition in response to a verification result of the first verification. The second verification module is configured to perform second verification on the second to-be-verified partition based on the start data set and the second verification start metadata.

8. An electronic device, comprising: Comprise: At least one processor; And The memory is connected in communication with the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1-6.

10. A computer program product, characterised in that, The computer program, when executed by the processor, implements the method of any one of claims 1-6.

Images