Offline timing evidence storage method and apparatus for robotic systems

Abstract

The application discloses an offline timing evidence storage method and device for a robot system, relates to the technical field of data evidence storage, industrial security forensics and information security, and solves the problems that the existing offline evidence storage technology cannot simultaneously meet the timing consistency, sequence non-forgery, tampering localization and long-term verifiability, and can cope with extreme risks such as master control of the controlled, storage tampering and repeated power failure in an offline environment. The application realizes nanosecond-level timing consistent accident snapshots through a hardware same-edge latching module, executes atomized anchoring transactions in a secure isolation computing unit, integrates a hardware monotonic increasing sequence as a physical anchor into digest calculation, cooperates with a two-phase commit, hierarchical storage and password agile migration mechanism, and realizes offline timing irreversible evidence storage. The application can complete offline self-verification without network consensus, can accurately locate the tampering position, guarantees that the evidence chain is long-term verifiable, and is suitable for high-security evidence storage scenes such as industrial equipment fault offline forensics.

Description

Technical Field

[0001] This application belongs to the fields of data storage, industrial security evidence collection and information security technology, specifically involving offline time-series evidence storage methods and devices for robot systems, which are particularly suitable for scenarios such as instantaneous offline evidence collection of industrial equipment failures, high-security-level offline data anti-tampering evidence collection, and trusted time-series recording in environments without network access. Background Technology

[0002] In fields such as industrial control, intelligent equipment, and critical infrastructure, instantaneous records of equipment failures and safety incidents are crucial evidence for post-incident attribution, liability determination, and compliance audits. These scenarios commonly involve offline environments characterized by network outages, internal network isolation, and the inability to respond to network events during the immediate aftermath of an incident. They also face extreme risks such as compromised control devices, tampering with storage media, and repeated power outages and communication retries. Existing evidence storage technologies cannot simultaneously meet the core requirements of temporal consistency, unforgeable sequences, tamper-proof locatability, and long-term verifiability. Specific shortcomings are as follows: I. Technical Challenges Faced by Network Consensus-Based Evidence Preservation Approaches in Specific Scenarios Relying on blockchain network consensus, online timestamp services, or external trusted third-party notation solutions cannot provide continuously usable temporal proofs in offline industrial settings. Industrial robots, servo drives, and other equipment experience failures within microseconds, leaving no time to wait for network consensus to complete. Furthermore, storing data summaries on the blockchain may expose sensitive business characteristics, introducing technical requirements for data compliance and the risk of trade secret leakage.

[0003] II. Technical Challenges of Software-Linked Summarization in Specific Scenarios Existing software-based chained digest schemes face limitations, not in the lack of security of the digest algorithms themselves, but in the fact that the sequence number and insertion position are software-controllable information, unconstrained by physical irreversibility. In scenarios where the master device (master processor) is controlled, attackers can completely hide record deletions through an attack sequence of "deleting a detrimental record → modifying the sequence number of subsequent records → recalculating the entire chained digest from the deletion position." The verification end will never know the true number and integrity of the records. This is because the sequence number is generated by software and can be arbitrarily rewritten, and the preceding digest can be recalculated by the attacker; there is no technical requirement for physical anchoring constraints.

[0004] III. Technical Challenges Faced by Single-Signature Schemes in Specific Scenarios The fundamental problem with existing single-signature schemes based on secure elements is not the insufficient strength of the signing key, but rather that signing is an independent operation on a single record. Signing only a single record can at most prove that "the content existed at the time of the signature." However, if an irreversible sequence number state and a previous chain state are not simultaneously bound within the security boundary, attack paths such as record insertion, rearrangement, forking, and inconsistencies in the state during power outage windows cannot be ruled out. Attackers can arbitrarily delete, insert, and rearrange records, and the signature of each record remains valid. If the secure element does not maintain an irreversible sequence number state, attackers can also forge records by replaying old data or create intermediate states where the signature and storage are inconsistent during power outage windows.

[0005] IV. Technical Challenges Faced by Software Sequential Data Acquisition in Specific Scenarios Existing multi-source signal acquisition schemes face limitations, not in insufficient sampling frequency, but in the fact that sampling occurs within a 50-500μs time window, employing software sequential reading to acquire multiple signals. When a fault occurs within this sampling window, the resulting snapshot mixes some channel values ​​from before the fault with others from after, forming a "stitched snapshot." All physical quantities in this snapshot never existed simultaneously at any given physical moment in the real world, making accurate causal inference impossible in post-event analysis and potentially leading to misjudgments of the accident's cause.

[0006] The aforementioned technical challenges are cited in documents such as "RFC 3161 Linked Timestamping" and "Merkle Tree". In summary, existing technologies generally lack a unified technical solution of "physical state anchoring + temporal consistency sampling + atomic update", and cannot simultaneously achieve the core objectives of temporal consistency snapshot, non-forgeable sequence proof, tamper-tamper locatability, and long-term sustainable verification in offline extreme environments.

[0007] Additionally, please refer to Table 1 below, which is a four-dimensional comparison table of key differences with existing related technologies.

[0008] Table 1. Four-dimensional comparison of key differences with existing related technologies.

[0009] Therefore, the technical solution of this application is not a simple combination of the aforementioned prior art, but rather a reconstruction of the physical basis for sequence number generation, atomicity guarantee, and power-down recovery at the hardware circuit level, representing an innovation in a different technical dimension. The aforementioned four prior art technologies all rely on software protocols as the basis for atomicity and sequence number control, which carries the theoretical risk of protocol layer penetration and engineering limitations in high-frequency scenarios. This application, through the combination of the dedicated hardware circuit AECU state machine and the MC / PDR hardware register within the SICU, sinks these capabilities from the software protocol layer to the hardware circuit layer, constituting the essential inventiveness that distinguishes this application from the prior art. Summary of the Invention

[0010] This application aims to overcome the above-mentioned deficiencies of the prior art and provides an offline temporal evidence storage method and apparatus for robot systems.

[0011] In a first aspect, embodiments of this application provide an offline temporal evidence storage method for a robot system, applied to an offline temporal evidence storage system for a robot system. The system includes a host processor, a secure isolated computing unit (SICU), and a non-volatile storage medium. The method includes: responding to a trigger event, having a hardware simultaneous edge-freezing sampling unit simultaneously capture and latch N input signals into an internal register on the same rising clock edge to generate snapshot data, wherein the clock enable of the hardware simultaneous edge-freezing sampling unit is gated off after latching, and the snapshot data remains frozen until an unlock confirmation is received; calculating the payload hash of the snapshot data through the host processor and sending an anchoring transaction request to the secure isolated computing unit, wherein the anchoring transaction request does not contain a sequence number parameter or a preorder digest parameter, and the host processor cannot specify the insertion position of the record; and executing an atomic anchoring transaction AT within its hardware security boundary through the secure isolated computing unit, wherein the atomic anchoring transaction is a hardware-uninterruptible transaction, executed in an indivisible manner. The following operations are performed: The current value of the hardware increment register (MC) is read internally as an unforgeable physical anchor number; the digest value of the previous record stored in the pre-order digest register (PDR) is read internally; the current value of the hardware increment register and the stored value of the pre-order digest register are integrated into the digest calculation to generate the current record digest, ensuring that deleting any record will inevitably lead to sequence number skipping or chain digest mismatch during verification; the current record digest is signed using a non-exportable device key within the secure isolated computing unit to generate a transaction receipt; a two-phase commit update is performed with a power-loss indivisible guarantee, ensuring that the hardware increment register completes unidirectional increment and the pre-order digest register is updated to the current record digest, guaranteeing that after any power failure, the states of the hardware increment register and the pre-order digest register simultaneously maintain the old value before commit or simultaneously update to the new value after commit, without any mixed intermediate states; wherein, the external interface of the secure isolated computing unit does not provide sequence number writing parameters and pre-order digest writing parameters, and the hardware increment register only allows unidirectional increment and has no external write path.

[0012] Furthermore, the system also includes a hardware edge-locked latch module (HSL), and the method further includes: writing a publicly verifiable metadata area P0 containing the current record sequence number, current record digest, and transaction receipt, as well as an encrypted payload area, into a non-volatile storage medium via the main control processor, and sending an unlock confirmation to the hardware edge-locked latch module after successful writing; verifying the validity of the transaction receipt, the continuity of the sequence number, and the consistency of the chain digest sequentially based on the sequence data in the publicly verifiable metadata area via an offline verification terminal, and outputting the first abnormal position and abnormal type, thereby achieving hardware-forced unreconstructable offline sequence proof.

[0013] Furthermore, the hardware same-edge frozen sampling unit includes an N-way edge-triggered D flip-flop array that shares the same clock line in the hardware same-edge latch module.

[0014] Furthermore, the D flip-flop array of the hardware edge latch module HSL adopts an equal-length clock distribution structure that ensures the upper limit of the clock arrival deviation δ_skew for each channel is ≤ 10ns, including H-tree, Mesh, Spine clock distribution, or symmetrical buffer daisy chain; the upper limit δ_skew remains valid in the industrial temperature range of -40℃ to +85℃ and under the full PVT angle with power supply voltage fluctuation of ±10%, and the delay deviation of a single-stage clock buffer does not exceed 2ns.

[0015] Furthermore, the hardware increment register and the preceding digest register are configured with only an external read path and no external write path in the hardware register address decoder of the secure isolation computing unit.

[0016] Furthermore, the hardware edge latch module HSL has a built-in hardware timeout watchdog. If no unlock confirmation is received from the Host after a preset time window Tmax has elapsed since entering the LOCKED state, the SICU internal collaborative hardware will automatically unlock the device and forcibly generate a special anchor record with record_type = AUTO_UNLOCK and write it into the evidence chain, so that the offline verification end can identify this abnormal unlock event.

[0017] Optionally, the preset time window Tmax ≥ AT execution budget + NVM write budget + safety margin.

[0018] Furthermore, in the two-phase commit update, Phase A is the shadow write phase, which writes the preceding summary shadow register and the transaction marker bit and completes the non-volatile memory refresh. If a power failure occurs during this phase, the system will roll back to the old state before the commit after power is restored. Phase B is the commit activation phase, which executes indivisible sub-operations in the following strict order: write the transaction marker bit TXN_marker.phase = 2 and complete the non-volatile memory refresh flush_nvm(); perform the atomic increment of the hardware increment register MC; switch the preceding summary register PDR from the shadow register PDR_shadow to commit; clear the transaction marker bit and complete the final flush_nvm(); if a power failure occurs after any sub-step, the compensation action is determined by a two-dimensional comparison between the TXN_marker phase value and the measured value of MC after power is restored.

[0019] Furthermore, the secure isolation computing unit maintains the cache information of the last successfully submitted transaction. For duplicate anchored transaction requests that completely match the payload hash and snapshot fingerprint, it directly returns the previously generated transaction receipt without performing the increment operation of the hardware increment register, thus preventing semantic ambiguity of the sequence number caused by communication retries.

[0020] Furthermore, the device key used for signing is stored in a non-exportable storage area inside the secure isolated computing unit, or it is derived from the physically unclonable function PUF of the secure isolated computing unit combined with a fuzz extractor, and is never output to the outside of the security boundary in plaintext form throughout the process.

[0021] Furthermore, the publicly verifiable metadata area includes self-description fields for hash algorithm identifier, signature algorithm identifier, key version, policy number, and record type. All self-description fields are bound to the calculation input of the current record digest to prevent metadata from being tampered with afterward.

[0022] Furthermore, a sensitive payload area is set in the non-volatile storage medium, and the sensitive payload area is encrypted using a t-of-n threshold encryption scheme, requiring no less than t legitimate shares to complete decryption, thereby achieving controllable disclosure of data.

[0023] Furthermore, the security isolation computing unit internally maintains a policy version increment register pv_mc. When decrypting and restoring the threshold share, it only accepts shares whose key version and policy version are not lower than the value of the current policy version increment register, rejects the injection of old version shares, and prevents policy rollback attacks. The authentication tag verification of the threshold share is bound to policy_id / key_version.

[0024] Furthermore, when latching snapshot data, the hardware edge latching module generates a snapshot fingerprint of no less than 32 bits, snap_fp, in parallel using a CRC-32 combinational logic circuit based on an LFSR array. The input of the snapshot fingerprint includes N channel data and their channel position codes, and the snapshot fingerprint is bound to the calculation input of the current record digest.

[0025] Furthermore, the width of the snapshot fingerprint (snap_fp) can be extended to 64 bits or 128 bits, achieved by SHA-256 truncated output.

[0026] Furthermore, when the hash algorithm, signature algorithm is upgraded or the key is rotated, a special migration anchor record is generated. The migration anchor record contains the new algorithm identifier, the new key version, the new public key digest and the effective sequence number boundary. The migration anchor record is at least bridged signed by the old version private key. After the verification end verifies that the bridged signature is successful, the algorithm and key suite used for subsequent verification are updated.

[0027] Furthermore, when generating the transaction receipt, a hybrid dual-signature mode of traditional digital signature and quantum-resistant digital signature is adopted, generating two types of signatures simultaneously and storing them in a publicly verifiable metadata area to achieve smooth migration resistant to quantum attacks.

[0028] Furthermore, the method also includes: if any record in the stored record sequence is deleted, the offline verification terminal detects the sequence number jump, accurately locates the position of the first missing record, and outputs the corresponding exception type.

[0029] Furthermore, the hardware increment register is implemented based on a one-time programmable OTP fuse array or an eMMCRPMB hardware increment register, and physically only supports unidirectional increment, and cannot be rolled back or reset.

[0030] Furthermore, the secure isolation computing unit is equipped with an atomic execution and submission unit (AECU) state machine. During the execution of a transaction with busy=1, the state machine physically blocks the input of new anchor transaction requests through hardware AND gates, thereby ensuring the exclusive execution of atomic anchor transactions.

[0031] Furthermore, the AECU state machine includes an ABORT exception exit path; when a hardware exception occurs in any of the LOAD / COMPUTE / SIGN / COMMIT_A / COMMIT_B stages, the state machine is forcibly switched to the ABORT state, the hardware clears all intermediate states, keeps the MC and PDR registers unchanged, clears the busy flag, and returns the ERROR_AT_ABORT status code.

