A robot distributed digital identity authentication system based on RobotDID and an implementation method thereof

Abstract

This invention discloses a robot distributed digital identity authentication system and implementation method based on RobotDID, including a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a secure execution module, and a lifecycle management module. The RobotDID generation module extracts the hardware fingerprint from the robot's built-in single PUF chip, generates a RobotDID through SM3 hashing, and generates an SM2 key pair in a secure execution environment. The private key is stored as encrypted text encapsulated in PUF. The on-chain evidence storage module uploads the DID document's SM3 hash to the PBFT consortium blockchain. The identity authentication module completes machine-to-machine or machine-to-platform authentication through a challenge-and-response mechanism. The secure execution module completes signing in an isolated environment. The lifecycle management module implements registration, update, authorization, revocation, and log uploading.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things security and robot trusted authentication technology, and particularly relates to a robot distributed digital identity authentication system and implementation method based on RobotDID. Background Technology

[0002] Currently, robot and smart device authentication primarily relies on a centralized server management model. Specifically, when a robot leaves the factory, the manufacturer registers its device identifier (such as serial number and MAC address) and corresponding public key with a central server. During authentication, the robot sends a signature challenge response to the server, which then queries its local database to verify the signature. Some systems use Public Key Infrastructure (PKI) to issue digital certificates for robots, with Certificate Authorities (CAs) managing the certificate lifecycle. In recent years, Distributed Digital Identity (DID) technology has begun to be applied in the Internet of Things (IoT) field, storing identity identifiers and DID documents based on blockchain or distributed ledgers to achieve decentralized publication of identity information. Furthermore, Trusted Execution Environments (TEEs) and security chips have been used for key storage in some high-end devices, but primarily in payment and content protection scenarios, and have not yet been deeply integrated with robot distributed identity systems. Some solutions employ "multi-sensor fusion" for robot identity authentication (including fusion of multi-source features from PUF chips, temperature and humidity sensors, vibration sensors, and electromagnetic signals). However, this approach has the following drawbacks: multi-sensor fusion increases hardware costs and system complexity, making it unsuitable for low-cost consumer robots; the calibration and maintenance costs of multi-source sensors are high, and sensor failure in harsh environments can render the entire identity authentication system unusable; this solution does not mandate the use of national cryptographic algorithms, failing to meet compliance requirements in domestic financial, government, and military industries. These technologies are developing independently and have not yet formed a complete distributed digital identity authentication solution specifically for robots, integrating a single PUF hardware fingerprint, national cryptographic algorithms, consortium blockchain evidence storage, a secure execution environment, and full lifecycle management.

[0003] However, the aforementioned existing technologies still have the following shortcomings.

[0004] 1. The centralized server management model has the risk of single point of failure. Once the server is attacked or malfunctions, all robots will be unable to complete identity authentication, and the server database is easily tampered with, leading to identity forgery.

[0005] 2. The robot lacks an unforgeable identity generated based on hardware physical fingerprints (such as PUF) and relies only on software-level serial numbers or certificates, making it easy to be impersonated and accessed.

[0006] 3. Identity data is stored and transmitted in plaintext or parsable form, lacking privacy protection, and original identity information needs to be exposed during cross-platform authentication.

[0007] 4. Robots from different manufacturers and platforms cannot achieve unified mutual trust authentication. In cross-domain scenarios, complex trust alliances or centralized bridging are required, resulting in poor universality.

[0008] 5. Private keys are often stored as files in ordinary file systems, lacking hardware-level isolation, and are easily stolen by operating system vulnerabilities or physical attacks.

[0009] 6. The entire lifecycle of a robot's identity, from registration to cancellation, lacks a traceable audit mechanism, and operation records are easily tampered with or lost.

[0010] 7. Existing multi-sensor fusion-based solutions suffer from high hardware costs, system complexity, sensor susceptibility to failure, and non-compliance with national cryptographic standards. Therefore, there is an urgent need for a robot distributed digital identity authentication solution that combines a single PUF hardware fingerprint, national cryptographic algorithms, tamper-proof evidence storage via a consortium blockchain, hardware isolation of a secure execution environment, and full lifecycle management to address these issues. Summary of the Invention

[0011] To overcome the aforementioned shortcomings of the prior art, this invention provides a robot distributed digital identity authentication system and implementation method based on RobotDID, which solves the problems of single point of failure, easy identity forgery, privacy leakage, difficulty in cross-domain mutual recognition, lack of hardware protection for keys, and unauditable lifecycle in the prior art.

[0012] To achieve the above objectives, the present invention provides the following technical solution:

[0013] A robot distributed digital identity authentication system based on RobotDID includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, a lifecycle management module, and an optional health monitoring module. The RobotDID generation module generates an asymmetric key pair based on the robot's unique hardware identifier, and generates a distributed digital identity identifier RobotDID and a corresponding DID document based on the asymmetric key pair. The RobotDID generation module provides the DID document to the on-chain evidence storage module and the identity authentication module for use.

