An end-to-end cloud multi-level multi-domain access control method

Abstract

The present application relates to the field of Internet of Things security and computing scheduling, and particularly relates to a kind of end edge cloud multistage multi-domain access control method, which method includes: first according to service level requirement and compliance clause generates intention constraint description and establishes session root and one-time session token;Each layer carries remote proof and execution commitment and submits bid in parallel, and control plane verifies to form a bid package set;Under the constraint, joint arrangement solution is determined, stage is settled and cross-domain data path is determined, and minimum data disclosure rule and minimum feasible plan are generated, and stage token is issued;Each stage executes according to token and generates execution proof, and control plane verifies and enters account after verification, and switches between backup plan and current plan according to verification and operation monitoring, and completes verifiable and traceable operation closed loop.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) security and computing scheduling, and in particular to a multi-level, multi-domain access control method for edge-cloud. Background Technology

[0002] The large-scale deployment of the Internet of Things (IoT) enables frequent data flow between terminals, near-end computing, and central computing power, placing simultaneous demands on latency, compliance, and traceability. Industries commonly face scenarios involving data sovereignty constraints, cross-regional regulatory differences, heterogeneous equipment, and fluctuating loads. There is an urgent need to establish a unified closed loop for access control, scheduling, and auditing across multiple computing layers and regions to reduce compliance and service interruption risks, and to ensure verifiable, on-demand allocation of computing power and bandwidth. Summary of the Invention

[0003] To address the numerous problems existing in the prior art, this invention provides a multi-level, multi-domain access control method for edge-cloud. This invention uses intent constraints to describe unified compliance requirements and service level requirements, and implements access control based on session roots and one-time session tokens. Terminal nodes, edge nodes, and cloud nodes bid in parallel, carrying remote proofs and execution commitments. The control plane jointly orchestrates to generate minimum feasible plans and minimum data leakage rules and issues phase tokens. During the execution phase, execution proofs are generated and combined with operational monitoring to switch backup plans, forming a verifiable and traceable closed loop.

[0004] A method for multi-level, multi-domain access control between edge and cloud includes the following steps:

[0005] Generate intent constraint descriptions and establish session roots and one-time session tokens based on service levels and compliance terms;

[0006] Terminal nodes, edge nodes, and cloud nodes submit bids in parallel based on intent constraint descriptions. The terminal nodes perform irreversible feature extraction on the original measurement data and combine it with remote proof and execution commitment to form a terminal node bid package. The edge node bid package and cloud node bid package contain capability statements and remote proof and execution commitment. After control plane verification, a set of bid packages is formed.

[0007] Under the constraints of intent description, the set of bid packages is jointly orchestrated and solved to determine the phase placement, cross-domain data paths and minimum data leakage rules, generate the minimum feasible plan and distribute phase tokens by the control plane.

[0008] Each stage is executed based on the stage token, outputs result data and generates an execution certificate. The control plane verifies the execution certificate and switches the backup plan or maintains the current plan based on the verification results and operation monitoring data. The result data and execution certificate are registered in the session-level audit log.

[0009] Preferably, the terminal node performs de-identification mapping and feature compression on the original measurement data according to the irreversible transformation operator sequence to generate irreversible feature data, and generates a commitment value with a random factor derived from the session root. The commitment value, the irreversible transformation operator sequence identifier, and the remote proof and execution commitment are bound together as the data payload and evidence set of the terminal node's bid package.

[0010] Preferably, the remote proof records the platform measurement information and the trusted execution environment measurement information, signs them with the device private key and binds them to the session root, and the execution commitment records the mirror fingerprint and policy fingerprint and binds them to the session root. The control plane performs digital signature verification, certificate chain verification and time window verification on the remote proof and execution commitment and then includes them in the bid package set.

[0011] Preferably, the capability declaration in the edge node bid package explicitly states the ability to perform summation and aggregation on homomorphic encrypted features within the ciphertext domain and the ability to perform outlier suppression using the grouped mean-median method on the sketch feature digest, and explicitly states the execution queue strategy and resource occupancy status for each stage in the cross-domain data path.

[0012] Preferably, the capability declaration in the cloud node bidding package explicitly states the constraint that decryption and reasoning are completed within a trusted execution environment and that the key does not leave the trusted execution environment, and explicitly states the constraint that the processing location and the range of result return are limited according to data residency requirements.

[0013] Preferably, the control plane's verification of the bid package set includes verification of the validity period of the one-time session token, verification of the session root binding relationship, verification of the consistency of field names, verification of the consistency of field value ranges, verification of the correspondence between the commitment value and the irreversible transformation operator sequence identifier, and verification of the consistency between the data resident domain label and the execution node region.

[0014] Preferably, the joint orchestration solution is based on the assembly graph consisting of stage nodes and transmission edges to construct a multi-objective comprehensive evaluation, and selects the assembly solution under the constraints of privacy level, data residence domain, trusted execution level, end-to-end latency budget and cost budget, and generates stage placement and cross-domain data paths.

[0015] Preferably, the minimum data leakage rule is written into the minimum feasible plan with a hop-by-hop field whitelist and a hop-by-hop data residence domain label, and a phase token is written synchronously. The execution node only allows data that is included in the field whitelist and whose label matches.

[0016] Preferably, the stage token contains the stage identifier, validity period, set of fields allowed to be processed, data residency domain label, trusted execution environment metric fingerprint, irreversible transformation operator sequence identifier, and data path identifier. Before stage execution, the execution node completes signature verification and session root verification.

[0017] Preferably, the control plane performs the verification as a prerequisite for registering the result data into the session-level audit log, and selects a backup plan in a preset order and replaces the stage token and records the switchover log when latency drift, field overriding, or data inconsistency is detected.

[0018] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows:

[0019] By employing intent constraint description, session roots, and one-time session tokens, we achieved unified session-level constraints and anti-replay access control. Through remote proof and parallel bidding of execution commitments, we ensured that only candidates with environmental and policy evidence were accepted for scheduling computation. Through joint orchestration and multi-objective comprehensive evaluation, we achieved phased placement and cross-domain data path selection under constraints of latency, cost, risk, and accuracy. Through minimum data leakage rules, hop-by-hop field whitelists, and hop-by-hop data residency domain labels, we achieved outbound domain control, ensuring only the necessary fields for each hop are sent out and that the geographic region is consistent. Through phase tokens, we achieved the ability to allow locally determined fields before execution, ensuring geographic and environmental consistency. Through execution proof, operational monitoring, and backup plan switching, we achieved verifiable results before accounting and plan replacement and continuous service under abnormal triggering. Through session-level audit logging, we achieved end-to-end chained accounting and compliance traceability. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the method of the present invention. Detailed Implementation

[0021] The embodiments of the present disclosure will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the disclosure. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the present disclosure for ease of explanation.

[0022] A method for multi-level, multi-domain access control between edge and cloud includes the following steps:

[0023] Generate intent constraint descriptions and establish session roots and one-time session tokens based on service levels and compliance terms;

[0024] The intent constraint description is a set of machine-readable constraints formed after the control plane performs structured parsing of service levels and compliance terms. This set addresses the end-to-end data and computation chain, providing constraints and boundaries at both the field and stage levels. Specifically, it includes: privacy level, data residency domain, end-to-end latency budget, trusted execution level, cost or energy budget, weight vectors for latency and cost, risk and accuracy, data category, and sensitivity classification. To facilitate the subsequent implementation of strong constraints, the intent constraint description also establishes a set of rules for field whitelist baselines and data residency domain labels, and provides the expression format for stage-level constraints. All the above items use definitive terminology and fixed field names to avoid open-ended or vague expressions.

[0025] The session root is used to bind all evidence, commitments, tokens, and results of this task to a single session context. Within the security boundary, the control plane calls key derivation functions, task identifiers, and timestamps to generate the session root, deriving the signing key and message verification key for this session, and setting the validity period and allowed geographic range. The session root resides only in the control plane's security domain and is not distributed in plaintext to end nodes, edge nodes, or cloud nodes. End nodes, edge nodes, and cloud nodes participate in verification using tokens and binding information issued by the control plane.

[0026] One-time session tokens are used for access control and anti-replay measures before execution and bidding. The token is generated based on an intent constraint description and includes a session identifier, an intent constraint description digest, a set of allowed geographic and data residency domain labels, a field whitelist fingerprint, a token validity period, trusted execution level requirements, remote proof type requirements, execution commitment content requirements, and an anomaly trigger threshold digest. The control plane digitally signs the token body and generates a message verification code using a message verification code key derived from the session root; each token is uniquely bound to the session root. The token serves as the sole authorization credential between the control plane and terminal nodes, edge nodes, and cloud nodes; any subsequent remote proof, execution commitment, and execution proof must carry the token fingerprint and session root binding information.