[0032] Furthermore, the Security Isolation Computing Unit (SICU) executes deterministic recovery logic upon power-up: First, it reads the transaction flag bit TXN_MARKER and its CRC checksum and magic number; when the CRC check fails or the magic number does not match, it enters the FORENSIC_HALT forensic shutdown state, rejects new anchor transaction requests, and exposes an abnormal status code; when phase = 0, it enters the ready state; when phase = 1, it executes Phase A rollback; when phase = 2, based on the two-dimensional comparison between the measured MC value and the expected_seq carried in TXN_MARKER, it performs MC increment and / or PDR switching respectively to ensure that the system converges to a unique consistent state after power-up.

[0033] Furthermore, the storage structure of the transaction marker bit TXN_MARKER includes a magic field, a phase field, an expected_seq field, a digest_crc32 field, and a CRC-32 / MAC checksum bit covering it; TXN_MARKER is written to non-volatile storage media with triple redundancy and read using a majority voting mechanism to ensure that single-page damage does not disrupt recovery decisions.

[0034] Furthermore, the offline verification terminal does not require access to online network services, online timestamp services, or trusted third parties throughout the entire process; it completes the entire chain of validity verification solely based on plaintext data from publicly verifiable metadata areas.

[0035] Furthermore, the intermediate state of the atomic anchored transaction is unreadable, unresettable, or has no debug readout during the busy period.

[0036] Furthermore, the snapshot data has nanosecond-level timing consistency.

[0037] Secondly, embodiments of this application provide an offline temporal evidence storage device for a robot system, comprising: a hardware co-edge latch module (HSL), a host processor (Host), a secure isolated computing unit (SICU), and a non-volatile storage medium; wherein, the latch output terminal of the hardware co-edge latch module is directly connected to the snapshot read interface of the host processor via a dedicated data bus; the host processor communicates with the secure isolated computing unit via an anchor transaction bus, which does not physically carry sequence number write signals and preorder digest write signals; the secure isolated computing unit internally integrates a hardware increment register (MC), a preorder digest register (PDR), an atomic execution and submission unit (AECU) state machine, a signature engine, and a non-exportable key storage area; the external read paths for the hardware increment register and the preorder digest register are provided by an internal address decoder, but there are no external write paths; the non-volatile storage medium is connected to the host processor and is used to store a publicly verifiable metadata area and an encrypted payload area.

[0038] Furthermore, the secure isolated computing unit integrates a hardware increment register, a preorder digest register, an atomic execution and submission unit (AECU) state machine, a signature engine, and a non-exportable key storage area. The external interface of the secure isolated computing unit does not have sequence number write parameters or preorder digest write parameters.

[0039] Furthermore, in the LOCKED state, the hardware edge latch module HSL implements gating shielding for external asynchronous reset signals, responding only to unlock confirmation signals from within the SICU that have undergone synchronous processing; external reset commands are physically blocked by combinational logic during the LOCKED state to ensure that the latched snapshot data is not erased by external reset attacks.

[0040] The offline temporal evidence storage method and apparatus for robot systems provided in this application have the following beneficial effects: Achieve nanosecond-level time-consistent snapshots, completely resolving the timing ambiguity defects of software sequential acquisition.

[0041] This application achieves parallel hardware latching by sharing a D flip-flop array on the same clock line through a hardware same-edge latching module. This reduces the sampling deviation of multiple sensors from 50-500μs to less than 10ns, a reduction of 4-5 orders of magnitude. All D flip-flops capture the input level in parallel on the same clock edge, ensuring that the sampling times of all physical quantities in the snapshot are completely consistent at the nanosecond level. This effectively solves the problem of snapshot stitching across physical moments, guaranteeing the authenticity of the instantaneous snapshot of the accident and the accuracy of causal inference.

[0042] Implement offline sequence proofs that are enforced by hardware and cannot be reconstructed, thus addressing the forgery vulnerability of software chained digests.

[0043] This application directly binds the internal MC hardware sequence of the secure isolation computing unit to the digest calculation as a physical anchor point. Combined with an atomic transaction design that eliminates the need for Seq / PrevDigest write parameters on the external interface, sequence number generation is transferred from the software layer to the hardware layer. The MC hardware value is automatically read from the LOAD state of the AECU atomic state machine and integrated into the digest calculation; the main control processor cannot specify or tamper with it. Deleting any record inevitably leads to sequence number skipping during verification, allowing the verification end to precisely locate the missing point. Even if an attacker completely controls the storage medium and obtains all parameters of the hash algorithm, they cannot forge a continuous and valid record chain. This achieves sequence unforgeability through "strong constraints at the physical level" rather than "cryptographic assumptions," enabling offline temporal irreversibility without relying on network consensus.

[0044] To achieve state consistency in power-off scenarios and resolve the intermediate state defect of single-signature schemes.

[0045] This application ensures that after any power outage, the MC and PDR states will always be in the old consistent state before the commit or the new consistent state after the commit, without any mixed intermediate states, and can complete deterministic recovery without manual intervention. At the same time, through the atomic anchor transaction design, the entire process of sequence number reading, previous digest reading, digest calculation, signing, commit update, and counter increment is completed in one go within the security boundary, which ensures the indivisibility of transactions from the hardware level and effectively solves the risk of state inconsistency under power outage windows and interruption scenarios.

[0046] To achieve idempotency in communication retry scenarios and avoid semantic ambiguity of sequence numbers.

[0047] This application uses a transaction caching and duplicate request matching mechanism to directly return the previously generated transaction receipt for duplicate anchored transaction requests that completely match the payload hash and snapshot fingerprint, without performing the MC increment operation. This avoids the repeated incrementing of sequence numbers and semantic ambiguity caused by communication retries and replay attacks, and ensures a one-to-one correspondence between each record and the physical event.

[0048] To achieve controlled disclosure of data and balance the protection of trade secrets with compliance with judicial evidence collection.

[0049] This application adopts a three-level partitioned storage design (P0 / P1 / P2) combined with a t-of-n threshold encryption scheme to achieve fine-grained access control for sensitive payloads. Sensitive data can only be decrypted when at least t legitimate shares are collected. This not only ensures the offline verifiability of public metadata but also avoids the leakage of sensitive business data, while meeting the dual requirements of compliance auditing and trade secret protection.

[0050] To achieve sustainable verification across generations and address the threats posed by algorithm retirement and quantum computing.

[0051] This application integrates metadata such as hash algorithm, signature algorithm, and key version directly into digest calculation through a self-describing field binding mechanism to prevent post-event tampering; it achieves the continuity of the evidence chain during algorithm upgrades and key rotation through migration anchoring record and bridging signature design; it also supports a hybrid dual-signature mode of traditional signature and quantum-resistant signature, which can smoothly complete quantum-resistant migration and ensure the long-term verifiability of the evidence chain for 10-20 years.

[0052] Furthermore, since both the hardware increment register MC and the atomic execution and submission unit AECU in this application are implemented using application-specific hardware circuits, and do not rely on the standard rate limitations of the general-purpose Trusted Platform Module (TPM), the solution in this application can be adapted to high-frequency behavior log scenarios such as high-frequency sampling of robot joint torques (hundreds of Hz to kiloHz) and millisecond-level event-triggered evidence storage in autonomous driving DSSAD. This breaks through the rate limit of approximately once every 5 seconds and the limited write lifetime of existing TPM-based monotonic counter solutions. This high-frequency capability is a key advantage of this application's technical solution in emerging high-security scenarios such as embodied intelligence, autonomous driving, and medical surgical robots.

[0053] Other features and advantages of the embodiments of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the embodiments of this application. The objects and other advantages of the embodiments of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0054] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This paper illustrates the overall architecture and data flow closed-loop diagram of the offline temporal evidence storage system for robot systems provided in an embodiment of this application. Figure 2 A flowchart of an offline temporal evidence storage method for a robotic system is shown, which addresses a fundamental deficiency in the application embodiments. Figure 3 This illustration shows the D flip-flop register array and H-tree clock distribution network diagram in the HSL of this application embodiment; Figure 4 The diagram shows the state machine of the HSL two-level synchronization chain and timing logic locking in an embodiment of this application; Figure 5 This is a schematic diagram of the state transition of the state machine of the atomic execution and submission unit inside the secure isolation computing unit described in this application; Figure 6 The following is a timing diagram of the two-stage commit and power-down recovery provided in an embodiment of this application; Figure 7 This illustration shows a diagram of the P0 / P1 / P2 partition and record structure provided in an embodiment of this application; Figure 8 The flowchart of threshold recovery and policy version increment in an embodiment of this application is shown; Figure 9 This illustration shows a migration anchoring record and bridging signature diagram in an embodiment of this application. Figure 10 The offline verification process and anomaly location output diagram in the embodiments of this application are shown; Figure 11 A schematic diagram of multi-industry channel mapping comparison is shown in the embodiments of this application. Detailed Implementation

[0056] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present application, and not all of them. The components of the embodiments of the present application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of the present application. All other embodiments obtained by those skilled in the art based on the embodiments of the present application without inventive effort are within the scope of protection of the present application.

[0057] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0058] The core terms and symbols used in this specification are defined as follows: Hardware Snapshot Latch (HSL): A hardware circuit based on a D flip-flop array. By using N edge-triggered D flip-flops sharing the same clock line, it forces all input channels to capture input levels in parallel on the same rising edge of the clock, eliminating the snapshot stitching problem across physical moments.

[0059] Secure Isolated Compute Unit (SICU): Implemented via Secure Element (SE), TPM, or SoC secure area, it features protected non-volatile memory and a protected execution environment. Hardware increment register (MonotonicCounter, MC): Located inside the securely isolated computing unit, it only allows unidirectional increment and has no write path to the external interface. The sequence of hardware increment registers directly participates in the digest calculation to form a physical anchor point.

[0060] Prev-Digest Register (PDR): Located in non-volatile memory within a secure, isolated computational unit, it is not writable externally and is updated only by the commit path of atomically anchored transactions.

[0061] AnchorTransaction (AT): An indivisible hardware transaction within a securely isolated computing unit, executing the entire process of "internal read sequence number → internal read previous sequence → digest calculation → receipt signature → consistency commit → counter increment → return proof", with no Seq / PrevDigest write parameters on the external interface.

[0062] Atomic Execution & Commit Unit (AECU): The hardware state machine responsible for executing AT within the securely isolated computing unit, containing seven core states: IDLE→LOAD→COMPUTE→SIGN→COMMIT_A→COMMIT_B→RESP, as well as the REPLAY idempotent recovery path.

[0063] δ_skew: The upper bound of the sampling arrival time deviation of each channel of the hardware edge latch module, which is determined by the clock tree and wiring constraints, with a typical value ≤10ns.

[0064] P0 / P1 / P2: Tiered storage partitions, P0 is the publicly verifiable metadata area (plaintext), P1 is the general encrypted payload area, and P2 is the sensitive threshold encryption area.

[0065] The systems, devices, and methods described in this application are applicable to, but not limited to, the following safety-critical event evidence storage scenarios for robot systems: ① Industrial robots (including collaborative robots, AGVs, and AMRs); ② Humanoid robots and embodied intelligent systems (including bipedal / quadrupedal / wheeled humanoids); ③ Intelligent driving vehicles and onboard EDR / DSSAD systems; ④ Power dispatching and intelligent substation monitoring systems; ⑤ Medical robots (including surgical, rehabilitation, and nursing robots); and ⑥ Special robots, including but not limited to: explosion-proof robots (petrochemical, mining, and coal mining), underwater robots (including ROVs, AUVs, and deep-sea operation robots), aerial unmanned aerial vehicle systems (including industrial-grade, inspection-grade, plant protection-grade, and military UAVs), fire-fighting and rescue robots, nuclear industry robots (including nuclear power plant decommissioning and nuclear emergency response), power line inspection robots, earthquake / mine rescue robots, agricultural special operation robots, chemical defense and anti-terrorism robots, etc. Those skilled in the art can adapt the core architecture of this invention (hardware latch array HSL + security element SE + offline timing proof mechanism) to any of the above specific application scenarios without inventive effort.

[0066] Please see Figure 1 , Figure 1 The diagram illustrates the overall architecture and data flow closed loop of the offline temporal evidence storage system for robot systems provided in this application embodiment. Figure 1 Specifically, it includes a main control processor 105, a secure isolation computing unit 108, and a non-volatile storage medium 114. The main control processor includes a main control core, a hash engine, and a storage interface driver. The non-volatile storage medium includes a PO public metadata area, a P1 payload area, and a P2 sensitive area.

[0067] In addition, the hardware edge-locked latch module includes an N-way D flip-flop, a CRC32 fingerprint generator, and a locking state machine. The secure isolation computing unit includes a hardware increment register, a preorder digest register, an atomic transaction state machine, a signature engine, and a non-derivative key.

[0068] The offline temporal evidence storage method for robot systems provided in this application can be applied to... Figure 1 The image shows an offline temporal evidence storage system for robotic systems. Please refer to [link / reference]. Figure 2 , Figure 2 A flowchart of an offline temporal evidence storage method for a robot system provided in an embodiment of the application is shown. The method may include steps S110 to S130.

[0069] Step S110: In response to the trigger event, the hardware same-edge freeze sampling unit performs parallel capture of N input signals on the same rising edge of the clock and latches them into the internal register to generate snapshot data. The clock enable of the hardware same-edge freeze sampling unit is gated off after latching is completed, and the snapshot data remains frozen until an unlock confirmation is received.

[0070] Step S120: The main control processor calculates the payload hash of the snapshot data and sends an anchor transaction request to the secure isolation computing unit. The anchor transaction request does not contain a sequence number parameter or a previous digest parameter, and the main control processor cannot specify the insertion position of the record.

