Blockchain-based trusted data space digital contract signing method

Abstract

This invention discloses a blockchain-based method for signing digital contracts in a trusted data space, specifically relating to the field of trusted data space security, to address the issue of synchronization between on-chain authorization and edge physical execution states. By responding to cross-domain data contract conclusion requests, the method triggers the extraction of hardware metric benchmarks from the underlying independent secure enclave of the target data flow node, generating a first physical metric vector. The method then merges the business authorization constraint rules with the first physical metric vector to generate a dynamic data access token. When an edge data routing node intercepts a controlled data call request, it collects the current second physical metric vector of the host machine and deconstructs the dynamic data access token based on this vector. During the deconstruction process, side-channel determination is performed based on memory access trajectory deviation and local power consumption distortion mode, outputting either a release action or a physical blocking action. Finally, a state confirmation certificate is generated and fed back to the blockchain node, triggering a data contract state machine update.

Description

Technical Field

[0001] This invention relates to the field of trusted data space security, and more specifically, to a blockchain-based method for signing digital contracts in trusted data spaces. Background Technology

[0002] Trusted data spaces are used to organize controlled data flows between different organizations. The basic approach typically involves data requesters and providers first using blockchain digital contracts to solidify business authorization constraints such as access scope, API calls, and maximum number of data entries. Then, edge data routing nodes on the target data flow node side intercept, verify, and allow data requests upon arrival. This architecture solves the problem of "who is authorized to access which data" in cross-organizational collaboration and allows blockchain nodes to record contract status, settlement status, and call results, making authorization relationships at the business level traceable.

[0003] However, in the actual operation of a trusted data space, on-chain contracts confirm the business authorization status, while the actual release of controlled data occurs in the edge hardware and host execution environment of the target data flow node. In other words, a digital contract can prove that a data call request is permitted according to business rules, but it cannot directly prove that at the moment the request is deconstructed, decrypted, and forwarded, the kernel-state code fragments of the target data flow node, the platform configuration register state, the local hardware acceleration unit, and the microarchitecture environment of the edge data routing node remain trustworthy. Existing processing methods typically handle these two layers separately: the on-chain side is responsible for authorization and state recording, while the edge side is responsible for token verification and message forwarding; once the physical execution state is not bound between the two, a temporal and spatial disconnect will occur between on-chain authorization and edge execution.

[0004] This gap may not be apparent in typical access control scenarios, but it poses a substantial risk in trusted data spaces. When a controlled data access request reaches an edge data routing node, the node often needs to deconstruct and verify the access token, business authorization constraints, or encrypted payload. This process triggers memory access, cache read / write operations, register operations, and hardware acceleration unit computations. If the target data flow node is subjected to microarchitectural side-channel attacks such as speculative execution sniffing, abnormal cache access probing, or differential power analysis at that instant, the attacker doesn't necessarily need to bypass on-chain contracts or forge business authorizations. Instead, they can infer sensitive information by utilizing the memory access trajectory, power consumption changes, or execution timing differences generated by the deconstruction and decryption of legitimate tokens. In this situation, traditional blockchain digital contracts will still consider the business authorization valid, and traditional edge gateways may continue to allow requests based on existing tokens, resulting in calls that are "legal in business terms but physically insecure" being executed.

[0005] Therefore, the key deficiency of existing technologies lies not in their inability to generate digital contracts, nor in their inability to execute conventional gateway interception, but in the lack of a continuous processing mechanism that spans contract signing, dynamic data access token generation, edge-site deconstruction, side-channel determination, and on-chain state updates. Specifically, existing methods do not implicitly bind the hardware metric benchmark of the target data flow node at the time of contract signing to the dynamic data access token, nor do they utilize the host machine's current second physical metric vector to participate in the token's mathematical deconstruction when a controlled data call request arrives. Furthermore, they do not simultaneously collect memory access trajectory deviation and local power distortion modulus during the mathematical deconstruction attempt to determine the microarchitecture execution state. Consequently, there is a lack of verifiable closed-loop relationships between on-chain authorization state, edge hardware state, and actual message processing actions, making it difficult to support the secure processing requirements of cross-institutional controlled data flow in a trusted data space.

[0006] To address the aforementioned problems, a technical solution is provided. Summary of the Invention

[0007] To overcome the aforementioned deficiencies in the prior art, embodiments of the present invention provide a blockchain-based trusted data space digital contract signing method. By responding to a cross-domain data contract conclusion request, the method triggers the extraction of hardware metric benchmarks from the underlying independent secure enclave of the target data flow node, generating a first physical metric vector. The method then merges the business authorization constraint rules with the first physical metric vector to generate a dynamic data access token. When an edge data routing node intercepts a controlled data call request, it collects the current second physical metric vector of the host machine and deconstructs the dynamic data access token based on the second physical metric vector. During the deconstruction process, side-channel determination is performed based on the memory access trajectory deviation and local power distortion mode, outputting either a release action or a physical blocking action. A state confirmation certificate is then generated and fed back to the blockchain node, triggering a data contract state machine update, thereby solving the problems mentioned in the background art.

[0008] To achieve the above objectives, the present invention provides the following technical solution: A blockchain-based trusted data space digital contract signing method is implemented between target data flow nodes, edge data routing nodes, and blockchain nodes, including: Step S1: In response to the received cross-domain data contract conclusion request, trigger the independent security enclave at the bottom layer of the target data transfer node, extract the hardware metric benchmark of the target data transfer node at the privilege level at the current moment. The hardware metric benchmark is formed by the platform configuration register value and kernel code fragment, and generate the first physical metric vector. Step S2: Parse the content of the data contract to be signed to obtain the business authorization constraint rules, perform nonlinear cryptographic fusion of the business authorization constraint rules and the first physical metric vector to generate a dynamic data access token, wherein the first physical metric vector is hidden as the ciphertext deconstruction mathematical correlation factor of the dynamic data access token; Step S3: When the edge data routing node intercepts the controlled data call request, it collects the current second physical metric vector of the host machine, and attempts to mathematically deconstruct the dynamic data access token based on the second physical metric vector. During the mathematical deconstruction attempt, it performs side channel determination and outputs the release action or physical blocking action. Step S4: Generate a state confirmation certificate based on the release action or physical blocking action, and feed the state confirmation certificate back to the blockchain node across the network to trigger the data contract state machine to perform settlement state update or blocking state update.

[0009] Furthermore, in step S1, the independent secure enclave reads kernel-mode code fragments and platform configuration register values ​​according to the critical control flow address space sequence. The critical control flow address space sequence includes kernel-mode code pages corresponding to decryption call entry, routing interception entry, controlled data address check entry, and register-level discard instruction entry. Each kernel-mode code page is arranged in ascending order of its starting physical address and is consistent with the critical control flow address space sequence saved by the edge data routing node, so that the first physical metric vector and the second physical metric vector correspond to the same kernel control flow address range at the same index position.

[0010] Furthermore, in step S1, the independent secure enclave concatenates the previous incremental hash value, the current kernel-mode code fragment, and the platform configuration register value at the same reading time in byte order to generate the current incremental hash value, and organizes the incremental hash values ​​obtained sequentially according to the critical control flow address space sequence into the first physical metric vector; when the critical control flow address space sequence changes, the updated critical control flow address space sequence is synchronously written to the independent secure enclave and the edge data routing node, and the first physical metric vector is re-collected.

[0011] Furthermore, in step S2, the business authorization constraint rules include the allowed interfaces, the maximum number of reads, and the controlled data call range; the digital contract signing entry performs standardized encoding of the business authorization constraint rules in the order of rule name, rule value, and rule boundary to form a business authorization constraint rule byte stream, and uses the byte length of the business authorization constraint rule byte stream as the derivation length boundary of the first physical metric vector feature segment, which is obtained by hash expansion and truncation of the first physical metric vector.

[0012] Furthermore, in step S2, the digital contract signing entry derives the first physical metric vector feature fragment from the first physical metric vector, performs an XOR operation on the business authorization constraint rule byte stream and the first physical metric vector feature fragment at the same byte position to obtain the obfuscated payload, and calls the token encapsulation key bound to the target data flow node identifier to perform symmetric encryption encapsulation with authentication label on the obfuscated payload to form a dynamic data access token. The dynamic data access token includes a ciphertext payload formed by the encapsulation count value, encryption result and authentication label.

