A method and system for edge mutation triggered digital identity emergency authorization and recovery

Abstract

The application discloses an edge mutation triggered digital identity emergency authorization and recovery method and system, and belongs to the technical field of edge computing and identity authentication. The running environment of an identity authentication service process on an edge computing node is monitored in real time. When an edge mutation event deviating from a preset reference state is captured, mutation cause characteristics are extracted. According to the category of the mutation event, a locally encrypted and stored emergency authorization strategy description file is read, and authorization actions are sequentially executed according to the operation primitive sequence defined therein. Within the validity period of a temporary credential, in response to a recovery request or a timeout event, a recovery process matched with the authorization strategy is executed. The application executes differentiated emergency authorization and recovery operations for different mutation causes, does not rely on a cloud or a centralized identity management platform, and can quickly complete emergency switching and safety fallback of a digital identity in the case of security anomalies in an edge computing environment.

Description

Technical Field

[0001] The present invention discloses a method and system for emergency authorization and recovery of digital identity triggered by edge mutations, belonging to the technical fields of edge computing and identity authentication. Background Art

[0002] In an edge computing environment, identity authentication services usually rely on local digital identity credentials such as certificates, tokens or symmetric keys at edge nodes to authorize users or devices. Since edge nodes are often deployed at sites with weak physical security protection and unstable network connections, their operating environments are prone to sudden abnormal changes, such as the registers of the trusted platform module being unexpectedly rewritten, frequent interruptions in the communication link, or sudden deviation of user behavior patterns from historical trajectories. Once such edge mutation events occur, it may lead to the inability to use the original identity credentials normally, or the node being unable to communicate with the cloud authentication center in time to obtain new credentials. Traditional solutions usually adopt the methods of global downgrading, direct denial of service or requesting manual intervention. However, global downgrading will reduce the security level of all users, direct denial of service will cause business interruption, and manual intervention has slow response and is not applicable to unattended edge nodes. Therefore, there is an urgent need for a method that can quickly and differentially complete the emergency authorization and recovery of digital identity according to the specific inducements of mutations after edge mutations occur.

[0003] Some existing emergency authorization technologies often focus on centralized identity management systems or cloud-based backup and recovery mechanisms. They assume that the network connection is always available and rely on multi-source data fusion or model training to evaluate risks. However, in the edge computing scenario, the network connection is not reliable, and the computing and storage resources of edge nodes are limited, making it difficult to carry complex machine learning models or large-scale data fusion processes. In addition, existing methods often introduce data preprocessing, normalization or standardization steps to ensure data consistency, which not only increases the processing delay of edge nodes, but also easily leads to preprocessing failure due to environmental mutations. More critically, existing technologies fail to design differential authorization strategies according to different inducements of edge mutation events, such as physical layer hardware changes, link layer communication anomalies, and application layer behavior mutations. As a result, when facing different types of mutations, either a uniform conservative strategy is adopted, or the emergency response ability is completely lost. At the same time, existing methods generally lack a structured withdrawal operation sequence that matches the authorization strategy in the recovery stage, making the rollback of the security state incomplete or unreliable. Summary of the Invention

[0004] To address the aforementioned issues, this invention proposes a method for emergency authorization and recovery of digital identity triggered by edge mutations. This method first monitors the operational environment of the identity authentication service process on edge computing nodes in real time. Once an edge mutation event deviating from a preset baseline state is detected, the characteristics of the mutation trigger are extracted, and the mutation is classified into physical layer, link layer, or application layer mutations using a decision tree. Then, the associated emergency authorization policy description file is read. Subsequently, authorization actions such as forging temporary identity credentials, setting validity periods, and attaching permission constraints are executed according to the operation primitive sequence defined in the policy file. Within the validity period of the temporary credential, a recovery process matching the authorization policy is executed based on user recovery requests or system timeout events, including revoking the temporary credential, clearing session traces, and reactivating the original digital identity state. The entire process is completed in a trusted execution environment on the edge node, and the specific details of the authorization actions and recovery operations differ significantly depending on the mutation type. Therefore, without relying on the cloud, introducing multi-source data, or performing model training, fine-grained, rapid response, and secure rollback to edge mutation events are achieved.

[0005] This application provides a method for emergency authorization and recovery of digital identity triggered by edge mutations, including the following steps: Step A: Monitor the running environment of the identity authentication service process in real time. When an edge mutation event deviating from the preset baseline state information is detected in the running environment, extract the mutation cause feature vector carried by the edge mutation event. Step B involves inputting the mutation cause feature vector into a pre-constructed cause classification decision tree, performing step-by-step matching along the branch conditions of the decision tree, and outputting the mutation category to which the marginal mutation event belongs. Step C: Based on the mutation category, read the corresponding emergency authorization policy description file, wherein the physical layer hardware mutation set is associated with the first policy description file, the link layer communication mutation set is associated with the second policy description file, and the application layer behavior mutation set is associated with the third policy description file. Step D: Parse the read emergency authorization policy description file and execute the authorization actions in sequence according to the defined operation primitive sequence, including creating a temporary identity credential, setting the validity period of the temporary identity credential, and attaching operation permission constraints to the temporary identity credential. Step E: During the validity period of the temporary identity credential, in response to a user-triggered recovery request or a timeout event automatically determined by the system, execute the recovery process that matches the emergency authorization policy description file, including revoking the temporary identity credential, clearing the session traces associated with the temporary identity credential, and reactivating the original digital identity state.

[0006] Further, step A includes: Periodically read the hash value change counter of the trusted platform module in the edge computing node to record the number of times the platform configuration register has been modified since the last authentication; When the value of the hash value change counter increases relative to the previous reading time, an edge mutation event is determined to have occurred, and the current value of the hash value change counter is used as the unique component of the mutation cause feature vector.

[0007] Furthermore, the cause classification decision tree in step B contains two levels of branching conditions: The first level is divided according to the numerical range of the unique component of the mutation cause feature vector. If the value falls within the first predetermined range, it is classified into the physical layer hardware mutation set; if it falls within the second predetermined range, it is classified into the link layer communication mutation set; and if it falls within the third predetermined range, it is classified into the application layer behavior mutation set. The second level further subdivides each mutation set into severe or mild subclasses based on how close the values ​​are to the interval boundaries. Values ​​that are less than a predetermined threshold from the interval boundary are classified into the mild subclass, while those that are not are classified into the severe subclass.

[0008] Furthermore, when the emergency authorization policy description file read in step C is the first policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D specifically include the following sub-steps: D1 reads a pre-stored downgraded authentication token for emergency use from the trusted platform module of the edge computing node; D2: Hash the feature information of the current edge mutation event to obtain an event digest, and then concatenate the event digest with the downgraded authentication token and hash it again to generate the basic seed of the first temporary credential. D3 calls the local pseudo-random number generator of the edge computing node to generate a random number string with a preset bit length as input to the basic seed, which serves as the main part of the first temporary certificate; D4. Obtain the system timestamp of the current edge computing node, add a predetermined emergency authorization validity period offset to the timestamp as the expiration time of the first temporary certificate. The predetermined emergency authorization validity period offset is set as the first duration offset for the physical layer severe mutation subclass and as the second duration offset for the physical layer slight mutation subclass. D5 combines the main body of the first temporary credential, the expiration time, and the device unique identifier of the edge computing node into a single package. The packaged data is then signed using the device private key in the trusted platform module to form the complete data structure of the first temporary credential. D6. Create an independent sandbox execution environment in the operating system of the edge computing node, inject the first temporary credential into the sandbox execution environment, and restrict the sandbox execution environment to access only a predefined set of emergency resources, which includes an emergency directory in the local file system and an emergency communication port in the network protocol stack. D7. Record the execution log of steps D1 to D6, append it to the read-only audit memory inside the edge computing node, and set the anti-tampering lock bit of the corresponding area of ​​the audit memory after the writing is completed.

[0009] Furthermore, when the emergency authorization policy description file read in step C is the second policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Read the pre-written emergency one-time password book from the secure storage area of ​​the edge computing node, which is generated and encrypted by the edge computing node administrator during deployment; The index offset is calculated based on the time difference between the detection timestamp of the edge mutation event and the system startup timestamp, and the entry number is obtained by performing a remainder operation on the total number of entries in the codebook. Take the password entry corresponding to the entry number from the password book and use it as the verification code of the second temporary credential; Obtain the real-time clock reading of the current edge node, round the real-time clock reading down to a preset time granularity level, and concatenate it with the verification code to form the payload of the second temporary credential. The payload is symmetrically encrypted using the hardware security module integrated within the edge node, and the resulting ciphertext serves as the main body of the second temporary credential. The validity period of the second temporary credential is set to be equal to the preset lifespan associated with the password entry retrieved from the codebook; The subject of the second temporary credential and the device serial number of the edge node are broadcast together to the kernel credential manager of the operating system, which then injects the second temporary credential into the current user session.