[0027] In principle, intent constraint descriptions transform service levels and compliance terms from natural language into decidable constraints, eliminating ambiguity before execution. Session roots establish trusted boundaries at the session level, rejecting cross-session evidence reuse. One-time session tokens employ a dual mechanism of short-term valid signatures and message verification codes to implement anti-replay and cross-domain tracing, ensuring that bidding and execution occur within the same security and compliance context. The synergy of these three elements allows the control plane to accept only bid packages with session bindings and constraint satisfaction in subsequent steps, and to directly reference field whitelist baselines and data residency domain labels when generating the minimum feasible plan, achieving hop-by-hop strong constraint distribution.

[0028] The corresponding effects are reflected in three aspects. In terms of compliance, the field whitelist baseline and data-residence domain labels are compiled once within the intent constraint description and a digest is transmitted in the token, thus forcing hop-by-hop verification in subsequent stages. In terms of security, the session root and one-time session token unify the signature and time window of remote proof and execution commitment with the session identifier, preventing the replay of static identities and timestamps. In terms of orchestration, the intent constraint description transforms latency budgets and cost or energy budgets and trusted execution levels into hard constraints and weights that can directly participate in orchestration solving, enabling joint orchestration solving to calculate feasible domains without re-parsed natural language clauses.

[0029] Example: Cameras, vibration sensors, and temperature / humidity sensors are deployed in an industrial park. The business requires that the end-to-end latency budget not exceed a specified threshold, compliance clauses require that facial recognition data be de-identified within the local domain and not exported, and trusted execution level requirements require controlled decryption within a trusted execution environment. The control plane first matches compliance clauses in the rule base, generating privacy level, data residency domain, and trusted execution level entries; combining business-side latency and cost / energy consumption requirements with risk weights, it generates weight vector entries; combining the data catalog, it marks camera data as a high-level sensitive category and vibration and temperature / humidity data as low-level sensitive categories; based on this, it forms an intent constraint description and generates a field whitelist baseline and data residency domain label rules. The control plane derives a session root using the system master key, task identifier, and time stamp, setting the validity period and allowed geographical range; subsequently, it generates a one-time session token, writes the session identifier, intent constraint description summary, allowed geographical range, field whitelist fingerprint, token validity period, trusted execution level requirements, remote proof type requirements, and execution commitment content requirements, and completes the generation of digital signatures and message verification codes. The control plane issues bidding announcements and one-time session tokens to terminal nodes, edge nodes, and cloud nodes. During subsequent parallel bidding, terminal nodes, edge nodes, and cloud nodes reference this token fingerprint and bind it to the session root. The control plane only accepts bids that satisfy the intent constraint description and token verification, thus achieving parallel admission with sessions as the boundary.

[0030] Terminal nodes, edge nodes, and cloud nodes submit bids in parallel based on intent constraint descriptions. The terminal nodes perform irreversible feature extraction on the original measurement data and combine it with remote proof and execution commitment to form a terminal node bid package. The edge node bid package and cloud node bid package contain capability statements and remote proof and execution commitment. After control plane verification, a set of bid packages is formed.

[0031] This invention establishes a parallel bidding mechanism between the control plane and terminal nodes, edge nodes, and cloud nodes. All bids are subject to intent constraint description and one-time session token as admission prerequisites. After formal verification, the control plane aggregates the bid packages into a set for subsequent joint orchestration and solution.

[0032] The terminal node performs irreversible feature extraction on the original measurement data based on the field whitelist and data residency domain label in the intent constraint description, generating irreversible feature data. Within the trusted execution environment, it then generates a remote proof and execution commitment. To ensure the integrity and consistency of the irreversible feature data, the terminal node hashes the irreversible feature data with a random factor derived from the session root to generate a commitment value, calculated as C = H(φ(x)||s). Here, C represents the commitment value, H represents the cryptographic hash function, φ(x) represents the irreversible feature data, x represents the original measurement data, and s represents the random factor derived from the session root. The terminal node packages the fingerprint of the irreversible feature data, the commitment value, the remote proof, and the execution commitment into a terminal node bid package.

[0033] Edge nodes generate capability claims based on intent constraints. These capability claims include at least the ability to aggregate cryptographic features, the ability to merge feature digests and suppress anomalies, the resource usage status for local execution phases, and the corresponding remote proofs and execution commitments. Edge node bid packages do not carry raw data; they only record the data categories that can be processed, the fingerprints of allowed field sets, and the time window and geographic range bound to the session root.

[0034] Cloud nodes provide capability statements based on intent constraint descriptions and trusted execution levels. The capability statements include at least the ability to complete controlled decryption and model inference within a trusted execution environment, model fingerprints and processing location restrictions, and are accompanied by remote proof and execution commitments, forming a cloud node bidding package.

[0035] To ensure bid comparability, all three bid packages submitted a predicted indicator vector, denoted as... Among them, v j This represents the vector of prediction indicators for the j-th bid. Indicates the predicted end-to-end latency. ρ represents the predicted calculation and transmission cost. j This represents the risk score. The prediction index vector serves as input for subsequent joint orchestration and solution, and the solution process is not provided in this invention.

[0036] The control plane performs token signature verification, session root binding verification, and time window verification on arriving bid packages. It also performs set constraint verification on field whitelists and data-resident domain labels, requiring... and Among them, F j F represents the set of allowed fields for the j-th bid declaration. baseline Represents the whitelist baseline of fields derived from the intent constraint description, R j Let R represent the set of regions for processing the j-th bid declaration. allowedThis indicates that geographic sets are allowed. Simultaneously, it controls the consistency between the control plane verification commitment value and the irreversible feature data fingerprint, verifies the certificate chain and trusted execution environment metric of remote proof, verifies the mirror fingerprint and policy fingerprint in the execution commitment, and aggregates the verified bids into a bid package set.

[0037] The principle behind this parallel bidding mechanism is characterized by three points. First, it uses intent constraints to describe a unified whitelist of fields, data residency domains, and trusted execution levels, eliminating ambiguities in compliance clauses among nodes. Second, it binds remote proofs and execution commitments and commitment values ​​to session roots, ensuring verifiable consistency of evidence and data within the same session and preventing cross-session reuse. Third, it uses predictive indicator vectors to achieve comparability alignment during the submission phase, directly providing computable input for subsequent joint orchestration and solution, reducing secondary extraction and redundant modeling. These three points work together to enable the control plane to converge a set of structurally consistent and evidentiarily complete bid packages within the same time window.

[0038] The corresponding effects are reflected in security, compliance, and orchestration. In terms of security, the commitment value binds irreversible characteristic data to the session root, forming a triple consistency chain of "data fingerprint, runtime environment, and policy fingerprint" in conjunction with remote proof and commitment execution. Regarding compliance, set constraint verification blocks unauthorized fields and out-of-bounds regions during the bidding stage, avoiding violations being discovered only in the later stages of joint orchestration. In terms of orchestration, predictive indicator vectors and capability declarations provide directly usable quantitative inputs for subsequent placement and cross-domain data path optimization, improving the stability of subsequent decisions.

[0039] Example: After the joint task of video monitoring and vibration monitoring in the park is triggered, the control plane issues one-time session tokens to terminal nodes, edge nodes, and cloud nodes. Camera terminal nodes perform irreversible feature extraction on images according to a field whitelist, generating irreversible feature data. They then generate commitment values ​​for the irreversible feature data and random factors derived from the session root, forming a terminal node bid package together with remote proof and execution commitment. Park edge nodes declare their capabilities in local encrypted feature aggregation, feature digest merging, and anomaly suppression, marking resource occupancy status, and attaching remote proof and execution commitment to form an edge node bid package. Regional cloud nodes declare their ability to complete controlled decryption and model inference within a trusted execution environment, providing model fingerprints and processing location constraints, forming a cloud node bid package. Each of the three bid packages provides a prediction index vector. The control plane performs token signature verification, session root binding verification, and time window verification on the three bid packages, checking that the field sets and region sets of each bid satisfy set constraint verification, verifying the consistency of remote proof and execution commitment with the commitment value, and including the verified bids as a bid package set to provide input for subsequent joint orchestration and solution.

[0040] Preferably, the terminal node performs de-identification mapping and feature compression on the original measurement data according to the irreversible transformation operator sequence to generate irreversible feature data, and generates a commitment value with a random factor derived from the session root. The commitment value, the irreversible transformation operator sequence identifier, and the remote proof and execution commitment are bound together as the data payload and evidence set of the terminal node's bid package.

[0041] For terminal node-side processing and evidence collection in the parallel bidding process, the goal is to generate irreversible feature data and bind it to session-level evidence within the terminal node, and encapsulate both, along with runtime environment metrics and execution policy commitments, into a data payload and evidence set for the terminal node bidding package, which can be directly invoked by the control plane for admission and subsequent orchestration.

[0042] The endpoint configures an irreversible transformation operator sequence based on the field whitelist and data residency domain labels in the intent constraint description. This sequence consists of several edge-executable de-identification mapping operators and feature compression operators in a fixed order, applied sequentially to the original measurement data to output irreversible feature data. For auditing and reproducibility, the endpoint records the operator sequence identifier and version list, adding them to subsequent execution commitment entries. This design ensures that data minimization is completed at the source, eliminating the need to externalize highly sensitive fields.

