Distributed device group unified authentication method and terminal

Abstract

The application provides a distributed device group unified authentication method and a terminal, which is applied to a device group, and the device group comprises at least two interconnected devices; the method comprises the following steps: each device in the device group calculates a dynamic capability score according to the capability attribute state of the device, and elects a device with the highest dynamic capability score as an authentication agent terminal. By means of the self-dynamic capability score calculation of each device in the device group according to the capability attribute state of the device and the election of the authentication agent terminal, the single-point trust problem depending on a cloud account system is avoided, and a pure local decentralized group authentication is realized. When a new device is added, the authentication agent terminal replaces the devices in the group to perform the interconnection authentication, so that the new device can join the group only by performing authentication with the authentication agent terminal once, the point-to-point handshake in the traditional distributed interconnection is simplified to centralized authentication, and the authentication cost and networking delay are greatly reduced.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a unified authentication method and terminal for distributed device groups. Background Technology

[0002] In current distributed operating systems, device group authentication and networking mainly rely on two modes: point-to-point authentication and account-based cloud authentication. Although account-based authentication simplifies user operations to some extent, the following problems exist when building a true "super terminal": (1) In shared account scenarios, malicious or unwanted devices can easily join the group. (2) Device authentication needs to be completed in the cloud, and cross-brand super terminal group authentication cannot be achieved. That is, there are problems with authentication security and universality. Summary of the Invention

[0003] The technical problem to be solved by this invention is: how to improve the security and universality of authentication.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A unified authentication method for a distributed device group is applied to a device group comprising at least two interconnected devices; the method includes: Each device in the device group calculates its own dynamic capability score based on its own capability attribute status, and the device with the highest dynamic capability score is elected as the authentication agent terminal.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A unified authentication terminal for a distributed device group includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the unified authentication method for a distributed device group as described above.

[0006] The beneficial effects of this invention are as follows: By having each device in a device group autonomously calculate a dynamic capability score based on its own capability attributes and elect an authentication agent terminal, the single-point trust problem of relying on a cloud-based account system is avoided, achieving purely local decentralized group authentication. When a new device joins, the authentication agent terminal performs interconnection authentication on behalf of the devices in the group, enabling it to join the group with only one authentication with the authentication agent terminal. This simplifies the point-to-point handshake in traditional distributed interconnection to centralized authentication, significantly reducing authentication overhead and network latency. Attached Figure Description

[0007] Figure 1 This is a system architecture diagram of devices in a device group according to a distributed device group unified authentication method in an embodiment of the present invention; Figure 2 This is a flowchart illustrating the device group construction process of a distributed device group unified authentication method according to an embodiment of the present invention. Figure 3 This is a flowchart illustrating the process of adding a new device to a device group in a distributed device group unified authentication method according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a unified authentication terminal for a distributed device group in an embodiment of the present invention. Detailed Implementation

[0008] Definitions:

[0009] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0010] In existing technologies, the following problems exist when building a true "super terminal": (1) The problem of “single point of trust” and “rigidity” in account authentication: The existing mechanism lacks fine-grained local risk assessment. Once the account token is leaked, or in a shared account scenario (such as a family sharing an account), malicious or unwanted devices can easily join the group, and the local group cannot effectively isolate them.

[0011] (2) Account authentication status and trust relationship rely entirely on cloud synchronization and are completely invalid offline. Furthermore, there is often an ecosystem silo effect: OpenHarmony devices from different manufacturers use their own independent account systems and cannot achieve cross-brand super terminal group authentication.

[0012] (3) It is not friendly to lightweight devices and screenless devices, and the account login process cannot be completed.

[0013] For point-to-point authentication, the following drawbacks exist when facing group interconnection authentication of multiple devices: (1) Pure point-to-point authentication requires new devices to authenticate with all devices in the group one by one; the authentication complexity is high. (2) Resource-constrained devices cannot independently complete authentication with multiple devices. (3) Fragmented trust relationships: Each device independently maintains its own trusted list, making it difficult to guarantee consistency across the entire network.

