Fire-fighting tamper-proofing inspection method and system based on alliance chain

Abstract

The present application relates to a kind of fire prevention tamper-proof inspection method and system based on alliance chain, belong to fire inspection and block chain technology field.The method generates single effective inspection challenge factor by obtaining one-time dynamic random factor of alliance chain;Synchronous activation two-dimensional code and near field communication double channel, obtain equipment logical identity coding and physical unique identification, execute double-factor asymmetric signature to inspection challenge factor;Call trusted execution environment to sign and consistency comparison after encapsulation as inspection event package;Submit alliance chain and with supervision chain verification as consensus access condition, complete double-chain interlocking storage through after and hierarchical output result.The present application prevents inspection data from being tampered or forged by dynamic challenge factor, double-factor signature and double-chain interlocking mechanism, improves the security and credibility of fire equipment inspection.

Description

Technical Field

[0001] This invention belongs to the field of fire inspection and blockchain technology, specifically involving a fire inspection method and system based on consortium blockchain to prevent tampering. Background Technology

[0002] Fire safety is an important component of the public safety system, and routine inspections of fire protection facilities are a core means of timely identifying potential hazards and ensuring the reliable operation of these facilities. With the continuous growth in the scale of urban buildings and the number of fire protection equipment, problems such as dispersed inspection points, complex operational scenarios, and significant regulatory challenges are becoming increasingly prominent. The authenticity and tamper-proof nature of inspection data are directly related to the implementation of fire safety responsibilities and the closed-loop management of potential hazards.

[0003] Traditional fire inspections often rely on single verification methods such as paper sign-in, ordinary QR code check-in, and NFC card swiping, which have significant security vulnerabilities. Ordinary QR codes are merely static logical identifiers, easily copied by photo and remotely forwarded for proxy check-in, making it impossible to verify whether inspection personnel were actually present. Ordinary NFC tags are susceptible to cloning and duplication; relying solely on a physical identifier is insufficient to completely prevent equipment replacement and tag forgery. Furthermore, traditional inspection data is mostly stored in centralized business systems, allowing administrators to arbitrarily modify inspection records. Proxy check-ins, missed inspections, and subsequent record-keeping are difficult to trace, compromising inspection quality and hindering fire safety supervision departments from conducting enforcement and liability determination based on accurate data.

[0004] In recent years, some solutions have introduced blockchain technology to achieve inspection data storage, attempting to solve the problem of data tampering. However, several technical shortcomings remain. First, most blockchain inspection solutions heavily rely on real-time network connections. However, fire inspections often involve weak or no-network scenarios such as underground garages, tunnels, high-rise building cores, and signal shielding rooms. Network interruptions can directly halt the inspection process. Inspection data generated offline lacks a reliable storage mechanism, the authenticity of supplementary data cannot be guaranteed, and the adaptability to different scenarios is insufficient. Second, existing solutions mostly adopt a single-chain storage architecture, completing data storage only on the business chain. They lack cross-verification and endorsement from authoritative fire safety regulatory nodes, limiting the legal validity and regulatory acceptance of the stored data, making it difficult to directly use as a basis for law enforcement. Third, most solutions deploy the verification logic on cloud servers. Inspection data must be transmitted to the cloud for verification via the public network, which not only suffers from network latency and slow response times but also faces security risks such as man-in-the-middle attacks, data hijacking, and tampering. The security and real-time performance of the verification process are difficult to balance.

[0005] In summary, existing fire inspection technologies have significant shortcomings in terms of equipment identity verification, reliable offline operation, authoritative evidence storage, and hierarchical data management, and cannot meet the needs of high-security fire inspections that are tamper-proof. Summary of the Invention

[0006] To address the aforementioned problems in the existing technology, this invention provides a fire protection anti-tampering inspection method and system based on consortium blockchain. The objective of this invention can be achieved through the following technical solutions: A fire protection anti-tampering inspection method based on consortium blockchain includes the following steps: When the inspection is started, a one-time dynamic random factor is obtained from the light node of the consortium blockchain, and a single valid inspection challenge factor is generated by combining the identity certificate and the device geofence verification hash. Using the inspection challenge factor as the original signature, obtain the device QR code logical encoding and near-field communication physical identifier, and perform asymmetric signatures respectively to generate logical and physical verification response data; Within the trusted execution environment, the signature verification operation is performed on the two verification response data. After hash tree comparison and time offset verification, the data is encapsulated to generate an inspection event packet with a secure time stamp. The inspection event package is submitted to the consortium blockchain, and the verification of the fire supervision filing chain is used as a consensus prerequisite. The verification hash anchors the block header to complete the dual-chain interlocking and storage, and the results are output in layers according to the node permissions.

[0007] Specifically, the process of obtaining the one-time dynamic random factor includes: Upon detecting the patrol start command, the system reads the digital identity certificate digest of the current patrol personnel and the geofence hash field of the device corresponding to the current location. The system then uses the terminal identity private key to perform asymmetric encryption on the request content and assembles it into an encrypted request message. The encrypted request message is uploaded to the light node of the consortium blockchain. The message is first decrypted using the corresponding public key. Then, the on-chain registration of the inspector's identity and the pre-stored validity of the fence information are verified. After the verification is passed, the one-time dynamic random factor is generated. The one-time dynamic random factor, digital identity credential, and geofence verification hash are concatenated in a preset field order, and a one-way hash operation is performed on the concatenated complete data to generate the single-valid inspection challenge factor.

[0008] Specifically, the process of verifying the geofence hash includes: Each fire-fighting device is pre-bound to a preset effective geographical area for inspection. The effective area is then mapped in a grid. The area boundary coordinates, effective coverage radius, device location number, and area effective period information are combined. A one-way hash operation is performed on the combined complete spatial data to generate a fixed and unique device geofence verification hash value, which is then pre-stored in the consortium blockchain. When the inspection is started, the terminal location data is acquired in real time to determine whether the current location falls within the effective range of the preset geofence. Only when the location is determined to be compliant will a dynamic random factor application be allowed to be initiated.

