Equipment communication identity authentication method and related equipment

Abstract

The embodiment of the invention provides an equipment communication identity authentication method and related equipment, and belongs to the technical field of communication security. The method comprises the following steps: analyzing a received equipment authentication request to obtain first identity information of requesting equipment; querying and acquiring a dynamic credible factor of the request equipment according to the first identity information; determining the equipment credibility type of the request equipment according to the dynamic credibility factor; under the condition that the equipment credibility type is credible equipment, a first authentication strategy is adopted to authenticate the request equipment; the first authentication strategy is realized by verifying the digital signature based on an asymmetric encryption technology; under the condition that the equipment credible type is non-credible equipment, a first authentication strategy and a second authentication strategy are adopted to authenticate the request equipment; the second authentication policy is implemented based on an authentication protocol of challenge and response interaction. According to the invention, the equipment identity authentication efficiency and the equipment communication security can be improved.

Description

Technical Field

[0001] This application relates to the field of communication security technology, and in particular to a device communication identity authentication method and related equipment. Background Technology

[0002] Device communication authentication methods primarily revolve around cryptographic techniques and protocol interactions. Their core objective is to verify the true identities of both communicating parties (device to device, device to server) and establish a secure communication channel. Currently, a common device authentication method is to issue a unique digital identity (i.e., a digital certificate) to each device, using asymmetric encryption technology to verify this digital identity during communication. However, traditional communication authentication methods are simplistic and cannot simultaneously address both communication security and authentication efficiency. Summary of the Invention

[0003] The main objective of this application is to propose a device communication authentication method and related equipment, which aims to improve the efficiency of device authentication and the security of device communication.

[0004] To achieve the above objectives, one aspect of this application proposes a device communication authentication method, comprising the following steps:

[0005] The received device authentication request is parsed to obtain the first identity information of the requesting device; The dynamic trust factor of the requesting device is obtained by querying the first identity information; The device trust type of the requesting device is determined based on the dynamic trust factor; If the device is classified as a trusted device, a first authentication strategy is used to authenticate the requesting device; the first authentication strategy is based on asymmetric encryption technology to verify digital signatures. When the device is classified as an untrusted device, the first authentication strategy and the second authentication strategy are used to authenticate the requesting device; the second authentication strategy is implemented based on an authentication protocol that uses challenge and response interaction.

[0006] In some embodiments, the first identity information of the requesting device is represented by an identity-based IPv6 address, which is obtained through the following steps: Perform a hash operation on the device's MAC address to obtain the hardware fingerprint segment; The equipment manufacturers are encoded and mapped to obtain the manufacturer's code segment; Perform a cyclic redundancy check on the domain name to which the device belongs to obtain the domain identifier segment; The network prefix of the device, the hardware fingerprint segment, the vendor code segment, and the domain identifier segment are concatenated to obtain the identified IPv6 address.

[0007] In some embodiments, the dynamic trust factor is stored in a blockchain node, and the registration process of the requesting device in the blockchain node is as follows: The requesting device accesses the IPv6 network and generates first identity information represented by an identity-based IPv6 address, and sends the first identity information to the blockchain node; The blockchain node verifies the address structure and address validity of the first identity information. After the verification is successful, it initializes the dynamic trust factor of the requesting device and stores the first identity information and the dynamic trust factor together.

[0008] In some embodiments, the dynamic trust factor is updated through the following steps: Statistics include device registration duration, number of successful authentications in history, total number of authentications in history, and number of abnormal behaviors in history. The standard registration time and the degree of abnormal behavior are calculated by normalizing the device registration time and the number of historical abnormal behaviors, respectively; and the device authentication success rate is determined based on the number of historical successful authentications and the total number of historical authentications. The dynamic trust factor is determined and updated based on the standard registration duration, the device authentication success rate, and the degree of abnormal behavior.

[0009] In some embodiments, authenticating the requesting device using the first authentication strategy and the second authentication strategy includes the following steps: Receive a private key commitment and an address binding commitment from the requesting device; A randomly generated challenge value is sent to the requesting device, so that the requesting device calculates a private key response and an address binding response based on the challenge value; Private key ownership is verified based on the private key commitment and the private key response, and address binding relationship is verified based on the address binding commitment and the address binding response. If the private key ownership verification and address binding relationship verification are passed, the requesting device is confirmed to have passed the authentication of the second authentication policy.

[0010] In some embodiments, the device communication authentication method further includes the following steps: Determine whether the requesting device is a cross-domain device based on the domain identifier indicated in the first identity information; In the case that the requesting device is a cross-domain device, determine the domain credibility score of the domain to which the requesting device belongs; The domain trust type of the domain to which the requesting device belongs is determined based on the domain trust score; When the domain trust type is a trusted domain, the lightweight identity data of the requesting device in the domain to which the requesting device belongs is synchronized to the target domain. The lightweight identity data includes the hash value of the identity-based IPv6 address and the device public key, and a dynamic trust factor.

[0011] In some embodiments, the device communication authentication method further includes the following steps: Perform address structure verification on the first identity information represented by an identity-based IPv6 address; If the address structure verification fails, it is determined that the overall authentication result of the requesting device fails. If the address structure verification passes, the step of querying and obtaining the dynamic trust factor of the requesting device based on the first identity information is executed to obtain the dynamic authentication result; If the dynamic authentication result indicates failure, it is determined that the overall authentication result of the requesting device has failed. If the dynamic authentication result indicates that the requesting device has passed, determine whether the domain to which the requesting device belongs is a trusted domain; If the domain to which the requesting device belongs is not a trusted domain, it is determined that the overall authentication result of the requesting device fails. If the domain to which the requesting device belongs is a trusted domain, the overall authentication result of the requesting device is determined to be successful.

