System partition dynamic protection method and device

Abstract

The application provides a system partition dynamic protection method and device, wherein the method comprises the following steps: in a boot loader stage, loading a simple payment verification light node module; verifying the related information of the light node module based on the latest checkpoint of a local trusted storage and a trust parameter, and obtaining the encryption proof of the latest block header sequence information and the target partition list record after the verification is passed; generating the local partition list information based on the hash value or image digest of each system partition, wherein the partition list information comprises version information and list hash; performing consistency check based on the latest block header sequence information and the encryption proof of the target partition list record, and checking whether the list hash corresponding to the version information on the chain is consistent with the local list hash after the check is passed; if consistent, generating a cryptography evidence in a trusted execution environment and chaining; and solving the technical problems that the static check in the prior art is bypassed, the source is untrusted, and the audit is untraceable.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of device partition protection, and in particular to a system partition dynamic protection method and device. BACKGROUND

[0002] The system partition integrity mechanism of a mobile terminal such as an Android device has the following problems: first, a traditional static check based on a local hash tree / signature (such as dm-verity / AVB) may bypass the check by means of Bootkit when an attacker has controlled the early start chain or the boot environment, and by forging a trusted root or replacing the check path; second, in the common practice of "rolling back from a local backup / restored partition image", the backup medium and the recovery source are in the same trust domain as the device, and once the backup is contaminated or a backdoor is implanted, the recovery process will write the contaminated content to the system partition again; and third, existing audits are mostly limited to local logs and vendor self-certification, and lack of third-party verifiable historical integrity evidence, and cannot provide traceable proof of "the system fingerprint of the device at a certain time" to regulators, enterprise MDMs or quality inspection agencies. SUMMARY

[0003] The present application provides a system partition dynamic protection method and device to at least partially solve one of the technical problems in the related art. The technical solution of the present disclosure is as follows:

[0004] In a first aspect, the present application provides a system partition dynamic protection method, comprising:

[0005] loading a simple payment verification (SPV) light node module in a boot loader stage of device startup;

[0006] verifying the reliability of related information of the SPV light node module based on a blockchain recent checkpoint and trust parameters of a local trusted storage, and obtaining an encryption proof of the latest block header sequence information and target partition list records after verification;

[0007] generating local partition list information based on hash values or image digests of each system partition, wherein the partition list information includes version information and list hash;

[0008] performing SPV consistency check based on the encryption proof of the latest block header sequence information and target partition list records, and checking whether the list hash corresponding to the version information on the chain is consistent with the local list hash after the check passes;

[0009] If consistent, generate a cryptographic evidence based on a proof circuit in a trusted execution environment (TEE), and submit the cryptographic evidence to a blockchain smart contract to enter a native normal mode; wherein the proof circuit indicates a cryptographic evidence generation rule.

[0010] In a second aspect, an embodiment of the present application provides a system partition dynamic protection device, comprising:

[0011] A block loading module is configured to load a simple payment verification (SPV) light node module in a boot loader stage of device startup.

[0012] A block verification module is configured to verify the reliability of related information of the SPV light node module based on a local trusted storage blockchain latest checkpoint and a trust parameter, and obtain an encryption proof of a latest block header sequence information and a target partition list record after verification.

[0013] A list generation module is configured to generate a native partition list information based on a hash value or an image digest of each system partition, wherein the partition list information comprises version information and a list hash.

[0014] A verification module is configured to perform an SPV consistency verification based on the latest block header sequence information and the encryption proof of the target partition list record, and verify whether a list hash corresponding to the version information on the chain is consistent with the list hash of the native after verification.

[0015] An evidence on-chain module is configured to generate a cryptographic evidence based on a proof circuit in a trusted execution environment (TEE) if consistent, and submit the cryptographic evidence to a blockchain smart contract to enter a native normal mode; wherein the proof circuit indicates a cryptographic evidence generation rule.

[0016] In a third aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory in communication with the processor; the memory stores computer execution instructions; and the processor executes the computer execution instructions stored in the memory to implement the method of the first aspect.

[0017] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, wherein the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method of the first aspect.