[0010] Furthermore, when the emergency authorization policy description file read in step C is a third policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Extract a snapshot of user behavior features saved during the last successful authentication from the trusted execution environment of the edge computing node; The last few user input operations before the current edge mutation event is triggered are compared with the user behavior feature snapshot, and the difference metric is calculated. Select the corresponding authorization strength level based on the predefined range in which the difference metric value falls; The generated third temporary credential is associated and bound with the current session identifier of the edge node, and the binding relationship is recorded in the temporary credential mapping table in memory.

[0011] Furthermore, the recovery process in step E specifically includes the following sub-steps: E1, after receiving the recovery request, verifies whether the initiator of the recovery request has recovery authority, and requires the initiator to provide the recovery verification code generated when creating the temporary identity certificate in step D; E2. If the verification code is successfully restored, check whether the validity period of the current temporary identity certificate has expired. If it has expired, proceed directly to step E5 to perform the cancellation operation. If it has not expired, proceed to step E3. E3. Based on the type of the emergency authorization policy description file read in step C, select different revocation operation sequences; E4, after completing the retraction operation sequence, performs the reconstruction of the original digital identity state, including loading the complete identity configuration file from the backup storage area of ​​the edge computing node during the most recent normal authentication, overwriting the running parameters of the current identity authentication service process one by one with the parameters in the configuration file, and reinitializing the random number seed of the identity authentication service. E5 calls the credential revocation interface provided by the edge computing node operating system, passes in the unique identifier of the temporary identity credential to be revoked, and the operating system kernel adds the temporary identity credential to the revocation list and broadcasts the revocation message to all running application processes on the same edge computing node. E6 records the complete execution trajectory of the above recovery process, appends it to the anti-tampering audit log inside the edge computing node, and hashes and locks the current tab of the audit log after writing to prevent subsequent tampering.

[0012] Furthermore, the temporary identity credential forged in step D includes at least the following data fields: The document includes the document version number, the device identifier of the document issuer, the temporary identifier of the document holder, the validity start time of the document, the validity end time of the document, the operation permission mask associated with the document, and the digital signature value of the document. The expiration time of the credential is determined by the type of the emergency authorization policy description file read in step C and the severity subclass of the edge mutation event. For the physical layer hardware mutation set, the expiration time is represented by an absolute timestamp. For the link layer communication mutation set, the expiration time is represented by a relative time offset. For the application layer behavior mutation set, the expiration time is represented by the session cycle number. The digital signature value of the credential is obtained by performing a signature operation on the concatenation result of all the aforementioned data fields using the device private key of the edge computing node. The digest algorithm used for the signature operation is consistent with the digest algorithm used by the edge computing node in normal authentication mode.

[0013] Furthermore, the method is executed within a trusted execution environment of the edge computing node, which is isolated from the main operating system of the edge computing node; The preset baseline state information in step A, the local encrypted storage policy library in step C, and the backup storage area required for the recovery process in step E are all physically located in the same secure non-volatile memory on the edge computing node. The secure non-volatile memory is exclusively accessed by the trusted execution environment. After an edge mutation event is detected in step A and before step B begins, the trusted execution environment automatically suspends all interrupt responses from the main operating system to the identity authentication service process until step E is completed or the validity period of the temporary identity credential is completely exhausted before interrupt responses can be resumed.

[0014] According to a second aspect of the present invention, the present invention claims protection for an emergency authorization and recovery system for digital identity triggered by edge mutation, comprising: One or more processors; A memory storing one or more programs that, when executed by one or more processors, enable the one or more processors to implement the aforementioned method for emergency authorization and recovery of digital identity triggered by edge mutation.

[0015] This invention discloses a method and system for emergency authorization and recovery of digital identity triggered by edge mutations, belonging to the field of edge computing and identity authentication technology. It monitors the operating environment of the identity authentication service process on edge computing nodes in real time. When an edge mutation event deviating from a preset baseline state is detected, the characteristics of the mutation trigger are extracted. Based on the category of the mutation event, a locally encrypted emergency authorization policy description file is read, and authorization actions are executed sequentially according to the operation primitive sequence defined therein. Within the validity period of the temporary credential, in response to a recovery request or timeout event, a recovery process matching the authorization policy is executed. This invention performs differentiated emergency authorization and recovery operations for different mutation triggers, without relying on cloud or centralized identity management platforms, and can quickly complete emergency switching and secure rollback of digital identity in security anomalies in edge computing environments. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the workflow of an emergency authorization and recovery method for digital identity triggered by edge mutation, as claimed in an embodiment of the present invention. Figure 2A second workflow diagram of a digital identity emergency authorization and recovery method triggered by edge mutation, as claimed in an embodiment of the present invention; Figure 3 The third flowchart is a method for emergency authorization and recovery of digital identity triggered by edge mutation, as claimed in an embodiment of the present invention. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0018] The technical solutions disclosed in the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0019] According to the first embodiment of this part, refer to Figure 1 This invention claims protection for a method for emergency authorization and recovery of digital identity triggered by edge mutation, comprising the following steps: Step A: Monitor the running environment of the identity authentication service process in real time. When an edge mutation event deviating from the preset baseline state information is detected in the running environment, extract the mutation cause feature vector carried by the edge mutation event. Step B involves inputting the mutation cause feature vector into a pre-constructed cause classification decision tree, performing step-by-step matching along the branch conditions of the decision tree, and outputting the mutation category to which the marginal mutation event belongs. Step C: Based on the mutation category, read the corresponding emergency authorization policy description file, wherein the physical layer hardware mutation set is associated with the first policy description file, the link layer communication mutation set is associated with the second policy description file, and the application layer behavior mutation set is associated with the third policy description file. Step D: Parse the read emergency authorization policy description file and execute the authorization actions in sequence according to the defined operation primitive sequence, including creating a temporary identity credential, setting the validity period of the temporary identity credential, and attaching operation permission constraints to the temporary identity credential. Step E: During the validity period of the temporary identity credential, in response to a user-triggered recovery request or a timeout event automatically determined by the system, execute the recovery process that matches the emergency authorization policy description file, including revoking the temporary identity credential, clearing the session traces associated with the temporary identity credential, and reactivating the original digital identity state.

[0020] In this embodiment, an identity authentication service process for robots on the production line runs on an edge computing node in a smart factory. This edge computing node is deployed on the factory floor, independent of the cloud or a central server. Initially, the system administrator pre-sets a set of baseline state information for the identity authentication service process. This baseline state information includes: expected hash values ​​of several platform configuration registers in the trusted platform module, a list of file hash values ​​for key service processes in the operating system, and operating mode parameters of the network interface card. The baseline state information is stored in a read-only memory within the edge computing node.

[0021] A monitoring daemon thread resides on the edge computing node. This thread reads the runtime environment information of the authentication service process every 200 milliseconds. The runtime environment information includes: the current operating mode of the CPU, the contents of the page table base address register in the memory management unit, and the current hash value stored in platform configuration register number 17 in the trusted platform module. The monitoring daemon thread compares each piece of this information with pre-saved baseline state information. If any item is found to be inconsistent with the baseline state—for example, if the current hash value of platform configuration register 17 in the trusted platform module differs from the baseline hash value—an edge mutation event is determined to have occurred. The monitoring daemon thread immediately captures this mutation event and extracts the mutation trigger feature vector. This feature vector is an ordered triple: the first component is the register number that changed; the second component is the bitwise difference length between the baseline hash value and the current hash value; and the third component is the current reading of the counter for the number of times the platform configuration register has been modified since the last successful authentication. These three components are concatenated in a fixed order to form the mutation trigger feature vector for this edge mutation event.