[0012] To achieve the above objectives, another aspect of this application proposes a device communication authentication system, comprising: The parsing module is used to parse the received device authentication request to obtain the first identity information of the requesting device; A device trust assessment model is used to query and obtain the dynamic trust factor of the requesting device based on the first identity information; and to determine the device trust type of the requesting device based on the dynamic trust factor. The dynamic authentication module is used to authenticate the requesting device using a first authentication strategy when the device's trust type is a trusted device; the first authentication strategy is implemented based on asymmetric encryption technology to verify digital signatures; or, when the device's trust type is an untrusted device, the first authentication strategy and a second authentication strategy are used to authenticate the requesting device; the second authentication strategy is implemented based on an authentication protocol of challenge and response interaction.

[0013] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method.

[0014] To achieve the above objectives, another aspect of the embodiments of this application proposes a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0015] The embodiments of this application include at least the following beneficial effects: This application provides a device communication identity authentication method, system, electronic device, and program product. This scheme first parses the received device authentication request to obtain the first identity information of the requesting device. Then, it queries and obtains the dynamic trust factor of the requesting device based on the first identity information, and further determines the device trust type based on the dynamic trust factor. The dynamic trust factor can characterize the real-time trustworthiness of the device, improving the accuracy of subsequent identification of devices with abnormal behavior, thereby enhancing communication security. For trusted devices, a first authentication strategy is used for authentication. The first authentication strategy is based on asymmetric encryption technology to verify digital signatures, resulting in a simple authentication process and high authentication efficiency. For untrusted devices, a dual authentication strategy is used, employing both the first and second authentication strategies. The second authentication strategy is based on a challenge-response interaction authentication protocol, providing higher security. This scheme distinguishes between trusted and untrusted devices through dynamic trust factors and then adaptively selects the appropriate strategy for authentication, balancing device identity authentication efficiency and device communication security. Attached Figure Description

[0016] Figure 1 This is a flowchart of the device communication authentication method provided in the embodiments of this application; Figure 2 This is a flowchart of the identity-based IPv6 address generation process provided in an embodiment of this application; Figure 3 This is a flowchart illustrating the registration process of a device in a blockchain node according to an embodiment of this application. Figure 4 This is a flowchart of the dynamic trust factor update calculation provided in the embodiments of this application; Figure 5 This is a flowchart illustrating the implementation of the second authentication strategy provided in this application embodiment; Figure 6 This is a flowchart of a device communication authentication method provided in another embodiment of this application; Figure 7 This is a flowchart illustrating the overall technical process for establishing communication using the device provided in this application embodiment; Figure 8 This is a deployment architecture diagram provided in the embodiments of this application; Figure 9 This is a schematic diagram of the device communication identity authentication system provided in the embodiments of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0019] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0020] Identity-based IPv6 addresses refer to a technical solution that embeds user identification information (such as username, account, etc.) into the address structure during the generation and allocation of IPv6 addresses. In some embodiments of this application, the device hardware fingerprint (MAC hash), manufacturer code, and domain identifier are embedded into the network address of the IPv6 interface identifier (IID) field through structured encoding, realizing the native binding of "address as identity". The format is network prefix + hardware fingerprint segment + manufacturer code segment + domain identifier segment.

[0021] The dynamic trust factor (TF) refers to an indicator or parameter used to dynamically and quantitatively characterize the trustworthiness of a communication device at a specific moment or in a specific context. In some embodiments of this application, the dynamic trust factor can be a trust quantification calculated based on device registration time, historical authentication success rate, and number of abnormal behaviors, used to dynamically adjust the complexity of the authentication process.

[0022] ZKP-IPv6 Binding Protocol is a security authentication protocol that integrates Zero-Knowledge Proof (ZKP) with IPv6 address binding mechanism. The prover can prove "possessing a legitimate private key" and "IPv6 address identity binding relationship" simultaneously without disclosing sensitive information, reducing communication rounds.

[0023] Domain trust score (Score(D)) refers to an evaluation system and method used to dynamically and quantitatively assess the overall trustworthiness of an autonomous domain (such as an organization, a cloud service region, an IoT management domain, or a network autonomous system) in a multi-domain, distributed network environment. In some embodiments of this application, the domain trust score may refer to an inter-domain trust index calculated based on cross-domain interaction records and the average trust factor of devices within the domain, used for cross-domain authentication trust transfer.

[0024] This application provides a device communication identity authentication method and related equipment. The scheme distinguishes between trusted and untrusted devices through dynamic trust factors, and then adaptively selects the corresponding strategy for authentication, which can balance device identity authentication efficiency and device communication security.

[0025] The device communication authentication method provided in this application relates to the field of communication security technology. This device communication authentication method can be applied to a terminal, a server, or software running on a terminal or server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, smart speaker, smartwatch, or vehicle terminal, but is not limited to these. The server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. The server can also be a node server in a blockchain network. The software can be an application implementing the device communication authentication method, but is not limited to the above forms.

[0026] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics devices, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0027] According to some embodiments of this application, the device communication authentication method of this application can be implemented based on the following network scenarios: Device A, acting as the requesting device, initiates a device authentication request; Device B, acting as the responding device, responds to the authentication request and authenticates Device A. If Device A passes authentication, Device A and Device B establish a session channel for communication. The device communication authentication method of this embodiment is primarily applied to the responding device, namely Device B. Device A and Device B may belong to the same domain or different domains. In each domain, blockchain technology can be used to provide data storage and query services; that is, any device in the domain can be constructed as a blockchain node. The following embodiments use Device A and Device B as examples to illustrate the technical solution of this embodiment.

