System partition dynamic protection method and device

Abstract

The invention provides a system partition dynamic protection method and device, and the method comprises the steps: loading a simple payment verification light node module in a boot loader stage; verifying related information of the light node module based on a block chain recent check point and trust parameters stored locally and credibly, and obtaining newest block head sequence information and an encryption proof recorded by a target partition list after verification is passed; on the basis of the hash value or the mapping abstract of each system partition, partition list information of the local machine is generated, and the partition list information comprises version information and list hash; based on the latest block head sequence information and the encryption proof recorded by the target partition list, performing consistency verification, and verifying whether the list hash corresponding to the version information on the chain is consistent with the list hash of the local machine or not after the verification is passed; if yes, cryptographic evidence is generated in the trusted execution environment and is chained; the technical problems that in the prior art, static verification is bypassed, a recovery source is not credible, and auditing is not traceable are solved.

Description

Technical Field

[0001] This application relates to the field of equipment partition protection technology, and in particular to a system partition dynamic protection method and device. Background Technology

[0002] The system partition integrity mechanism of mobile terminals such as Android devices has the following problems: First, traditional static verification based on local hash trees / signatures (such as dm-verity / AVB) may bypass verification by forging the root of trust or replacing the verification path through Bootkit-like means when attackers have control of the early boot chain or boot environment. Second, in the common practice of "rolling back from local backup / restore partition image", the backup media and recovery source are in the same trust domain as the device. Once the backup is contaminated or a backdoor is implanted, the recovery process will write the contaminated content back to the system partition. Third, existing audits are mostly limited to local logs and vendor self-certification, lacking verifiable historical integrity evidence from third parties, and cannot provide traceable proof to regulators, enterprise MDM, or quality inspection agencies that "the system fingerprint of the device was indeed running at a certain time". Summary of the Invention

[0003] This application provides a system partitioning dynamic protection method and apparatus to at least partially solve one of the technical problems in related technologies. The technical solution of this disclosure is as follows: In a first aspect, embodiments of this application propose a system partitioning dynamic protection method, including: During the bootloader stage of device startup, the Simple Payment Verification (SPV) light node module is loaded; Based on the most recent checkpoint and trust parameters of the blockchain stored locally, the reliability of the relevant information of the SPV light node module is verified, and after the verification is passed, the latest block header sequence information and the cryptographic proof of the target partition list record are obtained. Based on the hash value or image digest of each system partition, generate the partition list information of the local machine, which includes version information and list hash; Based on the latest block header sequence information and the cryptographic proof of the target partition list record, SPV consistency verification is performed, and after the verification is passed, the list hash corresponding to the version information on the verification chain is verified to be consistent with the list hash of the local machine. If they match, within the Trusted Execution Environment (TEE), cryptographic evidence is generated based on the proof circuit, and the cryptographic evidence is submitted to the blockchain smart contract, entering the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules.

[0004] Secondly, embodiments of this application propose a system partition dynamic protection device, comprising: The block loading module is used to load the Simple Payment Verification (SPV) light node module during the bootloader stage of device startup. The block verification module is used to verify the reliability of the relevant information of the SPV light node module based on the most recent checkpoint and trust parameters of the blockchain stored locally, and after the verification is passed, obtain the latest block header sequence information and the cryptographic proof of the target partition list record. The manifest generation module is used to generate local partition manifest information based on the hash value or image digest of each system partition. The partition manifest information includes version information and manifest hash. The verification module is used to perform SPV consistency verification based on the latest block header sequence information and the cryptographic proof of the target partition list record, and after the verification is passed, to verify whether the list hash corresponding to the version information on the verification chain is consistent with the list hash of the local machine. The evidence-on-chain module is used to generate cryptographic evidence based on the proof circuit within a Trusted Execution Environment (TEE) if there is consistency, and submit the cryptographic evidence to the blockchain smart contract to enter the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules. Thirdly, embodiments of this application provide an electronic device, including: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method described in the first aspect.