[0009] Specifically, the process of obtaining the device's QR code logical encoding and near-field communication physical identifier includes: After a single valid inspection challenge factor is generated and sent to the terminal, the QR code parsing channel and the near-field communication reading channel are activated simultaneously, and timeout control is enabled based on the terminal's unified security clock. The QR code parsing channel generates a logical identity code for the equipment's background registration based on the logical QR code of the fire protection equipment; the near-field communication reading channel reads the solidified data of the fire protection equipment's built-in chip, verifies the chip's original manufacturer's identity certificate, and extracts the physical unique identifier; if any channel fails to read, times out, or fails data verification, the inspection is deemed to have failed, an abnormal event record is generated, and the inspection process is terminated.

[0010] Specifically, the asymmetric signature process includes: Using a single valid inspection challenge factor as the unified signature text, the device logical signature private key corresponding to the logical identity code is called to perform an asymmetric signature operation on the signature text, and output logical verification response data containing logical identity features. The device physical signature private key corresponding to the physical unique identifier is called to independently perform a signature operation on the same signature text, and output physical verification response data containing hardware identity features. The two signature operations run in mutually isolated memory spaces, and the intermediate states are not exposed to each other. Each of them embeds the corresponding public key index identifier to form a two-factor signature response sequence.

[0011] Specifically, the verification operation process includes: The logical verification response data and physical verification response data are transmitted to the isolated secure area of ​​the trusted execution environment. The structured fields in the preset format in the two response data are parsed, and the corresponding signature value segment, public key index identifier segment and signature timestamp segment are extracted respectively. Retrieve the pre-built and non-exportable device public key certificate set within the trusted execution environment, and match the corresponding logical signature verification public key and physical signature verification public key according to the extracted public key index identifier; The matched signature verification public key is used to perform asymmetric signature verification operations on the two signature value segments respectively, and the original digest data corresponding to each signature is recovered, which is used as the input for subsequent hash tree comparison.

[0012] Specifically, the pass / fail determination process for the hash tree comparison includes: For the digest value recovered from the signature corresponding to the logical verification response data, together with the inspection challenge factor, they form two leaf nodes of a binary hash tree. One-way hash operation is performed on the two leaf nodes respectively to generate two fixed-length leaf hash values. The two leaf hash values ​​are concatenated in a preset fixed order and one-way hash operation is performed again to generate the corresponding unique root hash value. Following the same operational rules and node arrangement order, a binary hash tree is constructed for the digest value recovered from the signature corresponding to the physical verification response data and the original inspection challenge factor, generating the corresponding root hash value; the root hash values ​​of the two hash trees are then compared bit by bit with the standard verification root hash value pre-stored in the trusted execution environment.

[0013] Specifically, the encapsulation process of the inspection event packet includes: After the judgment is passed, three types of core data are collected in the secure storage domain of the trusted execution environment: single-valid inspection challenge factor, two-way verification response data, and local secure clock time stamp. The field mapping and order are arranged according to the preset message protocol to construct a three-layer structure of message header, business data segment, and verification segment. The verification segment generates an integrity digest by performing a hash operation on the entire business data segment.

[0014] Specifically, the implementation process of the consensus preconditions includes: After receiving the inspection event packet, the light node of the consortium blockchain extracts the device identity identifier and inspection permission identifier as verification parameters; it performs protocol conversion and message routing through the cross-chain gateway, constructs a standardized verification request message with cross-chain node signature, and forwards it to the corresponding node of the fire supervision filing chain; Upon receiving the verification result message from the regulatory chain, first verify the validity of the regulatory node's signature, then perform a one-way hash operation on the verification result to generate the regulatory chain verification hash. Associate and bind the verification result and the regulatory chain verification hash with the original inspection event packet, and synchronously write them into the pending queue of the business consortium chain. Event packets that fail verification are directly rejected.

[0015] Specifically, the process of the dual-chain interlocked evidence storage includes: The inspection event packages that are eligible for evidence storage are included in the current set of blocks to be packaged. A Merkle tree is constructed for all inspection events in the set in the order of submission, and Merkle root hash values ​​are generated by performing layer-by-layer operations. Assemble the block header information, including the block version number, on-chain unified timestamp, block height, previous block hash value, Merkle root hash value, and regulatory chain verification hash. The block-producing node performs a signature confirmation on the block header. The block-producing node broadcasts the complete block to the entire consortium chain network. After each node verifies the legality of the block and the consistency of the data, it synchronously writes it into the local distributed ledger to complete the chain-based solidification, realizing the dual-chain interlocking of the business chain and the regulatory chain.

[0016] Specifically, the process of generating the hierarchical output results includes: The system pre-defines three levels of permission mapping rules, corresponding to the inspection execution end, the operation and maintenance management end, and the regulatory enforcement end, respectively. For the inspection execution end, it calls the zero-knowledge proof protocol to generate compliance verification credentials containing only compliance conclusions and excluding sensitive information. For the operation and maintenance management end, it performs sensitive field desensitization processing, removes core signature data and identity privacy information, and outputs reports on device status and operation and maintenance suggestions. For the regulatory enforcement end, it grants access to view and retain the full original event package, complete signature evidence, and spatiotemporal data.

[0017] The beneficial effects of this invention are as follows: Dual anti-counterfeiting measures for device identity: Combining the logical identity encoding of QR code with the unique identifier of NFC physical chip, dual-channel independent asymmetric signature verification is completed with dynamic random challenge benchmark. The authenticity of the device is verified from two dimensions: logical identity and physical hardware. It can resist counterfeiting behaviors such as QR code copying and device replacement, and improve the credibility of the inspection device identity.