[0018] In a fifth aspect, an embodiment of the present application provides a computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the method of the first aspect.

[0019] The system partition dynamic protection method and device provided by the application introduce on-chain list anchoring and SPV verification, expand the integrity judgment from a single subject to network consensus, improve reliability, generate a proof to chain the fact that the verification is correct and the local list is equal to the on-chain list, and third parties can independently verify without contacting the partition content, which balances privacy and compliance; through the fuse mechanism, in the case of failed verification or inconsistency, the system automatically enters a limited trusted mode, blocks high-risk paths, retains necessary networking, guides recovery from on-chain anchored images, forms a closed loop of 'discovery-isolation-repair-recheck-unseal', reduces downtime and risk diffusion.

[0020] Additional aspects and advantages of the application will be set forth in part in the description which follows, and in part will become apparent to those skilled in the art upon examination of the following description and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0021] The above and / or additional aspects and advantages of the application will become apparent and be readily understood from the following description, taken in conjunction with the accompanying drawings, in which:

[0022] Figure 1 A flowchart of a system partition dynamic protection method provided by an embodiment of the application;

[0023] Figure 2 A block diagram of a system partition dynamic protection device provided by an embodiment of the application;

[0024] Figure 3 A block diagram of an electronic device provided by an embodiment of the application. DETAILED DESCRIPTION

[0025] The embodiments of the application are described in detail below, examples of which are shown in the accompanying drawings, in which the same or similar reference numerals represent the same or similar elements or elements having the same or similar functions throughout. The embodiments described below are exemplary and are intended to explain the application, and cannot be understood as limiting the application.

[0026] In related technologies, the system partition integrity mechanism of mobile terminals such as Android devices mainly includes: ① AVB / dm-verity: checking the hash tree or image signature of partitions such as boot / system / vendor in the startup chain, relying on vbmeta and OEM public key; ② Keymaster / TEE: used for key management and secure operation, important parameters stored in RPMB or SE; ③ Rollback Protection: limit loading of low version image through monotonic counter; ④ Recovery mechanism: recover system from local recovery partition or factory backup image; ⑤ Audit and log: security log is written locally, uploaded to the cloud of the manufacturer or the MDM platform of the enterprise. To improve the trusted start, BootROM→BL1 / BL2→Android Bootloader is signed step by step, and after entering the kernel, dm-verity guarantees the runtime integrity of read-only partitions. Enterprise scenarios are superimposed with SafetyNet / Attestation or remote forensics to determine whether the device is rooted / unlocked. Some high-security scenarios will place the "reference hash" in protected storage (such as RPMB) and compare it with the manufacturer's server through the network to determine whether it is the latest version. Overall, these schemes emphasize the mode of "local verification first, cloud assistance second", and the technology is mature and widely used, but the trust anchor and audit evidence are mainly provided by a single subject (device / manufacturer). It should be noted that AVB (Android Verified Boot) and dm-verity are two key technologies in Android system for software integrity and security, which work together but have different implementation levels and verification times.

[0027] 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 escalated or the trusted root is replaced, an attacker can forge a "seemingly passed" verification path to form a Bootkit bypass. Second, the recovery source is in the same domain. The common recovery / local backup image is saved with the system on the same machine. If the backup stage has been contaminated, the recovery will "solidify" the contamination, and it is difficult to prove to a third party that "the approved version before and after the recovery is the same". Third, the audit is weakly provable. The existing logs or cloud verification are usually issued by the manufacturer's centralized system, and external subjects lack convenient independent verification links. In order to protect privacy, the logs often do not contain strong evidence that can be publicly reviewed. Fourth, the dynamic response is insufficient. After the verification fails, the disposal is mostly "refuse to start or enter ordinary recovery", and there is a lack of a closed-loop strategy of "fusing-isolation-restricted networking-trusted source recovery-reverification-unfusing", which leads to either excessive downtime affecting availability or running with diseases expanding risks. Fifth, it is difficult to solidify the historical track. Even if recorded through the cloud, it is difficult to provide "time point-partition fingerprint-verification conclusion" on-chain evidence that can be publicly verified and non-repudiated, making it difficult to efficiently land compliance auditing, after-sales disputes, and supply chain tracking.