[0005] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method described in the first aspect.

[0006] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect.

[0007] The system partition dynamic protection method and device provided in this application improves reliability by introducing on-chain list anchoring and SPV verification, extending integrity judgment from a single entity to network-wide consensus. By generating proofs, the fact that the verification is correct and the local list is equal to the on-chain list is solidified on-chain, allowing third parties to independently verify without touching the partition content, thus balancing privacy and compliance. Through a circuit breaker mechanism, in the event of verification failure or inconsistency, the system automatically enters a restricted trusted mode, blocking high-risk paths, preserving necessary network connectivity, and guiding recovery from the on-chain anchored mirror, forming a closed loop of "discovery—isolation—repair—review—unblocking", reducing downtime and risk spread.

[0008] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0009] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a system partition dynamic protection method provided in an embodiment of this application; Figure 2 A block diagram of a system partition dynamic protection device provided in an embodiment of this application; Figure 3 This is a block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0010] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0011] In related technologies, the system partition integrity mechanism for mobile terminals such as Android devices mainly includes: ① AVB / dm-verity: Verifying the hash tree or image signature of partitions such as boot / system / vendor in the boot chain, relying on vbmeta and OEM public key; ② Keymaster / TEE: Used for key management and secure operations, storing important parameters in RPMB or SE; ③ Rollback Protection: Limiting the loading of low-version images through a monotonic counter; ④ Recovery Mechanism: Restoring the system from the local recovery partition or factory backup image; ⑤ Auditing and Logging: Security logs are written locally and uploaded to the manufacturer's cloud or enterprise MDM platform. To improve trusted startup, BootROM→BL1 / BL2→Android Bootloader verify signatures step by step, and after entering the kernel, dm-verity ensures the runtime integrity of the read-only partition. In enterprise scenarios, SafetyNet / Attestation or remote forensics are added to determine whether the device has been rooted / unlocked. Some high-security scenarios place the "reference hash" in protected storage (such as RPMB) and compare it with the manufacturer's server over the network to see if it is the latest version. Overall, these solutions emphasize a "primarily local verification, supplemented by cloud-based verification" model. While technically mature and widely implemented, their trust anchors and audit evidence are often provided by a single entity (device / manufacturer). It's worth noting that AVB (Android VerifiedBoot) and dm-verity are two key technologies in the Android system used to ensure software integrity and security. They work together but differ in their implementation levels and verification timing.

[0012] The disadvantages of the above scheme include: First, static, single-domain trust. AVB / dm-verity relies on a local root public key and a local hash tree. Once the bootloader is privileged or the trusted root is replaced, attackers can forge a seemingly successful verification path, forming a bootkit bypass. Second, recovery source is in the same domain. Common recovery / local backup images are stored on the same machine as the system. If the backup stage has been contaminated, recovery will "solidify" the contamination, and it is difficult to prove to third parties that "the version before and after recovery is indeed the same approved version." Third, weak audit verifiability. Existing logs or cloud verifications are usually generated by the vendor's centralized system, and external entities lack convenient independent verification links; moreover, to protect privacy, logs often do not contain strong evidence that can be publicly verified. Fourth, insufficient dynamic response. The handling after verification failure is mostly "refusing to start or entering normal recovery," lacking a fine-grained closed-loop strategy of "circuit breaker - isolation - restricted network - trusted source recovery - re-verification - unblocking," resulting in either excessive downtime affecting availability or running with defects and increasing risks. Fifth, historical trajectory is difficult to solidify. Even with cloud-based recording, it is difficult to provide publicly verifiable and non-repudiable on-chain evidence of "time point - partition fingerprint - verification conclusion," making it difficult to efficiently implement compliance audits, after-sales disputes, and supply chain tracking.

