Batch authentication and key agreement method of unmanned aerial vehicle assisted internet of things

Abstract

The invention relates to a batch authentication and key negotiation method of an unmanned aerial vehicle assisted internet of things. The method comprises a system initialization and equipment registration stage, a pre-authorization stage based on physical unclonable, an offline batch authentication and data acquisition stage and a centralized verification and state synchronization stage. An identity binding and offline authorization mechanism based on a physical unclonable function is introduced, multiple tasks are completed in a single round by adopting an integration mechanism of'authentication, namely transmission ', and a one-to-many batch authentication mechanism and a centralized state synchronization mechanism with voucher fallback fault-tolerant capability are supported. Therefore, the defects of low batch authentication efficiency, weak offline task capability, lack of physical security root, easy desynchronization attack and the like in an unmanned aerial vehicle assisted Internet of Things scene in the prior art are overcome, and an efficient, safe and robust batch authentication and key negotiation method is provided.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of wireless communication security technology, in particular to a batch authentication and key agreement method for unmanned aerial vehicle assisted Internet of Things. BACKGROUND

[0002] Unmanned aerial vehicle (UAV) assisted Internet of Things (IoT) systems are increasingly applied in scenarios such as environmental monitoring and infrastructure inspection. In such applications, UAVs serve as mobile base stations or data relays, responsible for collecting data from a large number of IoT devices deployed in wide-area, unattended environments. To ensure the authenticity, integrity, and confidentiality of data, it is essential to establish a secure authentication and key agreement (AKA) mechanism before communication. However, directly applying traditional AKA protocols to such scenarios faces serious challenges, primarily in achieving high communication efficiency and robust security. Current authentication and key agreement protocols often have high overhead due to multiple rounds of interaction, hindering fast and large-scale device authentication. Additionally, many existing protocols that use credential update mechanisms are vulnerable to permanent unsynchronization attacks, where a single session failure can result in permanent device lockout. SUMMARY

[0003] To address the above problems, the purpose of the present application is to provide a batch authentication and key agreement method for unmanned aerial vehicle assisted Internet of Things, achieving multi-task completion in a single round, supporting a one-to-many batch authentication mechanism, and possessing a centralized state synchronization mechanism with credential rollback fault tolerance capability.

[0004] To achieve the above purpose, the present application adopts the following technical solutions:

[0005] A batch authentication and key agreement method for unmanned aerial vehicle assisted Internet of Things, including system initialization and device registration phase, pre-authorization based on physically unclonable function (PUF), offline batch authentication and data collection phase, and centralized verification and state synchronization phase, specifically as follows:

[0006] In the system initialization and device registration phase, the ground control station generates a system master key and public parameters; the ground control station assigns a unique real identity and initial temporary identity to each unmanned aerial vehicle and target IoT device; the ground control station generates a challenge set C for each entity, including unmanned aerial vehicles and target IoT devices, through a secure channel; each entity generates a response set R through its built-in PUF circuit; each entity transmits the response set R back to the ground control station, and the ground control station binds and stores the real identity, temporary identity, and challenge-response pair;

[0007] In the pre-authorization stage based on PUF, the ground control station generates and issues a short-term operation credential with time limit for the UAV according to the predetermined task, which contains at least one PUF challenge for verifying the legitimacy of the physical entity of the UAV, and the pre-computed authentication parameters for the target IoT device; after receiving the credential, the UAV uses the built-in PUF circuit to operate the PUF challenge to generate a response, and completes the authentication and session key establishment with the ground control station based on the response and its real identity, while obtaining the authentication parameters of the target IoT device;

[0008] In the offline batch authentication and data collection stage, the UAV uses the short-term operation credential to broadcast the authentication request message to the target IoT device concurrently under the condition of being disconnected from the real-time communication with the ground control station; after receiving the authentication request, each target IoT device uses the built-in PUF circuit to perform challenge-response based verification to confirm the legitimacy of the message source, and after the verification passes, the collected data encrypted by the negotiated session key and the parameters for generating the next period temporary identity are encapsulated in the response message and returned to the UAV;