[0014] To at least address the aforementioned issues, this invention, based on the existing OpenHarmony distributed interconnection system, solves the authentication problem when multiple devices interconnect. It abstracts the device group as a logical "super terminal" and elects a "group authentication proxy" within the group. In this way, when a new device joins the network, it no longer needs to handshake with all devices in the group, but only authenticates with this proxy. After successful authentication, the proxy issues a "group credential envelope," and other devices in the group can trust the new device after verifying the envelope's signature.

[0015] This will enable: (1) to eliminate reliance on the cloud during device interconnection group authentication, achieving purely local device authentication with fine-grained access control; (2) to reduce the complexity of authentication interactions between new devices and groups, significantly improving network access efficiency and reducing the burden on lightweight devices; and (3) to build a group-level authentication system with dynamic defense capabilities.

[0016] The following describes in detail a unified authentication method for a distributed device group according to the present invention, applied to a device group comprising at least two interconnected devices. Please refer to [link / reference]. Figure 1 This is a system architecture diagram for devices within a device group. The OpenHarmony system provides a device trust authentication subsystem and a soft bus subsystem. The device trust authentication subsystem supports establishing point-to-point groups via PIN codes, QR codes, etc., and also supports multi-device interconnection groups based on an account system, providing a root of trust for inter-device communication. The soft bus subsystem establishes an encrypted transmission channel based on this root of trust, enabling applications to perform service discovery, data transmission, and distributed workflows across devices.

[0017] This embodiment adds or modifies modules (see gray modules) based on the existing device mutual trust authentication subsystem of OpenHarmony (see white module).

[0018] (1) The expansion of the soft bus subsystem is as follows: 1.1 Device discovery module: In addition to the native information, the device list broadcast also adds the authentication agent terminal information of the super terminal group to which the device belongs. 1.2 Device authentication request: When a new device triggers a connection request, it initiates an authentication request to the authentication agent device of the super terminal group.

[0019] (2) The device mutual trust authentication subsystem is expanded as follows: 2.1. In the original device group management service, a super terminal group lifecycle management module is added, which connects to the original device group management service and provides interfaces for group creation, disbandment, and member change. 2.2. Authentication agent dynamic election service: realizes negotiation among multiple devices to determine which device is suitable as the group's authentication agent. 2.3. Group identity key management service: connects to the HUKS key system and is responsible for the generation, storage, and updating of group public and private keys. 2.4. Group member synchronization and consistency service: realizes data synchronization based on the newly added group broadcast interface of the soft bus. 2.5. Mutual trust group information management service: on the original basis, the management of super terminal group information and mutual trust device list is added.

[0020] The method includes step 101: Step 101: Each device in the device group calculates its own dynamic capability score based on its own capability attribute status, and elects the device with the highest dynamic capability score as the authentication proxy terminal. For example, if the device group includes device A and device B, and device A has the highest dynamic capability score, then device A is elected as the authentication proxy terminal.

[0021] As described above, the beneficial effects of this invention are as follows: By having each device in the device group autonomously calculate a dynamic capability score based on its own capability attributes and elect an authentication agent terminal, the single-point trust problem of relying on a cloud account system is avoided, achieving purely local decentralized group authentication. When a new device joins, the authentication agent terminal performs interconnection authentication on behalf of the devices in the group, enabling it to join the group by only needing to authenticate with the authentication agent terminal once. This simplifies the point-to-point handshake in traditional distributed interconnection to centralized authentication, significantly reducing authentication overhead and network latency.

[0022] In one embodiment of the present invention, step 101, in which each device in the device group calculates its own dynamic capability score based on its own capability attribute status, includes: Score=w1SecLevel+w2CPU+w3Battery+w4NetStability+w5Mem; Among them, Score is the dynamic capability score; SecLevel is the security hardware level; CPU is the computing power level; Battery is the remaining battery percentage; NetStability is the network signal strength; Mem is the available memory percentage; w1 is the weighting coefficient for the security hardware level; w2 is the weighting coefficient for the computing power level; w3 is the weighting coefficient for the remaining battery percentage; w4 is the weighting coefficient for the network signal strength; and w5 is the weighting coefficient for the available memory percentage. These weighting coefficients are statically configured, but in practice, the weighting can be adjusted according to specific needs. Furthermore, other considerations can be added based on changing requirements, such as considering temperature-related performance when it affects overall performance. The values ​​for each variable are shown in Table 1. Table 1. Illustration of the values ​​of each variable