[0022] The aforementioned mutation cause feature vectors are input into a pre-constructed cause classification decision tree, which is stored in the secure non-volatile memory of the edge computing node and organized in a binary tree structure. The root node of the decision tree checks the difference length of the second component of the feature vector. If the difference length is less than a first threshold, it enters the left subtree, entering the physical layer hardware mutation set; if the difference length is between the first and second thresholds, it enters the middle subtree, entering the link layer communication mutation set; if the difference length is greater than the second threshold, it enters the right subtree, entering the application layer behavior mutation set. Within each subtree, the modification count counter reading of the third component of the feature vector is further checked. If the modification count counter reading is 0 or 1, it is classified into the mild subclass of that mutation set; if the reading is greater than or equal to 2, it is classified into the severe subclass. The decision tree finally outputs a four-tuple category identifier, such as physical layer hardware mutation set—severe subclass or application layer behavior mutation set—mild subclass. This category identifier is stored in a temporary variable on the edge computing node for use in subsequent steps.

[0023] The edge computing node maintains an encrypted policy library, organized as a set of key-value pairs. The key is a mutation category identifier, and the value is the corresponding emergency authorization policy description file. The entire policy library is encrypted using the edge computing node's private key and can only be decrypted and accessed within a trusted execution environment. Based on the mutation category output in step B, the system reads the corresponding policy description file from the policy library. The physical layer hardware mutation set is associated with the first policy description file, which defines a degradation authentication process dependent on the trusted platform module. The link layer communication mutation set is associated with the second policy description file, which defines an authentication process using an emergency one-time key. The application layer behavior mutation set is associated with the third policy description file, which defines an authentication process based on user behavior snapshot comparison. Each policy description file is written in a structured description language, containing a sequential list of multiple operation primitives, each with parameter placeholders.

[0024] The system parses and reads the emergency authorization policy description file, and executes authorization actions sequentially according to the sequence of operation primitives defined within it. First, it executes the primitive for creating temporary identity credentials: the system allocates a clean area in memory and generates a unique temporary identity identifier based on the credential type (symmetric or asymmetric) specified in the policy file. This identifier is composed of the current system time in milliseconds, the last 8 bits of the device serial number, and a sequentially increasing local sequence number. Next, it executes the primitive for setting the validity period: the system queries the validity period baseline value specified in the policy file, and then scales this baseline value according to the severity of the mutation category. The validity period is shortened for severe subcategories and extended for minor subcategories, ultimately obtaining a specific cutoff time, represented by the clock cycles of the real-time clock inside the edge computing node. Finally, it executes the primitive for attaching operation permission constraints: the system reads the list of allowed operations listed in the policy file, such as allowing only reading production logs or prohibiting writing control commands, encodes these allowed operations into a permission mask, and writes this mask into a specified field of the temporary identity credential.

[0025] During the validity period of the temporary identity credential, the system simultaneously monitors two types of triggering conditions. The first type is a user-triggered recovery request: when a user presses a dedicated physical recovery button on an external terminal, the edge computing node detects the button being pressed via GPIO pins, generates a hardware interrupt, and the interrupt service routine sends a recovery request signal to the identity authentication service process. The second type is a timeout event automatically determined by the system: every fixed clock tick, the system checks whether the current time has exceeded the expiration time set in step D; once the timeout condition is met, the system automatically triggers the recovery process. The recovery process includes the following steps: First, the operating system's credential management interface is invoked to add the unique identifier of the temporary identity credential to the blacklist, so that any access request using the credential is rejected. Then, all session processes associated with the temporary identity credential in the system are traversed, and a forced termination signal is sent to each process. Finally, the buffer storing the temporary identity credential in memory is cleared, and the original digital identity state is reloaded from the backup area into the identity authentication service process. The original digital identity state includes the original user identifier, the original permission mask, and the original session key material. After loading, the identity authentication service process is restored to the running state before the edge mutation event occurred.

[0026] Further, step A includes: Periodically read the hash value change counter of the trusted platform module in the edge computing node to record the number of times the platform configuration register has been modified since the last authentication; When the value of the hash value change counter increases relative to the previous reading time, an edge mutation event is determined to have occurred, and the current value of the hash value change counter is used as the unique component of the mutation cause feature vector.

[0027] In this embodiment, the trusted platform module of the edge computing node has a set of platform configuration registers built in, numbered from 0 to 23. Among them, the platform configuration register numbered 8 is specifically used to record the runtime environment hash value of the identity authentication service process. Each time a new hash value is written to this register by an expansion operation, an internal hardware counter—the hash value change counter—will automatically increment by 1. This counter is a read-only hardware register and cannot be cleared or written directly by software. It can only increment with each modification to the platform configuration register.

[0028] The edge computing node starts a timer interrupt with a period of 500 milliseconds. When each interrupt arrives, the monitoring thread performs a read operation. The read operation includes two machine instructions: the first instruction reads the current value of the platform configuration register 8, and the second instruction reads the current value of the hash value change counter. The monitoring thread maintains a variable in memory to store the value of the hash value change counter obtained during the last read. After each read, the current reading is compared with the previous reading. If the current reading is greater than the previous reading, it means that at least one modification operation of the platform configuration register 8 has occurred between the last monitoring and the current monitoring, that is, the operating environment has changed, so it is determined that an edge mutation event has occurred. At the same time, the difference between the current hash value change counter reading and the previous reading is used as the mutation intensity index of the edge mutation event. Then, the difference is used as the unique component of the mutation cause feature vector to form a one-dimensional vector. For example, if the previous reading is 5 and the current reading is 7, the difference is 2, and the feature vector is [2]. The feature vector is passed to step B for subsequent processing. If the current reading is equal to the previous reading, it is determined that no edge mutation event has occurred. The monitoring thread does not perform any subsequent operations, but only saves the current reading as the new previous reading and waits for the next timer interrupt.

[0029] This approach does not rely on any external time base or complex statistical models, but only on changes in the hardware counters within the trusted platform module to trigger the emergency authorization process, ensuring a rapid response to physical tampering and runtime abnormal modifications.

[0030] Furthermore, the cause classification decision tree in step B contains two levels of branching conditions: The first level is divided according to the numerical range of the unique component of the mutation cause feature vector. If the value falls within the first predetermined range, it is classified into the physical layer hardware mutation set; if it falls within the second predetermined range, it is classified into the link layer communication mutation set; and if it falls within the third predetermined range, it is classified into the application layer behavior mutation set. The second level further subdivides each mutation set into severe or mild subclasses based on how close the values ​​are to the interval boundaries. Values ​​that are less than a predetermined threshold from the interval boundary are classified into the mild subclass, while those that are not are classified into the severe subclass.

[0031] In this embodiment, the data for constructing the decision tree is pre-imported by the system administrator during deployment on the edge computing node, and the tree structure is stored in a secure storage area and cannot be modified online.

[0032] First-level branching condition: After receiving the mutation cause feature vector, the root node of the decision tree extracts the unique component of the vector, which is the difference in the hash value change counter. This component is a non-negative integer. The system internally predefines three non-overlapping integer intervals, denoted as interval A, interval B, and interval C. Interval A covers integers from 0 to 3, corresponding to the physical layer hardware mutation set; interval B covers integers from 4 to 10, corresponding to the link layer communication mutation set; interval C covers integers 11 and above, corresponding to the application layer behavior mutation set. The decision tree sequentially checks whether the component falls within interval A, interval B, and interval C. For example, if the difference is 2, it falls within interval A, and is directly determined to be in the physical layer hardware mutation set; if the difference is 7, it falls within interval B, and is determined to be in the link layer communication mutation set; if the difference is 15, it falls within interval C, and is determined to be in the application layer behavior mutation set. If the difference does not fall within any predefined range, for example, due to a hardware error resulting in a negative value or an overflow value, the decision tree will return a special unclassified label. At this point, the system will fall back to the most conservative emergency handling procedure to stop all identity authentication operations and require a physical restart of the edge computing node.