[0013] To address the aforementioned issues, this application provides a method and apparatus for dynamic protection of system partitions. The core of the solution is to embed SPV (Simple Payment Verification) light node capabilities during the Bootloader stage. Utilizing a decentralized blockchain as the "notarization / anchoring medium for partition fingerprints," the system partition hash is compared with the latest consensus state of the blockchain. After each verification, a zero-knowledge proof (zk-SNARK) is generated and uploaded to the blockchain to form publicly verifiable evidence of partition integrity without disclosing the partition content. Simultaneously, through the collaboration of a Trusted Execution Environment (TEE) and hardware security modules (HSM / SE / RPMB / anti-rollback counter), a dynamic strategy of "failure triggers circuit breaking, downgrades to a restricted trusted state, and triggers secure recovery" is established, plugging three major vulnerabilities: bypassing static verification, untrusted recovery sources, and untraceable auditing.

[0014] The following description, with reference to the accompanying drawings, describes a system partition dynamic protection method, apparatus, and device according to embodiments of this application.

[0015] Figure 1 This is a flowchart illustrating a system partition dynamic protection method provided in an embodiment of this application.

[0016] It should be noted that the system partition dynamic protection method in this application embodiment is the system partition dynamic protection device in this application embodiment. The system partition dynamic protection device can be configured in an electronic device so that the electronic device can perform the system partition dynamic protection function.

[0017] like Figure 1 As shown, the system's dynamic partition protection method includes the following steps: Step S101: During the Bootloader stage of device startup, the Simple Payment Verification (SPV) light node module is loaded.

[0018] Taking the Android system as an example, during the BootROM / BL stage, the system is conventionally verified and booted to the Android Bootloader (also known as the bootloader), maintaining compatibility with AVB (Android Verified Boot, a framework for verifying the integrity of the boot image, which ensures that the device can only load verified images during startup); upon entering the Bootloader, the SPV light node module is loaded.

[0019] This step loads a lightweight blockchain module, embedding the SPV light node module on the Bootloader / TEE side. It only synchronizes the block header and necessary Merkle tree branches, without downloading the complete chain data.

[0020] In this embodiment, the root of trust and security domain of the device system are: BootROM → Hierarchical Bootloader (BL1 / BL2 / Android Bootloader) → TEE (TrustZone Security OS) → Normal World (Android Kernel / System).

[0021] Step S102: Based on the most recent checkpoint and trust parameters of the blockchain stored locally, verify the reliability of the relevant information of the SPV light node module, and after the verification is passed, obtain the latest block header sequence information and the cryptographic proof of the target partition list record.

[0022] As one implementation, the blockchain's most recent checkpoint and trust parameters (including genesis hash, mainnet ID, and consensus threshold) are read from a protected storage medium (such as RPMB / SE); based on the blockchain's most recent checkpoint and trust parameters, the reliability of the relevant information of the SPV light node module is verified.

[0023] The data structure for the blockchain's most recent checkpoint and trust parameters is: {genesis, chain_id, last_trusted_height, last_block_hash}, where... Genesis block hash is the hash of the first block of the blockchain. It is the unique root identity identifier of the chain and is used to distinguish the mainnet from the testnet / private chain. The chain_id (mainnet ID) is used to distinguish different blockchain networks (e.g., Ethereum mainnet ID is 1, Ropsten testnet ID is 3) to prevent devices from mistakenly connecting to the wrong network. The consensus threshold is the minimum number of node signatures or computing power required for a blockchain to reach consensus (such as 2 / 3 nodes in PBFT, or 6 block confirmations in PoW). SPV uses it to determine whether a block is finalized.

[0024] last_trusted_height is the highest trusted block height (i.e., checkpoint) synchronized before the device was last shut down. The new block header is pulled from this height during the next startup to ensure synchronization continuity.

[0025] `last_block_hash` is the hash value of the last block, which is the hash of the block corresponding to `last_trusted_height`. It is stored in pairs with the height to prevent the checkpoint from being tampered with.

[0026] Relationships: genesis + chain_id is used to confirm "which chain is correct", last_trusted_height + last_block_hash is used to confirm "from which position to continue synchronization", and consensus threshold is used to confirm "whether the new block synchronized is trustworthy enough".

