Robot safety communication method and device and storage medium

Abstract

The invention discloses a robot safety communication method and device and a storage medium. The method comprises the following steps: acquiring an equipment identity credential from a hardware security environment of a robot, and establishing a security channel with a cloud service based on the equipment identity credential; obtaining an access token with a validity period from the cloud service through the secure channel; under the condition that the secure channel receives the control instruction from the cloud service, the control instruction is set in a temporary storage state; an execution authorization request for the control instruction is initiated to the cloud service, and the execution authorization request carries the access token; receiving a response to the execution authorization request from the cloud service; and under the condition that the response is authorization, the control instruction in the temporary storage state is sent to an execution mechanism of the robot to be executed.

Description

Robot safe communication methods, devices and storage media Technical Field

[0001] This application relates to the field of robot safety communication technology, specifically to a robot safety communication method, device, and storage medium. Background Technology

[0002] Secure communication for robots is fundamental to achieving trusted and controllable human-robot collaboration and embodied intelligence applications. Currently, secure communication between robot systems and cloud services generally relies on encrypted links based on the Transport Layer Security (TLS) protocol, combined with long-term pre-installed identity credentials for authentication. Specifically, before the robot equipment leaves the factory, the equipment manufacturer or system integrator pre-installs and embeds long-term valid digital certificates or Application Programming Interface (API) keys into the device's file system or security chip. After the device starts up, it uses this long-term credential to complete a TLS handshake with the cloud authentication server, establishing an encrypted communication channel. Subsequently, control commands (such as motion trajectories and task instructions) issued by the cloud service are transmitted to the robot through this channel. The robot system typically parses the received commands directly and then passes them to the underlying actuators for execution.

[0003] However, this long-term credential-based communication security architecture faces several inherent flaws in practical deployments: If a long-term pre-installed key or certificate is leaked during device logistics, deployment, or maintenance due to physical disassembly or firmware extraction, attackers can use this long-term valid credential to continuously impersonate legitimate devices, posing a persistent security threat. Simultaneously, the security boundary of existing solutions stops at the establishment of the communication link; the cloud lacks fine-grained control over subsequent command flows, making it impossible to verify whether each command is still authorized before execution, hindering defense against command replay attacks, and preventing devices from executing commands received and cached before the credential expires, thus bypassing the timeliness of access control. Furthermore, this architecture is ill-suited for large-scale dynamic deployment and maintenance needs. In scenarios involving tens or even hundreds of thousands of robots, the rotation and revocation management of long-term certificates or static keys is complex, making it difficult to respond promptly to dynamic security events such as device theft and firmware tampering, resulting in high system scalability and security maintenance costs.

[0004] Therefore, designing a robot secure communication method that can achieve plug-and-play functionality with zero long-term key storage, while also performing runtime authorization verification for each control command, thereby ensuring high real-time communication while fundamentally resisting the risks of physical leakage, replay attacks, and security policy bypass, has become a key technical problem that urgently needs to be solved to promote the large-scale reliable application of robot technology. Summary of the Invention

[0005] The purpose of this application is to provide a secure communication method, device, and storage medium for robots, in order to solve the technical problems in the prior art where robot devices are easily physically leaked due to long-term storage of fixed keys, leading to identity impersonation; the inability to perform fine-grained real-time authorization and replay attack defense for control commands after the communication link is established; and the complex and slow response of security credential management in large-scale dynamic deployment scenarios.

[0006] To achieve the above objectives, the first aspect of this application provides a robot secure communication method, comprising: obtaining device identity credentials from the robot's hardware security environment; establishing a secure channel with a cloud service based on the device identity credentials; obtaining an access token with a validity period from the cloud service through the secure channel; placing the control command in a temporary state when a control command is received from the cloud service through the secure channel; initiating an execution authorization request for the control command to the cloud service, wherein the execution authorization request carries the access token; receiving a response from the cloud service to the execution authorization request; and, if the response is authorized, sending the temporarily stored control command to the robot's actuator for execution.

[0007] In this embodiment of the application, obtaining device identity credentials from the robot's hardware security environment includes: obtaining the private key of an asymmetric key pair from the hardware security environment as the device identity credentials; wherein, the private key is dynamically generated based on the key seed preset in the hardware security environment at the time of manufacture, and the corresponding public key is stored in the robot's insecure storage area.