[0043] The application of irreversible transformation operator sequences is defined by a combinational mapping approach. Let the original measurement data be x, and let the operator sequence be... Let the irreversible feature data be φ(x), then: Among them, o i Let be the i-th operator, and k be the number of operators. This expression is used to clarify the determinism and sequentiality of end-side processing, avoiding inconsistent interpretations of the same data in subsequent stages.

[0044] To establish session-level source binding and tamper-proof verification, the terminal node calculates a commitment value for irreversible feature data and associates it with the session context. Let the commitment value be C, the cryptographic hash function be H, and the random factor derived from the session root be s, then: C = H(φ(x)||s), where || represents concatenation. By incorporating the random factor derived from the session root into the commitment value calculation, cross-session replay and offline substitution can be prevented. The commitment value and the irreversible feature data fingerprint are written together into the evidence set, and the control plane uses this to complete consistency verification.

[0045] Remote authentication and execution commitments are used to verify the operating environment and execution policy before the bidding stage. Remote authentication provides platform metrics and trusted execution environment metrics, signed with a device-side key and bound to the session root. The execution commitment contains a mirror fingerprint and a policy fingerprint. The policy fingerprint includes at least operator sequence identifiers, field whitelist digests, data residency domain labels, and resource lease information, and is bound to the session root. Together, they eliminate the vulnerability of "static identity verification but uncontrolled execution policy," enabling the control plane to determine environmental trustworthiness and policy consistency upon receiving a bid.

[0046] The assembly of terminal node bid packages follows the principles of "data minimization and evidence completeness." The data payload contains only irreversible feature data fingerprints and a small amount of statistical derivation required for subsequent edge aggregation (only those belonging to non-sensitive categories are whitelisted). The evidence set includes commitment values, remote proofs, executed commitments, and operator sequence identifiers. All entries, along with the binding information of one-time session tokens and session roots, are submitted together to form a structured terminal node bid package. The control plane performs token signature verification, session binding verification, time window verification, and set constraint verification of field whitelists and data residing domains on the bid packages. Those that meet the requirements are included in the bid package set for subsequent joint orchestration and solution.

[0047] The design's principles and effects are reflected in three aspects. First, the combined implementation of irreversible source transformation and field whitelisting prevents highly sensitive information from entering cross-domain paths, satisfying the strong constraints of data residency domain labels. Second, random factors derived from the session root are incorporated into the commitment value calculation, creating a verifiable one-to-one correspondence between irreversible feature data and the session context, avoiding cross-session reuse and offline replacement. Third, remote verification and commitment execution complete strong consistency checks of the environment and policies before bidding, allowing the control plane to directly perform assembly calculations without additional evidence gathering interactions, thereby shortening orchestration preparation time and improving admission determinism.

[0048] Example: A camera and a vibration acquisition terminal within the park participate in the bidding as terminal nodes. The intent constraint description restricts image-related fields from going out of domain and limits the end-to-end latency budget and trusted execution level. The terminal node configures de-identification mapping operators and feature compression operators for image modes, and frequency band energy aggregation operators and extreme value statistics operators for vibration modes, forming an irreversible transformation operator sequence. The terminal node performs the irreversible transformation operator sequence on the original measurement data, generating irreversible feature data based on the combined mapping expression; it uses random factors derived from the session root to participate in the commitment value calculation, obtaining the commitment value; it generates and signs a remote proof within the trusted execution environment, generates an execution commitment, and writes it into the operator sequence identifier, field whitelist summary, and data residency domain label; it encapsulates the irreversible feature data fingerprint, commitment value, remote proof, and execution commitment to form the terminal node bidding package and submits it to the control plane. The control plane completes token and session binding and time window verification, verifies that the whitelist of verification fields and the data resident domain label meet the set constraints, and verifies that the commitment value is consistent with the irreversible feature data fingerprint. After passing the verification, the bid is included as a member of the bid package set, providing input for subsequent stage placement and joint orchestration and solution of cross-domain data paths.

[0049] Preferably, the remote proof records the platform measurement information and the trusted execution environment measurement information, signs them with the device private key and binds them to the session root, and the execution commitment records the mirror fingerprint and policy fingerprint and binds them to the session root. The control plane performs digital signature verification, certificate chain verification and time window verification on the remote proof and execution commitment and then includes them in the bid package set.

[0050] This invention establishes a "proof-first" admission mechanism, requiring terminal nodes, edge nodes, and cloud nodes to submit remote proofs and execution commitments before bidding in parallel. The control plane only includes the corresponding bids in the bid package set after the formal and cryptographic verification is completed, and uses them as input for subsequent joint orchestration.

[0051] Remote authentication is used to prove the measurable trustworthiness of the runtime environment. Remote authentication records platform metric digests and trusted execution environment metric digests, generates a signature using the device's private key, and incorporates session identifiers and timestamps to complete session-level binding and time window constraints. The control plane uses this to perform certificate chain verification, signature verification, and time window verification, excluding submissions from non-current sessions, expired submissions, and forged submissions. The core computational expression for remote authentication is: Where sh dev For the device private key, h plat For platform metric summary, h tee For trusted execution environment metric digests, sid is the session identifier and t is the timestamp. Control plane verification of remote proofs includes: Verify(pk dev ,σ ra ,h plat ||h tee||sid||t)=1,t now ∈[t start ,t end ], where pk dev For the device public key, t now t represents the current time. start With t end This serves as the time window boundary. The design incorporates joint constraints on hardware, trusted execution environment, and session context during the bidding phase.

[0052] The execution commitment is used to pre-lock the software image and operation policy to be executed. The execution commitment records the image fingerprint and policy fingerprint, is signed with the device private key, and bound to a session identifier and timestamp. The policy fingerprint at least covers the operator sequence identifier, field whitelist digest, data residency domain label, and resource lease digest. The core calculation expression for the execution commitment is: Where h img For mirrored fingerprints, h policy This serves as the policy fingerprint. The control plane also performs certificate chain verification, signature verification, and time window verification on the execution commitment, and checks the consistency between the mirror fingerprint, policy fingerprint, and session identifier. After the remote proof and execution commitment pass verification, they, together with the commitment value of irreversible feature data and the verification results of the field whitelist set constraints, constitute the acceptable bid items, which are then aggregated into a bid package set.

[0053] In principle, remote proof binds hardware and trusted execution environment metrics to the conversation context, avoiding the reuse of old evidence across different sessions. Execution commitment locks the image and policy at the bidding time, preventing changes to the execution content after orchestration. These, along with session identifiers and time windows, enable the control plane to filter candidate paths based on trusted input without relying on post-run proofs, shortening the scheduling preparation link and reducing the frequency of subsequent retakes.

[0054] The corresponding effects are reflected in three aspects. First, the identity, environment, and policy are verified to be from the same source, eliminating the risk of granting access based solely on device identifiers and static keys. Second, time window verification and session identifier binding suppress replay and cross-domain forwarding. Third, policy fingerprinting pre-fixes the field whitelist, data residency domain label, and operator sequence, providing a comparable baseline for hop-by-hop whitelist checks of tokens in subsequent stages.

[0055] In this embodiment, a group of terminal nodes, a group of edge nodes, and a set of cloud nodes within the park enter the bidding process after receiving a one-time session token. Each terminal node calls the Trusted Execution Environment (TEE) to export the platform metric digest and the TEE metric digest, generates a remote proof according to the aforementioned signature expression, and exports a mirror fingerprint and a policy fingerprint within the same TEE, generating an execution commitment according to the aforementioned signature expression. The bidding message carries the certificate chain, device public key certificate, session identifier, and timestamp. The control plane performs certificate chain verification, signature verification, and time window verification on each bidding record simultaneously, and merges the entries submitted by the corresponding terminal nodes, edge nodes, and cloud nodes into a bid package set after passing the verification. This set is used for subsequent joint orchestration solving. If a node fails to provide a remote proof and execution commitment that are consistent with the session identifier and within the valid time window, it will be rejected from further decision-making. Through this process, the control plane completes the integrated hardware and software trust constraints during the bidding stage, ensuring that subsequent stage placement and cross-domain data path optimization are based on trusted input.

[0056] Preferably, the capability declaration in the edge node bid package explicitly states the ability to perform summation and aggregation on homomorphic encrypted features within the ciphertext domain and the ability to perform outlier suppression using the grouped mean-median method on the sketch feature digest, and explicitly states the execution queue strategy and resource occupancy status for each stage in the cross-domain data path.

