Low-altitude intelligent networking non-central cross-domain authentication architecture based on puf and zero-knowledge proof

Abstract

The application relates to the technical field of information security, and discloses a low-altitude intelligent networking centerless cross-domain authentication architecture based on PUF and zero-knowledge proof, which comprises an authentication node layer, a cross-domain cooperation layer and a data storage layer, and a five-stage cross-domain authentication method is proposed according to the authentication architecture layer, which comprises node registration, cross-domain credential generation, zero-knowledge proof construction, cross-domain verification and abnormal backtracking. By fusing PUF hardware features, non-interactive Schnorr zero-knowledge proof, elliptic curve algorithm and one-way hash, the centerless distributed architecture and two-factor authentication logic are adopted to effectively resist replay, forgery, side channel and man-in-the-middle attacks, and support quick resetting of lost credentials and accurate tracing of malicious nodes. Finally, the authentication method of the architecture is proved to be safe by an AVISPA tool, and the application has the advantages of small key size, low calculation cost and small storage requirement, and can be safely applied to low-altitude intelligent networking cross-domain communication scenes such as low-altitude logistics, emergency rescue, city inspection and agricultural plant protection.

Description

Technical Field

[0001] This invention relates to the field of information security technology, specifically to a decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof. Background Technology

[0002] As a core infrastructure of the low-altitude economy, the Low-Altitude Intelligent Network (LAI) deeply integrates manned and unmanned low-altitude platforms with ground support networks, constructing a human-machine-thing triadic intelligent interconnected system. It is widely used in low-altitude logistics, emergency rescue, urban patrol, and agricultural and forestry plant protection. With the rapid development of the low-altitude economy, the LAI network scale continues to expand, and the demand for cross-domain communication is increasing. Nodes in different airspaces and management domains require secure and efficient identity authentication to ensure the security and reliability of cross-domain communication. Nodes in the LAI (such as unmanned aerial vehicles) are mostly resource-constrained terminals. Compared with traditional servers or computers, they have significant limitations in storage capacity, computing power, and battery power. They are also more mobile, have more complex network layers, and multiple security domains coexist, making them unsuitable for deploying identity authentication protocols with high computational overhead and resource requirements. Simultaneously, these nodes need to process sensitive information such as flight trajectories and payload data, placing higher demands on the security and privacy protection of identity authentication.

[0003] The existing cross-domain authentication technology for low-altitude intelligent networks has the following shortcomings: (1) It relies on a central authentication authority, which poses a single point of failure risk, and the central node is easily targeted by attacks, leading to the paralysis of the entire authentication system; at the same time, the centralized architecture is difficult to adapt to the high dynamic topology and wide-area collaborative characteristics of low-altitude networks. (2) Sensitive information of nodes is easily leaked during the identity authentication process, which may lead to privacy leaks and data sovereignty security issues, especially since the high-definition camera equipment and trajectory information carried by low-altitude aircraft may involve sensitive area data. (3) The traditional encryption authentication mechanism has a large computational and communication overhead, which is not suitable for resource-constrained devices such as drones. (4) It has insufficient anti-attack capabilities and is difficult to resist typical malicious attacks in low-altitude intelligent networks, including GPS spoofing attacks and interference attacks at the perception layer, replay attacks, man-in-the-middle attacks, and wormhole attacks at the network layer, as well as malware injection and firmware vulnerability exploitation at the application layer. (5) It lacks a sound credential management and anomaly tracing mechanism, and it is difficult to quickly reset node credentials after they are lost, making it difficult to accurately locate and deal with malicious nodes.

[0004] Physically unclonable functions (PUFs) leverage minute differences in the hardware manufacturing process to generate unique and stable response values, possessing hardware-level identity characteristics and effectively resisting device forgery, cloning attacks, and hardware Trojan attacks. Zero-knowledge proof technology can prove the truth of a statement without disclosing sensitive information, providing strong support for privacy protection. Elliptic curve algorithms and one-way hash algorithms have the characteristics of low computational overhead and small key size, making them suitable for resource-constrained scenarios. Combining the above technologies to build a decentralized cross-domain authentication architecture can effectively solve the aforementioned shortcomings of existing technologies. Summary of the Invention

[0005] (a) Technical problems to be solved

[0006] To address the shortcomings of existing technologies, this invention provides a decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proofs. It has the advantages of small key size, decentralized architecture, strong privacy protection, high resistance to attacks, low computational overhead and low storage requirements. It solves the problems in existing technologies, such as single point of failure and incompatibility with high dynamics caused by centralized architecture, privacy leakage in the authentication process, high computational and storage overhead of traditional encryption mechanisms making them unsuitable for resource-constrained nodes, difficulty in resisting typical attacks of low-altitude intelligent networks, and lack of fast credential reset and accurate tracking of malicious nodes.

[0007] (II) Technical Solution

[0008] To achieve the above objectives, the present invention provides the following technical solution: a decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof, comprising an authentication node layer, a cross-domain collaboration layer, and a data storage layer;

[0009] The authentication node layer includes various UAV nodes, ground station nodes and edge computing nodes in the low-altitude intelligent network. Each node has an independent PUF module built in it and integrates a sensor security protection module.