[0013] Furthermore, in step S3, the edge data routing node reads the host platform configuration register value and the corresponding kernel-mode code segment according to the key control flow address space sequence to generate a second physical metric vector; performs integrity verification on the dynamic data access token, and after the integrity verification passes, derives a second physical metric vector feature segment based on the second physical metric vector, performs an XOR operation with the decrypted obfuscated payload to be restored to obtain the byte stream of the business authorization constraint rule to be parsed, and enters the business authorization constraint rule matching after the byte stream of the business authorization constraint rule to be parsed passes the encoding syntax verification.

[0014] Furthermore, in step S3, the local hardware acceleration unit performs dynamic data access token destructuring in a fragmented manner, with each fixed byte fragment corresponding to an observation window; within the observation window, the edge data routing node obtains the memory access address sequence through a hardware performance counter with an address sampling register, extracts the step size sequence of adjacent addresses, and calculates the memory access trajectory deviation based on the normal step size mean vector and normal step size covariance matrix in the safe baseline trajectory. The destructuring result of the fixed byte fragment is written into the temporary storage register inside the local hardware acceleration unit before the side channel determination is completed.

[0015] Furthermore, in step S3, the edge data routing node collects the internal transistor array logic switch switching rate and local operating voltage distribution data of the local hardware acceleration unit within the observation window, constructs a two-dimensional scalar power consumption field and calculates the local power consumption distortion mode, and uses the memory access trajectory deviation and the local power consumption distortion mode to form the current execution state feature points. It inputs the pre-deployed support vector data to describe the hypersphere model, and determines whether to continue deconstruction or output a physical blocking action based on the decision criteria output by the model. After completing the deconstruction, it outputs a release action or a physical blocking action based on the verification results of the business authorization constraint rules. The physical blocking action includes clearing the internal temporary storage register and writing a discard instruction to the data entry register.

[0016] Furthermore, in step S4, the edge data routing node reads the action type in the local action register according to the release action or physical blocking action, and establishes an action event relationship between the action type and the data contract content to be signed corresponding to the dynamic data access token; the status confirmation certificate includes the target data flow node identifier, the token digest of the dynamic data access token, the controlled data call request digest, the action event sequence number, the action type, the branch source, and the metric digest of the second physical metric vector. The branch source includes business authorization constraint rule verification passed, microarchitecture execution state out of bounds, and business authorization constraint rule verification failed. The controlled data call request digest is generated from the target data address, call interface, and number of requested reads in the controlled data call request.

[0017] Furthermore, in step S4, the edge data routing node sends the state confirmation certificate to the blockchain node through the cross-network feedback channel. The blockchain node obtains the public key of the edge data routing node device based on the target data flow node identifier and verifies the certificate signature in the state confirmation certificate. After the signature is verified, the blockchain node triggers the data contract state machine to enter the settlement update path, side channel blocking update path, or authorization blocking update path according to the action type and branch source, and updates the corresponding data contract state machine to the settlement state or blocking state.

[0018] The technical effects and advantages of this invention's blockchain-based trusted data space digital contract signing method are as follows: This invention introduces the hardware metric benchmark of the target data flow node into the dynamic data access token generation process, so that business authorization constraint rules no longer rely solely on on-chain contract state or plaintext token fields. When a controlled data call request arrives, the edge data routing node needs to complete a mathematical deconstruction attempt based on the host machine's current second physical metric vector. When the hardware state deviates, the deconstruction result cannot be stably restored to a resolvable business authorization constraint rule, thereby reducing the risk that legitimate authorizations will continue to be used by abnormal physical execution environments.

[0019] This invention simultaneously calculates the memory access trajectory deviation and local power distortion mode during the mathematical deconstruction of dynamic data access tokens, and uses a support vector data description hypersphere model for boundary determination. This processing method simultaneously covers memory access timing anomalies and local power distortion of hardware acceleration units, enabling edge data routing nodes to identify execution state deviations caused by microarchitecture side-channel attacks when performing token deconstruction and controlled data access determination.

[0020] This invention converts the release or physical blocking actions output by edge data routing nodes into state confirmation credentials and feeds them back to the blockchain node to trigger an update of the data contract state machine. As a result, the message processing actions already executed at the edge can correspond to the on-chain settlement or blocking states, reducing inconsistencies between edge execution results and data contract state records. Attached Figure Description

[0021] Figure 1 This is a flowchart illustrating the overall process of the blockchain-based trusted data space digital contract signing method of the present invention. Figure 2 This is a schematic diagram of the generation process of the first physical metric vector and the dynamic data access token of the present invention; Figure 3 This is a flowchart of the dynamic data access token mathematical deconstruction and side channel determination process of the present invention; Figure 4 This is a schematic diagram illustrating the process of generating state ownership certificates and updating the data contract state machine according to the present invention. Detailed Implementation

[0022] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0023] Please see Figure 1 - Figure 4 This invention provides a blockchain-based trusted data space digital contract signing method, comprising: This invention focuses on processing cross-domain data contract conclusion requests and controlled data access requests. At the digital contract signing entry point, during the conclusion phase, an independent security enclave is triggered based on the target data flow node identifier. The hardware metric benchmark of the target data flow node at the current moment is extracted to form a first physical metric vector. Subsequently, the content of the data contract to be signed is parsed to obtain business authorization constraint rules, which are converted into a business authorization constraint rule byte stream. This stream is then obfuscated and encrypted with feature fragments derived from the first physical metric vector to form a dynamic data access token. After the controlled data access request reaches the edge data routing node, the edge data routing node collects the current second physical metric vector of the host machine and performs a mathematical deconstruction attempt on the dynamic data access token based on the second physical metric vector. During the mathematical deconstruction attempt, the edge data routing node simultaneously collects memory access address sequences and hardware acceleration unit power consumption data, calculates memory access trajectory deviation and local power distortion mode, and inputs support vector data description hypersphere model to form a side-channel determination result. The edge data routing node outputs a release action or a physical blocking action based on the side channel determination result and the deconstructed service authorization constraint rules. The action result is encapsulated as a state confirmation certificate and fed back to the blockchain node, which drives the data contract state machine to complete the corresponding state update.

[0024] In the trusted data space, the cross-domain data contract conclusion request carries the target data flow node identifier and the content of the data contract to be signed. The digital contract signing entry point can then determine the physical execution node corresponding to this data contract. However, the business authorization constraint rules in the content of the data contract to be signed cannot directly enter the token generation process; the hardware measurement benchmark of the target data flow node at the time of contract conclusion must be obtained first. Therefore, step S1 handles the cross-domain data contract conclusion request response, independent secure enclave triggering, critical control flow address space reading, and the first physical measurement vector. Generate a task.

[0025] S101: Cross-domain data contract conclusion request reception and target data flow node locking.

[0026] The digital contract signing entry point takes the received cross-domain data contract conclusion request as the starting point for processing. It reads the target data flow node identifier and the content of the data contract to be signed from the cross-domain data contract conclusion request. The target data flow node identifier is used to determine the physical node that needs to perform hardware measurement. The content of the data contract to be signed is used to parse the business authorization constraint rules in step S2. Step S1 only maintains the correspondence between the two and does not disassemble the business authorization constraint statements in the content of the data contract to be signed.

[0027] When the target data transfer node identifier can uniquely correspond to a target data transfer node, and the content of the data contract to be signed can be consistently bound to the controlled data access scope managed by the target data transfer node, the digital contract signing entry generates a metric trigger request. The metric trigger request is an execution signal pointing to the underlying independent security enclave of the target data transfer node, carrying the association between the target data transfer node identifier and the content of the data contract to be signed. This association does not participate in subsequent incremental hash calculations; it is only used in step S2 to set the first physical metric vector. The index used for calls corresponding to business authorization constraint rules.

[0028] In one implementation, the data user initiates a cross-domain risk control scoring data call contract conclusion request through a trusted data space client. The request specifies that controlled data be provided by a target data transfer node located at a certain edge data gateway. Upon receiving the request, the digital contract signing entry locks the target data transfer node as a hardware measurement object, keeps the content of the data contract to be signed in a pending parsing state, and sends a measurement trigger request to the underlying independent secure flyby of the target data transfer node, causing the on-chain contract conclusion action to enter the physical execution environment confirmation stage of the target data transfer node.

[0029] S102: Determination of critical control flow address space sequence and establishment of privileged read path.

[0030] After receiving a measurement trigger request, the target data transfer node's underlying independent secure enclave takes over the hardware measurement processing. The independent secure enclave establishes a privileged access path within its isolated execution context. This path is used to read the target data transfer node's platform configuration registers and access the critical control flow address space preset by the operating system kernel. Once the privileged access path is bound to the platform configuration registers, the independent secure enclave enters the hardware measurement reading process.