[0014] The unique hardware identifier includes a hardware fingerprint feature code extracted from a single PUF chip built into the robot. The PUF chip does not rely on multi-source fusion of temperature and humidity sensors, vibration sensors, or electromagnetic signals. The RobotDID generation module inputs the PUF fingerprint feature code into the SM3 hash function to generate a PUF hash value, and generates a RobotDID based on the PUF hash value.

[0015] The on-chain evidence storage module performs hash calculation on the DID document, uploads the hash value of the DID document to the consortium blockchain storage, and provides the evidence storage information for the lifecycle management module to record; the identity authentication module calls the security execution module through a challenge-response mechanism to complete the identity verification between the robot and the platform, as well as between robots; the identity authentication module supports SM2 signature verification.

[0016] The secure execution module responds to the call of the identity authentication module and completes the private key storage and signature operation within the secure execution environment. The private key is not exposed to the outside world. The private key is generated by the SM2 elliptic curve cryptography algorithm, generated and encapsulated based on the physical non-cloning function of the PUF chip. The private key is stored in the secure storage area in ciphertext form and is reconstructed inside the PUF when used. It is prohibited to leave the secure storage area in plaintext form.

[0017] The lifecycle management module provides unified management for the RobotDID generation module, the on-chain evidence storage module, the identity authentication module, and the security execution module, and performs registration, update, authorization, revocation, and operation log recording for RobotDID.

[0018] Health monitoring steps: Collect robot operation status data, calculate 8-dimensional health index, use random forest model to predict health status, put the SM3 hash value of health conclusion on the blockchain for evidence storage, and do not put the original health data on the blockchain.

[0019] The health monitoring module collects the following eight operational status parameters of the robot and calculates the corresponding eight-dimensional health index vector H=(h_1,h_2,...,h_8):

[0020] •h1 – CPU temperature utilization: The ratio of the current CPU temperature to the chip's maximum allowable operating temperature (normalized to 0~1).

[0021] •h2 – Battery voltage health: The absolute value of the deviation between the current voltage and the rated voltage, mapped to 0~1 (1 indicates optimal) via the Sigmoid function;

[0022] •h3 – Cumulative value of joint angle error: Root mean square error between the actual angle and the commanded angle of each joint, normalized.

[0023] •h4 – Vibration amplitude: The mean (normalized) value of the vibration amplitude measured by the triaxial accelerometer after low-pass filtering.

[0024] •h5 – Drive current fluctuation coefficient: The coefficient of variation (standard deviation / mean) of the motor drive current;

[0025] h6 – Packet loss rate: The average packet loss rate over the most recent N communication cycles;

[0026] •h7 – Memory Usage: The percentage of total memory currently used for stack and dynamic memory usage;

[0027] • h8 – Disk / Flash Remaining Life Index: Percentage of remaining life based on write count or bad block rate (normalized).

[0028] The above 8-dimensional health index is collected and calculated locally by the robot at fixed intervals (e.g., every hour), without the need to upload the original data.

[0029] Mapping rules from random forest model output to health conclusions

[0030] The random forest model is pre-trained in the cloud using a labeled robot fault dataset. The model input is the aforementioned 8-dimensional health index vector H, and the output is a probability vector P=(p_{normal},p_{warning},p_{fault}) for three categories, representing the predicted probabilities of "normal", "warning", and "fault", respectively.

[0031] The rules for determining a health status are as follows:

[0032] • If p_{normal} ≥ 0.7, then it is considered "normal";

[0033] • If p_{normal} < 0.7 and p_{fault} < 0.5, then it is judged as a "warning".

[0034] • If p_{fault} ≥ 0.5, then it is determined as a "fault";

[0035] • A voting confirmation mechanism is adopted: the final health conclusion is output only when the judgment results of three consecutive sampling cycles are consistent; otherwise, the previous health conclusion is maintained to avoid state fluctuations.

[0036] The final output health conclusion (such as one of "normal", "warning", or "fault") and its corresponding timestamp are stored on the blockchain after being calculated by SM3 hash. The original probability vector and the original value of the health index are stored locally and are not on the blockchain.

[0037] The robot's unique hardware identifier is a PUF hardware fingerprint, along with at least one of the following optional components: SN serial number, chip ID, MAC address, or secure element ID. The DID document contains a DID identifier, an SM2 public key, device attributes, permission policies, and an expiration date. The on-chain evidence storage module only stores the hash digest of the DID document and does not store the original privacy data; the consortium blockchain uses the PBFT consensus mechanism.

[0038] A method for implementing distributed digital identity authentication for robots based on RobotDID includes the following steps:

[0039] S1: First, collect the robot's unique hardware identifier; the unique hardware identifier includes the hardware fingerprint feature code extracted from the robot's built-in single PUF chip;

[0040] S2: Then, a key pair is generated based on an asymmetric encryption algorithm, and a RobotDID is generated according to the unique hardware identifier, and a corresponding DID document is constructed; wherein, the PUF fingerprint feature code is input into the SM3 hash function to generate a PUF hash value, and the RobotDID is assembled according to the format containing the SM3 identifier; the SM2 algorithm is called to generate a key pair in the robot-side TEE trusted execution environment, a stable key is generated based on the fuzz extractor of the PUF chip, the private key is encapsulated in PUF and stored in the secure storage area in ciphertext form, and the public key is written into the DID document;