[0028] To solve the above problems, the embodiments of the present application provide a system partition dynamic protection method and device. The core of the scheme is to embed the SPV (Simple Payment Verification) light node capability in the Bootloader stage, use the decentralized blockchain as the "partition fingerprint notarization / anchoring medium", compare the system partition hash with the latest consensus state of the blockchain, and generate zero-knowledge proof (zk-SNARK) after each verification, and upload it to form integrity evidence that can be publicly verified and does not leak the content of the partition. At the same time, through the cooperation of the Trusted Execution Environment (Trusted Execution Environment, TEE) and the hardware security module (HSM / SE / RPMB / anti-rollback counter), a dynamic strategy of "fusing when failing, downgrading to a restricted trusted state and triggering a safe recovery" is established, which blocks the three vulnerabilities of bypassing static verification, untrusted recovery source and untraceable audit.

[0029] The system partition dynamic protection method, device and equipment of the embodiments of the present application are described below with reference to the accompanying drawings.

[0030] Figure 1 The flowchart of a system partition dynamic protection method provided by the embodiments of the present application.

[0031] It should be noted that the execution subject of the system partition dynamic protection method of the embodiment of the present application is the system partition dynamic protection device of the embodiment of the present application, which can be configured in an electronic device to enable the electronic device to perform a system partition dynamic protection function.

[0032] As shown in Figure 1 The system partition dynamic protection method comprises the following steps:

[0033] Step S101, loading a simple payment verification (SPV) light node module in a Bootloader stage of device startup.

[0034] Taking an Android system as an example, in a BootROM / BL stage, a conventional signature verification is performed to boot to an Android Bootloader (alias: Bootloader), and compatibility with an AVB (Android Verified Boot, which is a framework for verifying the integrity of a startup image, and can ensure that only a verified image can be loaded when a device starts) is maintained; entering the Bootloader, loading the SPV light node module.

[0035] This step loads a lightweight blockchain module, embeds an SPV light node module on a Bootloader / TEE side, only synchronizes a block header and a necessary Merkle tree branch, and does not download complete chain data.

[0036] The trust root and the security domain of the device system of the embodiment are: BootROM → hierarchical Bootloader (BL1 / BL2 / Android Bootloader) → TEE (TrustZone security OS) → normal world (Android kernel / system).

[0037] Step S102, verifying the reliability of related information of the SPV light node module based on a blockchain recent checkpoint and a trust parameter of a local trusted storage, and obtaining the latest block header sequence information and an encrypted proof of a target partition list record after verification.

[0038] As an implementation manner, reading a blockchain recent checkpoint (Checkpoint) and a trust parameter (including a genesis hash, a main network ID, and a consensus threshold) from a protected storage medium (such as RPMB / SE); verifying the reliability of related information of the SPV light node module according to the blockchain recent checkpoint and the trust parameter.

[0039] The data structure of the blockchain recent checkpoint and the trust parameter is: {genesis, chain_id, last_trusted_height, last_block_hash}, wherein,

[0040] genesis (genesis block hash) is the hash of the first block of the blockchain, which is the root identity of the unique chain, used to distinguish the main network from the test network / private chain;

[0041] chain_id (main network ID) is used to distinguish different blockchain networks (such as Ethereum main network ID 1, Ropsten test network 3), to prevent devices from connecting to the wrong network;

[0042] The consensus threshold is the minimum node signature or computing power ratio required for the blockchain to reach consensus (such as 2 / 3 nodes for PBFT and 6 block confirmations for PoW), and SPV uses it to determine whether the block is final.

[0043] last_trusted_height is the highest trusted block height (i.e. Checkpoint) synchronized by the device before the last shutdown, which starts pulling new block headers from this height when starting next time, ensuring synchronization continuity.

[0044] last_block_hash is the last block hash value, which is the hash of the block corresponding to last_trusted_height, stored in pairs with height to prevent checkpoint tampering.