[0009] In the centralized verification and state synchronization stage, the UAV performs preliminary authentication when receiving the message of the target IoT device, and verifies the legitimacy of the target IoT device one by one; after collecting all the information of the target IoT device, the UAV returns the collected response message to the ground control station; after receiving the collected response message, the ground control station performs centralized verification, and if the verification passes, the temporary identity of the UAV and the target IoT device in the database of the ground control station is updated synchronously.

[0010] Further, in the offline batch authentication and data collection stage, the integration mechanism of authentication and transmission is based on the integration mechanism, and the target IoT device performs session key negotiation confirmation, encrypted collection data upload and next period temporary identity update simultaneously in the response message of single authentication interaction.

[0011] Further, the UAV and the target IoT device maintain the perception of two credential states locally, which are the submitted old authentication credential and the to-be-processed new authentication credential; when the preliminary authentication fails, the entity performs consistency comparison based on the two credential states to distinguish between legitimate rollback and replay attack, and automatically rolls back the temporary identity to the version before the update to re-establish synchronization.

[0012] Further, the specific way for the ground control station to establish the physical security root of the identity is to mathematically bind the unique digital identity of each legitimate UAV and target IoT device with a set of challenge-response pairs generated by the PUF circuit, and store the binding relationship as the digital identity credential of the UAV and the target IoT device in the database.

[0013] Further, the offline batch authentication and data collection phase also has a certificate rollback anti-desynchronization attack mechanism, which is as follows: the certificate rollback anti-desynchronization attack mechanism is implemented through an authentication certificate rollback logic, and the specific execution logic of the receiving entity is as follows: (1) integrity check first: before any identity verification, the receiving entity first recalculates and verifies the integrity of the received identity verification message through a hash digest method to ensure that the message has not been tampered with; if the integrity check fails, the process is terminated; (2) double verification logic: after the integrity check is successful, the receiving entity first compares the authentication certificate contained in the message with the locally maintained to-be-processed authentication certificate; if the comparison fails, the receiving entity automatically compares it with the locally maintained submitted authentication certificate to identify whether there is a legitimate certificate rollback request; (3) freshness verification: the double verification logic provides protection by forcibly verifying the timestamp random number in the message; (4) anomaly detection: each entity maintains an internal rollback counter, and if the identity verification repeatedly triggers the rollback to the submitted authentication certificate operation, and the counter exceeds a predefined threshold, the entity marks the link as abnormal.

[0014] A batch authentication and key agreement system for unmanned aerial vehicle assisted Internet of Things device networking, comprising a ground control station, an unmanned aerial vehicle and a target Internet of Things device; the unmanned aerial vehicle and the target Internet of Things device each contain a physically unclonable function (PUF) circuit; each component in the system is configured to cooperatively perform steps in a batch authentication and key agreement method for unmanned aerial vehicle assisted Internet of Things as described above.

[0015] The present application has the following beneficial effects:

[0016] 1. The present application has fault-tolerant high reliability: the certificate rollback mechanism realizes protocol self-healing, effectively tolerates state desynchronization caused by communication packet loss, avoids permanent locking of devices, and significantly enhances the fault tolerance, robustness and reliability of the system under unstable links;

[0017] 2. The present application binds the digital identity of the device with its physical entity through the use of PUF technology, establishes a physical security root, and can effectively resist cloning attacks and key extraction attacks caused by physical capture of the device;

[0018] 3. The present application reduces the communication overhead of authenticating multiple devices from O(n) level proportional to the number of devices n to constant O(1) level through the batch authentication mechanism, greatly shortens the total task time, and has a particularly significant advantage in the case of a large number of devices, and through the decoupled operation model, the UAV can complete the core task autonomously without relying on real-time connection with the GCS, greatly expanding the operation range and environmental adaptability of the system. BRIEF DESCRIPTION OF DRAWINGS

[0019] Figure 1 This is a schematic diagram of the system model of the present invention;

[0020] Figure 2 This is a schematic diagram of the method flow in one embodiment of the present invention. Detailed Implementation

[0021] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments:

[0022] refer to Figures 1-2 To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to specific embodiments. The method of this invention is applied to a three-layer architecture consisting of a ground control station (GCS), a drone (denoted by Ua), and an IoT device (Di), and specifically includes the following steps:

[0023] Phase 1: System Initialization and Device Registration Phase

[0024] This phase is completed in a secure environment before all entities are deployed, and its core is to generate a complete set of credentials for each device that are bound to its physical characteristics.