[0041] S3: Then, calculate the hash value of the DID document and store the hash value on the blockchain; the hash value is calculated using the SM3 algorithm and uploaded to the consortium blockchain, which adopts the PBFT consensus mechanism.

[0042] S4: Next, the authentication direction sends a random challenge message to the target robot;

[0043] S5: Then, the target robot uses its own private key to perform an SM2 signature on the random challenge information within a secure execution environment, generating a signature result;

[0044] S6: The authenticator then obtains the DID document of the target robot from the consortium blockchain, extracts the SM2 public key from the DID document, and uses the public key to verify the legality of the signature result;

[0045] S7: If the verification passes, the target robot is allowed to access; if the verification fails, access is denied.

[0046] The private key is generated and encapsulated based on the PUF chip, stored in encrypted form in a secure storage area, and is not exported from the secure execution environment or transmitted in plaintext.

[0047] The authentication process supports authentication between robots, authentication between robots and platforms, and mutual trust authentication across consortium blockchains.

[0048] It also includes RobotDID lifecycle management steps: identity information update, permission change, temporary authorization, proactive revocation, and on-chain auditing of operation logs.

[0049] The random challenge information is dynamically generated and not reused during each authentication; the signature of the random challenge information is performed using the SM2 algorithm within the secure execution environment.

[0050] Health monitoring steps: Collect robot operation status data, calculate an 8-dimensional health index, use a random forest model to predict health status, store the SM3 hash value of the health conclusion on the blockchain for evidence, and do not store the original health data on the blockchain; and the communication encryption adopts the national cryptographic SM4 algorithm.

[0051] The technical effects and advantages of the RobotDID-based distributed digital identity authentication system and implementation method for robots in this invention are as follows:

[0052] 1. This invention employs a distributed digital identity system, eliminating the risk of single-point failures and data leakage by ensuring robot identities are not managed by a centralized server. It generates an unforgeable RobotDID based on the hardware fingerprint features of a single PUF chip, eliminating the need for multi-sensor fusion, reducing hardware costs by approximately 60%, and making the system simpler and more reliable. This avoids the difficulties of multi-sensor calibration and maintenance, and the problem of authentication unavailability due to sensor failure in harsh environments. An asymmetric key pair and RobotDID are generated based on the robot's PUF hardware fingerprint, ensuring that each robot has a globally unique and unforgeable identity. The hash value of the DID document is stored on the blockchain, leveraging the immutability of the PBFT consensus mechanism of the consortium blockchain to guarantee the authenticity and traceability of the identity information. Simultaneously, only the hash digest is stored, not the original privacy data, balancing public verification and privacy protection. Identity authentication is completed through a challenge-response mechanism. The authenticator issues random challenge information, the robot signs using its SM2 private key, and the authenticator obtains the SM2 public key from the consortium blockchain for verification. The entire process requires no real-time third-party intervention, supporting machine-to-machine authentication, machine-to-platform authentication, and cross-consortium blockchain mutual trust authentication, achieving decentralized, cross-platform, and cross-vendor identity mutual recognition. The private key is generated and encapsulated based on a PUF chip and stored in encrypted form in a secure storage area. The signature operation is completed within a secure environment, effectively preventing key leakage and physical attacks. The lifecycle management module supports the registration, update, authorization, revocation, and on-chain auditing of RobotDID operation logs, realizing controllable management and traceable auditing of the entire identity lifecycle.

[0053] 2. This invention adopts national cryptographic algorithms (SM2 / SM3 / SM4) throughout the entire stack, meeting the compliance requirements of domestic financial, government, and military industries. Communication encryption adopts the national cryptographic algorithm SM4, which has significant compliance advantages compared with existing multi-sensor fusion solutions that do not use national cryptographic algorithms.

[0054] 3. The optional health monitoring module of this invention uses a random forest model to evaluate the robot's health status and calculates an 8-dimensional health index. Only the SM3 hash value of the health conclusion is stored on the blockchain for evidence, and the original health data is not stored on the blockchain. This ensures that the health status is auditable and traceable, while avoiding the leakage of sensitive operational data. It is suitable for scenarios with high privacy protection requirements.

[0055] 4. This invention is based on a single PUF chip rather than multi-sensor fusion, which reduces hardware costs by about 60%, eliminates the need for sensor calibration and maintenance, and is particularly suitable for low-cost consumer robots and resource-constrained IoT robot nodes. It has good versatility and scalability. Attached Figure Description

[0056] Figure 1 This is a flowchart of PUF key generation and encapsulation;

[0057] Figure 2 This is a diagram of the DID document structure. Detailed Implementation

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