[0057] In the ciphertext domain summation and aggregation, edge nodes only process the homomorphic encryption features generated by the terminal nodes and do not decrypt the ciphertext. Let the summable aggregation statistics uploaded by the terminal nodes be the plaintext vector u. i (Counting, binning frequency, low-order moments, etc.), let the homomorphic encryption function be E. pk (·), where pk is the public key and Z is the ciphertext. i =E pk (u i Edge nodes perform group product operations on the arriving ciphertext sets within the time window to obtain aggregated ciphertext. Where n is the number of samples within the window. If the intent constraint description authorizes the generation of a low-sensitivity plaintext digest in the trusted execution environment, then decryption u is performed in the trusted execution environment. sum =Dec sk (Z sum Z is passed directly upstream when not authorized, where sk is the private key. sum The edge node capability declaration records the supported addition depth, the noise budget range that can be accommodated, and the batch size, and maps these ranges to the end-to-end delay budget described by the intent constraints so that the control plane can determine the feasible region during joint orchestration.

[0058] Robust merging of sketch feature summaries employs the grouped mean-median method. Let y be the sketch features uploaded by the terminal node. i=Sφ(x i ), where S is the projection operator corresponding to the fixed projection matrix fingerprint derived from the session root, φ(x i The data is irreversible. Edge nodes divide the sketch features within the time window into m non-overlapping groups G1,…,G m Calculate the mean value of each group for each coordinate: And for {g j Perform median-wise merging on each coordinate to obtain a robust merged result: z mom =median{g1,…,g m}, edge nodes with z mom For reference, outlier determination will be performed, satisfying ||y i -Z mom ||2>δ's sketch feature is labeled as an outlier, where δ is the magnitude threshold derived from the intent constraint description. The capability declaration explicitly specifies the number of supported groups, the capacity of each group, and the output format of the outlier label, and binds it to the session root to ensure that the merging rules are consistent within the session.

[0059] The execution queue strategy for each stage in the cross-domain data path adopts a preemptive multi-level priority system with minimum computing power reservation. Edge nodes are assigned three priority categories: urgent, control, and normal. Urgent nodes are guaranteed a fixed minimum computing power share and preemptible time slices; within the same priority level, services are provided on a first-come, first-served basis according to the deadline. Edge nodes maintain a sliding estimate of queuing latency. Where q k Queuing delay for observations in the most recent K time windows. When the threshold derived from the intent constraint is exceeded, the edge node sends a request to the control plane to switch the backup plan and saves the intermediate state of the current stage locally for smooth migration. The capability declaration synchronously outputs the current resource occupancy status, the length of each priority queue, the sliding latency estimate, and the time window index as comparable indicators for bidding.

[0060] The synergistic principle behind these three capabilities is reflected in the following ways: encrypted field summation and aggregation ensure that the original statistics are not exposed at edge nodes; the group mean and median method suppresses merging offsets caused by a small number of abnormal uploads; and preemptive multi-level queuing and sliding delay estimation provide predictable queuing boundaries for the control plane. After the control plane performs token signature verification and session binding verification on the capability claims, it merges the capability claims, remote proofs, and execution commitments into an edge node bid package, which serves as a candidate entry in the bid package set for subsequent joint orchestration.

[0061] In this embodiment, the edge node receives uploads from both the camera terminal node and the vibration terminal node within the same session. The terminal nodes generate homomorphic encrypted features and sketch features from the irreversible feature data of the images and vibrations, respectively. The edge node accumulates the ciphertext sequence within a time window of length 32, and obtains the aggregated ciphertext Z according to the aforementioned product rule. sum And in accordance with the authorization policy, only Z sum The data is passed to the control plane, and based on the fixed projection matrix fingerprint, the 64 sketch features are divided into 8 groups. The mean of each group is calculated, and the median of each coordinate is taken to obtain z. mom Sketch features exceeding the amplitude threshold are marked as outliers. In the queuing strategy, urgent categories retain the minimum computing power share, while regular categories are paused and intermediate states are recorded when the load increases. Once the sliding latency estimate exceeds the threshold, the edge node sends a backup plan switchover request to the control plane. Ultimately, the edge node bid package includes the addition depth range, batch size, outlier ratio, queue length, and sliding latency estimate, and is submitted together with remote proof and execution commitment to meet the control plane's pre-requirements for compliance and programmability.

[0062] Preferably, the capability declaration in the cloud node bidding package explicitly states the constraint that decryption and reasoning are completed within a trusted execution environment and that the key does not leave the trusted execution environment, and explicitly states the constraint that the processing location and the range of result return are limited according to data residency requirements.

[0063] This invention addresses the capability declaration of cloud nodes in parallel bidding. The goal is to complete decryption and inference within a trusted execution environment, ensuring that the key does not leave the trusted execution environment. At the same time, it limits the processing location and result return range based on data residency requirements, and writes the above constraints into the cloud node bidding package as structured fields for the control plane to perform admission and subsequent joint orchestration.

[0064] The cloud node's trusted execution environment, acting as a trusted boundary, only allows processing of upstream input after loading an image and policy locked by an execution commitment. The cloud node capability declaration first outlines the controlled decryption principle and key boundaries: Let the input ciphertext be Z, and the trusted execution environment's internal private key be sk. tee Let m be the decrypted plaintext, and execute it within a trusted execution environment. in This indicates the decryption process performed within a trusted execution environment, sk tee It is stored only in a sealed storage environment within a trusted execution environment and does not appear in plaintext on terminal nodes, edge nodes, or the control plane. The capability statement also specifies the session binding policy for key generation and loading, meaning that decryption is only permitted after the session identifier, timestamp, mirror fingerprint, and policy fingerprint have been verified to match.

[0065] The cloud node capability declaration is followed by a formal expression of residency and location constraints. Let R be the set of allowed processing regions. allowLet the actual execution region of the cloud node be r. exec The constraint is r exec ∈R allow The capability declaration invokes the remote verification platform metric digest and the trusted execution environment metric digest before image loading, and writes the region identifier and session identifier into the local policy of the trusted execution environment to ensure that decryption and inference are performed within the region constraints. If the joint orchestration requires execution on a regional cloud node, the policy explicitly prohibits cross-region migration and proxy forwarding.

[0066] The cloud node capability declaration also specifies the limitations on the range of results returned and the set of fields. Let F be the set of fields that can be returned. out Let the baseline of the whitelist field be F. baseline Let R be the set of regions that are allowed to be returned. return , constraint is The above constraints are checked field-by-field by the policy executor in the trusted execution environment and enforced on the return channel. Unauthorized fields and geographic targets are directly blocked. To ensure auditability, the cloud node calculates a result summary and generates a result signature for the result and policy state in the trusted execution environment. Let the result summary be h. res Let the session identifier be sid and the timestamp be t, generate Where σ res The result is signed, and the control plane verifies whether the source and return range of the result are consistent with the capability statement after receiving it.

[0067] The cloud node capability statement also includes a controlled process for inference execution. During the loading phase, the trusted execution environment verifies the mirror fingerprint and policy fingerprint recorded in the execution commitment and, after comparing them with the trusted execution environment metric digest in the remote proof, initiates inference. During the inference phase, only fields within the field whitelist baseline are accessed, and regional tags are integrated into the metadata of intermediate data, prohibiting cross-region caching and persistence. The capability statement simultaneously provides the resource consumption and concurrency limits for the inference phase; these values ​​are used to evaluate the feasible domains of end-to-end latency budgets and cost or energy consumption budgets during federated orchestration.

[0068] The above principles bring three types of benefits. In terms of security, both decryption and signing are completed within the trusted execution environment, and the key never leaves the trusted execution environment, eliminating the risk of decrypted materials being leaked. In terms of compliance, geographic constraints are written into the local policy of the trusted execution environment before execution, and geographic labels are used for hop-by-hop checks during execution to ensure that both the processing location and the return location simultaneously meet the residency requirements. In terms of orchestration, field set restrictions and geographic set restrictions are publicly disclosed as deterministic set constraints, allowing the control plane to directly use them as hard constraints in joint orchestration, avoiding retrospective corrections after execution.

[0069] In this embodiment, the regional cloud node receives aggregated ciphertext from the campus edge node. The control plane issues session identifiers, timestamps, and one-time session tokens based on the parallel voting input results. Within the Trusted Execution Environment (TEE), the cloud node verifies the certificate chain of the remote proof, the platform metric digest, and the TEE metric digest; it also verifies the mirror fingerprint and policy fingerprint in the execution commitment. Once they match the session identifier, the model is loaded and the policy is activated. The TEE dictates the region set R. allow Verify the current execution region identifier, satisfying r exec ∈R allow Then, controlled decryption is performed to obtain plaintext m. Inference is then completed in local memory, and the inference output is obtained by filtering according to the field whitelist baseline to obtain the field set F. out ,verify and Post-calculation result summary h res And generate the result signature σ res The results and their signatures are then sent to the control plane via the return channel. The control plane performs verification based on the result signature, session identifier, and timestamp, and writes it to the session-level audit log. At the same time, it uses the region and field check results as a priori for the next joint orchestration, ensuring that subsequent stage placement and cross-domain data path solving are performed on trusted inputs and verifiable constraints.

[0070] Preferably, the control plane's verification of the bid package set includes verification of the validity period of the one-time session token, verification of the session root binding relationship, verification of the consistency of field names, verification of the consistency of field value ranges, verification of the correspondence between the commitment value and the irreversible transformation operator sequence identifier, and verification of the consistency between the data resident domain label and the execution node region.

[0071] This invention is used to perform admission verification on a set of bid packages in the control plane, ensuring that parallel bids enter joint orchestration under a unified session and unified constraints. The verification contents are as follows: one-time session token validity verification, session root binding relationship verification, field name consistency verification, field value range consistency verification, correspondence between commitment value and irreversible transformation operator sequence identifier verification, and data resident domain label and execution node region consistency verification.

[0072] One-time session token validity verification is completed based on digital signature verification and time window verification. Let the control plane public key be pk. ctrl The token digest is h tok The token signature is σ tok The current time is t now The time window is [t] start ,t end Control plane verification Verify(pk) ctrl ,σ tok ,h tok ) = 1, t now∈[ start ,t end ].

[0073] After passing the verification, the session root binding relationship will be checked. The session root identifier will be denoted as sid, and the session identifier carried in the bid packet will also be sid. j The control plane requires SID. j =sid, and for the bid package summary h bid Verify the message verification code generated based on the session root derived key to ensure that the bid belongs only to the current session.

[0074] Field name consistency checks are based on the whitelist baseline of fields derived from the intent constraint description. Let the field whitelist baseline be F. base The set of fields for the j-th bid declaration is F. j Control plane verification Reject any unregistered fields or name drift. Field value range consistency checks are based on the field constraint library. Let I be the allowed value range for field f. f The value of field f in the bid is v f Control plane field-by-field validation v f ∈I f And record the reasons for exceeding the boundaries for auditing and accountability.

[0075] The verification of the correspondence between the commitment value and the irreversible transformation operator sequence identifier is used to confirm the consistency between the source processing link and the session binding. The terminal node has generated irreversible feature data and calculated the commitment value on the end side; the formula for calculating the commitment value is given in the aforementioned expression. The control plane first checks whether the operator sequence identifier chain within the bid is consistent with the policy fingerprint, and then checks whether the binding relationship between the commitment value and the irreversible feature data fingerprint is consistent with the session root. It requires that the commitment value matches the session identifier and the operator sequence identifier matches the policy fingerprint. To avoid the control plane accessing plaintext features, the verification is completed using fingerprints and chained digests: let the operator sequence digest be h. φ Irreversible feature fingerprint is d φ The control plane verifies the h recorded in the policy fingerprint. φ "and the h recorded in the execution commitment" φ "Consistent, and the committed values ​​originate from the same d." φ A random factor is derived from the same session root. Data residency domain label and execution node region consistency verification is performed using region set constraints. Let R be the set of allowed processing regions. allow The execution node region is r exec Returns the set of regions as R return Control plane verification r exec ∈R allow , The system performs consistency checks on each hop's labels to prevent any discrepancies between the region label and the execution region at any stage. For bids that include cross-domain path proposals, the control plane checks the region label of each stage in the path against the target region of that stage, forming programmable evidence of region compliance.

[0076] The principle behind the aforementioned verification chain is as follows: tokens and session roots provide hard constraints on time and identity; field names and value ranges provide hard constraints on data patterns; commitment values ​​and operator sequence identifiers provide verifiable bindings to the source processing chain; and geographic consistency provides hard constraints on processing location and return location. These four types of constraints are independent yet complementary, enabling the control plane to complete trusted access without accessing sensitive plaintext. The corresponding effects are: blocking expired tokens and cross-session replays; blocking field drift and unauthorized data injection; blocking end-side outputs forged with incorrect operator sequences; blocking out-of-bounds geographic execution and returns; and ultimately only aggregating bids that satisfy all constraints into a bid package set for direct calculation in subsequent joint orchestration.

[0077] Example: In a session within a smart park, the control plane receives parallel bids from three types of nodes. The control plane first verifies the token signature and time window for each bid, eliminating two expired bids. Then, it verifies the session root binding, eliminating one bid with an inconsistent session identifier. It performs set inclusion verification on field name consistency, finding one bid with an added, unregistered field and rejecting it. It checks the value range field by field, marking two data points outside the input threshold and rejecting them. It verifies the correspondence between the commitment value and the operator sequence identifier, identifying one operator sequence identifier that is inconsistent with the policy fingerprint and rejecting it. It checks regional consistency, rejecting one bid whose execution region is not within the allowed set. The remaining bids form a bid package set and enter joint orchestration. The control plane writes all rejection reasons and corresponding verification steps into the session-level audit log, providing a chain of evidence for subsequent compliance review.

[0078] Under the constraints of intent description, the set of bid packages is jointly orchestrated and solved to determine the phase placement, cross-domain data paths and minimum data leakage rules, generate the minimum feasible plan and distribute phase tokens by the control plane.

[0079] This invention performs joint orchestration and solution on the set of bid packages in the control plane, outputting a minimum feasible plan and issuing stage tokens. The inputs include an intent constraint description, the set of bid packages, a field whitelist baseline, data residency domain labels, and a prediction metric vector for each bid. The control plane first constructs candidate nodes and candidate links for the end node stage, edge node stage, and cloud node stage into an assembly diagram. Each candidate link carries a subset of the field whitelist baseline and the corresponding data residency domain labels.

[0080] To ensure the orchestration is computable and verifiable, decision variables and a unified objective are introduced. Let the stage placement matrix be x, representing the type of node each stage is placed in; let the cross-domain data traffic be f, representing the data carried on the candidate link; let the parameter selection be Θ, representing the values ​​of execution parameters such as homomorphic encryption and sketch digest; and let the end-to-end delay estimate be... Let the comprehensive cost estimate be Let the operational risk estimate be ρ(x,f,Θ), and the accuracy availability estimate be... Let the weight vector be {w} l ,w c ,w r ,w a This originates from the intention constraint description. Control plane solution: The end-to-end latency estimate is obtained by summing the computation latency of each stage and the transmission latency of each link; the overall cost estimate is obtained by summing the computation cost and the transmission cost; the operational risk estimate is given by node reputation and evidence integrity; and the accuracy and availability estimate is given by parameters such as the homomorphic encryption noise budget and the sketch dimension. Constraints include: each stage can only be placed once ∑ j x j,s =1; the hop-by-hop field set must be a subset of the field whitelist baseline; the hop-by-hop region must belong to the allowed region set; the trusted execution level must meet the intent constraint description; end-to-end latency and cost must not exceed the budget.

[0081] Within the feasible domain that satisfies the constraints, the control plane generates minimum data leakage rules. For a defined hop-by-hop path on the assembly drawing, the control plane calculates the minimum set of fields required to complete the task for each hop, and intersects it with the field whitelist baseline to obtain the allowed field set for that hop. Simultaneously, it inherits and validates the data residency domain labels for that hop. This forms a list of hop-by-hop field sets and hop-by-hop region labels, which serve as components of the minimum data leakage rules.

[0082] By integrating decision variables and minimum data leakage rules, the control plane compiles a minimum feasible plan. The minimum feasible plan includes a phase sequence, a hop-by-hop allowed field set, hop-by-hop region labels, execution positions for irreversible transformation operator sequences, parameter values ​​for homomorphic encryption and sketch digests, and priority and preemption strategies. Subsequently, a phase token is derived for each phase, containing the phase identifier, validity period, allowed field set, region label, trusted execution environment metric requirements, mirror fingerprint and policy fingerprint guidance, and binding information to the session root. The phase token is hardened with a digital signature and message verification code and distributed to the corresponding execution nodes via a secure channel.

[0083] The effectiveness of this orchestration principle is reflected in three aspects. First, objectives and constraints are unified in their expression, connecting bidding evidence and operational predictions, enabling assembly selection and safety compliance to be completed within the same optimization framework. Second, the minimum data leakage rule is derived through static assignment of required fields hop by hop, ensuring that cross-domain field leakage is minimized only while meeting availability requirements. Third, stage tokens transform key constraints of the plan into executable instructions, which can be verified before and after execution using tokens and evidence, forming a consistent closed loop from orchestration to execution.

[0084] Example: In a joint video and vibration task within a campus, the control plane receives several bid packages from end nodes, edge nodes, and cloud nodes. The intent constraint description requires that image-related fields be de-identified in the local domain and limits end-to-end latency and trusted execution level. The control plane places the end node stage at the camera terminal, the edge node stage at the campus edge, and the cloud node stage in the regional cloud. For the hop from an end node to an edge node, the allowed field set is the minimum set, including image embeddings and timestamps; for the hop from an edge node to a cloud node, the allowed field set is aggregated features or aggregated ciphertext. The control plane solves with a unified objective, obtaining the optimal solution that balances end-to-end latency, cost, risk, and accuracy, generating a minimum feasible plan containing hop-by-hop field sets and regional labels, and generating three generation stage tokens. Before execution, each node verifies its execution using the token; after execution, the control plane checks the execution proof against the fields and regional constraints in the token, achieving consistency verification between orchestration and execution.

[0085] Preferably, the joint orchestration solution is based on the assembly graph consisting of stage nodes and transmission edges to construct a multi-objective comprehensive evaluation, and selects the assembly solution under the constraints of privacy level, data residence domain, trusted execution level, end-to-end latency budget and cost budget, and generates stage placement and cross-domain data paths.

[0086] This invention abstracts the end node stage, edge node stage, and cloud node stage into stage nodes and transmission edges of an assembly diagram in the control plane. Based on the intent constraint description, it performs joint orchestration and solution on the bid package set, producing stage placement and cross-domain data paths. Each transmission edge of the assembly diagram is accompanied by a subset of whitelisted fields and a data-residence domain label. Stage nodes are accompanied by trusted execution levels and resource availability, used to simultaneously evaluate compliance and executability during the solution process.

[0087] Joint orchestration, centered on multi-objective comprehensive evaluation, retains the aforementioned notation and presents an integrated expression of the objective function and constraints. Let the stage placement matrix be x, representing the type of execution node to which each stage is placed; let the cross-domain data flow be f, representing the bearer on each transmission edge; let the parameter set be Θ, representing the selection of execution parameters such as homomorphic encryption and sketch digest; let the end-to-end delay estimate be... Let the comprehensive cost estimate be Let the operational risk estimate be ρ(x,f,Θ), and the accuracy availability estimate be... Let the weight vector be {w} l ,w c ,w r ,w a The control plane is defined by the intention constraints. In the objective function, the end-to-end delay is obtained by summing the stage computation delay and the link transmission delay; the overall cost is obtained by summing the computation cost and the transmission cost; the operational risk is combined with node reputation and evidence integrity metrics; and the accuracy and availability are estimated based on parameters such as homomorphic encryption noise budget and sketch dimension. Hard constraints are divided into placement constraints, geographical constraints, trust constraints, and budget constraints. The placement constraint allows each stage to be placed only once, in the form of ∑ j x j,s =1. Geographic constraints require that the execution geographic region r for each stage is [missing information]. s Belonging to the allowed set R allow And require the hop-by-hop field set f u→v Baseline F for field whitelist base A subset of r, of the form r s ∈R allow and Trusted constraint requirements phase trusted execution level q s Not lower than the required level Q min , in the form of q s ≥Q min Budget constraints require that end-to-end latency and overall cost not exceed the budget, in the form of... and Where L is the time delay budget and B is the cost or energy consumption budget.

[0088] To obtain an executable solution, the control plane first forms a feasible region through constraint pruning, then performs Pareto screening on the feasible solutions, and finally selects from the Pareto set using a weighted scalar objective. The resulting stage placement matrix and cross-domain data traffic correspond to one or more hop-by-hop paths on the graph. The control plane calculates the minimum set of fields required for the task hop-by-hop for each path, intersects it with the field whitelist baseline to obtain the allowed field set, and inherits and verifies the data residency domain label to form the minimum data leakage rule. The minimum feasible plan is composed of stage placement, cross-domain data paths, and minimum data leakage rules, and stage tokens are issued to each stage accordingly. The token records the stage identifier, validity period, allowed field set, regional label, trusted execution environment metric requirements, mirror fingerprint, and policy fingerprint, guiding pre-execution verification and hop-by-hop release during execution.

[0089] The effectiveness of this orchestration principle is reflected in three aspects. First, goals and constraints are characterized within the same mathematical framework, allowing for a unified trade-off between latency, cost, risk, and accuracy within the computable space, avoiding fragmented processes where compliance comes before or after performance. Second, regions and fields are defined as sets for each hop, and the minimum data leakage rule is calculated rather than empirically specified, reducing redundancy in cross-domain outgoings. Third, stage tokens convert the orchestration results into executable instructions, ensuring constraint consistency from solution to execution, and enabling rapid verification and switching at runtime based on tokens and evidence.

[0090] In this embodiment, the industrial park's video phase, vibration phase, and fusion phase constitute three pipeline segments. The control plane constructs an assembly diagram based on the set of bid packages: video phase candidates are placed at the camera terminal and the park edge, vibration phase candidates are placed at the sensor terminal and the park edge, and fusion phase candidates are placed at the park edge and the regional cloud. The intent constraint description requires that the image-related fields reside within the park region for de-identification, the end-to-end latency budget is a predetermined threshold, and the trusted execution level requires that the fusion phase run within a trusted execution environment. The control plane first trims out candidates that meet the region and trusted level requirements, and then filters them using a multi-objective comprehensive evaluation to obtain an assembly solution where the video phase is placed at the camera terminal, the vibration phase is placed at the sensor terminal, and the fusion phase is placed at the park edge. For the "video terminal to park edge" hop, the allowed field set contains only image embedding and time stamps; for the "vibration terminal to park edge" hop, the allowed field set contains only aggregation statistics. Based on this, the control plane generates a minimum feasible plan and issues three phase tokens. During execution, the hop-by-hop field and region are forcibly verified by the token, completing the integrated implementation from joint orchestration to controlled execution.

[0091] Preferably, the minimum data leakage rule is written into the minimum feasible plan with a hop-by-hop field whitelist and a hop-by-hop data residence domain label, and a phase token is written synchronously. The execution node only allows data that is included in the field whitelist and whose label matches.

[0092] This invention solidifies the minimum data leakage rules into the minimum feasible plan in the control plane and synchronously writes them into the stage token. Execution nodes then use this to implement hop-by-hop release and interception at the data exit. The core idea is to establish dual constraints of a minimum set of fields and a unique label at the region level for each hop, calculating and then enforcing them to ensure that only the data necessary to complete the function of that hop and the legitimate region identifier appear in the link.

[0093] The minimum data leakage rule is generated using set operations. Let the baseline of the field whitelist be F. base Let R be the set of fields required to complete the jump function. u→v Let F be the set of fields that the jump allows to be sent out. u→v Then F u→v =R u→v ∩F baseWhere u→v represents a directed jump from the previous stage to the next stage, R u→v Automatic resolution of task dependencies during joint orchestration and solving, F base This is derived from the intent constraint description. Geographic constraints are represented by data residency domain labels; let the geographic label for this hop be L. u→v This tag corresponds one-to-one with the minimum viable plan and the phase token.

[0094] To avoid ambiguous interpretations of the rules during execution, the phase token carries a hash digest of both the field set and the geographic label. Let the encoding function be `encode(·)`, the cryptographic hash function be `H`, and the token digest be `h`. tok Suppose that the execution node calculates a summary, h, for the set of fields to be sent out and the geographic tag using the same encoding. out Then h must be met before release. out =H(encode(F) u→v ||L u→v ))=h tok , where h tok Generated by the control plane and issued along with the stage token, || represents concatenation. This design transforms "what should be sent out" into a verifiable, fixed commitment; during execution, only a digest comparison is needed to verify the consistency of the rule ontology. The release logic of the execution node consists of three steps: entry verification, field filtering, and region verification. Entry verification checks the stage token signature and validity period and confirms session binding. Field filtering checks each field at the data exit to see if it belongs to F. u→v Records that do not belong to the specified region are discarded. The region verification process consists of two layers: first, checking whether the region tag carried by each record is equal to L. u→v Secondly, it checks whether the execution node's region is included in the allowed set for that label. All checks are handled with a failure-first policy; if any check fails, it is immediately blocked and the audit entry is logged.

[0095] The mechanism's effectiveness is reflected in three aspects. First, the field set is given by the intersection of task dependencies and the whitelist, ensuring that only fields required for the function are passed without propagating redundant sensitive information. Second, the regional label uses a unique value for each hop to define the residency boundary, preventing cross-domain migration. Third, the hash digest solidifies the rules into an immutable commitment, allowing execution nodes to complete consistency checks without parsing the rule details, reducing implementation complexity and improving auditability.

[0096] In this embodiment, the one-hop functionality from the camera terminal to the edge of the park relies on image embedding and timestamps, and the whitelist baseline prevents the original image from leaving the domain. The control plane calculates F. cam→edge ={Portrait Embedding, Timestamp}, Location Tag L can→edge =Park A. The one-hop from the park edge to the regional cloud only requires aggregating features to calculate F. edge→cloud={aggregate features}, geographic label L edge→cloud =Region 1. The above two sets of field sets and regional labels are written into the minimum feasible plan, and a summary is generated in each of the two stage tokens. During execution, after the camera terminal completes the entry verification, it only allows the entry of the human image embedding and timestamp, and each record has the Park A label. The exit summary is sent out after it is equal to the token summary. After the park edge completes the aggregation, it only allows the aggregation features with the Region 1 label. If any field is found to be outside the allowed set or the label does not match, it is immediately discarded and recorded for audit. The control plane performs random checks based on the audit entries and stage token information to achieve closed-loop consistency from orchestration rules to execution release.

[0097] Each stage is executed based on the stage token, outputs result data and generates an execution certificate. The control plane verifies the execution certificate and switches the backup plan or maintains the current plan based on the verification results and operation monitoring data. The result data and execution certificate are registered in the session-level audit log.

[0098] This invention is used to translate a minimum feasible plan into a verifiable execution process. Upon receiving a stage token, each stage first verifies the token signature, performs time window verification, and binds it to the session. Then, it performs calculations according to the allowed field set and data residency domain label in the stage token, generating result data and simultaneously generating a stage-level execution certificate, which is then submitted to the control plane. The control plane performs cryptographic and semantic consistency verification on the execution certificate and, based on operational monitoring data and preset thresholds, makes a decision to "maintain the current plan" or "switch to the backup plan." Subsequently, the result data and execution certificate are registered in the session-level audit log, achieving closed-loop traceability from orchestration to execution.

[0099] The phase-level execution verification record documents the results of the check on operational elements and constraints for this phase. Let the phase execution summary be h. stage It includes mirror fingerprint, policy fingerprint, operator sequence identifier, actual delay, actual energy consumption, hop-by-hop field whitelist verification result, hop-by-hop data resident domain label verification result, and stage input / output fingerprint. Let the stage proof signature be σ. stage Let the device private key be sk node Let the session identifier be sid and the time stamp be t, then the present invention adopts in This indicates a digital signature completed by the execution node within the trusted boundary, with || representing concatenation. If the stage takes place within a trusted execution environment, the signing key resides only in sealed storage within that environment. The meaning of the result signature already provided by the cloud node is consistent with the aforementioned expression and will not be repeated.

[0100] After receiving the phase-level execution proof, the control plane first verifies the signature's correctness based on the node's public key and checks the session identifier and time window. Next, it performs a consistency comparison between the "field whitelist verification result" and the "data residency domain label verification result," requiring complete consistency with the allowed field set and regional label recorded in the phase token. Finally, it verifies that the mirror fingerprint and policy fingerprint should be consistent with the execution commitment submitted during the bidding phase. If the signature verification and all three consistency checks pass, the verification flag v = 1; otherwise, v = 0. Operational monitoring data is used to determine whether a plan switch is needed. Let the observed end-to-end latency be l. obs Let the predicted end-to-end delay given in the tender be... Let the overall cost of observation be c. obs Let the predicted total cost be... Define delay drift and cost drift Let w be the value of a violation of the whitelist (w=1 if the condition is met, w=0 otherwise), let g be the value of regional inconsistency (g=1 if the condition is met, g=0 otherwise), and let τ be the uniform drift threshold. The control plane switching decision rule is switch=1(max(δ)). l ,δ c )>τ∨w=1∨g=1∨v=0), where 1(·) is an indicator function. When a switch is determined, the next plan is selected from the backup plan pool in a preset order, the corresponding stage token is issued, and the switch reason and trigger time are recorded; when a maintenance is determined, the current stage token is used to continue execution.