[0028] Figure 1 This is an optional flowchart of the device communication authentication method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S105.

[0029] S101, parse the received device authentication request to obtain the first identity information of the requesting device; S102, query and obtain the dynamic trust factor of the requesting device based on the first identity information; S103, determine the device trust type of the requesting device based on the dynamic trust factor; S104, when the device trust type is trusted device, the first authentication strategy is used to authenticate the requesting device; the first authentication strategy is based on asymmetric encryption technology to verify the digital signature. S105, when the device trust type is untrusted device, the first authentication strategy and the second authentication strategy are used to authenticate the requesting device; the second authentication strategy is implemented based on the authentication protocol of challenge and response interaction.

[0030] Steps S101 to S105 as illustrated in this embodiment of the application utilize dynamic trust factors to characterize the real-time trustworthiness of a device, thereby improving the accuracy of subsequent identification of devices exhibiting abnormal behavior and ultimately enhancing communication security. By using dynamic trust factors to distinguish between trusted and untrusted devices and then adaptively selecting appropriate authentication strategies, both device authentication efficiency and device communication security can be balanced.

[0031] In step S101 of some embodiments, device A initiates a device authentication request to device B. The device authentication request may include the identity information (i.e., first identity information) and address of device A and the address of device B. The identity information and address may be represented together in a string (such as an identity-based IPv6 address) or separately. The identity information is the unique identifier of the device and may be the device MAC address.

[0032] In step S102 of some embodiments, device A queries the blockchain node in the domain based on the first identity information to obtain the dynamic trust factor of device B. If device A and device B belong to the same domain, device A directly queries the blockchain node in the domain; if device A and device B do not belong to the same domain, it is necessary to migrate the identity-related data (including the dynamic trust factor) of device B in the blockchain node of its own domain to the blockchain node of device A's own domain, and then device A queries the blockchain node of its own domain for the dynamic trust factor of device B.

[0033] In step S103 of some embodiments, device A determines the trust type of the requesting device (i.e., device B) by performing a threshold determination based on the dynamic trust factor of device B. The device trust type is divided into trusted devices and untrusted devices. Further, untrusted devices can be further divided into ordinary trusted devices and low-trusted devices. For example, if the dynamic trust factor TF ≥ 0.6, device B is considered a trusted device (i.e., a high-trusted device); if TF < 0.6, device B is considered an untrusted device. Specifically, if 0.3 < TF < 0.6, device B is considered an ordinary trusted device; and if TF ≤ 0.3, device B is considered a low-trusted device.

[0034] In step S104 of some embodiments, for highly trusted devices, a first authentication strategy can be used to authenticate them. The first authentication strategy is implemented based on asymmetric encryption technology to verify digital signatures and verify address legitimacy.

[0035] In step S105 of some embodiments, for untrusted devices, a first authentication strategy and a second authentication strategy are used for authentication. The second authentication strategy is implemented based on an authentication protocol based on challenge-response interaction. Exemplarily, embodiments of this application can be implemented based on the ZKP-IPv6 binding protocol proposed in embodiments of this application, which will be described later.

[0036] For example, the overall process of device A requesting authentication from device B is as follows: S11. Device A sends a device authentication request to Device B. The device authentication request is expressed as: (Addr_A, Addr_B, TS, E_{Pk_B}(SESS_KEY), Sign_{Sk_A}); where Addr_A represents the first identity information of Device A, Addr_B represents the second identity information of Device B, and both the first identity information and the second identity information are in the form of an individualized IPv6 address; TS represents a timestamp; E_{Pk_B}(SESS_KEY) represents encrypting the session key SESS_KEY using the public key Pk_B of Device B. SESS_KEY is a temporarily generated symmetric key used to encrypt data in subsequent communications to ensure the confidentiality of the communication; Sign_{Sk_A} represents a digital signature, that is, using the private key Sk_A of Device A to sign the entire request or key parts of the request, such as Addr_A, Addr_B, TS, E_{Pk_B}(SESS_KEY)).

[0037] S12. Device B queries the blockchain node to obtain TF_A (i.e., the dynamic trust factor of Device A), and determines the trust level of Device A and selects the corresponding authentication strategy as follows: Highly trusted device (TF≥0.6): Skip the authentication of the second authentication strategy and only use the first authentication for authentication, that is, skip the authentication link based on the ZKP-IPv6 binding protocol, and only verify the digital signature and address legality. The authentication time is shortened to 80ms; Normally trusted device (0.3<TF<0.6): It is necessary to further use the second authentication strategy for authentication, that is, execute the complete ZKP-IPv6 protocol verification to verify the private key ownership and address binding relationship. Only when the digital signature and address legality verification and the ZKP-IPv6 protocol verification are passed, the dynamic authentication result based on the dynamic trust factor is considered to pass.

[0038] Lowly trusted device (TF≤0.3): On the basis of executing the complete ZKP-IPv6 protocol verification, an additional "on-chain verification of device behavior logs" link is added, and the authentication can only pass after there is no abnormal behavior record.

[0039] In this embodiment, the traditional algorithm uses a static trust level (such as "trusted upon registration") and cannot cope with changes in device behavior; in this embodiment, the dynamic trust factor of the device is updated in the blockchain node, and the abnormal device interception rate is increased from 15% to 95%, while avoiding over-verification of highly trusted devices.