[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include," "contain," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "includes..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0060] refer to Figure 1-2This invention provides a robot distributed digital identity authentication system and implementation method based on RobotDID. The system includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, a lifecycle management module, and an optional health monitoring module. The RobotDID generation module generates an asymmetric key pair and a distributed digital identity identifier (RobotDID) and a DID document based on the hardware fingerprint features extracted from the robot's built-in single PUF chip. The on-chain evidence storage module stores the hash value of the DID document on the blockchain. The identity authentication module calls the security execution module through a challenge-response mechanism to complete the authentication between the robot and the platform or machine. For authentication between humans and robots, the secure execution module stores and signs private keys within a secure execution environment, ensuring the private keys are not exposed externally. The lifecycle management module manages all modules and performs registration, update, authorization, revocation, and operation log recording for RobotDID. The method includes extracting the PUF hardware fingerprint, generating a PUF hash using SM3 hashing, generating a key pair based on SM2, constructing RobotDID and DID documents, calculating the hash and storing it on the blockchain, the authenticator initiating a random challenge, the robot signing with its private key using SM2 within the secure execution environment, and the authenticator retrieving the DID document from the consortium blockchain to extract the SM2 public key for verification. If the verification is successful, access is granted; otherwise, access is rejected.

[0061] Example 1

[0062] Industrial robot scenarios, integrating PUF, national cryptographic standards, and consortium blockchain.

[0063] Objective: To enable trusted access for industrial robots on the industrial internet platform, avoid single points of failure and identity forgery risks associated with traditional centralized identity authentication, and meet national cryptographic compliance requirements.

[0064] System Implementation: The system deployed in this embodiment includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, and a lifecycle management module. The security execution module uses a national cryptographic security chip (such as the ZTWGM series) with a built-in single PUF chip, integrated into the main control chip of the industrial robot; the on-chain evidence storage module is based on the FISCOBCOS consortium blockchain, uses the PBFT consensus mechanism, and is deployed on 5 consensus nodes within the factory; the identity authentication module runs on the industrial internet platform; and the lifecycle management module runs on the management platform. End-to-end communication encryption uses the national cryptographic SM4 algorithm.

[0065] Implementation steps:

[0066] S1: Read the stimulus response pairs from the robot's built-in single PUF chip and extract the PUF hardware fingerprint feature code. In this embodiment, the 128-bit stimulus response output by the PUF chip is used as the hardware identifier.

[0067] S2: Input the PUF fingerprint feature code into the SM3 hash function to generate a 256-bit PUF hash value (e.g.:

[0068] 6f8d4e2c1a9b7f3e5d8c2a4b6f1e9d7c8a3b5f2e6d9c4a8b7f2e1d5c9b3a7f4e);

[0069] Based on the PUF hash value, a RobotDID is generated according to the format did:robot:sm3:6f8d4e2c... A key pair is generated in the TEE trusted execution environment using the SM2 algorithm. The private key is encapsulated by the PUF fuzz extractor and stored in a secure storage area, while the public key is written into the DID document. The DID document contains the DID identifier, the SM2 public key in W3C standard format (e.g., Base58 or Base64 URL encoding), device attributes (device model, manufacturer name, production batch), access policy (allowing access only to specified MQTT topics), and validity period (365 days from registration).

[0070] S3: Calculate the SM3 hash value of the DID document and store the hash value on the blockchain. Calculating the SM3 hash value of the DID document yields:

[0071] The hash value 1ab21d8355cfa17f8e61194831e6e9b7c0e2c0a6ac9e7e6b9d6e0c5f3e5e5e5e (for example only) is submitted as transaction data to the consortium blockchain, and the PBFT consensus node packages it and uploads it to the chain.

[0072] S4: The authentication process initiates a random challenge to the target robot. The industrial internet platform generates a 128-bit random number, which is dynamically generated for each authentication and is not reused.

[0073] S5: The target robot uses its private key to perform an SM2 signature on the random challenge information within a secure execution environment, generating a signature result. The robot then uses its private key to sign the random number within the secure chip.

[0074] S6: The authenticator obtains the DID document of the target robot from the consortium blockchain, extracts the SM2 public key from the DID document, and uses the public key to verify the legality of the signature result. The platform obtains the robot's DID document from the consortium blockchain and extracts the public key to verify the signature.

[0075] S7: If the verification passes, the target robot is allowed to access; if the verification fails, access is denied. In this embodiment, if the verification passes, the platform allows the robot to access the MQTT server and establish secure communication. In addition, the lifecycle management module performs operation recording: recording this registration operation, generating an operation log, which includes the operation type (registration), operation object (did:robot:sm3:6f8d...), operation time, operator identity, and the log hash is uploaded to the blockchain for auditing.

[0076] Implementation Results: This embodiment achieves decentralized and trusted access for industrial robots, avoiding the single point of failure risk of traditional centralized identity servers. A single PUF chip provides an unforgeable hardware fingerprint. The private key is generated and encapsulated within the secure chip, and the original private key cannot be read by any external interface. The signature operation is completed entirely within the secure chip, without exporting the private key. The full-stack national cryptographic algorithm meets domestic compliance requirements.

[0077] Example 2

[0078] Service robot mutual trust + health monitoring.

[0079] Objective: To achieve direct mutual trust and authentication between two service robots without the need for a central server, and to add a health monitoring module that can be enabled or disabled based on computing power configuration.

[0080] System Implementation: The system deployed in this embodiment includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a secure execution module, a lifecycle management module, and a health monitoring module. Robot A and Robot B are both home service robots, each with a built-in single PUF chip. The secure execution environment uses an ARMTrustZone+PUF secure storage area. The on-chain evidence storage module uses the FISCOBCOS consortium blockchain (PBFT consensus) and is deployed on the home gateway device. The identity authentication module runs internally within each robot, supporting direct authentication between robots. The health monitoring module runs locally on the robot, with a pre-configured random forest model.