[0010] The cross-domain collaboration layer is a peer-to-peer network composed of distributed nodes. It adopts a distributed consensus mechanism to conduct cross-domain authentication rule negotiation, attribute information synchronization and zero-knowledge proof verification coordination, and supports dynamic topology adjustment.

[0011] The data storage layer adopts a distributed ledger with a consortium blockchain architecture. The ledger nodes consist of authorized ground stations and regulatory agency nodes, storing node PUF feature hash values, cross-domain authentication policies, authentication logs, and node anomaly records, supporting data immutability and traceability.

[0012] Preferably, the PUF module generates a unique hardware feature value for the node. The node constructs an identity identifier through the mapping relationship between the PUF response value and the random challenge value. The identity identifier is stored in the distributed ledger of the data storage layer after being processed by SHA-256 hash.

[0013] Preferably, the identity identifier generation satisfies the following formula:

[0014]

[0015] In the formula, For hash functions, For users Password This is the response value of PUF. This is a random challenge value for PUF.

[0016] Preferred, a decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proofs is applied to the following methods, including the following authentication stages:

[0017] Phase A: Node registration phase. The certified node inputs its identity information and PUF feature-related parameters, generates registration information, and sends it to the cross-domain collaboration layer. The cross-domain collaboration layer checks the validity of the node's identity, and the node completes registration and obtains a legitimate identity identifier.

[0018] Phase B: Cross-domain credential generation phase. When a node needs to communicate across domains, it submits a cross-domain authentication request to a collaborating node within its own domain. The collaborating node checks the time validity of the request and the legitimacy of the node's identity.

[0019] Phase C: Zero-knowledge proof construction phase. After receiving the cross-domain authentication credential, the node first checks the validity of the time, and then verifies the legality of the credential.

[0020] Phase D: Cross-domain verification phase. After receiving the zero-knowledge proof, the target domain verification node first checks the validity of the time, and then verifies the validity of the proof and the legitimacy of the node's identity.

[0021] Phase E: Anomaly Tracing Phase. When a node loses authentication credentials or engages in malicious behavior, the verification node submits anomaly information to the cross-domain collaboration layer. The collaboration layer traces the node's true identity through the binding relationship between PUF features and node identity, and performs credential revocation or permission freezing operations.

[0022] Preferably, the specific implementation steps of the node registration stage A are as follows:

[0023] S1.1 Node Selection Identity Identifier ,Will It is sent to the cross-domain collaboration layer through a secure channel, where... For node identity identification, Register an identifier for the node. Other auxiliary random numbers;

[0024] S1.2, Selecting Collaboration Node Identifiers in the Cross-Domain Collaboration Layer random numbers Check node identity identifier Whether it has been registered; node identity identifier If valid, then calculate the node identity information. Encrypted identity packet secret hash value generated by the collaboration layer ,in, For the collaboration layer private key, For PUF module type, β is a random filling parameter; when node identity identifier If the node has already been registered, a registration failure request will be returned, allowing the node to select a new identity.

[0025] S1.3, will Returning the message to the node via a secure channel, and simultaneously... It is stored in a distributed ledger, where CoopID is the identifier of the cooperating node. This is a coordination layer counter; upon receiving it, the node will set its local authentication failure counter. Initialize to 0, and Stored locally.

[0026] Preferably, the specific implementation steps of the cross-domain credential generation stage B are as follows:

[0027] S2.1 When a node needs to communicate across domains, enter the node's identity identifier. PUF Random Challenge Value and target domain identifier When the node's local authentication fails, a counter is displayed. Select random number Temporary public key for compute nodes Obfuscated temporary public key authentication credentials generated by the node ,in The failure threshold, Temporary random numbers generated by the node For elliptic curve generators, For timestamps, Send to the cross-domain collaboration layer;

[0028] S2.2 After receiving the data, the collaboration layer first checks... ,in This is the current timestamp of the collaboration layer. First, a predefined delay threshold is defined; then, decryption is performed. Check node identity identifier Validity, when node identity identifier If valid, retrieve the secret hash value generated by the corresponding collaboration layer. and Otherwise, terminate communication immediately; when At that time, calculate Then, it is determined that the collaboration layer is based on the locally stored... Is this condition met? If so, select a random number. Calculate its own public key Combined public key The new encrypted identity packet generated by the collaboration layer , and ,in It is a random number. For timestamps, then Return to the node;

[0029] S2.3 After receiving the data, the node first checks... ,in Given the node's current timestamp, calculate the temporary public key when the current timestamp is met. New encrypted identity packet and Then, determine the integrity check value recalculated by the node. Whether it is true or not; if it is true, then... Set to 0, and based on Generate cross-domain authentication credentials If not, then set , refuse and terminate the session.

[0030] Preferably, the zero-knowledge proof construction stage (stage C) is implemented using the following steps:

[0031] S3.1, Node based Select the necessary attributes that need to be disclosed. Hide sensitive attributes Select random number Generate commitment ,in Elliptic curve group generator, For group hierarchy, Let be the set of non-zero elements in the integer field modulo q;

[0032] S3.2, Calculate the challenge value ,in To prove the statement: , A private key derived from PUF;

[0033] S3.3 Calculate the response value Generate zero-knowledge proofs After compression, it is sent to the target domain verification node.

[0034] Preferably, the specific implementation steps of the cross-domain verification stage D are as follows:

[0035] S4.1, The target domain verification node receives zero-knowledge proof data. After that, first check ,in To verify the current timestamp of the node, The timestamps in the proof are used to defend against replay attacks;

[0036] S4.2 Verify that the node obtains its public key or identity key from the distributed ledger. Calculate the recalculated commitment value of the verification node. When the verification node recalculates the commitment value If the verification is successful, the session is valid; otherwise, the verification fails and the session is terminated. For the promises received, Modulo q operation;

[0037] S4.3 Verification Node Calculation ,verify Confirm PUF feature consistency, among which, A reference identity hash value for decryption / retrievable from the ledger or voucher;

[0038] S4.4 When all verifications pass, the verification node selects a random number. Calculate the temporary public key of the verification node. ,in, Verify the temporary random number generated by the node, where G is the base point of the elliptic curve. Send to the node; the node computes. Verification node computation ,in To verify the node identifier, both parties based on To conduct cross-domain communication.

[0039] Preferably, the specific implementation steps of the anomaly tracing stage E are as follows:

[0040] S5.1 When a node loses its authentication credentials, the node's identity identifier must be entered. PUF random challenge value and PUF response value Then, the node is regenerated with a registration identifier through calculation. and will Send to the cross-domain collaboration layer;

[0041] S5.2, Collaboration Layer Check The validity of the selection is determined by whether the device has already been registered. If registration is detected, a new selection is made. random numbers Recalculate node identity information , and , with new Replace the original authentication credentials;

[0042] S5.3 When malicious behavior is detected by a node, the verification node encrypts and uploads the abnormal information to the distributed ledger. The collaboration layer then uses the user's... password Trace the true identity of the node, add it to the blacklist, and update the blacklist set. Restrict cross-domain access permissions.

[0043] Preferably, the authentication architecture uses the AVISPA tool to perform security analysis and verification of this identity authentication method, and can be applied to cross-domain communication scenarios of low-altitude intelligent Internet of Things in low-altitude logistics, emergency rescue, urban inspection and agricultural and forestry plant protection.

[0044] Compared with existing technologies, this invention provides a decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proofs, which has the following beneficial effects:

[0045] 1. This invention overcomes the single point of failure and architectural incompatibility issues of traditional centralized authentication authorities by adopting a decentralized distributed cross-domain collaborative architecture and dynamic adaptive mechanism, thereby improving the robustness and wide-area collaborative capability of cross-domain authentication in low-altitude intelligent networks. Specifically, by using a peer-to-peer network composed of distributed nodes as the cross-domain collaborative layer, combined with a practical Byzantine fault-tolerant consensus mechanism and a consortium blockchain distributed ledger, the risk of single point of failure can be eliminated without any centralized authentication node. Furthermore, the collaborative layer supports dynamic topology adjustment, which can adapt to the characteristics of high node mobility and rapid network structure changes in low-altitude intelligent networks. At the same time, cross-domain authentication rule negotiation, attribute information synchronization, and zero-knowledge proof verification coordination can all be completed under a decentralized architecture. Ledger data is effectively guaranteed by sharded storage and attribute-based encrypted access control, ensuring cross-domain information consistency and data sovereignty security. Ultimately, this invention's architecture achieves deep adaptation to low-altitude wide-area and highly dynamic scenarios.

[0046] 2. This invention employs a two-factor authentication mechanism combining PUF hardware features with lightweight cryptographic primitives (elliptic curve cryptography, one-way hashing) to achieve low computational overhead, low storage requirements, and high-speed operation on resource-constrained nodes. It effectively resists device forgery, cloning attacks, side-channel attacks, and offline dictionary attacks. Specifically, by utilizing physically unclonable functions (SRAM-PUF or Butterfly PUF), a unique and unclonable hardware feature value is generated for each node, serving as the core credential for identity authentication. This resists device forgery and hardware Trojan attacks. The identity identifier is stored in a distributed ledger after being hashed using SHA-256. During transmission, only the dynamic challenge value and hash result are transmitted, preventing the original PUF response value from being leaked. Combined with the dynamic challenge mechanism, this effectively resists side-channel attacks. The use of elliptic curve multiplication and hashing during authentication avoids recalculation of large numbers, resulting in a small key size and low computational overhead. This meets the severe limitations of storage, computation, and energy in terminals such as drones. The identity binding based on a PUF-derived private key and a random number prevents offline dictionary attacks from obtaining valid PUF responses and random numbers, ultimately ensuring the hardware-level security of the architecture.

[0047] 3. This invention achieves cross-domain authentication without disclosing sensitive node attributes through zero-knowledge proofs and a robust anomaly tracing mechanism. It also enables rapid credential reset for lost credentials, precise malicious node location, and full lifecycle auditability. Specifically, by employing the non-interactive Schnorr zero-knowledge proof algorithm, nodes only need to prove to the target domain that they possess valid PUF features, cross-domain credentials, and satisfy attribute policies, without exposing any sensitive information (such as device ID, location, or specific PUF response values), thus unifying privacy protection and compliance authentication. Furthermore, this invention sets up a collaboration layer counter and a node counter. When the number of consecutive authentication failures exceeds a threshold, communication is automatically terminated, effectively resisting brute-force attacks. After a node credential is lost, it can submit a reset request to the collaboration layer based on the PUF feature and identity binding relationship to regenerate authentication credentials, thereby preventing device obsolescence. For detected malicious behavior, the verification node encrypts and uploads the anomaly information to the distributed ledger. The collaboration layer accurately traces the true identity through the PUF feature and node identity binding relationship and adds the node to a blacklist, updating the blacklist set and restricting cross-domain access permissions. Ultimately, this invention achieves full lifecycle security control and auditable traceability. Attached Figure Description