[0071] Step S130: The secure isolation computing unit executes an atomic anchor transaction AT within its hardware security boundary. This atomic anchor transaction is a hardware-uninterruptible transaction, and it sequentially performs the following operations in an indivisible manner: internally reading the current value of the hardware increment register as an unforgeable physical anchor sequence number; internally reading the digest value of the previous record stored in the preceding digest register; integrating the current value of the hardware increment register and the stored value of the preceding digest register into the digest calculation to generate the current record digest, ensuring that deleting any record will inevitably lead to sequence number skipping or chain digest mismatch during verification; using the secure isolation computing unit... An internally non-exportable device key signs the current record digest, generating a transaction receipt. A two-phase commit update is performed with a power-loss indivisible guarantee, ensuring that the hardware increment register completes unidirectional incrementing and the preceding digest register is updated to the current record digest. This guarantees that after any power failure, the hardware increment register and the preceding digest register simultaneously retain their pre-commit values ​​or simultaneously update to their post-commit values, without any mixed intermediate states. The external interface of the secure isolated computing unit does not provide sequence number write parameters or preceding digest write parameters, and the hardware increment register only allows unidirectional incrementing and has no external write path. Please continue reading. Figure 1 ,exist Figure 1 The system also includes a hardware synchronous latch module 101. N sensor inputs are connected to this module to provide trigger events and support multiple sensors. N can be configured from 8 to 32 depending on the application scenario.

[0072] Optionally, steps S140 and S150 may be included after step S130.

[0073] Step S140: The main control processor writes the publicly verifiable metadata area P0, which includes the current record number, current record summary, and transaction receipt, as well as the encrypted payload area, into the non-volatile storage medium, and sends an unlock confirmation to the hardware edge latch module after successful writing.

[0074] Step S150: Based on the sequence data in the publicly verifiable metadata area, the offline verification terminal sequentially verifies the validity of the transaction receipt, the continuity of the sequence number, and the consistency of the chain digest, and outputs the first abnormal position and abnormal type, thereby realizing the hardware-forced unreconstructable offline sequence proof.

[0075] Optionally, the hardware same-edge frozen sampling unit includes an N-way edge-triggered D flip-flop array sharing the same clock line in the hardware same-edge latch module.

[0076] Optionally, the snapshot data has nanosecond-level timing consistency.

[0077] Please continue reading. Figure 1 ,exist Figure 1 When industrial equipment experiences events such as collisions, overcurrents, or safety interruptions, it outputs trigger signals to the hardware synchronous latch module. The hardware synchronous latch module, through a D flip-flop array sharing the same clock line, performs parallel capture and latching of N input signals on the same rising edge of the clock, generating nanosecond-level time-consistent snapshot data and snapshot fingerprints. Simultaneously, it enters a locked state, freezing the snapshot data. The main control processor reads the snapshot data and snapshot fingerprint locked by the hardware synchronous latch module, calculates the payload hash of the snapshot data, and sends an anchor transaction request to the securely isolated computing unit. The request only contains the payload hash, snapshot fingerprint, and metadata, excluding the sequence number parameter. With the preceding digest parameters; the secure isolation computing unit executes atomic anchored transaction (AT) within the security boundary, completing the entire process of sequence number reading, preceding digest reading, digest calculation, signing, two-phase commit, and counter incrementing, and returns the current record sequence number, current record digest, transaction receipt, and execution status to the main control processor; after receiving the response that the AT has been successfully executed, the main control processor writes the publicly verifiable metadata of P0, the encrypted payload of P1, and the threshold encrypted sensitive data of P2 to the non-volatile storage medium; after the storage write is successful, the main control processor sends an unlock confirmation to the hardware edge latch module, the hardware edge latch module unlocks the state, and enters the next round of sampling ready state.

[0078] In other words, through the snapshot latching process: in response to triggering events such as collisions, overcurrents, and safety interruptions in industrial equipment, the N-way edge-triggered D flip-flop array in the hardware edge-triggered latching module, which shares the same clock line, captures and latches the N input signals in parallel to the internal register on the same rising edge of the clock, generating snapshot data; after latching is completed, the clock enable of the D flip-flop array is gated off, and the snapshot data remains frozen until an unlock confirmation is received, ensuring that a single triggering event corresponds to a unique snapshot.

[0079] Then, the request is sent as follows: The main control processor reads the locked snapshot data, calculates the payload hash of the snapshot data, and sends an anchor transaction request to the secure isolation computing unit. This request only contains the payload hash, optional snapshot fingerprint, metadata, etc., and does not contain the sequence number parameter and the previous summary parameter. The main control processor cannot specify the insertion position of the record through the external interface, thus avoiding the risk of software-controllable sequence number tampering from the root.

[0080] The atomic transaction execution steps are then performed: the secure isolated computing unit executes an atomic anchor transaction (AT) within its hardware security boundary. This transaction is a hardware-uninterruptible transaction and is executed sequentially in an indivisible manner: internally, the current value of the hardware increment register is read as an unforgeable physical anchor sequence number; internally, the digest value of the previous record stored in the preceding digest register is read; the current value of the hardware increment register and the value stored in the preceding digest register are integrated into the digest calculation to generate the current record digest, ensuring that deleting any record will inevitably lead to a sequence number skip or chain digest mismatch during verification; the current record digest is signed using an internal, non-exportable device key to generate a transaction receipt; and a two-phase commit update is performed in a power-loss-indivisible manner, ensuring that the hardware increment register completes unidirectional increment and the preceding digest register is updated to the current record digest, guaranteeing that after any power failure, the states of the hardware increment register and the preceding digest register either simultaneously retain the old values ​​before the commit or simultaneously update to the new values ​​after the commit, without any mixed intermediate states.

[0081] Next, the storage write step is executed: After receiving the AT execution success response, the main control processor writes the publicly verifiable metadata area P0, which contains the current record sequence number, current record summary, and transaction receipt, as well as the encrypted payload area, to the non-volatile storage medium. After successful writing, it sends an unlock confirmation to the hardware synchronous latch module, enabling the hardware synchronous latch module to enter the next round of sampling ready state.

[0082] Finally, the offline verification step is performed: Based on the sequence data in the P0 area, the offline verification terminal verifies the validity of the transaction receipt, the continuity of the sequence number, and the consistency of the chain digest in sequence, and outputs the first abnormal position and abnormal type, realizing the hardware-forced offline sequence proof that cannot be reconstructed, without the need to connect to online network services throughout the process.

[0083] Optionally, a digest function can be defined as Digest_i = H(domain_tag || payload_hash || MC_hw[i] || PDR_hw[i-1] || meta_hash || [snap_fp]). Here, domain_tag is the domain separator prefix, MC_hw[i] is the current value of the hardware increment register, PDR_hw[i-1] is the current value of the preceding digest register (corresponding to the previous record), meta_hash is the hash aggregation of the self-describing field of the publicly verifiable metadata area, and [snap_fp] is an optional input item—it is only included as input in the digest calculation in embodiments with a hardware edge latch module (HSL) configured; embodiments without HSL (such as pure software-triggered evidence storage scenarios) do not include this field.

[0084] The following section will discuss in detail the unhideability of deletion. Specifically, the theorem states: If an attacker deletes the record set D⊂{1,2,...,N}, |D|=k (k≥1), then the verifier will find that there exists a position j such that Seq_j≠Seq_{j-1}+1.

[0085] The proof is as follows: The hardware increment register's hardware value is strictly monotonically increasing: ∀i,MC[i+1]=MC[i]+1; The deletion of records occurs at the storage layer and does not affect the physical increment of the hardware increment registers within the secure isolation computing unit; The sequence of stored records after deletion is: {r_1,r_2,…,r_{Nk}}; The corresponding hardware increment register value sequence (already bound in Digest) is: {MC[1],MC[2],…,MC[j],MC[j+k+1],…}; At the first deletion point j: MC[j+k+1]-MC[j]=k+1>1; The verification end detected a skipped number: Seq_{j+1_store} - Seq_j = k+1 ≠ 1; Output: E_SEQ_GAPatj+1, precisely locating the first deletion point.

[0086] Furthermore, this theorem also has a corollary: chain-like non-reconstructability. Even if an attacker obtains the Hash function H, all payload_hashes, and all metas, they cannot generate a Digest_i' that makes Seq_i' consecutive; the reason is that MC_hw[i] and PDR_hw[i-1] are automatically read by the secure isolated computing unit hardware during AT execution, and the attacker cannot specify them. The combination of the two hardware values ​​makes any forgery attempt produce a Digest mismatch or a Seq skipping number.

[0087] The theorem precondition is that the sub-steps of Phase B are strictly executed in the order of "first write phase=2, then increment MC, then switch PDR, then clear the flag". For a detailed explanation, please refer to the relevant section on Phase B. Under this order, a recoverable transient state S_C = (N, Digest_{N-1}, Digest_N, 2) is added to the system state space: phase=2 has been written, but MC has not yet been incremented. At this time, the power-on recovery logic (see the relevant section on_power_up) performs MC compensation increment and PDR switching by comparing the measured value of MC with TXN_MARKER.expected_seq in two dimensions, eventually converging to S_new. In summary, power-down recovery will inevitably converge to S_old or S_new, and transient states S_A, S_B, and S_C are all mapped back to the steady state by the recovery logic; there are no unrecoverable mixed intermediate states.

[0088] The following section will discuss power-down consistency (i.e., no intermediate state).

[0089] First, we can define the state space: System state vector: S=(MC_val,PDR_val,PDR_shadow,TXN_phase) Steady-state space (the state during normal operation): S_old=(N,Digest_{N-1},-,0) / / The (N-1)th record has been submitted. S_new=(N+1,Digest_N,-,0) / / The Nth record has been submitted. Transient space (state during the commit process, which may be captured during power failure): S_A=(N,Digest_{N-1},Digest_N,1) / / Phase A completed, Phase B not started S_B=(N+1,Digest_N,Digest_N,2) / / Phase B complete, clearing markers incomplete Specifically, the theorem states: ∀At the time of power failure t, after recovery, the system state ∈ {S_old, S_new} does not have a third intermediate state. Here, S_old=(N,Digest_{N-1},-,0) is the old state after the (N-1)th record has been submitted, and S_new=(N+1,Digest_N,-,0) is the new state after the Nth record has been submitted.

[0090] The proof is as follows: If the power outage occurs before Phase A: the state remains S_old and no recovery is required; If the power failure occurs during Phase A: if TXN_marker.phase has not been written, the state remains S_old; if TXN_marker.phase=1 has been written, the recovery logic clears PDR_shadow and TXN_marker, and returns to S_old. If the power failure occurs after Phase A is completed and before Phase B begins: TXN_marker.phase=1, the recovery logic executes rollback_to_S_old(), returning to S_old; If the power failure occurs during Phase B: if the hardware increment register has not incremented, then TXN_marker.phase remains 1, and rollback to S_old is executed; if the hardware increment register has incremented and TXN_marker.phase=2, then the recovery logic executes commit_to_S_new(), converging to S_new. If the power failure occurs after Phase B is completed but before the marker is cleared: the system has actually reached S_new, the recovery logic confirms the completion of the submission, and maintains S_new.

[0091] In summary, power-down recovery will always converge to either S_old or S_new, and there are no mixed intermediate states.

[0092] Furthermore, in some embodiments, the D flip-flop array of the hardware co-edge latch module HSL adopts an equal-length clock distribution structure that ensures the upper limit of the clock arrival deviation δ_skew for each channel is ≤ 10ns, including H-tree, Mesh grid, Spine clock distribution, or symmetrical buffer daisy chain; the upper limit δ_skew remains valid in the industrial temperature range of -40℃ to +85℃ and under the full PVT angle with power supply voltage fluctuation of ±10%, and the delay deviation of a single-stage clock buffer does not exceed 2ns.

[0093] Please see Figure 3 , Figure 3 The diagram illustrates the D flip-flop register array and H-tree clock distribution network in the HSL of this application embodiment. The D flip-flop array of the hardware edge-locked latch module achieves synchronous clock distribution through a symmetrical H-tree clock distribution network. The clock signal originates from the source, passes through multiple levels of symmetrical buffers and equal-length wiring, and the path delay deviation to the clock end of each D flip-flop is controlled within 2ns. This ultimately achieves an upper bound of sampling arrival time deviation δ_skew ≤ 10ns for each channel, reducing the multi-channel sensor sampling deviation by 4-5 orders of magnitude compared to traditional software sequential sampling, effectively solving the snapshot stitching problem across physical moments.

[0094] pass Figure 3As can be seen, the core of the hardware edge-triggered latch module described in this application is an N-channel edge-triggered D flip-flop register array. All D flip-flops share the same clock input line, and the clock signal is synchronously distributed through an H-tree clock distribution network to ensure that the path delay deviation of the clock signal reaching the clock terminal of each D flip-flop is minimized, ultimately achieving an upper bound of sampling arrival time deviation δ_skew ≤ 10ns for each channel. The D terminal of the D flip-flop is directly connected to the input signal of the corresponding channel, and the Q terminal is connected to the latch output bus, ensuring that the input levels of all channels are captured in parallel at the same rising edge of the clock, effectively solving the timing splicing problem of software sequential sampling.

[0095] Furthermore, in the hardware register address decoder of the secure isolated computing unit, the hardware increment register and the preorder digest register are only configured with external read paths, and there are no external write paths.

[0096] In the hardware register address decoder of the secure isolated computing unit, the hardware increment register and the preorder summary register are only configured with external read paths, with no external write paths. When the main control processor accesses the registers via external buses such as SPI and I2C, it can only read the current values ​​of MC_VAL and the preorder summary register. Any command to write to the address of these registers will be intercepted by the address decoder, returning an ERROR_NO_SUCH_CMD error response. This ensures that the main control processor cannot modify the values ​​of the hardware increment register and the preorder summary register through external commands, thus eliminating the risk of external tampering of the serial number and preorder summary at the hardware level.

[0097] For example, the core register mapping of the secure isolated computing unit described in this application embodiment is shown in Table 2 below. MC_VAL and the preorder digest register only have a read path in the address decoder and no external write path. The main control processor cannot write to the hardware increment register or the preorder digest register via command.