[0008] In this embodiment of the application, establishing a secure channel based on device identity credentials and cloud services includes: using device identity credentials to sign challenge information containing a first random number; sending the signature and challenge information to the cloud service for verification by the cloud service based on a pre-stored device public key; and, if the verification is successful, establishing an encrypted secure channel based on a session key negotiated with the cloud service.

[0009] In this embodiment of the application, obtaining an access token with an expiration date from a cloud service includes: sending a token request to the cloud service, wherein the token request includes a signature of a second random number and a device integrity metric value using device identity credentials; receiving a token response returned by the cloud service in response to the token request; wherein the token response includes at least an access token with a short validity period and a one-time symmetric session key generated by the cloud service.

[0010] In this embodiment of the application, receiving a control command from a cloud service via a secure channel includes: receiving a control command data frame encrypted with a one-time symmetric session key sent through the secure channel; and decrypting the control command data frame using a one-time symmetric session key shared with the cloud service to obtain the control command.

[0011] In this embodiment of the application, initiating an execution authorization request for a control command to a cloud service includes: generating an execution authorization request for a control command in a temporary state, wherein the execution authorization request carries at least a currently valid access token and characteristic information of the control command; and sending the execution authorization request to the cloud service so that the cloud service can make an authorization determination based on the validity of the access token and the legality of the control command.

[0012] In this application example, the method further includes: monitoring the remaining validity period of the access token; when the remaining validity period is lower than a preset threshold, reusing the secure channel established between the device identity credentials and the cloud service to initiate a token refresh request to the cloud service, wherein the token refresh request includes a signature generated using the device identity credentials for the new challenge information; and receiving a new access token issued by the cloud service.

[0013] In this embodiment of the application, the method further includes: receiving a token revocation instruction or a security lock instruction from a cloud service; in response to the instruction, clearing all control instructions in a temporary state and preventing the execution of subsequent control instructions.

[0014] A second aspect of this application provides a robot safety communication device, comprising: a memory configured to store instructions; a processor configured to retrieve instructions from the memory and, when executing the instructions, to implement the robot safety communication method described above.

[0015] A third aspect of this application provides a computer-readable storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, it implements the robot safe communication method described above.

[0016] The technical solution of this application dynamically obtains device identity credentials from the robot's hardware security environment and uses them to establish a secure channel with cloud services, thereby obtaining a short-term valid access token. After receiving control commands, the token is temporarily stored, and a command execution authorization request carrying the token is sent to the cloud. Only after receiving a real-time authorization response from the cloud is the command sent to the execution mechanism for execution. This method transforms the trust foundation and execution control of robot secure communication from traditional, static, pre-set, and easily leaked long-term credentials and "one-time" link-level authentication to dynamic, hardware-based short-term authentication and real-time fine-grained command-level authorization. This forms a robot secure communication method based on dynamic credentials and runtime verification, which can fundamentally reduce the risk of physical leakage, defend against replay attacks, and ensure the strict timeliness of access control policies, thereby significantly improving the security, controllability, and manageability of the robot system throughout its deployment, maintenance, and operation lifecycle. Other features and advantages of the embodiments of this application will be described in detail in the following detailed implementation section. Attached Figure Description

[0017] The accompanying drawings are provided to further illustrate the embodiments of this application and constitute a part of the specification. They are used together with the following detailed description to explain the embodiments of this application, but do not constitute a limitation on the embodiments of this application. In the drawings: Figure 1 schematically shows a flowchart of a robot safety communication method according to an embodiment of this application; Figure 2 schematically shows a system structure block diagram of a robot safety communication method according to an embodiment of this application; Figure 3 schematically shows a flowchart of a robot safety communication method according to another embodiment of this application; Figure 4 schematically shows an internal structure diagram of a computer device according to an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are only for illustration and explanation of the embodiments of this application and are not intended to limit the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0019] It should be noted that the acquisition, transmission, storage, use, and processing of data in the technical solution of this application all comply with relevant laws and regulations. In the embodiments of this application, certain existing industry solutions such as software, components, and models may be mentioned. These should be considered exemplary, intended only to illustrate the feasibility of implementing the technical solution of this application, and do not imply that the applicant has already used or necessarily used such solutions.