[0025] Step IR1 (GCS Internal Initialization): As the system's root of trust, GCS performs the following operations:

[0026] (1) Generate the system master key And select a collision-resistant hash function. .

[0027] (2) For each drone that will be registered in the system and IoT devices Pre-assign a unique real identity or and an initial temporary identity. or .

[0028] (3) Generate a unique set of physical property challenges for each entity. .

[0029] Step IR2 (Device Registration and Credential Generation): Each entity ( or Registration is performed via a secure channel.

[0030] (1) GCS sends its corresponding data to the entity. .

[0031] (2) After receiving the information, the entity will set the challenge set Input its internal physical characteristic function to generate the corresponding response set. .

[0032] (3) The entity will respond set back to GCS securely.

[0033] (4) After GCS receives , , and this set of unique challenge-response pairs is formally bound, it will be stored in the database as the complete credential of this entity.

[0034] Phase Two: PUF-based pre-authorization phase

[0035] This phase is mainly for online pre-authorization between UAV and GCS, which is used to obtain task credentials.

[0036] Step OPBA1 (online pre-authorization between UAV and GCS):

[0037] (1) GCS operation: GCS selects a temporary UAV identity and retrieves the GCS private key and the corresponding UAV challenge-response pair set from the database . GCS selects an unused challenge-response pair from . GCS generates the current timestamp . GCS calculates the session key pre-shared value and the pre-shared public value . For bound IoT devices ( ), GCS performs the following operations in turn:

[0038] Retrieve the challenge-response pair set corresponding to the device from the database , and get the response corresponding to from it .

[0039] Calculate .

[0040] Calculate .

[0041] Calculate .

[0042] Calculate .

[0043] Subsequently, GCS calculates the verification message Finally, send to the drone. .

[0044] (2) Drone operation: Drone Received message from GCS Next, verify the timestamp. The timeliness and verification The legitimacy of it. Next, calculate and received The comparison is performed. If the verification is successful, then... Use Challenge The response is generated through its physical property function. Then... Calculate session key For each device UAV computing Thus far, drones Mutual authentication with GCS was completed, and a session key was established. They also obtained the authentication information of the associated IoT devices.

[0045] Phase 3: Offline Batch Authentication and Data Collection Phase

[0046] This stage involves the drone arriving at the target area and completing offline batch authentication, data collection, and identity updates with IoT devices.

[0047] Step OPBA2 (Offline Batch Authentication of Drones and IoT Devices):

[0048] (1) Drone operation: Drone After arriving at the target area, based on IoT devices temporary identity to each device Send a message.

[0049] (2) Operation of IoT devices: IoT devices Received message Then, first check the timestamp. The freshness of the product. If the verification fails, then... Terminate authentication. Otherwise, Calculate the verification value and received Compare. If ,but Use Challenge Response is generated through its physical characteristic function. Subsequently, calculate and received Compare. If then Continuously compute session key . Otherwise, authentication fails. After successful authentication, the IoT device establishes a session key with the GCS for subsequent secure communication and data sharing. Meanwhile, stores the session key for replay attack detection.

[0050] Step DAIU1 (IoT device encrypts and sends data):

[0051] After successful authentication, the following operations are performed immediately: generate a random number . Compute . Compute the new temporary identity . Compute the verification information . Finally, encrypts using the session key and sends the information to the UAV .

[0052] Step DAIU2 (UAV aggregates and forwards data): After receiving the message from the device , the UAV first checks the validity of . Compute , if , continue execution; otherwise, abort authentication. Generate a timestamp and compute its new temporary identity . When collects all messages from the devices in or reaches the preset time, compute . Finally, encrypts using the session key and sends the integrated message to the GCS.

[0053] This phase is the core of the invention to achieve efficient bulk access. When the UAV flies to the target area, it uses the short-term operation credentials it holds to broadcast authentication requests to all target IoT devices in its coverage area concurrently. Each IoT device independently uses its built-in PUF circuit to perform challenge-response verification on the received request to confirm the legitimacy of the UAV.

[0054] This step has two significant features: first, it embodies an integrated mechanism of "authentication as transmission". In the single response message after verification, the IoT device not only completes the session key negotiation confirmation with the UAV, but also encapsulates the collected data encrypted with the new key and the parameters for the next identity update. This design of integrating authentication, key negotiation, data upload and state update in one interaction greatly reduces the communication rounds, achieves O(1) level constant communication overhead, and significantly improves the access efficiency in the scenario of a large number of devices.

[0055] Second, it has a built-in anti-desynchronization attack mechanism for credential rollback. This mechanism aims to address the state inconsistency problem between the UAV / IoT device and the GCS caused by unreliable wireless communication (such as message loss). Specifically, when one party (such as the UAV) locally updates its temporary identity, and the GCS does not update due to not receiving confirmation, in the next communication, the UAV can intelligently identify the "desynchronization" state by comparing the received old identity with the last version of the identity recorded by itself. Once identified, the UAV will actively trigger a rollback operation to roll back its identity state to the old version consistent with the GCS, thereby achieving self-healing of the protocol, ensuring long-term stable operation of the system, and avoiding permanent locking of the device. The anti-desynchronization attack mechanism for credential rollback is implemented through an authentication credential rollback logic, and the specific execution logic of the receiving entity (drone or IoT device) is as follows: (1) integrity check first: before any identity verification, the receiving entity first recalculates and verifies the integrity of the received identity verification message through a hash digest method to ensure that the message has not been tampered with; if the integrity check fails, the process is terminated directly; (2) double verification logic: after successful integrity check, the receiving entity first compares the authentication credentials in the message with its locally maintained "pending authentication credentials"; if the comparison fails, the receiving entity automatically compares it with the "submitted authentication credentials" maintained locally to identify whether there is a legitimate credential rollback request; (3) freshness verification: the double verification logic provides anti-replay protection by forcibly verifying the timestamp nonce in the message; (4) anomaly detection: each entity maintains an internal rollback counter, and if the identity verification repeatedly triggers the rollback to the "submitted authentication credentials" operation, and the counter exceeds the predefined threshold, the entity marks the link as abnormal.

[0056] Phase four: centralized verification and state synchronization phase

[0057] This phase is the final verification and state synchronization of the data collected by the GCS to the UAV.

[0058] Step DAIU3 (GCS final verification and update):

[0059] The GCS receives the message from the UAV message After that, the final verification and status update are performed: GCS first checks the validity of the timestamp . If it is expired, GCS will terminate the procedure. Otherwise, GCS retrieves the corresponding and information from the database and calculates . GCS verifies . If the verification fails, the procedure is terminated. If the verification succeeds, GCS calculates . GCS decrypts the ciphertext of the message using the session key to obtain all . If the decryption is successful, the temporary identity value of in the database is updated, and the used challenge-response pair is deleted. Then, GCS obtains IoT devices bound to from the database and performs the following operations for each device: Obtain the corresponding and

[0060] from the database according to . Decrypt the encrypted data using the session key to obtain the sensor-collected data

[0061] . Combine the information in to calculate

[0062] and verify . If the verification is passed, calculate . GCS updates its temporary identity value in the database.

[0063] Delete the used challenge-response pair . At this time, GCS further confirms the authenticity of the identity of the IoT device , completing the identity verification closed loop. This procedure effectively integrates identity authentication, temporary identity update, and sensor data collection into a multitask single-step operation.

[0064] Credential rollback anti-desynchronization attack mechanism

[0065]

[0066] ​​​​The application effectively solves the problem of inconsistent states between entities caused by abnormal wireless communication (such as the loss of a response message on the way to the GCS) through the built-in anti-desynchronization attack mechanism of the certificate rollback. Under this mechanism, in order to ensure system security, the rollback operation is not blindly triggered, but strictly follows the principles of "verification first, double comparison, and exception fuse". The specific scenarios are as follows: the UAV or IoT device has completed the calculation locally and updated the new identity (denoted as ), but the GCS still retains the old identity (denoted as ) in its database due to the failure to receive the update confirmation message. When the GCS subsequently initiates the next task request based on its possession of , the UAV's processing flow is as follows:

[0067] (1) Integrity and freshness verification: Before parsing the identity information, the UAV must first perform integrity verification (such as hash verification) on the received message to ensure that the message has not been tampered with, and verify the timestamp or random number to confirm the freshness of the message. Only when the message passes both integrity and freshness verification will the UAV start the identity comparison process, which effectively prevents attackers from using replayed old messages to maliciously induce system rollback.

[0068] (2) Double comparison and rollback identification: After verification, the UAV performs comparison and finds that the target identity in the message does not match the current , but immediately discovers that the identity matches the "last version identity" (denoted as ) maintained locally. This "current version mismatch, historical version match" result allows the UAV to immediately identify it as a legitimate desynchronization event rather than an attack.

[0069] (3) State rollback and self-healing: At this time, the UAV actively triggers the rollback operation to roll back its temporary identity state from to . As a result, the UAV and the GCS records are re-aligned without additional communication rounds, and both parties can continue the authentication process based on this consensus state.

[0070] (4) Abnormal detection: As a defensive measure, each entity maintains an internal rollback counter. If the system detects that the rollback operation to is triggered repeatedly and frequently within a short period of time, and the number of times exceeds the preset threshold, the system will determine that there is a malicious attack or persistent link failure, and automatically mark the link as abnormal to interrupt the potential attack cycle.

[0071] Assuming that in the i-th round of authentication, the identity of the UAV in the database of the GCS is (1) Desynchronization occurs: After authentication, the UAV successfully updates its identity locally to , and retains as ; however, the response message sent by the UAV to the GCS containing the update confirmation is lost in the link, causing the GCS to fail to update and remain at (2) Next round (i+1) initiation: The GCS sends a new authentication request to the UAV using TIDi. (3) Identification and processing: The UAV receives the message and first confirms that the message is unaltered and fresh by MAC check. Subsequently, it finds that in the message is not equal to its current , but is equal to its backup (4) Result: The UAV determines that desynchronization has occurred, and rolls back its local current identity to , successfully responding to the request. The system thus avoids deadlock due to mismatched keys.

[0072] Those skilled in the art will understand that embodiments of the present application can be provided as methods, systems, or computer program products. Thus, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0073] The present application is described in reference to the flowchart and / or block diagrams of the method, apparatus (system) and computer program product according to embodiments of the present application. It is understood that each flow and / or block in the flowchart and / or block diagrams, and a combination of flows and / or blocks in the flowchart and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, an embedded processor, or other programmable data processing apparatus to produce a machine, so that the instructions, which are executed via the processor of the computer or other programmable data processing apparatus, generate an apparatus that creates the functions specified in the flowchart and / or block diagrams of the flow or flows and / or blocks. Figure 1 The flowchart and / or block diagrams of the flow or flows and / or blocks Figure 1 The flowchart and / or block diagrams of the flow or flows and / or blocks