[0031] The critical control flow address space sequence is determined when the target data transfer node is added to the trusted data space. The selected objects are the kernel-mode code pages corresponding to the decryption call entry point, routing interception entry point, controlled data address check entry point, and register-level discard instruction entry point. Each kernel-mode code page is written into the critical control flow address space sequence in ascending order of its starting physical address. This critical control flow address space sequence is simultaneously written to both the independent secure enclave and the edge data routing node. Step S1 generates the first physical metric vector. And step S3 generates the second physical metric vector At any given time, kernel-mode code segments and platform configuration register values ​​are read according to the same critical control flow address space sequence, so that the first physical metric vector... In With the second physical metric vector In The same index position corresponds to the same kernel control flow address range. When the target data transfer node experiences a version change in any kernel-mode code page in the critical control flow address space sequence due to kernel security patches, decryption program updates, or routing interception program updates, the target data transfer node re-executes the critical control flow address space sequence determination process when adding the trusted data space, and synchronously writes the updated critical control flow address space sequence to the independent secure enclave and edge data routing nodes. Before the update is complete, the digital contract signing entry is not based on the old first physical metric vector. Generate a new dynamic data access token After the update is completed, step S1 re-acquires the first physical metric vector. This enables the acquisition of the second physical metric vector in subsequent step S3. It can still be compared with the first physical metric vector Maintain the same address order and the same subscript meaning.

[0032] If any kernel-mode code page in the critical control flow address space sequence cannot be read under a privileged access path, the independent security enclave will mark the corresponding metric trigger request as not having formed a first physical metric vector. When all kernel-mode code pages in the critical control flow address space sequence have been read, and each kernel-mode code page has the platform configuration register value corresponding to the same read time, the independent safe enclave enters the incremental hash calculation.

[0033] S103: Incremental hashing of platform configuration register values ​​and kernel-mode code snippets.

[0034] The independent secure enclave reads kernel-mode code segments from the critical control flow address space sequentially, following the address order of the critical control flow address space sequence, and also reads the platform configuration register values ​​corresponding to the same read moment. The kernel-mode code segment read from the critical control flow address space is denoted as The platform configuration register value at the same read time is denoted as Independent secure enclaves use the SHA-256 hash algorithm to generate incremental hash values. : , in, For the first The incremental hash value corresponding to the segment critical control flow address space; The incremental hash value is calculated for the address space of the previous critical control flow segment; when hour, Pick , The initial metric value of the platform configuration register read at the starting point of the target data flow node metric for the independent secure enclave is used as the first physical metric vector. The initial input to the incremental hash chain; For the first Kernel-mode code fragments in the critical control flow address space; For the first The platform configuration register value at the time of segment read; This indicates concatenation in byte order. Incremental hash calculation proceeds segment by segment according to the critical control flow address space sequence. When any kernel-mode code segment or platform configuration register value changes, the change is propagated to the corresponding incremental hash value and subsequent incremental hash values.

[0035] In the implementation of cross-domain risk control scoring data retrieval, the independent secure enclave sequentially reads the kernel-mode code pages containing the risk control scoring interface decryption entry, routing interception entry, customer risk characteristic table address check entry, and message discard instruction entry. The contents of each kernel-mode code page and the platform configuration register value at the corresponding reading time are input into the incremental hash chain to obtain a set of incremental hash values ​​arranged in address order.

[0036] S104: The relationship between the generation of the first physical metric vector and the call to step S2 is established.

[0037] When the critical control flow address space sequence contains Segment address space, and independent secure enclaves are obtained sequentially. to At that time, the independent secure enclave organizes the incremental hash value array into a first physical metric vector. : , Among them, the first physical metric vector As the hardware metric benchmark for the target data flow node at the current moment, the incremental hash values ​​in the array are arranged according to the reading order of the key control flow address space sequence. This arrangement order serves as the reference for the first physical metric vector in step S2. The fixed order of time enables the business authorization constraint rules to obtain a stable bit-level input source when performing nonlinear cryptographic fusion.

[0038] Independent safe enclave completes first physical metric vector After generation, the first physical metric vector will be... Establish a corresponding output relationship with the target data flow node identifier in the metric trigger request, and return this corresponding output relationship to the digital contract signing entry. The digital contract signing entry will then send the first physical metric vector... Passed to step S2, serving as a dynamic data access token for step S2. The encrypted deconstruction mathematical correlation factor during generation; the content of the data contract to be signed is further parsed into business authorization constraint rules and the first physical metric vector by step S2. Do not write the token payload in plaintext business field format.

[0039] Through step S1, the cross-domain data contract conclusion request is converted into a first physical metric vector that can be invoked in step S2. The hardware metric of the target data transfer node at the time of contract signing is fixed as an array of incremental hash values ​​arranged according to the key control flow address space sequence. Step S1 also forms the target data transfer node identifier, the content of the data contract to be signed, and the first physical metric vector. The corresponding output relationship between them enables step S2 to, after parsing the business authorization constraint rules, match the business authorization constraint rules with the first physical metric vector. Perform nonlinear cryptographic fusion.

[0040] Step S1 has output the target data flow node identifier, the data contract content to be signed, and the first physical metric vector. The correspondence between them. However, the first physical metric vector It still cannot be directly issued as an access credential. In step S2, the business authorization constraint rules must first be parsed from the content of the data contract to be signed, then the business authorization constraint rules are converted into byte form that can participate in cryptographic operations, and then compared with the first physical metric vector. Perform nonlinear cryptographic fusion to generate a dynamic data access token for mathematical deconstruction attempts in step S3. .

[0041] S201: Parsing of Business Authorization Constraint Rules and Construction of Business Authorization Constraint Rule Byte Stream.

[0042] Step S2 uses the data contract content to be signed output from step S1 and the first physical metric vector. This serves as the starting point for processing. The digital contract signing entry point reads the authorization constraint statements related to controlled data calls from the content of the data contract to be signed, and parses the constraint items that can be executed by the edge data routing nodes into business authorization constraint rules. The business authorization constraint rules include at least the allowed API interfaces, the maximum number of reads, and the scope of controlled data calls, and are invoked after being restored through mathematical deconstruction in step S3.

[0043] After parsing, the digital contract signing entry point organizes the business authorization constraint rules according to the execution order of the constraints in the data contract to be signed, converting the allowed API interfaces, the maximum number of reads, and the controlled data call scope into a rule sequence with a defined order. Once the rule sequence is formed, the digital contract signing entry point performs normalized encoding on the rule sequence, writing each rule into a continuous byte range in the order of rule name, rule value, and rule boundary, resulting in a business authorization constraint rule byte stream. Business authorization constraint rules byte stream The rule items are encoded using a fixed byte order. Each rule item sequentially contains the rule name length, rule name, rule value length, rule value, rule boundary length, and rule boundary. Each length field is represented by a 2-byte unsigned integer and written in big-endian byte order. The rule name and rule value are represented using UTF-8 bytes, and the rule boundary is represented using comparable numerical bytes or address range bytes. Multiple rule items are written consecutively according to the constraint execution order in the data contract to be signed. In step S3, the edge data routing node splits the byte stream of the business authorization constraint rules to be parsed according to the same length field and byte order. Business authorization constraint rules byte stream It is a binary byte stream obtained by normalizing and encoding the business authorization constraint rules, and is used as the input object for bit-level obfuscation binding.

[0044] Business authorization constraint rules byte stream The standardized encoding order is also used as the byte stream of the business authorization constraint rules to be parsed in step S3. The basis for performing encoding syntax verification. Edge data routing nodes only... The business authorization constraint rule matching will only continue when the rule can be broken down into complete rule items in the order of rule name, rule value, and rule boundary.

[0045] In one implementation, the data user requests to call a cross-domain risk control scoring interface. The data contract to be signed specifies that the allowed API interface is the risk control scoring interface, the maximum number of records that can be read is the number agreed upon in the contract, and the controlled data access scope is the customer risk characteristic table managed by the target data flow node. After parsing the data contract to be signed, the digital contract signing entry encrypts the API interface, the maximum number of records that can be read, and the controlled data access scope into a business authorization constraint rule byte stream according to the contract execution order. and the business authorization constraint rule byte stream With the first physical metric vector Maintain the correspondence under the same target data flow node identifier.

[0046] S202: Nonlinear derivation of the feature segment of the first physical metric vector.

[0047] Business authorization constraint rules byte stream After formation, the digital contract signing entry reads the first physical metric vector generated in step S1. and based on business authorization constraint rules byte stream The byte length is used as the derivation length boundary. First physical metric vector. Composed of an incremental hash value array, the digital contract signing entry extracts the incremental hash value array according to the key control flow address space sequence determined in step S1, making the first physical metric vector... The input order in step S2 is consistent with the hardware measurement order at the time of contract signing.