[0048] Figure 1 This is a diagram of the authentication architecture framework of the present invention;

[0049] Figure 2 This is a flowchart of the node registration process of the present invention;

[0050] Figure 3 This is a flowchart of the cross-domain credential generation process of the present invention;

[0051] Figure 4 This is a flowchart of the cross-domain verification process of the present invention;

[0052] Figure 5 This is a diagram illustrating the node registration process in an embodiment of the present invention.

[0053] Figure 6 This is a diagram illustrating the cross-domain credential generation process according to an embodiment of the present invention; Detailed Implementation

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

[0055] Please see Figures 1-6 The low-altitude intelligent network's decentralized cross-domain authentication architecture based on PUF and zero-knowledge proof includes an authentication node layer, a cross-domain collaboration layer, and a data storage layer. Each layer works together to achieve decentralized cross-domain authentication.

[0056] The authentication node layer includes various UAV nodes (multi-rotor, fixed-wing, unmanned helicopter, etc.), ground station nodes, and edge computing nodes in the low-altitude intelligent network. Each node has a built-in independent PUF module to generate a unique hardware feature value for the node, which serves as the core credential for identity authentication. The node also integrates a sensor security protection module to resist perception layer attacks such as GPS spoofing and acoustic injection through multi-source sensor data fusion, ensuring the security of the node itself. It is mainly used to resist perception layer spoofing attacks and interference attacks.

[0057] The cross-domain collaboration layer is a peer-to-peer network composed of distributed nodes. It adopts a distributed consensus mechanism (practical Byzantine fault-tolerant algorithm) to ensure cross-domain information consistency, and coordinates cross-domain authentication rule negotiation, attribute information synchronization, and zero-knowledge proof verification. There is no central control node, and it supports dynamic topology adjustment to adapt to the high mobility of low-altitude networks. This layer is responsible for cross-domain authentication rule negotiation, attribute information synchronization, and zero-knowledge proof verification coordination, and supports dynamic topology adjustment to make the authentication architecture adapt to the network structure changes caused by the high mobility of low-altitude nodes. The collaboration nodes also have edge computing capabilities to reduce end-to-end latency in the authentication process.

[0058] The data storage layer adopts a distributed ledger with a consortium blockchain architecture. Ledger nodes consist of authorized ground stations and regulatory agency nodes, storing node PUF feature hash values, cross-domain authentication policies, authentication logs, and node anomaly records. This supports data immutability and traceability. The ledger uses a sharding storage mechanism, partitioning data according to cross-domain scenarios to improve access efficiency. Data transmission and storage employ encryption mechanisms to ensure data immutability and privacy protection, while supporting full lifecycle traceability. This provides data support for cross-domain verification and identity tracing. Ledger access permissions are controlled based on an attribute-based encryption mechanism.

[0059] Specifically, the PUF module is a physically unclonable function based on silicon technology (such as SRAM-PUF or Butterfly PUF), which can generate a unique hardware feature value (a stable and unique response value) for a node. The node constructs an identity identifier through the mapping relationship between the PUF response value and random challenge values ​​(CRPs). The identity identifier is then processed by SHA-256 hashing and stored in the distributed ledger of the data storage layer.

[0060] Specifically, the identity identifier generation satisfies the following formula:

[0061]

[0062] In the formula, For hash functions, For users Password This is the response value of PUF. The PUF module also has the ability to resist side-channel attacks by using a dynamic challenge mechanism to avoid feature leakage, with random challenge values ​​for the PUF module.

[0063] The authentication architecture is applied to the following method, which consists of five phases: node registration, cross-domain credential generation, zero-knowledge proof construction, cross-domain verification, and anomaly tracing. In this method, a collaboration layer counter is set. and node counter Used to track the number of consecutive failed authentication attempts, with an initial value set to 0 and a maximum failure threshold set to... (like ),when or At this point, the communication process terminates immediately, specifically including the following authentication phases:

[0064] Phase A: In the node registration phase, the main task is to assign a valid identity identifier and authentication credentials to the node to facilitate subsequent cross-domain communication authentication. First, the node selects its identity identifier and a random number, generating a random challenge value which is input into the PUF module to obtain a response value. The registration identifier is then calculated and sent to the cross-domain collaboration layer via a secure channel. Next, the cross-domain collaboration layer checks the validity of the node's identity identifier. If valid, it calculates authentication-related parameters and generates an encrypted identity identifier and verification value. If the identity identifier has already been registered, a request is returned, allowing the node to select a new identity identifier. Finally, the collaboration layer returns the encrypted identity identifier and verification value to the node via a secure channel, while simultaneously storing the node registration information in the distributed ledger. Upon receiving this information, the node initializes its counter and stores the relevant credentials, completing the registration.

[0065] Through the above steps, the node successfully obtains the encrypted identity identifier and verification value issued by the cross-domain collaboration layer, initializes the failure counter locally, completes the identity binding with the distributed ledger, and establishes a reliable and unforgeable hardware-level identity foundation for subsequent cross-domain authentication.

