A verifiable change access control method and system based on SET and two atomic locks

Abstract

This invention relates to the field of computer security technology, specifically to a verifiable change access control method and system based on SET and dual atomic locks. The method includes generating a unique hash identifier for the request intent: intent_hash; constructing and issuing a certificate, which at least includes a secure execution type (SET), an expiration date, a replay protection field, a root of evidence, and a signature; binding the certificate to the intent_hash; performing expiration date checks through fast gating; and performing atomic occupancy operations based on the replay protection key. This verifiable change access control method and system based on SET and dual atomic locks achieves an end-to-end security closed loop, eliminating the possibility of execution bypass; providing industrial-grade consistency and replay protection guarantees through dual atomic operations and dual-channel consistency gating; constructing a self-verifying and tamper-proof chain of evidence, greatly improving auditability; forming a tiered defense-in-depth system, enhancing the overall system's robustness and resistance to censorship; and improving the system's determinism and observability.

Description

Technical Field

[0001] This invention relates to the field of computer security technology, specifically to a verifiable change access control method and system based on SET and dual atomic locks. Background Technology

[0002] With the deepening of enterprise digital transformation and the popularization of cloud-native architecture, the security boundary of modern application systems has gradually migrated from the traditional network layer and host layer to the application logic layer and data layer. In distributed, microservice-based business systems, the security assurance of a business operation typically involves two logical phases: authorization decision-making and actual execution.

[0003] The current mainstream security architecture in the industry follows the design principle of "separation of decision and execution." In this paradigm, an independent authorization service determines whether to "allow" or "deny" a request based on the requester's identity credentials, access context, and predefined security policies. If the decision is to allow, an intermediate credential such as a security token, ticket, or simple log entry is generated. Subsequently, the backend service executing this business logic, upon receiving the request, must verify the validity of this intermediate credential and accordingly complete the actual operations such as database writes, message sending, or API calls.

[0004] However, this asynchronous and loosely coupled architecture pattern has revealed several inherent defects in practice: First, the decision-making and execution can be bypassed. Due to configuration errors, logical vulnerabilities, or malicious tampering, the execution-side service may deviate from the original approved intent after accepting the decision token, or even execute services that have not been decided. Secondly, in high-concurrency or distributed retry scenarios, existing solutions often rely on unique database indexes or simple cache locks, which makes it difficult to guarantee strict global consistency in long chains, and can easily lead to repeated execution, state conflicts or resource overruns. When it is necessary to trace the compliance of a business operation, auditors need to manually link data from multiple isolated systems such as decision logs, execution logs, and database change records. These data lack strong cryptographic links, and their integrity and time sequence are difficult to prove and are easily questioned. At the same time, semantic security is insufficient. Traditional authorization is mostly based on coarse-grained identity and role, or static policy rules, lacking dynamic and fine-grained verification of the specific "business semantics" of this request. Attackers can exploit rule blind spots to construct illegal operations under legitimate identities.

[0005] To address the aforementioned issues, we propose an improvement: a verifiable change access control method and system based on SET and a dual atomic lock. Summary of the Invention

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: This invention provides a verifiable change admission control method based on SET and two atomic locks, comprising the following steps: S1. Generate a unique hash identifier for the request intent; S2. Construct and issue a certificate, the certificate containing at least a security execution type, validity period, anti-replay field, first root of evidence, and signature, and bind the certificate to a unique hash identifier of the request intent; S3. Perform an expiration check through the first gating and perform an atomic occupancy operation based on the anti-replay key. If the occupancy fails, proceed to the anti-replay or idempotent processing flow. S4. Verify the certificate signature through the second gating and verify the mapping relationship of the security execution type, while implementing consistency gating rules; S5. Perform an atomic commit operation based on the decision key and write it to the decision record; S6. Generate an execution encapsulation body bound to the decision record, wherein the execution encapsulation body carries execution constraint information; S7. Generate execution receipts and calculate receipt roots; S8. At least based on the first evidence root, the receipt root, and the identifier of the execution package, generate a second evidence root and store it.

[0007] As a preferred embodiment of the present invention, the unique hash identifier of the request intent is intent_hash; The steps for generating intent_hash include: normalizing the input data, which includes sorting the key-value pairs in lexicographical order, unifying the time to UTC millisecond format, prohibiting non-numeric NaN / infinite large data, converting floating-point numbers to fixed-point representation, and unifying the units of measurement.

[0008] As a preferred embodiment of the present invention, the first evidence root is evidence_root; the atomic occupancy operation is claim_if_absent operation, which is executed based on the replay_key; the atomic commit operation is commit_if_absent operation, which is executed based on the decision_key.