[0020] Furthermore, if the embodiments of this application involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, features defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the technical solutions of various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. If the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.

[0021] Figure 1 schematically illustrates a flowchart of a robot secure communication method according to an embodiment of this application. As shown in Figure 1, the steps include: Step 101, obtaining device identity credentials from the robot's hardware security environment, and establishing a secure channel with a cloud service based on the device identity credentials.

[0022] In one embodiment, obtaining device identity credentials from the robot's hardware security environment includes: the robot obtaining the private key of an asymmetric key pair from the hardware security environment as the device identity credential; wherein the private key is dynamically generated based on a key seed pre-installed in the hardware security environment at the factory, and the corresponding public key is stored in the robot's insecure storage area. The hardware security environment refers to a secure computing area provided inside the robot, possessing physical or logical isolation characteristics, used to protect sensitive data (such as keys) and perform business operations. An asymmetric key pair refers to a pair of mathematically related keys, including a private key and a public key. The private key is used for signing or decryption and must be strictly kept confidential; the public key can be used to verify signatures or encryption and can be publicly distributed. The key seed refers to a secret value pre-injected into the hardware security environment, serving as the source for generating or deriving the actual encryption / decryption keys.

[0023] In this embodiment, establishing a secure channel based on device identity credentials and a cloud service includes: the robot using its device identity credentials to sign challenge information containing a first random number; sending the signature and challenge information to the cloud service for verification based on a pre-stored device public key; and, if verification is successful, establishing an encrypted secure channel based on a session key negotiated with the cloud service. The session key is a temporary symmetric encryption key jointly generated by both communicating parties through a key negotiation protocol after successful authentication. This key is used only for the current communication session and is discarded after the session ends, achieving forward secrecy. The secure channel refers to a communication path established based on the aforementioned session key, which encrypts the transmitted data. The first random number is a cryptographically secure random number generated locally by the robot during the initial authentication and secure channel establishment phase; this random number is included as a challenge value in the challenge information.

[0024] In one embodiment, upon startup, the robot first invokes its hardware security environment, such as a trusted execution environment, trusted platform module, or embedded secure element's application programming interface (API), to read from this security environment or generate a pair of asymmetric encryption keys in real time based on a factory-preset key seed. The private key serves as the device's identity credential and remains within the hardware security environment throughout the process; the corresponding public key, extracted during the device's factory manufacturing or initial configuration, is stored in the robot's non-volatile memory (such as a file system), which is considered an insecure storage area. To establish a secure channel, the robot generates a cryptographically secure random number as a challenge value and constructs challenge information containing this random number and optional device state information. Next, the robot digitally signs the challenge information using its private key. This process leverages the characteristics of asymmetric encryption algorithms to ensure that only devices holding the corresponding private key can generate a valid signature that can be verified by the public key. The robot sends the signature, random number, and related information to a cloud authentication endpoint via a standard network protocol. Upon receiving the request, the cloud service retrieves the pre-stored device public key based on the device identifier and uses this public key to verify the validity of the signature, while also checking the random number to prevent replay attacks. After successful verification, both parties execute a key negotiation protocol, generating identical session keys based on the negotiation results. Ultimately, an encrypted and forward-secret secure channel is established based on this session key. Forward secrecy means that even if the private key is leaked in the future, the communication content protected by the previously negotiated session key cannot be decrypted. Thus, both parties have successfully established a secure channel with two-way authentication, encryption, and forward secrecy, laying the foundation for subsequent secure communication.

[0025] Step 102: Obtain an access token with an expiration date from the cloud service via a secure channel.

[0026] In one embodiment, the robot obtains an access token with an expiration period from a cloud service, including: sending a token request to the cloud service, wherein the token request includes a signature of a second random number and a device integrity metric using device identity credentials; and receiving a token response returned by the cloud service in response to the token request; wherein the token response includes at least an access token with a short validity period and a one-time symmetric session key generated by the cloud service. The second random number refers to another cryptographically secure random number generated locally by the robot during the access token acquisition phase. This random number is included in the token request and is signed. In this embodiment, receiving control instructions from the cloud service via a secure channel includes: receiving a control instruction data frame encrypted using a one-time symmetric session key and transmitted through the secure channel; and decrypting the control instruction data frame using a one-time symmetric session key shared with the cloud service to obtain the control instructions.