[0033] Second-level branching condition: After determining the mutation set to which the first level belongs, the decision tree enters the internal child nodes corresponding to that mutation set. Each internal child node is responsible for judging the severity, based on the proximity of the component value of the feature vector to the boundary of the interval where the mutation set is located. For the physical layer hardware mutation set interval A: 0-3, the system presets an internal threshold T1, with a value of 1. Calculate the distance D_left (component value - 0) between the component value and the left boundary 0 of the interval, and the distance D_right (3 - component value) between the component value and the right boundary 3 of the interval. Take the smaller of D_left and D_right. If the smaller distance is less than or equal to T1, it is classified into the mild subclass; otherwise, it is classified into the severe subclass. For example: When component 1 is present, D_left=1, D_right=2, smaller distance=1, equal to T1, classified as a minor subclass; when component 3 is present, D_left=3, D_right=0, smaller distance=0, less than T1, classified as a minor subclass; when component 2 is present, D_left=2, D_right=1, smaller distance=1, equal to T1, classified as a minor subclass; and when component 0 is present, D_left=0, D_right=3, smaller distance=0, classified as a minor subclass. In fact, the smaller distance of all values ​​within interval A is less than or equal to 1. Therefore, all cases in the physical layer mutation set are classified as minor subclasses. This means that once a physical layer mutation occurs, even a small difference is considered to require emergency handling but not necessarily to immediately cut off all services. For the link layer communication mutation set interval B: 4-10, with a preset threshold T2=2. Calculate the distance between the component value and 4 and its distance from 10, and take the smaller one. If this smaller distance is less than or equal to 2, it is classified as a minor subclass; otherwise, it is classified as a severe subclass. For example, when component 6 is 2 units away from 4 and 4 units away from 10, with a smaller distance of 2, it belongs to the mild subclass. When component 9 is 1 unit away from 10 and 5 units away from 4, with a smaller distance of 1, it belongs to the mild subclass. When component 5 is 1 unit away from 4 and 5 units away from 10, with a smaller distance of 1, it belongs to the mild subclass. When component 8 is 2 units away from 10 and 4, with a smaller distance of 2, it belongs to the mild subclass. However, when component 7 is 3 units away from 4 and 3 units away from 10, with a smaller distance of 3 greater than 2, it belongs to the severe subclass. For the application layer behavior mutation set interval C: 11 and above, the preset threshold T3=5. Calculate the distance between the component value and the left boundary 11 of the interval. If the distance is less than or equal to 5, it belongs to the mild subclass; otherwise, it belongs to the severe subclass. For example, when component 13 is 2 units away from 11, it belongs to the mild subclass; when component 18 is 7 units away, it belongs to the severe subclass. After the second-level judgment is completed, the decision tree outputs the final complete category, such as the link layer communication mutation set - severe subclass. This category will be used as the index for reading the policy description file in step C.

[0034] Furthermore, referring to Figure 2When the emergency authorization policy description file read in step C is the first policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D specifically include the following sub-steps: D1 reads a pre-stored downgraded authentication token for emergency use from the trusted platform module of the edge computing node; D2: Hash the feature information of the current edge mutation event to obtain an event digest, and then concatenate the event digest with the downgraded authentication token and hash it again to generate the basic seed of the first temporary credential. D3 calls the local pseudo-random number generator of the edge computing node to generate a random number string with a preset bit length as input to the basic seed, which serves as the main part of the first temporary certificate; D4. Obtain the system timestamp of the current edge computing node, add a predetermined emergency authorization validity period offset to the timestamp as the expiration time of the first temporary certificate. The predetermined emergency authorization validity period offset is set as the first duration offset for the physical layer severe mutation subclass and as the second duration offset for the physical layer slight mutation subclass. D5 combines the main body of the first temporary credential, the expiration time, and the device unique identifier of the edge computing node into a single package. The packaged data is then signed using the device private key in the trusted platform module to form the complete data structure of the first temporary credential. D6. Create an independent sandbox execution environment in the operating system of the edge computing node, inject the first temporary credential into the sandbox execution environment, and restrict the sandbox execution environment to access only a predefined set of emergency resources, which includes an emergency directory in the local file system and an emergency communication port in the network protocol stack. D7. Record the execution log of steps D1 to D6, append it to the read-only audit memory inside the edge computing node, and set the anti-tampering lock bit of the corresponding area of ​​the audit memory after the writing is completed.

[0035] In this embodiment, the trusted platform module of the edge computing node stores not only the device private key used for normal authentication, but also a pair of downgraded authentication keys generated in advance during the initialization phase. The private key portion of the downgraded authentication key is stored in a storage slot within the trusted platform module that can only be accessed by emergency procedures, while the public key portion is publicly stored in the ordinary storage area of ​​the edge computing node. Simultaneously, during initialization, the trusted platform module uses the device private key to sign a fixed string, and the generated signature result is called a downgraded authentication token. This token is stored in plaintext in the non-volatile memory of the trusted platform module, but cannot be read without authorization. When the system executes D1, the identity authentication service process sends a special command through the device driver interface of the trusted platform module, requesting to read the downgraded authentication token. The trusted platform module verifies the caller's identity by checking whether the caller's code hash is in the whitelist. After successful verification, the downgraded authentication token is transmitted to the caller in encrypted form. The caller decrypts the token within the trusted execution environment to obtain the plaintext downgraded authentication token.

[0036] The system obtains a complete description of the current edge mutation event, which includes: the timestamp of the mutation, the platform configuration register number that changed, the difference bit pattern between the old and new values ​​of the register, and the difference of the hash value change counter. This information is concatenated into a binary string, and then the hash function module built into the edge computing node is used to process the string to obtain a fixed-length hash output, called the event digest. Subsequently, the downgraded authentication token obtained in step D1 is concatenated with the event digest in the order of token first and digest last to form a new byte sequence. The hash function module is called again to process the byte sequence to obtain a second hash output, which is called the base seed of the first temporary credential. The base seed has a fixed length of 128 bits.

[0037] The edge computing node contains a pseudo-random number generator, which is implemented using a linear feedback shift register. However, its initial state is determined by a base seed rather than by an external input. The system writes the base seed into the pseudo-random number generator's status register and then drives the generator to run a fixed number of times, for example, 32 times. Each run generates a 32-bit random number fragment. These fragments are then concatenated in sequence to form a 128-bit random number string. This random number string is used as the main part of the first temporary credential, i.e., the core random field in the credential used to identify the holder. This field will be used by other edge nodes or other services on the same node to identify the temporary identity in subsequent authorization decisions.

[0038] The system reads the real-time clock inside the edge computing node to obtain the current absolute timestamp, which is represented by the number of seconds since the epoch. Based on the severity level determined in step B, the system selects different validity period offsets. For the severe subclass of the physical layer, the first duration offset predefined by the system is set to a shorter value corresponding to several minutes in reality; for the mild subclass of the physical layer, the second duration offset is set to a longer value corresponding to several hours in reality. The current timestamp is added to the corresponding offset to obtain the expiration time of the first temporary certificate. At the same time, the system also checks whether the expiration time exceeds the maximum emergency authorization time limit pre-configured by the edge computing node. If it exceeds, it is forcibly truncated to the maximum time limit.

[0039] The system concatenates the following three data items into a single data block: the random number string obtained in step D3 (the main body of the first temporary credential), the timestamp value obtained in step D4 (the expiration time), and the 48-bit device identifier of the edge computing node, which is burned into a one-time programmable memory by the manufacturer. These data items are arranged in a fixed order: first the main body, then the expiration time, and finally the device identifier. The system then calls the signature engine in the trusted platform module to perform a digital signature operation on this data block using the device's private key. The signature operation involves internally hashing the data block and then encrypting the hash value using the private key to obtain the final signature value. The signature value is appended to the end of the credential data structure.

[0040] The operating system of the edge computing node supports a sandbox execution environment. This sandbox is a lightweight virtualization container with an independent process space and a restricted file system view. The system creates a new sandbox instance and injects the complete first temporary credential data structure generated in step D5 as an environment variable into the sandbox's startup parameters. After the sandbox instance starts, no process within it can access files, network ports, or shared memory outside the sandbox. The system predefines a set of emergency resources, including: read-only ` / emergency / config` directory and write-only ` / emergency / log` directory in the local file system, and UDP ports 49152 to 49155 in the network protocol stack. The sandbox's network namespace is configured to only allow sending packets to these ports and only allow receiving response packets from specific MAC addresses within the same subnet. Once the sandbox instance is activated, any authentication request using the first temporary credential must be sent through the sandbox.

[0041] The system contains a read-only audit memory, modeled after a one-time programmable memory. Write operations can only append, not modify existing content. The system records key events in each step (D1 to D6) as a log entry. Each log entry includes: step number, start timestamp, end timestamp, success / failure flag, and relevant key data such as the fingerprint of the downgrade authentication token, the first 8 bits of the base seed, and the sandbox process ID. These entries are written to the audit memory sequentially. After writing, the system writes a fixed value to the corresponding control register of the audit memory, setting the lock bit of the currently written page to 1. Once the lock bit is set to 1, no byte on that page can be modified or erased unless the entire edge computing node is physically destroyed. This mechanism ensures the complete and non-repudiable audit trail of the emergency authorization process.