[0081] Implementation steps:

[0082] S1: Read the stimulus response pairs of the robot's built-in single PUF chip and extract the PUF hardware fingerprint feature code.

[0083] S2: Generate RobotDID based on PUF hash (format as above), call SM2 in TEE to generate key pair, and store the private key after PUF encapsulation.

[0084] S3: DID document SM3 hash on-chain notarization (consortium blockchain).

[0085] S4: Robot A, acting as the certifier, generates random challenge information and sends it to Robot B.

[0086] S5: Robot B uses its private key to perform an SM2 signature on the challenge message within the TrustZone secure world.

[0087] S6: Robot A obtains Robot B's DID document from the consortium blockchain and extracts the SM2 public key for signature verification.

[0088] S7: After successful verification, robot A trusts robot B's identity and sends instructions to it.

[0089] Health monitoring steps: Robots A and B collect operational status data (CPU temperature, battery voltage, joint angle error, etc.) every hour, calculate an 8-dimensional health index (e.g., "CPU temperature, battery voltage, joint angle error, vibration amplitude, current fluctuation, communication latency, memory usage, disk health"), input it into a random forest model, and output a health conclusion (normal / warning / fault). The SM3 hash value of the health conclusion is stored on the blockchain for notarization; the original health data is stored locally and not on the blockchain. The final health conclusion is only output when the judgment results are consistent for three consecutive sampling periods. The random forest model updates its parameters quarterly via the cloud and distributes them to the robots through a secure channel.

[0090] Implementation Results: This embodiment achieves direct and trustworthy mutual trust between robots. The authentication process does not require any central server, avoiding the performance bottlenecks and single points of failure inherent in centralized authentication. The challenge-response mechanism ensures the uniqueness of each authentication and protection against replay attacks. A single PUF chip reduces hardware costs, the national cryptographic algorithm meets compliance requirements, and the health monitoring module enables trusted auditing of health status without disclosing raw data.

[0091] Example 3

[0092] Cross-domain mutual trust + temporary authorization.

[0093] Objective: To achieve mutual recognition of robot identities among different manufacturers and different consortium blockchains, solve the problem of cross-domain mutual trust authentication, and display temporary authorization and revocation.

[0094] Implementation System: The system deployed in this embodiment includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, and a lifecycle management module. Vendor A uses the Hyperledger Fabric consortium blockchain, and Vendor B uses the FISCOBCOS consortium blockchain. The two consortium blockchains are connected via a cross-chain gateway, sharing DID document hash evidence storage. Robots C and D both have a built-in single PUF chip and an SM2 key pair. The identity authentication module supports cross-domain authentication. The lifecycle management module runs on each vendor's management platform, supporting temporary authorization and revocation.

[0095] Implementation steps:

[0096] S1-S3: RobotDID is generated based on PUF hardware fingerprint, and the DID document SM3 hash is uploaded to the respective consortium blockchain.

[0097] S4: Robot C sends a random challenge message to Robot D.

[0098] S5: Robot D uses the SM2 private key to sign within the PUF secure zone.

[0099] S6: Robot C obtains the DID document hash of Robot D from the consortium blockchain of Manufacturer B through the cross-chain gateway, verifies the consistency of on-chain evidence storage, and extracts the SM2 public key for signature verification.

[0100] S7: After successful verification, robot C considers robot D to be trustworthy.

[0101] The lifecycle management module executes temporary authorization: Robot C requests a temporary access token from Robot D, which is valid for 1 hour. Robot D generates a temporary authorization record and uploads the authorization operation log to the blockchain for auditing. After 1 hour, the token automatically expires, and Robot D proactively revokes the temporary authorization.

[0102] Implementation Results: This embodiment demonstrates that the system supports cross-trust domain and cross-consortium blockchain mutual trust authentication. By implementing mutual lookup of DID document hashes through a cross-chain gateway, combined with temporary authorization and revocation mechanisms, secure and controllable cross-domain mutual trust is achieved.

[0103] Example 4

[0104] Identity renewal and revocation.

[0105] Objective: To enable the updating and revocation of robot identity information, demonstrating full lifecycle management capabilities.

[0106] System Implementation: The system deployed in this embodiment includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, and a lifecycle management module. Each robot node has a built-in single PUF chip as the security execution module. The on-chain evidence storage module uses a consortium blockchain (PBFT consensus). The lifecycle management module runs on the management platform and is responsible for registration, updates, authorization, revocation, and operation log recording.

[0107] Implementation steps (identity update scenario):

[0108] S1: Read the hardware fingerprint feature code of the robot's built-in PUF chip.

[0109] S2: Generate a new RobotDID based on the PUF hash and construct the corresponding new DID document. The robot generates a new SM2 key pair and constructs a new DID document. The new DID document contains the new SM2 public key and adds a "previousDID" field, pointing to the old DID identifier.

[0110] S3: Calculate the SM3 hash value of the new DID document and store the hash value on the blockchain for verification. The hash of the new DID document is stored on the blockchain, and the operation log is uploaded to the blockchain for auditing, recording the update operation.