[0018] Offline inspection is continuous and reliable: It relies on the trusted execution environment of the terminal to realize local signature verification without waiting for the cloud network to return; at the same time, it supports isolated encrypted storage in the absence of network, and automatically re-uploads to the chain in order after the network is restored. It is suitable for complex inspection scenarios such as underground space and signal shielded area, ensuring the continuity of inspection process and data security.

[0019] Spatiotemporal constraints prevent proxy inspections: A one-time dynamic random factor is strongly bound to the digital identity of the inspection personnel and the geofence hash of the equipment. Each inspection is valid only once and can resist replay attacks and off-site proxy inspections. This ensures that the inspection personnel are on-site to perform the inspection operations and standardizes the inspection process.

[0020] Cross-chain consensus enhances the validity of evidence storage: Through cross-chain verification between the business alliance chain and the fire supervision filing chain, coupled with the distributed consensus mechanism within the chain, the inspection data is given dual authoritative endorsement. The stored data has the characteristics of being tamper-proof and non-repudiable, which can meet the evidentiary validity requirements of fire supervision and law enforcement. Attached Figure Description

[0021] To facilitate understanding by those skilled in the art, the present invention will be further described below with reference to the accompanying drawings.

[0022] Figure 1 This is a flowchart illustrating a fire protection anti-tampering inspection method based on a consortium blockchain according to the present invention. Figure 2 This is a data object evolution flow diagram in this invention; Figure 3 This is a lifecycle status diagram of the inspection record in this invention. Detailed Implementation

[0023] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided.

[0024] Please see Figures 1-3 A fire protection anti-tampering inspection method based on consortium blockchain includes the following steps: S1: When the inspection process starts, a one-time dynamic random factor is obtained from the light node of the consortium blockchain. After being concatenated with the digital identity certificate of the current inspection subject and the geofence verification hash of the target fire-fighting equipment, a one-way hash operation is performed to generate a single valid inspection challenge factor. S2: Simultaneously activate the QR code parsing channel and the near-field communication reading channel to obtain the logical identity code and physical unique identifier of the target fire-fighting equipment respectively. Using the inspection challenge factor as the original text of the signature, perform asymmetric signature processing through the corresponding signature key to generate logical and physical verification response data respectively. S3: Call the pre-set signature verification public key in the trusted execution environment to perform signature verification operation on the logical and physical verification response data; compare the hash tree of the signature-obtained digest data with the inspection challenge factor and verify the offset between the signature timestamp and the security clock; after passing the verification, encapsulate the inspection challenge factor, logical and physical verification response data and the local security timestamp into an inspection event packet; S4: Submit the inspection event package to the consortium blockchain, using the verification result of the fire safety supervision filing chain as a prerequisite for consensus access; after verification, anchor the verification hash of the supervision chain into the block header to complete the dual-chain interlocking and evidence storage; output the results in layers according to the node permissions.

[0025] I. Generation of Inspection Challenge Factors When the inspection process is initiated, the system first needs to obtain a one-time dynamic random factor from the light node of the consortium blockchain, and then perform a one-way hash operation after concatenating it with the digital identity certificate of the current inspection subject and the geofence verification hash of the target fire-fighting equipment to generate a single valid inspection challenge factor.

[0026] (1) Obtaining a one-time dynamic random factor The one-time dynamic random factor refers to a random number or pseudo-random number generated once by a light node of the consortium blockchain and valid only for the current inspection session. It is used to ensure that each inspection challenge is unique and unpredictable, thereby effectively preventing replay attacks.

[0027] Specifically, upon detecting the inspection start command, the terminal device reads the digital identity certificate digest of the current inspection personnel and the device geofence hash field corresponding to the current location. It then uses the terminal's private key to perform asymmetric encryption on the request content before assembling it into an encrypted request message. Asymmetric encryption refers to an encryption method that uses a pair of public and private keys; data encrypted with the private key can only be decrypted with the corresponding public key, ensuring the confidentiality and integrity of the request content during transmission.

[0028] After the encrypted request message is uploaded to the consortium blockchain light node, the light node first decrypts the message using the corresponding public key, and then verifies the on-chain registration legitimacy of the inspector's identity and the pre-stored validity of the fence information. A consortium blockchain light node refers to a node type in the consortium blockchain that does not store the full ledger, only saves block header information, and can interact with full nodes. It is suitable for resource-constrained scenarios such as mobile terminals. After successful verification, the light node generates the one-time dynamic random factor.

[0029] (2) Generation of geofence verification hash The geofence verification hash is a fixed and unique hash value generated by hash mapping the preset valid geographical area for fire equipment inspection. It is used to verify whether the inspection personnel are within the legitimate geographical area before the inspection is started, and to prevent remote spoofing of inspections.

[0030] Specifically, the system pre-binds each fire-fighting device to a preset effective geographical area for inspection. This effective area is then mapped into a grid, combining the area boundary coordinates, effective coverage radius, device location number, and area activation cycle information. A one-way hash operation is performed on the combined spatial data to generate a fixed, unique device geofence verification hash value, which is then pre-stored in the consortium blockchain. A one-way hash operation converts input data of arbitrary length into a fixed-length hash value using a hash algorithm (such as SHA-256). This operation is irreversible, meaning the original data cannot be derived from the hash value.

[0031] When the inspection is initiated, the terminal obtains location data (such as GPS / BeiDou positioning) in real time to determine whether the current location falls within the effective range of the preset geofence. Only when the location determination is compliant will a dynamic random factor application be allowed to be initiated.

[0032] (3) Generation of inspection challenge factors The one-time dynamic random factor, digital identity credential, and geofence check hash are concatenated in a preset field order. A one-way hash operation is then performed on the concatenated complete data to generate the single-valid inspection challenge factor. This challenge factor serves as the unique "challenge code" for this inspection, and all subsequent signature operations are based on it, ensuring that the signature result of each inspection is uniquely bound to that inspection session.