[0101] Session-level audit logs are designed for traceability and evidence collection. The control plane generates audit entries for each phase, each entry containing at least a session identifier, plan identifier, phase identifier, phase execution summary, phase proof signature, signature verification result, whitelist verification result, geographic tag verification result, latency drift, cost drift, switchover decision, and time stamp. To prevent tampering, the control plane links the summaries of adjacent entries, forming an unalterable chain of records. The root summary of the record chain and the session end marker are archived simultaneously.

[0102] The aforementioned mechanism has clear application principles and effects in a multi-level, multi-domain architecture of edge-cloud. First, the stage token brings the "allowed field set, regional labels, and trust measurement requirements" from the minimum feasible plan to the execution entry point. Execution nodes can only proceed to computation after completing token verification at the entry point, preventing unauthorized execution. Second, the stage-level execution proof solidifies the "operational elements and constraint verification results" into cryptographically verifiable objects, enabling the control plane to complete validity judgments without obtaining sensitive plaintext. Third, the switching rules use a unified drift threshold and compliance signals as triggering conditions, ensuring that both "performance anomalies" and "compliance anomalies" can trigger backup plans immediately, reducing the probability of task interruption, and forming end-to-end traceable evidence through session-level audit logs.

[0103] In this embodiment, the park video stage, park edge fusion stage, and regional cloud inference stage are executed sequentially. The video stage, based on the stage token, outputs only the human image embedding and timestamp, writes a park location tag, calculates the stage execution summary, generates a stage proof signature, and sends it to the control plane. The fusion stage aggregates features from the inputs of the video and vibration stages, generates a stage-level execution proof, and sends it. The cloud inference stage performs decryption and inference within a trusted execution environment, generates a result summary and result signature, and sends it. The control plane performs signature verification and consistency checks on each of the three stages, and calculates latency drift and cost drift in real time. When the latency drift of the fusion stage exceeds a preset threshold or a field exceeds its authority, the control plane immediately switches to the backup plan's "fusion is executed on another park edge node" scheme and issues a new stage token; if all checks pass and the drift is within the threshold, the current plan is maintained. After the session ends, the control plane writes the three result data, all stage-level execution proofs, and the switching decision into the session-level audit log in chronological order, forming a top-down consistent evidence chain, providing a basis for subsequent compliance review and performance review.