[0023] As described above, by introducing a multi-dimensional comprehensive scoring formula that includes security hardware level, computing power level, remaining battery percentage, network signal strength, and available memory ratio, the suitability of each device in the group as a proxy is quantitatively evaluated. Among them, the security hardware level ensures a trusted execution environment for key storage and cryptographic operations, the computing power ensures that the proxy can efficiently perform Merkle tree construction and signature operations, the remaining battery and network signal strength ensure the continuous stability of the proxy service, and the available memory ratio ensures that the proxy has sufficient resources to process authentication requests. Through multi-dimensional comprehensive scoring, the selected authentication proxy terminal has the best comprehensive service capabilities, improving the overall reliability of the group authentication system.

[0024] In one embodiment of the present invention, after step 101 elects the device with the highest dynamic capability score as the authentication agent terminal, steps 102 to 104 are further included: Step 102: If a target device in the device group receives a request for a new device to join the device group, the target device sends the connection information of the authentication proxy terminal to the new device, instructing the new device to initiate a connection request to the authentication proxy terminal based on the connection information. The connection information includes the device group identifier (group_id), the authentication proxy terminal's UDID, and the authentication proxy terminal's term number (proxy_epoch), etc. The new device C initiates a connection request to device A based on the above information.

[0025] Step 103: The authentication agent terminal in the device group verifies the legitimacy of the new device. If the verification is successful, an access credential is generated and distributed to other member devices in the device group as well as the new device. For example, after receiving a connection request, the soft bus of device A forwards the request to the device authentication subsystem, requesting a check of the trust relationship between device A and device C. After successful authentication, an access credential is generated and sent to device B and device C.

[0026] Step 104: After successfully verifying the network access credential, other member devices in the device group store the identity information of the new device in their local trust list, establishing a mutual trust relationship with the new device. After successfully verifying the network access credential, device B stores the identity information of device C in its local trust list.

[0027] As described above, by uniformly generating and distributing network access credentials through the authentication agent terminal, new devices only need to authenticate with the authentication agent terminal once to join the group. This reduces the O(n²) interaction complexity of traditional distributed interconnection, where new devices need to shake hands with all members in the group one by one, to O(1), significantly reducing authentication overhead and network latency. Other member devices only need to verify the network access credentials issued by the authentication agent terminal to establish trust in the new device, achieving a highly efficient network access mechanism of "one-time authentication, network-wide access". At the same time, the network access credentials are distributed to other member devices and the new device simultaneously, ensuring consistency in the recognition of the new member's identity by all devices in the group.

[0028] In one embodiment of the present invention, the authentication agent terminal in the device group verifying the legitimacy of the new device in step 103 includes: the authentication agent terminal in the device group authenticating the new device through a preset authentication protocol, and terminating the process if the authentication fails. For example, device A uses the OpenHarmony standard PAKE protocol (such as PIN code / QR code verification) or other customized authentication protocols (such as certificate chain verification) to verify the legitimacy of device C; wherein, PIN code / QR code verification is manual confirmation, and certificate chain verification is an automatic challenge-response mechanism between devices.

[0029] As described above, the authentication agent terminal uses a preset authentication protocol to authenticate the legitimacy of new devices. If the authentication fails, the process is terminated immediately, effectively preventing unauthorized devices from accessing the group and ensuring the security of group resources and the legitimacy of group members' identities. As the device with the best comprehensive capabilities within the group, the authentication agent terminal can fully leverage its advantages in security hardware and computing power to perform authentication on devices entering the network, ensuring the security and efficiency of the authentication process.

[0030] In one embodiment of the present invention, step 102, in which the target device sends the connection information of the authentication proxy terminal to the new device, further includes: the target device in the device group sending the connection information of the authentication proxy terminal to the new device, so as to instruct the new device to initiate a connection request to the authentication proxy terminal according to the proxy identifier in the connection information, and receive the first proxy term number fed back by the authentication proxy terminal, and determine whether the first proxy term number is consistent with the second proxy term number in the connection information. If they are inconsistent, the connection is disconnected.

