A method for distributed device identification and authentication of a honeycomb for internet of things platform device management

Abstract

This invention provides a HarmonyOS distributed device identification and authentication method for IoT platform device management, comprising: responding to a request from a device to access the network, using the HarmonyOS distributed soft bus to perceive the current network topology and select multiple authentication nodes to form a dynamic trust mesh; the requesting device generates a temporary identity identifier and a temporary public-private key pair, and initiates distributed joint authentication to multiple authentication nodes; after each authentication node verifies the signature, it generates a partial signature and returns it; after receiving a certain number of partial signatures that meet a threshold, the requesting device synthesizes a complete signature as a distributed identity credential and synchronizes the trust record to online devices; the online devices use the system master public key to verify the complete signature and update their local trust record. This invention, through distributed joint authentication and threshold signature mechanisms, achieves efficient and reliable device identity authentication without a central trust anchor, eliminating the risk of single point of failure and reducing authentication latency.

Description

Technical Field

[0001] This invention relates to the field of IoT device security management technology, and in particular to a HarmonyOS distributed device identification and authentication method for IoT platform device management. Background Technology

[0002] With the widespread adoption of 5G mobile communication technology and the HarmonyOS operating system, the number of IoT devices is experiencing explosive growth. These devices encompass sensors, industrial terminals, smart home devices, and more, exhibiting significant distributed and heterogeneous characteristics. HarmonyOS, through distributed soft bus technology, connects different devices into a super terminal, enabling cross-device collaboration. This places higher demands on the real-time performance and reliability of device access authentication.

[0003] Existing IoT device identification and authentication schemes mainly fall into two categories. The first category is a centralized authentication model based on traditional public key infrastructure, such as object identifiers, handles, and IoT codes. This type of scheme relies on a central server to make authentication decisions, which can easily create network bottlenecks when devices are densely connected. Furthermore, a failure of the central node will cause all devices on the network to fail to authenticate, posing a single point of failure risk. The second category is a distributed identification scheme based on blockchain. This type of scheme achieves decentralized authentication through a consensus mechanism, but the consensus process incurs high computational overhead and prolonged confirmation time, making it difficult to meet the real-time requirements for rapid device network access.

[0004] Both of the aforementioned solutions face common technical shortcomings in HarmonyOS distributed scenarios: authentication latency and single point of failure issues in dynamic device network access scenarios. Specifically, in typical applications such as industrial IoT and smart homes, devices need to frequently access or exit the network. Existing authentication models either introduce uncontrollable round-trip latency due to centralized architecture or result in excessively long authentication times due to consensus mechanisms, neither of which can balance authentication efficiency and system reliability. How to achieve fast, distributed, and single-point-free device identification and authentication while ensuring security has become a pressing technical challenge for the HarmonyOS IoT platform. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a HarmonyOS distributed device identification and authentication method for IoT platform device management, in order to solve or improve the technical problems existing in the prior art.

[0006] The technical solution of this invention is implemented as follows: a HarmonyOS distributed device identification and authentication method for IoT platform device management, comprising the following steps: In response to a request from a device to access the network, the HarmonyOS distributed soft bus is used to perceive the current network topology in real time. Based on a preset selection strategy, multiple authentication nodes are selected from online devices to form a dynamic trust mesh, thereby distributing the authentication load to peripheral devices and eliminating the dependence on the central node. The application device generates a temporary identity identifier based on its hardware characteristics and generates a temporary public-private key pair bound to this authentication session. The authentication request containing the temporary identity identifier and temporary public key is sent to multiple authentication nodes in the dynamic trust grid through the distributed soft bus to initiate distributed joint authentication. Each of the authentication nodes verifies the authentication request, and after successful verification, signs the temporary identity and temporary public key using its own private key to generate its own partial signature, and returns the partial signature to the requesting device, so as to distribute the authentication decision-making power to multiple independent nodes; After receiving partial signatures that meet the threshold number, the application device synthesizes a complete signature as a distributed identity credential using a threshold signature algorithm. The trust record containing the distributed identity credential, the temporary identity identifier, and the temporary public key is synchronized to at least some online devices in the network through the distributed soft bus, so as to realize the generation of identity credentials without a central trust anchor by utilizing the composability of threshold signatures. Each device is pre-configured or obtains a system master public key for verifying the threshold signature via a distributed soft bus. After receiving the trust record, the online device uses the system master public key to verify the validity of the complete signature. After successful verification, the trust record is updated locally, so as to achieve consistent recognition of the distributed identity credential by all network devices without the need for global consensus.

[0007] Compared with existing technologies, the beneficial effects of this invention are as follows: By dynamically selecting authentication nodes through the HarmonyOS distributed soft bus to form a dynamic trust grid, the authentication load is distributed to peripheral devices, eliminating the dependence on the central node and avoiding the single point of failure risk and performance bottleneck of the centralized architecture; combined with the threshold signature mechanism to achieve distributed joint authentication, the authentication decision is completed collaboratively by multiple independent nodes, and verifiable identity credentials can be generated without global consensus, which significantly reduces authentication latency and computational overhead, and meets the real-time requirements for rapid network access of IoT devices while ensuring security. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart of the joint certification process of the present invention; Figure 2 This is the system structure frame of the present invention; Figure 3This is a timing diagram for the authentication of the present invention; Figure 4 This is the trust synchronization and verification process of the present invention. Detailed Implementation

[0010] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the spirit or scope of the invention. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0011] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0012] This embodiment provides a HarmonyOS distributed device identification and authentication method for IoT platform device management.

[0013] During the system deployment phase, the first step is to establish the basic security parameters for the entire distributed authentication system. This phase is performed offline in a secure environment by a trusted initialization node. Once completed, this node can be destroyed to ensure that no single node possesses the complete system private key.