[0104] Preferably, the stage token contains the stage identifier, validity period, set of fields allowed to be processed, data residency domain label, trusted execution environment metric fingerprint, irreversible transformation operator sequence identifier, and data path identifier. Before stage execution, the execution node completes signature verification and session root verification.

[0105] This invention implements the minimum feasible plan as a enforceable phase token mechanism. The phase token carries both constraints and verification information. Before the start of a phase, the execution node only needs to complete local self-checks and admission based on the phase token, without requesting sensitive plaintext or external interpretation, thereby ensuring that end nodes, edge nodes, and cloud nodes operate collaboratively under the same constraints.

[0106] The payload of the stage token consists of seven fields: stage identifier, validity period, set of allowed fields, data residency domain label, trusted execution environment metric fingerprint, irreversible transformation operator sequence identifier, and data path identifier. The set of allowed fields is based on the result of the minimum data leakage rule calculation. The data residency domain label limits the executable and returnable regions for this stage. The trusted execution environment metric fingerprint is a hash of the runtime environment metric. The irreversible transformation operator sequence identifier is used to perform consistency comparisons between the de-identification and feature compression links on the peer side or edge side before and after execution. The data path identifier is used to identify predecessors and successors in multi-segment pipelines.

[0107] To achieve non-repudiable token verification, the control plane signs and binds the phase token body to the session. Let the token body be TB, and the token digest be h. tok =H(TB), let the control plane private key be sk ctrlLet the session root derived key be k. sess Control plane generation Where H(·) is the cryptographic hash function, For digital signature operations, This is a message verification code derived from the session root key.