[0027] The most recent checkpoint on the blockchain, i.e., the highest trusted block height and its hash before the device's last shutdown, is the starting point for SPV verification. The checkpoint serves as a trust anchor for SPV synchronization, preventing verification from starting from a malicious fork and ensuring the continuity of the block header sequence. Trust parameters (genesis hash / mainnet ID / consensus threshold) are used to identify the correct blockchain network and prevent connection to private chains or testnets set up by attackers. Verification in this step is a prerequisite for subsequent SPV consistency checks. The device retrieves subsequent block headers starting from `last_trusted_height`, verifies whether its hash chain legally continues to the latest block, and confirms that the block containing the on-chain inventory record has not been rolled back.

[0028] As one implementation, after successful verification, the latest block header sequence and the Merkle proof of the target list record are obtained through a read-only network stack (such as restricted drivers or whitelisted ports).

[0029] Step S103: Based on the hash value or image digest of each system partition, generate the partition list information of the local machine. The partition list information includes version information and list hash.

[0030] This can be understood as follows: the partition list is not a static file pre-stored in the device, but is regenerated every time the device starts up, to ensure that it reflects the actual state of the current system partitions and to prevent the use of a tampered pre-stored partition list.

[0031] In some embodiments, a native partition manifest (i.e., a partition integrity manifest) is constructed, containing the hash root of each system partition (which may be the dm-verity hash root or the image digest), version number, timestamp, publisher signature, etc. In one example, the Merkle root is used as the manifest hash.

[0032] As one implementation, after the Bootloader loads and verifies the SPV light node module, it constructs the local partition integrity list by calculating or reading the hash values ​​of each system partition in real time. During the construction process, for partitions with dm-verity enabled, their verity root hash can be read directly; for other partitions, their image digest is calculated on-site. As an example, the dm-verity root (or image digest) is calculated or read for read-only partitions such as / system, / vendor, / product, and / system_ext to synthesize the Manifest Root.

[0033] Step S104: Based on the latest block header sequence information and the cryptographic proof of the target partition list record, perform SPV consistency verification, and after the verification passes, verify whether the list hash corresponding to the version information on the verification chain is consistent with the list hash of the local machine.

[0034] This step primarily performs SPV consistency verification, including block header validity verification and transaction proof verification. Based on the latest block header sequence information, it verifies the validity of the new block header (such as workload / signature / BFT threshold, depending on the blockchain type). According to the cryptographic proof recorded in the target partition's list, it verifies that the list record transactions are contained in the Merkle root at a certain height. Verifying that the list record transactions are contained in the Merkle root at a certain height can be understood as using Merkle proofs to verify that the list hash transactions uploaded by the vendor are indeed packaged into the block header of a historical block. The "certain height" refers to the block number when the list transaction was uploaded (e.g., block 1,000,000). The Merkle root is the root hash value of all transactions recorded in that block header. The verification method is that the device obtains the path hash from the transaction to the Merkle root through the SPV node. Verifying the correct path proves that the transaction truly exists in that block, without needing to download the complete block data. The core function is to confirm that this version of the list does indeed exist on the chain and has not been forged or rolled back.

[0035] In some embodiments, the method further includes: during the system release process prior to device startup, calculating the hash value or image digest of each system partition, obtaining an anchored list of partitions, and signing it onto the blockchain.

[0036] In other words, the on-chain partition list is calculated and signed by the manufacturer when the system image is released. It is actively anchored to the chain through a smart contract. Each official version release will anchor it once, forming an on-chain version history. The device only verifies the anchored historical list and does not write it. Specifically, when the device starts up, it queries and verifies the historical record through the SP light node.

[0037] In some embodiments, the method further includes: obtaining the highest version of the local machine through a local rollback counter; determining whether the highest version of the local machine is less than the lowest version recorded on the chain; and if it is less, triggering a circuit breaker mechanism.