[0098] Table 2 Mapping of Core Registers for the Security Isolation Computing Unit MC_VAL 0x00 64bit RO (external) Increment the current value of the register; externally read-only, internally incrementable. PDR[0:31] 0x10 256bit RO (external) Pre-sequence summary register, externally read-only, internally writable by AECU AT_CMD 0x30 8bit WO Atomic Transaction Command Register AT_STATUS 0x31 8bit RO AT status: 0=IDLE, 1=BUSY, 2=OK, 3=ERROR LAST_SEQ 0x40 64bit RO The sequence number of the last submission (used for idempotency testing). LAST_DIGEST 0x48 256bit RO The summary submitted last time (for idempotency detection) TXN_MARKER 0x70 32bit RO (external) Two-phase commit transaction flag PV_MC 0x80 32bit RO (external) Policy version increment register Furthermore, the hardware edge latch module HSL has a built-in hardware timeout watchdog. If no unlock confirmation is received from the Host after a preset time window Tmax has elapsed since entering the LOCKED state, the SICU internal collaborative hardware will automatically unlock the device and forcibly generate a special anchor record with record_type = AUTO_UNLOCK and write it into the evidence chain, so that the offline verification end can identify this abnormal unlock event.

[0099] Optionally, the preset time window Tmax ≥ AT execution budget + NVM write budget + safety margin.

[0100] Please see Figure 4 , Figure 4 The diagram illustrates the HSL two-level synchronization chain and timing logic locking state machine in an embodiment of this application. In this embodiment, after the hardware same-edge latch module completes the snapshot data latching, the timing logic state machine immediately enters the LOCKED state. At this time, the clock enable of the D flip-flop array is gated off, and the register output remains frozen. Even if the input channel signal changes, the latched snapshot data will not change. Only when the main control processor completes the storage write of all partitions P0 / P1 / P2 and sends an unlock confirmation to the hardware same-edge latch module will the state machine switch back to the IDLE ready state and enter the next sampling cycle, ensuring the transaction semantics of "one snapshot, one append".

[0101] pass Figure 4 It is known that the hardware edge-detection latch module uses a two-stage D flip-flop synchronization chain to perform cross-clock domain synchronization processing on asynchronous trigger signals, eliminating the risk of metastability. The output of the synchronization chain generates a synchronous trigger signal through edge-detection combinational logic, driving the timing logic to lock the state machine. The state machine includes two core states: IDLE and LOCKED. In the IDLE state, the D flip-flop array responds to the clock and trigger signal, and can perform a new sampling latch. In the LOCKED state, the clock enable of the D flip-flop array is gated off, and the register output remains frozen. It only switches back to the IDLE state after receiving an unlock confirmation from the main control processor, ensuring that a single trigger event corresponds to a unique snapshot data and avoiding sampling overwriting.

[0102] In one implementation, during the two-phase commit update, Phase A is the shadow write phase, where the preceding summary shadow register and transaction marker are written and a non-volatile memory refresh is completed. If a power failure occurs during this phase, the system rolls back to the old state before the commit after power-on. Phase B is the commit effective phase, where indivisible sub-operations are executed in the following strict order: (i) writing the transaction marker TXN_marker.phase = 2 and completing the non-volatile memory refresh flush_nvm(); (ii) performing an atomic increment of the hardware increment register MC; (iii) switching the preceding summary register PDR from the shadow register PDR_shadow to commit; (iv) clearing the transaction marker and completing the final flush_nvm(). If a power failure occurs after any sub-step, the compensation action is determined by a two-dimensional comparison between the TXN_marker phase value and the measured value of MC after power-on.

[0103] Please see Figure 6 , Figure 6 The following is a timing diagram of the two-stage commit and power-down recovery provided in an embodiment of this application.

[0104] Specifically, in this embodiment, the two-phase commit update is divided into two atomic phases: Phase A Shadow Write Phase: Write the preceding summary shadow register PDR_shadow and the transaction marker TXN_marker (phase=1), and call flush_nvm() to complete the non-volatile memory forced flush. During this phase, the core hardware increment register and preceding summary register are not modified. If a power failure occurs during this phase, the system will automatically roll back to the old state before the commit after power is restored.

[0105] Phase B commit and take effect: Hardware atomic increment of the hardware increment register is performed, the preceding summary register is switched from the shadow register, and the transaction marker is updated to TXN_marker (phase=2). After completion, flush_nvm() is called to flush and clear the transaction marker. This phase completes the core state update. If a power failure occurs during this phase, the system will automatically complete the commit after power-on and converge to the new state after the commit.

[0106] Phase A completes the shadow data writing and transaction marking without modifying the core hardware increment register and previous summary register, and can be safely rolled back after power failure; Phase B completes the atomic update and status marking of the core register, and can be committed after power failure, ensuring that there are no intermediate state residues.

[0107] The security isolation computing unit executes deterministic recovery logic upon power-up, and its pseudocode implementation is as follows: run void on_power_up() { TXN_Marker m = TXN_marker_read_with_crc(); if (!m.crc_ok || m.magic != TXN_MAGIC) { enter_FORENSIC_HALT(); / / Illegal value / corruption → Enter audit shutdown return; } uint64_t mc_now = MC_read_internal(); switch (m.phase) { case PHASE_NONE: return; / / No outstanding transactions case PHASE_A: PDR_shadow_clear(); TXN_marker_clear(); / / Keep the old value in MC / PDR return; case PHASE_B: if (mc_now < m.expected_seq) { / / MC has not yet finished incrementing MC_increment_internal(); / / Compensation increment } PDR_commit_from_shadow(); / / Unconditional toggle TXN_marker_clear(); return; default: enter_FORENSIC_HALT(); } } / / MC has been incremented, and the previous digest register has completed the switch. As a specific implementation of the above scheme, the secure isolation computing unit maintains the transaction cache information of the last successfully submitted transaction. For duplicate anchoring transaction requests that completely match the payload hash and snapshot fingerprint, it directly returns the transaction receipt generated last time and does not perform the increment operation of the hardware increment register to prevent semantic ambiguity of sequence numbers caused by communication retries.

[0108] In this embodiment, the secure isolation computing unit internally maintains the LastCommitted information cache of the last successfully submitted transaction, which includes the previous sequence number, digest, receipt, payload hash, and snapshot fingerprint. When a new anchor transaction request is received, the payload hash and snapshot fingerprint of the current request are first compared with the cache information to see if they match completely. If they match, it is determined to be a duplicate request, and the previously generated transaction receipt is returned directly. The increment operation of the hardware increment register is not performed to avoid duplicate increment of the sequence number and semantic ambiguity caused by communication retries and link jitter.

[0109] Optionally, the device key used for signing is stored in a non-exportable storage area inside the secure isolated computing unit, or it is derived from the physically unclonable function (PUF) of the secure isolated computing unit combined with a fuzz extractor, and is never output to the outside of the security boundary in plaintext form throughout the process.

[0110] In this embodiment, the device signature key K_dev used to generate the transaction receipt is stored in a secure storage area inside the secure isolated computing unit. At the hardware level, only the signature call interface is open, and the key reading interface is not open. The key is never output in plaintext outside the security boundary of the secure isolated computing unit. In another optional embodiment, the device key is derived by the Physically Unclonable Function (PUF) combined with the Fuzzy Extractor (FE) built into the secure isolated computing unit. The key derivation process is completed entirely inside the secure isolated computing unit, and no key plaintext is leaked out. This ensures that even if the storage medium is completely copied, the new device cannot generate a legitimate transaction receipt, thus achieving a strong binding between the evidence chain and the device's origin.

[0111] In an alternative embodiment, the publicly verifiable metadata area includes self-description fields for hash algorithm identifier, signature algorithm identifier, key version, policy number, and record type. All self-description fields are bound to the calculation input of the current record digest to prevent metadata from being tampered with afterward.

[0112] In this embodiment, the publicly verifiable metadata area of ​​P0 includes self-description fields such as hash algorithm identifier, signature algorithm identifier, key version, policy number, and record type. All self-description fields are used as input parameters and incorporated into the hash calculation of the current record digest. If an attacker subsequently modifies the self-description field to upgrade the spoofing algorithm, the recalculated digest will inevitably not match the original digest. The verification end can directly identify the tampering behavior and prevent malicious tampering of metadata.

[0113] The P0 area contains at least four self-descriptive fields: hash_alg_id, sig_alg_id, key_version, and record_type. All fields are bound to the Digest calculation input to prevent metadata from being tampered with or used to fake algorithm upgrades.

[0114] As a specific implementation of the above scheme, a sensitive payload area is set in the non-volatile storage medium. The sensitive payload area is encrypted using a t-of-n threshold encryption scheme, and decryption requires no less than t legitimate shares to complete, thereby achieving controllable disclosure of data.

[0115] Please see Figure 7 , Figure 7 The diagram illustrates the P0 / P1 / P2 partition and record structure provided in an embodiment of this application.

[0116] In this embodiment, a P2 sensitive payload area is set in the non-volatile storage medium. This area is encrypted using a t-of-n threshold encryption scheme based on the Shamir secret sharing algorithm. At least t legitimate shares are required to decrypt the sensitive payload data. A typical configuration is a 2-of-3 threshold scheme, where the shares are held by the equipment manufacturer, the equipment user, and a third-party notary office, respectively. Decryption is only possible when at least two shares are collected. This ensures both the offline verifiability of public metadata and the controllable disclosure of sensitive business data, balancing the compliance requirements of trade secret protection and judicial evidence collection.

[0117] P0 represents the publicly verifiable metadata area, P1 represents the general encrypted payload area, and P2 represents the sensitive threshold encrypted area. Specifically, the record format for each partition is as follows: P0 (Publicly verifiable metadata area, plaintext): Seq_i (8B), Digest_i (32B), Receipt_i (64-2420B), record_type (1B), hash_alg_id (2B), sig_alg_id (2B), key_version (4B), policy_id (4B), payload_len (4B), payload_hash (32B), snap_fp (4B, optional), channel_mask (4B), error_code (2B, optional), ext_fields (TLV, optional).

[0118] P1 (General payload area, encrypted): Enc(K1,Payload_i), uses a symmetric encryption algorithm to encrypt and protect the regular payload data.

[0119] P2 (Sensitive Payload Area, Threshold Encryption): Employs a t-of-n threshold encryption scheme, requiring at least t valid shares to decrypt.

[0120] Furthermore, the security isolation computing unit internally maintains a policy version increment register pv_mc. When decrypting and restoring the threshold share, it only accepts shares whose key version and policy version are not lower than the value of the current policy version increment register, rejects the injection of old version shares, and prevents policy rollback attacks. The authentication tag verification of the threshold share is bound to policy_id / key_version.

[0121] Please see Figure 8 , Figure 8 A flowchart illustrating the threshold recovery and policy version increment state in an embodiment of this application is shown.

[0122] In this embodiment, the secure isolation computing unit internally maintains a 32-bit policy version increment register pv_mc. This register has the same hardware unidirectional increment attribute as the hardware increment register and has no external write path. When the threshold share is decrypted and restored, the system first verifies the key_version and policy_id carried by the share. It only accepts legitimate shares with a version number not lower than the current pv_mc value and directly rejects the injection request of the old version share, returning an ERROR_POLICY_ROLLBACK error to prevent attackers from performing rollback attacks by injecting old version policy shares.

[0123] In this embodiment, the Shamir secret-sharing algorithm can be used to implement threshold encryption. The specific process is as follows: Choose a large prime number p (p=2^256-189 is recommended); A random session key K is generated within a secure, isolated computing unit; Generate random polynomials ; Calculate n shares: share_i = (i, f(i)); Calculate the authentication tag for each share: tag_i=HMAC(K_tag,share_i||policy_id||key_version||device_uid).

[0124] Meanwhile, the security isolation computing unit maintains an incrementing policy version register pv_mc. When decrypting and restoring the threshold share, it requires key_version>=pv_mc to reject the injection of old version shares and prevent policy rollback attacks.

[0125] In an alternative embodiment, when latching snapshot data, the hardware edge latch module generates a snapshot fingerprint of no less than 32 bits, snap_fp, in parallel using a CRC-32 combinational logic circuit based on an LFSR array. The input of the snapshot fingerprint includes N channel data and their channel position codes, and the snapshot fingerprint is bound to the calculation input of the current record digest.

[0126] Optionally, the snapshot fingerprint (snap_fp) width can be extended to 64 bits or 128 bits, achieved by SHA-256 truncated output.

[0127] In this embodiment, the hardware edge-locking module generates a snapshot fingerprint (snap_fp) using standard CRC-32 combinational logic implemented through a linear feedback shift register (LFSR) array while latching the snapshot data. The generator polynomial is 0x04C11DB7 according to the IEEE 802.3 standard. This fingerprint is sent to the main control processor along with the snapshot data and is used as an input parameter in the hash calculation of the current record digest. If an attacker subsequently modifies the snapshot data in the storage medium, both the snapshot fingerprint and the digest will mismatch, allowing the verification end to directly identify the data tampering and strengthening the integrity protection of the snapshot data.

[0128] As a specific implementation of the above scheme, when the hash algorithm, signature algorithm is upgraded or the key is rotated, a special migration anchor record is generated. The migration anchor record contains the new algorithm identifier, the new key version, the new public key digest and the effective sequence number boundary. The migration anchor record is at least bridged and signed by the old version private key. After the verification end verifies that the bridged signature is successful, the algorithm and key suite used for subsequent verification are updated.

[0129] Please see Figure 9 , Figure 9 The diagram illustrates the migration anchoring record and bridging signature in an embodiment of this application.

[0130] In this embodiment, when the hash algorithm, signature algorithm is upgraded, or the key is rotated, the system generates a special migration anchor record (record_type=MIGRATION_ANCHOR). The record payload includes the new algorithm identifier, the new key version, the new public key digest, and the effective sequence number boundary. The migration anchor record is at least bridged and signed by the old version private key, and optionally, it is double-signed by the new private key to form a bidirectional bridge. When the verification end encounters a migration anchor record, it first verifies the validity of the old private key bridged signature. After the verification is successful, it automatically updates the signature verification algorithm and public key suite of subsequent records to ensure the continuous and verifiable evidence chain during algorithm upgrades and key rotations.