[0108] Before the phase begins, the execution node completes two verifications: first, it verifies the signature (Verify(pk)). ctrl , σ tok h tok ) = 1, where pk ctrl To control the plane public key; secondly, to recalculate the local message verification code and match it with m tok If the comparison is successful, session root verification and anti-replay are completed. Token constraints are concretized into three types of decidable rules at the execution entry point. First, field permission rules: let F be the set of fields to be sent at the exit point in this stage. out Let F be the set of allowed tokens. allow ,Require Secondly, the regional consistency rule, assuming the regional label carried by the record is L. rec Let the geographic tag specified in the token be L. allow Requires L rec =L allow Simultaneously, the region where the execution node is located belongs to the allowed set for that label. Thirdly, the environment and algorithm consistency rule: let h be the metric for the trusted execution environment of the local machine. tee Let h be the metric required for the token request. req h is required tee =h req Suppose the digest of the sequence of the local irreversible transformation operators is: Let the digest of the token record be Require All three types of rules are executed with a failure-first strategy; if any rule is not met, the process will be rejected from entering the stage calculation and an audit entry will be recorded.

[0109] In principle, the stage token reduces the abstract plan of "how it should be executed" to a set relationship and hash comparison that can be "determined locally": the field set and the regional label form a static boundary through set inclusion and equality relationships; the trusted execution environment metric fingerprint and the irreversible transformation operator sequence identifier form the algorithm and environment boundary through hash consistency; the signature and message verification code strongly bind the stage token to the session root, eliminating cross-session reuse and mid-course tampering. The execution node does not need to connect externally to complete the admission determination at the entry point, and the control plane only needs to perform execution proof verification on the result. The two combine to form an end-to-end verifiable closed loop.

[0110] The corresponding effects are reflected in three aspects. In terms of security, the key is only used for signing and message verification codes; sensitive plaintext does not appear in the token; and the environment and algorithm are verified through metric and digest comparisons to ensure it has not been replaced. In terms of compliance, hop-by-hop field sets and data residency domain labels are enforced at the token level, blocking the outgoing of unauthorized fields and out-of-bounds regions. In terms of operability, data path identifiers ensure a traceable causal chain between stages during runtime, allowing for the identification of specific hops and rules in case of drift.