[0040] According to some embodiments of the present application, the first identity information of the requesting device is represented by an individualized IPv6 address. Please refer to Figure 2 , and the individualized IPv6 address can be obtained through but not limited to the following steps: S201, perform a hash operation on the device's MAC address to obtain the hardware fingerprint segment; S202, perform encoding mapping on the equipment manufacturer to obtain the manufacturer encoding segment; S203, Perform cyclic redundancy check on the domain name to which the device belongs to obtain the domain identifier segment; S204 concatenates the network prefix, hardware fingerprint segment, vendor code segment, and domain identifier segment of the device to obtain an identified IPv6 address.

[0041] Traditional solutions employ a dual system of "custom identity identifier (such as UUID) + IPv6 address," requiring the additional design of identifier-address mapping algorithms (such as DNS-SD, CoAP resource discovery). This mapping process increases authentication time by more than 30%, and the mapping relationship is easily tampered with, posing a risk of identity forgery. For example, in the Industrial Internet of Things (IIoT), a sensor can bypass authentication and access the system by forging a UUID and mapping it to a legitimate IPv6 address.

[0042] Based on this, this application presents an identity-based IPv6 address encoding algorithm to achieve native binding between address and identity. In the entire communication authentication process, identity-based IPv6 addresses are used to jointly represent the identity and address information of the requesting and responding devices, which can eliminate additional mapping steps and reduce authentication time by more than 30%.

[0043] The specific IPv6 address encoding algorithm for identity verification in this application embodiment is as follows: 1) Field splitting: The 64-bit Interface Identifier (IID) of the IPv6 address is split into 3 functional segments: Hardware fingerprint segment (24 bits): The first 24 bits of the device MAC address are taken after performing SHA-256 hash, and are denoted as H(MAC); Manufacturer code segment (16 bits): Uses the manufacturer code assigned by the International Organization for Standardization (ISO) (e.g., "TechCorp" corresponds to code 0x1A3F); Domain Identifier (24 bits): The first 24 bits of the domain name to which the device belongs (e.g., “Factory-D1”) are taken after CRC32 verification and recorded as CRC(DID); 2) Address Generation: A complete IPv6 address is generated by concatenating the following segments: "Network prefix (64 bits) + Hardware fingerprint (24 bits) + Vendor code (16 bits) + Domain identifier (24 bits)". Mathematically, this is expressed as: Addr=Prefix||H(MAC)||MFR||CRC(DID); The symbol || indicates field concatenation, for example: 2001:db8:1::[H(MAC)=0x123456][MFR=0x1A3F][CRC(DID)=0x789ABC]→complete address 2001:db8:1::123456:1A3F:789ABC).

[0044] According to some embodiments of this application, the dynamic trust factor of each device is stored in the blockchain node of its domain. Please refer to... Figure 3 The process for requesting device registration in the blockchain node is as follows: S301, Request the device to access the IPv6 network and generate first identity information represented by an identity-based IPv6 address, and send the first identity information to the blockchain node; S302, the blockchain node verifies the address structure and address legality of the first identity information. After the verification is successful, it initializes the dynamic trust factor of the requesting device and associates and stores the first identity information and the dynamic trust factor.

[0045] For example, the registration process of device A in the blockchain node is as follows: S21, Device A accesses the IPv6 network and generates an IPv6 address containing identity information through the aforementioned identity-based IPv6 address encoding algorithm. S22, Device A generates a key pair (Pk_A, Sk_A), which integrates the device IPv6 address, device MAC address, device manufacturer and domain identifier to form identity data D_A; where Pk_A is the public key of device A and Sk_A is the private key of device A.

[0046] S23, the blockchain node verifies the address structure through the address validity verification algorithm, and then associates a set of identity data and dynamic trust factor with the storage device A, namely storage (Addr_A,Pk_A,H(D_A),TF_init=0.5) (TF_init is the initial trust factor).

[0047] In this embodiment, the address validity verification algorithm is as follows: the blockchain node verifies the address structure through a preset algorithm—verifying whether H (MAC) is consistent with the MAC hash uploaded by the device, whether MFR is in the ISO legitimate vendor list, and whether CRC (DID) matches the domain identifier. Only when the verification is passed can the identity verification be completed.

[0048] Traditional algorithms often use only random or simple MAC-based mappings for IPv6 addresses (such as EUI-64), lacking a structured identity design. This embodiment endows the address itself with identity attributes, completing the "address-identity" binding during the registration phase, eliminating the need for additional mappings during subsequent authentication.

[0049] According to some embodiments of this application, please refer to Figure 4 The dynamic trust factor stored in the blockchain node can be updated through, but is not limited to, the following steps: S401, Statistics on device registration duration, number of successful authentications in history, total number of authentications in history, and number of abnormal behaviors in history; S402, normalize the device registration time and the number of historical abnormal behaviors to obtain the standard registration time and the degree of abnormal behavior; and determine the device authentication success rate based on the number of historical successful authentications and the total number of historical authentications. S403 determines and updates dynamic trust factors based on standard registration duration, device authentication success rate, and degree of abnormal behavior.

[0050] Traditional distributed authentication schemes often employ a "one-time identity registration + fixed trust level" mechanism, lacking dynamic trust assessment algorithms. For example, a device may be trusted during initial registration, but subsequently experience multiple authentication failures. The system still processes these failures based on the initial trust level, failing to promptly intercept risks and resulting in an abnormal access rate exceeding 15%.

[0051] This application proposes a dynamic trust factor (TF) calculation algorithm. In the blockchain, the dynamic trust factor of a device is adjusted based on factors such as the real-time behavior of the device, which can improve the interception rate of abnormal devices to over 95%.