[0009] As a preferred technical solution of the present invention, the certificate signature field set is bound to at least: intent_hash, policy intermediate representation hash policy_ir_hash, security execution type SET, validity period start and end time valid_from / valid_until, and anti-replay field.

[0010] As a preferred embodiment of the present invention, the replay key is constructed based on the set of input fields, and its lifetime ttl_ms is not less than the certificate validity period window valid_until_ms-valid_from_ms.

[0011] As a preferred technical solution of the present invention, when the claim_if_absent operation fails, an idempotent retry branch is executed: query the existing decision record decision_record according to the decision_key; if it exists and is an allowed decision, return the associated existing execution encapsulation body; otherwise, reject the request.

[0012] As a preferred technical solution of the present invention, the second gate is a semantic gate (SemanticGate), which verifies the secure execution type SET by checking whether the correspondence between SET and policy_ir_hash and artifact_hash conforms to the preset mapping table or whitelist constraints.

[0013] As a preferred technical solution of the present invention, the consistency gating rule is a dual-channel consistency gating fail-closed, that is, if either the fast channel of the first gating or the semantic channel of the second gating is rejected, the entire system is rejected; if the semantic channel cannot complete the verification due to timeout or insufficient resources, it is rejected by default or only allowed to enter a strictly limited set of degraded allowable sets.

[0014] As a preferred technical solution of the present invention, all execution interfaces of the execution engine that generate side effects must carry and verify the capsule token (capsule_token); execution will be refused if the token is missing or invalid.

[0015] As a preferred embodiment of the present invention, the second evidence root 2 is generated according to a preset linking formula, wherein the linking formula is: evidence_root2 = H(domain prefix ||evidence_root ||receipt_root ||capsule_id), Where receipt_root is the receipt root and capsule_id is the execution package identifier.

[0016] A verifiable change access control system based on SET and dual atomic locks includes an atomic execution processor (AEP), which includes a fast gating module and a semantic gating module. The PolicyRegistry is used to store policy mappings and states. ReplayDB, a replay database, supports the atomic operation claim_if_absent; DecisionDB, a decision database, supports the commit_if_absent atomic operation. The ExecutionCapsuleEngine is used to generate and validate capsules; The Evidence / ReceiptStore repository is used to store evidence roots and receipts; The AEP sequentially calls the replay database and the decision database, and completes the closed loop through the execution encapsulation engine and the evidence receipt repository.

[0017] As a preferred technical solution of the present invention, the atomic commit operation commit_if_absent of the decision database DecisionDB returns one of the following three states: created (new creation), existing (existing, consistent record already exists), or conflict (conflict). If it is in the existing state, the existing decision is reused; if it is in the conflict state, fail-closed (rejection) is triggered.

[0018] As a preferred technical solution of the present invention, the PolicyRegistry records the policy hash (policy_hash), the policy intermediate representation hash (policy_ir_hash), the mapping whitelist of the security execution type (SET), the revocation list, and the status (ACTIVE / REVOKED / DEPRECATED). If the policy status is REVOKED, AEP rejects the relevant request.

[0019] As a preferred embodiment of the present invention, the execution encapsulation body is a capsule; the execution encapsulation body engine ExecutionCapsuleEngine supports injecting a determinism configuration file (determinism_profile) into the capsule and verifying the consistency between the configuration file and the capsule fields during execution.

[0020] As a preferred technical solution of the present invention, the Evidence / ReceiptStore provides a verifiable query interface based on intent_hash, decision_key, or capsule_id, which is used by third parties to conduct closed-loop review of the permitted decision and execution results.

[0021] The beneficial effects of this invention are as follows: This verifiable change access control method and system based on SET and dual atomic locks achieves an end-to-end security closed loop, eliminating the possibility of execution bypass; through dual atomic operations and dual-channel consistency gating, it provides industrial-grade consistency and anti-replay guarantees; it constructs a self-verifying and tamper-proof evidence chain, greatly improving auditability; it forms a gradient defense-in-depth system, enhancing the robustness and anti-censorship of the overall system; it improves the determinism and observability of the system, and enhances the transparency and trustworthiness of the system. Attached Figure Description

[0022] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is the core flowchart of a security decision-making method based on SET and a dual-atomic lock, which is a verifiable change access control method of the present invention. Figure 2 This is an architecture module diagram of a verifiable change access control system based on SET and dual atomic locks according to the present invention. Figure 3 This is a schematic diagram of the gradient defense layer of a verifiable change admission control method and system based on SET and dual atomic locks according to the present invention. Figure 4 This is a closed-loop evidence chain structure diagram of a verifiable change access control method and system based on SET and dual atomic locks according to the present invention; Detailed Implementation