[0045] Relationship: genesis+chain_id is used to confirm "the correct chain", 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 synchronized new block is sufficiently trusted".

[0046] The latest checkpoint of the blockchain, i.e. the highest trusted block height and its hash before the last shutdown of the device, is the starting point of SPV verification. Checkpoint serves as the trust anchor for SPV synchronization, preventing verification from starting from a malicious forked chain and ensuring the continuity of the block header sequence. Trust parameters (genesis hash / main network ID / consensus threshold): used to identify the correct blockchain network to prevent connecting to an attacker-built private chain or test network; the verification in this step is the prerequisite for the subsequent SPV consistency check, and the device starts from last_trusted_height to obtain subsequent block headers, verifies whether the hash chain is legally extended to the latest block, and confirms that the block where the list record is located has not been rolled back.

[0047] As an implementation, after verification, the latest block header sequence and Merkle proof of the target list record are obtained through a read-only network stack (such as a restricted driver, a whitelisted port).

[0048] Step S103, based on the hash value or image digest of each system partition, generate the local partition list information, which includes version information and list hash.

[0049] It can be understood that the partition list is not a static file pre-stored in the device, but is regenerated each time the device starts to ensure that the actual state of the current system partition is reflected and to prevent the use of a tampered pre-stored partition list.

[0050] In some embodiments, the local partition list (i.e., the partition integrity list, PartitionManifest) is constructed, which contains the hash root (dm-verity hash root or image digest) of each system partition, version number, timestamp, publisher signature, etc. In one example, the Merkle root is used as the list hash.

[0051] As an implementation, after the Bootloader loads the SPV light node module and passes the verification, the local partition integrity list is constructed by calculating or reading the hash value of each system partition in real time. During the construction process, for the partitions that have enabled dm-verity, the hash root (verity root hash) can be directly read, and for other partitions, the image digest is calculated on site. As an example, the dm-verity root (or image digest) is calculated or read for the read-only partitions such as / system, / vendor, / product, / system_ext, etc., to synthesize the Manifest Root.

[0052] Step S104, based on the latest block header sequence information and the encryption proof recorded by the target partition list, perform SPV consistency verification, and after the verification passes, check whether the list hash corresponding to the version information on the chain is consistent with the local list hash.

[0053] The step mainly performs SPV consistency verification, including validity verification of the block header and transaction proof verification, based on the latest block header sequence information, verifying the validity of the new block header (such as work / signature / BFT threshold, depending on the type of block chain), and verifying that the list record transaction is included in the Merkle root of a certain height according to the encrypted proof recorded in the target partition list. The verification of the list record transaction included in the Merkle root of a certain height can be understood as verifying that the list hash transaction chained by the manufacturer is indeed packaged into the block header of a certain historical block by using the Merkle proof. The certain height refers to the block number when the list transaction is chained (such as the first 1,000,000 blocks), and the Merkle root is the root hash value of all transactions recorded in the block header. The verification method is that the device obtains the path hash of the transaction to the Merkle root through the SPV node, and verifies that the path is correct, which proves that the transaction exists in the block. It is not necessary to download the complete block data; the core function is to confirm that the list of this version indeed exists on the chain and has not been forged or rolled back.

[0054] In some embodiments, the method further comprises: in the system release process before the device starts, calculating the hash value or image digest of each system partition, obtaining the anchored partition list and signing it on the chain.

[0055] That is, the partition list on the chain is calculated by the manufacturer to calculate the hash root of the partition list when the system image is released and signed, and is anchored on the chain by the smart contract. Each official version release is anchored once to form the version history on the chain; the device end only verifies the anchored historical list and does not write it. Specifically, the device queries and verifies the historical record through the SPV light node when starting.

[0056] In some embodiments, it further comprises: obtaining the local highest version through the local anti-rollback counter; judging whether the local highest version is less than the minimum version recorded on the chain; if it is less, triggering the fuse mechanism.