[0052] For example, the dynamic trust factor (TF) in this application embodiment is calculated using the following formula: TF=α×(t / T)+β×(S / S_total)-γ×(E / E_threshold); Where t represents the device registration duration (in days); T represents the baseline duration used for normalization (which can be set to 365 days); α represents the registration duration weight to avoid excessive distrust of new devices, for example, α=0.3. S represents the number of successful authentications in the device's history; S_total represents the total number of authentications in the device's history; β represents the authentication success rate weight, which is a core credibility indicator, and the authentication success rate weight can be a large value, such as β=0.5. E represents the number of historical abnormal behaviors (abnormal behaviors can be signature failures, timestamp anomalies, etc.); E_threshold represents the abnormal threshold used for normalization (for example, the abnormal threshold can be set to 5 times); γ represents the abnormal behavior weight to control the spread of risk, for example, γ=0.2.

[0053] According to some embodiments of this application, please refer to Figure 5 The second authentication strategy process in step S105 may include, but is not limited to, the following steps: S501, Receive private key commitment and address binding commitment from the requesting device; S502, a randomly generated challenge value is sent to the requesting device so that the requesting device can calculate the private key response and address binding response based on the challenge value; S503, verify private key ownership based on private key commitment and private key response, and verify address binding relationship based on address binding commitment and address binding response; S504, after verifying the private key ownership and address binding relationship, confirms that the requesting device has passed the authentication of the second authentication policy.

[0054] Currently, zero-knowledge proof algorithms have poor adaptability. Traditional privacy protection schemes directly apply general zero-knowledge proof algorithms (such as Groth16), resulting in numerous interaction rounds (≥4 rounds) and high computational complexity (single proof time exceeding 500ms), which cannot meet the low-latency requirements (≤200ms) of industrial control and other scenarios. This embodiment optimizes the adaptability of zero-knowledge proof algorithms by combining actual private key and address binding relationship verification requirements and innovatively proposes the ZKP-IPv6 binding protocol (i.e., the second authentication strategy), reducing the number of interaction rounds (from 4 rounds to 2 rounds), and controlling the single proof time to within 100ms, thus meeting the requirements of low-latency scenarios.

[0055] The ZKP-IPv6 binding protocol algorithm aims to simultaneously prove that "the device possesses a legitimate private key" and "the IPv6 address identity binding relationship" while protecting privacy, reducing the number of interaction rounds. Compared to traditional algorithms that require four rounds of interaction, the embodiments of this application only require two rounds of interaction to verify the legitimacy of the private key and the address binding relationship. The specific algorithm implementation process is as follows: 1) Commitment Phase (Round 1): The prover (device A) generates a random number r and calculates: Private key commitment: C1 = g^r × Pk_A^r1 (g is the base point of the elliptic curve, Pk_A is the public key of device A, and r1 is a random number); Address binding commitment: C2 = H(Addr_A)^r × CRC(DID_A)^r2 (H(Addr_A) is the hash of device A's address, DID_A is the domain identifier, and r2 is a random number). Send (C1,C2) to the verifier (device B); 2) Challenge and Proof Phase (Round 2): The verifier generates a random challenge value c and sends it to the prover; The prover calculates the response value: Private key response: s1 = r + c × x_A (x_A is the private key of device A, corresponding to the public key Pk_A = g^x_A); Address binding response: s2 = r + c × y_A (y_A is the address binding key, which satisfies H(Addr_A) = CRC(DID_A)^y_A); Send (s1,s2) to the verifier; 3) Verification phase: Verifier verification: If the private key commitment and private key response satisfy the formula g^s1=C1×Pk_A^c, then the private key ownership is verified. If the address binding commitment and address binding response satisfy the formula H(Addr_A)^s2=C2×CRC(DID_A)^c, then the address binding relationship is verified. If both checks pass, the application is considered valid.

[0056] Traditional zero-knowledge proofs only verify the ownership of the private key and require an additional algorithm to verify the legitimacy of the address. This protocol integrates the two verification methods, reducing the number of interaction rounds by 50% and the time taken for a single proof from 500ms to 100ms, thus meeting the low latency requirements.

[0057] According to some embodiments of this application, please refer to Figure 6 The device communication authentication method in this application embodiment may also include, but is not limited to, the following steps: S601, determine whether the requesting device is a cross-domain device based on the domain identifier indicated in the first identity information; S602, when the requesting device is a cross-domain device, determine the domain trust score of the domain to which the requesting device belongs; S603, determine the domain trust type of the domain to which the requesting device belongs based on the domain trust score; S604, when the domain trust type is trusted domain, synchronize the lightweight identity data of the requesting device in the domain to which the requesting device belongs to the target domain. The lightweight identity data includes the hash value of the identity IPv6 address and the device public key and the dynamic trust factor.

[0058] Currently, authentication between different IoT platforms (i.e., cross-domain devices) requires trust transfer through a third-party intermediary server, which poses a "single point of failure" risk. Furthermore, the full identity data synchronization algorithm results in high bandwidth overhead for cross-domain authentication (≥1KB of synchronized data per device), making it unusable in narrowband IoT (NB-IoT) scenarios. Therefore, this application's embodiments design a distributed domain trust scoring and lightweight evidence storage synchronization algorithm to achieve intermediary-free cross-domain authentication, reducing cross-domain bandwidth overhead by 80% (≤200B of synchronized data per device).

[0059] The distributed domain credibility scoring (Score(D)) and lightweight evidence storage synchronization algorithm proposed in this application are as follows: 1) Formula for calculating the domain credibility score (D): Score(D)=e×(S_cross / S_cross_total)+k×(TF_avg); Where e and k are weighting coefficients, e can be 0.7 (corresponding to the core cross-domain trust index), and k can be 0.3 (reflecting the overall trustworthiness of devices within the domain). S_cross represents the number of successful cross-domain authentications in the history of domain D; S_cross_total represents the total number of cross-domain authentications in the history of domain D. TF_avg represents the average dynamic trust factor of all devices within domain D. Score(D) ranges from 0 to 1.