[0048] The digital contract signing entry uses the SHA-256 hash extension method from the first physical metric vector. Feature fragment of the derived first physical metric vector First physical metric vector feature fragment It is the first physical metric vector The result obtained after non-linear hash expansion, and whose length matches the byte stream of the business authorization constraint rules. Consistent byte fragments. The derivation process is as follows: the first physical metric vector... The incremental hash values ​​are concatenated into a metric concatenation string in their original order. This metric concatenation string and the count sequence number are then input into the SHA-256 hash algorithm round by round to obtain candidate hash strings. Finally, the byte stream is processed according to the business authorization constraint rules. The candidate hash string is truncated to its length to form the first physical metric vector feature segment. : , in, This is a feature segment of the first physical metric vector; Business authorization constraint rules byte stream byte length; The first physical metric vector generated in step S1; To ensure that the total length of the candidate hash strings is not less than The smallest positive integer; This indicates extracting from the beginning of the candidate hash string. 1 byte; This indicates concatenation in byte order. First physical metric vector. After entering the SHA-256 hash extension, it no longer enters the token payload as the original incremental hash value array, but instead serves as a feature fragment for generating the first physical metric vector. The required mathematical correlation factors are hidden.

[0049] When the first physical metric vector feature segment The byte length reaches At this time, the digital contract signing entry point enters bit-level obfuscation binding processing; when the candidate hash string length is less than At that time, the digital contract signing entry increments the counter number and continues to execute the SHA-256 hash expansion until the first physical metric vector feature fragment is reached. Byte stream of business authorization constraint rules This forms a one-to-one byte position relationship.

[0050] S203: Bit-level obfuscation binding and symmetric cryptographic encapsulation.

[0051] First physical metric vector feature segment Once formed, the digital contract signing portal will display the business authorization constraint rules in byte stream. Feature fragments of the first physical metric vector Perform an XOR operation on the same byte positions to obtain the obfuscated payload. : , in, The obfuscated payload is the underlying payload of the symmetric encryption encapsulation. Byte stream for business authorization constraint rules; This is a feature segment of the first physical metric vector; This indicates a bitwise XOR operation. The XOR operation is performed bit by bit according to the byte position, and the business authorization constraint rules are based on the byte stream. The first in Location and first physical metric vector feature fragment The first in Bits form a unique correspondence, outputting a mixed load. The first in Bit. Nonlinear processing in nonlinear cryptographic fusion is determined by the first physical metric vector. The SHA-256 hash extension is used to generate the XOR operation, which is then used to convert the business authorization constraint rule byte stream. Feature fragments of the first physical metric vector Binding bit by bit.

[0052] Mixed loads After generation, the digital contract signing entry point calls a symmetric encryption algorithm to obfuscate the payload. Encapsulation is performed. The symmetric encryption algorithm uses a token encapsulation key pre-set by the target data flow node and the edge data routing node. Token encapsulation key When a target data transfer node is added to the trusted data space, a digital contract signing entry and the corresponding edge data routing node are written to it. The writing result is bound to the target data transfer node identifier. The digital contract signing entry generates a dynamic data access token. The corresponding token encapsulation key is invoked according to the target data flow node identifier. In step S3, the edge data routing node calls the locally stored token encapsulation key according to the identifier of the same target data flow node. .

[0053] The digital contract signing portal will obfuscate the payload. As the encrypted input, the encapsulation count value corresponding to the target data flow node identifier is read. Use a token to encapsulate the key. Perform symmetric encryption encapsulation with authentication tags and output the encryption result. and certification labels ; Ciphertext payload From package count value Encryption results and certification labels Formed by splicing in a fixed order. Encapsulated count value. Generated by a monotonically increasing counter maintained by the digital contract signing entry for the same target data flow node identifier, used to ensure the same obfuscated payload Different encrypted payloads are formed in different contracting events. ; Certification label Used for edge data routing nodes to ciphertext payload in step S3 Perform integrity verification. Ciphertext payload. It is formed according to the following relationship: , in, To encapsulate the count value, To obfuscate the load Token-encapsulated key The encrypted result obtained from encryption, The authentication tag is output as a symmetric encryption encapsulation with an authentication tag. This indicates concatenation in byte order. The integrity check value is included with the ciphertext payload. Encapsulated together in a dynamic data access token In this process, the integrity check value does not constitute the plaintext payload of the business authorization constraint rules, nor does it constitute an independent contract additional signature. The edge data routing node first checks the encrypted payload in step S3. The integrity of the data is checked, and if the integrity check fails, a physical blocking action and an authorized blocking flag are output directly.

[0054] S204: Dynamic data access token generation and distribution to edge data routing nodes.

[0055] Ciphertext payload Once formed, the digital contract signing portal will contain the encrypted payload. Write the call index corresponding to the target data flow node identifier into the dynamic data access token. Dynamic data access token It is a ciphertext payload And the access credentials formed by the target data flow node's call index, used in step S3 to perform mathematical deconstruction attempts when the edge data routing node intercepts a controlled data call request. Dynamic data access token. The target data flow node call index is only used by the edge data routing node to locate the local token encapsulation key. The queue to be destructured is not used to express business authorization constraint rules.

[0056] Digital contract signing portal generates dynamic data access tokens Then, the dynamic data access token Establish a contract status correspondence with the content of the data contract to be signed, and assign dynamic data access tokens. The dynamic data access token is sent to the edge data routing node of the target data flow node. The edge data routing node receives the dynamic data access token. Then, the dynamic data access token The data is placed in a local destructuring queue. When step S3 intercepts a controlled data access request pointing to controlled data, the edge data routing node calls the local hardware acceleration unit to access the dynamic data access token. An attempt was made to deconstruct the mathematical structure.

[0057] In the implementation of cross-domain risk control scoring data retrieval, after the digital contract signing entry completes the obfuscation and encapsulation of the risk control scoring interface call rules, the edge data routing node of the target data flow node only receives the dynamic data access token. Cannot access tokens from dynamic data The system directly reads the allowed API interfaces or the maximum number of data entries that can be read. When subsequent controlled data call requests reach the edge data routing node, the edge data routing node must collect a second physical metric vector within the current physical environment of the target data flow node. Combined with dynamic data access tokens Only after performing mathematical deconstruction attempts and deconstructing the business authorization constraint rules can they be used to determine whether to allow or block data flow.

[0058] In step S2, the business authorization constraint rules in the data contract to be signed are converted into a business authorization constraint rule byte stream. and the first physical metric vector generated in step S1 Achieve nonlinear cryptographic fusion to form dynamic data access tokens. First physical metric vector The mathematical correlation factor used in the ciphertext deconstruction is hidden within the ciphertext payload. The generation process of dynamic data access tokens The edge data routing node is delivered to the target data flow node for step S3 to invoke when intercepting controlled data call requests.

[0059] Step S2 has already linked the business authorization constraint rules with the first physical metric vector. Generate dynamic data access tokens The data is then delivered to the edge data routing node of the target data flow node. However, before the controlled data access request reaches the controlled data, the edge data routing node also needs to reconstruct a second physical metric vector that can be used for mathematical deconstruction in the current physical environment of the host machine. and in dynamic data access token During the deconstruction process, the execution status of the microarchitecture is monitored synchronously. Step S3 outputs either a release action or a physical blocking action, which is then used by step S4 to generate a status confirmation certificate. .

[0060] S301: Controlled data call request interception, second physical metric vector acquisition and fragment deconstruction initiation.

[0061] The edge data routing node uses the dynamic data access token issued in step S2 The process begins with a controlled data call request entering the target data flow node. After the controlled data call request arrives at the data entry register of the edge data routing node, the edge data routing node reads the target data address and call interface from the controlled data call request, and matches the target data address with the controlled data range managed by the target data flow node. If the matching result indicates that the controlled data call request points to controlled data, the edge data routing node suspends packet forwarding and enters local physical measurement collection.

[0062] Under the current execution environment of the host machine, the edge data routing node reads the host platform configuration register values ​​and corresponding kernel-mode code fragments according to the key control flow address space sequence adopted in step S1, and generates a second physical metric vector using the SHA-256 incremental hash method. Second physical metric vector It is an array of incremental hash values ​​generated by the host hardware metric at the moment the controlled data access request arrives at the target data flow node, used as a dynamic data access token. An attempt at mathematical deconstruction. Incremental hash value corresponding to the segment critical control flow address space Generate according to the following relationship: , in, For the first The incremental hash value generated in the segment critical control flow address space in the current execution environment of the host machine; This is the incremental hash value corresponding to the address space of the previous critical control flow segment; when hour, Pick , The initial metric value of the platform configuration register read by the edge data routing node at the start point of host data acquisition is used as the second physical metric vector. The initial input to the incremental hash chain; For the host machine Kernel-mode code fragments read from the critical control flow address space; For the host machine The platform configuration register value at the time of segment read; This indicates concatenation in byte order. After all critical control flow address spaces have been read, the edge data routing node will... to Organized into a second physical metric vector according to the reading order. .