[0038] This can be understood as follows: the rollback counter stores the highest version number ever flashed into the device, stored in security hardware such as RPMB / eFuse in a monotonically increasing manner, and cannot be rolled back; the on-chain minimum version threshold refers to the minimum system version that is forcibly required on the chain, set by the manufacturer or enterprise policy. If the current version of the device is lower than the on-chain minimum version threshold, a circuit breaker is triggered to prevent the flashing of an old version with known vulnerabilities: this not only prevents the local counter from being tampered with, but also forces the device to upgrade to a secure version through on-chain global policies, thus plugging the vulnerability of "downgrade attack".

[0039] In other words, the device compares the hash of the corresponding version on the blockchain with its current version number. If they do not match, the circuit breaker mechanism is triggered. The circuit breaker mechanism is also triggered if the device's version is lower than the minimum version threshold on the blockchain.

[0040] Step S105: If consistent, within the Trusted Execution Environment (TEE), cryptographic evidence is generated based on the proof circuit, and the cryptographic evidence is submitted to the blockchain smart contract, entering the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules.

[0041] In some embodiments, the proof circuit includes public and private inputs. The public inputs include on-chain list hashes, block header roots, and device anonymity proof identifiers (excluding personal data). The private inputs include the local partition hash set and the intermediate value of the SPV verification. The circuit proof is used to define the mathematical constraints on the cryptographic evidence. The mathematical constraints include list consistency verification and the correct execution of the SPV verification steps. The proof circuit design in this embodiment does not disclose the partition content and completes the SPV verification and hash equality as specified.

[0042] This can be understood as follows: the proof circuit is the rule definition, the proof generation is the execution of verification and the production of cryptographic evidence; the proof circuit is the template for generating the proof, and generating the proof is the process of filling the template with real data and performing calculations. Without circuit design, a proof cannot be generated; without proof generation, the design rules of the proof circuit cannot be verified by a third party.

[0043] As an example, the design of the proof circuit defines the mathematical constraints to be proven—namely, "the list hash of the local machine = the list hash of the chain" and "the SPV verification steps are executed correctly"—but does not reveal the partition content itself. This is static, pre-defined verification logic.

[0044] In some embodiments, within a Trusted Execution Environment (TEE), a set of elliptic curve or pairing libraries are invoked, and a pre-set proof key is used to perform zero-knowledge concise non-interactive knowledge argument zk-SNARK proof generation to obtain cryptographic evidence. As an example, upon startup, the TEE substitutes actual data (local partition hash and SPV intermediate values ​​as private inputs) into the proof circuit, runs the zk-SNARK algorithm, and generates a publicly verifiable cryptographic proof π. Specifically, the TEE side invokes a set of elliptic curve / pairing libraries (such as a built-in BN curve pairing library) to perform zk-SNARK (such as Groth16 / PLONK general settings) proof generation, using a pre-set proof key (stored in RPMB, with key integrity guaranteed by the TEE). After generating the proof, the proof π and the public input are submitted to the audit contract; the contract or lightweight validator only performs the verification (low cost for verification of Groth16, etc.) and does not need to access the partition content.

[0045] This proof can demonstrate that "the list hash measured locally is equal to the list hash recorded on the chain, and the verification process is executed according to the specification", and the proof will be stored on the chain.

[0046] Any third party can verify the proof on the blockchain and obtain the conclusion that "the system list running on a certain device instance (anonymized) at a certain time is consistent with the on-chain anchor," thus achieving audit visibility.

[0047] In some embodiments, if the generation of cryptographic evidence based on the proof circuit fails or times out, a circuit breaker mechanism is triggered.

[0048] In some embodiments, when the device's computing power is more limited, the "ZK proof generation" can be migrated to a trusted execution agent (such as an enterprise edge trusted node). The trusted execution agent produces zk-SNARK and sends it back, and the terminal only verifies and uploads it to the chain (without disclosing the partition content).