[0060] If Score(D) ≥ 0.8 (or other thresholds), domain D is considered a trusted domain, and the identity verification of devices within that domain can be directly trusted.

[0061] 2) The lightweight evidence storage and synchronization algorithm is as follows: During cross-domain authentication, the trusted domain (Score(D)≥0.8) only needs to synchronize the following lightweight identity data with the target domain: Device identity data hash: H(D_A) = SHA-256(Addr_A||Pk_A||DID_A); The device's current trust factor: TF_A; The target domain (i.e., the domain where the responding device is located) queries the blockchain to see if H(D_A) exists. If it exists and TF_A≥0.3, then there is no need to synchronize the full identity data, and the verification can be done directly through the evidence storage.

[0062] Traditional cross-domain algorithms rely on an intermediary server to synchronize all data (bandwidth overhead ≥ 1KB / device); in the case of cross-domain authentication, this application embodiment does not use an intermediary and only synchronizes hash and TF value (bandwidth overhead ≤ 200B / device), instead of all identity information. Data integrity is ensured through hash consistency verification, reducing cross-domain authentication bandwidth by 80%, and can be used normally in narrowband IoT scenarios.

[0063] For example, the cross-domain authentication process between device A and device B is as follows: S31. If device A and device B belong to different domains, the domain in which device B is located (which can be any of the devices) calculates Score(D_A) using the "Distributed Domain Trustworthiness Scoring Algorithm". S32. If Score(D_A)≥0.8, the domain where device B is located synchronizes H(D_A) and TF_A to the domain where device A is located (i.e., the target domain) through the "lightweight evidence storage synchronization algorithm". Cross-domain authentication is completed when the target domain verifies the synchronized data.

[0064] According to some embodiments of this application, the device communication authentication method of this application may also include, but is not limited to, the following steps: S701, perform address structure verification on the first identity information represented by the identity-based IPv6 address; S702, if the address structure verification fails, it is determined that the overall authentication result of the requesting device fails; S703, if the address structure verification passes, execute the step of querying and obtaining the dynamic trust factor of the requesting device based on the first identity information to obtain the dynamic authentication result; the dynamic authentication result refers to the authentication result of the requesting device obtained by executing steps S101 to S105, that is, if the requesting device is a trusted device, the dynamic authentication result is passed as long as the authentication is passed based on the first authentication strategy, and if the requesting device is an untrusted device, the dynamic authentication result is passed as long as the authentication is passed based on both the first authentication strategy and the second authentication strategy.

[0065] S704, if the dynamic authentication result indicates failure, determine that the overall authentication result of the requesting device fails; S705, if the dynamic authentication result indicates that the requesting device belongs to a trusted domain; S706, if the domain to which the requesting device belongs is not a trusted domain, determine that the overall authentication result of the requesting device fails; S707: If the domain to which the requesting device belongs is a trusted domain, the overall authentication result of the requesting device is deemed successful.

[0066] Traditional authentication methods rely solely on the "signature verification result" for decision-making, failing to incorporate factors such as device behavior and inter-domain trust. This results in a high false positive rate (over 8% false rejection rate for legitimate devices), impacting system availability. This application proposes a multi-factor authentication decision-making algorithm that integrates multiple dimensional indicators to determine authentication results, thereby reducing the false positive rate.

[0067] The logical representation of the multi-factor authentication decision algorithm in this embodiment is as follows: Decision=IF (Verify_Sign∧Check_Addr∧(TF_A≥0.6∨(Verify_ZKP∧Score(D_A)≥0.8))) THEN PassELSEReject; Among them, Verify_Sign indicates that the device's digital signature verification is successful; Check_Addr indicates that the identity-based IPv6 address structure verification is successful; TF_A≥0.6 indicates that the device is a highly trusted device and can skip the ZKP-IPv6 protocol verification process; Verify_ZKP indicates that the ZKP-IPv6 protocol verification is successful; Score(D_A)≥0.8 indicates that the device's domain needs to be a trusted domain to enhance identity trustworthiness.

[0068] Traditional algorithms rely solely on a single condition, "signature verification," resulting in a false rejection rate exceeding 8%. This embodiment integrates five dimensions of conditions, reducing the false rejection rate to below 1% while ensuring manageable risk.

[0069] Furthermore, device B outputs a Decision according to the "multi-factor authentication decision algorithm." If successful, communication is established; otherwise, an anomaly is recorded. (Addr_A, Addr_B, TS, TF_A, Score(D_A), Decision) is stored in the blockchain for subsequent TF updates and auditing.

[0070] This application's embodiments employ five innovative algorithms throughout the entire process of "identity registration - authentication request - verification decision - cross-domain collaboration - record storage," forming a technical route completely different from existing technologies. The IoT intelligent agent identity authentication technology based on these innovative algorithms is suitable for large-scale multi-domain collaborative scenarios such as industrial IoT, smart homes, and vehicle-to-everything (V2X) networks, and can solve problems in existing technologies such as the disconnect between identity and addressing, low authentication efficiency, and poor cross-domain compatibility.