[0033] II. Generation of Two-Factor Signature Response Data The QR code parsing channel and the near-field communication reading channel are activated simultaneously to obtain the logical identity code and physical unique identifier of the target fire-fighting equipment, respectively. The inspection challenge factor is used as the original text of the signature, and asymmetric signature processing is performed through the corresponding signature key to generate logical and physical verification response data.

[0034] (1) Obtaining logical identity code and physical unique identifier Logical identity coding refers to the logical identification information of fire protection equipment registered in the business backend. It is usually encoded in a QR code label on the outside of the equipment and is used to identify business attributes such as equipment type, model, and owner. Physical unique identifier refers to the tamper-proof hardware serial number or UID embedded in the NFC chip built into the fire protection equipment. It is used to identify the physical entity of the equipment and has uniqueness and anti-cloning properties.

[0035] After a single valid inspection challenge factor is generated and sent to the terminal, the terminal simultaneously activates the QR code parsing channel and the near-field communication reading channel, and enables timeout control based on the terminal's unified security clock. The QR code parsing channel scans the logical QR code on the outside of the fire-fighting equipment to obtain the logical identity code registered in the equipment's backend; the near-field communication reading channel reads the embedded data of the fire-fighting equipment's chip through NFC sensing, verifies the chip's original manufacturer's identity certificate, and extracts the physical unique identifier. If either channel fails to read, times out, or data verification fails, the inspection is deemed a failure, an abnormal event record is generated, and the inspection process is terminated.

[0036] (2) Execution of asymmetric signatures Using a single valid inspection challenge factor as the unified signature text, the device's logical signature private key corresponding to the logical identity code is invoked to perform an asymmetric signature operation on the signature text, outputting logical verification response data containing logical identity characteristics. Asymmetric signature refers to the process of digitally signing data using a private key. Any verifier holding the corresponding public key can verify the authenticity and integrity of the signature, but cannot forge the signature.

[0037] Simultaneously, the device's physical signature private key corresponding to the physical unique identifier is invoked to independently perform signature operations on the same original signature text, outputting physical verification response data containing hardware identity characteristics. The two signature operations run in isolated memory spaces, with intermediate states not exposed to each other, and each embeds its corresponding public key index identifier, forming a two-factor signature response sequence. Two-factor signature refers to signing the same data simultaneously based on two independent dimensions: logical identity and physical identity. Attackers must simultaneously compromise both the logical identity system and the physical hardware system to forge valid inspection data, greatly enhancing tamper resistance.

[0038] III. Signature Verification and Encapsulation in Trusted Execution Environments The system invokes a pre-configured signature verification public key in the trusted execution environment to perform signature verification operations on the logical and physical verification response data; it then performs a hash tree comparison between the hash data obtained from the signature verification and the inspection challenge factor, and verifies the offset between the signature timestamp and the security clock; upon successful verification, it encapsulates the inspection challenge factor, the logical and physical verification response data, and the local security timestamp into an inspection event packet.

[0039] (1) Verification calculation A Trusted Execution Environment (TEE) is a secure area located within the main processor of a device, ensuring the confidentiality and integrity of code and data loaded into it. Even if the operating system kernel is compromised, the data within the TEE cannot be accessed. The signature verification operation of this invention is performed entirely within the isolated secure area of ​​the TEE, ensuring that the signature verification public key and the verification process are not interfered with by external malicious software.

[0040] Specifically, the logical verification response data and physical verification response data are input into the isolated secure area of ​​the trusted execution environment. The structured fields in the two response data are parsed using a preset format, and the corresponding signature value segment, public key index segment, and signature timestamp segment are extracted respectively. A pre-built, non-exportable device public key certificate set is retrieved from within the trusted execution environment. Based on the extracted public key index, the corresponding logical verification public key and physical verification public key are matched respectively. Asymmetric verification operations are performed on the two signature value segments using the matched verification public key to recover the original digest data corresponding to each signature, which is used as input for subsequent hash tree comparison. Signature verification is the inverse operation of signature verification. It uses the public key to verify whether the signature value was signed by the corresponding private key and whether the original text has been tampered with. Successful signature verification allows the recovery of the original digest value at the time of signature.

[0041] (2) Hash tree comparison A hash tree, also known as a Merkle tree, is a binary tree structure where leaf nodes store the hash value of a data block, and non-leaf nodes store the hash result of concatenating the hash values ​​of their child nodes and then hashing them again, ultimately forming a unique root hash value. By comparing the root hash value, it is possible to efficiently verify whether the data contained in two hash trees are completely consistent.

[0042] Specifically, for the digest value recovered from the signature corresponding to the logical verification response data, together with the inspection challenge factor, forming two leaf nodes of a binary hash tree, a one-way hash operation is performed on each leaf node to generate two fixed-length leaf hash values. These two leaf hash values ​​are then concatenated in a preset fixed order, and a one-way hash operation is performed again to generate a corresponding unique root hash value. Following the same operation rules and node arrangement order, a binary hash tree is constructed for the digest value recovered from the signature corresponding to the physical verification response data and the original inspection challenge factor, generating a corresponding root hash value. The root hash values ​​of both hash trees are then compared bit-by-bit with the standard verification root hash value pre-stored within the trusted execution environment. The signature verification is considered successful only when both root hash values ​​match the standard value.

[0043] In addition, the system also verifies the offset between the signature timestamp and the secure clock: the signature timestamp is a timestamp embedded in the response data during signature processing, while the secure clock is a trusted time source maintained internally by the TEE. If the deviation between the signature timestamp and the secure clock exceeds a preset threshold (e.g., ±5 minutes), the signature is deemed to have a potential replay attack risk, and the signature verification fails.