[0066] Phase B: During the cross-domain credential generation phase, when a node needs cross-domain communication, it submits a cross-domain authentication request to a collaborating node within its own domain. The node inputs its identity identifier and related parameters, generates a request message, and sends it to the collaboration layer. The collaboration layer checks the time validity of the request and the legitimacy of the node's identity. If valid, it generates a cross-domain authentication credential and returns it to the node; otherwise, the collaboration layer terminates the session. After receiving the credential, the node verifies its validity. If valid, it completes the cross-domain credential acquisition; otherwise, the session terminates.

[0067] Through the above mechanism, the node and the collaboration layer complete a two-way challenge-response verification, dynamically generate cross-domain authentication credentials, ensure that the node's identity is legitimate and has cross-domain communication permissions, and effectively resist replay attacks and brute-force attacks through the timestamp and counter mechanism.

[0068] Phase C: In the zero-knowledge proof construction phase, nodes select necessary attributes to be disclosed (such as permission level and flight qualifications) based on cross-domain authentication credentials, while hiding sensitive attributes (such as specific location and device number). Nodes use the non-interactive Schnorr zero-knowledge proof algorithm to generate commitment, challenge, and response values, constructing a zero-knowledge proof that they possess legitimate PUF features and cross-domain credentials, and that the attributes meet the authentication requirements of the target domain. The proof process does not disclose any sensitive information, and the proof is sent to the target domain verification node.

[0069] Through the aforementioned non-interactive zero-knowledge proof algorithm, nodes can prove to the target domain that their attributes meet the authentication policy without exposing PUF features, sensitive attributes, and the specific content of cross-domain credentials, thus achieving a balance between privacy protection and compliant authentication.

[0070] Phase D: In the cross-domain verification phase, after receiving the zero-knowledge proof, the target domain verification node first checks the time validity of the proof to defend against replay attacks; secondly, it verifies the validity of the proof and the legitimacy of the node's identity, and confirms the consistency of the PUF features; if all verification steps pass, the verification node negotiates a session key with the initiating node, allowing the initiating node to access the target domain for cross-domain communication; if the verification fails, it refuses access and records the reason for the failure and uploads it to the distributed ledger.

[0071] Through the above verification process, the target domain node performs multiple checks on the timeliness, validity, and PUF feature consistency of the zero-knowledge proof. After negotiating the session key, secure cross-domain communication access is achieved. When verification fails, abnormal information is automatically recorded on the blockchain to ensure the auditability of the authentication process.

[0072] Phase E: In the anomaly tracing phase, if a node loses its authentication credentials, it needs to submit a reset request to the collaboration layer. After verifying the validity of the node's identity, the collaboration layer regenerates and issues the authentication credentials. If malicious behavior of a node is detected, the verification node encrypts and uploads the anomaly information to the distributed ledger. The collaboration layer traces the true identity of the node through the binding relationship between PUF features and node identity, adds it to the blacklist, restricts cross-domain access permissions, and realizes the handling of abnormal nodes.

[0073] Through the aforementioned credential loss reset and malicious behavior tracing mechanisms, the collaboration layer can quickly restore legitimate node credentials based on PUF characteristics and identity binding relationships, or accurately locate malicious nodes and blacklist them, thereby achieving full lifecycle security control and dynamic blocking of cross-domain permissions.

[0074] This invention addresses the characteristics of resource-constrained nodes in the Low-Altitude Intelligent Network (LAI) and the problems existing in current identity authentication technologies. It proposes a decentralized cross-domain authentication architecture and method for LAI based on PUF and zero-knowledge proofs. This method provides a set of cross-domain identity authentication and session key negotiation services between LAI nodes, ensuring the authenticity and validity of node identities and preventing malicious attacks. The authentication method includes five stages: node registration, cross-domain credential generation, zero-knowledge proof construction, cross-domain verification, and anomaly tracing. By introducing PUF hardware features, zero-knowledge proofs, elliptic curve algorithms, and one-way hash algorithms, and employing a decentralized distributed architecture and two-factor authentication logic, it resists various security vulnerabilities. Security proof is achieved through AVISPA protocol analysis tools. Ultimately, this method architecture is applicable to cross-domain communication scenarios of terminal devices with limited computing, storage, and energy resources.

[0075] The architecture of this invention is applied to the following embodiments to implement the phased execution steps:

[0076] Example

[0077] Phase A: Node Registration Phase

[0078] The registration phase primarily involves issuing legitimate identity identifiers and authentication credentials to nodes, facilitating cross-domain communication authentication later. First, enter the node's name and select the identity identifier. random numbers Generate random challenge values ,calculate Further calculations ,Will The data is sent to the cross-domain collaboration layer via a secure channel; secondly, the cross-domain collaboration layer selects a collaboration node identifier. Random numbers Check node identity identifier Has it already been registered? If so... If valid, then calculate. , , ,in For the collaboration layer private key, It is a PUF module type; if If the node is already registered, a registration failure request will be returned, allowing the node to select a new identity. Finally, the collaboration layer will... Returning the message to the node via a secure channel, and simultaneously... Stored in a distributed ledger, where Initialize to 0. After receiving the data, the node will set the counter. Initialize to 0, and Store locally, complete registration, the specific process is as follows: Figure 5 As shown.

[0079] Phase B: Cross-Domain Credential Generation Phase