[0027] In one embodiment, after establishing a secure channel, the robot sends a token request to the cloud service. This request includes a digital signature of a second random number and a device integrity metric, using the device identity credentials (i.e., the private key protected in the hardware security environment). The device integrity metric may include the cryptographic hash of the currently running firmware, the counter value of the trusted platform module, etc., used to prove to the cloud that its software state has not been tampered with and that the operating environment is trustworthy. Upon receiving the token request, the cloud service verifies the validity of the signature using a pre-stored device public key and checks whether the device integrity metric meets expectations. After successful verification, the cloud service dynamically generates an access token with a short validity period and a one-time symmetric session key. The cloud encapsulates the access token and the one-time symmetric session key in a token response and returns it to the robot through the established secure channel. The robot receives and stores the access token and the one-time symmetric session key. The robot receives control command data frames encrypted using the one-time symmetric session key sent through the secure channel; subsequently, it decrypts the data frame using the corresponding locally stored one-time symmetric session key to obtain the plaintext control commands.

[0028] Step 103: When a control command is received from a cloud service on the secure channel, the control command is placed in a temporary state.

[0029] In one embodiment, after receiving control commands from the cloud service through an established secure channel, the robot does not immediately parse and send them to the underlying actuators. Instead, it first initiates a secure command storage mechanism. The core of this mechanism is to temporarily store the received raw control commands, such as low-frequency trajectory key points or task command packages, in a managed command cache. This cache is typically located within the robot's random access memory, and its access permissions and lifecycle are controlled by the system's security module.

[0030] Simultaneously, the robot's motion control module can perform necessary preprocessing on the temporarily stored raw instructions. For example, if the raw instruction is a trajectory point issued at a frequency of 1 Hz, the module will, based on the robot's motion dynamics model and control cycle requirements, use an interpolation algorithm to convert it in real time into a smooth control instruction sequence at a frequency of 100 Hz or higher. Crucially, all high-frequency instruction sequences generated at this stage are strictly confined to the instruction buffer, remaining in a "prepared but not executed" temporary state, and are not written to the CAN bus (Controller Area Network), EtherCAT bus (Ethernet Automation Technology), or other actuator interfaces. This step introduces a controllable delay and check window before the actual physical execution of the instructions, providing the necessary technical prerequisite for implementing instruction-level runtime authorization verification.

[0031] Step 104: Initiate an execution authorization request for the control command to the cloud service, wherein the execution authorization request carries an access token.

[0032] In one embodiment, the robot initiates an execution authorization request for a control command to a cloud service, including: generating an execution authorization request for a control command in a temporary state, wherein the execution authorization request carries at least a currently valid access token and characteristic information of the control command; and sending the execution authorization request to the cloud service so that the cloud service can make an authorization determination based on the validity of the access token and the legality of the control command.

[0033] In one embodiment, after receiving control commands from the cloud, the robot's motion control module does not execute them immediately but first stores them in a command buffer. Next, the module performs necessary preprocessing on the buffered control commands, such as interpolating low-frequency trajectory points into a high-frequency execution command sequence. After this, the robot constructs an execution authorization request, which carries at least a currently valid access token and characteristic information of the interpolated high-frequency control command sequence, such as the hash value or digest of the command sequence, and sends it to a specific authorization endpoint of the cloud service via a secure channel. Upon receiving the authorization request, the cloud service first verifies the validity and permissions of the carried access token and analyzes the legality and rationality of the command characteristic information. Only when both verification and analysis pass does the cloud return a successful authorization response to the robot; otherwise, it returns an authorization failure response and may trigger a security alarm.

[0034] Step 105: Receive the response from the cloud service to the execution authorization request.

[0035] Step 106: If the response is authorized, send the control commands that are in a temporary state to the robot's actuators for execution.