[0044] (3) Encapsulation of inspection event packages After successful verification, three core data categories—the single-valid inspection challenge factor, two-way verification response data, and the local secure clock timestamp—are aggregated within the secure storage domain of the Trusted Execution Environment (TEE). The secure storage domain is an isolated storage area within the TEE specifically designed for storing sensitive data, inaccessible to external applications. Following a preset message protocol, field mapping and sequential arrangement are executed to construct a three-layer structure: message header, business data segment, and verification segment. The verification segment generates an integrity digest through a hash operation on the entire business data segment, used for integrity verification during subsequent transmission and evidence storage.

[0045] IV. Dual-chain evidence storage and layered output The inspection event package is submitted to the consortium blockchain, and the verification result of the fire supervision filing chain is used as a prerequisite for consensus access. After the verification is passed, the verification hash of the supervision chain is anchored into the block header to complete the dual-chain interlocking and evidence storage. The results are output in layers according to the node permissions.

[0046] (1) Preconditions for consensus access Consensus access refers to the verification process that an inspection event package must undergo before being included in the consortium blockchain. The innovation of this invention lies in using the verification results of the fire safety supervision filing chain as a prerequisite for consensus access; that is, only inspection events that have passed verification by the supervision chain are eligible to enter the consensus process of the consortium blockchain.

[0047] Specifically, after receiving an inspection event packet, the light node of the consortium blockchain extracts the device identity identifier and inspection permission identifier as verification parameters. It then performs protocol conversion and message routing through a cross-chain gateway (a relay device or protocol conversion service that enables data exchange between different blockchain systems), constructs a standardized verification request message with a cross-chain node signature, and forwards it to the corresponding node on the fire safety supervision filing chain. Upon receiving the verification result message from the supervision chain, it first verifies the validity of the supervision node's signature, then performs a one-way hash operation on the verification result to generate a supervision chain verification hash. The verification result and the supervision chain verification hash are then associated and bound to the original inspection event packet and synchronously written into the business consortium blockchain's pending processing queue. Event packets that fail verification are directly rejected and cannot enter the consensus process.

[0048] (2) Dual-chain interlocked evidence storage Dual-chain interlocking refers to the establishment of a two-way locking relationship between the business alliance chain and the fire supervision and filing chain by anchoring hash values ​​to each other. If the data on either chain is tampered with, the anchor hash on the other chain will be mismatched, thus achieving dual anti-tampering protection.

[0049] Specifically, inspection event packages qualified for evidence storage are included in the current set of blocks to be packaged. A Merkle tree is constructed for all inspection events in the set according to their submission order, and Merkle root hash values ​​are generated layer by layer. The block header information is assembled, including the block version number, on-chain unified timestamp, block height, previous block hash value, Merkle root hash value, and regulatory chain verification hash. The block-producing node performs a signature confirmation on the block header. The block-producing node broadcasts the complete block to the entire consortium blockchain network. After each node verifies the block's legality and data consistency, it synchronously writes the block into its local distributed ledger to complete chain-based solidification, achieving interlocking between the business chain and the regulatory chain.

[0050] (3) Zero-knowledge proof desensitization layered output Zero-knowledge proof is a cryptographic protocol that allows a prover to demonstrate the truth of a statement to a verifier without revealing any additional information beyond the statement's truth value. In this invention, it is used to prove compliance of an inspection to low-privilege nodes without disclosing sensitive inspection data.

[0051] Specifically, the system pre-defines a three-tiered permission mapping rule, corresponding to the inspection execution end, the operation and maintenance management end, and the regulatory enforcement end. For the inspection execution end, a zero-knowledge proof protocol is invoked to generate compliance verification credentials containing only compliance conclusions and excluding sensitive information. For the operation and maintenance management end, sensitive fields are anonymized, removing core signature data and identity privacy information, and outputting reports on device status and operation and maintenance suggestions. For the regulatory enforcement end, access to and retention of the full original event package, complete signature evidence, and spatiotemporal data is granted. Through this layered output mechanism, data traceability is ensured while maximizing the protection of the privacy of inspection personnel and the sensitive information of the equipment.

[0052] This embodiment is applied to a multi-entity collaborative fire protection facility inspection and supervision scenario. This method can be applied to daily fire equipment inspection scenarios, such as regular on-site inspections of fire extinguishers, fire hydrants, alarm controllers, and other equipment.

[0053] I. Generation of Inspection Challenge Factors In this embodiment, when the inspection personnel arrive at the location of the target fire-fighting equipment with the inspection terminal, they trigger an inspection start command through the interactive interface of the inspection terminal. The inspection terminal has a built-in security chip, which pre-stores the digital identity credential of the current inspection personnel (denoted as ID_user) and the terminal identity private key (denoted as SK_terminal).

[0054] In response to the inspection start command, the inspection terminal first acquires the current real-time location data (denoted as LOC_current) and compares this location data with the locally pre-stored geofence information of the target fire-fighting equipment. Let the geofence verification hash of the target fire-fighting equipment be H_geo. This H_geo is pre-calculated by the equipment management backend and synchronously stored in the local cache of the consortium blockchain light node. The specific generation method of the geofence verification hash H_geo is as follows: The valid geographical area bound to the target fire-fighting equipment is mapped in a grid, and a one-way hash operation is performed after combining the area boundary coordinate set G, the effective coverage radius R, the equipment location number D_id, and the area validity period T_valid.

[0055] If LOC_current is within the valid geographical range represented by H_geo, the location is deemed compliant, and the inspection terminal initiates a dynamic random factor request to the consortium blockchain light node. This request is generated by reading the digital identity certificate digest H_user of the current inspector and the aforementioned H_geo, performing asymmetric encryption on the request content using the terminal's private key SK_terminal, assembling it into an encrypted request message, and uploading it to the consortium blockchain light node.