[0080] When a node needs to communicate across domains, it submits a cross-domain authentication request to collaborating nodes within its own domain. The node then inputs... , and target domain identifier ,when Choose a random number ,calculate , and ,in For the base points of the elliptic curve and For timestamps, Send to the cross-domain collaboration layer; upon receiving it, the collaboration layer first checks... ,in This is the current timestamp of the collaboration layer. First, a predefined delay threshold is defined; then, decryption is performed. ,examine Validity, if If valid, then retrieve the corresponding... and Otherwise, terminate communication immediately; if ,calculate Therefore, to judge Is this condition met? If so, select a random number. ,calculate , , , and ,in It is a random number. For timestamps, then Returned to the node; upon receiving it, the node first checks... ,in Let the current timestamp of the node be used. If the condition is met, then calculate... , and Then judge Is it true? If it is true, then... Set to 0, and based on Generate cross-domain authentication credentials If not, then set The session will be refused and terminated. Detailed procedures are as follows: Figure 6 As shown.

[0081] Phase C: Zero-knowledge proof construction phase

[0082] Node based Select the necessary attributes that need to be disclosed. For example, access levels such as logistics and delivery level, and legal flight qualifications; hiding sensitive attributes. For example, device number, location information, etc. Nodes select random numbers. Generate commitment ,in Elliptic curve group generator, Group order; by calculating challenge value ,in To prove the statement: , Calculate the response value by generating a private key from the PUF. Generate zero-knowledge proofs After compression, it is sent to the target domain verification node.

[0083] Phase D: Cross-domain verification phase

[0084] The target domain verification node received After that, first check ,in To verify the current timestamp of the node, To prove the timestamp, it is used to defend against replay attacks; furthermore, the verification node obtains the timestamp from the distributed ledger. ,calculate ,like If the verification is successful, the proof is valid; otherwise, the verification fails and the session is terminated. Subsequently, the verification node calculates... ,verify Confirm PUF feature consistency; if all verifications pass, the verification node selects a random number. ,calculate ,Will Send to the node; the node computes. Verification node computation ,in To verify the node identifier, both parties based on To conduct cross-domain communication.

[0085] Phase E: Anomaly Tracing Phase

[0086] If the node loses its authentication credentials, you need to enter... , and Then, the real identity identifier is obtained through calculation. and will Send to the cross-domain collaboration layer; the collaboration layer checks. The validity of the registration is checked, i.e., whether it has been registered before. If it has been registered, a new selection is made. random numbers Recalculate , and , with new Replace the original authentication credentials; if malicious behavior is detected by a node, the verification node will encrypt and upload the abnormal information to the distributed ledger, and the collaboration layer will then... Tracing the true identity of nodes, adding them to the blacklist, and updating... Restrict cross-domain access permissions.

[0087] Through the security demonstrations of the above embodiments, the proposed decentralized cross-domain authentication architecture and method for low-altitude intelligent networks based on PUF and zero-knowledge proofs can resist various attacks and has the following security features:

[0088] (1) Resistance to offline dictionary attacks: due to the registration identifier being Among them, those with hardware uniqueness Attackers cannot obtain the real information. and random numbers ,because Hash functions have one-way property, meaning that given a hash function... In cases where it is impossible to obtain through inverse operation Therefore, even if the attacker obtains... It is also impossible to guess by traversing an offline dictionary. , Key information such as registration requests cannot be forged or node identities can be cracked.

[0089] (2) Anonymity: During node transmission, information related to identity is... and All of them A mixed hash value combining random numbers and PUF characteristics. Due to... , A random value for each registration or communication, in different sessions. and It is dynamically changing, and attackers cannot obtain it from... or Separate from Furthermore, it is impossible to associate the identity of the same node through multiple communication messages, thus failing to achieve anonymity protection.

[0090] (3) Resistance to forgery and impersonation attacks: The validity of zero-knowledge proofs and cross-domain credentials relies on PUF-derived private keys and dynamic random numbers. Attackers without legitimate private keys and random numbers cannot forge verified proofs or credentials. The verification equation for zero-knowledge proofs is as follows: ,in , This is a private key derived from the PUF. An attacker wishing to forge proof would need to do so in an unknown... Generate a solution that satisfies the verification equation. Assuming the attacker forges Try to satisfy ,because unknown, It cannot be calculated correctly, and Because of PUF characteristics, attackers cannot forge them. Therefore, forged credentials cannot be verified. Meanwhile, cross-domain credentials... based on , Dependent on random numbers and Since attackers lack valid random numbers, they cannot generate valid credentials and therefore cannot impersonate legitimate nodes.

[0091] (4) Resistance to replay attacks: Timestamp and delay threshold constraints ensure message timeliness, and parameter correlation ensures verification failure after timestamp tampering. All communication messages contain timestamps. The verification node passed Determine message freshness. If an attacker replays an expired message... If the attacker modifies the timestamp, it will be rejected directly; In subsequent verification Sending with the node Unequal, leading to Verification failed, and the session terminated. Furthermore, in zero-knowledge proofs... It is strongly correlated with timestamps and target domain identifiers, and the proof of replay cannot pass verification due to parameter mismatch, effectively resisting replay attacks.