[0131] Among them, a special migration anchor record (record_type=MIGRATION_ANCHOR) is generated, and the specific specifications are as follows: Payload content: new_sig_alg_id, new_key_version, new_pubkey_hash (new public key / certificate chain digest), effective_seq (effective sequence number boundary).

[0132] Receipt requirements: The migration record must be bridged and signed by the old private key at least once, and optionally signed by the new private key at the same time to form a two-way bridge.

[0133] Verification rules: When the verification end encounters a migration anchor record, it first verifies the validity of the old signature. After the verification is successful, it updates the signature verification algorithm and public key suite for subsequent records.

[0134] Optionally, in some implementations, when generating transaction receipts, a hybrid dual-signature mode of traditional digital signature and quantum-resistant digital signature is adopted, generating two types of signatures simultaneously and storing them in a publicly verifiable metadata area to achieve smooth migration resistant to quantum attacks.

[0135] In this embodiment, when generating transaction receipts, a hybrid dual-signature mode of traditional digital signature and quantum-resistant digital signature is adopted. Both types of signatures are generated simultaneously and stored in the P0 publicly verifiable metadata area. The typical migration path is as follows: Ed25519 traditional signature is used from 2026 to 2030, Ed25519+Dilithium-2 hybrid dual-signature is used from 2030 to 2035, and Dilithium-2 quantum signature is fully adopted after 2035. While ensuring compatibility, a smooth transition to resist quantum attacks is achieved, ensuring the long-term verifiability of the evidence chain for 10-20 years.

[0136] For example, quantum-resistant migration paths can be shown in Table 3 below.

[0137] Table 3 Anti-quantum migration pathways When generating transaction receipts, a hybrid dual-signature mode combining traditional digital signatures and quantum-resistant digital signatures can be adopted. Both types of signatures are generated and stored in the P0 area, ensuring compatibility while achieving a smooth transition against quantum attacks.

[0138] In one implementation, the method further includes: if any record in the stored record sequence is deleted, the offline verification terminal detects the sequence number jump, accurately locates the position of the first missing record, and outputs the corresponding exception type.

[0139] Please see Figure 10 , Figure 10 The offline verification process and anomaly location output diagram in the embodiments of this application are shown.

[0140] In this embodiment, since the hardware increment register value is strictly monotonically increasing, and the sequence number of each record is bound to the hardware increment register value read during AT execution, if an attacker deletes any one or more records in the storage medium, the sequence number of the remaining records will inevitably have skipped numbers. During the verification process, the offline verification end will check Seq_i==Seq_{i-1}+1 line by line. Once a discontinuous sequence number is detected, the position of the first missing record and the E_SEQ_GAP exception type will be output immediately, thereby achieving precise location of the record deletion behavior.

[0141] Optionally, the hardware increment register is implemented based on a one-time programmable OTP fuse array or an eMMCRPMB hardware increment register, which physically only supports unidirectional increment and cannot be rolled back or reset.

[0142] In this embodiment, the hardware increment register is implemented based on a one-time programmable OTP fuse array. Each increment operation corresponds to the physical melting of a fuse. The transition from the fuse being on to off is an irreversible physical transition, and there is no possibility of rollback or reset. In another optional embodiment, the hardware increment register is implemented based on the eMMC's RPMB hardware increment register. The eMMC controller guarantees the atomicity and irreversibility of the increment operation at the hardware layer, and ensures the unforgeability of the sequence number from the physical layer.

[0143] In one implementation, the secure isolation computing unit is equipped with an atomic execution and commit unit state machine. During the execution of a transaction with busy=1, the state machine physically blocks the input of new anchor transaction requests through hardware AND gates, thereby ensuring the exclusive execution of atomic anchor transactions.

[0144] Please see Figure 5 , Figure 5 This diagram illustrates the state transition of the state machine of the atomic execution and commit unit within the secure isolation computing unit described in this application. In this embodiment, during transaction execution when busy=1, the atomic execution and commit unit state machine physically blocks the write enable signal of the AT_CMD command register through a hardware AND gate. New anchor transaction requests are directly ignored, and the external interface continuously returns the BUSY (0x01) state when reading the AT_STATUS register, ensuring the exclusive execution of atomic anchor transactions and preventing interruption by external requests, thus guaranteeing the atomicity of transactions at the hardware level.

[0145] according to Figure 5 As can be seen, the atomic execution and submission unit state machine contains 7 core states and 1 REPLAY idempotent path. The core actions and transition relationships of each state are shown in Table 4 below.

[0146] Table 4. State Machine of Atomic Execution and Submission Unit IDLE Waiting for AT_REQ, busy=0 LOAD or REPLAY LOAD Set busy=1; Read MC→seq_local; Read PDR→prev_local COMPUTE COMPUTE The Digest_i = H(domain_tag || payload_hash || MC_hw[i] || PDR_hw[i-1] || meta_hash || [snap_fp]) is calculated, where the MC sequence is directly bound to the digest calculation. SIGN SIGN Receipt_i=Sign(K_dev,Digest_i) COMMIT_A COMMIT_A Write PDR_shadow; Write TXN_marker (phase=1); flush COMMIT_B COMMIT_B MC.increment(); PDR = PDR_shadow; Write TXN_marker(phase=2); flush; Clear markers RESP RESP Output AT_RSP; Update LastCommitted; Clear busy IDLE REPLAY If a duplicate request is detected, LAST_RECEIPT is returned, and MC is not incremented. IDLE ABORT Clear PDR_shadow; clear TXN_marker; keep MC and PDR unchanged; write to ABORT_LOG counter; clear busy; return AT_RSP(status=ERROR_AT_ABORT) IDLE The AECU state machine includes an ABORT exception exit path. If a hardware exception occurs at any stage of LOAD / COMUTE / SIGN / COMMIT_A / COMMIT_B (including but not limited to hash engine error, signature engine error, flush_nvm failure, PUF derivation failure), the state machine is forcibly switched to the ABORT state. The hardware clears all intermediate states, keeps the MC and PDR registers unchanged, clears the busy flag, and returns the ERROR_AT_ABORT status code. This ensures that the entire transaction is rolled back under any exception and that subsequent anchor requests can be accepted, avoiding permanent deadlocks.

[0147] In the embodiments of this application, the inputs are guaranteed to be exclusive. For example, the input may include payload_hash, optional snap_fp, record_type, hash_alg_id, sig_alg_id, key_version, policy_id, channel_mask, payload_len, ext_fields, etc., without a Seq parameter or a PrevDigest parameter. The output may include Seq_i, Digest_i, Receipt_i, AT_Status, and ErrorCode.

[0148] The exclusivity guarantee is used to characterize that the external interface does not provide Seq write parameters, does not provide hardware increment register rollback / reset commands, does not provide preorder summary register write parameters, rejects new requests during busy periods, and has no AT intermediate state readout.

[0149] The atomicity guarantee of AT in this application stems from the triple constraint enforced by hardware, rather than the assumptions of the software transaction protocol.

[0150] First, the exclusivity constraint: the atomic execution and commit unit state machine rejects any new requests during busy=1, ensuring that the transaction cannot be interrupted; the external interface reads AT_STATUS and returns BUSY(0x01) during busy, and any AT_REQ is ignored; in the internal implementation, the AT_CMD register write enable and the busy signal are gated by an AND gate, and the write enable is physically blocked when busy=1.

[0151] Secondly, the indivisible constraint: MC.increment() in COMMIT_B is a hardware atomic operation, and there is no physical state of "incrementing by half"; when implemented based on OTP fuse array, the fuse's transition from on to off is a physical jump that is irreversible and uninterruptible; when implemented based on RPMB increment register, the eMMC controller guarantees atomic writing at the hardware layer.

[0152] Finally, power-down recovery constraints: The TXN_marker of PhaseA and PhaseB guarantees that the system can be restored to a consistent state at any time of power failure. The system state space only contains S_old (old state before commit) and S_new (new state after commit), and there is no third mixed intermediate state. When PhaseA loses power, it rolls back to S_old, and when PhaseB loses power, it completes the commit to S_new.

[0153] It is evident that the atomicity of this application is a direct consequence of the hardware circuitry, rather than an assumption of the software protocol.

[0154] As a specific implementation of the above scheme, the Security Isolation Computing Unit (SICU) executes deterministic recovery logic upon power-up: First, it reads the transaction flag bit TXN_MARKER and its CRC checksum and magic number; when the CRC check fails or the magic number does not match, it enters the FORENSIC_HALT forensic shutdown state, rejects new anchor transaction requests, and exposes an abnormal status code; when phase = 0, it enters the ready state; when phase = 1, it executes Phase A rollback; when phase = 2, based on the two-dimensional comparison between the measured MC value and the expected_seq carried in TXN_MARKER, it performs MC increment and / or PDR switching respectively to ensure that the system converges to a unique consistent state after power-up.

[0155] Optionally, the storage structure of the transaction marker bit TXN_MARKER includes a magic field, a phase field, an expected_seq field, a digest_crc32 field, and a CRC-32 / MAC checksum bit covering it; TXN_MARKER is written to non-volatile storage media with triple redundancy and read using a majority voting mechanism to ensure that single-page damage does not disrupt recovery decisions.

[0156] In this embodiment, during the power-on initialization phase, the security isolation computing unit first reads the phase value of the TXN_MARKER transaction flag bit and performs the corresponding recovery operation according to the phase value: if phase=0, there are no incomplete transactions, and it directly enters the ready state; if phase=1, it is determined that Phase A has failed, and a rollback operation is performed, clearing the shadow register and transaction flag, while the hardware increment register / preceding summary register retains its old value; if phase=2, it is determined that Phase B has failed, and a commit completion operation is performed, switching the preceding summary register and clearing the transaction flag, ensuring that the system will inevitably converge to a consistent state after power-on, without the need for manual intervention.

[0157] In an alternative embodiment, the offline verification terminal does not need to access online network services, online timestamp services, or trusted third parties throughout the entire process, and completes the full-chain validity verification solely based on plaintext data from a publicly verifiable metadata area.

[0158] In this embodiment, the offline verification terminal does not need to access online network services, online timestamp services, or trusted third parties throughout the entire process. It only needs to obtain plaintext data from the P0 publicly verifiable metadata area in the storage medium to complete the full-chain verification of transaction receipt validity, sequence number continuity, and chain digest consistency. At the same time, it can accurately locate the position and error type of the first anomaly point, which is suitable for offline evidence collection scenarios without network.

[0159] The offline verification algorithm in this application does not require access to online services; it can complete the entire chain of verification based solely on plaintext data in the P0 zone. The specific specifications are as follows: Input: A sequence of P0 metadata read in order; Output: VerifyReport, which includes OK / FAIL, the first exception location i*, the exception type, and suggested evidence collection actions.

[0160] The verification process involves performing the following verification steps sequentially on the i-th record (i ranges from 1 to m) in the sequence: Algorithm and key selection: Select the corresponding hash / signature verification engine and public key based on record_type, hash_alg_id, sig_alg_id, and key_version; Migration record processing: If a MIGRATION migration anchor record is encountered, first verify the bridge signature of the old private key, and then update the subsequent signature verification suite after successful verification. Receipt validity verification: Execute Verify(PubKey,Digest_i,Receipt_i). If verification fails, output an E_SIG_FAIL exception. Sequence number continuity verification: Verify that Seq_i == Seq_{i-1} + 1. If the condition is not met, output E_SEQ_GAP (skip number) or E_SEQ_DUP (duplicate) error. Digest consistency verification: Verify Digest_i = H(domain_tag || payload_hash || MC_hw[i] || PDR_hw[i-1] || meta_hash || [snap_fp]). If the verification fails, output the E_DIGEST_MISMATCH exception. Once all records have been verified, a verification success report will be output. If any step fails to verify, the verification will be terminated immediately, and the location of the first anomaly, the anomaly type, and suggested evidence collection actions will be output.

[0161] Furthermore, this application is further illustrated by specific embodiment A.

[0162] Example A: Offline Evidence Collection for Collision Faults in Industrial Robots This embodiment is applied to an offline evidence collection scenario for collision faults in a six-axis industrial robot welding task, and the specific implementation is as follows: Channel configuration: Configure 16 acquisition channels, CH[0-5] for 6 joint currents, CH[6-11] for 6 joint speeds, CH

[12] for control command mirroring, CH

[13] for safety status bit, CH

[14] for event code, CH

[15] for time base; Threshold configuration: A 2-of-3 threshold encryption scheme is adopted, with shares held by the equipment manufacturer, the equipment user, and a third-party notary office, respectively. At least two shares are required to decrypt sensitive payload data. Execution process: t=0μs: The collision occurs, and the current in joint 1 jumps from 100A to 220A; t=0.05μs: The collision sensor detects an anomaly and outputs a high-level trigger signal to HSL.TRIG_IN; t=0.12μs: The rising edge of CLK_SAMPLE arrives synchronously through the H-tree clock distribution network. The 16 edge-triggered D flip-flops inside the hardware edge latch module capture the input level of each channel in parallel on the same clock edge and latch it into the internal register. t=0.15μs: The hardware edge latch module's sequential logic state machine enters the LOCKED state, SNAP_VALID=1, the D flip-flop array clock enable is gated off, and the register output is frozen; t=1ms: The main control processor reads SNAP_DATA