[0063] Local hardware acceleration unit for dynamic data access tokens The process employs a fragmented destructuring approach. Edge data routing nodes first process the dynamic data access token. Ciphertext payload in Integrity verification is performed. If the integrity verification fails, a physical blocking action and an authorized blocking flag are output directly. If the integrity verification passes, the local hardware acceleration unit encapsulates the key using a token in its internal temporary register. For encrypted payload Perform symmetric decryption to obtain the obfuscated payload to be decrypted. The scrambled load to be restored The byte length is determined as the destructuring length boundary. Obfuscated load to be restored The data forwarding path to the edge data routing node is not released before the side channel determination is completed.

[0064] Edge data routing nodes to deconstruct length boundaries To extract the length, from the second physical metric vector Derived second physical metric vector feature fragment : , in, This is a feature segment of the second physical metric vector; For the scrambled load to be restored byte length; This is the second physical metric vector; To ensure that the total length of the candidate hash strings is not less than The smallest positive integer; This indicates extracting from the beginning of the candidate hash string. One byte. Second physical metric vector feature fragment. Mixed load to be restored After establishing a one-to-one correspondence between byte positions, the edge data routing nodes perform the following destructuring operation: , in, The byte stream of the business authorization constraint rules to be parsed; The obfuscated load to be restored; This is a feature segment of the second physical metric vector; This indicates a bitwise XOR operation.

[0065] After each fixed-byte segment is decrypted or XORed, the local hardware acceleration unit writes the result to an internal temporary register and does not release it to the data forwarding path. The length of the fixed-byte segment is denoted as... The width of the data path is determined by the internal data path of the local hardware acceleration unit, in one embodiment. Take 64 bytes. Obfuscated payload to be restored. according to Sequential division into A fixed byte segment, in which Not less than The smallest integer; the last fixed byte fragment is insufficient. Processing is based on the actual remaining bytes. Each fixed byte segment corresponds to an observation window, and the edge data routing node completes the memory access trajectory deviation of the corresponding segment within this observation window. Local power distortion mode and decision-making basis Calculation; only if the observation window satisfies Only then are the results of the corresponding segment retained in the internal temporary register, awaiting the deconstruction of the next segment. The edge data routing node calculates the memory access trajectory deviation at the end of each observation window. and local power distortion mode The decision-making basis is described by the support vector data of the hypersphere model. Only if the current observation window satisfies At that time, the local hardware acceleration unit continues to process the next fixed byte segment; when any observation window satisfies At this time, the local hardware acceleration unit clears its internal temporary registers, stops subsequent fragment destructuring, and the edge data routing node writes a discard instruction to the data entry register. The complete business authorization constraint rules are only satisfied when all observation windows are met. It is then released into the rule parsing process.

[0066] In the implementation of cross-domain risk control scoring data retrieval, after the call message of the risk control scoring interface arrives at the edge data routing node, the edge data routing node completes the second physical metric vector before the message enters the customer risk characteristic table. Data is collected and a dynamic data access token is initiated by the local hardware acceleration unit. The piecewise destructuring operation.

[0067] S302: Extraction of memory access trajectory deviation and calculation of Mahalanobis distance.

[0068] Second physical metric vector Collection process and dynamic data access token After the fragmentation process begins, the edge data routing node synchronously activates a hardware performance counter with an address sampling register. This hardware performance counter records the memory access addresses that trigger cache accesses within the fragmentation process context and writes the results to an address tracking buffer. The edge data routing node then reads the host machine's underlying memory access address sequence data from the address tracking buffer in sampling time order until a preset observation window length is reached. Then, the sampled memory access addresses are organized into a memory access address sequence. ,in For the first The address value corresponding to this memory access.

[0069] Preset observation window length The mean vector of the normal step size in the safety baseline trajectory is determined during the construction phase and is also used for real-time sampling. and normal step size covariance matrix All based on length of The step size sequence vector is calculated to obtain the real-time step size sequence vector. Also maintain Dimension. Edge data routing node memory access address sequence The step size sequence vector is formed by subtracting adjacent addresses. .

[0070] Step size sequence vector Once formed, the edge data routing nodes read the secure baseline trajectory. The secure baseline trajectory is formed by repeatedly running a deconstruction procedure within a clean, attack-free isolated sandbox, and includes a normal step-size mean vector. and normal step size covariance matrix Edge data routing nodes will use step-size sequence vectors. Normal step size mean vector and normal step size covariance matrix Input Mahalanobis distance calculation, output memory access trajectory deviation. : , in, Memory access trajectory deviation represents the statistical degree of deviation of the memory access step sequence in the current observation window from the safe baseline trajectory; This is the step size sequence vector obtained during the current observation window; This is the normal step size mean vector in the safe baseline trajectory; Normal step size covariance matrix The inverse matrix; Represents matrix transpose. Memory access trajectory deviation. As a dimensionless scalar, after output, it proceeds to step S304, where it is compared with the local power distortion mode. Together, they constitute the input features of the support vector data description hypersphere model.

[0071] When the normal step size covariance matrix When irreversible, the edge data routing node adopts... Alternative Perform the inverse operation, where To and Identity matrices of the same dimension The regularization parameter is set to 0.01 times the minimum non-zero step size variance in each dimension of the safe baseline trajectory. This is only used to ensure matrix invertibility and does not change the deviation of the memory access trajectory. As an output meaning of statistical Mahalanobis distance.

[0072] S303: Construction of two-dimensional scalar power field and calculation of local power distortion mode.

[0073] The local hardware acceleration unit executes dynamic data access tokens. During the piecewise mathematical deconstruction, the edge data routing node synchronously reads the microampere-level current sensing array in the local hardware acceleration unit. The current sensing array collects data on the internal transistor array logic switch switching rate and local operating voltage distribution at each coordinate point according to a two-dimensional wafer coordinate system. The edge data routing node inputs the logic switch switching rate, local operating voltage, and equivalent load capacitance into the dynamic power consumption equation under the same sampling clock to construct a two-dimensional scalar power field. : , in, Coordinate points in a two-dimensional wafer coordinate system The dynamic power consumption value at the location, measured in watts; Coordinates The internal transistor array logic switch switching rate is obtained by the local hardware acceleration unit's running count or by the sensor array. coordinate point The equivalent load capacitance at the location is provided by the factory configuration of the local hardware acceleration unit or the initialization calibration file of the target data transfer node, and corresponds one-to-one with the sampling points of the current sensing array according to the two-dimensional wafer coordinate system; coordinate point Local operating voltage at the location; This refers to the operating clock frequency used by the local hardware acceleration unit during mathematical deconstruction attempts. (Two-dimensional scalar power field) After formation, the edge data routing node proceeds to calculate spatial partial derivatives. The coordinates of the sampling points in the two-dimensional wafer coordinate system are determined by the current sensing array deployment file of the local hardware acceleration unit or the initialization calibration file of the target data transfer node. During the initialization phase, the edge data routing node reads this sampling point coordinate file and maps each current sensing sampling point to two-dimensional coordinates. ; Spacing between adjacent sampling points in the horizontal direction The distance between adjacent sampling points in the vertical direction is determined by the difference between two adjacent horizontal coordinates under the same vertical coordinate. Determined by the difference between two adjacent vertical coordinates under the same horizontal coordinate. Local power distortion mode. Spatial partial derivatives are calculated only for coordinate points with horizontally adjacent sampling points and vertically adjacent sampling points.

[0074] Edge data routing nodes extract the power consumption difference between adjacent coordinate points on the horizontal and vertical axes of a two-dimensional wafer coordinate system, and divide the power consumption difference by the distance between adjacent coordinate points to obtain discrete spatial partial derivatives. Then, the second norm of the horizontal and vertical discrete spatial partial derivatives is calculated to obtain the power consumption gradient norm distribution, and the maximum value in this power consumption gradient norm distribution is selected as the local power consumption distortion mode. : , in, This is a local power distortion mode, with the dimension of watts per meter; The distance between adjacent sampling points in the two-dimensional wafer coordinate system; The vertical spacing between adjacent sampling points in a two-dimensional wafer coordinate system; This represents the power consumption difference between adjacent sampling points in the horizontal direction. This represents the power consumption difference between adjacent sampling points along the vertical axis. Local power distortion mode. The location of the steepest power consumption change that occurs during the mathematical decomposition attempt by the local hardware acceleration unit is output and then proceeds to step S304 for the deviation from the memory access trajectory. Together they constitute the feature points of the current execution state. .