[0071] Please refer to the following. Figure 7 The overall flowchart and technical process for establishing communication between devices are as follows: First, the device generates an identity-based IPv6 address, and then performs identity verification and TF initialization on the blockchain node. When communication is required, the requesting device initiates an authentication request to the responding device. The responding device requests the dynamically updated device TF value from the blockchain node. The responding device determines whether "TF≥0.6" is true. If it is, ZKP authentication is skipped; otherwise, ZKP-IPv6 protocol authentication is performed. The responding device determines whether the requesting device is communicating across domains. If it is, the domain trust score of the requesting device's domain is calculated and lightweight data synchronization is performed; otherwise, direct verification is performed. A comprehensive authentication judgment is made through a multi-factor decision algorithm. If successful, communication is established; otherwise, an exception is recorded and the process ends.

[0072] According to some embodiments of this application, the methods of this application embodiment can be deployed as follows: Figure 8 The architecture shown is divided into three layers from top to bottom: algorithm layer, module layer, and application layer. Algorithm layer: includes identity-based IPv6 encoding algorithm, dynamic TF calculation algorithm, ZKP-IPv6 protocol algorithm, domain trust scoring algorithm, and multi-factor decision algorithm; Module layer: Corresponds to the deployment of address encoding module, trust assessment module, ZKP protocol module, cross-domain trust module, and decision control module; Application layer: Connects to scenarios such as industrial IoT, smart home, and vehicle networking, and provides authentication services.

[0073] The address encoding module deploys an "identified IPv6 address encoding algorithm" to generate addresses and verify their legitimacy; the trust assessment module deploys a "dynamic trust factor calculation algorithm" to update the device's TF value in real time and determine its trust level; the ZKP protocol module deploys a "ZKP-IPv6 binding protocol algorithm" to complete privacy protection and identity binding verification; the cross-domain trust module deploys a "domain trust scoring algorithm" and a "lightweight evidence storage and synchronization algorithm" to achieve cross-domain authentication without intermediaries; and the decision control module deploys a "multi-factor authentication decision algorithm" to output authentication results and control the process flow.

[0074] Example: Taking cross-domain authentication between sensor A (domain D1) and controller B (domain D2) in an industrial Internet of Things as an example, the details are as follows: Address generation: Sensor A's MAC address is 00:11:22:33:44:55, H(MAC)=0x123456; Manufacturer code is 0x1A3F; Domain D1 identifier CRC=0x789ABC; Network prefix is ​​2001:db8:1::, generated address is 2001:db8:1::123456:1A3F:789ABC; TF calculation: A registered for 180 days (t=180), successfully authenticated 100 times (S=100), with a total of 102 authentications (S_total=102), and 1 exception (E=1); TF = 0.3 × (180 / 365) + 0.5 × (100 / 102) - 0.2 × (1 / 5) ≈ 0.148 + 0.490 - 0.04 = 0.598, Sensor A is a common and reliable device; Cross-domain score: Domain D1 successfully crossed domains 80 times (S_cross=80), with a total of 85 cross-domain attempts (S_cross_total=85), and an average TF of 0.62 within the domain; Score(D1) = 0.7 × (80 / 85) + 0.3 × 0.62 ≈ 0.659 + 0.186 = 0.845, domain D1 belongs to the trusted domain; ZKP verification: A and B execute the ZKP-IPv6 protocol, and the verification is successful after 2 rounds of interaction; Multi-factor decision: Verify_Sign=Pass ∧Check_Addr=Pass ∧Verify_ZKP=Pass ∧Score(D1)=0.845≥0.8→Decision=Pass; Verification results: Authentication time, bandwidth consumption and other indicators meet expectations, there is no privacy leakage, and it meets the needs of industrial scenarios.

[0075] According to some embodiments of this application, the methods of this application have at least one of the following beneficial effects: 1. Fundamental differences at the algorithm level: Breaking through the traditional "identity-addressing separation" algorithm framework, it innovates the identity-based IPv6 encoding algorithm, enabling addresses to natively possess identity attributes, significantly improving authentication efficiency, and eliminating the risk of mapping tampering; 2. Advantages of dynamic trust assessment: The dynamic trust factor algorithm updates the device trust in real time, which greatly improves the interception rate of abnormal devices, while simplifying the verification of high-trust devices, thus balancing security and efficiency. 3. Improved Zero-Knowledge Proof Adaptability: The ZKP-IPv6 binding protocol reduces the number of interaction rounds from 4 to 2, significantly reducing proof time and meeting the needs of low-latency scenarios (such as industrial control). 4. Breakthrough in cross-domain algorithm compatibility: Distributed domain trust and lightweight synchronization algorithm enable cross-domain authentication without intermediaries, significantly reducing bandwidth overhead and allowing normal use in narrowband IoT scenarios; 5. Reduced false rejection rate of decision-making algorithm: The multi-factor decision-making algorithm integrates five dimensions of indicators, which significantly reduces the false rejection rate of legitimate devices, improving system availability and user experience.

[0076] Please refer to Figure 9 This application also provides a device communication identity authentication system, including: The parsing module is used to parse the received device authentication request to obtain the first identity information of the requesting device; The device trust assessment model is used to query and obtain the dynamic trust factor of the requesting device based on the first identity information; and to determine the device trust type of the requesting device based on the dynamic trust factor. The dynamic authentication module is used to authenticate the requesting device using a first authentication strategy when the device's trust type is trusted; the first authentication strategy is implemented based on asymmetric encryption technology to verify digital signatures; or, when the device's trust type is untrusted, it is used to authenticate the requesting device using both the first and second authentication strategies; the second authentication strategy is implemented based on an authentication protocol with challenge and response interaction.