[0111] S4-S7: In subsequent authentication, the authenticator uses the "previousDID" field to trace the history of identity changes and maintain identity continuity.

[0112] Implementation steps (identity revocation scenario):

[0113] S1: Collect the PUF hardware fingerprint feature code of the robot whose license has been revoked.

[0114] S2: Instead of generating new key pairs, the lifecycle management module prepares the revocation certificate.

[0115] S3: Store the SM3 hash value of the revocation certificate on the blockchain. The revocation certificate includes the revoked RobotDID, the reason for revocation, and the revocation time.

[0116] S4: During subsequent certification, the certifier will first check whether the RobotDID has been revoked.

[0117] S5-S7: If the license has been revoked, the certifier will directly refuse access and will not perform signature verification.

[0118] Implementation Results: This example demonstrates the complete capabilities of RobotDID lifecycle management, including registration, update, authorization, revocation, and operation log auditing. On-chain evidence storage ensures that all operations are tamper-proof and traceable.

[0119] Example 5

[0120] Resource-constrained robot scenarios.

[0121] Implementation objective: To apply this system to resource-constrained IoT robot nodes and demonstrate the system's versatility and scalability.

[0122] System Implementation: The system deployed in this embodiment includes a RobotDID generation module, an on-chain evidence storage module, an identity authentication module, a security execution module, and a lifecycle management module. The robot node is a low-cost sensor robot with 8KB RAM and 64KB Flash. The security execution module uses a domestically produced lightweight security chip (such as the National Technology N32S003 series or an equivalent chip supporting SM2), with built-in PUF functionality, supporting hardware-level key storage and elliptic curve signature operations. The on-chain evidence storage module is deployed on a cloud-based proxy node; the robot itself does not directly participate in blockchain interactions. The RobotDID generation module reads the security chip via an I2C interface. The identity authentication module runs on an authentication platform. The lifecycle management module runs in the cloud.

[0123] Implementation steps:

[0124] S1: Read the PUF hardware fingerprint feature code inside the security chip (in this embodiment, the unique PUF derived identifier of the security chip is used).

[0125] S2: The RobotDID is generated based on a PUF hash, and a key pair is generated by calling the SM2 coprocessor within the security chip. The private key is generated and encapsulated by the chip's internal PUF and is never exported from the chip; the public key is read out via the I2C interface. The RobotDID generation module reads the public key and generates the RobotDID.

[0126] S3: Calculate the SM3 hash value of the DID document and store the hash value on the blockchain. The robot sends the DID document to the cloud proxy node, which calculates the hash and submits it to the consortium blockchain.

[0127] S4: The authentication direction sends a random challenge message to the target robot. The platform generates the random challenge message and sends it to the robot.

[0128] S5: The target robot uses its own private key to perform an SM2 signature on the random challenge information within a secure execution environment, generating a signature result. The robot signs the challenge information using its private key within the secure chip; the private key remains inside the secure chip and cannot be read.

[0129] S6: The authenticator obtains the DID document of the target robot from the consortium blockchain, extracts the SM2 public key from the DID document, and uses the public key to verify the legality of the signature result. The platform obtains the DID document from the consortium blockchain and extracts the public key to verify the signature.

[0130] S7: If the verification passes, the target robot is allowed to access; if the verification fails, access is denied. Access is allowed after successful verification. Implementation effect: This embodiment proves that the system can be extended to resource-constrained robot devices without requiring the robot to run a blockchain node or a complex TEE environment. The domestically produced lightweight security chip provides hardware-level key isolation, and the lightweight proxy scheme reduces terminal resource requirements and has good versatility.

[0131] Comparative Example 1

[0132] The proposed solution employs a traditional centralized digital identity authentication system, without utilizing distributed digital identity or blockchain storage. The system works as follows: robot identities are centrally managed by a server, which stores the robot's ID, public key, and permission list. During authentication, the robot sends a signature challenge response to the server, which then verifies the signature by querying its local database.

[0133] The shortcomings of this comparative example are: when the central server suffers a DDoS attack or the database is tampered with, all robot authentication fails or incorrect authentication occurs. The server becomes a single point of failure and a performance bottleneck. Cross-platform interoperability is difficult, and different vendors need to negotiate a unified central server, which is practically difficult to deploy. Compared with comparative example 1, the embodiments of this invention use decentralized DID and consortium blockchain notarization, with no single point of failure, and any node can independently verify its identity.

[0134] Comparative Example 2

[0135] Comparative Example 2 employs multi-source feature fusion using a PUF chip, temperature and humidity sensor, vibration sensor, and electromagnetic signal, without using national cryptographic algorithms. The private key is stored as a file in a regular file system. The DID document is stored directly on the blockchain.

[0136] The shortcomings of this comparison are as follows: multi-sensor fusion increases hardware costs and system complexity, making it unfriendly to low-cost consumer robots; the calibration and maintenance costs of multi-source sensors are high, and sensor failure in harsh environments can render the entire identity authentication system unusable; attackers can read private key files through operating system vulnerabilities or extract private keys through memory dumps; after the private key is leaked, attackers can impersonate the robot's identity; direct uploading of DID documents to the blockchain exposes private data; and it does not comply with national cryptographic compliance requirements.