[0075] In the implementation of cross-domain risk control scoring data retrieval, the local hardware acceleration unit executes dynamic data access tokens. During chip fragmentation, edge data routing nodes read the logic switch toggle rate and operating voltage distribution of local areas of the chip in a two-dimensional wafer coordinate system. If a local area experiences a steep power consumption descent due to repeated cryptographic collision instructions, the edge data routing node uses a two-dimensional scalar power field... The spatial partial derivative L2 norm outputs this local variation as a local power distortion mode. .

[0076] S304: Support Vector Data Description Determination, Destruction Result Verification, and Action Output.

[0077] Memory access trajectory deviation and local power distortion mode After both are generated, the edge data routing nodes organize them into current execution state feature points in a fixed order. Current execution state feature points The hypersphere model is described by pre-deployed support vector data. The training samples of the hypersphere model and the real-time input use the same two-dimensional feature structure, where the first dimension of the two-dimensional feature structure is the memory access trajectory deviation. The second dimension is the local power consumption distortion mode. .

[0078] In one embodiment, the pre-deployed support vector data describes the hypersphere model as a single-class kernel function boundary model; to facilitate deployment in a local hardware acceleration unit, its equivalent computational structure includes three sequential computation layers. The first layer is a two-dimensional input normalization layer, with two input nodes, each receiving the memory access trajectory deviation. and local power distortion mode The second layer is a Gaussian radial basis function kernel mapping layer, with 64 kernel computation units. Each kernel computation unit corresponds to one normal state support vector retained after training. Its activation function is a Gaussian radial basis function, used to calculate the feature points of the current execution state. With corresponding support vectors The kernel function values ​​between the layers; the third layer is the distance output layer, with one output node, based on 64 kernel function values ​​and corresponding support vector coefficients. In addition to the kernel function constants between support vectors, the decision-making basis is output. This equivalent computational structure does not use traditional fully connected hidden layers, nor does it employ ReLU, Sigmoid, or Softmax classification activation functions. The output is not the class probability, but rather the feature points of the current execution state. The Euclidean distance to the center of the hypersphere.

[0079] The training dataset was collected in a clean, isolated sandbox free from attacks, with 12,000 training samples, each sample represented by a dynamic data access token. The deconstruction process generates the sample features, which only include two dimensions: the first dimension is the memory access trajectory deviation. The 255-dimensional step-size sequence is extracted from the memory access address sequence of length 256, and the Mahalanobis distance is calculated relative to the safe baseline trajectory; the second dimension is the local power distortion mode. The maximum power gradient norm is obtained by calculating the sampling points of the two-dimensional wafer coordinates of the local hardware acceleration unit. Before training... and Quantile normalization is performed separately, mapping the 5th percentile of the training set to 0 and the 95th percentile to 1. Values ​​outside this range are truncated at the boundaries, ensuring that training feature points and real-time current execution state feature points are on the same numerical scale. After training, the edge data routing nodes will record the memory access trajectory deviation. 5th percentile and the 95th percentile Local power distortion mode 5th percentile and the 95th percentile With support vectors Support vector coefficients Core width parameter and preset radius threshold This information is then written into the model parameter area. During the real-time inference phase, the edge data routing nodes first apply the aforementioned percentile parameters to the current observation window. and Perform the same quantile normalization, and then use the normalized two-dimensional feature points as the current execution state feature points. Input support vector data to describe the hypersphere model.

[0080] During the training phase, single-class convex optimization training described by support vector data is used, with only normally functioning samples as input and no attack samples input. The training feature points obtained from multiple safe runs form the training feature point set. ,in, For the first Two-dimensional training feature points obtained from the first safe run For the first The deviation of the memory access trajectory obtained from the second safe operation. For the first The local power consumption distortion mode obtained from the first safe operation. In this embodiment, the number of training feature points is [not specified]. The training objective function is to minimize the sum of the squared radius of the hypersphere and the out-of-bounds relaxation: , The constraints are: , in, The center of a hypersphere in the high-dimensional regenerative nucleus Hilbert space; The radius of the hypersphere obtained during the training process; For the first The out-of-bounds relaxation amount corresponding to each training feature point; The penalty parameter controls the proportion of normal training samples allowed to lie outside the hypersphere boundary; in this embodiment... ; The number of training feature points; For training feature points High-dimensional features after kernel function mapping. After training, the convex optimization result is converted into support vectors. Support vector coefficients and preset radius threshold The above parameters are then written into the model parameter area of ​​the edge data routing node.

[0081] Support vector data description of the hypersphere model uses a Gaussian radial basis kernel function: , in, This represents the Gaussian radial basis function kernel value between two two-dimensional feature points; and Let them be any two two-dimensional feature points; Let be the Euclidean distance between the two. This is the kernel width parameter of the Gaussian radial basis function. From the training feature point set The median of the Euclidean distance between any two distinct training feature points is used to determine the median; when the median is 0, the minimum non-zero Euclidean distance is taken as the median. In this embodiment, the normalized feature space within... We set the value to 1.25. After model training, we retain 64 support vectors and 64 support vector coefficients. Core width parameter and preset radius threshold The pre-trained parameters are then written into the model parameter area of ​​the edge data routing node. During the real-time inference phase, the edge data routing node does not retrain the model; it only uses the pre-trained parameters to calculate the decision basis. .

[0082] Edge data routing nodes will display the current execution state feature points. After inputting the Support Vector Data Description Hypersphere model, the Support Vector Data Description Hypersphere model calculates the feature points of the current execution state. The Euclidean distance from the center of the hypersphere in higher-dimensional space is used as a basis for decision-making. : , in, As the basis for decision-making, it represents the characteristic points of the current execution state. The Euclidean distance from the center of the hypersphere in higher-dimensional space; Characteristic points representing the current execution state Its own kernel function value; Characteristic points representing the current execution state With the support vectors The kernel function value; Indicates the first support vectors With the support vectors Kernel function values ​​between; and Normal state support vectors retained during the training phase; and The support vector coefficients obtained by convex optimization solution; To determine the number of support vectors, in this embodiment... .

[0083] Edge data routing nodes will make decisions based on With preset radius threshold Comparison. When When the edge data routing node determines that the current mathematical deconstruction attempt is outside the hypersphere boundary, it immediately issues an interrupt command to the local hardware acceleration unit, clears the internal temporary registers, and stops the byte stream of the service authorization constraint rules to be parsed. The parsing continues, and a discard instruction is written to the data entry register, outputting a physical blocking action and a side-channel blocking flag. The physical blocking action indicates that the packet is discarded at the register level, and the side-channel blocking flag indicates that the physical blocking action was triggered by a microarchitecture execution state out of bounds. The physical blocking action and the side-channel blocking flag are retained for step S4 to generate the state confirmation certificate. Input.

[0084] when At this time, the edge data routing node allows the local hardware acceleration unit to complete the dynamic data access token. An attempt at mathematical deconstruction, and a byte stream of business authorization constraint rules to be parsed. Perform encoding syntax verification. The encoding syntax verification forms a business authorization constraint rule byte stream in step S201. The rule name, rule values, and rule boundaries are written in the order specified during the verification process. If the byte stream of the business authorization constraint rule to be parsed... If the rules cannot be split into complete rule items according to the writing order, or if the rule boundary of any rule item cannot be resolved into a comparable boundary value, the edge data routing node directly writes a drop instruction to the data entry register and outputs a physical blocking action and an authorized blocking flag.

[0085] Only the byte stream of the business authorization constraint rules that has passed the encoding syntax check is available for parsing. Only then does the process begin, matching each element of the API call, target data address, and requested read count. The business authorization constraint rules obtained from rule parsing are matched item by item with the API call, target data address, and requested read count in the controlled data call request. If the API call belongs to a permitted API, the target data address falls within the controlled data call range, and the requested read count does not exceed the upper limit, the edge data routing node outputs a release action. If any matching result does not satisfy the business authorization constraint rules, the edge data routing node writes a discard instruction to the data entry register and outputs a physical blocking action and an authorization blocking flag. The authorization blocking flag indicates that the physical blocking action was triggered by the failure of the business authorization constraint rule verification.