[16] and SNAP_FP; t=2ms: The main control processor calculates payload_hash=SHA256(SNAP_DATA); t=3ms: The main control processor sends AT_REQ to the secure isolated computing unit via SPI (excluding Seq / PrevDigest parameters); t=3.1ms: The security isolation computing unit enters the LOAD state, internally reads MC=12345, and internally reads the prequence summary register; t=3.5ms: The security isolation computing unit is in COMPUTE state, directly binding the hardware increment register sequence to the digest calculation; t=5ms: The secure isolated computing unit is in the SIGN state and generates a receipt using an internal, non-derivative key; t=6ms: SICU enters COMMIT_A (Phase A), writes PDR_shadow and TXN_marker (phase=1) and flush_nvm(); t=7.0ms: Enter COMMIT_B (PhaseB) sub-step (i): Write TXN_marker (phase=2) and flush_nvm(); t=7.3ms: Execute MC atomic increment (OTP fuse blown or RPMB counter increment); t=7.6ms: Perform PDR ← PDR_shadow switch; t=7.9ms: Clear TXN_marker and flush_nvm(); t=8ms: SICU returns AT_RSP(seq=12345, digest, receipt, status=OK) t=10-14ms: The main controller completes the writing of data to the P0 / P1 / P2 partitions; t=15ms: The main control processor sends UNLOCK_CMD, the hardware edge latch module unlocks, and enters the next round of sampling ready state.

[0163] Optionally, this application further illustrates the concept through specific embodiments.

[0164] Example B: Incident Token Generation This embodiment is applied to the automated accident attribution scenario of equipment safety shutdown events. When the equipment detects a safety shutdown event, the main control processor triggers an atomic anchor transaction (AT) with a payload of CrashToken={event_code,severity,snap_fp,payload_hash,policy_id,key_version}. The transaction receipt output by the secure isolated computing unit after executing the AT can be completely verified offline by third-party institutions without the need to access online services. This completes the verification of the authenticity and timing of the accident event, supporting the automated accident attribution process.

[0165] In addition, this application embodiment also provides an offline temporal evidence storage device for a robot system, including: a hardware co-edge latch module HSL, a host processor Host, a secure isolated computing unit SICU, and a non-volatile storage medium; wherein, the latch output terminal of the hardware co-edge latch module is directly connected to the snapshot read interface of the host processor through a dedicated data bus; the host processor communicates with the secure isolated computing unit through an anchor transaction bus, the anchor transaction bus does not carry sequence number write signals and preorder digest write signals at the physical layer; the secure isolated computing unit internally integrates a hardware increment register MC, a preorder digest register PDR, an atomic execution and submission unit AECU state machine, a signature engine, and a non-exportable key storage area, the external read path of the hardware increment register and the preorder digest register is provided by an internal address decoder, but there is no external write path; the non-volatile storage medium is connected to the host processor and is used to store a publicly verifiable metadata area and an encrypted payload area.

[0166] Optionally, the secure isolated computing unit integrates a hardware increment register, a preorder digest register, an atomic execution and submission unit (AECU) state machine, a signature engine, and a non-exportable key storage area, and the external interface of the secure isolated computing unit does not have sequence number write parameters and preorder digest write parameters.

[0167] Optionally, the hardware edge latch module HSL, in the LOCKED state, implements gated shielding for external asynchronous reset signals and only responds to unlock confirmation signals from within the SICU that have undergone synchronous processing; External reset commands are physically blocked by combinational logic during the LOCKED state to ensure that latched snapshot data is not erased by external reset attacks.

[0168] Furthermore, this application provides further illustrative examples.

[0169] Example C: Offline Evidence Collection of Autonomous Driving Data Black Box (EDR / DSSAD) In this embodiment, N=32, corresponding to 32 core data channels, specifically divided into: vehicle dynamics parameter channels (4 channels, including wheel speed, braking pressure, steering angle, yaw angle / longitudinal + lateral acceleration), AI decision output channels (2 channels, including autonomous driving system decision commands and decision confidence), environmental perception data channels (6 channels, including millimeter-wave radar perception feature hash, forward / side camera image feature hash, and lidar point cloud feature hash), and vehicle status and safety signal channels (20 channels, including collision detection signals, airbag trigger status, ADAS functional module activation status, vehicle power status, gear information, etc.).

[0170] The trigger events are set as high-risk and accident-related scenarios in autonomous driving, specifically including: vehicle collision acceleration > 2.5g (complying with the general industry standard for vehicle collision detection), activation of the automatic emergency braking (AEB) system, the autonomous driving system issuing a steering wheel takeover request to the driver (including takeover timeout failure to respond), any of the vehicle's airbags being triggered, the ADAS system issuing a core fault alarm, and sudden changes in vehicle speed (exceeding the preset normal driving fluctuation range), etc. After being triggered, data locking and encryption are immediately initiated to ensure that key time sequence data at the moment of the accident and before and after are not tampered with or lost.