[0057] It can be understood that the highest version number that the device has ever flashed is stored in the anti-rollback counter in a monotonically increasing manner in the RPMB / eFuse and other secure hardware, and cannot be rolled back; the minimum version threshold on the chain refers to the minimum system version required on the chain, which is set by the manufacturer or enterprise strategy. If the current version of the device is lower than the minimum version threshold on the chain, the fuse is triggered to prevent the old version with known vulnerabilities from being flashed: both the local counter is tampered with, and the device is forced to upgrade to a safe version through the global strategy on the chain, and the vulnerability of the "version down attack" is blocked.

[0058] That is, the device compares the list hash corresponding to the version on the chain according to the current version number of the local machine. If they are not consistent, the fuse mechanism is triggered; if the version of the local machine is lower than the minimum version threshold on the chain, the fuse mechanism is also triggered.

[0059] Step S105, if consistent, generating a cryptographic evidence based on the proof circuit in the trusted execution environment TEE, and submitting the cryptographic evidence to the blockchain smart contract, entering the native normal mode; wherein the proof circuit indicates the cryptographic evidence generation rule.

[0060] In some embodiments, the proof circuit includes public inputs and private inputs, the public inputs include the on-chain manifest hash, the block header root and the device anonymous proof identification (without personal data), and the private inputs include the native partition hash set and the SPV verification intermediate value, the proof circuit is used to define the mathematical constraints of the cryptographic evidence, and the mathematical constraints include the manifest consistency check and the correct execution of the SPV check step. The design of the proof circuit of the present embodiment does not disclose the partition content, and the SPV verification and the hash equation are completed according to the specification.

[0061] It can be understood that the proof circuit is a rule definition, the generation of the proof is the execution of the verification and the output of the cryptographic evidence, the proof circuit is a template for generating the proof, and the generation of the proof is a process of filling real data in the template and calculation. Without the circuit design, the proof cannot be generated; without the generation of the proof, the design rule of the proof circuit cannot be verified by a third party.

[0062] As an example, the design of the proof circuit defines the mathematical constraints to be proved, i.e. "the manifest hash of the native = the manifest hash on the chain" and "the SPV verification step is executed correctly", but does not disclose the partition content itself. This is a static and pre-set verification logic.

[0063] In some embodiments, in the trusted execution environment TEE, a complete elliptic curve or pairing library is called, a pre-set proof key is used, zero-knowledge succinct non-interactive knowledge argument zk-SNARK proof generation is performed, and a cryptographic evidence is obtained. As an example, when the TEE is started, the actual data (the partition hash of the native and the SPV intermediate value as the private input) is substituted into the proof circuit, the zk-SNARK algorithm is run, and the publicly verifiable cryptographic proof π is generated. Specifically, the TEE side calls a complete elliptic curve / pairing library (such as a built-in BN curve pairing library) to perform zk-SNARK (such as Groth16 / PLONK general setting) proof generation, and uses a pre-set proof key (stored in the RPMB, and the key integrity is guaranteed by the TEE);

[0064] After the proof is generated, the proof π and the public input are submitted to the audit contract; the contract or the light verifier only needs to verify (the verification cost of Groth16 is low), and does not need to access the partition content.

[0065] The proof can prove that "the manifest hash measured by the native = the manifest hash recorded on the chain, and the verification process is executed according to the specification", and the proof is stored on the chain.

[0066] Any third party can review the proof on-chain and get the conclusion that "the system list of the device instance (anonymized) at a certain time runs in line with the on-chain anchor", realizing audit visibility.

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