[0137] Compared to Comparative Example 2, each embodiment of this invention uses a single PUF chip, eliminating the need for multi-sensor fusion. Preliminary estimates suggest that this significantly reduces hardware costs (approximately 40%-60%) compared to multi-sensor fusion solutions, resulting in a simpler and more reliable system. The private key is generated and encapsulated based on the PUF, stored in encrypted form in a secure storage area, and not exported externally. Only the hash digest is uploaded to the blockchain for evidence storage; the original privacy data is not stored. The entire stack employs the SM2 / SM3 / SM4 national cryptographic algorithms, meeting domestic compliance requirements. Security, cost, and compliance are all significantly superior to Comparative Example 2.

[0138] In summary, Embodiments 1 to 5 of this invention demonstrate specific implementations in five different application scenarios: trusted access for industrial robots, mutual trust and health monitoring for service robots, cross-domain mutual trust authentication, identity update and revocation, and access for resource-constrained robots. The above embodiments all adopt a decentralized distributed digital identity system, with core features including: generating an unforgeable RobotDID and corresponding DID document based on a single PUF hardware fingerprint; generating a PUF hash using SM3 hashing and incorporating it into the DID identifier; generating a key pair by calling the SM2 algorithm within the TEE or secure chip, with the private key generated and encapsulated based on PUF and stored in encrypted form in a secure storage area; storing the SM3 hash value of the DID document on the consortium blockchain (PBFT consensus), storing only the digest and not exposing the original privacy data; completing identity verification through a challenge-response mechanism, whereby the authenticator issues random challenge information, the target robot signs using the SM2 private key in a secure execution environment, and the authenticator obtains the DID document from the consortium blockchain and extracts the SM2 public key for signature verification; the lifecycle management module supports registration, update, authorization, revocation, and on-chain auditing of operation logs; the optional health monitoring module uses a random forest model to evaluate the robot's health status, only hashing the health conclusions on the blockchain; and communication encryption uses the national cryptographic algorithm SM4. The above embodiments cover various typical scenarios such as machine-to-platform authentication, machine-to-machine authentication, cross-trust domain authentication, identity change and revocation, and lightweight terminal access, demonstrating the universality and scalability of the technical solution under different hardware configurations, network environments, and consortium blockchain platforms. The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims. Finally: The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0139] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the claims.

[0140] In conclusion, the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A robot distributed digital identity authentication system based on RobotDID, characterized in that, include: The RobotDID generation module is configured to: extract a hardware fingerprint feature code from a single PUF chip built into the robot; input the hardware fingerprint feature code into an SM3 hash function to obtain a PUF hash value; assemble the PUF hash value into a distributed digital identity identifier (RobotDID) according to a format including an SM3 identifier; generate an asymmetric key pair within a secure execution environment, wherein the private key is generated based on the PUF chip and encapsulated as ciphertext, stored in a secure storage area, and the public key is written into a DID document; the DID document includes a DID identifier, an SM2 public key, device attributes, permission policies, and an expiration date. The on-chain evidence storage module is configured to: calculate the SM3 hash digest of the DID document, upload the hash digest to the consortium blockchain for storage, wherein the consortium blockchain adopts the PBFT consensus mechanism and does not store the original data of the DID document; The identity authentication module is configured to: call the secure execution module through a challenge-response mechanism to complete the identity verification between the robot and the platform or between robots; in the challenge-response mechanism, the authenticator dynamically generates non-repeating random challenge information each time, the target robot uses its private key to perform SM2 signature on the random challenge information in the secure execution environment, and the authenticator obtains the target robot's DID document from the consortium blockchain and extracts the SM2 public key for signature verification; The secure execution module is configured to store the private key and perform signature operations within the secure execution environment. The private key does not leave the secure storage area in plaintext and is reconstructed within the PUF when needed. The lifecycle management module is configured to perform registration, update, authorization, and revocation of the RobotDID, and to store the hash value of the operation log on the blockchain for evidence.

2. The robot distributed digital identity authentication system based on RobotDID as described in claim 1, characterized in that, The secure execution environment is a trusted execution environment or a national cryptographic security chip; the private key is generated by the SM2 elliptic curve cryptography algorithm, and a stable key is generated based on the fuzzy extractor of the PUF chip, which is then encapsulated into ciphertext for storage and reconstructed within the PUF when in use; the single PUF chip does not rely on temperature and humidity sensors, vibration sensors, or electromagnetic signals.

3. The robot distributed digital identity authentication system based on RobotDID as described in claim 1, characterized in that, The authentication module supports the following authentication types: direct authentication between robots, authentication between a robot and the platform, and cross-consortium chain mutual trust authentication by connecting different consortium chains through cross-chain communication; the communication encryption adopts the SM4 algorithm.