[0042] Furthermore, when the emergency authorization policy description file read in step C is the second policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Read the pre-written emergency one-time password book from the secure storage area of ​​the edge computing node, which is generated and encrypted by the edge computing node administrator during deployment; The index offset is calculated based on the time difference between the detection timestamp of the edge mutation event and the system startup timestamp, and the entry number is obtained by performing a remainder operation on the total number of entries in the codebook. Take the password entry corresponding to the entry number from the password book and use it as the verification code of the second temporary credential; Obtain the real-time clock reading of the current edge node, round the real-time clock reading down to a preset time granularity level, and concatenate it with the verification code to form the payload of the second temporary credential. The payload is symmetrically encrypted using the hardware security module integrated within the edge node, and the resulting ciphertext serves as the main body of the second temporary credential. The validity period of the second temporary credential is set to be equal to the preset lifespan associated with the password entry retrieved from the codebook; The subject of the second temporary credential and the device serial number of the edge node are broadcast together to the kernel credential manager of the operating system, which then injects the second temporary credential into the current user session.

[0043] In this embodiment, an emergency one-time password book is first read from the secure storage area of ​​the edge computing node. This storage area is protected by a hardware encryption engine and can only be decrypted within a trusted execution environment and under specific conditions, such as the current system time being within a preset maintenance window. This one-time password book is generated and written by the administrator when the edge computing node is deployed. The generation process is as follows: the administrator generates a random seed on an offline device, uses this seed to expand 1000 password entries, each 16 bytes long, and then encrypts them using a public key before transmitting them to the edge computing node. The edge computing node decrypts them using its device private key and stores them in the secure storage area. Each password entry is logically associated with a preset lifespan, for example, the first 200 entries are associated with 10 minutes, the middle 500 entries with 30 minutes, and the last 300 entries with 60 minutes. These associations are encoded in a hidden field in the password book.

[0044] The detection timestamp of the edge mutation event (the moment the monitoring thread first detected the link anomaly) and the system startup timestamp of the edge computing node (the moment of the last cold start) are obtained. The time difference between the two is calculated to obtain an integer in milliseconds. This integer is divided by the total number of password entries in the codebook, and the remainder is taken to obtain a sequence number between 0 and 999. This sequence number is used as the entry number for this operation.

[0045] Based on the calculated entry number, the corresponding password entry is retrieved from the codebook. This password entry is a 16-byte random string. This 16-byte string is used as the checksum of the second temporary credential. Then, the real-time clock reading of the edge node is obtained, and the reading is in milliseconds. An internal time granularity level is preset, such as 30 seconds. The real-time clock reading is divided by the number of milliseconds corresponding to 30 seconds, and the remainder is discarded to obtain an integer quotient. This integer quotient is concatenated with the aforementioned 16-byte checksum. The concatenation method is as follows: the integer quotient is first converted to a 4-byte big-endian representation, and then concatenated with the 16-byte checksum to form a 20-byte payload.

[0046] The edge node's integrated hardware security module is invoked. This security module is an independent coprocessor that stores the device's root key, which is written during chip manufacturing and cannot be exported. An encryption request is sent to the hardware security module, carrying the aforementioned 20-byte payload and specifying the use of the AES symmetric encryption algorithm. This is merely an example encryption method name and does not constitute a specific algorithm-defined electronic codebook mode. The hardware security module uses its internal root key to encrypt the payload and outputs 20 bytes of ciphertext, which serves as the body of the second temporary credential.

[0047] This function queries the preset expiration time associated with a password entry retrieved from the password book. For example, if the retrieved entry number is 150, belonging to the first 200 entries, the preset expiration time is the number of milliseconds corresponding to 10 minutes. This expiration time is used as the validity period of the second temporary credential. Unlike an absolute expiration time, this validity period is a relative value, indicating to the kernel credential manager that the credential will automatically expire after this time following the injection session.

[0048] Finally, the 20-byte ciphertext of the second temporary credential is concatenated with the edge computing node's device serial number—a unique number stored in a one-time programmable register—to form a message. This message is sent to the kernel credential manager via a high-privilege call within the operating system, similar to a system call but bypassing regular permission checks. The kernel credential manager, running in kernel mode, receives the message, parses out the credential body and device serial number, verifies the serial number's match with the local machine, and then injects the second temporary credential into the user session currently initiating the authentication request. The injection method involves adding a field to the kernel-maintained session structure to store a copy of the credential body and starting a timer with a timeout period set in the previous steps. After the timer expires, the kernel automatically clears this field.

[0049] Furthermore, when the emergency authorization policy description file read in step C is a third policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Extract a snapshot of user behavior features saved during the last successful authentication from the trusted execution environment of the edge computing node; The last few user input operations before the current edge mutation event is triggered are compared with the user behavior feature snapshot, and the difference metric is calculated. Select the corresponding authorization strength level based on the predefined range in which the difference metric value falls; The generated third temporary credential is associated and bound with the current session identifier of the edge node, and the binding relationship is recorded in the temporary credential mapping table in memory.

[0050] In this embodiment, a snapshot of user behavior features saved during the last successful authentication is extracted from the trusted execution environment (TEX) of the edge computing node. The snapshot is generated as follows: after the user's last successful login via normal authentication, the system silently records the intervals between the user's previous 100 keystrokes (milliseconds between each keystroke) and a compressed fingerprint of the mouse movement trajectory. The compressed fingerprint is generated by dividing the mouse movement trajectory into a 16×16 grid on a two-dimensional plane, recording the order in which each grid is traversed to form a sequence, and then performing run-length encoding on this sequence to obtain a compressed, compact representation. The snapshot is stored in a protected memory area of ​​the TEX, accessible only to the authentication service process.

[0051] The system acquires the last few user input operations before the current edge mutation event is triggered. Specifically, the input sub-operations maintain a circular buffer, storing the most recent 20 keyboard and mouse events. From this buffer, the intervals of the last 10 keystrokes and the movement of the last mouse trajectory within the last 5 seconds are extracted. These real-time data are processed into a real-time behavioral feature description using a keystroke interval sequence and a grid sequence in the same format. This real-time behavioral feature description is then compared with the features saved in the snapshot. The comparison process does not calculate any mathematical distance but compares each item: for keystroke intervals, it checks whether each value in the real-time interval falls within the allowable fluctuation range of the corresponding value in the snapshot. The allowable fluctuation range is preset to a relative proportion, such as 80% to 120% of the snapshot value; for mouse trajectories, it checks whether the run-length encoded grid sequence is a subsequence of the sequence in the snapshot, allowing for the insertion of a small number of extra grids. The number of mismatches is counted, resulting in a mismatch count. This mismatch count is divided by the total number of comparison items to obtain a ratio value, internally called the difference metric.

[0052] Three predefined intervals are preset: the low difference interval corresponds to a difference metric value less than or equal to 0.15, the medium difference interval corresponds to a difference metric value greater than 0.15 and less than or equal to 0.45, and the high difference interval corresponds to a difference metric value greater than 0.45. The corresponding authorization intensity level is selected based on which interval the difference metric value falls into.

[0053] If the user is in a low-difference range, their current behavior is considered highly consistent with normal patterns. Although an application-layer mutation event has been triggered, it may be a false alarm. In this case, the original identity credentials generated during the last successful authentication are directly reused. The complete data structure of the original identity credentials is read from the persistent storage area of ​​the trusted execution environment and passed to the current session as is, without modifying any attributes, including the original expiration date, permission mask, and session key.

[0054] If the value falls within the medium-difference range, indicating a certain degree of anomaly but not yet reaching a dangerous level, a new third temporary credential is generated. The process involves copying the main body of the original identity credential, but modifying its validity period field to be shorter than the remaining validity period of the original identity credential. Specifically, the time between the current time of the original identity credential's remaining validity period and its original expiration time is calculated, and one-third of this time is taken as the new validity period of the third temporary credential. Simultaneously, all write operation flags are cleared from the permission mask, retaining only the read operation flag, thus implementing read-only access restriction.

[0055] If the user's behavior falls within a high-discrepancy range, it is considered a significant deviation from normal patterns. However, extremely short-term emergency operations are still permitted, and a third temporary credential is generated. Its validity period is set to a predefined, extremely short time window, initialized to a very small fixed duration corresponding to a few seconds in reality. Furthermore, a flag is added to the additional data field of the third temporary credential, requiring the user to enter a predetermined number of correct static passwords consecutively after obtaining the credential before performing any subsequent operations. The predetermined number of attempts is set to three; this means that even with the credential in hand, the user still needs to provide three additional correct static passwords within a very short period to actually perform any operation requiring the credential.