[0036] In one embodiment, after sending an execution authorization request to the cloud service, the robot continuously listens for and receives authorization responses from the cloud. This response is essentially an authorization decision instruction securely signed by the cloud. When the received response is parsed and confirmed as "authorized," the system security module immediately performs the following atomic operations: (1) Confirming that the authorization response strictly corresponds to the currently stored, pending sequence of control instructions. This is typically achieved by matching the transaction identifier or instruction feature hash value in the request and response to ensure that the correct batch of instructions is authorized.

[0037] (2) Change the status of the corresponding instruction cache from "pending review" to "authorized to execute".

[0038] (3) The safety module releases the authorized high-frequency control command sequence from the command buffer and writes it to the robot's underlying control bus, such as CAN bus, EtherCAT bus, or specific servo driver interface, through the corresponding device driver interface according to the timing requirements. This "writing" action triggers the actuator to start actually executing the control command sequence.

[0039] This mechanism ensures that any control command, from receipt to final physical execution, must be authorized in real-time and positively through the cloud. Even if the device has successfully established a secure channel and holds a valid access token, if the cloud responds to an authorization request for a particular command or batch of commands with a denial or timeout, the corresponding command will be permanently discarded in the cache and will never be sent to the execution mechanism. This fundamentally eliminates security vulnerabilities caused by cached commands still being executed after the token expires or by commands being executed again in the event of a replay attack, achieving eventual consistency of access control policies at the command execution level.

[0040] In one embodiment, the method further includes: monitoring the remaining validity period of the access token; when the remaining validity period is lower than a preset threshold, the robot reuses the secure channel established based on the device identity credentials and the cloud service to initiate a token refresh request to the cloud service, wherein the token refresh request includes a signature generated using the device identity credentials for the new challenge information; and receiving a new access token issued by the cloud service.

[0041] In one embodiment, the robot continuously monitors the remaining validity period of the currently used access token. When the remaining validity period is detected to be lower than a preset threshold, the robot reuses the same secure channel previously established with the cloud service based on the device's identity credentials to initiate a token refresh request to the cloud service's token management endpoint. This refresh request must include a digital signature generated using the private key in the device's hardware security environment against the new challenge information. After verifying the signature validity and device identity, the cloud service issues a new short-term access token and sends it to the robot through the secure channel. The robot receives and replaces the old token, thus achieving secure and seamless renewal of access credentials without relying on long-term stored refresh tokens.

[0042] In one embodiment, the method further includes: the robot receiving a token revocation instruction or a security lock instruction from a cloud service; in response to the instruction, clearing all control instructions in a temporary state and preventing the execution of subsequent control instructions.

[0043] In one embodiment, to address security incidents such as device theft, credential leakage, or detected abnormal behavior, the cloud service can proactively issue token revocation or global security lock commands to a specific robot. Upon receiving the command through a secure channel or designated control channel, the robot immediately triggers a local security handling process: first, it forcibly clears all temporarily stored control commands in the command buffer, regardless of their authorization status; then, it locks the command processing pipeline, preventing any new control commands from entering the execution process, whether from the current channel or other means, and places the system in a controlled secure standby state. This mechanism ensures that when the cloud detects a security threat, it can immediately and effectively interrupt control of the robot, preventing the harm from escalating and achieving rapid security linkage response from the cloud to the device.

[0044] This application transforms the traditional secure communication mode based on long-term static keys and one-time link authentication into a dynamic credential management and command-level real-time authorization mechanism based on hardware roots of trust. This fundamentally solves the problems of identity spoofing due to physical device leakage, inability to defend against replay attacks due to lack of runtime control, and uncontrolled command execution timeliness due to security policy bypassing. It also eliminates the inherent contradiction in traditional solutions where "communication security relies on fixed keys, and authorization and execution are separated in time and space." The system coordinates the execution of control commands based on short-cycle access tokens and real-time cloud authorization responses, achieving an end-to-end dynamic security closed loop from authentication to execution. This ensures that the execution of each control command undergoes real-time authorization verification in the cloud, guaranteeing strict consistency of access control policies in the final execution stage. Simultaneously, by integrating hardware security environment, forward confidentiality channels, and command sandbox execution path constraint mechanisms, it can build a defense-in-depth system at three levels: device, communication link, and execution node. This significantly reduces the complexity of security management and the risk of credential leakage in large-scale deployment and operation environments, providing systematic support for achieving highly secure, highly controllable, and scalable robot cloud-edge collaboration and remote operation.