[0086] In the implementation of cross-domain risk control scoring data retrieval, risk control scoring interface requests are only made at the current execution state characteristic point. Only when the boundary of the support vector data description hypersphere is not crossed, and the risk control scoring interface, customer risk feature table address, and number of requested reads all comply with the deconstructed business authorization constraint rules, will the edge data routing node allow access to the controlled data. If the memory access trajectory or power consumption distortion during the deconstruction process exceeds the limit, the edge data routing node will directly execute register-level physical blocking. If the deconstructed byte stream cannot pass the encoding syntax verification, or the number of requested reads exceeds the upper limit of the number of reads, the edge data routing node will output physical blocking action and authorization blocking flag.

[0087] Through step S3, the edge data routing node completes the second physical metric vector when the controlled data retrieval request arrives. Collection, dynamic data access token Fragmented mathematical deconstruction attempt, memory access trajectory deviation With local power distortion mode The calculation is performed, and the decision-making basis of the hypersphere model is described by support vector data. Step S3 ultimately generates a release action, or a physical blocking action and its corresponding side-channel blocking flag or authorized blocking flag, which are then used in step S4 to generate the status confirmation certificate. And then feed it back to the blockchain node.

[0088] Step S3 has already generated a release action or a physical blocking action and its corresponding side-channel blocking flag or authorized blocking flag at the edge data routing node. However, the edge-side action has not yet been transformed into a data contract state that can be confirmed by the blockchain node. Step S4 needs to generate a state confirmation certificate based on the action result, judgment source, and microarchitecture judgment parameters output by step S3. and the status confirmation certificate Feedback across the network is sent to the blockchain node, enabling the data contract state machine to complete settlement or block updates.

[0089] S401: Edge-side action result locking and state branch determination.

[0090] Step S4 uses the release action, physical blocking action, side-channel blocking flag, license blocking flag, and memory access trajectory deviation output in step S3. Local power distortion mode Decision-making basis Preset radius threshold and dynamic data access tokens The correspondence serves as the starting point for processing. After outputting a release action or physical blocking action, the edge data routing node immediately reads the action type from its local action register and matches the action type with the dynamic data access token. Establish action event relationships for the corresponding data contract content to be signed; when the action type is a release action, the action event relationship points to the settlement branch, and when the action type is a physical blocking action, the action event relationship points to the blocking branch.

[0091] When a physical blocking action carries a side-channel blocking flag, the edge data routing node determines the source of the blocking branch as a microarchitecture execution state out of bounds. When a physical blocking action carries an authorized blocking flag, the edge data routing node determines the source of the blocking branch as a failure to pass the business authorization constraint rule verification. If the action type is a release action, the edge data routing node determines the source of the release branch as a successful business authorization constraint rule verification. This branch source is used to describe the data contract state machine update path and does not change the message release or register-level discard result already completed in step S3.

[0092] In the implementation of cross-domain risk control scoring data retrieval, after the risk control scoring interface request is allowed by the edge data routing node, the action register records the allowance action, and the status branch corresponding to the data contract content to be signed is determined as the settlement branch; if the risk control scoring interface request is interrupted during the local hardware acceleration unit deconstruction due to decision-making basis... Greater than the preset radius threshold The action register records the physical blocking action and the side channel blocking flag, and the state branch corresponding to the data contract content to be signed is determined as the blocking branch.

[0093] S402: Construction of Status Confirmation Certificate and Generation of Status Confirmation Summary.

[0094] After the edge-side action result is locked, the edge data routing node constructs a status confirmation certificate. Status confirmation certificate It is a credential object used to prove to blockchain nodes that the edge data routing node has taken either permission or physical blocking action for the current controlled data access request. Its inputs include the target data flow node identifier and the dynamic data access token. The token digest, controlled data access request digest, action event sequence number, action type, source of the blocked branch or the source of the allowed branch, and second physical metric vector. Metrics summary, memory access trajectory deviation Local power distortion mode Decision-making basis and preset radius threshold The controlled data access request digest is obtained by concatenating the target data address, the calling interface, and the number of data entries requested in the controlled data access request in a fixed order and then performing a SHA-256 hash operation; the action event sequence number is obtained by the edge data routing node for the same dynamic data access token. A monotonically increasing counter is generated for maintenance. When the action type is a physical blocking action corresponding to the authorized blocking flag, a status confirmation credential is generated. It also writes the matching results of business authorization constraint rules that failed the validation.

[0095] Edge data routing nodes first check the dynamic data access token Perform a SHA-256 hash operation to obtain the token digest. Perform a SHA-256 hash operation on this controlled data access request to obtain the controlled data access request digest. Then, perform a SHA-256 hash operation on the second physical metric vector. Perform a SHA-256 hash operation to obtain a metric digest, then sort the data according to the target data flow node identifier, token digest, controlled data call request digest, action event sequence number, metric digest, action type, branch source, and memory access trajectory deviation. Local power distortion mode Decision-making basis and preset radius threshold By concatenating the order of the data, a state ownership summary is generated. : , in, This is a state ownership summary, used to generate state ownership certificates. The signature of the voucher; Identify the target data flow node; For dynamic data access tokens The token digest; A request byte string formed by concatenating the target data address, the calling interface, and the number of data items requested to be read in a fixed order in a controlled data access request. A digest of controlled data access requests; The sequence number of the action event; The second physical metric vector A summary of metrics; The type of action includes release actions or physical blocking actions; For branch origins, this includes business authorization constraint rule validation passing, microarchitecture execution state out of bounds, business authorization constraint rule validation failing, or invalid credentials; The deviation of the memory access trajectory; This is a local power consumption distortion mode; The decision-making basis for the output of the hypersphere model is described by support vector data; The preset radius threshold; This indicates concatenation in byte order.

[0096] State ownership summary Once formed, the edge data routing node uses its device private key to establish a state ownership digest. Generate a credential signature and a status confirmation digest. The credential signature and the action types required for participating in state machine updates are collectively encapsulated into a state ownership credential. When the action type is a release action, the status confirmation certificate... The branch originates from the business authorization constraint rule verification; when the action type is a physical blocking action, the status confirmation certificate is used. The branch source in the code corresponds to either a side channel blocking flag or a license blocking flag. Therefore, the state ownership certificate... It carries both the action result of the edge data routing node and the source of the determination that triggered the action result in step S3.

[0097] S403: Status confirmation certificate cross-network feedback and blockchain node verification.

[0098] Status confirmation certificate After generation, the edge data routing node will assign the state ownership certificate. The data is sent to the blockchain node via a cross-network feedback channel within the trusted data space. This cross-network feedback channel uses the target data flow node identifier as the routing basis and transmits the state ownership certificate. Send the data to the blockchain node containing the data contract state machine that carries the data contract content to be signed, so that the edge-side action result can correspond to the original data contract state.

[0099] Blockchain nodes receive state confirmation certificates Then, read the status confirmation certificate. State confirmation summary The process involves several steps: verifying the credential signature, action type, and branch source; then, obtaining the edge data routing node device public key based on the target data flow node identifier. This edge data routing node device public key is registered with the blockchain node hosting the data contract state machine when the target data flow node joins the trusted data space; the registration record is bound to the target data flow node identifier. The blockchain node only uses the edge data routing node device public key corresponding to this registration record to verify the state ownership certificate. The signature of the voucher.

[0100] After the credential signature is verified, the blockchain node confirms the ownership of the credential based on its status. Carrying the target data flow node identifier and dynamic data access token The token digest is used to find the corresponding data contract state machine; after finding the unique corresponding data contract state machine, the blockchain node enters the state update determination. If the credential signature fails verification, or the dynamic data access token... The token digest cannot be mapped to the content of the data contract to be signed, so the blockchain node will issue a state ownership certificate. The credential is marked as invalid, triggering the data contract state machine to enter the blocking update path. The blocking source record indicates that the credential is invalid. This blocking update only applies to the on-chain settlement state, preventing the corresponding data contract content to be signed from entering the settlementable state; register-level message actions already executed by the edge data routing node are not modified in reverse by the blockchain node.

[0101] S404: Settlement or blocking update of the data contract state machine.

[0102] Blockchain node completion status confirmation certificate After verification, the certificate of ownership is confirmed based on its status. The action type and branch source trigger the data contract state machine. When the action type is a release action and the branch source is a business authorization constraint rule that has passed verification, the data contract state machine enters the settlement update path. The blockchain node records the controlled data call corresponding to the data contract content to be signed as released and updates the contract status to a settlement-ready state.