[0056] Regardless of the strength level, the generated third temporary credential will ultimately be associated and bound to the current session identifier of the edge node. The current session identifier is a unique integer assigned to each login session. The binding relationship is recorded in a temporary credential mapping table in memory. This mapping table is maintained by the kernel and is a simple set of key-value pairs: the key is the session identifier, and the value is the complete data structure of the temporary credential. The mapping table is not written to any disk, flash memory, or non-volatile storage media, and all binding relationships are automatically lost upon power failure.

[0057] Furthermore, referring to Figure 3 The recovery process in step E specifically includes the following sub-steps: E1, after receiving the recovery request, verifies whether the initiator of the recovery request has recovery authority, and requires the initiator to provide the recovery verification code generated when creating the temporary identity certificate in step D; E2. If the verification code is successfully restored, check whether the validity period of the current temporary identity certificate has expired. If it has expired, proceed directly to step E5 to perform the cancellation operation. If it has not expired, proceed to step E3. E3. Based on the type of the emergency authorization policy description file read in step C, select different revocation operation sequences; E4, after completing the retraction operation sequence, performs the reconstruction of the original digital identity state, including loading the complete identity configuration file from the backup storage area of ​​the edge computing node during the most recent normal authentication, overwriting the running parameters of the current identity authentication service process one by one with the parameters in the configuration file, and reinitializing the random number seed of the identity authentication service. E5 calls the credential revocation interface provided by the edge computing node operating system, passes in the unique identifier of the temporary identity credential to be revoked, and the operating system kernel adds the temporary identity credential to the revocation list and broadcasts the revocation message to all running application processes on the same edge computing node. E6 records the complete execution trajectory of the above recovery process, appends it to the anti-tampering audit log inside the edge computing node, and hashes and locks the current tab of the audit log after writing to prevent subsequent tampering.

[0058] In this embodiment, the user initiates a recovery request on an external terminal, for example, by pressing a physical recovery button or entering a specific recovery command in the command line. Upon receiving the request, the system verifies whether the initiator has recovery permissions. The core of the verification is based on the recovery verification code generated when the temporary identity credential is forged. Under different strategies, the recovery verification code is generated in different ways: For the physical layer of the first strategy description file, the recovery verification code is a 6-digit number string generated separately at the same time as the basic seed is generated in step D2. This number string is presented to the on-site maintenance personnel at once through a small display screen on the front panel of the edge computing node; for the link layer of the second strategy description file, the recovery verification code is a combination of the index number of the password entry and the last two bytes of the checksum, which is also displayed when the credential is forged; for the application layer of the third strategy description file, the recovery verification code is a partial digest value of the user's behavioral feature snapshot, which the user needs to enter when initiating a recovery request. The string entered by the user is compared byte by byte with the original recovery verification code stored internally. If they are completely consistent, the verification is successful; if they are inconsistent, a failed verification attempt is recorded. If three consecutive attempts fail, the recovery interface is temporarily locked for a period of time.

[0059] After successful verification, the current real-time clock value is read and compared with the expiration time of the temporary identity credential. The expiration time has already been stored in a specific field of the credential data structure in step D. The difference between the current time and the expiration time is calculated. If the difference is greater than or equal to 0, it means the validity period has expired; if the difference is less than 0, it means it has not expired. If it has expired, steps E3 and E4 are skipped, and the process proceeds directly to step E5 to perform the cancellation operation. If it has not expired, step E3 is executed.

[0060] Based on the type of the emergency authorization policy description file read in step C, select different revocation operation sequences.

[0061] For the first policy description file: the revocation operation sequence includes three actions; the first action: call the sandbox management interface, send a SIGTERM signal to the sandbox process created in step D6, wait for the sandbox process to exit, and then send a SIGKILL signal to forcibly terminate the remaining process; the second action: traverse the temporary files mounted by the sandbox instance and delete all files and directories therein; the third action: access the non-volatile storage slot in the trusted platform module, and rewrite the status byte of the downgraded authentication token stored there from unused to used. Once marked as used, the token cannot be used again in any authorization process.

[0062] For the second policy description file: the revocation operation sequence includes three actions; the first action: sending a deregistration command to the kernel credential manager, carrying the ciphertext of the second temporary credential. The kernel credential manager searches for this ciphertext in the credential list in memory, and if found, removes it from the list; the second action: clearing the broadcast queue. At the end of step D, the second temporary credential was broadcast to the kernel credential manager, and there may be a backlog of unprocessed credentials in the broadcast queue. The kernel interface is called to clear all pending credential entries in the broadcast queue; the third action: resetting the used count of the emergency one-time cipherbook. The cipherbook internally maintains a pointer indicating which entry should be used next. During authorization, this pointer moves forward; during recovery, the pointer needs to be rolled back to the value before authorization, and the used count field is decremented by 1. If it reaches a negative number, it is set to 0.

[0063] For the third policy description file: the revocation operation sequence includes three actions; the first action: unbind the third temporary credential from the current session identifier, traverse the temporary credential mapping table, find the entry corresponding to the session identifier, and set the credential field in that entry to null; the second action: delete the temporary credential mapping table entry in memory. That is, directly remove the entry from the mapping table; the third action: restore the original baseline value of the user behavior feature snapshot. During the authorization process, the baseline value may be temporarily adjusted due to a high difference metric value, such as including abnormal behavior in the baseline. During recovery, the original snapshot from the last normal authentication needs to be reloaded from the backup storage, overwriting any potentially corrupted snapshots.

[0064] After completing the revocation sequence, the original digital identity state is reconstructed. The reconstruction process includes the following operations: The complete identity configuration file from the most recent successful authentication is loaded from the backup storage area of ​​the edge computing node. This backup storage area is a read-only flash partition that stores several parameters, including the user identifier (UID), group identifier (GID), home directory path, authorization policy ID, and session key seed. These parameters are read into memory one by one, and then each parameter overwrites the corresponding runtime parameters in the current identity authentication service process. After overwriting, the random number seed in the identity authentication service is reinitialized. This seed is a mixture of the current clock count, the current value of the platform configuration register, and the output of a hardware noise source. After reinitialization, the identity authentication service is restored to a state capable of handling normal authentication requests.

[0065] The kernel calls the credential revocation interface provided by the edge computing node operation. This interface is a kernel call that takes the unique identifier of the temporary identity credential as its parameter. After receiving the revocation request, the kernel adds the identifier to a black linked list called the "revocation list." Thereafter, any access request carrying this identifier will be directly rejected during the permission check phase. Simultaneously, the kernel broadcasts a message to all running application processes on the same edge computing node through its internal inter-process communication mechanism. The message states that the credential identifier XXXX has been revoked. Upon receiving the broadcast, each application process will proactively clear any state corresponding to this credential from its internal cache to avoid further use.

[0066] The complete execution trajectory of the above recovery process is recorded for subsequent auditing. The recorded information includes: the time the recovery request was received (represented by a real-time clock counter), the success or failure of the recovery verification code, the number of failures, the type of the reversal operation sequence (physical layer, link layer, or application layer), and the timestamp of the original identity state reconstruction. This information is formatted into a fixed-length record, and then the anti-tampering audit log write interface is called. This audit log is organized in log blocks, each block being a fixed 512 bytes. After a block is filled, its content is hashed, and the hash value is stored in the header of the next block. When writing a new record, the hash value of the last block is checked against the expected value; only if they match is writing allowed, thus forming a hash chain to prevent modification of already written logs. After writing is complete, the write pointer is moved to a new block, ready for the next write.

[0067] Furthermore, the temporary identity credential forged in step D includes at least the following data fields: The document includes the document version number, the device identifier of the document issuer, the temporary identifier of the document holder, the validity start time of the document, the validity end time of the document, the operation permission mask associated with the document, and the digital signature value of the document. The expiration time of the credential is determined by the type of the emergency authorization policy description file read in step C and the severity subclass of the edge mutation event. For the physical layer hardware mutation set, the expiration time is represented by an absolute timestamp. For the link layer communication mutation set, the expiration time is represented by a relative time offset. For the application layer behavior mutation set, the expiration time is represented by the session cycle number. The digital signature value of the credential is obtained by performing a signature operation on the concatenation result of all the aforementioned data fields using the device private key of the edge computing node. The digest algorithm used for the signature operation is consistent with the digest algorithm used by the edge computing node in normal authentication mode.