[0031] For example, if device C receives a connection message with the second proxy term number of proxy_epoch=1, and device A receives a response with the first proxy term number of proxy_epoch=1, then device A is currently a valid authentication proxy terminal and will proceed with the connection. If the second proxy term number is proxy_epoch=2, then the connection will be closed.

[0032] As described above, by introducing a consistency verification mechanism for the agent term number during the connection establishment process, it is possible to effectively prevent new devices from mistakenly connecting to old agent terminals that have been revoked or replaced. This mechanism can verify the validity of agent terminals locally without relying on the cloud revocation list, thus enhancing the forward security of the group authentication system.

[0033] In one embodiment of the present invention, step 103, in which the authentication agent terminal generates the network access credential, includes: the authentication agent terminal in the device group adding the public key of the new device to the local member list and generating first public key data; the authentication agent terminal generating a network access envelope based on the first public key data, its own first agent term number, the identification information of the new device, and the public key; and signing the network access envelope using its own private key to generate the network access credential.

[0034] Device A adds Device C's public key to its local member list, then rearranges all member public keys in lexicographical order of UDID, reconstructs the Merkle Tree, and generates a new first public key data merkle_root. Then, it uses the first public key data merkle_root, the first proxy term number proxy_epoch=1, Device C's UDID, and the public key to generate an entry envelope. Device A uses its own private key to sign the entry envelope to obtain the entry credential.

[0035] As described above, the authentication agent terminal adds the new device's public key to the local member list and generates the first public key data. Then, the first public key data, the agent's own term number, the new device's identification information, and the public key are combined to form the network access credential payload and signed with the agent's own private key. This makes the network access credential unforgeable and complete, and no device can forge a legitimate credential without knowing the agent's private key. At the same time, the group member status is bound to the agent's term, providing a standardized data format and verification basis for subsequent consistency verification among group members.

[0036] In one embodiment of the present invention, step 104, in which the other member devices in the device group successfully verify the network access credential and store the identity information of the new device in the local trust list, includes steps 401 to 403: Step 401: Other member devices in the device group determine whether the current proxy term number in the network access credential is greater than or equal to the latest term number recorded locally. If so, they obtain the proxy identifier of the authentication proxy terminal and obtain the public key of the authentication proxy terminal based on the proxy identifier; otherwise, they reject the network access credential. For example, if the latest term number recorded locally by device B is proxy_epoch=1, which is the same as the first proxy term number proxy_epoch=1, then they obtain the UDID of device A and obtain the public key of device A based on the UDID.

[0037] Step 402: The other member devices use the public key of the authentication proxy terminal to verify the validity of the signature in the access credential. If the signature is invalid, the access credential is rejected. For example, device B verifies the validity of the signature in the access credential using device A's public key. If the verification is successful, it indicates that the access credential was issued by device A.

[0038] Step 403: The other member devices add the new device's public key to their local temporary list and generate second public key data. If the second public key data is inconsistent with the first public key data, they refuse to update the local trust list; if they are consistent, they store the new device's identity information in the local trust list. For example, if device B adds device C's public key to its local temporary list and calculates its local second public key data merkle_root1, and merkle_root1 is consistent with merkle_root, then device C's identity information is stored in the local trust list.

[0039] As described above, a multi-level network access credential verification mechanism is implemented on the group member side, including agent term number verification, signature validity verification, and public key data consistency verification. Among these, agent term number verification ensures that the credential is issued by an agent with a current valid term, preventing old credentials from being replayed; signature verification ensures that the credential content has not been tampered with during distribution; and public key data consistency verification effectively prevents the authentication agent terminal from maliciously tampering with the member list by comparing the second public key data with the first public key data. The three levels of verification work together to ensure the final consistency of group members' perception of the new device's identity.

[0040] In one embodiment of the present invention, each device in the device group initializes a proxy term number when electing an authentication proxy terminal. For example, when device A and device B elect device A as the authentication proxy terminal, the initial proxy term number is proxy_epoch=1.