[0056] After receiving the encrypted request message, the consortium blockchain light node decrypts the message using the pre-stored terminal identity public key PK_terminal, extracts H_user and H_geo, and verifies the on-chain registration validity of the inspector's identity and the pre-stored validity of the geofence information, respectively. Upon successful verification, the consortium blockchain light node invokes a secure random number generator to generate a one-time dynamic random factor Rnd, and returns Rnd to the inspection terminal.

[0057] After receiving Rnd, the inspection terminal concatenates Rnd, ID_user, and H_geo in a preset field order to obtain concatenated data M_concat = Rnd||ID_user||H_geo. A SHA-256 one-way hash operation is then performed on M_concat to generate a single-use valid inspection challenge factor C = Hash(M_concat). This challenge factor C has single-use validity and timeliness, effectively preventing replay attacks.

[0058] II. Generation of Two-Factor Validation Response Data After the inspection challenge factor C is issued to the inspection terminal, the inspection terminal simultaneously activates the QR code parsing channel and the near-field communication reading channel, and enables timeout control based on the terminal's unified security clock, setting the timeout threshold to ΔT_timeout.

[0059] The QR code decoding channel scans the QR code labels affixed to the surface of the target fire-fighting equipment using the camera unit of the inspection terminal, decodes and parses the QR code image, and extracts the logical identity code ID_logic registered in the background for the target fire-fighting equipment. This logical identity code ID_logic is a unique logical identifier for the equipment in the management platform.

[0060] The near-field communication (NFC) reading channel uses the NFC sensing unit of the inspection terminal to approach the NFC tag area of ​​the target fire-fighting equipment and reads the embedded data of the NFC chip in the fire-fighting equipment. The NFC chip stores the chip manufacturer's identity certificate Cert_chip and the physical unique identifier ID_physical. The inspection terminal first verifies Cert_chip with the pre-installed chip manufacturer's root certificate. After confirming that the chip has not been replaced or tampered with, it extracts ID_physical.

[0061] If either the QR code parsing channel or the NFC reading channel fails to read, no data is returned after ΔT_timeout, or the data verification fails, the inspection is deemed a failure. An abnormal event record containing the reason for the failure and a timestamp is generated, the inspection process is terminated, and the report is sent to the backend.

[0062] If both channels are successfully read, the process proceeds to the signature stage. Using the inspection challenge factor C generated in step one as the unified signature text, two independent asymmetric signature operations are performed: First-way signature: The device's logical signature private key SK_logic (pre-stored in the terminal's isolated storage area) corresponding to the logical identity code ID_logic is invoked to perform an ECDSA asymmetric signature operation on the original signature C, outputting logical verification response data Sig_logic = Sign(SK_logic, C). The logical public key index identifier IDX_logic is embedded in this Sig_logic, used for matching the corresponding public key during subsequent signature verification.

[0063] The second signature method involves calling the device's physical signature private key SK_physical (pre-programmed into the NFC chip and unreadable) corresponding to the physical unique identifier ID_physical. This private key is then used to independently perform an ECDSA asymmetric signature operation on the same original signature text C, outputting physical verification response data Sig_physical = Sign(SK_physical, C). The physical public key index identifier IDX_physical is embedded within this Sig_physical.

[0064] The two signature operations run in isolated memory spaces, with intermediate states not exposed to each other, ultimately forming a two-factor signature response sequence {Sig_logic, Sig_physical}.

[0065] III. Local Trusted Signature Verification and Event Encapsulation The two signature response data streams generated in step two, Sig_logic and Sig_physical, are unidirectionally transmitted to the isolated secure zone of the Trusted Execution Environment (TEE). The TEE is built based on ARM TrustZone technology and is hardware isolated from the ordinary execution environment (REE) of the inspection terminal.

[0066] Within the TEE, message format and integrity checks are first performed on Sig_logic and Sig_physical, respectively. After successful checks, the structured fields of both response data are parsed, and the corresponding signature value segment, public key index identifier segment, and signature timestamp segment are extracted. Let the signature timestamp extracted from Sig_logic be T_sig_logic, and the signature timestamp extracted from Sig_physical be T_sig_physical.

[0067] Retrieve the pre-built, non-exportable device public key certificate set within the TEE. This certificate set is written to the TEE's persistent storage area during device manufacturing or registration and cannot be read externally. Based on the extracted public key index identifier IDX_logic, match the corresponding logical signature public key PK_logic in the certificate set; match the corresponding physical signature public key PK_physical based on IDX_physical.

[0068] Perform ECDSA verification on the signature value segment of Sig_logic using PK_logic to recover the original digest data corresponding to the signature, denoted as D_logic_recovered, i.e., D_logic_recovered = Verify(PK_logic, Sig_logic). Theoretically, D_logic_recovered should be equal to Hash(C). Perform the same verification operation on the signature value segment of Sig_physical using PK_physical to recover D_physical_recovered = Verify(PK_physical, Sig_physical).

[0069] Next, a hash tree comparison is performed. Using D_logic_recovered and C as two leaf nodes, SHA-256 operations are performed on each to generate leaf hash values ​​H_leaf_L1 and H_leaf_L2. H_leaf_L1 and H_leaf_L2 are concatenated in a preset fixed order and then subjected to SHA-256 again to generate the root hash value H_root_logic. Following the exact same operation rules and node arrangement order, a binary hash tree is constructed using D_physical_recovered and C to generate the root hash value H_root_physical. H_root_logic and H_root_physical are then compared bit-by-bit with the pre-stored standard verification root hash value H_root_standard within the TEE. If both root hash values ​​match H_root_standard, then both signatures are valid.

[0070] Simultaneously, the offsets of the signature timestamps T_sig_logic and T_sig_physical from the TEE's internal security clock are verified. Let the current security clock timestamp be T_tee, and calculate the offsets Offset_logic = |T_sig_logic - T_tee| and Offset_physical = |T_sig_physical - T_tee|. If both Offset_logic and Offset_physical are less than the preset offset threshold ΔT_offset, then the timeliness is deemed satisfactory.