[0068] In this embodiment, the temporary identity credential is constructed as a data structure with a fixed format and stored contiguously in memory. This data structure contains the following seven fields, arranged in order: The credential version number field occupies 2 bytes. Its value is determined by the firmware version of the edge computing node. Whenever there is a major update to the emergency authorization policy, the version number is incremented. The current version number is hard-coded in the read-only area of ​​the trusted execution environment. When the credential is created, the version number is directly copied from this read-only area to the corresponding position on the credential.

[0069] The device identifier field of the credential issuer occupies 6 bytes. This identifier comes from the one-time programmable memory burned during the manufacturing of the edge computing node and cannot be changed. When the credential is forged, this identifier is copied into the credential through a direct memory read instruction. This field is used by the verifier receiving the credential to confirm that the credential does indeed come from this node and is not forged by other malicious nodes.

[0070] The credential holder's temporary identifier field occupies 16 bytes. This temporary identifier is generated in step D according to different policies. For example, under the physical layer policy, it is a 128-bit random number string generated by a pseudo-random number generator; under the link layer policy, it is the first 16 bytes of a 20-byte ciphertext; under the application layer policy, it is part of a compressed fingerprint of a snapshot of user behavior characteristics. This field uniquely identifies the user or process that has obtained emergency authorization and ensures global uniqueness during its validity period.

[0071] The valid start time field for credentials occupies 8 bytes. This field stores an absolute timestamp indicating when the credential becomes effective. In most cases, the valid start time is set to the current time when the credential is minted. However, when there is a large deviation between the real-time clock of the edge computing node and the trusted time source, it is allowed to set the valid start time to the last successful authentication time, thereby ensuring that the credential becomes effective no earlier than the user's actual login time.

[0072] The credential expiration time field occupies 8 bytes, and its storage format varies depending on the policy type. For physical layer hardware mutation sets, the expiration time is stored as an absolute timestamp with the same time base as the start time, directly compared with the current real-time clock. For link layer communication mutation sets, the expiration time is not stored as an absolute time, but rather as a relative time offset in milliseconds, indicating how many milliseconds have elapsed since the credential became effective before it expires. For application layer behavioral mutation sets, the expiration time stores a session cycle number, which is an internally maintained incrementing counter that increments after each complete user login and logout. During credential verification, the current session cycle number is compared with the number in the credential; if the current number is greater than the credential number, the credential expires.

[0073] The operation permission mask field associated with the credential occupies 4 bytes, totaling 32 bits. Each bit represents the authorization status of a specific operation; bit 0 set to 1 indicates that reading logs is allowed; bit 1 set to 1 indicates that writing configuration parameters is allowed; bit 2 set to 1 indicates that firmware upgrades are allowed; bit 3 set to 1 indicates that access to the debug interface is allowed; the remaining bits are reserved for future expansion. When the credential is minted, these bits are set to the corresponding values ​​according to the operation permission list defined in the policy description file. Bits without explicit authorization are always set to 0.

[0074] The digital signature value field of the credential occupies 64 bytes. The signature value is generated as follows: the byte contents of the aforementioned six fields are concatenated into a long byte string in the order of version number, issuer identifier, holder identifier, start time, end time, and permission mask. Then, the edge computing node's device private key is used to perform a digital signature operation on this byte string. The signature operation is completed by calling the hardware signature engine in the trusted platform module. After receiving the byte string and the private key handle, the engine internally generates a signature result according to a predetermined digest algorithm and signature algorithm. The engine outputs the result as a signature value of exactly 64 bytes. This signature value is filled into the last field of the credential. When verifying the credential, the verifier uses the device's public key to recalculate the signatures of all fields except the signature value and compares them with the signature value in the credential. If they match, it proves that the credential originates from a legitimate device and has not been tampered with.

[0075] Once the temporary identity credential is forged, it is copied to a protected kernel memory area. Ordinary user-mode processes cannot access it directly; they can only query or use the credential through authorized call requests.

[0076] Furthermore, the method is executed within a trusted execution environment of the edge computing node, which is isolated from the main operating system of the edge computing node; The preset baseline state information in step A, the local encrypted storage policy library in step C, and the backup storage area required for the recovery process in step E are all physically located in the same secure non-volatile memory on the edge computing node. The secure non-volatile memory is exclusively accessed by the trusted execution environment. After an edge mutation event is detected in step A and before step B begins, the trusted execution environment automatically suspends all interrupt responses from the main operating system to the identity authentication service process until step E is completed or the validity period of the temporary identity credential is completely exhausted before interrupt responses can be resumed.

[0077] In this embodiment, upon startup of the edge computing node, the firmware first initializes an independent trusted execution environment (TEE). This environment is created based on hardware-assisted virtualization (HAL) technology, possessing its own address space and register context, and runs on the same physical CPU as the main operation but at a different virtual machine monitor layer. The main operation cannot directly access the TEE's memory region; any cross-domain access will be captured by the hardware and trigger a security exception. The TEE runs a minimalist operating kernel containing only basic task scheduling, memory allocation, and encryption services, without any network protocol stack code, Ethernet drivers, or wireless communication drivers. This means the TEE cannot exchange data with external cloud servers or centralized identity management platforms through any network interface. All sensitive operations related to identity authentication, including all judgments from steps A to E, reading the policy library, forging credentials, and restoring identity, are completed within this isolated environment.

[0078] The preset baseline state information mentioned in step A is stored in a special physical memory area, which is hardware-configured to allow access only by the Trusted Execution Environment (TEE). This area is physically located on the same secure non-volatile memory chip on the motherboard of the edge computing node. This chip also houses the local encrypted storage policy library from step C, as well as the backup storage area required for the recovery process in step E. This secure non-volatile memory is connected to the CPU via a dedicated bus equipped with an encryption engine, ensuring that any eavesdropping on the bus will not yield plaintext data. The TEE has exclusive access to this memory; the main operation cannot directly read or write its contents under any circumstances, and can only perform a very limited number of query operations through a controlled interface provided by the TEE.

[0079] After a precipitous event is detected in step A and before step B begins, the monitoring logic within the Trusted Execution Environment (TEE) automatically performs the following operations: It sends a mask to the CPU's interrupt controller, which masks all external interrupts from the main operation, including timer interrupts, disk interrupts, and network card interrupts, while retaining internal interrupts from the TEE itself. This means that once the main operation detects a precipitous event, its subsequent execution flow is completely suspended, unable to respond to any peripheral requests or execute any user processes. Simultaneously, the TEE takes over control of the CPU and begins executing steps B, C, D, and E. During the entire emergency authorization and recovery process, the main operation is essentially frozen until one of the following two conditions is met, at which point the TEE will resume interrupt response: Condition 1: Step E is completed, meaning the entire recovery process is finished, the original digital identity state has been rebuilt, the temporary identity credential has been revoked or expired normally, and all reversal operation sequences have been executed. At this point, the trusted execution environment writes another mask to the interrupt controller, removing the previous mask and allowing the main operation to resume normal operation.

[0080] Condition 2: The temporary identity credential expires completely, and no user initiates a recovery request, or the recovery request consistently fails verification. When the internal time monitor detects that the current time has exceeded the credential's expiration time, the trusted execution environment automatically executes a minimal cleanup process to invalidate the credential, clear the temporary buffer, and then restores the interrupt response to the main operation.

[0081] Before the interrupt response is restored, no process in the main operation is aware of the events occurring within the trusted execution environment. They only observe a brief time standstill; although the hardware clock is still running, the software-level interrupt loss causes process scheduling to pause. This design ensures that during the most sensitive permission changes, there is no possibility of interference or malicious code injection from the main operation. Even if the main operation has been completely controlled by an attacker, because its interrupts are shielded, the attacker cannot interrupt or interfere with the emergency authorization and recovery process in the trusted execution environment. Only after the old and new identity states have been switched can the main operation regain control, thus guaranteeing the security of the emergency digital identity processing.

[0082] According to a second embodiment of the present invention, the present invention claims protection for an emergency authorization and recovery system for digital identity triggered by edge mutation, comprising: One or more processors; A memory storing one or more programs that, when executed by one or more processors, enable the one or more processors to implement the aforementioned method for emergency authorization and recovery of digital identity triggered by edge mutation.