[0045] Figure 2 schematically illustrates the system architecture of a robot secure communication method according to an embodiment of this application. As shown in Figure 2, the system is built around the secure communication and command execution of a robot terminal (RCP-Agent). The core includes four components: RCP-Agent, RCP-Gateway (gateway service), RobotMotion (control service), and Resource-API (resource interface). Trusted interaction is achieved through a multi-layered security mechanism: First, the RCP-Agent needs to complete pre-verification of cross-domain authentication metadata (such as company credentials) to obtain communication access privileges; then, the RCP-Agent establishes a secure connection with the RCP-Gateway via the mTLS1 encryption protocol, and the RCP-Gateway distributes a dynamic token to it; when RobotMotion (responsible for executing robot CRUD commands) initiates a request to Resource-API, it must carry the aforementioned token, and Resource-API verifies the token's validity through the JWT Introspect mechanism; after successful verification, Resource-API opens its interface capabilities to RobotMotion, and finally, RobotMotion executes the robot commands.

[0046] Figure 3 schematically illustrates a flowchart of a robot secure communication method according to another embodiment of this application. As shown in Figure 3: After a cold start, the device reads its proprietary asymmetric encryption private key (such as an ed25519 algorithm private key) and necessary authentication metadata from the Trusted Execution Environment (TPM). Based on this metadata, a secure communication channel is established between the device and the cloud service via a two-way authenticated transport layer security protocol. This channel not only performs two-way certificate verification but also has forward secrecy features, ensuring that even if the long-term private key is leaked in the future, historical communication content cannot be decrypted. The robot sends an identity request to the cloud through the established mTLS channel. This request includes a random number, the current value of the Trusted Platform Module (TPM) counter, and the cryptographic hash value of the device firmware, and digitally signs all of the above information using the private key. The cloud verifies the signature validity, checks the device identity, verifies whether the firmware hash has been tampered with, and confirms that the TPM counter value is normal, then dynamically issues a short-term valid access token and a one-time symmetric session key. The access token uses the JSONWeb Token format with a validity period of 10 minutes; the session key uses the AES-256-GCM algorithm for efficient encrypted transmission of subsequent high-frequency command data. Upon receiving the original control commands, the robot's motion control module first performs necessary preprocessing. For example, low-frequency command sequences are converted into high-frequency smooth control sequences using an interpolation algorithm. Crucially, all processed commands are temporarily stored in the device's random access memory (RAM), in a secure sandbox state of "ready but not yet executed," during which time no commands are sent to any execution bus. To ensure access continuity, the system proactively initiates a refresh process before the old access token expires. This process reuses the initially established mTLS secure channel and uses the device's private key to sign the new challenge information, requesting a new access token from the cloud. This mechanism eliminates the need for long-term stored refresh tokens, simplifying key management and supporting large-scale device concurrency. Before the command actually drives the physical actuator, the system must initiate an instruction introspection request to the cloud. This request carries the currently valid access token and the characteristic information of the command to be executed. After the cloud verifies the token's validity and authorizes it, the device writes the corresponding instruction sequence, temporarily stored in the security sandbox, to the underlying control bus, such as CAN or EtherCAT, for execution. The cloud maintains a certificate revocation list. If a device's access token is added to this list (e.g., due to device theft), the cloud will refuse authorization when the device subsequently initiates an introspection request. Upon detecting authorization failure or receiving a revocation instruction from the cloud, the device's security sandbox mechanism immediately locks the instruction processing pipeline and clears all temporarily stored instruction traces, thereby achieving rapid security isolation and response from the cloud to the device.

[0047] This application also provides a robot safety communication device, the device comprising: a memory configured to store instructions; a processor configured to retrieve instructions from the memory and, when executing the instructions, to implement any of the above-described robot safety communication methods.

[0048] This application also provides a machine-readable storage medium storing instructions that cause a machine to execute the above-described robot safety communication method.