[0023] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0024] like Figures 1-4 As shown, a verifiable change admission control method based on SET and two atomic locks includes the following steps: A unique hash identifier for generating the request intent; Construct and issue a certificate that includes at least a security execution type, validity period, anti-replay field, first root of evidence, and signature, and bind the certificate to a unique hash identifier of the request intent; The validity period is checked through the first gate, and an atomic occupancy operation is performed based on the anti-replay key. If the occupancy fails, the anti-replay or idempotent processing flow is entered. The second gating system verifies the signature of the certificate and the mapping relationship of the security execution type, while implementing consistency gating rules. An atomic commit operation is performed based on the decision key, and the decision record is written. Generate an execution encapsulation body bound to the decision record; the execution encapsulation body carries execution constraint information. Generate an execution receipt and calculate the receipt root; At least based on the first evidence root, the receipt root, and the identifier of the execution encapsulation body, a second evidence root is generated and stored.

[0025] The unique hash identifier of the request intent is intent_hash; The steps to generate intent_hash include: normalizing the input data, which includes sorting the key-value pairs in lexicographical order, unifying the time to UTC millisecond format, prohibiting non-numeric NaN / infinite large data, converting floating-point numbers to fixed-point representation, and unifying the units of measurement.

[0026] The first evidence root is evidence_root; the atomic occupancy operation is claim_if_absent, which is executed based on the replay_key; the atomic commit operation is commit_if_absent, which is executed based on the decision_key.

[0027] The certificate signing field set must be bound to at least: intent_hash, policy intermediate representation hash policy_ir_hash, security execution type SET, validity period start and end time valid_from / valid_until, and anti-replay field.

[0028] The replay key is constructed based on the set of input fields, and its time to life (ttl_ms) is not less than the certificate validity window (valid_until_ms - valid_from_ms).

[0029] When the claim_if_absent operation fails, execute the idempotent retry branch: query the existing decision record decision_record by decision_key; if it exists and is an allowed decision, return the associated existing execution wrapper; otherwise, reject the request.

[0030] The second gate is the semantic gate SemanticGate, which verifies the secure execution type SET by checking whether the correspondence between SET and policy_ir_hash and artifact_hash conforms to the preset mapping table or whitelist constraints.

[0031] The consistency gating rule is a dual-channel consistency gating fail-closed, meaning that if either the fast channel of the first gating or the semantic channel of the second gating is rejected, the entire channel is rejected; if the semantic channel cannot complete the verification due to timeout or insufficient resources, it is rejected by default or only allowed to enter a strictly limited set of allowed downgrades.

[0032] All execution interfaces of the execution engine that produce side effects must carry and verify the capsule token (capsule_token); execution will be refused if the token is missing or invalid.

[0033] The second evidence root, evidence_root2, is generated based on a preset linking formula, which is: evidence_root2= H(domain prefix||evidence_root||receipt_root||capsule_id), where receipt_root is the receipt root and capsule_id is the execution package identifier.

[0034] A verifiable change access control system based on SET and dual atomic locks includes an atomic execution processor (AEP), which includes a fast gating module and a semantic gating module. The PolicyRegistry is used to store policy mappings and states. ReplayDB, a replay database, supports the atomic operation claim_if_absent; DecisionDB, a decision database, supports the commit_if_absent atomic operation. The ExecutionCapsuleEngine is used to generate and validate capsules; The Evidence / ReceiptStore repository is used to store evidence roots and receipts; AEP calls the replay database and decision database in sequence, and completes the closed loop by executing the encapsulation engine and the evidence receipt repository.

[0035] The atomic commit operation `commit_if_absent` in the DecisionDB database returns one of three states: `created` (newly created), `existing` (already exists with a consistent record), or `conflict` (conflict). If it is `existing`, the existing decision is reused; if it is `conflict`, a `fail-closed` rejection is triggered.

[0036] The Policy Registry records the policy hash (policy_hash), the policy intermediate representation hash (policy_ir_hash), the mapping whitelist of the security execution type (SET), the revocation list, and the status (ACTIVE / REVOKED / DEPRECATED). If the policy status is REVOKED, AEP will reject the relevant request.

[0037] The execution encapsulation body is a capsule; the execution encapsulation engine ExecutionCapsuleEngine supports injecting a determinism configuration file (determinism_profile) into the capsule and verifying the consistency between the configuration file and the capsule fields during execution.

[0038] The Evidence / ReceiptStore repository provides a verifiable query interface based on intent_hash, decision_key, or capsule_id, allowing third parties to conduct closed-loop review of permitted decisions and execution results.