[0111] Example: In the three-stage pipeline of "camera terminal → campus edge → regional cloud", the control plane issues stage tokens to the camera terminal, specifying the stage identifier as video stage, the validity period as from the current time to a specified time, the allowed fields set as image embedding and timestamp, the data residence domain label as campus A, the trusted execution environment metric fingerprint as a specified hash, the irreversible transformation operator sequence identifier as the edge-side de-identified link digest, and the data path identifier as "accessing the campus edge fusion stage after the video stage". Before starting, the camera terminal verifies the consistency between the signature and the message verification code, reads the allowed set and regional label from the token, and only allows image embedding and timestamp to pass after execution. It labels each record with the campus A label and compares the local trusted execution environment metric and irreversible transformation operator sequence digest with the token before sending it out. The campus edge receives the corresponding stage token, verifies its own region and label to be consistent, and then performs aggregation. The regional cloud runs inference in the trusted execution environment after verifying the consistency of the metric fingerprint. All three stages use the token as the entry constraint. At the end of the session, the control plane can connect the execution proofs and results of each stage according to the data path identifier to form a complete session-level audit record.

[0112] Preferably, the control plane performs the verification as a prerequisite for registering the result data into the session-level audit log, and selects a backup plan in a preset order and replaces the stage token and records the switchover log when latency drift, field overriding, or data inconsistency is detected.

[0113] This invention specifies the access and switching mechanism for result data in the control plane. After each stage completes the calculation, it generates an execution certificate and sends it up along with the result data. The control plane first verifies the execution certificate, and only registers it in the session-level audit record if the verification is successful; otherwise, it refuses to register and enters the switching process.

[0114] Execution proof verification includes signature verification, session consistency verification, and constraint consistency verification. Let the phase execution digest be h. stage It includes mirror fingerprint, policy fingerprint, operator sequence identifier, actual latency, actual energy consumption, field whitelist verification result, data residency domain label verification result, and input / output fingerprint; let the session identifier be sid, the timestamp be t, and the node public key be... The signature of the phase proof is σ stage Control plane calculation Where 1(·) is the indicator function, and || represents concatenation. If the field whitelist verification result and the data residency domain label verification result are not equal to the compliance mark, or the mirror fingerprint and policy fingerprint are different from the recorded values ​​in the execution commitment, then v is set to 0. Only when v=1, the result data and execution proof are written to the session-level audit record, and a record chain digest is generated for subsequent traceability. The switching decision combines performance drift and compliance signals. Let the observation end-to-end latency be l. obs The predicted end-to-end latency is The overall cost of observation is The predicted total cost is Delay drift is Cost drift Let ω be the field overriding indicator, set to 0 for compliance and 1 for violation; let g be the data residency inconsistency indicator, set to 0 for compliance and 1 for violation; and let τ be the uniform drift threshold. The control plane calculates switch = 1(max(δ)). l ,δ c )>τ∨ω=1∨g=1∨v=0), when switch=1, enter the backup plan selection and token replacement.

[0115] Backup plans are selected deterministically based on a preset order and plan metadata. The device backup plan pool is... Each plan p records a risk assessment value r. p Predicting end-to-end delay Forecast comprehensive cost Control plane selection is lexicographically ordered. First, compare the risk assessment values. If they are equal, then compare the predicted end-to-end delays. If they are still equal, then compare the predicted overall costs. Determine p. * A new stage token bound to the session root is then generated and atomically replaces the old token, which is synchronously distributed to the corresponding execution nodes, rendering the old token immediately invalid. The control plane simultaneously writes a switchover log, which includes at least the session identifier, old plan identifier, new plan identifier, trigger type, trigger value, replacement time, list of involved stages, and the fingerprint of the new token, for post-event auditing.

[0116] The principle behind this mechanism is to use "proof first" as a necessary condition for result registration, "unified criteria" as the trigger condition for plan switching, and "deterministic order" as the election rule for backup plans, thereby incorporating trusted execution, compliance constraints, and service continuity into the same control loop. The corresponding effects are: results without proof are not recorded, avoiding audit contamination; in the event of performance drift or compliance violations, a switch to a verified backup path can be made immediately, shortening recovery time; and all critical actions are chain-recorded, facilitating traceability and accountability.

[0117] In this embodiment, the park edge fusion phase and the regional cloud inference phase run within the same session. Within a single window, the control plane receives two execution proofs and result data. The whitelist verification of fields on the video and vibration sides, as well as the data residency domain label verification, both equal the compliance mark, signature verification passes, and the result is registered. Subsequently, the latency drift of the fusion phase is detected to be 0.28, exceeding the set threshold of 0.2, thus establishing a switching criterion. The control plane selects candidate schemes with lower risk assessment values ​​and shorter predicted end-to-end latency from the backup plan pool in lexicographical order, atomically replaces the fusion phase token, and records the switching log. In subsequent windows, the new fusion phase execution proof passes verification, results are continuously registered, and session-level audit records form a complete chain of evidence, supporting compliance review and performance review.

[0118] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for multi-level, multi-domain access control between edge and cloud, characterized in that, Includes the following steps: Generate intent constraint descriptions and establish session roots and one-time session tokens based on service levels and compliance terms; Terminal nodes, edge nodes, and cloud nodes submit bids in parallel based on intent constraint descriptions. The terminal nodes perform irreversible feature extraction on the original measurement data and combine it with remote proof and execution commitment to form a terminal node bid package. The edge node bid package and cloud node bid package contain capability statements and remote proof and execution commitment. After control plane verification, a set of bid packages is formed. Under the constraints of intent description, the set of bid packages is jointly orchestrated and solved to determine the phase placement, cross-domain data paths and minimum data leakage rules, generate the minimum feasible plan and distribute phase tokens by the control plane. Each stage is executed based on the stage token, outputs result data and generates an execution certificate. The control plane verifies the execution certificate and switches the backup plan or maintains the current plan based on the verification results and operation monitoring data. The result data and execution certificate are registered in the session-level audit log.

2. The method according to claim 1, characterized in that, The terminal node performs de-identification mapping and feature compression on the original measurement data according to the irreversible transformation operator sequence to generate irreversible feature data, and generates commitment values ​​with random factors derived from the session root. The commitment values, along with the irreversible transformation operator sequence identifier and remote proof and execution commitment, are bound together as the data payload and evidence set of the terminal node's bid package.

3. The method according to claim 1, characterized in that, The remote proof records platform measurement information and trusted execution environment measurement information, is signed with the device private key and bound to the session root, and the execution commitment records the mirror fingerprint and policy fingerprint and is bound to the session root. The control plane performs digital signature verification, certificate chain verification and time window verification on the remote proof and execution commitment and then includes them in the bid package set.

4. The method according to claim 1, characterized in that, The capability declaration in the edge node bidding package explicitly states the ability to perform summation and aggregation on homomorphic encrypted features within the ciphertext domain and the ability to perform outlier suppression using the group mean-median method on the sketch feature digest. It also specifies the execution queue strategy and resource occupancy status for each stage in the cross-domain data path.

5. The method according to claim 1, characterized in that, The capability declaration in the cloud node bidding package explicitly states the constraint that decryption and reasoning are completed within a trusted execution environment and that the key does not leave the trusted execution environment, and also explicitly states the constraint that the processing location and the range of results returned are limited according to data residency requirements.

6. The method according to claim 1, characterized in that, The control plane's verification of the bid package set includes verification of the validity period of the one-time session token, verification of the session root binding relationship, verification of the consistency of field names, verification of the consistency of field value ranges, verification of the correspondence between the commitment value and the irreversible transformation operator sequence identifier, and verification of the consistency between the data residency domain label and the execution node region.

7. The method according to claim 1, characterized in that, The joint orchestration solution is based on the assembly graph consisting of stage nodes and transmission edges to construct a multi-objective comprehensive evaluation. Under the constraints of privacy level, data residence domain, trusted execution level, end-to-end latency budget, and cost budget, the assembly solution is selected and the stage placement and cross-domain data path are generated.

8. The method according to claim 1, characterized in that, The minimum data leakage rule is written into the minimum feasible plan with a hop-by-hop field whitelist and a hop-by-hop data residence domain label, and the stage token is written synchronously. The execution node only allows data that is included in the field whitelist and whose label matches.

9. The method according to claim 1, characterized in that, The phase token specifies the phase identifier, validity period, set of fields allowed to be processed, data residency domain label, trusted execution environment metric fingerprint, irreversible transformation operator sequence identifier, and data path identifier. Before phase execution, the execution node completes signature verification and session root verification.

10. The method according to claim 1, characterized in that, The control plane performs the verification as a prerequisite for registering the result data into the session-level audit log, and selects a backup plan in a preset order and replaces the stage token and records the switchover log when latency drift, field unauthorization, or data residency inconsistency is detected.

Images