4. The robot distributed digital identity authentication system based on RobotDID as described in claim 1, characterized in that, It also includes a health monitoring module, configured as follows: The robot's following eight operating status parameters are collected at fixed intervals: CPU temperature utilization, battery voltage health, cumulative joint angle error, vibration amplitude, drive current fluctuation coefficient, communication packet loss rate, memory usage rate, and disk remaining life index. Calculate an 8-dimensional health index vector based on the eight parameters mentioned above; The health index vector is input into a pre-trained random forest model, which outputs probability vectors for three categories: normal, warning, and fault. The health conclusion is output according to the judgment rules: if the normal probability is ≥0.7, it is judged as normal; if the normal probability is <0.7 and the failure probability is <0.5, it is judged as a warning. If the probability of failure is ≥0.5, it is determined to be a failure; A health conclusion is only output when the results of three consecutive sampling cycles are consistent; otherwise, the previous conclusion is maintained. The final health conclusion and its timestamp SM3 hash value will be stored on the blockchain for evidence, while the original health index data and probability vector will not be stored on the blockchain.

5. A robot distributed digital identity authentication system based on RobotDID as described in claim 1, characterized in that, The authorization operations performed by the lifecycle management module include temporary authorization, setting a validity period, and automatic expiration upon expiration; the revocation operation includes active revocation, and the revocation certificate contains the revoked RobotDID, the reason for revocation, and the revocation time, and the hash value of the revocation certificate is stored on the blockchain; during authentication, it is first checked whether the RobotDID has been revoked.

6. A method for implementing robot distributed digital identity authentication based on RobotDID, applied to the robot distributed digital identity authentication system based on RobotDID as described in any one of claims 1-5, characterized in that, Includes the following steps: S1: Extract hardware fingerprint feature code from the robot's built-in single PUF chip; S2: Input the hardware fingerprint feature code into the SM3 hash function to obtain the PUF hash value, and assemble it into a RobotDID according to the format containing the SM3 identifier; generate an asymmetric key pair in the secure execution environment, generate a stable key based on the fuzzy extractor of the PUF chip, encapsulate the private key into ciphertext through PUF and store it in a secure storage area, and write the public key into the DID document; the DID document contains the DID identifier, SM2 public key, device attributes, permission policy and validity period; S3: Calculate the SM3 hash digest of the DID document, and upload the hash digest to the consortium blockchain for storage. The consortium blockchain adopts the PBFT consensus mechanism. S4: The certifier dynamically generates unique random challenge information and sends it to the target robot; S5: The target robot uses its own private key to perform SM2 signature on the random challenge information within the secure execution environment to obtain a signature result. The private key does not leave the secure storage area in plaintext. S6: The authenticator obtains the DID document of the target robot from the consortium blockchain, extracts the SM2 public key from the DID document, and uses the public key to verify the signature result; S7: If the verification is successful, the target robot is allowed to access; if the verification fails, access is denied.

7. The robot distributed digital identity authentication method based on RobotDID as described in claim 6, characterized in that, The secure execution environment is a trusted execution environment or a national cryptographic security chip; the private key is generated based on the PUF chip and encapsulated as ciphertext and stored in a secure storage area, and is not exported from the secure execution environment or transmitted in plaintext; the signature operation is performed within the secure execution environment.

8. The robot distributed digital identity authentication method based on RobotDID as described in claim 6, characterized in that, The authentication process includes: direct authentication between robots, authentication between robots and the platform, and cross-consortium chain mutual trust authentication by connecting different consortium chains through cross-chain communication. The method also includes RobotDID lifecycle management steps: generating a new DID document with a field pointing to the old DID when updating identity information, generating a new DID document when changing permissions, setting an expiration period when granting temporary authorization, generating a revocation certificate and hashing the revocation certificate on the chain when voluntarily revoking, and storing the hash values ​​of all operation logs on the chain.

9. The robot distributed digital identity authentication method based on RobotDID as described in claim 6, characterized in that, It also includes health monitoring steps: The robot's following eight operating status parameters are collected at fixed intervals: CPU temperature utilization, battery voltage health, cumulative joint angle error, vibration amplitude, drive current fluctuation coefficient, communication packet loss rate, memory usage rate, and disk remaining life index. Calculate an 8-dimensional health index vector based on the eight parameters mentioned above; The health index vector is input into a pre-trained random forest model, which outputs probability vectors for three categories: normal, warning, and fault. The following judgment rules are used to output a health conclusion: if the normal probability is ≥0.7, it is judged as normal; if the normal probability is <0.7 and the failure probability is <0.5, it is judged as a warning. If the probability of failure is ≥0.5, it is determined to be a failure; A health conclusion is only output when the results of three consecutive sampling cycles are consistent; otherwise, the previous conclusion is maintained. The final health conclusion and its timestamp SM3 hash value are stored on the blockchain for evidence, while the original health index data and probability vector are not stored on the blockchain. The SM4 algorithm is used for communication encryption.

10. The robot distributed digital identity authentication method based on RobotDID as described in claim 6, characterized in that, After the hash value of the DID document is stored on the blockchain, the authenticator can query the hash value from the consortium blockchain to verify the integrity of the DID document. The consortium blockchain adopts the PBFT consensus mechanism and is jointly maintained by multiple consensus nodes. The method is suitable for resource-constrained robots, which do not directly participate in blockchain interaction but complete the on-chain operation through cloud proxy nodes.

Images