[0039] Example: Secure firmware update for industrial robots S1: A unique hash identifier for generating the request intent.

[0040] The upgrade management platform constructs an intent description for this firmware update, including fields such as the target robot device ID, the firmware image hash to be upgraded (fw_image_hash:"0xabc123..."), and the upgrade time window. The system standardizes this intent description, for example, by sorting it by field name and standardizing the time format, and then calculates its hash value to obtain the intent_hash of this update request.

[0041] S2: Construct and issue certificates.

[0042] The policy engine determines whether the firmware update request is allowed based on the security policy. If allowed, a secure execution certificate is constructed. In this certificate, the secure execution type SET is defined as FIGRMWARE_UPDATE, explicitly indicating its semantics as a firmware upgrade operation. The certificate also includes a validity period, a replay protection field, a first evidence root (evidence_root), and can be bound to the policy hash, intent_hash, and the digital signature of the authorization service. This certificate is strongly bound to the intent_hash.

[0043] S3: Dual atomic lock gate.

[0044] Upon receiving the upgrade instructions and certificate, the Atomic Execution Processor (AEP) within the robot controller initiates the verification process.

[0045] The first atomic lock, or fast gating and occupancy, involves AEP first checking if the certificate is valid. Next, it constructs a unique replay_key (e.g., RB-001_FW_UPDATE_2023100102) using the anti-replay field in the certificate and initiates a claim_if_absent atomic operation to the ReplayDB database. This operation ensures that within the same time window, a firmware update request for robot RB-001 can only be successfully processed once, preventing duplicate or conflicting update attempts from the source.

[0046] The second atomic lock, namely semantic gating and commit: After the quick check passes, AEP enters semantic gating. It verifies the certificate signature, recalculates and compares the intent_hash, and critically verifies whether SET=FIRMWARE_UPDATE matches the current context and the preset security policy, such as allowing only signed firmware versions to be installed on this robot model. After all verifications pass, AEP initiates a commit_if_absent atomic operation to the decision database DecisionDB based on the decision_key, permanently writing a decision record decision_record that "allows this firmware update". This operation is atomic, ensuring that even under concurrent requests, only one consistent decision is ultimately committed.

[0047] Step S4: Generate the execution package, i.e., the capsule.

[0048] After the decision is atomically submitted, the system generates an execution capsule. In this industrial scenario, the execution constraint information carried within the capsule is particularly important, for example: determinism_profile: This configuration file specifies that the firmware flashing process must be completed in an isolated, uninterrupted execution environment, pausing all other non-critical tasks during the flashing process to ensure determinism.

[0049] Deadline execution time: must be strictly aligned with the maintenance window; failure to complete within the time limit is considered a failure.

[0050] capsule_token: A unique and unforgeable credential used in subsequent execution phases.

[0051] S5: Execution, generation of receipts, and closed-loop evidence chain.

[0052] Before performing the actual flashing operation, the firmware update engine must verify and "activate" this capsule token. Upon successful flashing, the engine generates an execution receipt, including the final firmware version number, flashing time, integrity checksum, etc., and calculates the receipt root (receipt_root). Finally, according to preset rules, the system combines the initial evidence_root from the decision-making stage, the receipt_root from this execution, and the capsule ID (capsule_id) to generate the final, tamper-proof second evidence root (evidence_root2) and stores it. Thus, an end-to-end evidence chain is formed from "update decision" to "update execution completion," providing one-stop verification for internal audits or external compliance checks.

[0053] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A verifiable change access control method based on SET and a two-atomic lock, characterized in that, Includes the following steps: S1. Generate a unique hash identifier for the request intent; S2. Construct and issue a certificate, the certificate containing at least a security execution type, validity period, anti-replay field, first root of evidence, and signature, and bind the certificate to a unique hash identifier of the request intent; S3. Perform an expiration check through the first gating and perform an atomic occupancy operation based on the anti-replay key. If the occupancy fails, proceed to the anti-replay or idempotent processing flow. S4. Verify the certificate signature through the second gating and verify the mapping relationship of the security execution type, while implementing consistency gating rules; S5. Perform an atomic commit operation based on the decision key and write it to the decision record; S6. Generate an execution encapsulation body bound to the decision record, wherein the execution encapsulation body carries execution constraint information; S7. Generate execution receipts and calculate receipt roots; S8. At least based on the first evidence root, the receipt root, and the identifier of the execution package, generate a second evidence root and store it.

2. The verifiable change access control method based on SET and dual atomic lock according to claim 1, characterized in that, The unique hash identifier for the request intent is intent_hash; The steps for generating intent_hash include: normalizing the input data, which includes sorting the key-value pairs in lexicographical order, unifying the time to UTC millisecond format, prohibiting non-numeric NaN / infinite large data, converting floating-point numbers to fixed-point representation, and unifying the units of measurement.