[0041] When the proxy renegotiation condition is triggered, each device in the device group recalculates its dynamic capability score and re-elects an authentication proxy terminal, and increments the proxy term number; that is, proxy_epoch+1, at which point proxy_epoch=2.

[0042] The new authentication proxy terminal publishes a statement containing the updated proxy term number to each member device within the device group. Upon receiving the statement, each member device updates its locally recorded connection information of the authentication proxy terminal and the proxy term number. That is, it sends the proxy term number proxy_epoch=2 to each member device.

[0043] As described above, by introducing a monotonically increasing agent term number mechanism, the term number is incremented each time the agent is renegotiation occurs, and the new agent issues a statement containing the updated term number. Each member device synchronously updates the locally recorded authentication agent terminal information and term number. This causes the network access credentials issued by the old agent to automatically become invalid because the term number no longer matches, achieving smooth switching of group authentication agents and rapid local revocation of credentials without relying on a cloud revocation list. This is suitable for device group authentication scenarios in offline environments.

[0044] In one embodiment of the present invention, the conditions for triggering proxy renegotiation include at least one of the following: the current authentication proxy terminal is offline, the remaining power of the current authentication proxy terminal is lower than a preset power threshold, the network signal strength of the current authentication proxy terminal is lower than a preset strength threshold, and the dynamic capability score of the new device is higher than that of the current authentication proxy terminal.

[0045] As described above, by setting up a proxy renegotiation mechanism that covers multiple triggering conditions such as proxy terminal offline, low power, weak network signal, and higher scores of new devices, the group can promptly re-elect a better proxy terminal when the proxy terminal's capabilities decline or the group topology changes. This avoids a decline in authentication service quality due to single point of failure or proxy terminal performance degradation, ensuring that the group authentication service continues to operate in a highly available state and enhancing the system's dynamic adaptability.

[0046] Please refer to Figure 2 This invention provides a specific application scenario to illustrate the above steps. Assume that devices A, B, and C ultimately need to form a super terminal group. Device A (initial agent): a standard device (L2), supporting complex algorithms and possessing a TEE. Device B (group member): a lightweight device (L0), not supporting complex algorithms or a TEE, and unable to act as a proxy, but possessing basic encryption / decryption capabilities. Device C (newly added device): a standard device (L2), supporting complex algorithms and SE.

[0047] Group initialization and security anchor establishment, i.e., authentication when the first (device A) and the second (device B) in the group interconnect, including S1-S10: S1. Devices discover each other through a distributed soft bus and select a target device to connect to; that is, device A and device B discover each other through the distributed soft bus.

[0048] S2. Device A connects and starts, initiates group creation, and generates the initial group identifier (group_id).

[0049] S3. Proxy Election: When the mutual trust authentication subsystem of devices A and B receives an authentication request from the soft bus subsystem, the dynamic proxy election service executes the proxy election algorithm. Local device attributes are read, each attribute is assigned a weight, and a proxy capability score is calculated. If device A has the highest proxy capability score, then device A is marked as CurrentProxy (representing the current authentication proxy device in the group).