[0071] After both comparisons pass, C, Sig_logic, Sig_physical, and the local secure clock timestamp T_tee are collected in the secure storage domain of the TEE, and an inspection event packet (Event) is constructed according to the preset message protocol. The Event consists of a three-layer structure: a message header, a service data segment, and a checksum segment. The message header records the protocol version number and event type identifier; the service data segment contains C, Sig_logic, Sig_physical, T_tee, and the corresponding public key index identifier; the checksum segment generates an integrity digest by performing a SHA-256 operation on the entire service data segment to prevent the Event from being tampered with during transmission.

[0072] IV. Dual-chain evidence storage and layered output The inspection terminal submits the Event to the light node of the business consortium blockchain. After receiving the Event, the light node of the consortium blockchain extracts the device identity identifier and inspection permission identifier as verification parameters, performs protocol conversion and message routing through the cross-chain gateway, constructs a standardized verification request message Req_cross with the cross-chain node signature, and forwards it to the corresponding node of the fire supervision filing chain.

[0073] After receiving the `Req_cross`, the fire safety supervision and filing chain node queries the filing and registration status of the fire equipment, the validity period of the inspection qualification, and historical inspection records. Based on this comprehensive assessment, it generates a verification result `Result_audit` and encapsulates it into a verification result message, returning it to the consortium blockchain light node. Upon receiving this message, the consortium blockchain light node first verifies the validity of the supervisory node's signature, then performs a SHA-256 operation on `Result_audit` to generate a supervisory chain verification hash `H_audit = Hash(Result_audit)`. It then associates and binds `Result_audit` and `H_audit` with the original `Event` and writes them to the consortium blockchain's pending processing queue. If `Result_audit` fails, the `Event` is directly rejected and does not proceed to the subsequent evidence storage process.

[0074] After verification, the Event qualifies for evidence storage and is included in the set of blocks to be packaged. A Merkle tree is constructed for all inspection events in the set in submission order, and a Merkle root hash H_merkle is generated layer by layer. The block-producing node assembles the block header information, which includes: block version number Ver, on-chain unified timestamp T_block, block height H_block, previous block hash H_prev, Merkle root hash H_merkle, and regulatory chain verification hash H_audit. After the block-producing node performs a signature confirmation on the entire block header, it broadcasts the complete block to the entire consortium blockchain network. Each node verifies the block's legality and data consistency and then synchronously writes it to its local distributed ledger, completing the block's on-chain solidification. Thus, the same inspection evidence is simultaneously anchored to both the business consortium blockchain and the fire safety supervision filing blockchain, achieving dual-chain interlocking evidence storage. Tampering with data on either chain will be detected by the hash verification of the other chain.

[0075] After the evidence is stored, the results are output hierarchically according to the access node's permission level. The system has a preset three-level permission mapping rule: The first level corresponds to the inspection execution end. When the inspection execution end node queries, the system calls the zero-knowledge proof protocol to generate a compliance verification credential ZKP = ZKProof(Event) containing only the "compliant / non-compliant" conclusion. It does not contain any original signature, identity information, or location details, and is used by the inspection personnel to confirm the results on-site.

[0076] The second level corresponds to the operation and maintenance management end. When the operation and maintenance management end node queries, the system performs anonymization processing on sensitive fields in the Event, removing core signature data such as Sig_logic and Sig_physical, as well as the identity and privacy information of inspection personnel, and outputs a structured report of equipment status assessment and operation and maintenance suggestions, so that operation and maintenance personnel can understand the overall health of the equipment.

[0077] The third level corresponds to the regulatory enforcement end. When a regulatory enforcement node queries, the system grants access to view and download the full original Event package, complete dual-signature evidence, and spatiotemporal data (including location trajectory, check-in and check-out times, etc.) for regulatory departments to use for auditing, evidence collection, and enforcement.

[0078] It should be noted that the SHA-256 hash algorithm, ECDSA signature algorithm, ARMTrustZone trusted execution environment, and Merkle tree structure used in this embodiment are all mature technologies in the field, and their specific implementation details do not affect the substantive content of this invention. The aforementioned letter parameters (such as ID_user, SK_terminal, Rnd, C, Sig_logic, H_audit, etc.) are only used to indicate the generation and transmission relationship of each data unit. In actual implementation, the length, format, and specific encoding method of each parameter can be flexibly selected according to engineering requirements.

[0079] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A fire protection anti-tampering inspection method based on consortium blockchain, characterized in that, Includes the following steps: A one-time dynamic random factor is obtained from a light node of the consortium blockchain, and a single valid inspection challenge factor is generated by combining the identity credentials with the device geofence verification hash. Using the inspection challenge factor as the original signature, obtain the device QR code logical encoding and near-field communication physical identifier, and perform asymmetric signatures respectively to generate logical and physical verification response data; The signature verification operation is completed on the two verification response data. After hash tree comparison and time offset verification, the data is encapsulated to generate an inspection event packet with a secure time stamp. The inspection event package is submitted to the consortium blockchain, and the verification of the fire supervision filing chain is used as a consensus prerequisite. The verification hash anchors the block header to complete the dual-chain interlocking and storage, and the results are output in layers according to the node permissions.

2. The method according to claim 1, characterized in that, The process of obtaining the one-time dynamic random factor includes: Read the digital identity certificate digest of the inspection personnel and the geofence hash field of the device corresponding to the current location, and assemble them into an encrypted request message after performing asymmetric encryption; The encrypted request message is uploaded to the light node of the consortium blockchain for decryption. The on-chain registration of the inspector's identity and the pre-stored validity of the fence information are verified. After the verification is passed, the one-time dynamic random factor is generated.

