A multi-agent intercommunication security method, system and device
Patent Information
- Application Number
- CN202611291137.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-08-25
- Publication Date
- 2026-10-27
AI Technical Summary
(1)本多智能体间安全交互方法通过端侧智能体、KDC、控制中心三方协作的六步流程(认证请求、KDC验证分发、票据转发、业务加密发送、票据解密验证、业务解密执行),构建了一个闭环的安全交互链路。该方法实现了端侧智能体的强身份认证(基于长期密钥和SM3)、动态会话密钥的安全分发(由可信KDC生成)、以及后续所有业务通信的端到端加密(SM4)与完整性保护(SM3)。有效解决了智能体身份易伪造、通信明文传输、密钥管理困难等问题。
Smart Images

Figure CN122993933A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the fields of artificial intelligence and network security technology, and in particular to a secure identity authentication and encrypted communication method, system and device applicable to multi-agent collaborative scenarios such as robots and smart terminals. Background Technology
[0002] In recent years, with the continuous improvement of the intelligence level of robots and IoT devices, and the large-scale deployment of 5G / 6G communication technologies, multi-agent collaborative operations have become an important application paradigm in fields such as industrial automation, smart logistics, and smart cities. Interactions between agents are no longer limited to simple instruction transmission, but involve the exchange of complex business logic, sensitive data (such as user identity, location information, and operational instructions), and critical control commands. Therefore, ensuring the trustworthiness of identities and the confidentiality and integrity of communications between agents has become crucial.
[0003] However, existing intelligent agents suffer from security vulnerabilities (including robot identity verification, plaintext transmission of information, and lack of encryption), lacking strong encryption measures. Furthermore, the channels through which information is transmitted between agents also have relatively low security. As multi-agent systems gradually enter people's daily lives and profoundly impact their work, the demand for high-level security guarantees for multi-agent systems and their constituent systems becomes increasingly prominent and urgent.
[0004] The existing technical solutions mainly have the following technical problems: (1) Intelligent agent identity ID confirmation: The lack of a CA-certified USB encryption key, also known as a USBKey, determines unique identity information; encryption algorithms such as SM3 / SM4 / SHA3 determine identity information, etc.
[0005] (2) Lack of authentication protocol: For example, the Kerberos protocol can be used, which is a network identity authentication protocol that provides secure authentication services, especially in insecure network environments.
[0006] (3) Encrypted tunnel: lack of encrypted information transmission, such as IPSec encrypted transmission, to ensure that information is not stolen or tampered with.
[0007] In existing technologies, some research has focused on authentication and key negotiation in specific scenarios. For example, patent CN122420824A, entitled "A V2V Two-Way Authentication and Session Key Negotiation Method with Conditional Privacy Protection Based on ECC," focuses on vehicle-to-vehicle (V2V) communication scenarios, using elliptic curve cryptography (ECC) to achieve two-way authentication and key negotiation. However, this scheme has high computational complexity and is specifically designed for V2V scenarios, making it difficult to directly apply to resource-constrained, broad-based multi-agent interaction environments. Another example is patent CN122309032A, entitled "An End-Side Intelligent Agent Autonomous Execution and State Management Method Based on Standardized Protocols," which focuses on the autonomous execution and state management of intelligent agents. While it involves standardized interaction, it does not deeply address the issues of secure authentication and the dynamic and secure distribution of session keys.
[0008] Therefore, existing technologies lack a lightweight, high-security unified secure interaction scheme that is suitable for large-scale, distributed multi-agent architectures, making it difficult to ensure machine-to-machine communication security while also taking into account efficiency and ease of deployment. Summary of the Invention
[0009] This invention aims to address the shortcomings of the prior art by providing a secure interaction method, system, and device for multiple agents. By introducing a trusted key distribution center (KDC) and combining commercial cryptographic algorithms and optimized authentication protocols, a "always-verified, never-trusted" security defense system is built between the edge agents and the control center, integrating identity verification, real-time early warning, and proactive defense. This system achieves strong identity authentication, secure negotiation of session keys, end-to-end encryption of communication, and integrity protection, thereby improving the ability to resist replay attacks and network attacks.
[0010] To achieve the above technical solution, the present invention provides a method for secure interaction among multiple agents, specifically including the following steps: S1. The edge agent issues a service request: After starting up, the edge agent assembles an authentication request containing its own identifier, target service identifier, timestamp, and one-time random number. It calculates the SM3 message authentication code using its local long-term key and sends the request and verification code to the KDC. After successful authentication, the edge agent receives the session key, the uncrackable encrypted ticket from the control center, and the corresponding initialization vector issued by the KDC. It then forwards the ticket and vector to the control center. In subsequent service interactions, the edge agent uses the session key to encrypt the service data using SM4 and generates an SM3 integrity verification code. It then sends the ticket, encrypted service data, and verification code to the control center to conduct secure service communication. S2, KDC Authentication and Key Distribution: The KDC receives the authentication request from the client-side agent, parses the client-side agent's own identifier, target service identifier, timestamp, random number, and SM3 checksum, retrieves the client-side agent's corresponding long-term key to recalculate the checksum and complete the identity verification. At the same time, it verifies the timestamp, uses random number buffering to resist replay attacks, and generates a short-term session key between the client-side agent and the control center after verification. It encapsulates the ticket plaintext and encrypts it with the control center's long-term key using SM4 to generate the corresponding initialization vector. Finally, it sends the session key, encrypted ticket, and initialization vector back to the client-side agent to complete authentication and key distribution. S3. Control Center Authentication and Execution: The control center receives tickets or encrypted service requests with tickets forwarded by the end-side intelligent agent, decrypts the tickets using its own long-term key, verifies that the tickets were issued by the KDC, extracts the end-side intelligent agent's own identifier, session key, and ticket validity period after decryption, and verifies the validity of the tickets; for the service request, it uses the session key to recalculate the SM3 checksum to complete the integrity verification, and after the verification is passed, it uses the session key SM4 to decrypt the service data to obtain the plaintext, and finally executes the service logic to complete the trusted access process of the end-side intelligent agent.
[0011] Preferably, the specific process of step S1 includes: S11. Prepare authentication request information: After starting up, the client-side agent constructs an authentication request, which includes its own identifier robot_id, the target service identifier service_id, the current timestamp, and a one-time random number nonce; S12. Generate authentication verification code: The edge agent uses its pre-configured long-term key to calculate the SM3-based message authentication code for the above authentication request content, which is used to prove the authenticity and integrity of the request to the KDC. S13. Send authentication request to KDC: The terminal agent sends the authentication request and the corresponding SM3 verification code to KDC to request access to the specified control center service. S14. Receive the authentication result returned by KDC: If the authentication is successful, the terminal agent obtains the session key used to communicate with the control center from the response of KDC, and KDC generates an encrypted ticket and the corresponding initialization vector for the control center. S15. Forward Ticket to Control Center: The edge agent forwards the encrypted ticket and initialization vector returned by KDC to the control center as is, as the identity credential for subsequent access services; S16. Entering the secure communication phase: After obtaining the session key, the edge agent enters the standby state, generates business messages as needed, and uses the session key to encrypt the business data using SM4, while generating an integrity check code based on SM3. S17. Sending encrypted service messages: The terminal agent sends a message containing encrypted tickets, encrypted service data, and verification codes to the control center to request specific services.
[0012] Preferably, the specific process of step S2 includes: S21. Receive authentication request from the end-side intelligent agent: KDC receives the authentication request from the end-side intelligent agent and parses its own identifier, target service identifier, timestamp, random number and authentication verification code. S22. Verify the legitimacy of the client-side agent: KDC finds the corresponding long-term key based on the client-side agent identifier and uses the key to recalculate the SM3 checksum to verify whether the request comes from a legitimate client-side agent and has not been tampered with. S23. Check timestamps and replay attacks: KDC checks whether the request timestamp is within the allowed time window and combines it with the random number caching mechanism to determine whether the request is a replay request; S24. Generate Session Key: After successful authentication, KDC generates a new short-term session key for the end agent and the target control center for subsequent secure communication. S25. Constructing a service ticket: KDC encapsulates the edge agent's own identifier, the target service identifier, the session key, and the encrypted ticket validity period information into plaintext; S26. Encrypted Ticket: The KDC uses the long-term key of the control center to encrypt the plaintext of the ticket using SM4 and generates a corresponding initialization vector, so that only the target control center can decrypt the ticket. S27. Return authentication result: KDC returns the session key, encrypted ticket and initialization vector to the end agent, completing the authentication and key distribution process.
[0013] Preferably, the specific process of step S3 includes: S31. Receive ticket or service request: The control center receives messages from the edge intelligent agent; S32. Decrypt and verify the ticket: The control center uses its own long-term key to decrypt the ticket. If the decryption is successful, it means that the ticket was indeed generated by KDC for this service and the source is trustworthy. S33. Extracting Session Key and Identity Information: The control center obtains the terminal agent's own identifier, session key, and ticket validity information from the ticket plaintext, and confirms that the ticket is still valid. S34. Verify the integrity of business messages: For a business request, the control center uses the session key obtained from the ticket to recalculate the SM3 checksum for the business data and compares it with the checksum sent by the end-side intelligent agent. S35. Decrypting business data: If the integrity verification passes, the control center uses the session key to decrypt the business data using SM4 to obtain the plaintext business content. S36. Execute business logic: The control center performs corresponding operations based on the decrypted business information.
[0014] Preferably, in step S31, the message received by the control center from the end-side intelligent agent contains a ticket issued by the KDC, or carries an encrypted service request for the ticket.
[0015] This invention also provides a secure interaction system between multiple agents to implement the above-mentioned interaction method, specifically including: Intelligent Agent Identity Module: Determines the identity of an intelligent agent as a "thing", enabling information identity traceability between people, between people and machines, and between machines in the Internet of Things; Key Distribution Center (KDC): Stores long-term keys for all edge agents and long-term keys for all control centers; responsible for identifying edge agents, generating session keys, and issuing tickets visible only to the control center; Encrypted transmission module: using proprietary protocols or leveraging mature technologies and equipment to achieve cyberspace security, including IPSec VPN security gateway devices and firewalls; Monitoring software: including the KDC main program, control center terminal, and client terminal, monitors whether the interactive information is successfully encrypted; Authentication protocol: used to perform authentication; Control Center: Used to provide specific service identity, holds its own long-term key, can verify tickets, can communicate using session keys, and does not need to know the long-term key of the end agent; Edge-side intelligent agent: The identity of the agent requesting the service, holding its own long-term key, capable of encrypting / verifying messages, and not "directly trusted" by any control center.
[0016] Preferably, the authentication protocol adopts a private authentication protocol or a Kerberos authentication protocol, and uses symmetric encryption technology to provide strong authentication for the end-side intelligent agent / server.
[0017] The present invention also provides a secure interaction device between multiple agents, including the system described above.
[0018] The beneficial effects of the multi-agent secure interaction method, system, and device provided by this invention are as follows: (1) This multi-agent secure interaction method constructs a closed-loop secure interaction link through a six-step process involving collaboration among the end-side agent, KDC, and control center (authentication request, KDC verification and distribution, ticket forwarding, encrypted service transmission, ticket decryption verification, and service decryption execution). This method achieves strong identity authentication for the end-side agent (based on long-term keys and SM3), secure distribution of dynamic session keys (generated by a trusted KDC), and end-to-end encryption (SM4) and integrity protection (SM3) for all subsequent service communications. It effectively solves problems such as easy forgery of agent identities, plaintext transmission of communication, and difficulty in key management.
[0019] (2) This multi-agent secure interaction method constructs a security boundary by using robot authentication, Kerberos protocol, domestic key SM3 / SM4 / SHA3, IPSec encrypted transmission and configurable expiration interval, etc., and provides services such as access isolation, identity authentication, access control, data encryption and transmission encryption. It ensures that all types of data (including confidential data and ordinary data) are processed in compliance with regulations during collaborative interaction, and constructs a security defense scheme of "always verify, never trust", which effectively prevents data leakage.
[0020] (3) This multi-agent secure interaction system integrates authentication protocols suitable for distributed network environments with national cryptographic algorithms, adapting to resource-constrained agent scenarios, and forming a lightweight, highly secure, and controllable multi-agent secure interaction system. It achieves full-process security reinforcement from "identity" to "communication," providing solid technical support for large-scale secure applications of multi-agent systems in fields such as intelligent logistics, industrial robot clusters, and smart cities, and has significant industrial practical value. Attached Figure Description
[0021] Figure 1 This is the overall flowchart of the interaction method in this invention.
[0022] Figure 2 This is a flowchart illustrating the steps involved in issuing a service request to the edge-side intelligent agent in this invention.
[0023] Figure 3 This is a flowchart illustrating the specific steps of KDC authentication and key distribution in this invention.
[0024] Figure 4 This is a flowchart illustrating the specific steps of the control center authentication and execution process in this invention.
[0025] Figure 5 This is a block diagram of the interactive system in this invention.
[0026] Figure 6 This is a general technical block diagram of the interactive system in this invention.
[0027] Figure 7 This is a network topology diagram of the interactive system in this invention.
[0028] Figure 8 This is a diagram of the encryption model for Kerberos and cryptographic security authentication in this invention. Detailed Implementation
[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 without creative effort are within the protection scope of the present invention.
[0030] Example 1: A secure interaction system between multiple agents.
[0031] Reference Figures 5 to 7 As shown, a secure interaction system between multiple agents specifically includes: (1) Intelligent Agent Identity Module 1: Determine the identity of the intelligent agent as a "thing" and realize the traceability of information identity in the Internet of Everything, such as human-human, human-machine, and machine-machine.
[0032] (2) Key Distribution Center (KDC) 2: As a trusted third party, its identity is equivalent to the "notary office" in the whole system; Function: Store the long-term keys of all end-side intelligent agents (such as robots) and store the long-term keys of all services (control center); Responsible for: verifying the identity of end-side intelligent agents (such as robots), generating session keys, issuing "tickets that are only shown to services (control center)", etc.
[0033] (3) Encrypted transmission module 3: Using mature technologies and equipment to achieve network space security, including IPSecVPN security gateway equipment, firewalls, etc.
[0034] (4) Monitoring software 4: including KDC main program, control center terminal and client, to monitor whether the interactive information is successfully encrypted.
[0035] (5) Mainstream authentication protocol, Kerberos protocol 5: used for authentication. Kerberos is a trusted third-party authentication protocol that uses symmetric encryption technology to provide strong authentication for clients / servers. The Kerberos protocol provides a powerful authentication mechanism for network services through a ticket-based authentication protocol. Its core technology is to issue tickets to both communicating parties through a trusted third party (Key Distribution Center, KDC) to achieve two-way authentication and session key distribution. The Kerberos protocol has advantages such as single sign-on, two-way authentication, and prevention of replay attacks, but it also has limitations such as single point of failure and strict time synchronization requirements.
[0036] (6) Control Center 6 (Server): Provides a specific service identity. Functions: Holds its own long-term key, can verify tickets, can communicate using session keys, and does not need to know the client's (agent such as a robot's) long-term key.
[0037] (7) End-side agent 7 (client, such as a robot), the identity of the requesting service. Function: Holds its own long-term key (used only with KDC), can encrypt / verify messages, and is not "directly trusted" by any service.
[0038] Reference Figure 8 As shown, this system adopts a centralized authentication mechanism based on Kerberos and replaces traditional algorithms with domestic cryptographic algorithms such as SM4, SM3, and SM2 to achieve two-way authentication and secure communication between the robot and the control center. The authentication process includes three stages: TGT acquisition (Ticket Granting Ticket), service ticket application, and service access. After successful authentication, symmetric encrypted communication is performed based on a dynamic session key, thereby achieving confidentiality, integrity, and resistance to replay attacks.
[0039] This multi-agent secure interaction system clearly defines core modules such as agent identity, KDC, and control center. In particular, it adopts an authentication protocol based on Kerberos principles combined with domestic cryptographic algorithms (SM3 / SM4). This enables the system to not only possess the advantages of Kerberos protocol's two-way authentication and prevention of replay attacks, but also meet the compliance requirements of high-security business scenarios through domestic cryptographic algorithms, and effectively avoid the supply chain security risks that may arise from introducing foreign encryption algorithms.
[0040] Example 2: A method for secure interaction between multiple agents.
[0041] Reference Figures 1 to 8As shown, a secure interaction method between multiple agents based on the secure interaction system between multiple agents in Embodiment 1 mainly includes three core processes: the client-side agent issuing a service request, KDC authentication and key distribution, and control center authentication. Specifically, it includes: I. The edge-side intelligent agent issues a service request (see...) Figure 2 (as shown) 1. Prepare authentication request information: After startup, the edge-side intelligent agent (such as a robot) constructs an authentication request, which includes its own identifier robot_id, the target service identifier service_id, the current timestamp, and a one-time random number nonce.
[0042] 2. Generate authentication verification code: The edge agent (such as a robot) uses its own pre-configured long-term key to calculate the SM3-based message authentication code for the above authentication request content, which is used to prove the authenticity and integrity of the request to the KDC.
[0043] 3. Send an authentication request to the KDC: The edge-side intelligent agent (such as a robot) sends the authentication request and the corresponding SM3 checksum to the KDC to request access to the designated control center service.
[0044] 4. Receive the authentication result returned by KDC: If authentication is successful, the robot obtains the session key used for communication with the control center from the KDC's response. The KDC then generates an encrypted ticket for the control center (which the robot cannot decrypt, but is only responsible for forwarding), as well as the initialization vector corresponding to the encrypted ticket.
[0045] 5. Forward the ticket to the control center: The edge-side intelligent agent (such as a robot) forwards the ticket and initialization vector returned by the KDC to the control center as is, as an identity credential for subsequent access services.
[0046] 6. Entering the secure communication phase: After obtaining the session key, the edge agent (such as a robot) enters a standby state, generates business messages as needed, and uses the session key to encrypt the business data using SM4, while generating an integrity check code based on SM3.
[0047] 7. Send encrypted service messages The edge-side intelligent agent (such as a robot) sends a message containing tickets, encrypted business data, and verification codes to the control center to request specific services.
[0048] II. KDC (Key Distribution Center) and Key Distribution (see...) Figure 3 (as shown) 1. Authentication request from the receiving end-side intelligent agent (e.g., a robot): KDC receives authentication requests from edge-side intelligent agents (such as robots), and parses the edge-side intelligent agent's (such as robot) own identifier robot_id, target service identifier service_id, current timestamp, one-time random number nonce, and authentication verification code.
[0049] 2. Verify the legitimacy of edge-side intelligent agents (such as robots): KDC looks up the corresponding long-term key based on the identifier of the edge agent (such as a robot), and uses the key to recalculate the SM3 checksum to verify whether the request comes from a legitimate edge agent (such as a robot) and has not been tampered with.
[0050] 3. Check timestamps and replay attacks: KDC checks whether the request timestamp is within the allowed time window and uses the random number caching mechanism to determine whether the request is a replay request.
[0051] 4. Generate session key: After successful authentication, KDC generates a new short-term session key for the edge agent (such as a robot) and the target control center for subsequent secure communication.
[0052] 5. Construct service tickets: KDC encapsulates information such as the edge agent's (e.g., robot) own identifier, target service identifier, session key, and ticket validity period into ticket plaintext.
[0053] 6. Encrypted Tickets: KDC uses the control center's long-term key to encrypt the plaintext of the ticket using SM4 and generates a corresponding initialization vector, so that only the target control center can decrypt the ticket.
[0054] 7. Return authentication result: KDC returns the session key (for use by the edge agent), the encrypted ticket, and the initialization vector to the edge agent (such as a robot) to complete the authentication and key distribution process.
[0055] III. Control Center Certification (see...) Figure 4 (as shown) 1. Receiving invoices or business requests: The control center receives messages from edge-side intelligent agents (such as robots), which may contain tickets issued by the KDC or encrypted business requests carrying tickets.
[0056] 2. Decrypt and verify the ticket: The control center uses its own long-term key to decrypt the ticket. If decryption is successful, it indicates that the ticket was indeed generated by the KDC for this service and its source is trustworthy.
[0057] 3. Extract session key and identity information: The control center obtains the edge agent's (such as a robot's) own identifier, session key, and ticket validity information from the ticket plaintext, and confirms that the ticket is still valid.
[0058] 4. Verify the integrity of business messages: For a business request, the control center uses the session key obtained from the ticket to recalculate the SM3 checksum for the business data and compares it with the checksum sent by the edge agent (such as a robot).
[0059] 5. Decrypt business data: If the integrity verification passes, the control center uses the session key to decrypt the business data using SM4 to obtain the plaintext business content.
[0060] 6. Execute business logic: The control center executes corresponding operations based on the decrypted business information, thereby completing a secure and reliable access process for an edge-side intelligent agent, such as a robot.
[0061] This invention clarifies the responsibilities and security boundaries of each entity by detailing the operations of the edge agent, KDC, and control center. The edge agent only holds a long-term key shared with the KDC and cannot decrypt service tickets, thus achieving decoupling from the service and minimizing trust. The KDC centrally manages the keys and performs strict replay protection checks, becoming the cornerstone of the system's security. The control center autonomously obtains the session key and verifies requests by decrypting tickets, without needing to know the edge agent's key. This design ensures the rigor and feasibility of the entire process; any single point of attack will not directly jeopardize the entire system.
[0062] To further explain the present invention, this embodiment takes the example of a hotel logistics delivery robot (as an end-side intelligent agent) needing to report its task status to a central scheduling system (as a control center) to illustrate the implementation process of this method.
[0063] Assume that it has been pre-deployed in the system.
[0064] Key Distribution Center (KDC): Stores the long-term key K_robot for all robots and the long-term key K_service for all control centers.
[0065] Robot R: It is pre-configured with its unique identifier robot_id_R and a long-term key K_R shared with KDC.
[0066] Central Dispatch Service S: Its service identifier service_id_S and long-term key K_S shared with KDC are pre-configured.
[0067] The interaction flow is as follows: Phase 1: Authentication and Ticket Acquisition 1. After robot R starts, it needs to communicate with the scheduling service S. It generates an authentication request: Req_Auth = {robot_id_R, service_id_S, timestamp_T, nonce_N}.
[0068] 2. Robot R uses its own long-term key K_R to calculate the SM3 message authentication code MAC_Auth =SM3(K_R, Req_Auth) for Req_Auth.
[0069] 3. Robot R sends (Req_Auth, MAC_Auth) to KDC.
[0070] 4. After KDC receives the request: a. Locate K_R based on robot_id_R.
[0071] b. Recalculate the SM3 value of Req_Auth using K_R, compare it with the received MAC_Auth, and verify the bot's identity and request integrity.
[0072] c. Check if timestamp_T is within the valid time window and check if nonce_N has appeared in the cache (to prevent replay attacks).
[0073] d. After all verifications are successful, KDC generates a short-term session key SK_session.
[0074] e. KDC constructs the plaintext ticket: Ticket_Plain = {robot_id_R, service_id_S, SK_session, expiry_time}.
[0075] f. KDC uses the long-term key K_S of service S to encrypt Ticket_Plain using the SM4 algorithm, generating an encrypted ticket Ticket_Enc and a corresponding initialization vector IV_ticket. This ticket cannot be decrypted by robot R.
[0076] g. KDC sends {SK_session, Ticket_Enc, IV_ticket} to robot R.
[0077] 5. Robot R receives the response and saves the session key SK_session.
[0078] Phase Two: Service Access and Secure Communication 6. Robot R forwards {Ticket_Enc, IV_ticket} to the central scheduling service S as is. This is its "ticket" to access the service.
[0079] 7. After Service S receives the invoice: a. Using your own long-term key K_S and IV_ticket, perform SM4 decryption on Ticket_Enc to obtain Ticket_Plain.
[0080] b. Successful decryption proves that the ticket was issued by KDC and its source is credible.
[0081] c. Extract robot_id_R, SK_session, and expiry_time from Ticket_Plain, and check if the ticket is within its validity period.
[0082] 8. After that, robot R needs to send business data (such as "Task A has been completed").
[0083] a. Robot R uses the session key SK_session to encrypt the business data Data using the SM4 algorithm, resulting in Enc_Data.
[0084] b. At the same time, use SK_session to calculate the SM3 integrity check code MAC_Data of Data (or Enc_Data, depending on the protocol).
[0085] c. Robot R sends {Ticket_Enc, Enc_Data, MAC_Data} to service S.
[0086] 9. After service S receives the business request: a. Since the ticket has been verified and cached in a previous session (or decrypted and verified again), service S retrieves the corresponding SK_session from it.
[0087] b. Service S uses SK_session to recalculate the checksum of the received data and compares it with MAC_Data to verify data integrity.
[0088] c. After successful verification, use SK_session to decrypt Enc_Data using SM4 to obtain the plaintext business data Data.
[0089] d. Service S executes the corresponding business logic (such as updating task status) based on Data.
[0090] 10. In each subsequent interaction, robot R uses SK_session to encrypt data and generate a verification code. Service S uses the same key to verify and decrypt the data until the session key expires.
[0091] The core of this invention lies in introducing a trusted third party—a Key Distribution Center (KDC)—and drawing on the "ticket" concept of the Kerberos protocol, while deeply integrating domestically developed cryptographic algorithms, resulting in: (1) The edge agent (robot) and the control center (service) do not directly trust each other. They only trust the KDC. The robot obtains an "access credential" (ticket) by proving that it has a long-term key shared with the KDC. The service verifies the authenticity of the credential by being able to decrypt the ticket encrypted by the KDC with its key. This achieves centralized management of trust and minimizes its diffusion.
[0092] (2) The long-term key is used only for initial authentication and ticket encryption. Actual business communication uses one-time or short-term session keys, which are dynamically generated by the KDC and distributed to both parties through a secure channel (tickets encrypted with the long-term key). This achieves forward security, ensuring that past session records will not be decrypted even if the long-term key is leaked in the future.
[0093] (3) In authentication requests and business communications, the SM3 algorithm generates a message authentication code (MAC) to ensure that information is not tampered with during transmission, thus achieving data integrity protection and authentication. The SM4 algorithm is used to encrypt service tickets issued by the KDC (using a long-term service key) and actual business data (using a session key), ensuring the confidentiality of communication.
[0094] (4) Through timestamps and one-time random number (nonce) mechanisms, KDC can effectively identify and reject replay attacks. Both tickets and session keys have expiration dates, which limits the time window for key exposure and further enhances security.
[0095] (5) From identity authentication, key distribution, credential transmission to encrypted business communication, the entire process forms a secure closed loop. Monitoring software can monitor the encryption and decryption status of each link to ensure that the security policy is executed correctly. The edge intelligent agent, KDC, and control center each perform their respective duties and together constitute a defense-in-depth system of "always verifying and never trusting".
[0096] Through the above mechanisms, this invention enables multiple agents to perform collaborative work in open or semi-open network environments with high levels of identity credibility, data confidentiality, and integrity in their interaction process. This can meet the application needs of high-security human-computer interaction and machine-machine collaboration scenarios in fields such as finance, telecommunications, government affairs, and high-end manufacturing.
[0097] Example 3: A Secure Interaction Device Between Multiple Agents A secure inter-agent interaction device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor loads a secure inter-agent interaction system as described in Embodiment 1. When the secure inter-agent interaction system executes the program, it implements the secure inter-agent interaction method of Embodiment 2. This allows any computing device equipped with memory and a processor (such as an intelligent robot, smartphone, or server) to execute the method, realizing the productization and widespread application of the technology.
[0098] The above description is only a preferred embodiment of the present invention, but the present invention should not be limited to the content disclosed in the embodiments and drawings. Therefore, any equivalent or modified embodiments made without departing from the spirit of the present invention shall fall within the protection scope of the present invention.
Claims
1. A method for secure interaction among multiple agents, characterized in that... Specifically, the steps include the following: S1. The terminal agent sends a service request: After the terminal agent starts, it assembles an authentication request containing its own identifier, target service identifier, timestamp, and one-time random number, calculates the SM3 message authentication code using the local long-term key, and sends the request and verification code to the KDC. After successful authentication, the edge agent receives the session key, the uncryable encrypted ticket from the control center, and the corresponding initialization vector issued by the KDC, and forwards the ticket and vector to the control center. During subsequent business interactions, the edge agent uses the session key to encrypt the business data using SM4 and generates an SM3 integrity check code. It then sends the ticket, encrypted business data, and check code to the control center to conduct secure business communication. S2, KDC Authentication and Key Distribution: The KDC receives the authentication request from the client-side agent, parses the client-side agent's own identifier, target service identifier, timestamp, random number, and SM3 checksum, retrieves the client-side agent's corresponding long-term key to recalculate the checksum and complete the identity verification. At the same time, it verifies the timestamp, uses random number buffering to resist replay attacks, and generates a short-term session key between the client-side agent and the control center after verification. It encapsulates the ticket plaintext and encrypts it with the control center's long-term key using SM4 to generate the corresponding initialization vector. Finally, it sends the session key, encrypted ticket, and initialization vector back to the client-side agent to complete authentication and key distribution. S3. Control Center Authentication and Execution: The control center receives tickets or encrypted service requests with tickets forwarded by the end-side intelligent agent, decrypts the tickets using its own long-term key, verifies that the tickets were issued by the KDC, extracts the end-side intelligent agent's own identifier, session key, and ticket validity period after decryption, and verifies the validity of the tickets; for the service request, it uses the session key to recalculate the SM3 checksum to complete the integrity verification, and after the verification is passed, it uses the session key SM4 to decrypt the service data to obtain the plaintext, and finally executes the service logic to complete the trusted access process of the end-side intelligent agent.
2. The method for secure interaction between multiple agents as described in claim 1, characterized in that, The specific process of step S1 includes: S11. Prepare authentication request information: After starting up, the client-side agent constructs an authentication request, which includes its own identifier robot_id, the target service identifier service_id, the current timestamp, and a one-time random number nonce; S12. Generate authentication verification code: The edge agent uses its pre-configured long-term key to calculate the SM3-based message authentication code for the above authentication request content, which is used to prove the authenticity and integrity of the request to the KDC. S13. Send authentication request to KDC: The terminal agent sends the authentication request and the corresponding SM3 verification code to KDC to request access to the specified control center service. S14. Receive the authentication result returned by KDC: If the authentication is successful, the terminal agent obtains the session key used to communicate with the control center from the response of KDC, and KDC generates an encrypted ticket and the corresponding initialization vector for the control center. S15. Forward Ticket to Control Center: The edge agent forwards the encrypted ticket and initialization vector returned by KDC to the control center as is, as the identity credential for subsequent access services; S16. Entering the secure communication phase: After obtaining the session key, the edge agent enters the standby state, generates business messages as needed, and uses the session key to encrypt the business data using SM4, while generating an integrity check code based on SM3. S17. Sending encrypted service messages: The terminal agent sends a message containing encrypted tickets, encrypted service data, and verification codes to the control center to request specific services.
3. The secure interaction method among multiple agents as described in claim 1, characterized in that, The specific process of step S2 includes: S21. Receive authentication request from the end-side intelligent agent: KDC receives the authentication request from the end-side intelligent agent and parses its own identifier, target service identifier, timestamp, random number and authentication verification code. S22. Verify the legitimacy of the client-side agent: KDC finds the corresponding long-term key based on the client-side agent identifier and uses the key to recalculate the SM3 checksum to verify whether the request comes from a legitimate client-side agent and has not been tampered with. S23. Check timestamps and replay attacks: KDC checks whether the request timestamp is within the allowed time window and combines it with the random number caching mechanism to determine whether the request is a replay request; S24. Generate Session Key: After successful authentication, KDC generates a new short-term session key for the end agent and the target control center for subsequent secure communication. S25. Constructing a service ticket: KDC encapsulates the edge agent's own identifier, the target service identifier, the session key, and the encrypted ticket validity period information into plaintext; S26. Encrypted Ticket: The KDC uses the long-term key of the control center to encrypt the plaintext of the ticket using SM4 and generates a corresponding initialization vector, so that only the target control center can decrypt the ticket. S27. Return authentication result: KDC returns the session key, encrypted ticket and initialization vector to the end agent, completing the authentication and key distribution process.
4. The secure interaction method among multiple agents as described in claim 1, characterized in that, The specific process of step S3 includes: S31. Receive ticket or service request: The control center receives messages from the edge intelligent agent; S32. Decrypt and verify the ticket: The control center uses its own long-term key to decrypt the ticket. If the decryption is successful, it means that the ticket was indeed generated by KDC for this service and the source is trustworthy. S33. Extracting Session Key and Identity Information: The control center obtains the terminal agent's own identifier, session key, and ticket validity information from the ticket plaintext, and confirms that the ticket is still valid. S34. Verify the integrity of business messages: For a business request, the control center uses the session key obtained from the ticket to recalculate the SM3 checksum for the business data and compares it with the checksum sent by the end-side intelligent agent. S35. Decrypting business data: If the integrity verification passes, the control center uses the session key to decrypt the business data using SM4 to obtain the plaintext business content. S36. Execute business logic: The control center performs corresponding operations based on the decrypted business information.
5. The secure interaction method between multiple agents as described in claim 4, characterized in that, In step S31, the control center receives a message from the end-side intelligent agent containing a ticket issued by the KDC, or an encrypted service request carrying the ticket.
6. A secure interaction system between multiple agents, characterized in that, To implement the interaction method according to any one of claims 1-5, specifically including: Intelligent Agent Identity Module: Determines the identity of an intelligent agent as a "thing", enabling information identity traceability between people, between people and machines, and between machines in the Internet of Things; Key Distribution Center (KDC): Stores long-term keys for all edge agents and long-term keys for all control centers; responsible for identifying edge agents, generating session keys, and issuing tickets visible only to the control center; Encrypted transmission module: using proprietary protocols or leveraging mature technologies and equipment to achieve cyberspace security, including IPSec VPN security gateway devices and firewalls; Monitoring software: including the KDC main program, control center terminal, and client terminal, monitors whether the interactive information is successfully encrypted; Authentication protocol: used to perform authentication; Control Center: Used to provide specific service identity, holds its own long-term key, can verify tickets, can communicate using session keys, and does not need to know the long-term key of the end agent; Edge-side intelligent agent: The identity of the agent requesting the service, holding its own long-term key, capable of encrypting / verifying messages, and not "directly trusted" by any control center.
7. The multi-agent secure interaction system as described in claim 6, characterized in that, The authentication protocol adopts a private authentication protocol or a Kerberos authentication protocol, and uses symmetric encryption technology to provide strong authentication for the end-side intelligent agent / server.
8. A secure interaction device between multiple agents, characterized in that... include: The system as described in any one of claims 6-7.
Citation Information
Patent Citations
End-side agent autonomous execution and state management method based on standardized protocol
CN122309032A
V2V bidirectional authentication and session key negotiation method with conditional privacy protection based on ECC
CN122420824A