[0103] When the action type is a physical blocking action and the branch originates from a microarchitecture execution state out of bounds, the data contract state machine enters the side-channel blocking update path, the blockchain node updates the contract state to the blocking state, and writes a side-channel blocking flag; when the action type is a physical blocking action and the branch originates from a business authorization constraint rule verification failure, the data contract state machine enters the authorization blocking update path, the blockchain node updates the contract state to the blocking state, and writes an authorization blocking flag; State confirmation certificate. When a credential is marked as invalid, the data contract state machine enters the invalid credential blocking update path. The blockchain node updates the contract state to the blocking state and writes the source of the invalid credential. The side-channel blocking flag and the authorization blocking flag use the same flags output in step S3 to distinguish the triggering reason for the blocking state.

[0104] In the implementation of cross-domain risk control scoring data retrieval, the blockchain node receives the status confirmation certificate corresponding to the risk control scoring interface request. Subsequently, if the credential signature passes verification and the action type is a release action, the data contract state machine writes the risk control scoring data call to the settlement-ready state; if the action type is a physical blocking action and the branch source is a microarchitecture execution state out of bounds, the data contract state machine writes the call to the blocking state and records a side-channel blocking flag; if the action type is a physical blocking action and the branch source is a business authorization constraint rule verification failure, the data contract state machine writes the call to the blocking state and records an authorization blocking flag; if the status confirms the credential... If the signature verification fails, the data contract state machine will write the call to a blocked state and record the source of the invalid credential.

[0105] Following step S4, the output of step S3 includes the release action, physical blocking action, side-channel blocking flag, license blocking flag, and memory access trajectory deviation. Local power distortion mode and decision-making basis Converted into a status confirmation certificate The blockchain nodes then verify the transaction and update the state machine. Based on this, the data contract state machine forms a settleable state or a blocked state. The local action result of the edge data routing node is consistent with the on-chain contract state, and the controlled data call processing process in the trusted data space ends.

[0106] The above embodiments are merely preferred embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A blockchain-based trusted data space digital contract signing method, executed between a target data flow transfer node, an edge data routing node and a blockchain node, characterized in that, include: Step S1: In response to the received cross-domain data contract conclusion request, trigger the independent security enclave at the bottom layer of the target data transfer node, extract the hardware metric benchmark of the target data transfer node at the privilege level at the current moment. The hardware metric benchmark is formed by the platform configuration register value and kernel code fragment, and generate the first physical metric vector. Step S2: Parse the content of the data contract to be signed to obtain the business authorization constraint rules, perform nonlinear cryptographic fusion of the business authorization constraint rules and the first physical metric vector to generate a dynamic data access token, wherein the first physical metric vector is hidden as the ciphertext deconstruction mathematical correlation factor of the dynamic data access token; Step S3: When the edge data routing node intercepts the controlled data call request, it collects the current second physical metric vector of the host machine, and attempts to mathematically deconstruct the dynamic data access token based on the second physical metric vector. During the mathematical deconstruction attempt, it performs side channel determination and outputs the release action or physical blocking action. Step S4: Generate a state confirmation certificate based on the release action or physical blocking action, and feed the state confirmation certificate back to the blockchain node across the network to trigger the data contract state machine to perform settlement state update or blocking state update. 2.The blockchain-based trusted data space digital contract signing method according to claim 1, characterized in that, In step S1, the independent secure enclave reads kernel-mode code fragments and platform configuration register values ​​according to the critical control flow address space sequence. The critical control flow address space sequence includes kernel-mode code pages corresponding to decryption call entry, routing interception entry, controlled data address check entry, and register-level discard instruction entry. Each kernel-mode code page is arranged in ascending order of its starting physical address and is consistent with the critical control flow address space sequence saved by the edge data routing node, so that the first physical metric vector and the second physical metric vector correspond to the same kernel control flow address range at the same index position. 3.The blockchain-based trusted data space digital contract signing method of claim 2, characterized in that, In step S1, the independent secure enclave concatenates the previous incremental hash value, the current kernel-mode code fragment, and the platform configuration register value at the same reading time in byte order to generate the current incremental hash value, and organizes the incremental hash values ​​obtained sequentially according to the critical control flow address space sequence into the first physical metric vector; when the critical control flow address space sequence changes, the updated critical control flow address space sequence is synchronously written to the independent secure enclave and the edge data routing node, and the first physical metric vector is re-collected. 4.The blockchain-based trusted data space digital contract signing method of claim 1, wherein, In step S2, the business authorization constraint rules include the allowed interfaces, the maximum number of reads, and the controlled data call range. The digital contract signing entry performs standardized encoding of the business authorization constraint rules in the order of rule name, rule value, and rule boundary to form a business authorization constraint rule byte stream. The byte length of the business authorization constraint rule byte stream is used as the derivation length boundary of the first physical metric vector feature segment. The first physical metric vector feature segment is obtained by hash expansion and truncation of the first physical metric vector. 5.The blockchain-based trusted data space digital contract signing method of claim 4, characterized in that, In step S2, the digital contract signing entry derives the first physical metric vector feature fragment from the first physical metric vector, performs an XOR operation on the business authorization constraint rule byte stream and the first physical metric vector feature fragment at the same byte position to obtain the obfuscated payload, and calls the token encapsulation key bound to the target data flow node identifier to perform symmetric encryption encapsulation with authentication tag on the obfuscated payload to form a dynamic data access token. The dynamic data access token includes a ciphertext payload formed by the encapsulation count value, encryption result and authentication tag. 6.The blockchain-based trusted data space digital contract signing method of claim 3, wherein, In step S3, the edge data routing node reads the host platform configuration register value and the corresponding kernel-mode code segment according to the key control flow address space sequence to generate a second physical metric vector; performs integrity verification on the dynamic data access token, and after the integrity verification passes, derives a second physical metric vector feature segment based on the second physical metric vector, performs an XOR operation with the decrypted obfuscated payload to be restored to obtain the byte stream of the business authorization constraint rule to be parsed, and enters the business authorization constraint rule matching after the byte stream of the business authorization constraint rule to be parsed passes the encoding syntax verification.

7. The blockchain-based trusted data space digital contract signing method according to claim 6, characterized in that, In step S3, the local hardware acceleration unit performs dynamic data access token destructuring in a fragmented manner, with each fixed byte fragment corresponding to an observation window. The edge data routing node obtains the memory access address sequence through a hardware performance counter with an address sampling register within the observation window, extracts the step size sequence of adjacent addresses, and calculates the memory access trajectory deviation based on the normal step size mean vector and normal step size covariance matrix in the safe baseline trajectory. The destructuring result of the fixed byte fragment is written into the temporary storage register inside the local hardware acceleration unit before the side channel determination is completed. 8.The blockchain-based trusted data space digital contract signing method of claim 7, wherein, In step S3, the edge data routing node collects the internal transistor array logic switch switching rate and local operating voltage distribution data of the local hardware acceleration unit within the observation window, constructs a two-dimensional scalar power consumption field and calculates the local power consumption distortion mode, and uses the memory access trajectory deviation and the local power consumption distortion mode to form the current execution state feature points. It inputs the pre-deployed support vector data to describe the hypersphere model, and determines whether to continue deconstruction or output a physical blocking action based on the decision criteria output by the model. After completing the deconstruction, it outputs a release action or a physical blocking action based on the verification results of the business authorization constraint rules. The physical blocking action includes clearing the internal temporary storage register and writing a discard instruction to the data entry register. 9.The blockchain-based trusted data space digital contract signing method of claim 1, wherein, In step S4, the edge data routing node reads the action type in the local action register according to the release action or physical blocking action, and establishes an action event relationship between the action type and the data contract content to be signed corresponding to the dynamic data access token; the status confirmation certificate includes the target data flow node identifier, the token digest of the dynamic data access token, the controlled data call request digest, the action event sequence number, the action type, the branch source, and the metric digest of the second physical metric vector. The branch source includes business authorization constraint rule verification passed, microarchitecture execution state out of bounds, and business authorization constraint rule verification failed. The controlled data call request digest is generated from the target data address, call interface, and number of requested reads in the controlled data call request. 10.The blockchain-based trusted data space digital contract signing method of claim 9, wherein, In step S4, the edge data routing node sends the state confirmation certificate to the blockchain node through the cross-network feedback channel. The blockchain node obtains the public key of the edge data routing node device based on the target data flow node identifier and verifies the certificate signature in the state confirmation certificate. After the signature is verified, the blockchain node triggers the data contract state machine to enter the settlement update path, side channel blocking update path, or authorization blocking update path according to the action type and branch source, and updates the corresponding data contract state machine to the settlement state or blocking state.

Images