[0049] Step S106: If there is no consistency, trigger the circuit breaker mechanism to block the mounting and interface of the untrusted partition, enter the restricted trusted mode, download the target partition image corresponding to the partition list anchored on the blockchain from the trusted source, write the target partition image into the partition and return to the verification step.

[0050] In some embodiments, triggering the circuit breaker mechanism further includes: enabling a restricted network whitelist to allow access only to trusted image distributions and blockchain gateways.

[0051] In one example, after the circuit breaker mechanism is triggered, the mounting of untrusted partitions is blocked (forced to be read-only or not mounted), the system is switched to a secure mini-system (secure boot disk / recovery mini-system), high-risk peripherals and debugging interfaces (such as ADB, unsigned updates, and installations from unknown sources) are disabled, the "restricted network whitelist" is enabled, allowing access only to trusted image distributions and blockchain gateways; and the system is forced into the "recovery process state machine" until recovery is complete and verification is passed again, at which point the circuit breaker is automatically deactivated.

[0052] In some embodiments, the recovery process (on-chain anchored trusted source) includes: downloading a read-only partition image that matches the on-chain anchored manifest hash (multi-source verification is possible: from CDN / enterprise image / P2P, but all with the on-chain hash as the unique truth value), rewriting it, and then performing the above steps. After passing the verification, the normal mode is unlocked.

[0053] In some embodiments, the triggering conditions for the circuit breaker mechanism include: SPV consistency verification failure, manifest hash root inconsistency, rollback failure, TEE integrity module anomaly, proof generation failure or exceeding limits. Once any step of the verification fails or an inconsistency occurs, the circuit breaker controller intervenes: blocking the mounting / execution path of the high-risk partition, downgrading to "restricted trusted mode", allowing only the restricted network to recover by obtaining an on-chain anchored image from a trusted source, and then verifying and de-circuiting after completion.

[0054] It should also be noted that this method does not replace AVB / dm-verity, but adds a triple enhancement of "on-chain notarization + ZK proof + circuit breaker recovery": 1) AVB is still used to complete local signature verification; 2) On-chain list is used as an external non-repudiable anchor; 3) In case of failure, a dynamic circuit breaker closed loop is entered to avoid running with defects; that is, "on-chain list anchoring + SPV verification" is introduced on the basis of local AVB / dm-verity.

[0055] The system partition dynamic protection method in this application extends integrity judgment from a single entity to network-wide consensus by introducing on-chain list anchoring and SPV verification. Even if an attacker controls the local chain, it is difficult to simultaneously tamper with the on-chain history and consensus proof. By generating proof, the fact that the verification is correct and the local list is equal to the on-chain list is solidified on-chain. Third parties can independently verify without touching the partition content, balancing privacy and compliance. Through the circuit breaker mechanism, in the event of verification failure or inconsistency, it automatically enters the restricted trusted mode, blocking high-risk paths, preserving necessary network access, and guiding recovery from the on-chain anchored image, forming a "discovery-isolation-repair-recovery" process. The closed-loop "core-unsealing" mechanism reduces downtime and risk spread; recovery images can be distributed from multiple sources, but all are based on on-chain hashes to prevent contaminated local backups from being written back, effectively improving the system's dynamic partition protection capabilities; each verification and recovery action generates on-chain verifiable proofs and timestamps, providing objective evidence for after-sales dispute resolution, corporate compliance audits, and supply chain quality tracking; SPV light nodes only synchronize block headers and necessary proofs, resulting in low resource consumption; proofs are completed within the TEE using pre-built keys and a pairing library, resulting in low on-chain verification costs; the overall solution does not rely on machine learning or large models, is compatible with existing hardware and operating system capabilities, and is engineering-feasible.

[0056] To achieve the above embodiments, this application also proposes a system partition dynamic protection device. Figure 2 This is a schematic diagram of a system partition dynamic protection device provided in an embodiment of this application. Figure 2 As shown, the system's partition dynamic protection device may include: a block loading module 210, a block verification module 220, a list generation module 230, a verification module 240, and an evidence uploading module 250.