[0068] In some embodiments, when the device computing power is more limited, the "ZK proof generation" can be migrated to a trusted execution agent (such as an enterprise edge trusted node) to complete, and the trusted execution agent outputs the zk-SNARK and returns it, and the terminal only verifies and uploads (without revealing the partition content.

[0069] Step S106, if not consistent, trigger the fuse mechanism, 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.

[0070] In some embodiments, triggering the fuse mechanism further includes: opening a restricted network whitelist to allow access only to trusted image distribution and blockchain gateways.

[0071] In one example, after triggering the fuse mechanism, the untrusted partition mounting is blocked (forced read-only or not mounted), switched to a secure small system (secure boot disk / restore microsystem), high-risk peripherals and debugging interfaces (such as ADB, unsigned updates, unknown source installation) are closed, a "restricted network whitelist" is opened to allow access only to trusted image distribution and blockchain gateways; forced entry into the "recovery process state machine" until recovery is complete and the verification is passed again to automatically defuse.

[0072] In some embodiments, the recovery process (trusted source anchored on the chain) includes: downloading a read-only partition image that matches the list hash anchored on the chain (multiple source verification is possible: from CDN / enterprise image / P2P, but all with the on-chain hash as the only true value), rewriting and then executing the above steps, and unlocking the normal mode after passing.

[0073] In some embodiments, the trigger conditions of the fuse mechanism include: SPV consistency verification failure, list hash root inconsistency, rollback failure, TEE integrity module exception, proof generation failure or timeout. Once any step of verification fails or inconsistency occurs, the fuse controller cuts in: blocks the mounting / execution path of high-risk partitions, downgrades to "restricted trusted mode", and only allows restricted networks to obtain the image anchored on the chain from trusted sources for recovery, and then verifies and defuses after completion.

[0074] It also needs to be explained that the method does not replace AVB / dm-verity, but adds the triple enhancement of "on-chain notarization + ZK proof + fuse recovery": 1) still use AVB to complete local signature verification; 2) use on-chain list as an external non-repudiable anchor; 3) enter dynamic fuse closed loop when failure to avoid running with disease; that is, introduce "on-chain list anchoring + SPV verification" on the basis of local AVB / dm-verity.

[0075] The system partition dynamic protection method of the embodiment of the application introduces on-chain list anchoring and SPV verification, expands the integrity judgment from a single subject to the whole network consensus, and it is difficult for an attacker to tamper with the on-chain history and consensus proof even if the attacker controls the local start chain; the fact that the verification is correct and the local list is equal to the on-chain list is solidified by generating a proof, a third party can independently verify without touching the partition content, and privacy and compliance are considered; through the fuse mechanism, in the case of failed verification or inconsistency, automatically enter the restricted trusted mode, block high-risk paths, retain necessary networking, guide recovery from on-chain anchored images, form a closed loop of "discovery - isolation - repair - review - unseal", reduce downtime and risk diffusion; the recovery image can be distributed from multiple sources, but all with on-chain hash as true, avoiding writing back of the polluted local backup, effectively improving the system partition dynamic protection capability; each verification and recovery action will output a chain-verified proof and timestamp, providing objective evidence for after-sales dispute handling, enterprise compliance audit, and supply chain quality tracking; the SPV light node only synchronizes block headers and necessary proofs, with small resource occupation; the proof is completed in TEE with pre-set keys and pairing library, with low on-chain verification cost, and the overall scheme does not rely on machine learning or large models, which is consistent with the existing hardware and operating system capabilities, and has engineering implementability.

[0076] In order to realize the above-mentioned embodiment, the application further provides a system partition dynamic protection device. Figure 2 A structural schematic diagram of a system partition dynamic protection device provided by an embodiment of the application is shown in FIG. 1. Figure 2 As shown in the figure, the system partition dynamic protection device can include a block loading module 210, a block verification module 220, a list generation module 230, a verification module 240, and an evidence on-chain module 250.

[0077] The block loading module 210 is configured to load a simple payment verification (SPV) light node module in the boot loader stage of device startup.

[0078] The block verification module 220 is configured to verify the reliability of the related information of the SPV light node module based on the latest checkpoint of the block chain and the trust parameter of the local trusted storage, and after the verification is passed, obtain the latest block header sequence information and the encrypted proof of the target partition list record.

[0079] The manifest generation module 230 is configured to generate a local partition manifest information based on the hash value or image digest of each system partition, the partition manifest information including version information and a manifest hash;

[0080] The verification module 240 is configured to perform SPV consistency verification based on the latest block header sequence information and the cryptographic proof of the target partition manifest record, and if the verification passes, verify whether the manifest hash corresponding to the version information on the chain is consistent with the local manifest hash.

[0081] The evidence on-chain module 250 is configured to, if consistent, generate a cryptographic evidence based on a proof circuit in a trusted execution environment (TEE), and submit the cryptographic evidence to a smart contract of a blockchain, and enter a normal mode; wherein the proof circuit indicates a cryptographic evidence generation rule.