[0074] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, so that the instructions stored in the computer readable memory produce an article of manufacture including an instruction apparatus that implements the functions specified in the flowchart and / or block diagrams of the flow or flows and / or blocks. Figure 1 The flowchart and / or block diagrams of the flow or flows and / or blocks Figure 1 The flowchart and / or block diagrams of the flow or flows and / or blocks

[0075] These computer program instructions can also be loaded into a computer or other programmable data processing devices, so that a series of operational steps are performed on the computer or other programmable devices to generate a computer implemented process, so that the instructions executed on the computer or other programmable devices provide a process for implementing the flowchart Figure 1 one flowchart or multiple flowcharts and / or blocks Figure 1 one flowchart or multiple flowcharts and / or blocks

[0076] The above description is only the preferred embodiment of the present application, not other forms of the present application, any skilled in the art can use the above disclosed technical content to change or modify as equivalent embodiments of equivalent changes. But any simple modification, equivalent change and modification of the above embodiments without departing from the technical solution of the present application, according to the technical essence of the present application, still belongs to the protection scope of the technical solution of the present application.

Claims

1. A method for batch authentication and key negotiation in a drone-assisted Internet of Things, characterized in that, The process includes the system initialization and device registration phase, the pre-authorization phase based on physical non-cloning, the offline batch authentication and data acquisition phase, and the centralized verification and status synchronization phase, as detailed below: During the system initialization and device registration phase, the ground control station generates a system master key and public parameters; the ground control station assigns a unique real identity and an initial temporary identity to each UAV and target IoT device; the ground control station generates a Physically Unclonable Function (PUF) challenge set C for each entity; each entity, including the UAV and target IoT device, receives the challenge set C through a secure channel and generates a response set R through its built-in PUF circuit; each entity sends the response set R back to the ground control station, and the ground control station binds and stores the real identity, temporary identity, and challenge-response pairs. In the PUF-based pre-authorization phase, the ground control station generates and issues a short-term operating credential for the UAV according to a predetermined task. This credential includes at least one PUF challenge to verify the legitimacy of the UAV's physical entity, as well as authentication parameters pre-calculated for the target IoT device. After receiving the credential, the UAV uses its built-in PUF circuit to calculate the PUF challenge to generate a response, and completes authentication and session key establishment with the ground control station based on the response and its real identity, while simultaneously obtaining the authentication parameters of the target IoT device. During the offline batch authentication and data collection phase, the drone, without real-time communication with the ground control station, uses short-term operation credentials to broadcast authentication request messages to the target IoT device concurrently. Upon receiving an authentication request, each target IoT device uses its built-in PUF circuit to perform challenge-response based verification to confirm the legitimacy of the message source. After successful verification, it encapsulates the collected data encrypted with the negotiated session key and the parameters used to generate the temporary identity for the next cycle in a response message and sends it back to the drone. During the centralized verification and status synchronization phase, when the drone receives a message from the target IoT device, it performs preliminary authentication and verifies the legitimacy of the target IoT device one by one. After collecting all target IoT device information, the drone will send the collected response message back to the ground control station. Upon receiving the collected response message, the ground control station will perform centralized verification. If the verification is successful, it will synchronously update the temporary identities of the drone and the target IoT devices in its own database.