[0014] System common parameter generation: The trusted initialization node generates common system parameters based on elliptic curve cryptography, including: Elliptic curve parameters: The modulus of a finite field of prime order is selected. Elliptic curve equation coefficients Base point and base point The level , forming a parameter set ( This embodiment preferably uses the secp256k1 curve, whose safety has been widely verified.

[0015] System public-private key pair: Based on the above elliptic curve parameters, generate the system master private key. and system master public key Among them, the system master public key It will be made public to all network devices for verifying subsequently generated distributed identity credentials.

[0016] Threshold private key fragmentation generation and distribution: To achieve decentralized authentication decisions, the system master private key Instead of storing directly on any single device, it adopts... Threshold Shamir secret sharing scheme split into Private key sharding The threshold value t is set to Ensure that it does not exceed Even if all authentication nodes are compromised, it is still possible to synthesize a legitimate signature.

[0017] Each private key fragment is pre-configured via a secure channel to the device subsequently selected as an authentication node. The secure channel includes, but is not limited to: TLS encrypted channel based on pre-configured certificates; Physical writing method before the device leaves the factory; Sealed delivery via a trusted execution environment.

[0018] System master public key distribution: System Master Public Key Configure all network devices using any of the following methods: The device automatically obtains the information when it first connects to the network via the HarmonyOS distributed soft bus broadcast. The equipment is pre-positioned in a safe storage area when it leaves the factory.

[0019] After completing the above distribution, the trusted initialization node immediately destroys the system master private key. This ensures that no single node possesses the complete private key during subsequent authentication processes.

[0020] After system initialization is complete, when a new device requests to connect to the IoT platform, the following authentication process is executed: First, when a device requests network access, the method utilizes the HarmonyOS distributed soft bus to perceive the current network topology in real time. Specifically, it obtains a list of online devices by periodically broadcasting probe messages or listening for device discovery signals in the network. Then, according to a preset selection strategy, multiple authentication nodes are selected from the online devices to form a dynamic trust mesh. This selection strategy comprehensively considers multiple dimensions such as device trust level and resource availability, distributing the authentication load to surrounding trusted devices, thereby eliminating dependence on a single central node.

[0021] Then, the requesting device generates a temporary identity based on its hardware characteristics and generates a temporary public-private key pair bound to this authentication session. Subsequently, the requesting device sends an authentication request containing the temporary identity and temporary public key to multiple authentication nodes in the dynamic trust mesh via the distributed soft bus to initiate distributed federated authentication.

[0022] Subsequently, each authentication node verifies the received authentication request. Upon successful verification, each node uses its pre-configured private key to sign the temporary identity and temporary public key, generating its own partial signature. This partial signature is then returned to the requesting device, thus distributing authentication decision-making power among multiple independent nodes.

[0023] Upon receiving a number of partial signatures that meet a preset threshold, the requesting device synthesizes a complete signature using a threshold signature algorithm, serving as a distributed identity credential. Subsequently, the requesting device synchronizes a trust record containing this distributed identity credential, the temporary identity identifier, and the temporary public key to at least some online devices in the network via the distributed soft bus, thereby leveraging the composability of threshold signatures to generate identity credentials without a centralized trust anchor.

[0024] It should be noted that the complete signature Essentially, it is a joint endorsement of the applicant device's identity by multiple authentication nodes in a dynamic trust mesh, and its validity can be verified through the system's master public key. Independent verification is conducted regardless of whether the device broadcasting the trust record is trustworthy. Therefore, after synthesizing the complete signature, the requesting device's role changes from "the authenticated party" to "the credential issuer." Whether the trust record it publishes is accepted by other devices depends on the verifiability of the complete signature in the record, not on the trust in the requesting device.

[0025] In this system, each device in the network is pre-configured or obtains the system master public key for verifying the threshold signature via a distributed soft bus. When an online device receives the trust record, it uses the system master public key to verify the validity of the complete signature. Upon successful verification, the online device updates the trust record locally and stores it in a local database. Thus, consistent recognition of the distributed identity credential is achieved across all devices in the network without requiring global consensus.

[0026] As a specific implementation, the present invention further proposes the following steps for "using HarmonyOS distributed soft bus to perceive the current network topology in real time and selecting multiple authentication nodes from online devices according to a preset selection strategy": obtaining a list of surrounding online devices through the device discovery mechanism of the distributed soft bus; selecting from the list of online devices based on at least one of the following indicators: trust level, historical online duration, historical authentication success rate, and resource idleness. Each device acts as an authentication node, forming a dynamic trust mesh, in which... It is an odd number greater than or equal to 3; the trust level is dynamically updated based on the device's historical online time and historical authentication success rate, and is maintained locally by each device.

[0027] The selection strategy includes a comprehensive scoring function:

[0028] in, Indicates the first A comprehensive rating of each online device. The trust level of this device, Historical online time (in seconds). This represents the historical authentication success rate (value range [0,1]). This represents the current resource idleness (value range [0,1]). The weighting coefficients and , for The smoothness coefficient of the function. The resource idleness threshold; the highest comprehensive score Each device is selected as an authentication node to dynamically filter out trusted and resource-rich collaborative authentication entities in a distributed environment.

[0029] Specifically, the device discovery mechanism of the distributed soft bus can detect and acquire online device information within physical or logical proximity in real time. This mechanism works collaboratively through various underlying communication technologies, such as near-field communication, Bluetooth Low Energy, or LAN multicast, to achieve device discovery. Combined with the soft bus's service discovery protocol, requesting devices can efficiently obtain a list of available device resources in the current network, providing basic data for the selection of subsequent authentication nodes.

[0030] Based on this, devices are selected from the list of online devices according to at least one of the following indicators: trust level, historical online duration, historical authentication success rate, and resource availability. Each device acts as an authentication node, forming a dynamic trust mesh, in which... It is an odd number greater than or equal to 3. Among these, the trust level is dynamically evaluated based on the device's historical behavior and performance; historical online time reflects the device's operational stability; historical authentication success rate measures the device's performance and reliability as an authentication node; and resource idleness ensures that the selected node has sufficient computing, storage, and network resources to avoid authentication delays or failures. The value is set to an odd number greater than or equal to 3 to avoid ties in distributed decision-making or threshold signatures, and to ensure that distributed authentication has decentralized characteristics and fault tolerance, that is, the authentication system can still operate normally when some nodes fail or are attacked.

[0031] The trust level is dynamically updated based on the device's historical online time and historical authentication success rate, and is maintained locally by each device. For example, if a device successfully participates in authentication and correctly performs its duties, its trust level can be increased accordingly; conversely, if authentication fails, frequent offline events occur, or abnormal behavior occurs, its trust level may decrease. This dynamic update mechanism makes trust assessment more accurate and real-time, reflecting the current trust status of the device. At the same time, maintaining the trust level locally by each device reduces reliance on a centralized trust authority, enhancing the system's decentralized characteristics and resistance to single points of failure.

[0032] The selection strategy employs the aforementioned comprehensive scoring function, wherein, Trust level is a core indicator that directly reflects the reliability of equipment; (Historical online duration) uses a logarithmic function. Weighting is applied to reflect the non-linear characteristics of the impact of online duration on equipment reliability, which conforms to the law of diminishing marginal returns of equipment stability improvement; (Historical authentication success rate) directly measures the performance and reliability of the device as an authentication node; (Current resource idleness) uses The function performs weighting to ensure that resource idleness is close to or below a preset threshold. The score dropped rapidly, higher than The time score tends to stabilize, thus effectively screening out equipment with sufficient resources. For the weighting coefficients, satisfying The importance of each indicator can be flexibly adjusted according to the application scenario. λ is... The smoothing coefficient of the function controls the sensitivity of resource availability to the score. A larger λ value will make the curve steeper, indicating that it is more sensitive to changes in resource availability. A resource idleness threshold is defined, indicating the inflection point from "insufficient" to "sufficient" resource idleness. Ultimately, the resource idleness threshold is the one with the highest overall score. Each device is selected as an authentication node to dynamically filter out trusted and resource-rich collaborative authentication entities in a distributed environment.

[0033] Regarding the dynamic maintenance of trust levels, each device maintains its trust level locally. An incremental update mechanism is used. The system defaults to the following trust level parameters: Initial trust value =0.6: The default trust level that a new device receives when it first connects to the network.

[0034] Trust Enhancement Steps When a device successfully completes one authentication (as an applicant device) or successfully participates in an authentication node task (returning a valid partial signature), the trust level is determined according to... renew.

[0035] Trust reduces step size When a device fails to respond within the timeout period, refuses to sign, or is marked as a failed node during the authentication process, the trust level is adjusted accordingly. renew.

[0036] Minimum Trust Threshold =0.4: Used to determine whether the device is suitable to continue to assume a key role such as an authentication node.

[0037] During system initialization or when there are no devices with historical trust records in the network, each device uses a default initial trust value. =0.6 is used as a temporary trust level. If, due to a large number of devices behaving abnormally or continuous penalties, the trust level of all online devices in the current network falls below the preset minimum trust threshold, this will be used as a temporary trust level. If the score is 0.4, the conventional authentication node selection strategy (i.e., the selection method based on the comprehensive scoring function) will be temporarily disabled. To ensure network availability before a trust system is effectively established, the system will instead randomly select nodes from the list of currently online devices. Each device serves as a temporary authentication node for this authentication. After the authentication is completed, the trust level of each temporary authentication node will be updated based on its actual response behavior (such as whether it returns a valid partial signature in a timely manner) in order to gradually establish a trust assessment basis.

[0038] In the downgraded mode, after completing the authentication task, each temporary authentication node's actual response behavior (including whether it promptly returns a valid partial signature, whether the signature verification passes, etc.) will be recorded and used to update its trust level. The system also activates a recovery monitoring mechanism: when it detects that the trust level in the current network is not lower than a preset recovery threshold... ( The number of online devices (set to 0.5) exceeds At that time, and these devices were recently Second-rate( If no abnormal behavior is recorded during authentication tasks (set to 3), the system automatically exits the downgrade mode and reverts to the conventional authentication node selection strategy based on a comprehensive scoring function. This mechanism ensures the network can still operate when the trust foundation is weak and promptly restores normal selection logic after the trust system is rebuilt, avoiding security risks introduced by prolonged use of random selection.

[0039] As a specific implementation, the present invention further proposes a step for generating a temporary identity identifier, which specifically includes: the application device obtaining hardware features through a physical non-cloning function or a hardware unique serial number; performing a hash operation on the hardware features with the current timestamp and a random number to generate a temporary identity identifier with a one-time password feature; the temporary identity identifier has a preset validity period, and if authentication is not completed within the validity period, the temporary identity identifier automatically expires.

[0040] The temporary identity identifier is generated in the following way:

[0041] in, For temporary identification purposes, For cryptographic hash functions, These are hardware feature values ​​extracted based on physically unclonable functions or unique hardware serial numbers. This is the current timestamp. For random numbers, sign This represents a bit string concatenation operation; the hash operation ensures that the temporary identity has a one-time pad feature to prevent replay attacks, and achieves a strong binding between device identity and physical entity based on hardware characteristics.

[0042] To achieve the above objectives, the applicant device needs to possess unique hardware characteristics. For example, leveraging the properties of Physically Unclonable Functions (PUFs), a repeatable but unpredictable response value can be obtained by inputting a challenge value as a hardware characteristic; alternatively, a unique hardware serial number pre-programmed into the device can be obtained. Hardware characteristics obtained through these methods provide a unique physical identifier for the device, making them difficult to copy or tamper with.

[0043] In the HarmonyOS IoT platform, the invocation of PUF functionality needs to be deeply integrated with the underlying security architecture of the HarmonyOS system, specifically including: First, the PUF hardware module is abstracted and encapsulated through the HarmonyOS Hardware Driver Framework (HDF). HDF provides a unified driver interface for PUF, shielding the differences in PUF implementations from different hardware vendors, enabling upper-layer system services to call PUF functions in a standardized manner. HDF is also responsible for managing the PUF's power state, clock configuration, and challenge-response timing, ensuring the stability and reliability of PUF operation.

[0044] Secondly, the PUF invocation process is executed within a Trusted Execution Environment (TEE, i.e., the TEE secure isolation environment provided by HarmonyOS). The requesting device initiates a PUF challenge request through the TEE's secure system service interface. The security driver inside the TEE directly interacts with the PUF hardware, obtains the hardware characteristic value, and then performs a hash operation with the timestamp and random number in the TEE's secure memory. Throughout this process, the hardware characteristic value is not exposed to the ordinary execution environment (REE), preventing malicious applications or attackers from stealing hardware characteristics through system vulnerabilities.

[0045] For devices that do not integrate PUF hardware or whose PUF function is unavailable, the system can fall back to a backup plan: read the pre-set hardware unique serial number (such as chip ID, burned device certificate serial number, etc.) from the device's secure storage area, and verify its integrity through a secure boot chain to ensure that the serial number has not been tampered with.

[0046] After obtaining the hardware characteristics, to generate a temporary identity with one-time cryptographic pad properties, the hardware characteristics are hashed with the current timestamp TS and the random number RND. Specifically, the above information is concatenated into a bit string and then hashed using a cryptographic hash function. Generate a fixed-length hash value as a temporary identity identifier. Because each authentication uses a different timestamp and random number, the generated temporary identity is unique, effectively preventing replay attacks.

[0047] Furthermore, to enhance security and manage the lifecycle of identity identifiers, the temporary identity identifiers are assigned a preset validity period. If the requesting device fails to complete the authentication process within this validity period after generating the temporary identity identifier, the temporary identity identifier will automatically expire. When receiving an authentication request, the authentication node first checks whether the temporary identity identifier contained within it is still valid. If it has expired, the authentication request is rejected. This mechanism effectively reduces the risk of long-term misuse or leakage of temporary identity identifiers.

[0048] As a specific implementation, this invention further proposes a fault-tolerant processing mechanism to address the situation where authentication nodes fail. Specifically, after the application device sends an authentication request to multiple authentication nodes in the dynamic trust grid, it immediately starts a timer. The timer is used to monitor the response time of the authentication request to ensure that the authentication process proceeds within a reasonable time range. When an authentication request is issued, a counter is started, and corresponding processing is triggered after a preset time is reached.

[0049] If the requesting device does not receive a partial signature from any authentication node within the preset timeout period, or receives an explicit rejection message, the authentication node will be marked as an invalid node. This marking mechanism allows the requesting device to identify nodes that are currently unable or unwilling to participate in authentication, thereby excluding them from the subsequent authentication process.

[0050] To ensure the continuity of the authentication process, the requesting device re-initiates topology awareness via the HarmonyOS distributed soft bus to obtain the latest network device information, particularly discovering new and available online devices to replace the expired authentication nodes. Specifically, the requesting device can call the device discovery interface provided by the distributed soft bus to scan the surrounding network environment and obtain the latest list of online devices.

[0051] Subsequently, the requesting device selects online devices that have not been marked as invalid from the candidate authentication node list according to a preset selection strategy (such as trust level, resource idleness, etc.), thereby ensuring that the authentication mesh is always composed of active and trustworthy nodes.

[0052] After updating the dynamic trust grid, the requesting device resends the authentication request to the new set of authentication nodes, thereby ensuring that the authentication process can continue through the new nodes even if some nodes fail. Specifically, the requesting device reconstructs the authentication request message containing a temporary identity and a temporary public key, and sends it to all authentication nodes in the updated dynamic trust grid via a distributed soft bus.

[0053] The fault-tolerance processing steps continue until the number of collected partial signatures reaches the threshold, thus synthesizing a complete signature; or, if it is confirmed that the total number of available authentication nodes in the current network is lower than the threshold, authentication is terminated. The requesting device continuously counts the number of valid partial signatures collected and monitors the total number of devices in the current network that can act as authentication nodes. Once either termination condition is met, the authentication process ends.

[0054] As a specific implementation, this invention further proposes that when each authentication node verifies the authentication request, it specifically includes: verifying the validity of the timestamp in the authentication request and the signal reachability of the requesting device. The timestamp validity verification is used to ensure the timeliness of the authentication request and prevent replay attacks, for example, by checking whether the timestamp in the request is within a preset valid time window. The signal reachability verification is used to confirm whether the requesting device truly exists in the current network topology and can effectively communicate with the authentication node, for example, by measuring signal strength, latency, or utilizing the neighbor discovery mechanism provided by the distributed soft bus.

[0055] In addition, each authentication node queries the local trust database for the historical behavior records of the requesting device during the verification process. If historical records of the requesting device exist, its trust value is evaluated based on these historical records (e.g., historical authentication success rate, presence of abnormal behavior records, etc.); if not, an evaluation is performed based on a preset initial trust value. This trust value serves as an important reference for authentication decisions, influencing whether the authentication node agrees to sign for the requesting device.

[0056] In the step of "signing the temporary identity and temporary public key using their respective private keys," the private key of each authentication node is a fragment of a private key generated based on a threshold signature algorithm. This threshold signature algorithm is implemented based on system public parameters, including the system master public key. Specifically, during the system initialization phase, a pair of system master public keys is generated. and system master private key System master private key Using threshold signature algorithms (e.g.) The secret sharing scheme was divided into Private key sharding and distributed to Each authentication node holds only a fragment of its own private key. These private key fragments are generated based on common system parameters, ensuring they can work together to generate a key that can be shared by [the system]. The complete signature is verified, thus ensuring that even if a few fragments of the private keys of a few authentication nodes are leaked, a valid signature cannot be forged individually.

[0057] The partial signature is generated based on an elliptic curve threshold signature scheme. Let the threshold value be... The number of certified nodes is ,satisfy When the first After an authentication node verifies the authentication request of the applying device, the authentication node uses the private key it holds to shard the device. Temporary Identity (TID) and Temporary Public Key for the Applied Device splicing result Perform a signature operation to generate a partial signature. ,Right now This system allows for the collection of at least... After signing each of the distinct partial signatures (threshold values), a complete and valid signature is synthesized using a specific algorithm. Threshold value It is usually set to Half plus one is used to ensure consensus among a majority of nodes.

[0058] The application device collects at least After each part is signed, the complete signature is assembled using Lagrange interpolation. The complete signature This represents the consensus of a majority of authentication nodes in the dynamic trust grid. The synthesized complete signature. It has the following key features: it can utilize the system master public key, either pre-configured or obtained via a distributed soft bus. This verification process allows any device possessing the system's master public key to independently verify the validity of the distributed identity credential, without relying on a centralized certification authority.

[0059] As a specific implementation, the present invention further proposes a step of synchronizing a trust record containing the distributed identity credential to at least some online devices in the network via the distributed soft bus. Specifically, this includes: the requesting device packaging the complete signature, temporary identity identifier, temporary public key, and authentication timestamp into a trust record; synchronizing the trust record to all online devices in the network via the distributed data object mechanism of the HarmonyOS distributed soft bus in an incremental update manner; and each online device, upon receiving the trust record, verifying the complete signature using the system master public key, storing the trust record in a local trust database after successful verification, and verifying data integrity using a hash chain.

[0060] The hash chain verification is performed in the following manner: Let the current trust record be... Its integrity check value satisfy: ,in, For cryptographic hash functions, This is the integrity check value of the previous trust record. This is the serialized data for the current trust record. For the first trust record (i.e.... (At that time), the initial value of its integrity check value Defined as a string of all zero bits (i.e.) The hash function outputs a string of zeros (the length of the hash function is all zeros). This recursive relationship forms a hash chain; tampering with any trust record will invalidate subsequent verification values, thus ensuring the tamper-proof nature of the trust database. If an attacker attempts to modify a historical trust record... Then its corresponding check value Changes will occur, leading to If all subsequent checksums cannot match the recalculated results, the tampering can be detected.

[0061] Specifically, the trust record structurally encapsulates all key information generated during the authentication process. The full signature, the core output of distributed authentication, represents the shared recognition of the device's identity by multiple authentication nodes; the temporary identity identifier and temporary public key are the unique credentials used by the requesting device in this authentication session, used for identity verification and key negotiation in subsequent communications; and the authentication timestamp records the precise moment authentication was completed. Packaging all this information into a self-contained, verifiable identity credential unit facilitates efficient transmission and storage across the network.

[0062] Building upon this foundation, the Distributed Data Object (DDO) of the HarmonyOS Distributed Soft Bus enables real-time, efficient, and consistent data sharing across different devices. By using DDO to synchronize trust records, the underlying capabilities of the soft bus are leveraged to ensure reliable transmission of trust records to every online device in the network. Incremental updates synchronize only changed trust records, rather than transmitting the entire record every time, significantly reducing network bandwidth consumption and device processing burden, and improving synchronization efficiency. This synchronization to all online devices builds a network-wide, consistent trust view, providing a foundation for subsequent trusted communication between devices.

[0063] Upon receiving a trust record, each online device first verifies the complete signature using a pre-configured or acquired system master public key to confirm that the credential was generated by a threshold signature algorithm and has not been tampered with. After successful verification, the trust record is considered valid and stored in the device's local trust database. Building upon this, a hash chain verification mechanism is introduced to further enhance the data integrity and tamper-proof capabilities of the trust record during local storage and subsequent synchronization.

[0064] The hash chain verification uses cryptographic hash functions to construct a data chain to ensure data integrity. Specifically, each new trust record... Before storage, its own serialized data is compared with the integrity check value of the previous trust record. The data is concatenated, and a cryptographic hash operation is performed on the concatenated result to generate the integrity verification value of the current trust record. This recursive relation makes each Each record contains all historical information from the beginning of the chain to the current record. If any record in the chain is trusted... The corresponding hash value was tampered with. This will change, causing a mismatch in the hash calculation results of all subsequent trust records, thus immediately exposing the tampering. This mechanism provides tamper-proof capabilities for the local trust database; even if an attacker gains access to local storage, it is difficult to modify historical trust records undetected. Cryptographic hash function ( It should possess characteristics such as collision resistance, irreversibility of preimages, and avalanche effect. For example, the SHA-256 or SHA-3 algorithm can be used to ensure the security of the hash chain.

[0065] As a specific implementation, the present invention further proposes a step of updating the trust record locally, specifically including: after receiving the trust record, the online device initiates a verification query to multiple surrounding devices via a distributed soft bus to confirm the validity of the complete signature in the trust record; if the number of verification results returned by the surrounding devices exceeds a preset threshold, the receiving device writes the trust record into the local trust database and marks it as trustworthy; if the verification fails, the trust record is discarded, and the requesting device is marked as a potentially malicious device; the preset threshold θ is set as follows: ,in, The number of surrounding devices that initiated the verification query. The threshold is set to ensure that a trust record is accepted only after more than half of the verifiers approve it, preventing malicious nodes from forging credentials and injecting them into the network, and maintaining the consistency of the distributed trust environment.

[0066] To ensure the reliability and effectiveness of verification queries, online devices prioritize selecting verification nodes from the local trust database whose trust level is higher than a preset high trust threshold when choosing nearby verification nodes. And resource idleness The device is used as the query object, and the number of queries is... There must be at least 3 nodes, and no more than twice the number of authentication nodes in the dynamic trust grid. If the number of available high-trust nodes in the vicinity is insufficient, the trust level requirement may be appropriately lowered, but the minimum trust level must not be lower than [a certain threshold]. .

[0067] After collecting verification feedback results, if a minority of feedback results are found to be significantly inconsistent with the majority, the receiving device will mark the device providing that feedback as a potential anomalous node and record its abnormal behavior locally. If the same device continues to provide anomalous feedback in multiple verification queries, it will be added to a local watchlist, and its participation priority will be reduced in subsequent authentication node selection or verification queries. If necessary, the anomalous behavior can be synchronized to surrounding devices via a distributed soft bus to achieve collaborative protection.

[0068] Specifically, when an online device receives a new trust record, it no longer relies solely on its own verification result. Instead, it leverages the device discovery and communication capabilities of the distributed soft bus to proactively initiate verification requests to multiple nearby online devices. These peripheral devices independently verify the complete signature in the received trust record and return their verification results to the device that initiated the query. This step introduces a multi-party cross-verification mechanism to enhance the reliability of trust records and prevent a single malicious node from deceiving other devices by forging signatures or tampering with records.

[0069] After collecting verification feedback from surrounding devices, the receiving device counts the number of successful verifications. If this number exceeds a preset threshold, the trust record is considered trustworthy and written into the receiving device's local trust database, explicitly marked as "trustworthy." This majority-based decision-making mechanism significantly improves the tamper resistance and reliability of the trust record. If the verification results from surrounding devices fail to reach the preset threshold, the validity of the trust record is questionable, and it may be forged or tampered with. The receiving device immediately discards the trust record to prevent it from polluting the local trust database. Furthermore, to maintain network security, the device that initiates the trust record synchronization request will be marked as a "potentially malicious device" for subsequent monitoring of its behavior or further isolation measures.

[0070] The preset threshold Set as That is, the majority principle, in which This represents the total number of peripheral devices participating in the verification query. This setting can effectively resist "Syllabus attacks" or collusion attacks by a few malicious nodes. Even if there is a certain proportion of malicious nodes in the network, as long as the malicious nodes cannot form a majority, they cannot successfully inject forged trust records.

[0071] As one specific implementation, the present invention further proposes subsequent communication steps. Specifically, when the first device communicates with the second device, the first device queries the trust record of the second device from a local trust database to obtain the temporary public key of the second device. The local trust database stores the trust records of authenticated devices in the network, including the temporary identity identifier and temporary public key of the device. By querying the local trust database, the first device can efficiently and conveniently obtain the temporary public key of the second device without re-authentication. The temporary public key is generated by the device during the authentication phase and synchronized to the entire network, and has the characteristic of being bound to this authentication session.

[0072] Based on this, the first device and the second device, using their respective temporary public-private key pairs, communicate through... - The key exchange protocol dynamically negotiates and generates the session key for this communication, thereby achieving secure communication. - The protocol allows two communicating parties to independently calculate the same shared secret over an insecure channel by exchanging their respective temporary public keys and combining them with their temporary private keys. This shared secret is known only to the two communicating parties. By dynamically negotiating session keys through this protocol, it ensures that a completely new temporary key is used for each communication, thus achieving forward security.

[0073] The session key negotiation process is as follows: Let the temporary private key of the first device be... The temporary public key is The temporary private key for the second device is The temporary public key is ,in Let be a generator on an elliptic curve. The first device computes a shared secret. The second device calculates the shared secret. Session key Generate via key derivation function: .in, This is a key derivation function used to derive a valid key from a high-entropy secret. and Random numbers are generated for the first and second devices respectively to ensure the randomness and uniqueness of the session key. By introducing random numbers, even when sharing a secret... Even with the same key, different session keys can be generated. Combined with the temporary key feature of the DH protocol, they provide forward security, ensuring that even if a session key is leaked in the future, the confidentiality of past sessions will not be compromised.

[0074] As one specific implementation, the present invention further proposes a trust revocation step. This step is used to dynamically manage the trust status of authenticated devices, ensuring that the identity credentials of all devices in the network always reflect their current validity and trustworthiness. It is a key component of device lifecycle management, enabling timely responses to changes in device status and maintaining the security and consistency of the entire distributed trust environment.

[0075] Specifically, the triggering conditions for trust revocation include the following two main situations: First, when an authenticated device is offline for more than a preset validity period, the validity of its identity credentials may decrease due to the device's prolonged inactivity with the network. The preset validity period is flexibly configured according to the security requirements of the actual application scenario. Second, when a device needs to be forcibly revoked, it is proactively initiated by the network administrator, the security policy engine, or a system component that detects abnormal device behavior (such as being attacked or violating usage rules), and has higher priority and immediacy.

[0076] To maintain the characteristics of a distributed architecture, this invention allows any authentication node in the network to initiate a revocation request. This eliminates the need for a single centralized management entity, enhancing the system's robustness and resistance to single points of failure. When an authentication node detects or receives an instruction to revoke device trust, it initiates the revocation process, generating a revocation record containing a temporary identity of the device to be revoked. This record is then broadcast to other online devices in the network via the HarmonyOS distributed soft bus, achieving network-wide trust state synchronization.

[0077] When other online devices receive a broadcast revocation record, they first check if a trust record corresponding to the temporary identity exists in their local trust database, and compare the timestamp or version number of the revocation record with that of the local record. If the timestamp or version number of the revocation record is updated to the local record, the corresponding trust record is immediately deleted or marked as invalid, thus ensuring the validity and consistency of the revocation operation. Once a device's trust record is revoked, its original distributed identity credentials become invalid. If the device wishes to access the network again, it must re-execute the above authentication steps, regenerate the temporary identity and temporary public-private key pair, and initiate a new distributed federated authentication with the dynamic trust mesh, thereby ensuring that the revoked device cannot regain network access using expired credentials.

[0078] As one specific implementation, the present invention proposes a HarmonyOS IoT platform device management system. This system adopts the above-mentioned HarmonyOS distributed device identification and authentication method to perform distributed authentication and identity management on devices requesting network access, and realizes trusted communication between devices based on the trust database maintained locally by each device.

[0079] Specifically, the HarmonyOS IoT platform device management system is built on the HarmonyOS operating system, and its core function is to manage the entire lifecycle of IoT devices connected to the platform. This system uses the aforementioned HarmonyOS distributed device identification and authentication method as its core device access and identity management mechanism, leveraging HarmonyOS's distributed capabilities to achieve cross-device collaboration and resource sharing. When a new device attempts to connect to the platform, the system invokes this distributed authentication method. Through the authentication service module, it coordinates steps such as distributed soft bus, authentication node selection, temporary identity generation, threshold signature synthesis, and trust record synchronization to perform multi-party consensus verification of the device's legitimacy and establish distributed identity credentials for it, avoiding reliance on a single central node.

[0080] Furthermore, the system enables trusted communication between devices based on a locally maintained trust database on each device. After authentication, a device's trust record is stored in its local trust database. When two devices need to communicate, they query the local database to obtain each other's distributed identity credentials and temporary public keys. This is then combined with... - Key exchange protocols and other methods are used to dynamically negotiate secure session keys and establish encrypted communication channels, thereby avoiding the need for a central server as a trusted intermediary and improving communication efficiency and security.

[0081] The present invention also provides an embodiment of a practical application of the method of the present invention: I. Application Scenarios: A HarmonyOS IoT platform (hereinafter referred to as the "Platform") in a smart industrial park was selected. The Platform covers the production area, warehousing area, and office area, and includes a total of 127 online devices such as sensor nodes, edge gateways, AGVs, smart cameras, and environmental monitoring instruments. The Platform realizes interconnection between devices based on the HarmonyOS distributed soft bus, and uses the distributed device identification and authentication method provided by this invention to perform access authentication and identity management for newly added devices.

[0082] A new device—an intelligent inspection robot (Device ID: ROB-2025-001, hereinafter referred to as the "applying device")—is requesting access to the IoT platform. This device is pre-installed with the system's master public key and has the ability to generate temporary identity identifiers and temporary public-private key pairs. This embodiment will describe in detail the entire process of this device from initiating an authentication request to obtaining distributed identity credentials and establishing trusted communication with other devices within the platform.

[0083] II. Specific Implementation and Numerical Calculations at Each Stage: (a) Responding to device access requests and selecting authentication nodes: 1. Current network topology awareness: The requesting device uses the HarmonyOS distributed soft bus's device discovery mechanism to broadcast probe messages to the surrounding area and obtain a list of online devices in the current network. The soft bus works in conjunction with near-field communication and LAN multicast technology to return online device information within 0.5 seconds.

[0084] There are currently 126 devices online. Information on some key devices is shown in the table below:

[0085] 2. Authentication Node Selection: The platform uses a comprehensive scoring function to score online devices, with weighting coefficients set as follows: Smoothing coefficient Resource idleness threshold .

[0086] Taking the GW-001 edge gateway as an example, its comprehensive score is calculated as follows:

[0087] Calculate each item:

[0088] item: , ,

[0089] but:

[0090] The same applies to other devices: AGV-12: ; CAM-08: ; SENS-23: ; EDGE-05: ; Select the one with the highest overall score Each device serves as an authentication node, and the final set of authentication nodes selected is as follows:

[0091] in If the number is odd, the threshold signature requirement is met.

[0092] (ii) Apply for the device to generate a temporary identity and a temporary public-private key pair: 1. Hardware Feature Extraction: The application device extracts hardware feature values ​​through a Physically Unclonable Function (PUF). After sampling and quantization, a 256-bit binary feature is obtained:

[0093]

[0094] 2. Generate a temporary identity: Get current timestamp (Unix timestamp, seconds), random number After concatenation, the hash is calculated using the SHA-256 hash function:

[0095] The calculation yielded:

[0096]

[0097] This temporary identity is valid for 60 seconds and will automatically expire if authentication is not completed within the time limit.

[0098] 3. Generate a temporary public / private key pair: The requesting device generates a temporary public / private key pair for this authentication session based on elliptic curve (secp256k1): Temporary private key : Randomly generate a 256-bit integer, with the following possible values:

[0099]

[0100] Temporary public key : Through the base point of the elliptic curve calculate:

[0101] Obtain the public key point Compression form:

[0102]

[0103] (III) Initiating Distributed Joint Authentication and Partial Signature Generation: 1. Sending authentication request: The requesting device sends the authentication request to five authentication nodes in the dynamic trust mesh via a distributed soft bus. The request content includes: Temporary identity ; Temporary public key ; Current timestamp ; Authentication request type identifier; 2. Authentication Node Verification and Partial Signature: Taking the authentication node EDGE-05 as an example, its verification process is as follows: Check the validity of the timestamp: If the time difference with the current time is less than 5 seconds, it is valid.

[0104] Signal reachability verification: confirmed via soft bus heartbeat. It is accessible.

[0105] Query the local trust database: The requested device is a new device with no history. An initial trust value of 0.8 is used for evaluation, which meets the minimum trust requirements.

[0106] After successful verification, EDGE-05 uses its private key to fragment. right Perform signing and generate a partial signature. .

[0107] The system adopts a threshold signature scheme, setting a threshold value. Number of certified nodes Each authentication node's private key fragment is generated from the system's master private key via... Secret sharing scheme generated.

[0108] EDGE-05 calculation section signature:

[0109] Return the signature value (in hexadecimal):

[0110]

[0111] Other authentication nodes (GW-001, AGV-12, CAM-08, SENS-23) completed the verification and returned partial signatures.

[0112] (iv) Fault tolerance and signature synthesis: 1. Fault tolerance: After sending the authentication request, the requesting device starts a timer with a timeout of 3 seconds. If a partial signature from an authentication node is not received within the timeout period, it is marked as an invalid node and a new topology-aware replacement is initiated. In this embodiment, all five authentication nodes return partial signatures within 2.1 seconds, with no timeouts or rejections, thus eliminating the need to trigger a fault tolerance mechanism.

[0113] 2. Generate a complete signature: After collecting three partial signatures (threshold values), the requesting equipment synthesizes a complete signature using Lagrange interpolation. Assume the collected partial signatures come from EDGE-05, GW-001, and AGV-12, and their signature values ​​are denoted as follows: .

[0114] Composite calculation (simplified illustration):

[0115] Complete signature after synthesis for:

[0116]

[0117] The complete signature can be obtained from the system's master public key. The verification passed, proving that it is jointly recognized by at least 3 authentication nodes.

[0118] (v) Trust record synchronization and local update: 1. Establish a trust record: The device application will package the following information into a trust record. : Full signature ; Temporary identity ; Temporary public key ; Authentication timestamp ; 2. Synchronize to online devices: Using the Distributed Data Object (DDO) of the HarmonyOS Distributed Soft Bus, the requesting device synchronizes its trust records to all online devices in the network via incremental updates. The synchronization process is completed within 0.8 seconds, covering the current 126 online devices.

[0119] 3. Local verification and hash chain verification: Taking the online device GW-001 as an example, after receiving the trust record: Use the system master public key Verify complete signature Verification passed.

[0120] Perform hash chain verification: Let the integrity verification value of the previous trust record in the local trust database be... The hash chain verification value of the current trust record is:

[0121] Calculated And store it in the local database.

[0122] 4. Multi-party cross-validation: GW-001 initiated verification queries to three surrounding devices, and the query results were all "verification passed," exceeding the preset threshold. After confirming the trust record is valid, it is written to the local database and marked as "trusted".

[0123] (vi) Subsequent communication and session key negotiation: 1. Query trust history: Suppose another online device, AGV-12, needs to communicate with the requesting device (ROB-2025-001). AGV-12 queries the local trust database for the trust record of ROB-2025-001 and obtains its temporary public key. .

[0124] 2. Session Key Negotiation AGV-12 and ROB-2025-001 negotiated the session key via the Diffie-Hellman key exchange protocol: AGV-12 Temporary Private Key:

[0125]

[0126] AGV-12 Temporary Public Key: (Calculated by the system) ROB-2025-001 Temporary Private Key: ; ROB-2025-001 Temporary Public Key: ; AGV-12 calculates shared secrets:

[0127] ROB-2025-001 Computational Shared Secret:

[0128] Both sides calculated the same result Then, the session key is generated using the key derivation function:

[0129] in Random numbers are generated for each party to ensure the randomness and forward security of the session key.

[0130] (vii) Trust revocation and re-authentication: If the inspection robot goes offline due to a malfunction and exceeds the preset validity period (30 days) during subsequent operation, the authentication node EDGE-05 in the platform detects its offline status, initiates a revocation request, generates a revocation record, and broadcasts it to all online devices via the distributed soft bus.

[0131] Upon receiving the revocation record, other online devices compare the timestamps and, after confirming that the revocation record has been updated, mark the trust record of ROB-2025-001 as invalid. If the device needs to reconnect to the network, it must re-execute all steps of this authentication method, regenerate the temporary identity and temporary public-private key pair, and re-authenticate through the dynamic trust mesh.

[0132] III. Effect Verification and Comparison:

[0133] Verification through the above embodiments shows that the method of the present invention achieves efficient, secure, and decentralized device authentication and identity management in the HarmonyOS IoT platform, effectively solving problems such as single point of failure, authentication delay, and trust anchor dependence in traditional solutions, and has significant engineering practical value.

[0134] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in the present invention, and these should all be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A HarmonyOS distributed device identification and authentication method for device management on an IoT platform, characterized in that, Includes the following steps: In response to a request from a device to access the network, the HarmonyOS distributed soft bus is used to perceive the current network topology in real time. Based on a preset selection strategy, multiple authentication nodes are selected from online devices to form a dynamic trust mesh, thereby distributing the authentication load to peripheral devices and eliminating the dependence on the central node. The application device generates a temporary identity identifier based on its hardware characteristics and generates a temporary public-private key pair bound to this authentication session. The authentication request containing the temporary identity identifier and temporary public key is sent to multiple authentication nodes in the dynamic trust grid through the distributed soft bus to initiate distributed joint authentication. Each of the authentication nodes verifies the authentication request, and after successful verification, signs the temporary identity and temporary public key using its own private key to generate its own partial signature, and returns the partial signature to the requesting device, so as to distribute the authentication decision-making power to multiple independent nodes; After receiving partial signatures that meet the threshold number, the application device synthesizes a complete signature as a distributed identity credential using a threshold signature algorithm. The trust record containing the distributed identity credential, the temporary identity identifier, and the temporary public key is synchronized to at least some online devices in the network through the distributed soft bus, so as to realize the generation of identity credentials without a central trust anchor by utilizing the composability of threshold signatures. Each device is pre-configured or obtains a system master public key for verifying the threshold signature via a distributed soft bus. After receiving the trust record, the online device uses the system master public key to verify the validity of the complete signature. After successful verification, the trust record is updated locally, so as to achieve consistent recognition of the distributed identity credential by all network devices without the need for global consensus.

2. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, The step of "using HarmonyOS distributed soft bus to perceive the current network topology in real time and selecting multiple authentication nodes from online devices according to a preset selection strategy" further includes: The device discovery mechanism of the distributed soft bus is used to obtain a list of nearby online devices; Select from the list of online devices based on at least one of the following indicators: trust level, historical online duration, historical authentication success rate, and resource availability. Each device acts as an authentication node, forming a dynamic trust mesh, in which... It is an odd number greater than or equal to 3; The trust level is dynamically updated based on the device's historical online time and historical authentication success rate, and is maintained locally by each device. The selection strategy includes a comprehensive scoring function: ； in, Indicates the first A comprehensive rating of each online device. The trust level of this device, Historical online time (in seconds). This represents the historical authentication success rate (value range [0,1]). This represents the current resource idleness (value range [0,1]). The weighting coefficients and , for The smoothness coefficient of the function. The resource idleness threshold; the highest comprehensive score Each device is selected as an authentication node to dynamically filter out trusted and resource-rich collaborative authentication entities in a distributed environment.

3. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, The step of "generating a temporary identity based on its hardware characteristics" further includes: The application device obtains hardware characteristics through a physically unclonable function or a unique hardware serial number; The hardware features are hashed with the current timestamp and a random number to generate a temporary identity with a one-time password feature. The temporary identity has a preset validity period. If authentication is not completed within the validity period, the temporary identity will automatically expire. The temporary identity identifier is generated in the following way: ； in, For temporary identification purposes, For cryptographic hash functions, These are hardware feature values ​​extracted based on physically unclonable functions or unique hardware serial numbers. This is the current timestamp. For random numbers, sign This represents a bit string concatenation operation; the hash operation ensures that the temporary identity has a one-time pad feature to prevent replay attacks, and achieves a strong binding between device identity and physical entity based on hardware characteristics.

4. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, After the application device sends authentication requests to multiple authentication nodes in the dynamic trust grid, the process also includes a fault tolerance step: The application device starts a timer. If it does not receive a partial signature from any authentication node within the preset timeout period, or receives a message rejecting the signature, it marks the authentication node as an invalid node. The requesting device re-initiates topology awareness via a distributed soft bus, selects a new online device from the candidate authentication node list to replace the failed node, updates the dynamic trust grid, and resends the authentication request until the number of collected partial signatures reaches the threshold number, or the authentication is terminated when it is confirmed that the total number of available authentication nodes in the current network is lower than the threshold number.

5. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, The step of "each authentication node verifies the authentication request" specifically includes: Verify the validity of the timestamp in the authentication request and the signal reachability of the requesting device; Query the historical behavior records of the requested device in the local trust database. If the records exist, evaluate the trust value based on the historical records. If the records do not exist, evaluate the trust value based on the preset initial trust value. In the step of "signing the temporary identity and temporary public key using their respective private keys", the private key of each authentication node is a fragment of a private key generated based on a threshold signature algorithm. The threshold signature algorithm is implemented based on system public parameters, which include the system master public key. The partial signature is generated based on the elliptic curve threshold signature scheme, with a threshold value of [value missing]. The number of certified nodes is ,satisfy , No. Partial signature generated by each authentication node satisfy: ； in, Indicates the use of the first Private key sharding of each authentication node Perform the signature operation. For temporary identification of the equipment application, The temporary public key for the requesting device; the requesting device, upon collecting at least After each part is signed, the complete signature is synthesized using Lagrange interpolation. The complete signature Able to utilize the system's master public key Verification is required.

6. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, The step of "synchronizing the trust record containing the distributed identity credentials to at least some online devices in the network via the distributed soft bus" further includes: The application device packages the complete signature, temporary identity, temporary public key, and authentication timestamp into a trust record; The trust record is synchronized to all online devices in the network in an incremental update manner through the distributed data object of HarmonyOS distributed soft bus; After receiving the trust record, each online device verifies the complete signature using the system master public key. If the verification is successful, the trust record is stored in the local trust database, and the data integrity is verified using a hash chain. The hash chain verification is performed in the following manner: Let the current trust record be... Its integrity check value satisfy: ； in, For cryptographic hash functions, This is the integrity check value of the previous trust record. The serialized data of the current trust record forms a hash chain through this recursive relationship. Tampering with any trust record will cause the subsequent verification value to become invalid, thereby ensuring the tamper-proof characteristics of the trust database.

7. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 6, characterized in that, The steps for "completing the trust record update locally" specifically include: After receiving the trust record, the online device initiates a verification query to multiple surrounding devices via a distributed soft bus to confirm the validity of the complete signature in the trust record; If the number of verified results from surrounding devices exceeds a preset threshold, the receiving device will write the trust record to its local trust database and mark it as trustworthy. If the verification fails, the trust record is discarded, and the requesting device is marked as a potentially malicious device. The preset threshold Set as: ； in, The number of surrounding devices that initiated the verification query. The threshold is set to ensure that a trust record is accepted only after more than half of the verifiers approve it, preventing malicious nodes from forging credentials and injecting them into the network, and maintaining the consistency of the distributed trust environment.

8. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, It also includes subsequent communication steps: When the first device communicates with the second device, the first device queries the trust record of the second device from the local trust database to obtain the temporary public key of the second device; The first and second devices, based on their respective temporary public-private key pairs, communicate via... - The key exchange protocol dynamically negotiates and generates the session key for this communication, thus enabling secure communication. The session key negotiation process is as follows: Let the temporary private key of the first device be... The temporary public key is The temporary private key for the second device is The temporary public key is ,in is a generator on an elliptic curve; First device calculates shared secrets The second device calculates the shared secret. Session key Generate via key derivation function: ； in, Derived function for key. and Random numbers generated for the first and second devices respectively are used to ensure the randomness and forward security of the session key.

9. The HarmonyOS distributed device identification and authentication method for IoT platform device management according to claim 1, characterized in that, It also includes a trust revocation step: When an authenticated device goes offline for more than the preset validity period or needs to be forcibly revoked, any authentication node in the network initiates a revocation request and broadcasts the revocation record containing the device's temporary identity via the distributed soft bus. After receiving the revocation record, other online devices compare it with the timestamp or version number in the local trust database. If the timestamp of the revocation record is updated to the local record, the corresponding trust record is deleted or marked as invalid. When a revoked device reapplies for access, it must repeat the authentication steps described in claim 1.

10. A device management system for the HarmonyOS Internet of Things platform, characterized in that, The HarmonyOS distributed device identification and authentication method as described in any one of claims 1 to 9 is used to perform distributed authentication and identity management on devices requesting network access, and to realize trusted communication between devices based on the trust database maintained locally by each device.

Images