3. The method according to claim 1, characterized in that, The specific process of verifying the hash of the geofence includes: Each fire-fighting device is pre-bound to a preset effective geographical area for inspection, and a grid mapping process is performed. The area boundary coordinates, effective coverage radius, device location number and area effective period information are combined. The complete spatial data generated after combination is subjected to a one-way hash operation to generate a device geofence verification hash value and pre-store it in the consortium blockchain. The terminal location is obtained in real time. When the terminal location falls into the preset effective geographical area for inspection, a dynamic random factor application is initiated.

4. The method according to claim 1, characterized in that, The process of obtaining the QR code logical encoding and near-field communication physical identifier includes: Simultaneously activate the QR code parsing channel and the near-field communication reading channel, and enable timeout control based on the terminal's unified security clock; if any channel fails to read, timeout is missing, or data verification fails, the inspection is deemed to have failed, and the inspection process is terminated after generating an abnormal event record. The QR code parsing channel generates a QR code logical code for the equipment's backend registration based on the fire equipment's logical QR code; the near-field communication reading channel reads the fixed data of the fire equipment's built-in chip, verifies the chip's original manufacturer's identity certificate, and then extracts the near-field communication physical identifier.

5. The method according to claim 1, characterized in that, The specific process of the asymmetric signature includes: Using a single valid inspection challenge factor as the original signature text, an asymmetric signature operation is performed on the original signature text to output logical verification response data containing logical identity features; the same original signature text is independently processed to output physical verification response data containing hardware identity features; the two signature operations run in mutually isolated memory spaces, with intermediate states not exposed to each other, and each embeds its corresponding public key index identifier to form a two-factor signature response sequence.

6. The method according to claim 1, characterized in that, The specific process of the signature verification calculation includes: The structured fields in the preset format of the two response data are parsed, and the corresponding signature value segment, public key index identifier segment and signature timestamp segment are extracted respectively; Asymmetric signature verification operations are performed on the two signature value segments respectively to recover the original digest data corresponding to each signature, which is then used as input for subsequent hash tree comparison.

7. The method according to claim 1, characterized in that, The pass / fail determination process for the hash tree comparison includes: For the original digest data recovered from the signature corresponding to the logical verification response data, together with the inspection challenge factor, they form two leaf nodes of a binary hash tree. One-way hash operation is performed on each of the two leaf nodes. The two leaf hash values ​​generated are concatenated in a preset fixed order and then one-way hash operation is performed again to generate the corresponding root hash value. According to the same operation rules and node arrangement order, a binary hash tree is constructed for the original digest data corresponding to the physical verification response data and the inspection challenge factor to generate the corresponding root hash value. The root hash values ​​of the two hash trees are compared bit by bit with the pre-stored standard verification root hash value.

8. The method according to claim 1, characterized in that, The encapsulation process of the inspection event packet includes: It collects three types of core data: single-valid inspection challenge factors, two-way verification response data, and local security clock timestamp; it performs field mapping and sequential arrangement according to the preset message protocol to construct a three-layer structure of message header, business data segment, and verification segment.

9. The method according to claim 1, characterized in that, The specific implementation process of the consensus preconditions includes: After receiving the inspection event packet, the light node of the consortium blockchain extracts the device identity identifier and inspection permission identifier as verification parameters and constructs a standardized verification request message with cross-chain node signature. Verify the validity of the cross-chain node signature, then perform a one-way hash operation on the verification result to generate the regulatory chain verification hash. Associate and bind the verification result and the regulatory chain verification hash with the inspection event package, and synchronously write them into the business consortium chain pending queue.

10. The method according to claim 1, characterized in that, The specific process of the dual-chain interlocked evidence storage includes: The inspection event packages that are eligible for evidence storage are included in the current set of blocks to be packaged. A Merkle tree is constructed for all inspection events in the set in the order of submission, and Merkle root hash values ​​are generated by performing layer-by-layer operations. Assemble the block header information, including the block version number, on-chain unified timestamp, block height, previous block hash value, Merkle root hash value, and regulatory chain verification hash. The block-producing node performs a signature confirmation on the block header. The block-producing node broadcasts the complete block to the entire consortium chain network. After each node verifies the legality of the block and the consistency of the data, it synchronously writes it into the local distributed ledger to complete the chain-based solidification, realizing the dual-chain interlocking of the business chain and the regulatory chain.

11. The method according to claim 1, characterized in that, The specific process of generating the hierarchical output results includes: The system pre-defines three levels of permission mapping rules, corresponding to the inspection execution end, the operation and maintenance management end, and the regulatory enforcement end, respectively. For the inspection execution end, it generates compliance verification credentials containing only compliance conclusions. For the operation and maintenance management end, it performs sensitive field desensitization processing and outputs equipment status and operation and maintenance suggestion reports. For the regulatory enforcement end, it grants access to view and retain all original event packages, complete signature evidence, and spatiotemporal data.

12. A fire protection anti-tampering inspection system based on consortium blockchain, characterized in that, To implement the method as described in claims 1-11, comprising: The dynamic challenge generation module is configured to obtain a one-time dynamic random factor from the light node of the consortium blockchain when the inspection starts, and combine it with the operator identity credentials and the device geofence verification hash to generate a single valid inspection challenge factor. The dual-channel signature response module is configured to use the inspection challenge factor as the signature text, obtain the device QR code logical encoding and near-field communication physical identifier, perform asymmetric signature operations respectively, and generate two outputs: logical verification response data and physical verification response data. The trusted execution environment signature verification module is configured to perform signature verification operations on the two verification response data within the trusted execution environment, and to perform hash tree comparison and time offset verification. The event encapsulation module is configured to encapsulate the data after signature verification into an inspection event package with a secure time stamp; The consortium blockchain submission and evidence storage module is configured to submit the inspection event package to the consortium blockchain and use the fire supervision filing chain verification as a consensus prerequisite, and verify the hash anchored block header to complete the dual-chain interlocked evidence storage. The hierarchical output module is configured to output the evidence storage results hierarchically according to node permissions.

Images