2. The method for batch authentication and key negotiation of a drone-assisted Internet of Things according to claim 1, characterized in that, The offline batch authentication and data collection phase is based on an integrated mechanism of authentication and transmission. In the response message of a single authentication interaction, the target IoT device simultaneously performs session key negotiation confirmation, encrypted data collection upload, and temporary identity update for the next cycle.

3. The method for batch authentication and key negotiation in a drone-assisted Internet of Things according to claim 1, characterized in that, The drone and the target IoT device maintain awareness of two credential states locally: the old authentication credential that has been submitted and the new authentication credential that is pending processing. When the initial authentication fails, the entity performs a consistency comparison based on the two credential states to distinguish between legitimate rollback and replay attacks, and automatically rolls back the temporary identity to the version before the update to re-establish synchronization.

4. The method for batch authentication and key negotiation of a drone-assisted Internet of Things according to claim 1, characterized in that, The specific method by which the ground control station establishes the physical security root of identity is as follows: for each legitimate drone and target IoT device, its unique digital identity is mathematically bound to a set of unique challenge-response pairs generated by the PUF circuit, and this binding relationship is stored in the database as its digital identity credential.

5. The method for batch authentication and key negotiation in a drone-assisted Internet of Things according to claim 1, characterized in that, The offline batch authentication and data collection stage also has a built-in credential rollback anti-desynchronization attack mechanism, as follows: The credential rollback anti-desynchronization attack mechanism is implemented through an authentication credential rollback logic. The specific execution logic of the receiving entity is as follows: (1) Integrity check first: Before performing any authentication, the receiving entity first recalculates and verifies the integrity of the received authentication message through the hash digest method to ensure that the message has not been tampered with; If the integrity check fails, the process will terminate. (2) Dual authentication logic: After the integrity check is successful, the receiving entity first compares the authentication credentials contained in the message with the authentication credentials to be processed maintained locally; if the comparison fails, the receiving entity automatically compares it with the submitted authentication credentials maintained locally to identify whether there is a legitimate credential rollback request; (3) Freshness verification: The dual authentication logic provides protection by forcibly verifying the timestamp random number in the message; (4) Anomaly detection: Each entity maintains an internal rollback counter. If the authentication repeatedly triggers the rollback to the submitted authentication credentials and the counter exceeds the predefined threshold, the entity marks the link as abnormal.

6. A batch authentication and key negotiation system for unmanned aerial vehicle-assisted Internet of Things (UAV) communication, characterized in that, The system includes a ground control station, a drone, and a target IoT device; both the drone and the target IoT device contain a Physically Unclonable Function (PUF) circuit; and the components of the system are configured to collaboratively perform the steps of a batch authentication and key negotiation method for a drone-assisted IoT as described in any one of claims 1-5.

Images