[0049] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram is shown in Figure 4. The computer device includes a processor A01, a network interface A02, a memory (not shown in the figure), and a database (not shown in the figure) connected via a system bus. The processor A01 provides computing and control capabilities. The memory includes internal memory A03 and a non-volatile storage medium A04. The non-volatile storage medium A04 stores an operating system B01, a computer program B02, and a database (not shown in the figure). The internal memory A03 provides an environment for the operation of the operating system B01 and the computer program B02 in the non-volatile storage medium A04. The database of the computer device stores structured data related to robot safety communication and authorization. The network interface A02 of the computer device is used for communication with external terminals via a network connection. When the computer program B02 is executed by the processor A01, it implements a robot safety communication method.

[0050] Those skilled in the art will understand that the structure shown in Figure 4 is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or may combine certain components, or may have different component arrangements.

[0051] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0052] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0053] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0054] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0055] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0056] Memory may include non-persistent memory in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0057] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0058] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0059] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A robot safe communication method, characterized in that, The method includes: obtaining device identity credentials from the robot's hardware security environment; establishing a secure channel with a cloud service based on the device identity credentials; obtaining an access token with a validity period from the cloud service through the secure channel; placing the control command in a temporary state when a control command is received from the cloud service through the secure channel; initiating an execution authorization request for the control command to the cloud service, wherein the execution authorization request carries the access token; receiving a response from the cloud service to the execution authorization request; and sending the control command in the temporary state to the robot's actuator for execution when the response is authorized.

2. The robot safe communication method according to claim 1, characterized in that, The step of obtaining device identity credentials from the hardware security environment of the robot includes: obtaining the private key of an asymmetric key pair from the hardware security environment as the device identity credentials; wherein the private key is dynamically generated based on the key seed preset in the hardware security environment at the time of manufacture, and the corresponding public key is stored in the insecure storage area of ​​the robot.

3. The robot safe communication method according to claim 1, characterized in that, The step of establishing a secure channel with the cloud service based on the device identity credentials includes: using the device identity credentials to sign challenge information containing a first random number; sending the signature and the challenge information to the cloud service for verification based on a pre-stored device public key; and, if the verification is successful, establishing an encrypted secure channel based on a session key negotiated with the cloud service.

4. The robot safe communication method according to claim 1, characterized in that, Obtaining an access token with a validity period from the cloud service includes: sending a token request to the cloud service, wherein the token request includes a signature of a second random number and a device integrity metric using the device identity credentials; receiving a token response returned by the cloud service in response to the token request; wherein the token response includes at least an access token with a short validity period and a one-time symmetric session key generated by the cloud service.

5. The robot safe communication method according to claim 1 or 4, characterized in that, Receiving a control command from the cloud service via the secure channel includes: receiving a control command data frame encrypted with a one-time symmetric session key sent through the secure channel; and decrypting the control command data frame using the one-time symmetric session key shared with the cloud service to obtain the control command.

6. The robot safe communication method according to claim 1, characterized in that, The step of initiating an execution authorization request for the control command to the cloud service includes: generating an execution authorization request for the control command in the temporary state, wherein the execution authorization request carries at least the currently valid access token and the characteristic information of the control command; and sending the execution authorization request to the cloud service so that the cloud service can make an authorization determination based on the validity of the access token and the legality of the control command.

7. The robot safe communication method according to claim 1, characterized in that, The method further includes: monitoring the remaining validity period of the access token; when the remaining validity period is lower than a preset threshold, reusing the secure channel established between the device identity credentials and the cloud service to initiate a token refresh request to the cloud service, wherein the token refresh request includes a signature generated using the device identity credentials for new challenge information; and receiving a new access token issued by the cloud service.

8. The robot safe communication method according to claim 1, characterized in that, The method further includes: receiving a token revocation instruction or a security lock instruction from the cloud service; in response to the instruction, clearing all control instructions in the temporary state and preventing the execution of subsequent control instructions.

9. A robot safety communication device, characterized in that, The device includes: a memory configured to store instructions; and a processor configured to retrieve the instructions from the memory and, when executing the instructions, to implement the robot safe communication method according to any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the robot safe communication method as described in any one of claims 1 to 8.

Images