[0057] Among them, the block loading module 210 is used to load the Simple Payment Verification SPV light node module during the bootloader stage of the device startup. The block verification module 220 is used to verify the reliability of relevant information of the SPV light node module based on the latest checkpoint and trust parameters of the blockchain in local trusted storage, and after the verification is passed, obtain the latest block header sequence information and the cryptographic proof of the target partition list record. The manifest generation module 230 is used to generate local partition manifest information based on the hash value or image digest of each system partition. The partition manifest information includes version information and manifest hash. The verification module 240 is used to perform SPV consistency verification based on the latest block header sequence information and the cryptographic proof of the target partition list record, and after the verification is passed, to verify whether the list hash corresponding to the version information on the verification chain is consistent with the list hash of the local machine. The evidence-on-chain module 250 is used to generate cryptographic evidence based on the proof circuit within the Trusted Execution Environment (TEE) if there is consistency, and submit the cryptographic evidence to the blockchain smart contract to enter the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules.

[0058] Furthermore, in one possible implementation of this application embodiment, the device further includes a fuse recovery module 260, used for: If there is a discrepancy, the circuit breaker mechanism is triggered, blocking the mounting of untrusted partitions and interfaces, entering a restricted trusted mode, downloading the target partition image corresponding to the partition list anchored on the blockchain from a trusted source, writing the target partition image into the partition, and returning to the verification step.

[0059] Furthermore, in one possible implementation of this application embodiment, the circuit breaker recovery module 260 is also used for: Enable a restricted network whitelist to allow access only to trusted mirror distributions and blockchain gateways.

[0060] Furthermore, in one possible implementation of this application embodiment, the verification module 240 is further configured to: Obtain the highest version of the local machine by using the local rollback counter; Determine if the highest version on the local machine is less than the lowest version recorded on the chain; If the value is less than the circuit breaker threshold, the circuit breaker mechanism will be triggered.

[0061] Furthermore, in one possible implementation of this application embodiment, the circuit breaker recovery module 260 is also used for: If the generation of cryptographic evidence based on the proof circuit fails or times out, the circuit breaker mechanism is triggered.

[0062] Furthermore, in one possible implementation of this application embodiment, the proof circuit includes public inputs and private inputs. The public inputs include on-chain list hashes, block header roots, and device anonymity proof identifiers. The private inputs include the local partition hash set and the SPV verification intermediate value. The circuit proof is used to define the mathematical constraints of the cryptographic evidence. The mathematical constraints include list consistency verification and the correct execution of the SPV verification steps.

[0063] Furthermore, in one possible implementation of this application embodiment, the evidence-on-chain module 250, when generating cryptographic evidence based on the proof circuit, is used for: Within a Trusted Execution Environment (TEE), a complete set of elliptic curve or pairing libraries is invoked, and a pre-set proof key is used to perform zero-knowledge concise non-interactive knowledge argumentation zk-SNARK proof generation to obtain cryptographic evidence. Furthermore, in one possible implementation of this application embodiment, the list of anchored partitions on the chain is obtained by calculating the hash value or image digest of each system partition during the system release process.

[0064] It should be noted that the foregoing explanation of the system partition dynamic protection method embodiment also applies to the system partition dynamic protection device of this embodiment, and will not be repeated here.

[0065] To implement the above embodiments, this application also proposes an electronic device. Please see [link to relevant documentation]. Figure 3 , Figure 3 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 3 As shown, the electronic device 300 includes: a processor 301 and a memory 302 communicatively connected to the processor 301; the memory 302 stores computer execution instructions; the processor 301 executes the computer execution instructions stored in the memory to implement the method provided in the foregoing embodiments.

[0066] To implement the above embodiments, this application also proposes a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the foregoing embodiments.

[0067] To implement the above embodiments, this application also proposes a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the foregoing embodiments.