[0077] It is understood that the methods described in the above method embodiments are applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0078] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0079] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0080] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 902 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0081] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method.

[0082] It is understood that the content of the above method embodiments is applicable to this storage medium embodiment. The specific functions implemented in this storage medium embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0083] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0084] It is understood that the content of the above method embodiments is applicable to the embodiments of this program product. The specific functions implemented by the embodiments of this program product are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0085] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0086] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0087] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0088] The system embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0089] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0090] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0091] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0092] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative; for instance, the division of modules described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0093] The modules described above as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0094] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0095] If the integrated modules are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0096] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A device communication authentication method, characterized in that, Includes the following steps: The received device authentication request is parsed to obtain the first identity information of the requesting device; The dynamic trust factor of the requesting device is obtained by querying the first identity information; The device trust type of the requesting device is determined based on the dynamic trust factor; If the device is classified as a trusted device, a first authentication strategy is used to authenticate the requesting device; the first authentication strategy is based on asymmetric encryption technology to verify digital signatures. When the device is classified as an untrusted device, the first authentication strategy and the second authentication strategy are used to authenticate the requesting device; the second authentication strategy is implemented based on an authentication protocol that uses challenge and response interaction.

2. The device communication authentication method according to claim 1, characterized in that, The first identity information of the requesting device is represented by an identity-based IPv6 address, which is obtained through the following steps: Perform a hash operation on the device's MAC address to obtain the hardware fingerprint segment; The equipment manufacturers are encoded and mapped to obtain the manufacturer's code segment; Perform a cyclic redundancy check on the domain name to which the device belongs to obtain the domain identifier segment; The network prefix of the device, the hardware fingerprint segment, the vendor code segment, and the domain identifier segment are concatenated to obtain the identified IPv6 address.

3. The device communication authentication method according to claim 1, characterized in that, The dynamic trust factor is stored in the blockchain node, and the registration process of the requesting device in the blockchain node is as follows: The requesting device accesses the IPv6 network and generates first identity information represented by an identity-based IPv6 address, and sends the first identity information to the blockchain node; The blockchain node verifies the address structure and address validity of the first identity information. After the verification is successful, it initializes the dynamic trust factor of the requesting device and stores the first identity information and the dynamic trust factor together.

4. The device communication authentication method according to claim 3, characterized in that, The dynamic credibility factor is updated through the following steps: Statistics include device registration duration, number of successful authentications in history, total number of authentications in history, and number of abnormal behaviors in history. The standard registration time and the degree of abnormal behavior are calculated by normalizing the device registration time and the number of historical abnormal behaviors, respectively; and the device authentication success rate is determined based on the number of historical successful authentications and the total number of historical authentications. The dynamic trust factor is determined and updated based on the standard registration duration, the device authentication success rate, and the degree of abnormal behavior.

5. The device communication authentication method according to claim 1, characterized in that, The authentication of the requesting device using the first authentication strategy and the second authentication strategy includes the following steps: Receive a private key commitment and an address binding commitment from the requesting device; A randomly generated challenge value is sent to the requesting device, so that the requesting device calculates a private key response and an address binding response based on the challenge value; Private key ownership is verified based on the private key commitment and the private key response, and address binding relationship is verified based on the address binding commitment and the address binding response. If the private key ownership verification and address binding relationship verification are passed, the requesting device is confirmed to have passed the authentication of the second authentication policy.

6. The device communication authentication method according to claim 2, characterized in that, The device communication authentication method further includes the following steps: Determine whether the requesting device is a cross-domain device based on the domain identifier indicated in the first identity information; In the case that the requesting device is a cross-domain device, determine the domain credibility score of the domain to which the requesting device belongs; The domain trust type of the domain to which the requesting device belongs is determined based on the domain trust score; When the domain trust type is a trusted domain, the lightweight identity data of the requesting device in the domain to which the requesting device belongs is synchronized to the target domain. The lightweight identity data includes the hash value of the identity-based IPv6 address and the device public key, and a dynamic trust factor.

7. The method according to claim 6, characterized in that, The device communication authentication method further includes the following steps: Perform address structure verification on the first identity information represented by an identity-based IPv6 address; If the address structure verification fails, it is determined that the overall authentication result of the requesting device fails. If the address structure verification passes, the step of querying and obtaining the dynamic trust factor of the requesting device based on the first identity information is executed to obtain the dynamic authentication result; If the dynamic authentication result indicates failure, it is determined that the overall authentication result of the requesting device has failed. If the dynamic authentication result indicates that the requesting device has passed, determine whether the domain to which the requesting device belongs is a trusted domain; If the domain to which the requesting device belongs is not a trusted domain, it is determined that the overall authentication result of the requesting device fails. If the domain to which the requesting device belongs is a trusted domain, the overall authentication result of the requesting device is determined to be successful.

8. A device communication authentication system, characterized in that, include: The parsing module is used to parse the received device authentication request to obtain the first identity information of the requesting device; A device trust assessment model is used to query and obtain the dynamic trust factor of the requesting device based on the first identity information. The device trust type of the requesting device is determined based on the dynamic trust factor; The dynamic authentication module is used to authenticate the requesting device using a first authentication strategy when the device's trust type is a trusted device; the first authentication strategy is implemented based on asymmetric encryption technology to verify digital signatures; or, when the device's trust type is an untrusted device, the first authentication strategy and a second authentication strategy are used to authenticate the requesting device; the second authentication strategy is implemented based on an authentication protocol of challenge and response interaction.

9. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 7.

Images