[0050] S4. The super terminal group lifecycle management module in device A and device B initializes the monotonically increasing proxy_epoch to 1 (term number, used to record the validity period identifier of the group authentication agent's issued credentials. If the number corresponding to the credential is inconsistent with the latest term number, it means that the credential was not issued by the current agent).

[0051] S5. Devices within the group establish a trust relationship with each other, that is, devices A and B complete two-way PAKE authentication through PIN / QR code or other means; S6. Device A and Device B each generate their own public and private key pairs. The group maintains a list of group members' public keys and their group credentials. The private keys are stored by the devices themselves.

[0052] S7. Device A and Device B synchronously record their respective superterminal groups (group_id), the list of devices within the group, and the device UDID of the proxy authentication device (Device A) within the group. They also establish a mapping table between UDIDs and device identity public keys, storing this table in their local trust list. For example, Device A: UDID: a - Public Key: a; Device B: UDID: b - Public Key: b. The purpose of this is to ensure that upon receiving a network access credential issued by the proxy, the proxy's public key can be immediately retrieved from the local mapping table to independently verify its signature.

[0053] S8. Group identity key management service for device A: Sort all member public keys in UDID lexicographical order, construct MerkleTree, and generate merkle_root.

[0054] S9. The group member synchronization and consistency service of device A will synchronize merkle_root to device B.

[0055] S10. Initialization complete. A is the agent, and B is the group member.

[0056] Please refer to Figure 3 This is for the interaction authentication between the new device C and device B within the group.

[0057] S11. Device C discovers device B through the device list broadcast on the soft bus and selects device B to trigger a connection. The broadcast information of device B contains the information of the hyperterminal group to which it belongs, including group_id, CurrentProxy_UDID, and proxy_epoch; and as can be seen from the fact that the hyperterminal group authentication proxy negotiated in the previous group initialization process is device A, CurrentProxy_UDID is the UDID of device A.

[0058] S12. After obtaining the UDID of device A, device C initiates a connection with device A via the soft bus. Device A and device B essentially form a "terminal entity D." Device C does not directly connect to device A but instead connects to device B. Device B then informs device A to act as a proxy for authentication. Simultaneously, device C interacts with device B before and after authentication, confirming whether device A's connection target is device B within the group. Device C maintains interaction with device B throughout the authentication process (e.g., progress queries or final result callbacks). As an authenticated member, device B knows who the current legitimate proxy is. If device C connects to a "fake proxy," it cannot complete the subsequent synchronization logic with device B (e.g., it cannot provide a valid Merkle Root signature), and device B will determine that authentication has failed, thus preventing man-in-the-middle attacks.

[0059] S13. Two-way authentication: When device A's soft bus receives a connection request, it forwards the request to the device authentication subsystem, requesting a check of the trust relationship between device A and device C. Simultaneously, device C's device authentication subsystem checks whether the two devices are already in the same superterminal group, same account group, or P2P group. If authentication information for both devices exists in any of these groups, the subsystem returns a successful authentication result to the soft bus subsystem. The soft bus subsystem receives the result and returns it to device C, notifying device C and device B that they are already authenticated. Device C can then directly initiate a connection with device B.

[0060] If neither device has authentication information in the HyperTerminal group, the same account group, or the P2P group, then the process of adding device C to the HyperTerminal group of devices A and B will be initiated. That is, the HyperTerminal group's proxy authentication device A will perform the device authentication process, which requires authenticating device C and adding device C to the HyperTerminal group. The specific authentication process is as follows: S131. Device A verifies the legitimacy of Device C, such as by using the OpenHarmony standard PAKE protocol or other customized authentication protocols to authenticate Device C.

[0061] S131. Device C verifies the identity of Device A (using the exchanged public key and signature) and checks the proxy_epoch to prevent connection to a revoked old proxy. If the verification fails, the connection is terminated.

[0062] S14. After verifying the legitimacy of device C, device A generates and distributes group credential envelopes. Specifically: device A adds device C's public key to its local member list; then, it rearranges all member public keys in UDID lexicographical order, reconstructs the MerkleTree, and generates a new `new_merkle_root`. Device A then broadcasts to all online members ("all online members" refers to existing online member devices in the device group to which device A belongs, excluding device C), waiting for member verification and ACK responses. If all responses are received, or if a preset timeout threshold (e.g., 60 seconds) is reached and the response rate exceeds a preset threshold (e.g., 80%), the process proceeds to the next step; otherwise, a rollback occurs (device A discards `new_merkle_root`, maintaining `proxy_epoch=1` and the old `MerkleRoot`). If no response is received, the device must re-enter the group process and update its status.

[0063] S141. Device A generates an entry envelope containing device A's proxy_epoch, device C's UDID, device C's public key, and new_merkle_root. Device A uses its private key to sign the above fields.

[0064] S15. Device A sends the network access information of Device C to all online group members (Device B) through the group member synchronization and consistency service.

[0065] Local update for group members: After receiving the network access envelope from device C, device B verifies the information and updates it locally.

[0066] S16. After receiving the envelope, Device B first queries the currently valid CurrentProxy_UDID through the HyperTerminal Group Lifecycle Management module to obtain the proxy's public key. It then verifies the proxy_epoch (which must be greater than or equal to the locally recorded epoch). Using Device A's locally stored public key, it verifies the validity of the signature in the envelope. If they do not match, the update is rejected. If they match, device B adds device C's public key to its local temporary list, calculates its local `merkle_root1`, and compares it with `new_merkle_root` in the envelope (L0 devices typically lack sufficient computing power to process dynamic Merkle trees, especially when the group size is large. Therefore, the Merkle root of an L0 device is calculated and generated by the proxy device; group members only need to store and compare the root hash value, without needing to rebuild the Merkle tree locally; L0 devices have the ability to verify proxy signatures). If they do not match, the update is refused (to prevent the proxy from tampering with the member list). If all verifications pass, device B writes device C's identity information to its local storage. Afterward, device B and device C can directly communicate using the STS protocol based on the locally stored public key, without needing to go through device A as an intermediary.

[0067] Similarly, after device A generates the network access credential, it sends the credential directly to the new device C. Upon receiving the credential, device C can store the information in its local trust list, thereby establishing trust with other members in the group (such as device A and device B). Therefore, device C's local member list update is achieved by receiving and verifying the network access credential issued by proxy device A, which is essentially the same as the update mechanism of device B.

[0068] Agent renegotiation and dynamic maintenance: S17, Triggering proxy renegotiation: Triggering conditions: 1. Device C successfully joins, and the existing agent device (Device A) triggers agent election; 2. The existing agent's battery level is below 10%, and the existing agent device triggers agent election; 3. Agent device offline detection: When a new device member requests authentication, if the new device C fails to connect to agent device A, the target device B attempts to connect to the agent device. If it also fails, other online devices in the group connect to device A in turn. If all connections fail, the last device to attempt a connection initiates agent election. If any member in the group fails to connect to the agent device multiple times, the process described above repeats, with each member in the group attempting to connect to the agent device in turn.

[0069] New round of election: The certification agent dynamic election service recalculates the scores. Device C (standard device, with SE) scores higher than device A because it has stronger security capabilities and a more up-to-date state.

[0070] S18. Mark the device C with the highest score as CurrentProxy and initialize the monotonically increasing proxy_epoch to 2.

[0071] S19, Network-wide Synchronization: The new agent C publishes a declaration containing proxy_epoch=2 and a new merkle_root. Group member devices A and B synchronously update their local records. Since proxy_epoch has been updated, any credentials issued by the old agent A (bound to the old epoch) will automatically become invalid, achieving rapid local revocation. Subsequent processes for new devices joining the group will be handled by the new agent device C, which will perform interconnection authentication.

[0072] Please refer to Figure 4 A unified authentication terminal for a distributed device group includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the unified authentication method for a distributed device group as described above. For example, if the terminal is a proxy device, it executes the steps related to the proxy device; if the terminal is a group member device, it executes the steps related to group members.

[0073] In summary, the distributed device group unified authentication method and terminal provided by this invention abstracts the device group into a logical "super terminal," and selects the best device from the group as the "group authentication proxy" through dynamic capability scoring. This simplifies the authentication interaction when a new device joins the network from "shaking hands with all devices in the group one by one" to "single-point authentication with only the proxy device," achieving "one-time authentication, network-wide access." Simultaneously, it introduces proxy term numbering and a Merkle tree mechanism to ensure forward and backward security. While ensuring the security that the device's private key does not leave the device, the O(n²) authentication interaction complexity of traditional distributed interconnection is reduced to O(1), achieving pure local, fine-grained access control free from cloud dependence. Furthermore, the proxy term numbering and Merkle tree mechanism construct a group-level authentication system with dynamic defense capabilities, providing a feasible technical solution for building a cross-brand, cross-account "super terminal."

[0074] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A unified authentication method for a distributed device group, characterized in that, Applied to a group of devices, the group of devices comprising at least two interconnected devices; the method includes: Each device in the device group calculates its own dynamic capability score based on its own capability attribute status, and the device with the highest dynamic capability score is elected as the authentication agent terminal.

2. The method for unified authentication of a distributed device group according to claim 1, characterized in that, Each device in the device group calculates its own dynamic capability score based on its own capability attribute status, including: Score=w1SecLevel+w2CPU+w3Battery+w4NetStability+w5Mem; Among them, Score is the dynamic capability score; SecLevel is the security hardware level; CPU is the computing power level; Battery is the remaining battery percentage; NetStability is the network signal strength; Mem is the available memory percentage; w1 is the weighting coefficient of the security hardware level; w2 is the weighting coefficient of the computing power level; w3 is the weighting coefficient of the remaining battery percentage; w4 is the weighting coefficient of the network signal strength; and w5 is the weighting coefficient of the available memory percentage.

3. The method for unified authentication of a distributed device group according to claim 1, characterized in that, After selecting the device with the highest dynamic capability score as the authentication agent terminal, the process also includes: If a target device in the device group receives a request for a new device to join the device group, the target device sends the connection information of the authentication proxy terminal to the new device, instructing the new device to initiate a connection request to the authentication proxy terminal based on the connection information. The authentication agent terminal in the device group verifies the legitimacy of the new device. If the verification is successful, it generates an access credential and distributes the access credential to other member devices in the device group as well as the new device. After successfully verifying the network access credentials, the other member devices in the device group store the identity information of the new device in their local trust list, thus establishing a mutual trust relationship with the new device.

4. The method for unified authentication of a distributed device group according to claim 3, characterized in that, The authentication agent terminal in the device group verifies the legitimacy of the new device by including: The authentication agent terminal in the device group performs legality authentication on the new device through a preset authentication protocol. If the authentication fails, the process is terminated.

5. The method for unified authentication of a distributed device group according to claim 3, characterized in that, The step of sending the connection information of the authentication proxy terminal from the target device to the new device also includes: The target device in the device group sends the connection information of the authentication proxy terminal to the new device, instructing the new device to initiate a connection request to the authentication proxy terminal according to the proxy identifier in the connection information, and receive the first proxy term number fed back by the authentication proxy terminal, and determine whether the first proxy term number is consistent with the second proxy term number in the connection information. If they are inconsistent, the connection is disconnected.

6. The method for unified authentication of a distributed device group according to claim 3, characterized in that, The authentication agent terminal generates network access credentials including: The authentication agent terminal in the device group adds the public key of the new device to the local member list and generates first public key data; the authentication agent terminal generates an access envelope based on the first public key data, its own first agent term number, the identification information of the new device and the public key; and signs the access envelope with its own private key to generate the access credential.

7. The method for unified authentication of a distributed device group according to claim 6, characterized in that, After successfully verifying the network access credential, the other member devices in the device group store the new device's identity information in their local trust list, including: The other member devices in the device group determine whether the current agent term number in the network access credential is greater than or equal to the latest term number recorded locally. If so, they obtain the agent identifier of the authentication agent terminal and obtain the public key of the authentication agent terminal based on the agent identifier; otherwise, they reject the network access credential. The other member devices use the public key of the authentication agent terminal to verify the validity of the signature in the access credential; if the signature is invalid, the access credential is rejected. The other member devices add the new device's public key to their local temporary list and generate second public key data. If the second public key data is inconsistent with the first public key data, they refuse to update the local trust list; if they are consistent, they store the new device's identity information in the local trust list.

8. The method for unified authentication of a distributed device group according to claim 1, characterized in that, When electing an authentication agent terminal, each device in the device group initializes the agent term number. When the agent renegotiation condition is triggered, each device in the device group recalculates its dynamic capability score and re-elects an authentication agent terminal, and increments the agent term number. The new authentication agent terminal publishes a statement containing the updated agent term number to each member device in the device group. After receiving the statement, each member device updates the connection information of the authentication agent terminal and the agent term number recorded locally.

9. The method for unified authentication of a distributed device group according to claim 8, characterized in that, The conditions for triggering proxy renegotiation include at least one of the following: the current authentication proxy terminal is offline, the remaining battery power of the current authentication proxy terminal is lower than a preset battery power threshold, the network signal strength of the current authentication proxy terminal is lower than a preset strength threshold, and the dynamic capability score of the new device is higher than that of the current authentication proxy terminal.

10. A unified authentication terminal for a distributed device group, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements a unified authentication method for a distributed device group as described in any one of claims 1 to 9.

Images