[0092] (5) Resistance to known key attacks: Session keys are generated through independent random number negotiation. Random numbers from different sessions are independent of each other, so leakage of a session key will not affect other sessions. Session key ,in For the node, a random number. To verify the node random number, , In each communication and All numbers are fresh random numbers; random numbers from different sessions are generated independently and are unrelated. (Due to dependency...) One-dimensionality and the discrete logarithm problem of elliptic curves, even in a given session The leak also prevents attackers from accessing the site. Middle reverse push or Furthermore, it cannot generate random numbers and session keys for other sessions, ensuring that known key attacks are ineffective.

[0093] (6) Resistance to side-channel attacks: PUF signatures are protected through dynamic challenges and encrypted transmission. Information leaked via the side channel cannot be fully recovered, and key transmission uses an encrypted channel, preventing attackers from obtaining valid information. PUF challenge value The numbers are dynamically generated random numbers, and different numbers are used for each communication. Even if the attacker obtains part of it through the side channel and The corresponding relationship cannot be modeled using the PUF function to predict response values ​​for other challenge values. Meanwhile, The transmission process is protected by an encrypted channel, and the transmitted data is Equal hash value, not Original value, side channel cannot capture The presence of valid key information prevents the implementation of side-channel attacks.

[0094] (7) Resistance to Man-in-the-Middle Attacks: The session key is generated based on the elliptic curve discrete logarithm problem. Attackers cannot calculate the key without a legitimate private key, and message integrity is guaranteed through hash verification, preventing tampering with the communication content. Session key negotiation relies on... ,in , and In other words, key negotiation is based on the elliptic curve Diffie-Hellman (ECDH) mechanism. An attacker who wants to obtain the session key needs to calculate... However, due to the elliptic curve discrete logarithm problem, attackers cannot obtain... and From or Therefore, it is impossible to calculate. Unable to obtain At the same time, communication messages (such as...) , Integrity is verified through hash calculation. If an attacker tampers with the message, the hash value will not match, the verification will fail, and a man-in-the-middle attack cannot be carried out.

[0095] (8) Full forward security: The session key relies on ephemeral random numbers and the elliptic curve discrete logarithm problem. Even if the private key is leaked long-term, the random numbers from past sessions cannot be recovered, and the key remains secure. The core is Relying on temporary random numbers and rather than long-term private keys Even long-term private keys Leak, due to and It is a temporary random number generated for a single session and is not reused after the session ends, making it impossible for attackers to bypass it. Restore past conversations , or Therefore, past conversations It remains safe and has full forward safety.

[0096] The symbols and descriptions used in the embodiments are shown in Table 1 below:

[0097] Table 1

[0098]

[0099] Finally, for the proposed decentralized cross-domain authentication architecture and method for low-altitude intelligent networks based on PUF and zero-knowledge proof, the security analysis and proof of this identity authentication method were implemented using the AVISPA tool. It was proved that the present invention has the advantages of small key size, low computational overhead and low storage requirements, and can be securely applied to cross-domain communication scenarios of low-altitude intelligent networks such as low-altitude logistics, emergency rescue, urban inspection and agricultural and forestry plant protection.

[0100] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proofs, characterized in that: It includes an authentication node layer, a cross-domain collaboration layer, and a data storage layer; The authentication node layer includes various UAV nodes, ground station nodes and edge computing nodes in the low-altitude intelligent network. Each node has an independent PUF module built in it and integrates a sensor security protection module. The cross-domain collaboration layer is a peer-to-peer network composed of distributed nodes. It adopts a distributed consensus mechanism to conduct cross-domain authentication rule negotiation, attribute information synchronization and zero-knowledge proof verification coordination, and supports dynamic topology adjustment. The data storage layer adopts a distributed ledger with a consortium blockchain architecture. The ledger nodes consist of authorized ground stations and regulatory agency nodes, storing node PUF feature hash values, cross-domain authentication policies, authentication logs, and node anomaly records, supporting data immutability and traceability.

2. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 1, characterized in that: The PUF module generates a unique hardware feature value for each node. The node constructs an identity identifier through the mapping relationship between the PUF response value and the random challenge value. The identity identifier is then processed by SHA-256 hashing and stored in the distributed ledger of the data storage layer.

3. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 2, characterized in that: The identity identifier is generated according to the following formula: In the formula, For hash functions, For users Password This is the response value of PUF. This is a random challenge value for PUF.

4. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 1, characterized in that, The authentication architecture is applied in the following methods, including the following authentication phases: Phase A: Node registration phase, where the authentication node inputs identity information and PUF feature-related parameters, generates registration information, and sends it to the cross-domain collaboration layer; The cross-domain collaboration layer checks the validity of the node's identity, and the node completes registration and obtains a valid identity identifier; Phase B: Cross-domain credential generation phase. When a node needs to communicate across domains, it submits a cross-domain authentication request to the collaborating nodes within its own domain. The coordinating nodes check the time validity of the request and the legitimacy of the node's identity; Phase C: Zero-knowledge proof construction phase. After receiving the cross-domain authentication credential, the node first checks the validity of the time, and then verifies the legality of the credential. Phase D: Cross-domain verification phase. After receiving the zero-knowledge proof, the target domain verification node first checks the validity of the time, and then verifies the validity of the proof and the legitimacy of the node's identity. Phase E: Anomaly Tracing Phase. When a node loses authentication credentials or engages in malicious behavior, the verification node submits anomaly information to the cross-domain collaboration layer. The collaboration layer traces the node's true identity through the binding relationship between PUF features and node identity, and performs credential revocation or permission freezing operations.

5. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 4, characterized in that: The specific implementation steps for the node A registration phase are as follows: S1.1 Node Selection Identity Identifier ,Will It is sent to the cross-domain collaboration layer through a secure channel. For node identity identification, Register an identifier for the node. Other auxiliary random numbers; S1.2, Selecting Collaboration Node Identifiers in the Cross-Domain Collaboration Layer random numbers Check node identity identifier Whether it has been registered; node identity identifier If valid, then calculate the node identity information. Encrypted identity packet secret hash value generated by the collaboration layer ,in, For the collaboration layer private key, For PUF module type, β is a random filling parameter; when node identity identifier If the node has already been registered, a registration failure request will be returned, allowing the node to select a new identity. S1.3, will Returning the message to the node via a secure channel, and simultaneously... It is stored in a distributed ledger, where CoopID is the identifier of the cooperating node. This is a coordination layer counter; upon receiving it, the node will set its local authentication failure counter. Initialize to 0, and Stored locally.

6. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 4, characterized in that: The specific implementation steps for Phase B, the cross-domain credential generation phase, are as follows: S2.1 When a node needs to communicate across domains, enter the node's identity identifier. PUF Random Challenge Value and target domain identifier When the node's local authentication fails, a counter is displayed. Select random number Temporary public key for compute nodes Obfuscated temporary public key authentication credentials generated by the node ,in The failure threshold, Temporary random numbers generated by the node For elliptic curve generators, For timestamps, Send to the cross-domain collaboration layer; S2.2 After receiving the data, the collaboration layer first checks... ,in This is the current timestamp of the collaboration layer. First, a predefined delay threshold is defined; then, decryption is performed. Check node identity identifier Validity, when node identity identifier If valid, retrieve the secret hash value generated by the corresponding collaboration layer. and ; Otherwise, terminate communication immediately; when At that time, calculate Then, it is determined that the collaboration layer is based on the locally stored... Is this condition met? If so, select a random number. Calculate its own public key Combined public key The new encrypted identity packet generated by the collaboration layer , and ,in It is a random number. For timestamps, then Return to the node; S2.3 After receiving the data, the node first checks... ,in Given the node's current timestamp, calculate the temporary public key when the current timestamp is met. New encrypted identity packet and Then, determine the integrity check value recalculated by the node. Whether it is true or false; if it is true, then... Set to 0, and based on Generate cross-domain authentication credentials If not, then set , refuse and terminate the session.

7. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 4, characterized in that: The specific implementation steps for stage C, the zero-knowledge proof construction stage, are as follows: S3.1, Node based Select the necessary attributes that need to be disclosed. Hide sensitive attributes Select random number Generate commitment ,in Elliptic curve group generator, For group hierarchy, Let be the set of non-zero elements in the integer field modulo q; S3.2, Calculate the challenge value ,in To prove the statement: , A private key derived from PUF; S3.3 Calculate the response value Generate zero-knowledge proofs After compression, it is sent to the target domain verification node.

8. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 4, characterized in that: The specific implementation steps for the cross-domain verification stage (Stage D) are as follows: S4.1, The target domain verification node receives zero-knowledge proof data. After that, first check ,in To verify the current timestamp of the node, The timestamps in the proof are used to defend against replay attacks; S4.2 Verify that the node obtains its public key or identity key from the distributed ledger. Calculate the recalculated commitment value of the verification node. When the verification node recalculates the commitment value If the verification is successful, the session is valid; otherwise, the verification fails and the session is terminated. For the promises received, Modulo q operation; S4.3 Verification Node Calculation ,verify Confirm PUF feature consistency, among which, A reference identity hash value for decryption / retrievable from the ledger or voucher; S4.4 When all verifications pass, the verification node selects a random number. Calculate the temporary public key of the verification node. ,in, Verify the temporary random number generated by the node, where G is the base point of the elliptic curve. Send to the node; the node computes. Verification node computation ,in To verify the node identifier, both parties based on To conduct cross-domain communication.

9. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claim 4, characterized in that: The specific implementation steps for the anomaly tracing stage E are as follows: S5.1 When a node loses its authentication credentials, the node's identity identifier must be entered. PUF random challenge value and PUF response value Then, the node is regenerated with a registration identifier through calculation. and will Send to the cross-domain collaboration layer; S5.2, Collaboration Layer Check The validity of the selection is determined by whether the device has already been registered. If registration is detected, a new selection is made. random numbers Recalculate node identity information , and , with new Replace the original authentication credentials; S5.3 When malicious behavior is detected by a node, the verification node encrypts and uploads the abnormal information to the distributed ledger. The collaboration layer then uses the user's... password Trace the true identity of the node, add it to the blacklist, and update the blacklist set. Restrict cross-domain access permissions.

10. The decentralized cross-domain authentication architecture for low-altitude intelligent networks based on PUF and zero-knowledge proof as described in claims 4-9, characterized in that: The authentication architecture uses the AVISPA tool to perform security analysis and verification of this identity authentication method, and can be applied to cross-domain communication scenarios of low-altitude intelligent Internet of Things in low-altitude logistics, emergency rescue, urban inspection and agricultural and forestry plant protection.

Images