[0082] Further, in a possible implementation of the embodiment of the present application, the device further includes a fuse recovery module 260, configured to:

[0083] If inconsistent, trigger a fuse mechanism to block untrusted partition mounting and interfaces, and enter a restricted trusted mode, download a target partition image corresponding to the partition manifest anchored on the blockchain from a trusted source, write the target partition image into a partition, and return to the verification step.

[0084] Further, in a possible implementation of the embodiment of the present application, the fuse recovery module 260 is further configured to:

[0085] Start a restricted network whitelist to allow access to only trusted image distribution and a blockchain gateway.

[0086] Further, in a possible implementation of the embodiment of the present application, the verification module 240 is further configured to:

[0087] Obtain the local highest version by using a local rollback counter;

[0088] Determine whether the local highest version is less than the minimum version recorded on the chain;

[0089] If less, trigger the fuse mechanism.

[0090] Further, in a possible implementation of the embodiment of the present application, the fuse recovery module 260 is further configured to:

[0091] If the generation of the cryptographic evidence based on the proof circuit fails or times out, trigger the fuse mechanism.

[0092] Further, in a possible implementation of the embodiment of the application, the proof circuit includes a public input and a private input, the public input includes the on-chain inventory hash, the block header root and the device anonymous proof identifier, and the private input includes the native partition hash set and the SPV verification intermediate value, and the proof circuit is used to define a mathematical constraint of the cryptographic evidence, and the mathematical constraint includes an inventory consistency check and correct execution of the SPV check step.

[0093] Further, in a possible implementation of the embodiment of the application, the evidence on-chain module 250, when generating the cryptographic evidence based on the proof circuit, is configured to:

[0094] In the trusted execution environment TEE, a complete elliptic curve or pairing library is called, a preset proof key is used, zero-knowledge succinct non-interactive knowledge argument zk-SNARK proof generation is performed, and the cryptographic evidence is obtained.

[0095] Further, in a possible implementation of the embodiment of the application, the anchored partition inventory on the chain is obtained by calculating hash values or image digests of each system partition in a system publishing process.

[0096] It should be noted that the foregoing explanation and description of the system partition dynamic protection method embodiment also applies to the system partition dynamic protection device of the embodiment, which will not be described here again.

[0097] To implement the above-mentioned embodiments, the application further provides an electronic device. Please refer to Figure 3 , Figure 3 is a structural schematic diagram of the electronic device provided by the embodiment of the application. As shown in Figure 3 , the electronic device 300 includes a processor 301 and a memory 302 connected with the processor 301; the memory 302 stores computer execution instructions; and the processor 301 executes the computer execution instructions stored in the memory to implement the method provided by the foregoing embodiments.

[0098] To implement the above-mentioned embodiments, the application further provides a computer readable storage medium, which stores computer execution instructions, and the computer execution instructions are used to implement the method provided by the foregoing embodiments when executed by a processor.

[0099] To implement the above-mentioned embodiments, the application further provides a computer program product, which includes a computer program, and the computer program is used to implement the method provided by the foregoing embodiments when executed by a processor.

[0100] In the foregoing various embodiment descriptions, the description with reference to the terms "one embodiment", "some embodiments", "an example", "a specific example", or "some examples" and the like 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 application. In the present 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 appropriate manner in any one or more embodiments or examples. Furthermore, the person skilled in the art can combine and combine the different embodiments or examples described in the present specification and the features of the different embodiments or examples, without contradiction.

[0101] In addition, the terms "first", "second", are used only for the purpose of description, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the technical features indicated. Therefore, the features defined with "first", "second" can explicitly or implicitly include at least one of the features. In the description of the present application, the meaning of "a plurality of" is at least two, for example, two, three, etc., unless otherwise explicitly specifically limited.

[0102] Although the embodiments of the present application have been shown and described above, it is understood that the above-described embodiments are exemplary and cannot be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above-described embodiments within the scope of the present 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 proof circuit 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