[0068] In the foregoing descriptions of the embodiments, the terms "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0069] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0070] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A system partitioning dynamic protection method, characterized in that, Includes the following steps: During the bootloader stage of device startup, the Simple Payment Verification (SPV) light node module is loaded; Based on the most recent checkpoint and trust parameters of the blockchain stored locally, the reliability of the relevant information of the SPV light node module is verified, and after the verification is passed, the latest block header sequence information and the cryptographic proof of the target partition list record are obtained. Based on the hash value or image digest of each system partition, generate the partition list information of the local machine, which includes version information and list hash; Based on the latest block header sequence information and the cryptographic proof of the target partition list record, SPV consistency verification is performed, and after the verification is passed, the list hash corresponding to the version information on the verification chain is verified to be consistent with the list hash of the local machine. If they match, within the Trusted Execution Environment (TEE), cryptographic evidence is generated based on the proof circuit, and the cryptographic evidence is submitted to the blockchain smart contract, entering the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules.

2. The method according to claim 1, characterized in that, The method further includes: If there is a discrepancy, the circuit breaker mechanism is triggered, blocking the mounting and interface of the untrusted partition, entering the restricted trusted mode, downloading the target partition image corresponding to the partition list anchored on the blockchain from the trusted source, writing the target partition image into the partition, and returning to the verification step.

3. The method according to claim 2, characterized in that, The circuit breaker triggering mechanism also includes: Enable a restricted network whitelist to allow access only to trusted mirror distributions and blockchain gateways.

4. The method according to claim 1, characterized in that, After verifying that the manifest hash corresponding to the version information on the verification chain is consistent with the manifest hash of the local machine, the process further includes: Obtain the highest version of the local machine by using the local rollback counter; Determine whether the highest version of the local machine is less than the lowest version recorded on the chain; If the value is less than the circuit breaker threshold, the circuit breaker mechanism will be triggered.

5. The method according to claim 1, characterized in that, The method further includes: If the generation of cryptographic evidence based on the proof circuit fails or times out, the circuit breaker mechanism is triggered.

6. The method according to claim 1, characterized in that, The proof circuit includes public inputs and private inputs. The public inputs include on-chain list hashes, block header roots, and device anonymity proof identifiers. The private inputs include the local partition hash set and the SPV verification intermediate value. The circuit proof is used to define the mathematical constraints of the cryptographic evidence. The mathematical constraints include list consistency verification and correct execution of the SPV verification steps.

7. The method according to claim 1, characterized in that, The generation of cryptographic evidence based on the proof circuit includes: Within a Trusted Execution Environment (TEE), a complete set of elliptic curve or pairing libraries is invoked, and a pre-set proof key is used to perform zero-knowledge concise non-interactive knowledge argumentation zk-SNARK proof generation to obtain cryptographic evidence.

8. The method according to claim 2, characterized in that, The list of anchored partitions on the chain is obtained by calculating the hash value or image digest of each system partition during the system release process.

9. A system partition dynamic protection device, characterized in that, include: The block loading module is used to load the Simple Payment Verification (SPV) light node module during the bootloader stage of device startup. The block verification module is used to verify the reliability of the relevant information of the SPV light node module based on the most recent checkpoint and trust parameters of the blockchain stored locally, and after the verification is passed, obtain the latest block header sequence information and the cryptographic proof of the target partition list record. The manifest generation module is used to generate local partition manifest information based on the hash value or image digest of each system partition. The partition manifest information includes version information and manifest hash. The verification module is used to perform SPV consistency verification based on the latest block header sequence information and the cryptographic proof of the target partition list record, and after the verification is passed, to verify whether the list hash corresponding to the version information on the verification chain is consistent with the list hash of the local machine. The evidence-on-chain module is used to generate cryptographic evidence based on the proof circuit within a Trusted Execution Environment (TEE) if there is consistency, and submit the cryptographic evidence to the blockchain smart contract to enter the local normal mode; wherein, the proof circuit indicates the cryptographic evidence generation rules.

10. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-8.

Images