[0083] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A method for edge mutation triggered digital identity emergency authorization and recovery, characterized in that, Includes the following steps: Step A: Monitor the running environment of the identity authentication service process in real time. When an edge mutation event deviating from the preset baseline state information is detected in the running environment, extract the mutation cause feature vector carried by the edge mutation event. Step B involves inputting the mutation cause feature vector into a pre-constructed cause classification decision tree, performing step-by-step matching along the branch conditions of the decision tree, and outputting the mutation category to which the marginal mutation event belongs. The cause classification decision tree in Step B contains two levels of branch conditions: the first level divides three mutation sets, namely the physical layer hardware mutation set, the link layer communication mutation set, and the application layer behavior mutation set; the second level divides the severity within each mutation set. Step C: Based on the mutation category, read the corresponding emergency authorization policy description file, wherein the physical layer hardware mutation set is associated with the first policy description file, the link layer communication mutation set is associated with the second policy description file, and the application layer behavior mutation set is associated with the third policy description file. Step D: Parse the read emergency authorization policy description file and execute the authorization actions in sequence according to the defined operation primitive sequence, including creating a temporary identity credential, setting the validity period of the temporary identity credential, and attaching operation permission constraints to the temporary identity credential. Step E: During the validity period of the temporary identity credential, in response to a user-triggered recovery request or a timeout event automatically determined by the system, execute the recovery process that matches the emergency authorization policy description file, including revoking the temporary identity credential, clearing the session traces associated with the temporary identity credential, and reactivating the original digital identity state.

2. The method of claim 1, wherein, Step A includes: Periodically read the hash value change counter of the trusted platform module in the edge computing node to record the number of times the platform configuration register has been modified since the last authentication; When the value of the hash value change counter increases relative to the previous reading time, an edge mutation event is determined to have occurred, and the current value of the hash value change counter is used as the unique component of the mutation cause feature vector.

3. The method of claim 2, wherein, The cause classification decision tree in step B contains two levels of branching conditions: The first level is divided according to the numerical range of the unique component of the mutation cause feature vector. If the value falls within the first predetermined range, it is classified into the physical layer hardware mutation set; if it falls within the second predetermined range, it is classified into the link layer communication mutation set; and if it falls within the third predetermined range, it is classified into the application layer behavior mutation set. The second level further subdivides each mutation set into severe or mild subclasses based on how close the values ​​are to the interval boundaries. Values ​​that are less than a predetermined threshold from the interval boundary are classified into the mild subclass, while those that are not are classified into the severe subclass.

4. The method of claim 1, wherein, When the emergency authorization policy description file read in step C is the first policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D specifically include the following sub-steps: D1 reads a pre-stored downgraded authentication token for emergency use from the trusted platform module of the edge computing node; D2: Hash the feature information of the current edge mutation event to obtain an event digest, and then concatenate the event digest with the downgraded authentication token and hash it again to generate the basic seed of the first temporary credential. D3 calls the local pseudo-random number generator of the edge computing node to generate a random number string with a preset bit length as input to the basic seed, which serves as the main part of the first temporary certificate; D4. Obtain the system timestamp of the current edge computing node, and add the predetermined emergency authorization validity period offset to the timestamp as the expiration time of the first temporary certificate; D5 combines the main body of the first temporary credential, the expiration time, and the device unique identifier of the edge computing node into a single package. The packaged data is then signed using the device private key in the trusted platform module to form the complete data structure of the first temporary credential. D6. Create an independent sandbox execution environment in the operating system of the edge computing node, inject the first temporary credential into the sandbox execution environment, and restrict the sandbox execution environment to access only a predefined set of emergency resources, which includes an emergency directory in the local file system and an emergency communication port in the network protocol stack. D7. Record the execution log of steps D1 to D6, append it to the read-only audit memory inside the edge computing node, and set the anti-tampering lock bit of the corresponding area of ​​the audit memory after the writing is completed.

5. The method of claim 1, wherein, When the emergency authorization policy description file read in step C is the second policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Read the pre-written emergency one-time password book from the secure storage area of ​​the edge computing node, which is generated and encrypted by the edge computing node administrator during deployment; The index offset is calculated based on the time difference between the detection timestamp of the edge mutation event and the system startup timestamp, and the time difference is used to perform a remainder operation on the total number of entries in the codebook to obtain the entry number. Take the password entry corresponding to the entry number from the password book and use it as the verification code of the second temporary credential; Obtain the real-time clock reading of the current edge node, round the real-time clock reading down to a preset time granularity level, and concatenate it with the verification code to form the payload of the second temporary credential. The payload is symmetrically encrypted using the hardware security module integrated within the edge node, and the resulting ciphertext serves as the main body of the second temporary credential. The validity period of the second temporary credential is set to be equal to the preset lifespan associated with the password entry retrieved from the codebook; The subject of the second temporary credential and the device serial number of the edge node are broadcast together to the kernel credential manager of the operating system, which then injects the second temporary credential into the current user session.

6. The method of claim 1, wherein, When the emergency authorization policy description file read in step C is the third policy description file, the authorization actions executed sequentially according to the operation primitive sequence in step D include: Extract a snapshot of user behavior features saved during the last successful authentication from the trusted execution environment of the edge computing node; The last few user input operations before the current edge mutation event is triggered are compared with the user behavior feature snapshot, and the difference metric is calculated. Select the corresponding authorization strength level based on the predefined range in which the difference metric value falls; The generated third temporary credential is associated and bound with the current session identifier of the edge node, and the binding relationship is recorded in the temporary credential mapping table in memory.

7. The method of claim 1, wherein, The recovery process in step E specifically includes the following sub-steps: E1, after receiving the recovery request, verifies whether the initiator of the recovery request has recovery authority, and requires the initiator to provide the recovery verification code generated when creating the temporary identity certificate in step D; E2. If the verification code is successfully restored, check whether the validity period of the current temporary identity certificate has expired. If it has expired, proceed directly to step E5 to perform the cancellation operation. If it has not expired, proceed to step E3. E3. Based on the type of the emergency authorization policy description file read in step C, select different revocation operation sequences; E4, after completing the retraction operation sequence, performs the reconstruction of the original digital identity state, including loading the complete identity configuration file from the backup storage area of ​​the edge computing node during the most recent normal authentication, overwriting the running parameters of the current identity authentication service process one by one with the parameters in the configuration file, and reinitializing the random number seed of the identity authentication service. E5 calls the credential revocation interface provided by the edge computing node operating system, passes in the unique identifier of the temporary identity credential to be revoked, and the operating system kernel adds the temporary identity credential to the revocation list and broadcasts the revocation message to all running application processes on the same edge computing node. E6 records the complete execution trajectory of the above recovery process, appends it to the anti-tampering audit log inside the edge computing node, and hashes and locks the current tab of the audit log after writing to prevent subsequent tampering.

8. The method according to claim 1, characterized in that, The temporary identity credential forged in step D contains at least the following data fields: The document includes the document version number, the device identifier of the document issuer, the temporary identifier of the document holder, the validity start time of the document, the validity end time of the document, the operation permission mask associated with the document, and the digital signature value of the document. The expiration time of the credential is determined by the type of the emergency authorization policy description file read in step C and the severity subclass of the edge mutation event. For the physical layer hardware mutation set, the expiration time is represented by an absolute timestamp. For the link layer communication mutation set, the expiration time is represented by a relative time offset. For the application layer behavior mutation set, the expiration time is represented by the session cycle number. The digital signature value of the credential is obtained by performing a signature operation on the concatenation result of all the aforementioned data fields using the device private key of the edge computing node. The digest algorithm used for the signature operation is consistent with the digest algorithm used by the edge computing node in normal authentication mode.

9. The method according to claim 1, characterized in that, The method is executed within a trusted execution environment on the edge computing node, which is isolated from the main operating system of the edge computing node. The preset baseline state information in step A, the local encrypted storage policy library in step C, and the backup storage area required for the recovery process in step E are all physically located in the same secure non-volatile memory on the edge computing node. The secure non-volatile memory is exclusively accessed by the trusted execution environment. After an edge mutation event is detected in step A and before step B begins, the trusted execution environment automatically suspends all interrupt responses from the main operating system to the identity authentication service process until step E is completed or the validity period of the temporary identity credential is completely exhausted before interrupt responses can be resumed.

10. A digital identity emergency authorization and recovery system triggered by edge mutation, characterized in that, include: One or more processors; A memory having stored one or more programs that, when executed by one or more processors, cause the one or more processors to implement a method for emergency authorization and recovery of digital identity triggered by edge mutation as described in any one of claims 1 to 9.

Images