[0171] The threshold scheme adopts a 3-of-5 design, with five data shares held by the vehicle manufacturer, the vehicle consumer (or the owner's authorized representative), the insurance company, the traffic management department, and the third-party motor vehicle appraisal agency, respectively. At least three shares must be unlocked together to read the evidence data. This ensures data security and confidentiality while also taking into account the legitimate data access needs of all parties involved in the accident determination, and avoids a single entity monopolizing the data and affecting the fairness of liability determination.

[0172] The evidence preservation time window and triggering event mechanism in this embodiment are strictly compatible with the mandatory technical specifications of UNECE R157 Annex 4 §5.1.2 for DSSAD (Data Storage System for Automated Driving), namely: a rolling buffer of data for 30 seconds before triggering and continuous data retention for 5 minutes after the triggering event. The 3-of-5 threshold allocation forms a one-to-one correspondence with the responsible parties (vehicle manufacturers / consumers / insurance companies / traffic management departments / third-party assessment agencies) identified in UNECE R157 Annex 4 §4.2, providing a verifiable chain of evidence that complies with international regulations for determining accident liability.

[0173] Optionally, this application further illustrates the concept through specific embodiments.

[0174] Example D: Storage of operational data for critical power grid infrastructure.

[0175] In this embodiment, N=24, corresponding to 24 core data channels, specifically divided into: power grid electrical parameter channels (8 channels, including instantaneous values ​​of three-phase voltage, instantaneous values ​​of three-phase current, active power, and reactive power), equipment operating status channels (6 channels, including transformer winding and oil temperature, circuit breaker opening and closing positions, and disconnector status), control and protection channels (6 channels, including relay protection operation status, SCADA remote control commands, and protection device alarm signals), and power grid synchronization parameter channels (4 channels, including system frequency, three-phase phase angle, voltage amplitude deviation, and frequency deviation).

[0176] The trigger events are set as abnormal power grid operation scenarios and critical operation scenarios, specifically including: any action of the relay protection device (including overcurrent, overvoltage, zero-sequence protection, etc.), execution of remote control commands of the SCADA system (including circuit breaker opening and closing, transformer voltage adjustment, and other critical operations), three-phase voltage / current exceeding the preset safe operation threshold, power grid frequency / phase angle deviating from the standard range, network security events (including illegal intrusion, data tampering, abnormal access, etc.), transformer temperature over-temperature alarm, etc. After triggering, data encryption and locking and time sequence evidence storage are immediately initiated to ensure the integrity, authenticity and immutability of critical operation data at the moment of abnormality and before and after, providing accurate basis for fault tracing.

[0177] The threshold scheme adopts a 2-of-3 design, with three data shares held by the power grid operator, the National Energy Administration, and a third-party professional auditing institution, respectively. At least two shares must be unlocked collaboratively before the stored data can be read. This not only ensures the security and confidentiality of power grid operation data and operational autonomy, but also meets the compliance requirements of industry supervision and third-party auditing, avoids the risk of operation by a single entity, and ensures the fairness and standardization of data retrieval.

[0178] Example E: Compliant storage of operational data from medical surgical robots.

[0179] This application example is used for medical malpractice liability determination (machine failure / AI error / operational error) + NMPA compliance audit.

[0180] Channel configuration: 20 channels (6 joint positions, 6 joint torques, end effector force feedback, operator's instructions, AI-assisted decision output, patient vital signs, emergency stop status, and image-guided target position).

[0181] Triggering events include: force feedback exceeding the safety threshold, conflict between AI and doctor's instructions, joint exceeding the preoperative planning boundary, emergency stop activation, and abnormal patient vital signs.

[0182] Threshold configuration: 2 of 3 (hospitals, equipment manufacturers, NMPA).

[0183] In this embodiment, N=16 (expandable to 24), corresponding to the position / torque channels of 6 joints in both legs and 6 joints in both arms (12 channels), IMU three-axis + visual / tactile / depth perception feature vector hash (4 channels), large model action output token sequence summary + decision confidence + task state machine identifier + human-machine takeover signal (4 channels), and safety event bits for emergency stop triggering / collision detection / boundary crossing alarm / fall detection (4 channels, enabled only in extended configuration). Triggering events include joint torque exceeding the preset SSM boundary, large model decision confidence below the threshold but still executing the action, human-machine distance below the safety threshold, and abnormal jump of the task state machine. The threshold scheme adopts a 2-of-3 design, with the three shares held by the robot manufacturer, the deployment operator, and the industry regulatory agency, respectively.

[0184] This embodiment focuses on the offline, irreversible temporal evidence storage of physical states and decision-making output data during the operation of humanoid robots. The evidence storage object is the factual record of "when, what signal, and what output," without involving the interpretation of the semantic rationality of the decisions. It provides an immutable original data foundation for post-event compliance audits, accident liability determination, and judicial evidence collection. This embodiment can directly connect to the intelligent behavior safety sub-domain of the Safety Ethics section of the "Humanoid Robot and Embodied Intelligence Standard System (2026 Edition)," the L3-L5 collaborative interaction dimensions of T / CIE 298-2025 "Humanoid Robot Intelligence Classification," and the compliance requirements of Article 12 (automatic logging) and Article 14 (human supervision) of the EU Artificial Intelligence Act (EU) 2024 / 1689.

[0185] Optionally, this application also illustrates Embodiment F: Offline time-series evidence storage for an underwater ROV special robot.

[0186] In this embodiment, the specific manifestations are as follows: ① The deep-sea operation environment is completely offline, with no network signal coverage. The T6 agent cannot rely on cloud support and can only operate independently locally, which fully highlights the irreplaceable nature of "offline time-series evidence" and solves the industry pain point that deep-sea operation data cannot be transmitted in real time and is difficult to trace; ② ROV deep-sea operations are mostly long-duration missions, with operation time ranging from several hours to several days. During the operation, the amount of various events and data accumulated is large, which highlights the engineering value of the NVM partition storage + threshold unlocking mechanism of this invention, realizing the secure storage and controllable reading of massive offline data; ③ After the ROV operation is completed, it needs to float to the surface for recovery. After recovery, batch data can be uploaded to the blockchain through dedicated equipment, which perfectly matches the bridging signature and cross-domain authentication mechanism of this invention, realizing the secure connection between offline data and the blockchain network; ④ ROVs are widely used in key scenarios such as pipeline inspection, submarine optical cable maintenance, and deep-sea salvage. During the operation, core needs such as equipment safety, operation quality, and responsibility definition are involved, and the need for responsibility traceability is extremely strong, which fully highlights the legal value of the evidence data and provides an immutable original basis for operation compliance audit and accident responsibility determination.

[0187] The system can be configured with N=26, corresponding to 26 core data channels. Considering the characteristics of underwater ROV operations, the channel allocation takes into account equipment operating status, operational data, environmental awareness, and safety events. Specifically, the channels are divided as follows: ROV body operating parameter channels (8 channels), including thruster speed / thrust, body attitude angles (roll / pitch / yaw), cabin pressure / temperature, remaining battery power, and underwater depth; operational execution parameter channels (6 channels), including robotic arm joint position / torque, operational tool (cutting / grabbing) operating status, operational progress feedback, and operational point coordinates; environmental awareness data channels (6 channels), including underwater visibility, water temperature / salinity, underwater acoustic detection signal feature hash, camera image feature hash, and obstacle distance detection; and safety and control channels (6 channels), including emergency stop trigger signal, fault alarm status, remote control commands (local cache), operational mode switching signal, communication link status (local detection), and threshold unlock trigger signal. All channel data is stored using time-series encryption and divided into NVM storage partitions according to operational stages to ensure orderly data retention and prevent tampering.

[0188] The threshold configuration employs a 3-of-5 strong redundancy design. Considering the multiple stakeholders involved in underwater ROV operations, five data shares are held by the ROV manufacturer, the operation unit, the maritime regulatory authority, the third-party testing agency, and the operation client, respectively. At least three shares must be unlocked collaboratively to read and retrieve the evidence data. This design ensures the security and controllability of the evidence data, preventing a single entity from tampering with the data or monopolizing evidence, while also accommodating the legitimate needs of all parties—the operation unit can use it for operation quality verification, the maritime regulatory authority for compliance supervision, the third-party testing agency for technical assessment, and the operation client for results acceptance and accountability. This fully demonstrates the practicality and safety of strong redundancy design in special robot scenarios.

[0189] This embodiment strictly adheres to relevant industry standards and international norms to ensure the compliance and universality of the technology implementation. Specifically, it directly aligns with GB 3836 "Electrical Apparatus for Explosive Atmospheres" (for electrical safety requirements in underwater flammable and explosive environments), ISO 13482 "Safety requirements for robots and robot systems – Part 1: Robots" (ensuring ROV operation safety and personnel safety), and the IECEx system "IECEx System for Electrical Apparatus for Explosive Atmospheres" (meeting equipment certification requirements for special underwater environments). It also complies with the relevant clauses in the "Data Security Law" and the "Marine Environmental Protection Law" regarding underwater operation data retention and environmental monitoring data security. As a simplified embodiment for special robots, this embodiment is simple in structure and highly targeted, and can be directly applied to the deployment of offline evidence storage systems for various deep-sea ROVs without complex modifications. This highlights the core innovative value of the invention and possesses strong engineering practicality and promotional value.

[0190] Please see Figure 11 , Figure 11 A schematic diagram of multi-industry channel mapping comparison is shown in the embodiments of this application.

[0191] Figure 11 The document illustrates the channel segments and number of paths, typical triggering events, threshold scheme 2-of-3, and docking standards for each of the embodiments A to F above. For detailed descriptions, please refer to the foregoing, which will not be repeated here.

[0192] Optionally, embodiments of this application also provide a non-transient computer-readable storage medium storing computer-executable instructions. When these instructions are executed on a processor, they cause the processor to execute the offline temporal evidence storage method for robot systems described in the above embodiments. This storage medium can be deployed in the main control unit of industrial equipment, offline evidence collection terminal, and verification equipment to achieve standardized deployment and execution of the method of the present invention.

[0193] Optionally, this application embodiment also uses eight interlocking constraint chains, C1-C8, to combine independent functional modules into a security system with indivisible transaction semantics. The absence of any constraint can construct a reproducible attack or state inconsistency. The engineering implementation and acceptance criteria for each constraint are as follows: C1: External interface has no Seq / PrevDigest write parameters Engineering implementation: The external interface of the secure isolation computing unit does not provide Seq write parameters, the AT does not accept external PrevDigest as an insertion point, and the AT intermediate state cannot be read / reset externally (no debug read during busy periods). Acceptance test case: Attempt to write to the hardware increment register via SPI command or pass the Seq parameter. The expected result is ERROR_NO_SUCH_CMD or no response.

[0194] C2: One snapshot, one append (hardware edge latch module successfully frozen to AT) Engineering implementation: The hardware edge latch module enters the LOCKED state after snapshot_valid=1, prohibiting overwrite. The main control processor can only send unlock_cmd after receiving AT_RSP (status=OK) and completing the storage write. Acceptance test case: During the LOCKED period, SNAP_DATA is read multiple times, and the expected result is that the data is completely consistent and does not change over time.

[0195] C3: Verifiable continuity (Seq is continuous and localizable) Engineering implementation: AT returns a successful response satisfying Seq_i=Seq_{i-1}+1, and offline verification outputs the first abnormal position and error type for any skipped / repeated numbers; Acceptance test case: Manually delete the kth P0 record. The expected result is that the verification program outputs "E_SEQ_GAP at k".

[0196] C4: Internal position lock (prequence digest register is not writable externally, Digest is bound to Prev) Engineering implementation: Digest_i = H(domain_tag || payload_hash || MC_hw[i] || PDR_hw[i-1] || meta_hash || [snap_fp]), the preceding digest register can only be updated by the AT submission path; Acceptance test case: Modify the meta field in P0. The expected result is that the recalculated Digest does not match, and the verification fails.

[0197] C5: Power-down consistency and power-on recovery Project Implementation: A two-phase commit mechanism is adopted. In Phase A, PDR_shadow and TXN_marker are written (phase=1) and flush_nvm() is called. In Phase B, the hardware increment register is incremented, the pre-sequence summary register is switched, TXN_marker is written (phase=2) and flush_nvm() is called. Finally, the marker is cleared. Upon power-on recovery, TXN_marker is read. If phase=1, the rollback is performed. If phase=2, the commit is completed. Acceptance test case 1: If power is lost at any point in Phase A, the expected result is that after recovery, the hardware increment register / preceding summary register returns to the old state; Acceptance test case 2: Power failure at any point in Phase B, the expected result is that after recovery, the hardware increment register / preceding summary register completes the new state update.

[0198] C6: Source binding is non-replaceable Engineering implementation: The device signature key K_dev is located inside the secure isolation computing unit and cannot be exported, or it is derived from the PUF+ fuzz extractor and does not output the plaintext key. The receipt is Sign(K_dev,Digest_i). Acceptance test case: Copy the stored data to the new device. The expected result is that the Receipt output by the new device fails to verify.

[0199] C7: Idempotent resend of receipt (incremental response to prevent retries) Engineering implementation: The secure isolation computing unit maintains LastCommitted=(seq_last,digest_last,receipt_last,payload_hash_last,snap_fp_last). For matching duplicate requests, it directly returns receipt_last or E_DUPLICATE and must not increment the hardware increment register. Acceptance test case: Send the same AT_REQ 5 times consecutively. The expected result is that the hardware increment register increments only once and the returned receipts are completely consistent.

[0200] C8: Threshold access / policy rollback defense + password agility / migration anchoring Engineering Implementation: Threshold shares are verified with tag_i and bound to policy_id / key_version; the secure isolated computation unit maintains the policy version incrementing state pv_mc to prevent rollback; the self-description fields hash_alg_id / sig_alg_id / key_version / record_type are bound to the digest calculation; the migration anchor record is used to solidify the new public key digest and is signed by the old key. Acceptance test case: Inject the old key_version share. The expected result is recovery rejection, returning ERROR_POLICY_ROLLBACK.

[0201] Optionally, the test cases for C1 to C8 are shown in Table 5 below. All test cases must meet the expected results in order to achieve complete security protection capabilities.

[0202] Table 5 Test cases for interlock constraints C1-C8 TC-C1-01 External interface without Seq write parameters Attempt to write to the hardware increment register ERROR_NO_SUCH_CMD TC-C2-01 Hardware edge latch module freeze semantics Multiple reads during LOCKED Data consistency TC-C3-01 Sequence continuity Delete the kth record E_SEQ_GAPatk TC-C4-01 Position lock Modify meta field Digest verification failed. TC-C5-01 Phase A power failure Power off after PDR_shadow Hardware increment register / PDR revert to old value TC-C5-02 Phase B power failure The hardware increment register increments and then power is cut off. Hardware increment register / PDR completes new value TC-C6-01 Source binding Copy storage to new device Receipt verification failed. TC-C7-01 Idempotent retry Send the same request 5 times The hardware increment register only increments by 1, and the receipt remains consistent. TC-C8-01 Strategy rollback Inject old version shares ERROR_POLICY_ROLLBACK TC-PQC-01 Migration Anchoring Verification after writing to MIGRATION Subsequent records are continuously verifiable The design of the two-stage D flip-flop synchronization chain satisfies the following metastable convergence parameters: under the process conditions of fclk = 100MHz and metastable resolution time constant τ ≤ 100 ps, ​​the single-stage metastable resolution probability P_meta ≤ exp(-T_resolve / τ), and the system-level MTBF ≥ 10 after cascading the two stages. 9 Years. When the sampling frequency increases or the process time constant deteriorates, the MTBF can be maintained at 10 by increasing the number of synchronization chain stages (three or more). 9 More than 1 year. Optionally, in the method provided in this application embodiment, the Verilog pseudocode of the hardware same-edge latch module is as follows: / / Hardware-based parallel latch module - Parallel latch circuit based on D flip-flop array / / Core circuit features: N-way edge-triggered D flip-flops share the same clock line, capturing input levels in parallel on the same rising edge of the clock. modulehsl#(parameterN=16,parameterW=16)( inputwireclk, / / Master clock input, distributed via H-tree clock distribution network inputwirerst_n, / / Asynchronous low-level reset, directly connected to the CLR terminal of the D flip-flop. inputwiretrig, / / Asynchronous input trigger, requires processing via a synchronization chain. inputwire[N*W-1:0]din, / / N-channel ×W bit-width parallel data input, directly connected to the D terminal of a D flip-flop inputwireunlock_cmd, / / Input the unlock command outputregsnapshot_valid, / / Output snapshot validity flag outputreglocked, / / Output in locked state outputreg[N*W-1:0]snap_data, / / Output of the Q-end of the D flip-flop array, latched snapshot data outputreg[31:0]snap_fp / / CRC32 combinational logic output, snapshot fingerprint ); / / ==========Two-stage D flip-flop synchronization chain circuit (cross-clock domain synchronization, eliminating metastability)========= regtrig_ff1,trig_ff2; always@(posedgeclkornegedgerst_n)begin if(!rst_n)begintrig_ff1<=1'b0;trig_ff2<=1'b0;end elsebegintrig_ff1<=trig;trig_ff2<=trig_ff1;end end / / Edge detection combinational logic: AND gate + inverter wiretrig_sync=trig_ff1&~trig_ff2; / / ==========D flip-flop register array + sequential logic locked state machine========= wire rst_n_gated = rst_n | locked; / / Disables external reset during LOCKED always @(posedge clk) begin if (!rst_n_gated) begin locked <= 1'b0; snapshot_valid <= 1'b0; snap_data <= '0; snap_fp <= 32'h0; end else begin / * Existing synchronization logic * / end end / / ==========Standard CRC-32 combinational logic implemented using a linear feedback shift register (LFSR) array to generate snapshot fingerprints (snap_fp)========= function[31:0]fold_xor32(input[N*W-1:0]x); integer k; reg[31:0]acc; begin acc=32'h0; fold_xor32=acc; end endfunction endmodule The pseudocode for the secure isolated computational unit atomic transaction (AT) is as follows: typedef struct { uint8_trecord_type; uint16_thash_alg_id; uint16_tsig_alg_id; uint32_tkey_version; uint32_tpolicy_id; uint8_tpayload_hash

[32] ; boolhas_snap_fp; uint32_tsnap_fp; / / Note: No Seq parameter, no PrevDigest parameter }AT_Req; typedef struct { uint64_tseq; uint8_tdigest

[32] ; uint8_treceipt[RCPT_MAX]; uint16_tstatus; }AT_Rsp; staticLastCommittedLC; AT_RspAT_Execute(constAT_Req*req){ AT_Rsprsp={0}; if(is_busy())returnERR_BUSY(); / / C7: Idempotency Detection if(match_last(req,&LC)&&mc_value_unchanged()){ return make_replay_rsp(&LC); / / Non-incrementing hardware increment register } set_busy(true); / / LOAD: Internally reads the hardware increment register and the preceding summary register (cannot be specified externally). uint64_tseq=MC_read_internal(); uint8_tprev

[32] ; PDR_read_internal(prev); / / COMPUTE: The hardware incrementing register sequence is directly bound to the digest computation. uint8_tmsg[MSG_MAX]; size_tlen=pack_msg(msg,req,seq,prev); hash(req->hash_alg_id,msg,len,rsp.digest); / / SIGN sign(req->sig_alg_id,key_select(req->key_version), rsp.digest, 32, rsp.receipt); / / COMMIT_A(PhaseA) PDR_shadow_write(rsp.digest); TXN_marker_write(seq,crc32(rsp.digest),PHASE_A); flush_nvm(); / / COMMIT_B (PhaseB) - Strict order TXN_marker_write(seq+1, crc32(rsp.digest), PHASE_B); flush_nvm(); / / (i) Mark first MC_increment_internal(); / / (ii) Increment again PDR_commit_from_shadow(); / / (iii) Switch again TXN_marker_clear(); flush_nvm(); / / (iv) Clear markers TXN_marker_clear(); flush_nvm(); LC_update(&LC,req,seq,rsp.digest,rsp.receipt); rsp.seq=seq; rsp.status=STATUS_OK; set_busy(false); returnrsp; } / / After COMMIT_B is completed, a readback test must be performed. uint64_t mc_after = MC_read_internal(); if (mc_after != seq + 1) { / / Increment not yet complete enter_ABORT(); / / Triggering ABORT does not update LC return ERR_COMMIT_B_FAIL(); } LC_update(&LC, req, seq, rsp.digest, rsp.receipt); set_busy(false); void on_power_up() { TXN_Marker m = TXN_marker_read_with_crc(); if (!m.crc_ok || m.magic != TXN_MAGIC) { enter_FORENSIC_HALT(); / / Illegal value / corruption → Enter audit shutdown return; } uint64_t mc_now = MC_read_internal(); switch (m.phase) { case PHASE_NONE: return; / / No outstanding transactions case PHASE_A: PDR_shadow_clear(); TXN_marker_clear(); / / Keep the old value in MC / PDR return; case PHASE_B: if (mc_now < m.expected_seq) { / / MC has not yet finished incrementing MC_increment_internal(); / / Compensation increment } PDR_commit_from_shadow(); / / Unconditional toggle TXN_marker_clear(); return; default: enter_FORENSIC_HALT(); } } The pseudocode for the data structure definition is as follows: / / P0record struct P0_Record{ uint64seq; bytes32digest; bytesreceipt; uint8record_type; / / NORMAL=0x01,MIGRATION=0x02 uint16hash_alg_id; uint16sig_alg_id; uint32key_version; uint32policy_id; uint32payload_len; bytes32payload_hash; uint32snap_fp_opt; uint16channel_mask; uint16error_code_opt; / / Error code (optional) tlv[]ext_fields_opt; }; / / MigrationAnchorpayload structMigrationAnchorPayload{ uint16new_sig_alg_id; uint32new_key_version; bytes32new_pubkey_hash; uint64effective_seq; uint16old_sig_alg_id_opt; uint32old_key_version_opt; }; Specifically, LC_update (LastCommitted cache update) requires a hardware readback verification of the measured value of the MC register as a prerequisite atomic condition. The cache can only be updated if the measured value of MC is greater than or equal to the value before commit + 1; any readback failure will force entry into the ABORT path to avoid fault injection attacks that could cause a misalignment between the cache and register states.

[0203] In summary, this application directly binds the MC hardware sequence within the secure isolation computing unit to the digest calculation as a physical anchor. Combined with an atomic transaction design that eliminates the need for Seq / PrevDigest write parameters on the external interface, sequence number generation is transferred from the software layer to the hardware layer. The MC hardware value is automatically read and integrated into the digest calculation during the LOAD state of the atomic execution and submission unit's atomic state machine, and cannot be specified or tampered with by the main control processor. Deleting any record inevitably leads to sequence number skipping during verification, allowing the verification end to pinpoint the missing point. Even if an attacker completely controls the storage medium and obtains all parameters of the hash algorithm, they cannot forge a continuous and legitimate record chain. This achieves sequence unforgeability through "strong physical constraints" rather than "cryptographic assumptions," enabling offline temporal irreversibility without relying on network consensus.

[0204] To achieve state consistency in power-off scenarios and resolve the intermediate state defect of single-signature schemes.

[0205] This application ensures that after any power outage, the MC and PDR states will always be in the old consistent state before the commit or the new consistent state after the commit, without any mixed intermediate states, and can complete deterministic recovery without manual intervention. At the same time, through the atomic anchor transaction design, the entire process of sequence number reading, previous digest reading, digest calculation, signing, commit update, and counter increment is completed in one go within the security boundary, which ensures the indivisibility of transactions from the hardware level and effectively solves the risk of state inconsistency under power outage windows and interruption scenarios.

[0206] To achieve idempotency in communication retry scenarios and avoid semantic ambiguity of sequence numbers.

[0207] This application uses a transaction caching and duplicate request matching mechanism to directly return the previously generated transaction receipt for duplicate anchored transaction requests that completely match the payload hash and snapshot fingerprint, without performing the MC increment operation. This avoids the repeated incrementing of sequence numbers and semantic ambiguity caused by communication retries and replay attacks, and ensures a one-to-one correspondence between each record and the physical event.

[0208] To achieve controlled disclosure of data and balance the protection of trade secrets with compliance with judicial evidence collection.

[0209] This application adopts a three-level partitioned storage design (P0 / P1 / P2) combined with a t-of-n threshold encryption scheme to achieve fine-grained access control for sensitive payloads. Sensitive data can only be decrypted when at least t legitimate shares are collected. This not only ensures the offline verifiability of public metadata but also avoids the leakage of sensitive business data, while meeting the dual requirements of compliance auditing and trade secret protection.

[0210] To achieve sustainable verification across generations and address the threats posed by algorithm retirement and quantum computing.

[0211] This application integrates metadata such as hash algorithm, signature algorithm, and key version directly into digest calculation through a self-describing field binding mechanism to prevent post-event tampering; it achieves the continuity of the evidence chain during algorithm upgrades and key rotation through migration anchoring record and bridging signature design; it also supports a hybrid dual-signature mode of traditional signature and quantum-resistant signature, which can smoothly complete quantum-resistant migration and ensure the long-term verifiability of the evidence chain for 10-20 years.

[0212] Compared to VMC (TPM software virtualization), this application has certain advantages in terms of atomicity guarantee, power-loss safety, failure modes, and recalculation risk. Specifically, in terms of atomicity guarantee, VMC (TPM software virtualization) requires 6-8 TPM call sequences and relies on software transaction protocols; while this application uses a single AECU FSM, which is hardware-level uninterruptible. In terms of power-loss safety, VMC (TPM software virtualization) requires logging in storage, and power-on recovery relies on log reading; while this application uses TXN_marker two-phase marking, with Phase A / B hardware guarantee. In terms of failure modes, VMC (TPM software virtualization) may experience timeouts and deadlocks, requiring transaction rollback logic; while this application has no intermediate states, making it physically impossible for promiscuous states to occur. In terms of recalculation risk, an attacker can forge the entire subsequent chain by obtaining the hash function parameters; while in terms of recalculation risk, an attacker cannot forge the MC sequence even with the hash. Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for storing offline temporal evidence in a robotic system, characterized in that, An offline temporal evidence storage system for robotic systems, the system comprising a host processor (Host), a secure isolated computing unit (SICU), and a non-volatile storage medium, the method comprising: In response to the trigger event, the hardware same-edge freeze sampling unit captures N input signals in parallel on the same rising edge of the clock and latches them into an internal register to generate snapshot data. The clock enable of the hardware same-edge freeze sampling unit is gated off after latching is completed, and the snapshot data remains frozen until an unlock confirmation is received. The main control processor calculates the payload hash of the snapshot data and sends an anchor transaction request to the secure isolation computing unit. The anchor transaction request does not contain a sequence number parameter or a previous digest parameter, and the main control processor cannot specify the insertion position of the record. The secure isolated computing unit executes atomic anchor transactions (AT) within its hardware security boundary. These atomic anchor transactions are hardware-uninterruptible transactions and sequentially perform the following operations in an indivisible manner: Internally, the current value of the hardware increment register (MC) is read as an unforgeable physical anchor sequence number; internally, the digest value of the previous record stored in the preceding digest register (PDR) is read; the current value of the hardware increment register and the stored value of the preceding digest register are integrated into the digest calculation to generate the current record digest, ensuring that deleting any record will inevitably lead to sequence number skipping or chain digest mismatch during verification; the current record digest is signed using a non-exportable device key within the secure isolated computing unit to generate a transaction receipt; a two-phase commit update is performed with a power-loss indivisible guarantee, ensuring that the hardware increment register completes unidirectional incrementing and the preceding digest register is updated to the current record digest, guaranteeing that after any power failure, the states of the hardware increment register and the preceding digest register simultaneously maintain the old values ​​before the commit or simultaneously update to the new values ​​after the commit, without any mixed intermediate states. The external interface of the secure isolated computing unit does not provide sequence number writing parameters and preorder digest writing parameters, and the hardware increment register only allows unidirectional increment and has no external write path.

2. The method according to claim 1, characterized in that, The system further includes a hardware same-edge latch module HSL, and the method further includes: The main control processor writes the publicly verifiable metadata area containing the current record number, current record summary, and transaction receipt, as well as the encrypted payload area, into the non-volatile storage medium, and sends an unlock confirmation to the hardware edge latch module after successful writing. The offline verification terminal verifies the validity of the transaction receipt, the continuity of the sequence number, and the consistency of the chain digest in sequence based on the sequence data in the publicly verifiable metadata area, and outputs the first abnormal position and abnormal type, thereby realizing the hardware-forced offline sequence proof that cannot be reconstructed.

3. The method according to claim 2, characterized in that, The hardware same-edge frozen sampling unit includes an N-way edge-triggered D flip-flop array that shares the same clock line in the hardware same-edge latch module.

4. The method according to claim 3, characterized in that, The D flip-flop array of the hardware edge latch module HSL adopts an equal-length clock distribution structure that ensures that the clock of each channel reaches the upper deviation limit δ_skew ≤ 10ns, including H tree, Mesh grid, Spine clock distribution or symmetric buffer daisy chain. The upper bound δ_skew remains valid across the entire PVT angle within an industrial temperature range of -40℃ to +85℃ and a power supply voltage fluctuation of ±10%, with a single-stage clock buffer delay deviation not exceeding 2ns.

5. The method according to claim 3, characterized in that, The hardware edge latch module HSL has a built-in hardware timeout watchdog. If no unlock confirmation is received from the Host after a preset time window Tmax has elapsed since entering the LOCKED state, the SICU internal collaborative hardware will automatically unlock the device and forcibly generate a special anchor record with record_type = AUTO_UNLOCK and write it into the evidence chain, so that the offline verification end can identify this abnormal unlock event.

6. The method according to claim 5, characterized in that, The preset time window Tmax ≥ AT execution budget + NVM write budget + safety margin.

7. The method according to claim 3, characterized in that, When latching snapshot data, the hardware edge latching module generates a snapshot fingerprint of no less than 32 bits, snap_fp, in parallel using a CRC-32 combinational logic circuit based on an LFSR array. The input of the snapshot fingerprint includes N channel data and their channel position codes, and the snapshot fingerprint is bound to the calculation input of the current record digest.

8. The method according to claim 7, characterized in that, The snapshot fingerprint (snap_fp) width can be extended to 64 bits or 128 bits, achieved by SHA-256 truncated output.

9. The method according to claim 2, characterized in that, The publicly verifiable metadata area includes self-description fields for hash algorithm identifier, signature algorithm identifier, key version, policy number, and record type. All self-description fields are bound to the calculation input of the current record digest to prevent metadata from being tampered with afterward.

10. The method according to claim 9, characterized in that, When the hash algorithm, signature algorithm is upgraded or the key is rotated, a special migration anchor record is generated. The migration anchor record contains the new algorithm identifier, the new key version, the new public key digest and the effective sequence number boundary. The migration anchor record is at least bridged signed by the old version private key. After the verification end verifies that the bridged signature is successful, the algorithm and key suite used for subsequent verification are updated.

11. The method according to claim 2, characterized in that, The offline verification terminal does not require access to online network services, online timestamp services, or trusted third parties throughout the entire process. It completes the entire chain of validity verification solely based on plaintext data from publicly verifiable metadata areas.

12. The method according to claim 1, characterized in that, The hardware increment register and the preceding digest register are configured with only an external read path and no external write path in the hardware register address decoder of the secure isolated computing unit.

13. The method according to claim 1, characterized in that, In the two-phase commit update, Phase A is the shadow write phase, which writes the preceding summary shadow register and the transaction marker bit and completes the non-volatile memory refresh. If a power failure occurs during this phase, the system will roll back to the old state before the commit after power is restored. Phase B is the commit activation phase, which executes indivisible sub-operations in the following strict order: write the transaction marker bit TXN_marker.phase = 2 and complete the non-volatile memory refresh flush_nvm(); perform the atomic increment of the hardware increment register MC; switch the preceding summary register PDR from the shadow register PDR_shadow to commit; clear the transaction marker bit and complete the final flush_nvm(); if a power failure occurs after any sub-step, the compensation action is determined by a two-dimensional comparison between the TXN_marker phase value and the measured value of MC after power is restored.

14. The method according to claim 13, characterized in that, The Security Isolation Computing Unit (SICU) executes deterministic recovery logic upon power-up: First, it reads the transaction flag bit TXN_MARKER and its CRC checksum and magic number; when the CRC check fails or the magic number does not match, it enters the FORENSIC_HALT forensic shutdown state, rejects new anchor transaction requests, and exposes an abnormal status code; when phase = 0, it enters the ready state; when phase = 1, it executes Phase A rollback; when phase = 2, based on the two-dimensional comparison between the measured MC value and the expected_seq carried in TXN_MARKER, it performs MC increment and / or PDR switching respectively to ensure that the system converges to a unique consistent state after power-up.

15. The method according to claim 14, characterized in that, The storage structure of the transaction marker bit TXN_MARKER includes a magic field, a phase field, an expected_seq field, a digest_crc32 field, and a CRC-32 / MAC checksum bit covering it. TXN_MARKER is written to non-volatile storage media with triple redundancy and read using a majority voting mechanism to ensure that single-page damage does not disrupt recovery decisions.

16. The method according to claim 1, characterized in that, The secure isolation computing unit maintains the cache information of the last successfully submitted transaction. For duplicate anchored transaction requests that completely match the payload hash and snapshot fingerprint, it directly returns the transaction receipt generated last time and does not perform the increment operation of the hardware increment register to prevent semantic ambiguity of sequence numbers caused by communication retries.

17. The method according to claim 1, characterized in that, The device key used for signing is stored in a non-exportable storage area inside the secure isolated computing unit, or it is derived from the physically unclonable function PUF of the secure isolated computing unit combined with a fuzz extractor, and is never output to the outside of the security boundary in plaintext form throughout the process.

18. The method according to claim 1, characterized in that, The non-volatile storage medium is provided with a sensitive payload area, which is encrypted using a t-of-n threshold encryption scheme. Decryption requires no less than t legitimate shares to achieve controllable data disclosure.

19. The method according to claim 18, characterized in that, The secure isolation computing unit internally maintains a policy version increment register pv_mc. When decrypting and restoring the threshold share, it only accepts shares whose key version and policy version are not lower than the value of the current policy version increment register, rejects the injection of old version shares, and prevents policy rollback attacks. The authentication tag verification of the threshold share is bound to policy_id / key_version.

20. The method according to claim 1, characterized in that, When generating transaction receipts, a hybrid dual-signature mode of traditional digital signature and quantum-resistant digital signature is adopted. Both types of signatures are generated simultaneously and stored in a publicly verifiable metadata area to achieve smooth migration resistant to quantum attacks.

21. The method according to claim 1, characterized in that, The method further includes: if any record in the stored record sequence is deleted, the offline verification terminal detects the sequence number jump, accurately locates the position of the first missing record, and outputs the corresponding exception type.

22. The method according to claim 1, characterized in that, The hardware increment register is implemented based on a one-time programmable OTP fuse array or an eMMC RPMB hardware increment register. Physically, it only supports unidirectional increment and cannot be rolled back or reset.

23. The method according to claim 1, characterized in that, The secure isolation computing unit is equipped with an atomic execution and commit unit (AECU) state machine. During the execution of a transaction with busy=1, the state machine physically blocks the input of new anchor transaction requests through hardware AND gates, thereby ensuring the exclusive execution of atomic anchor transactions.

24. The method according to claim 23, characterized in that, The AECU state machine includes an ABORT exception exit path; If a hardware exception occurs at any stage of LOAD / COMPUTE / SIGN / COMMIT_A / COMMIT_B, the state machine is forced to enter the ABORT state. The hardware clears all intermediate states, keeps the MC and PDR registers unchanged, clears the busy flag, and returns the ERROR_AT_ABORT status code.

25. The method according to claim 1, characterized in that, The intermediate state of the atomic anchored transaction is unreadable, unresettable, or has no debug readout during the busy period.

26. The method according to claim 1, characterized in that, The snapshot data has nanosecond-level timing consistency.

27. An offline temporal evidence storage device for a robotic system, characterized in that, include: Hardware co-edge latch module HSL, host processor, security isolated computing unit SICU, and non-volatile storage medium; The latch output terminal of the hardware co-edge latch module is directly connected to the snapshot read interface of the main control processor via a dedicated data bus. The main control processor communicates with the secure isolated computing unit via an anchored transaction bus. This anchored transaction bus does not physically carry sequence number write signals or preorder digest write signals. The secure isolated computing unit internally integrates a hardware increment register (MC), a preorder digest register (PDR), an atomic execution and commit unit (AECU) state machine, a signature engine, and a non-exportable key storage area. External read paths for the hardware increment register and preorder digest register are provided by an internal address decoder, but no external write paths exist. The non-volatile storage medium is connected to the main control processor and is used to store a publicly verifiable metadata area and an encrypted payload area.

28. The apparatus according to claim 27, characterized in that, The secure isolated computing unit integrates a hardware increment register, a preorder digest register, an atomic execution and submission unit (AECU) state machine, a signature engine, and a non-exportable key storage area. Furthermore, the external interface of the secure isolated computing unit does not have sequence number write parameters or preorder digest write parameters.

29. The apparatus according to claim 27, characterized in that, In the LOCKED state, the hardware synchronous latch module HSL gates and shields external asynchronous reset signals, responding only to unlock confirmation signals from within the SICU that have undergone synchronous processing. External reset commands are physically blocked by combinational logic during the LOCKED state to ensure that latched snapshot data is not erased by external reset attacks.

Images