3. The verifiable change access control method based on SET and dual atomic lock according to claim 2, characterized in that, The first evidence root is evidence_root; the atomic occupancy operation is claim_if_absent operation, which is executed based on the replay_key; the atomic commit operation is commit_if_absent operation, which is executed based on the decision_key.

4. The verifiable change access control method based on SET and dual atomic lock according to claim 3, characterized in that, The certificate signature field set must be bound to at least: intent_hash, policy intermediate representation hash policy_ir_hash, security execution type SET, validity period start and end time valid_from / valid_until, and anti-replay field.

5. The verifiable change admission control method based on SET and dual atomic lock according to claim 4, characterized in that, The replay key is constructed based on the set of input fields, and its lifetime ttl_ms is not less than the certificate validity period window valid_until_ms-valid_from_ms.

6. The verifiable change access control method based on SET and dual atomic lock according to claim 5, characterized in that, When the claim_if_absent operation fails, an idempotent retry branch is executed: query an existing decision record decision_record based on the decision_key; if it exists and is an allowed decision, return the associated existing execution wrapper; otherwise, reject the request.

7. The verifiable change access control method based on SET and dual atomic lock according to claim 1, characterized in that, The second gate is the semantic gate (SemanticGate), which verifies the secure execution type SET by checking whether the correspondence between SET and policy_ir_hash and artifact_hash conforms to the preset mapping table or whitelist constraints.

8. The verifiable change access control method based on SET and dual atomic lock according to claim 1, characterized in that, The consistency gating rule is a dual-channel consistency gating fail-closed, meaning that if either the fast channel of the first gating or the semantic channel of the second gating is rejected, the entire system is rejected; if the semantic channel cannot complete the verification due to timeout or insufficient resources, it is rejected by default or only allowed to enter a strictly limited set of allowed downgrades.

9. The verifiable change access control method based on SET and dual atomic lock according to claim 1, characterized in that, All execution interfaces of the execution engine that produce side effects must carry and verify the capsule token (capsule_token); execution will be refused if the token is missing or invalid.

10. The verifiable change access control method based on SET and dual atomic lock according to claim 1, characterized in that, The second evidence root, evidence_root2, is generated according to a preset linking formula, which is: evidence_root2=H(domain prefix||evidence_root||receipt_root||capsule_id), where receipt_root is the receipt root and capsule_id is the execution encapsulation identifier.

11. A verifiable change access control system based on SET and dual atomic locks, applied to the verifiable change access control method based on SET and dual atomic locks as described in any one of claims 1-10, characterized in that, This includes an atomic execution processor (AEP), which comprises a fast gating module and a semantic gating module; The PolicyRegistry is used to store policy mappings and states. ReplayDB, a replay database, supports the atomic operation claim_if_absent; DecisionDB, a decision database, supports the commit_if_absent atomic operation. The ExecutionCapsuleEngine is used to generate and validate capsules; The Evidence / ReceiptStore repository is used to store evidence roots and receipts; The AEP sequentially calls the replay database and the decision database, and completes the closed loop through the execution encapsulation engine and the evidence receipt repository.

12. A verifiable change access control system based on SET and dual atomic locks according to claim 11, characterized in that, The atomic commit operation `commit_if_absent` of the DecisionDB database returns one of the following three states: `created` (new creation), `existing` (existing consistent record), or `conflict` (conflict). If it is in the `existing` state, the existing decision is reused; if it is in the `conflict` state, `fail-closed` (rejection) is triggered.

13. A verifiable change access control system based on SET and dual atomic locks according to claim 11, characterized in that, The Policy Registry records the policy hash (policy_hash), the policy intermediate representation hash (policy_ir_hash), the mapping whitelist between the security execution type (SET), the revocation list, and the status (ACTIVE / REVOKED / DEPRECATED). If the policy status is REVOKED, AEP rejects the relevant request.

14. A verifiable change access control system based on SET and dual atomic locks according to claim 11, characterized in that, The execution encapsulation body is a capsule; the execution encapsulation body engine ExecutionCapsuleEngine supports injecting a determinism configuration file (determinism_profile) into the capsule and verifying the consistency between the configuration file and the capsule fields during execution.

15. A verifiable change access control system based on SET and dual atomic locks according to claim 11, characterized in that, The Evidence / ReceiptStore repository provides a verifiable query interface based on intent_hash, decision_key, or capsule_id, which is used by third parties to conduct closed-loop review of permitted decisions and execution results.

Images